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
way.
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
document.
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.
--
HLS