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

[Steve Atkins <steve@xxxxxxxxxxx>]

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

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

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

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

Cheers,
  Steve