>>>> Today I isolated an SMTP interoperability problem which was induced
by
>>>> the fact that V8.6.12 sendmail terminates it's SMTP commands with
>>>> linefeed instead of <CR><LF>. Perhaps this is configurable via
>>>> sendmail.cf but doesn't the standard clearly state that SMTP
commands are
>>>> to be terminated by <CR><LF> (mine does)?
>>>> I'm hoping that someone will answer the following questions so
that I can
>>>> choose the best strategy to resolve this delema.
>>>> 1) Are there many versions of sendmail (or other MTA
implementations)
>>>> that terminate 821 command lines with just a linefeed char?
>>>> 2) Is this a known sendmail glitch (bug) that happened fairly
recently
>>>> that is fixed ?? OR 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.
A special thanks to the following people for their quick repsonses:
Ned Freed
Chris Bartram
Randall Gellens
I also agree with all of the above and now have a better understanding of
how prevalent the problem is. My position was similar to Ned's
suggestion which is to incorporate a customer configurable switch. I
have been thru this kind of thing before where you sometimes have to
support nonconformant behavior in order to keep a customer's
infrastructure operable (it's a real shame).
Ned, I'll submit a request to the DRUMS (Detailed Revision/Update of
Messaging Standards) mailing list to get this more visible (if it isn't
already) in the Internet-Draft of the revised SMTP document.
-regards,
Mike