ietf-smtp
[Top] [All Lists]

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

2011-05-19 11:08:07

On Wed, May 11, 2011 at 7:43 AM, Keith Moore 
<moore(_at_)network-heretics(_dot_)com> 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.)

Thanks Keith for clarification. The RFC calls facet "Subject".

and is section 2 it does say "The second sub-code indicates the
probable source of any delivery anomalies...."

but, well, read on.


When mail is blocked because of information from a party that is not actually 
involved in transmission (e.g. a blackhole list), it makes sense to have a 
separate 2nd facet code for this, because (in some sense) it's the blackhole 
list that has to fix the problem before similar messages can be delivered in 
the future.   But the list below mixes several different sources in the same 
facet code.


When I first read this, I thought you were saying there really should
be only 3 Subject codes, but looking at RFC 3463, that can't be what
you meant.  I see more than one subject can cover a who. But mixing
several sources into one Subject is currently done in RFC 3463. From
the bottom 2 (I've changed some letters that are present in the RFC to
avoid anti-spam systems from triggering):

x.0.z - Other or Undefined Status
 could be sender or receiver

x.1.z - Addressing Status
 states "_generally_ can be corrected by sender..."
 so who is "sender"

x.2.z - Mailbox Status
 "... _assumed_ to be under the control of the recipient"
 so who is "receiver"

x.3.z - Mail System Status
 "... _assumed_ to be under the general control of the destination ..."
 so who is "receiver"

x.4.z - Network and Routing Status
 "... _assumed_ to be under the control of the destination or
intermediate system ..."
 so who is "receiver" (but could be sender too)

x.5.z - Mail Delivery Protocol Status
 "... the full range of problems ..."
 so who could be either "sender or receiver"

x.6.z - Message Content or Media Status
 " ... media issues are under the control of both the sender and the
receiver ... "
 so who is "sender or receiver"

x.7.z - Security or Policy Status
 "Security policy status issues are assumed to under control of either
or both the sender and recipient"
 so who is "sender or receiver"

So it seems the intent and implementation have actually drifted since
Keith came up with the codes. I suppose x.8.z could be used for when
who is "sender" and x.9.z could be used for when who is "receiver" and
x.10.z for "3rd party". But the word "Subject" or even "who" really
seems to be "what".

-- 
Jeff Macdonald
Ayer, MA

<Prev in Thread] Current Thread [Next in Thread>