[Top] [All Lists]

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

2011-05-11 14:57:39
On May 11, 2011, at 2:44 PM, Steve Atkins wrote:

On May 11, 2011, at 11:11 AM, Keith Moore wrote:

On May 11, 2011, at 11:34 AM, 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.

one of the major reasons for enhanced status codes was to provide a 
language-independent indication of the error.    I certainly don't mind URLs 
being used to supply more information (especially if done in multiple 
languages) but I don't think it obviates the need for the enhanced status 

I don't think it meets that goal, as it doesn't provide enough information to 
do anything useful in response to those broad categories. Pretty much all of 
the suggested categories break down into two groups:

 1. Something went wrong. Keep trying.
 2. Something went wrong. Read the error message.

The defined meaning of the enhanced status code should be a close approximation 
to the error message. 

t's only worthwhile for an SMTP receiver to send these codes or for an SMTP 
sender to parse them if they can be used to adjust the behaviour of the 
sender in a mutually beneficial way.

The codes as defined are broad categories that are informational (as opposed 
to imperative, e.g. "Please don't send email to this address again", "Please 
don't send any further email to this address / domain until a human has 
intervened", "Please reduce the rate at which you are sending email to this 
MX") so they don't seem to communicate much to the senders automation in 
terms of "what behaviour you should change in response to this message".

They're not so much meant for "automation" - except perhaps for mailing lists - 
as for human consumption.

Admittedly, the codes weren't designed for a world where the sender has to 
argue with some blackhole list about whether his message should get through.  
But even in the world where RFCs 1981-1894 were written, about half of all 
bounced messages were due to errors downstream of the sender - mostly DNS 
errors, MTA configuration errors, and a few recipient disk quota/space issues.  
 In general, the sender couldn't fix most of those problems directly, but it 
was still helpful to the sender to know where the problem was.

Today, there's still a very useful difference between telling the sender: 
"your message didn't get delivered because the recipient address was not that 
of a valid recipient",  or
"your message didn't get delivered because it was too large", or
"your message didn't get delivered because we think it's spam based on the 
content", or 
"your message didn't get delivered because blackhole list FOO accused your IP 
of generating spam", or
"your message didn't get delivered because your domain's DNS says that your IP 
is not authorized to send mail"

A sysadmin who ignores the human readable message (whether due to language 
issues, poor logging or what have you) and relies solely on the extended 
response code is going to be in just the same situation as automated code - 
they're not going to have enough information to make a decision about what 
they should do in response without reading the human readable part of the 

That might be true today, because today people are refusing delivery for a lot 
more reasons than anticipated at the time RFCs 1891-4 were written.  So 
extending the list of codes seems appropriate.

That's why I'm wondering what the intended use of these codes by the email 
senders is.


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