Paul Smith writes:
> We just use the first digit of the basic status code, and pretty much ignore
> the extended status code.
The most common uses of extended status code appears to be in user-facing
email systems. When their users' mail bounces the extended status code
selects one of templates consisting of a long novel for a bounce message,
decorated with pretty fonts and animated graphics, that boils down to
"please don't contact our customer service/helpdesk about this, we can't do
anything about it", that attempts to explain to the reader why the message
cannot be delivered.
This is exactly they were intended to do: Provide detailed - and localized -
explanations of why an error occurred.
That's pretty much all that status code seems to be used for. When I'm
implementing the logic for an SMTP client the only thing I need to know, for
any given command's results is whether it succeeded, failed, or I should try
again later. So, if it's '1', '2', or '3', the operation is deemed as a
success, '4' means try again, and everything else means a failure. I've yet
to find myself in any situation where any other outcome is possible.
Use to classify faiures as "hard" or "soft" is quite common, as are any
number of more specialized (and mostly nonstandard) uses. AFAICR this
usage was never envisioned at the time they were standardized.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp