John C Klensin wrote:
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.
I would agree with that. Something like:
If an SMTP client receives a reply code that is not defined by this
RFC or a negotiated extension, it SHOULD send a RSET or QUIT command, and
SHOULD treat the unknown reply code as a 5xx code.
I'm with you up to the 5yz code. I think 4yz would be more appropriate - that
way you don't bounce messages unnecessarily when dealing with a broken server.
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.
(I'm not too sure what to do if an undefined code is received in response
to a RCPT command. It's clear to me that you don't want to continue the
SMTP transaction, but do you want to fail all the recipients and
generate a non-delivery notification? Or do you want to just fail the
one recipient and retry the others (if any)?)
That brings us back to 1yz.
Well, it's not just 1yz that worries me. It's differing reply codes
in a multiline reply. As Tony Hansen pointed out, there are SMTP
implementations that do not simply use the last reply code, and
although their quality may be in question, they are in widespread use
and breaking them is not a good idea.
There's no quality issue here. As you yourself have pointed out, the
specifications are pretty clear that all the codes are supposed to be the same
and multiple acts of creative reading are needed to support any other
conclusion. And someone else has pointed out that using the first code can
simplify implementation. So: The standards permit use of the first code and it
can be simpler. Seems like a reasonably high quality choice to me.
Ned