[Top] [All Lists]

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

2011-05-12 11:21:32

Keith Moore wrote:

All I'm asking for in the context of the current discussion is for enhanced status codes to distinguish "rejected because of a blacklist or reputation service" codes, from codes that indicate a failure in the signal path.

That sounds more like an SPF issue, not RBL. no?

it applies to both, though the codes for the two should be distinct (as is proposed).

X.8.3 seems to cover RBL - "IP listed on RBL RBL-NAME"
X.8.12 seems to fit SPF - IDENTITY is an un-delegated IP

the issue is that the 2nd facet value of '8' is being used both for conditions determined locally and conditions determined by a 3rd party.

I had an earlier draft post (than the final one you had first responded to) that suggested a technical reason why this I-D should use subject classifications per RFC3463 due to this I-D having a limit of 100 details. But I didn't want to suggest a drastic change

Per RFC3463, what we are calling the 2nd facet formally is the subject:

      status-code = class "." subject "." detail

      class = "2"/"4"/"5"
      subject = 1*3digit
      detail = 1*3digit

With the current classifications for subject:

      X.0.XXX Other or Undefined Status
      X.1.XXX Addressing Status
      X.2.XXX Mailbox Status
      X.3.XXX Mail System Status
      X.4.XXX Network and Routing Status
      X.5.XXX Mail Delivery Protocol Status
      X.6.XXX Message Content or Media Status
      X.7.XXX Security or Policy Status

So technically, this I-D could of used existing subjects allowing for more than 100 "Anti-Spam" related reasons (in total).

The I-D is suppose to update RFC3463 with a new specific subject:

      X.8.XXX Anti-Spam policy related

But this suggest a world of AVS issues is limited to 100 reasons. So far, the I-D suggest there are 26.

RFC3463 goes into example status details for each of the status subjects and many of the I-D anti-spam codes fits there too. So yes, I think that many of the proposed status codes can easily fit within existing RFC3463 subjects, if not all or most.

Also, you can see this "conflict" with rev1 of the I-D having a new X.8.26 specifically for Greylisting and the current Harris recommendation and non-IETF BCP is 4.7.1 which fits the RFC3463 X.7.XXX security or policy status subject.

So one has to ask what are the motivations for the I-D X.8.XXX status subject?

Here is what I think:

  1.0 - Consolidation:

     1.1 - Definition, registration, limited to 100
     1.2 - Easier to Trace/Search, i.e. logs, grep "4.8.26"

  2.0 - Automation:

     2.1 - Reporting  (helping/blaming someone, i.e. DSN)
     2.2 - Local Notification (security, signaling local network)

The I-D is trying to formally do 1.1, which is fine, with the intent to help with 2.1.

But you have two issues:

  Most of the (sensitive) reporting is for the wrong people, and
  most likely won't reach them (false bounce), and

  Jeff's ultimate question which started this thread:

        Why aren't people using it?

My view is its more than just IETF registration of a new special subject with 26 details limited to 100. Today, it needs to provide how the special subject helps the current process beyond just reporting because it could be mostly false targeted reporting. I like the Alert Status idea because this special subject would have a higher local network interest. I don't think it will help to have something like:

    X.8.11 <IDENTITY> has been compromised
    Pass the Buck: USER?
                   LOCAL HOST?

If you look at the description:

    It has been determined by the receiver (or a 3rd
    party the receiver is using) that the IDENTITY
    (an IP address or Domain) has been compromised.
    This is usually and indication that the machine
    hosting the IP is infected with a virus or is
    part of a Zombie network.  Administrators MAY
    include a URL for further details by appending
    the text with ": see <URL> for further details."

It seem to missed out that the IDENTITY could be the AUTH user.


Hector Santos