First, disclaimer...I have not read the draft, but please read on.
On May 11, 2011 at 08:34 -0700, Steve Atkins wrote:
=>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)?
Somewhat agree. My feeling is that humans read the status code text as
you say, but log parsers/report generators and/or queue watchers are
looking at the status codes. None of those can "fix" the problem(s),
but they bring the problem to the attention of sites running them.
Both as a sender and receiver. (Note how this ties into Hector's...only
good guys care/report, never bad guys. :)
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************