Of course, Postfix is out of conformance with the standard and,
maybe more important, breaking any signatures over the message
body text, by doing this. Basically you can't win.
And that requirement is in the standard, not only because of the
historical reason of some implementations needing to allocate an
appropriately-limited buffer length but because long lines have
occasionally been an attack vector on SMTP-receiver
implementations who neither enforced the limit by rejection or
some trick (like truncation or behavior like that Victor
describes) or that simply deal with the longer lines without
problems (essentially kicking that can down the road until
either something else rejects it or is messes up a
poorly-written MUA).
john
--On Thursday, January 16, 2020 13:44 -0500 Viktor Dukhovni via
Exim-users <exim-users@???> wrote:
>> On Jan 16, 2020, at 1:12 PM, Jeremy Harris via Exim-users
>> <exim-users@???> wrote:
>>
>>> Does anyone know of anything that Exim can do to modify the
>>> message as it is routed through
>>
>> Exim can't; it's a policy decision in what it regards it's job
>> as being. That covers things like not converting from
>> 8-bit-dirty to uuencoded, and so forth. This would come into
>> the same bucket.
>
> FWIW, on a best-effort "garbage in / garbage out" basis,
> Postfix by default folds long body lines in messages by
> inserting CRLF + SPACE.
>
> http://www.postfix.org/postconf.5.html#smtp_line_length_limit
>
> If the incoming message is not RFC-compliant, it may be
> modified in transit, in a way that minimizes damage to already
> poorly formed message.
