> > > The MTA is one we wrote ourselves, so we'll add an option to it to either
> > > accept ONLY CRLF as line terminators in messages (the new default) or
> > > accept any combination of LF, CR, CRLF (or even LFCR which we've seen in
> > > one instance from an MUA a couple of years ago..)
> > >
> > > We may make this a bit smarter in the future. One thing we've spotted in
> > > this case is that the message header is all formatted correctly, but the
> > > message body has bare CRs in it, so we may say that if the header is
> > > correct then we'll assume the rest of the message should be, but if the
> > > header uses just CRs or just LFs then we'll assume the rest of the
> message
> > > is the same as well.
>
> > One technique I've seen mentioned in a previous thread about this, and
> > which at least looks as if it should work well, was to look at the SMTP
> > commands the client sends.
>
>I've used this technique in the past. It did not work well in practice.
>In many implementations message and command handling are largely divorced
>from each other, and when one is broken it isn't predictable by looking
>at the other.
But surely, the thing is that if all the other MTA/MUAs are working
correctly, then they'll be sending the line terminators as CRLF, so if you
expect CRLF then you are obeying the standards. If the other MTA/MUAs
aren't working correctly, then they will either send commands with CR or LF
terminators in which case you can then set your MTA to expect ANY line
terminators, or it will send commands with a CRLF in which case you have
the fallback that you can point the finger at the other person's software
and say that it's not behaving correctly.
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 don't see that there's a 'perfect' solution to this, except for everyone
doing everything totally according to the standards, and I don't think
that'll ever happen...
You're right, it won't. The only way I've found that works is to
provide an option that lets people configure what they want to allow.
Maybe the best thing to do is just to disobey the 'be flexible in what you
receive' idea, and just reject anything which has incorrect line
terminators - at least that might put pressure on people to use the proper
ones... :-)
Even this doesn't work well, since you can't find the end of a message
reliably to report the error.
Ned