On Thu, 2003-12-18 at 11:16, Philip Hazel wrote:
> Sigh. *Sigh*. SIGH. S I G H! Sorry, I'm going to have to rant just a
> little; I can't keep it all bottled up.
you are entitled!
> The upshot of all this was a change at release 4.21, which was recorded
> thus:
>
> 58. Following a discussion on the list, the rules by which Exim recognises line
> endings on incoming messages have been changed. The -dropcr and drop_cr
> options are now no-ops, retained only for backwards compatibility. The
> following line terminators are recognized: LF CRLF CR. However, special
> processing applies to CR:
>
> (i) The sequence CR . CR does *not* terminate an incoming SMTP message,
> nor a local message in the state where . is a terminator.
whereas LF . LF *does*. (correct me if I'm wrong, my newest Exim is
4.20.)
> (ii) If a bare CR is encountered in a header line, an extra space is added
> after the line terminator so as not to end the header. The reasoning
> behind this is that bare CRs in header lines are most likely either
> to be mistakes, or people trying to play silly games.
[...]
> I suppose I could make it treat bare LF in a header like bare CR (see ii
> above), but only if this was SMTP over TCP/IP, and there had been a
> previous CRLF line terminator. Yuck.
since Exim's queue format uses LF only (not wire format -- IMHO this
should be fixed for the next major release), there aren't many
alternatives, if we want to accept the message:
1) change "abc" LF "def" CR LF
into "abc" LF SPC "def" LF
becoming "abc" CR LF SPC "def" CR LF when passed on to the next
server
2) strike that LF character
3) replace LF with "?" (this is what Sendmail does with NUL, btw)
I think I prefer 3). it would be nice to use a string making clear what
happened, such as "<bare LF!>", but there's no telling which syntactical
element the LF is inserted into, so this can change the interpretation
of the header substantially.
> > if you really, really want to support telnet sessions with no LF->CRLF
> > translation, you can make a note of what style of line ending was used
> > on the very first command (HELO or whatever).
>
> There have been bad experiences in the past with software that has tried
> to be clever like this. It tends to get confused when (by some kind of
> mistake) the first line is terminated differently to the subsequent
> lines. We saw this when the option to deliver messages locally with CRLF
> was introduced. If you set that option, but use a message_prefix with
> only LF, and the program you deliver to over a pipe tries to be clever
> like this, you have a problem.
ugh. but message_prefix *should* only have LF, with the LF being fixed
up when emitted? or are you saying this fixup isn't done when the
target is a pipe?
it is also not too unlikely that the SMTP commands are CRLF terminated,
while the DATA content has just LF, due to the former being produced by
a library, and the latter being sent to the library as a blob.
I'm not wholly convinced about the message_prefix example. it seems to
me that our best course of action is to consider the first line of DATA
content. what do you suggest?
--
Kjetil T.
