[Top] [All Lists]

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

2011-05-19 11:38:28

On Wed, May 11, 2011 at 2:44 PM, Steve Atkins <steve(_at_)blighty(_dot_)com> 

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

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.

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".

I'm very puzzled. 1) and 2) above is just distilling messages into 5xx
and 4xx. It applies to RFC 3463 as well. But the codes I'm proposing
do communicate what needs to be changed. x.8.2 say "excessive volume".
It addresses the "reduce the rate at which you are sending email".

Is your comment directed at RFC 3463 in general? For instance, x.3.4
Message too big for system, implies that the sender can't send a
message that big. I don't think it needs to say "please reduce message
size for acceptance".

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's why I'm wondering what the intended use of these codes by the email 
senders is.

If by senders you mean "Marketers", I would hope better list
management. But for everyone else, less phone calls to the receiver.

Jeff Macdonald
Ayer, MA

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