CRLF as per RFC3156 5.1

[massar]

After decoding the plain text, make sure to convert LF -> CRLF as per RFC3156 5.1: 8<------------- (1) The data to be signed MUST first be converted to its content- type specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical sequence. ------------>8

[vixie]

deep in the heart of the code itself, we see this:

    $_ = $msg->stringify_body;
    study $_;
    # surprise! Mail::SendEasy does not implement RFC 821 4.5.2!
    s:^\.:..:mgo;
    # nor does Mail::SendEasy ensure that line terminators are \r\n
    s:\r\n$:\n:mgo;
    s:\n$:\r\n:mgo;
    if ($debug) {
            print;
    } else {
            $smtp->print($_);
    }

if this is correct, we're normalizing to \r\n as the line ending. no \n will survive unless it is not the last character of a line. so, only when the body or an attachment is encoded in some way that disassociates the SMTP framing protocol's line endings from the message content -- like quoted-printable with its =0D=0A, or base64, or similar.

i do not believe that we should modify these blobs. if richard is seeing \n in an attachment, it's because (a) that body or attachment came to ops-t's mail-handler that way, and (b) it came to us in a way that disassociates the body or attachment text's line termination framing from SMTP's line termination framing. richard's gripe is with those senders, or the e-mail tools used by those senders.

tearing apart every body and every attachment so that we can ensure that it uses proper internal line termination framing is madness. our responsibility is to ensure that we use the right framing from SMTP's point of view -- and, we are.