[Top] [All Lists]

Re: slight update to draft-macdonald-antispam-registry

2011-05-11 12:34:41

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 -

<Prev in Thread] Current Thread [Next in Thread>