bruceg
Omit \r\r\n
- I don't think so. Mail-delivering-programms use \r\n or \n as line terminators. * getline splits on \n so only one \r remains at the end of the line if the Mail-delivering-programm uses \r\n
- I wrote that patch because my mails got crippled. I'm testing my patch since Jun 2021 :-). No problems so far.
*RFC 2821: SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
Just an additional hint. I anybody wan't to use the (great!) nullmailer with s/mime encoded mails like me, ionums patch is absolutely essential. All attempts to sign (end encrypt) mails with 'openssl smime' will fail without the patch! See https://stackoverflow.com/questions/66228622/how-to-use-openssl-to-sign-an-email-message-and-curl-to-send-it The pached smtp lib worked instantly with s/mime.
