ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-23 03:01:37



--On Sunday, 22 April, 2007 21:56 -0400 "David F. Skoll"
<dfs(_at_)roaringpenguin(_dot_)com> wrote:

Second, given the fact that 1yx are not currently defined for
current commands, it should be ignored.

Umm... no, I don't think so!

If you're writing a state machine (SMTP client) and it
receives some unknown reply code from the server, the ONLY
sane course of action is to QUIT or RSET.  The poor client has
no idea what the server means; it could be expecting the
client to alter its state in some way rendering subsequent
commands useless or dangerous.

Let me suggest looking at this particular piece of the argument
a different way, because it is an area in which we could put
some words into 2821bis if there was agreement on those words.

Many codes are "not currently defined" in 2821.  2821 and its
predecessors are pretty clear about what to do about them: the
rule is "use the first digit if you don't recognize the specific
code".  That leaves us
   6yz, 7yz, 8yz, 9yz, and 0yz
which are clearly and unambiguously "not defined".  What is a
client to do if it receives one of them?  Ignore it?  Does the
client assume that, because 6 > 5 and the code system tends
toward "worse" as the first digits get higher, that  650 is even
more permanently fatal than 550 and that 750 is more fatal than
that?  One could, but I suggest that it is a real stretch.
Absent extensions, does one assume that it is harmless because
it is lower-numbered than 2yz and that it should be ignored?  Or
does one assume that a 0yz code arises from some sort of
wrapping and so is "worse" or "more fatal and permanent" than
9yz would be, whatever that means?  Whatever the answers, it is
clear to me that 2821 (and 821, and FTP) offer no guidance at
all about what to do with one of these undefined codes.

The strawman proposed text would be a provision that a client
SHOULD (or perhaps even MUST) send a RSET or QUIT in response to
a code whose first digit is undefined by either 2821bis or a
negotiated extension.

That brings us back to 1yz.  I suggest that there are two
possible interpretations of it and that logic doesn't permit
anything else.  It is either an undefined code, in which case
the same analysis that applies to 0yz, 6yz...9yz above applies
also to it.  Or it is, because of the language in 821 (and
carried forward) a defined code  with a definition of "client
must now issue another command to tell the server whether to
continue or abort".   There are no cases in 821 or 2821 that
justify an interpretation of "required to ignore this defined
code" and nothing there, at least that I can find, that makes
ignoring an undefined code a safe thing to do.

      john


<Prev in Thread] Current Thread [Next in Thread>