[Top] [All Lists]

Re: New issue (was Re: rfc2821bis-01 Issue 18: Usability of 1yz replies)

2007-04-23 12:54:55

John C Klensin wrote:

Hmm.  Do you want to requeue it and keep trying for four or five
days on the theory that the server might spontaneously fix
itself?  Or would it be better to bounce the puppy and hope that
someone will complain?    I think I can argue that one either

It does need to be a SHOULD so there's an out for dealing with
specific cases of brokenness where 5yz treatment has been
determined to be more appropriate operationally.

John, I think we all need to sleep on this more. :-)

First, this is definitely functionality change.

Second, the existing text in various spots already supports the idea of handling unrecognized codes. I've cut snippets below for your quick reading.

But before I continue, I would like to note that after researching many of the codes out there, most do not support the level of details for the reply codes as written in the text. So even though it is already documented, as we seen with the existence of broken software now deemed "high quality," I don't know what is the worth for the level of details here. i.e, it might be too complex.

That said, the text in 4.2. SMTP Replies, already has:

   Consequently, a sender-SMTP MUST be prepared to handle codes not
   specified in this document and MUST do so by interpreting the first
   digit only.

This is reiterated and reinforced in 4.3.2. Command-Reply Sequences.

   Since some servers may generate other
   replies under special circumstances, and to allow for future
   extension, SMTP clients SHOULD, when possible, interpret only the
   first digit of the reply and MUST be prepared to deal with
   unrecognized reply codes by interpreting the first digit only.

This 4.3.2 sentence makes it clear that "1yz " is not valid,

   Unless extended using the mechanisms described in Section 2.2, SMTP
   servers MUST NOT transmit reply codes to an SMTP client that are
   other than three digits or that do not start in a digit between 2 and
   5 inclusive.

But it is also inconsistent with the 4.2 sentence:

   An SMTP server SHOULD send only the reply codes listed in this

In 4.2.1.  Reply Code Severities and Theory, we have:

   An unsophisticated SMTP client, or one that receives an unexpected
   code, will be able to determine its next action (proceed as planned,
   redo, retrench, etc.) by examining this first digit.  An SMTP client
   that wants to know approximately what kind of error occurred (e.g.,
   mail system error, command syntax error) may examine the second
   digit.  The third digit and any supplemental information that may be
   present is reserved for the finest gradation of information.

This provides the framework on how to deal with undefined reply codes.

Rather than open a can of worms with defining new "RETRY" functionality for aborting clients, you can consider to simply use, change or define one of first digit codes as "ignore."

Ideally, x2z would be appropriate since we are partly dealing with connection issues.

In other words, these can be use to provide quideline as what may be recommended or augmented into the retry logic/recommendations.

For a completely unrecognized code, the client SHOULD ignore the code. It MAY begin its own timeout consideration. It MAY also abort. But I don't think that is not appropriate given what we already define about.

But like I said, I'm at a point now with the more than expected time and resources spent on this to do full source code analysis of many of these codes, that I recognized these level of spec reply code details are simply not followed.

As with the case with the first reply code issue, there is enough powerful voices here that would rather now endorse this BROKEN code behavior as high quality and compliant code in 2821bis, and even encourage the design as simple, optimized and high quality.

So given that the specification is far too complex and no common support for reply codes other than the pure basic codes, adding new layman logic to guide clients to "sanely" abort on unrecognized reply codes is as simple as it gets.


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