https://bugs.exim.org/show_bug.cgi?id=3063
--- Comment #16 from Simon Arlott <bugzilla.exim.simon@???> ---
(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):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
