... Should MTA implementations be modified to accept it since there
are many versions of sendmail out there doing this already?
I say NO. Patching conforming implementations to adopt to broken ones
propogates garbage. If MTAs refuse to communicate with hosts running
software that sends LF instead of CRLF, those hosts will get fixed.
Easy to say, but if you're selling SMTP mail system(s) and your customers
call you complaining that they can't get mail to john doe, or when they're
evaluating the product and can't get mail to their most important customer
you're hard pressed to point fingers. Especially when the fix is relatively
simple (if you encounter a LF character before you hit a CR when reading
the HELO command, then set your incoming line-terminator character(s) to
a LF instead of CRLF).
If you correct it coming in, then you're not propagating anything, just
following that oldest of 'net rules; be conservative in what you put out
and liberal in what you accept...
I agree with all of this, but please keep in mind that there is a big
difference between an implementation deciding to accept this junk and modifying
the standards to require implementations to accept it.
LF-terminated lines in SMTP are a fact of life every server implementor runs
into sooner later. Depending on context they will either get the offending
client fixed or else modify their server to accept this incompliant form. Or
provide a switch to let the customer choose whether or not strict compliance is
enforced in this area. (This last is what our PMDF products do.)
However, a note about the prevalance of this practice on the Internet,
how nonstandard it is, and in spite of this the reality of having to deal
with it, in the SMTP specification might be a good idea.
Ned