> > I can't see how this can be worse than just expecting the standard line
> > terminators all the time -
> The altnerative that works better is to provide an option that lets you
> unconditionally accept bare CR or LF as a terminator. Basing the decision on
> what's used in commands offered no advantage over insisting on CRLF when I
> tried it.
I've just this minute seen a bad SMTP server response which makes me wonder
about all this...
I send a remote MTA a 'EHLO my.server.com' command and it responds with:
250-OK<CR><CR><LF>
250-SIZE 3072000<CR><CR><LF>
250 8BITMIME<CR><LF>
Unsurprisingly this upsets things as <CR><CR><LF> isn't a line terminator
our MTA recognises at the moment... (It sees <CR><CR> and says 'oh, this is
an MTA which uses bare <CR>s as line terminators, so it has a blank line in
the response). It's not consistent even then, because normal responses use
<CR><LF> it only seems to be the multiline responses which use <CR><CR><LF>
Indeed, this is one of the cases I was thinking of when I suggested that
determining what terminators are active based on initial behavior isn't a good
idea.
(The remote MTA is at mail.commerceqld.com.au if anyone wants to look..)
Yes, and at many other addresses as well. This is a *very* popular and widely
deployed server.
I wonder how much time 'good' MTA developers put in around the world to be
able to handle all the situations caused by 'bad' MTA developers..
If memory serves, I first spotted this one about two years ago. Several
things became clear almost immediately:
(a) The problem was going to be widespread.
(b) The problem wasn't going to be fixed in a timely fashion.
(c) It was limited to status responses.
(d) Changing more general line terminator settings to deal with it wasn't a
great idea.
As a result I implemented a very specific fix to deal with this problem that
didn't change terminator handling in other cases. Sites could deal with this
problem while still, if they decided to, accepting bare CR, bare LF, or both as
terminators elsewhere. It only took a few minutes to implement.
Since then I've spent far more time talking about the problem than I ever did
analyzing it and fixing it.
Ned