[Top] [All Lists]

RFC2821bis-02 Issue 28: Client behavior on unrecognized reply code (was: Re: New issue...)

2007-04-23 16:11:42


After thinking about the several comments on this, together with
other comments on the list, I want to propose threading the
needle with the following text, tentatively placed at the end of
the introduction to section 4.2:

                In the absence of extensions negotiated with the client,
                SMTP servers MUST NOT send reply codes whose first
                digits are other than 2, 3, 4, or 5.   Clients that
                receive such out-of-range codes SHOULD normally treat
                them as fatal errors and terminate the mail transaction.

Note that 
(1) This makes it incumbent on the server to not send junk.
That is where the real responsibility lies, IMO.

(2) It focuses on the first digit only.  I believe that the
existing text is adequately clear that, if one doesn't
understand the second or third digits, one should fall back on
the first.

(3) It avoids dealing with the question of what an "undefined"
code is entirely, dodging another rathole.

(4) If I've done it correctly, the final sentence dodges the
issue of whether to treat the unrecognized code as 4yz or 5yz.
We affirm the fact that this is a bad situation, suggest that
clients should be prepared for it, and use a SHOULD to indicate
"fatal... terminate".    From the standpoint of the standard,
such codes are really sufficiently out of scope that imposing
requirements on the client as to whether, e.g., to treat the
error as temporary or permanent seems like overkill.

Can everyone live with that, more or less?  If not, please
suggest alternate text and/or convince Tony that this particular
dead horse needs more kicking.


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