Re: CRs in messages
2001-05-28 15:48:59
> > 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 - except in the rare case when the other MTA/MUA
will be sending incorrect line terminators to commands, correct line
terminators in data AND the message contains raw LFs or CRs. In this case
it's still the other person's software which is behaving incorrectly and
your attempt to accept its incorrect data is just not catching every
possibility. In my experience, most MTAs use the same terminators for
commands and in the message data and for the message terminator.
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...
Checking for a CR.CR as the last data received at the point of a timeout is
a possibility, but as I've said it will stop any 'intelligent' MUA
behaviour such as MIME decoding/recoding on messages containing CR line
terminators.
If you always check for CRLF as the message terminator except at a timeout,
but allow any line terminator in the body of a message, then, as well as
introducing complexity, it means that message data may be 'corrupted' if
there are bare CRs or LFs in the middle of a message.
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... :-)
Paul VPOP3 - Internet Email Server/Gateway
paul(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/
|
|