[Top] [All Lists]

Re: [ietf-smtp] [dispatch] Forced SMTP redirects

2021-03-18 09:25:06
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 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

ietf-smtp mailing list