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.