[Top] [All Lists]

what's up with sendmail commands ending with linefeed only?

1996-07-19 18:21:22

  >>>>  Today I isolated an SMTP interoperability problem which was induced
  >>>>   the fact that  V8.6.12 sendmail terminates it's SMTP commands with
  >>>>  linefeed instead of <CR><LF>.  Perhaps this is configurable via
  >>>> 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
  >>>>   that terminate 821 command lines with just a linefeed char?
  >>>>   2) Is this a known sendmail glitch (bug) that happened fairly
  >>>>   that is fixed ??  OR  Should MTA implementations be modified to
  accept it
  >>>>   since there are many versions of sendmail out there doing this

  >>> I say NO.  Patching conforming implementations to adopt to broken
  >>> 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
  >> call you complaining that they can't get mail to john doe, or when
  >>evaluating the product and can't get mail to their most important
  >> you're hard pressed to point fingers. Especially when the fix is
  >> simple (if you encounter a LF character before you hit a CR when
  >> the HELO command, then set your incoming line-terminator character(s)
  >> a LF instead of CRLF).
  >> If you correct it coming in, then you're not propagating anything,
  >> following that oldest of 'net rules; be conservative in what you put
  >> 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
  >the standards to require implementations to accept it.
  >LF-terminated lines in SMTP are a fact of life every server implementor
  >into sooner later. Depending on context they will either get the
  >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
  >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.