[Top] [All Lists]

some changes for draft-macdonald-antispam-registry

2010-03-30 22:57:52

Off-list, the following suggestion was made:

- it is perhaps a matter of style, but the Introduction shouldn't contain the 
whole work; suggest splitting it into an Introduction that describes the goal 
of the work, and a Discussion that then spells it out

To this point, I have the following changes so far:

1.  Introduction

   This RFC defines a set of Enhanced Status Codes [RFC3463] [RFC1893]
   for SMTP related to anti-spam policy.  These codes are to be
   registered with the IANA Mail Enhanced Status Codes registry as
   defined in [RFC5248].  Anti-Spam policy is inherently a local

   This document is being discussed on the SMTP mailing list,
   ietf-smtp(_at_)imc(_dot_)org [1].

2. Introducing the Anti-Spam Subject

   The most common extended SMTP code assigned to anti-spam policy is
   5.7.1.  This is because the subject code of 7 is meant for security
   or policy.  For anti-spam policy, the only logical detail code is 1,
   "Delivery not authorized, message refused".  Using 5.7.1 for many
   different anti-spam policies weakens the usefulness of extended SMTP
   error codes.  One of the motivations behind [RFC3463] was to
   re-distribute the classifications of SMTP error codes in order to
   provide a richer set of errors, and provide a means for
   machine-readable, human language independent status codes.  Thus a
   new subject code of 8 is introduced for anti-spam policy.

3. Methodology of determining new detail codes

   All of the new detail text was gathered by surveying several existing
   large ISPs to see what messages were produce when presented with
   messages that violate their policies.  An attempt was then made to
   coalesce the messages together into common themes.  These themes
   where then simply assigned a detail number.

   While this document provides suggested text for each detail code,
   alternate text can be provided if the text is in the spirit of the
   suggested text.  This will allow sites to simply prepend the proper
   extended SMTP code to their existing text.  Sites that are starting
   to implement anti-spam policy SHOULD use the text provided in this

   While this document strives to document common anti-spam policies, it
   is by nature incomplete.  [RFC3463] notes that new subject and detail
   codes will be added over time.  This document is no exception to that
   and can be extended at future dates.

I'd appreciate any comments. I have many other comments to incorporate
still, just wanted to keep a pulse on the document.

Jeff Macdonald
Ayer, MA

<Prev in Thread] Current Thread [Next in Thread>
  • some changes for draft-macdonald-antispam-registry, Jeff Macdonald <=