https://bugs.exim.org/show_bug.cgi?id=3063
--- Comment #16 from Simon Arlott <[email protected]> --- (In reply to Viktor Dukhovni from comment #14) > (In reply to Simon Arlott from comment #13) > > > > Jeremy, you've still not explained why Exim is now changing message content > > like this. Postfix and Sendmail don't do it. > > Well, Postfix does in fact change message content when, for example, folding > overly long headers or body lines, in order to ensure RFC-compliant SMTP > output. > In this case a line-break + space is inserted, and even without attempting > to find a semantically appropriate context, garbage-in, garbage-out. > > So it wouldn't be entirely unprecedented to replace non-conformant input > with a plausible best-effort approximation. You could say the same thing about <LF>.<LF>, which is the cause of this problem to begin with. It could allow new attacks based on adding and removing headers. Incoming message with a second subject header hidden in what looks like the message body: ``` Received: ...<CRLF> X-Placeholder1: A<LF> Subject: A<CRLF> <LF> X-Placeholder2: B<CRLF> Subject: B<CRLF> <CRLF> Message body<CRLF> .<CRLF> ``` Spooled message with alternative subject header exposed: ``` Received: ... Received: ... X-Placeholder1: A Subject: A X-Placeholder2: B Subject: B Message body ``` > As a result, while both <LF> and <CRLF> were accepted as line endings on > input (leading to a "Normal" queue file record), the output is <CRLF> > terminated either way. So it would perhaps be more natural to canonicalise > <LF>.<LF> to <CRLF>.<CRLF> (but without treating it as end-of-message!). > The result would then be subject to dot-stuffing (SMTP transparency) on > output. I think this is the approach that should be taken. > One might accept <LF>.<LF> as message end only from clients whose "EHLO" and > all subsequent SMTP commands up to and including "DATA" are <LF> terminated. > This allows some legacy unix-native SMTP clients to continue to work, while > requiring RFC-conformant line-endings from all others. This could be implemented by checking that no <CR> character has been received anywhere in the plaintext of the connection (without needing to specifically check line endings on every command). A host list or expanded configuration variable would allow it to be accepted only from specific clients. (It could exclude checking the message content itself because a message with CRLF line endings could be sent through an SMTP client that only uses LF line endings, but that allows a form of SMTP smuggling.) -- You are receiving this mail because: You are on the CC list for the bug. -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/ ## unsubscribe (doesn't require an account): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
