On May 11, 2011, at 8:07 AM, Laura Atkins wrote:
On May 11, 2011, at 7:01 AM, Murray S. Kucherawy wrote:
I'm not following this thread closely, but I thought I'd say something
about extended status codes. Part of the idea of extended status codes
is that you should be able to determine the likely source of the
problem by looking at the second facet of the status code. Or to put
it another way, the second facet of the status code is supposed to
indicate _who_ probably needs to fix the problem (e.g. the sender, the
MSA, a relay, the delivery agent, etc.)
I haven't implemented this, but I have to say I really like this approach.
Perhaps the proposal would benefit from making such distinctions in the new
codes it's registering.
If you're going to make the second facet of the status code be who probably
needs to fix the problem, you could also make the third facet point to where
they need to go to fix it.
It doesn't even need to be that detailed. 1 for this is internal (so you need
to contact the recipient domain) and 2 for this is external (so you need to
contact a third party). Then follow that with a URL pointing to the third
party or the postmaster / internal troubleshooting pages.
If there's a URL or human readable message that's all that's needed for someone
to diagnose the delivery problem (which is how it's commonly done today).
Adding additional computer readable information as an extended response code is
only useful if it's intended to be handled entirely automatically - if you're
going to put human eyeballs on it, the human readable response is all you need,
once you've used the SMTP response (e.g. 5xx) to triage.
With the extended status codes as listed in this draft I don't see there being
enough additional information provided to automatically alter the senders
behaviour usefully in most cases, beyond the way they're already being
signalled by the SMTP status codes. There's always going to need to be either a
human looking at the response and making a decision - that most of the listed
enhanced status codes include the phrase "see URL for further details" is a
tacit admission of that - or more sophisticated automation that depends on many
things other than the enhanced code.
What is the intended use by senders of these codes (assuming that some
significant subset of receivers were to implement them, and map their existing
responses on to them as accurately as they can)?
Cheers,
Steve