ietf-822
[Top] [All Lists]

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/



<Prev in Thread] Current Thread [Next in Thread>