[Top] [All Lists]

Re: 2821bis: three-digit-and-crlf replies

2007-06-13 05:12:53

On Tue, Jun 12, 2007 at 05:20:18PM -0400, John C Klensin wrote:

Peter is correct: "250"CRLF (and "250 "CRLF) are in violation of 
the spec, but clients are expected to handle it as if they had 
  "250 random-string"CRLF

If one wants the ABNF to be normative and to accurately cover 
all of the corner cases, the 2821 syntax and the 2821bis fix are 
a little buggy.


I am following semi-strict SMTP protocol syntax analysis at the
smtp-server, but very loose one in smtp-client code that parses
replies given to it.

My server will in general conform to that "must have random-string"
type thinking.  (Replies to "HELP" may have blank lines, perhaps
even at last reply line.)

I would prefer if the syntax rules are precise for the input
that servers are expecting, but the reply processing should IMO
be as relaxed as possible.

My smtp-client reply mistreatment pitfall list has:

  - SMTP server replies are not guaranteed to arrive to client
    in single network packet, single line may arrive in multiple
    network packets.
  - SMTP server may use multi-line reply (see X.X.X)
  - Multiline replies may arrive in multiple network packets
    or in a single one
  - SMTP server may reply with "unexpected" reply codes, and
    thus knowing only how to react on expected set of precise
    codes is usually worst possible implementation strategy.
    In X.X.X of "Theory of reply codes" (sp?) do pay attention
    on the meaning of the first digit of the reply code!
  - In case implementer wants to have precise treatment of
    something (like "551 User not local; please try <forward-path>"
    or "251 User not local; will forward to <forward-path>")
    they can do so, but at the same time must also handle
    first-digit based rough classification for everything
    that does not need special cases - or are not known
    at the implementation time.)

All of those were encountered some 10 years ago in one big
and widely used workgroup communication and document management
system that has ad-hoc internet email interface .. possibly
the bugs still exist in it.

Should that kind of "SMTP pitfalls avoidance guide" be written
as separate RFC ?  Or as some sort of Wiki ?

/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>