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?
WHO?
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.
--
Sincerely
Hector Santos
http://www.santronics.com