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 <[email protected]> wrote: >> On Jan 16, 2020, at 1:12 PM, Jeremy Harris via Exim-users >> <[email protected]> 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
