Re: Negotiated noncompliance

[[e-mail] ( Claus Färber )]

Robert Elz <[e-mail]> schrieb/wrote:
> On the LF issue specifically, do we have any evidence at all that any
> large number of clients are still doing this?

Sending bare LF is not the only problem.

There is also an interoperability problem regarding the handling of bare  
LF on the receiving side. According to the current standard, bare LFs  
are allowed within mail data. However, I don't think that _any_  
implementation will actually handle it correctly.

The whole CRLF/LF problem is due to a implementation technique mandated  
by C/C++ libraries: They detect line endings based on the LF only. As a  
result this is what also most MTA implementations do. They then strip  
the CR and treat the result as a line.

So if they receive a bare LF, they either give an error because the CR  
is missing /or/ treat it as equivalent to CRLF. Both is illegal  
according to the standard (within message bodies).

Further, implementations on Unix-like systems tend to write the message  
to their queue or to user's mailboxes with their local line-ending  
conventions. So even if the smtpd part would handle bare LFs correctly,  
they would be converted to CRLF when the message is relayed to the next  
host via SMTP (or made available to a client via protocols such as IMAP,  
POP3 or even local file access).

So while sending bare LFs within mail bodies is allowed by the standard,  
it just won't work with most MTAs and MUAs running on the Internet.

It's too late to change the installed base of MTAs and MUAs. Better  
change the standard to explicitly disallow (or at least discourage) bare  
LFs within message texts.

Although I know it's very late, I thus propose the following change in  
section 4.1.1.4 DATA (DATA):

< codes, although experience has indicated that use of control characters
< other than SP, HT, CR, and LF (especially the ASCII "Null" character)
< may cause problems and SHOULD be avoided when possible.

> codes, although experience has indicated that use of control characters
> other than SP, CR and HT (especially the ASCII "Null" and bare LF
> characters) may cause problems and SHOULD be avoided when possible.

Claus

-- 
http://www.faerber.muc.de