On 18/03/2021 13:51, John C Klensin wrote:
There are, I think, two unresolved question about the
interactions with extended reply codes. One is what a client is
expected to do it receives an unrecognized code --either one in
the ranges used by SMTP/5321 or completely out of range (666
anyone?)-- followed by some digits and periods that might be an
extended code?
From our SMTP client's point of view. An *extended* status code can be
anything, but the basic status codes have to be 1xx to 5xx (xx can be
any non-space character - we're quite forgiving). A response of "451
8.5.1 whoopsie" would be treated as a response of 451 with text "8.2.1
whoopsie"
An invalid basic status such as '666' would be treated as a generic 5xx
response. I'm not really sure what else could be done with it.
We just use the first digit of the basic status code, and pretty much
ignore the extended status code. There's the *option* of doing something
with it, and the user (server administrator) can set it up to do
something with it, but, as far as I am aware, no one ever does, as it's
too fragile, and gives negligible benefit for our customers. (For mail
servers handling more mail, then I wouldn't be surprised if they do
something with the extra digits, but our software is aimed at SMEs, not
at Gmail-wannabees.)
IME, the code details and extended codes are slightly useful for
diagnostic and troubleshooting, but, not really, as most of them are
only useful to the remote mail server "administrators", and in most
cases those people haven't got a clue what would trigger the different
codes.
assumption that, with a problem reply code, the strings cannot
be assumed to be extended response codes. The other is that,
if it were really the case that most MTAs are ignoring all but
the first digit, what are they transmitting back toward the
sender and does it include the extended codes and original text.
In SMTP responses we generate we use the 5321 response codes and 3463
extended codes, or the nearest suitable ones (by our guesstimates, since
the RFCs don't give values for all possible reasons)
In NDRs we generate we use the codes and text given by the remote
server, whatever they are. Ours is not to reason why... One of my pet
hates is mail servers which decide that ANY 452 code means "Requested
action not taken: insufficient system storage" even when the original
text is nothing like that. Yes, I have seen that happen, and it's a
nightmare to diagnose through.
--
Paul
Paul Smith Computer Services
support(_at_)pscs(_dot_)co(_dot_)uk - 01484 855800
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp