On Tue, Jun 12, 2007 at 05:20:18PM -0400, John C Klensin wrote:
....
So...
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
received
"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.
john
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>