[Top] [All Lists]

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

2011-05-05 19:28:15

Jeff Macdonald wrote:

Hi Folks,

There is a slight update, where I added a code for greylisting. I've
also updated the contact information to reflect my current job.

Draft can be found here:


If you've implemented this draft, please let me know.


We started a major upgrade of our MTA and your previous I-D revs were already added part of the updated extended reply code text tables. I'll updated to rev2.

First some quick review typos found:

   X.8.4, typo "to"  change to "too"
   X.8.26, typo "INDENTIY"  change to "IDENTITY"

A few suggestions.

1 - Motivations for supporting this proposed standard.

With this rev2 update with greylisting info, you might want to add some motivations text to the introduction, for example after the 1st para:

   Extended reply codes, such as X.8.26, can help improve
   email communications under greylisted environments by
   using smarter reschedule retransmissions.

For example, our retry table has a retry rule specifically for Greylisting pushing up the few few retries, for example:

   if reply.attempts < 3 then
     if reply.code is 451 or
        reply.text has "4.7.1" or
        reply.text has "grey"

2 - What is IDENTITY?

When we added the X.8.YYY entries, the immediate "scratch head" which was what macros (for the SMTP session process entities) to use for the IDENTITY in certain of the entries. It was not hard to figure out, but it might help to add a terminology/definition section to describe what IDENTITY is or might be.

  2. Terminology and Definitions


  The IDENTITY can be any value reflected within the extended
  reply code reason and response.  It may be directly related
  to the value being monitored or evaluated for anti-spam
  purposes [in each stage of the SMTP state machine].  Generally,
  the value is the SMTP client IP address or domain input from
  the client, such as the return path provided in MAIL FROM: state.

  Each extended reply code in section 4.1 provide further explicit
  insights to the identity values are being considered.

Or whatever you think is better as a general definition:)

3 - Suggestion to add Summary table

I think a summary section with easy to read table (i.e. in "one" page view) would greatly help readers simply pursuing the doc. It will "sell" the proposal and increase consideration to implement. I would add it before the IANA Consideration section but also consider re-outlining the TOC and it as an introduction summary

   1.  Introduction
     1.1  Introducing the Anti-Spam Subject
     1.2  Summary of Enumerated Status Codes
   2.  Terminology and Definitions
   3.  Methodology of determining new detail codes
   4.  IANA Considerations
     4.1.  Enumerated Status Codes

1.2 Summary of Enumerated Status Codes

   The following table summarizes when extended codes are applicable for
reply codes with example response text associated with the extended code. Please review the terminology section 2.1 for IDENTITY and the section 4.1 IANA considerations to get detail information for each extended reply code.

             Table 1.0 - Anti-spam Extended Codes.

| Reply | Extended| | | Code | Code | Sample Response Text |

| any | X.8.0 | Undefined Policy detail | | any | X.8.1 | Message refused by local policy | | any | X.8.2 | Excessive volume | | any | X.8.3 | IP listed on RBL RBL-NAME | | any | X.8.4 | Too many invalid recipients | | any | X.8.5 | Unacceptable content | | any | X.8.6 | Suspected phishing attempt | | any | X.8.7 | IDENTITY is dynamically blocked due to complaints | | any | X.8.8 | IDENTITY is permanently blocked due to complaints | | any | X.8.9 | Recipient not accepting messages from IDENTIDY | | any | X.8.10 | IDENTITY is a dynamic IP | | any | X.8.11 | IDENTITY has been compromised | | any | X.8.12 | IDENTITY is an un-delegated IP | | any | X.8.13 | Reverse DNS lookup for IDENTITY failed | | any | X.8.14 | IDENTITY is temporarily blocked | | any | X.8.15 | IDENTITY is permanently blocked | | any | X.8.16 | IDENTITY is an open relay | | any | X.8.17 | Malformed content | | any | X.8.18 | Recipients have complained about included content | | any | X.8.19 | IDENTITY temporarily rate limited due to complaints.| | any | X.8.20 | IDENTITY temporarily rate limited | | any | X.8.21 | IDENTITY-A is a non-authorized sender for IDENTITY-B| | any | X.8.22 | Message contains a virus | | any | X.8.23 | IDENTITY has been permanently deferred | | any | X.8.24 | messages from IDENTITY not accepted | | any | X.8.25 | messages from local dynamic network not accepted | | 45z | X.8.26 | IDENTITY Greylisted, please retry later |


Why use 45z for X.8.26?

For x.8.26, I was going to suggest changing that to 451, but its probably better to use 45z with some informative notes for using either 450 or 451. But having an explicit 450 somewhat tells SMTP receivers to use 450 - period, and that may now what they wish to use.

The reason why is that there are already receivers using 451. Most, if not all, early greylisting adopters began using the "Official" GreyListing specs by the purported inventor:

This doc was often referenced in the support mailing list and its example for a response is:

   451 4.7.1 Please try again later

I did a quick search of today's SMTP outbound trace log for the word "grey" and found this unique grouping of responses:

  421 This server implements greylisting, please try again in # seconds
  450 4.2.0 <RCPT>: Recipient address rejected: Greylisted, see URL
  450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # minutes
  450 4.7.1 <RCPT>: Recipient address rejected: Policy Rejection-
                    Greylisted, please try later (see URL).
  450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # minutes
450 4.7.1 <RCPT>: Recipient address rejected: GREYLISTING, please retry later
  450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # seconds
  451 4.7.1 Greylisting in action, please come back in HH:MM:SS
  451 4.7.1 Greylisting in action, please come back later
  451 Greylisted for # seconds
  451 Greylisted, please try again in # seconds
  451 Greylisting enabled, try again in # minutes

So you can see there are many using the Harris document. But you see both 450 and 451 with the 4.7.1 which is probably reflective of people, including myself, wondering if 450 was better based on what RFC2821 had for example 45z text:

  450  Requested mail action not taken: mailbox unavailable
  451  Requested action aborted: error in processing
  451  Requested action aborted: local error in processing
  452  Requested action not taken: insufficient system storage

Just based on the text above, one can reasonable use 450 and 451. But even though 451 for greylisted session wasn't really due to an error in processing, I went with it as a default because extended codes are optional. I speculate that was what Harris was thinking too.

Hope this helps.


Hector Santos