On 06/06/2020 18:22, Dave Crocker wrote:
I believe systems still vary on how they respond to an incoming LF. I
even suspect there are arguments for treating it only as data and
arguments for treating it as newline. I suspect, therefore, the
answer to your question will be how you assess the benefits and
detriments of each choice.
From personal experience - the mail server we publish *used* to treat
either LF or CRLF as a line ending. That stopped over 20 years ago
because of the unending problems it caused. Now LF is just a character
line any other if it's not preceded by a CR (similarly with a lone CR)
The problem is that if someone sends a message with LF.LF, and you treat
LF as a line ending, you've got a message terminator in the middle of a
message, causing all sorts of grief.
You can't expect a previous MTA to have dot-padded it, because the RFCs
don't say they should, so you end up with a situation where your mail
server behaves counter to what the user expects, and the RFCs say its
behaviour is wrong, so users are right to complain.
OTOH Treating ONLY CRLF as a line break is what the RFCs say, so it's
perfectly defensible behaviour.
I suppose with a submission server you could be more flexible, but, to
be honest, I've *never* come across a case where not treating a lone LF
as a line break has been a problem.
(To be honest, I'd be tempted to treat a lone LF as a 99.9999% reliable
indicator of spam. Similarly with a NULL (0x00) character in the middle
of an (RFC5322) message. Legitimate mail will just never have it unless
it was generated by something very dodgy).
--
Paul
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp