[Top] [All Lists]

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

2011-05-19 15:02:51
On 5/19/11 5:44 PM, Jeff Macdonald wrote:
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.)

From the SMTP transaction point of view there are only two parties involved:

  1. the SMTP client and
  2. the SMTP server

So if the intention is to enable systems/people to determine who needs to take action to fix something, we only need two 'subject' codes: it's either the client that has to fix something, or the server. The server can delegate part of its policy determination process to other systems that provide input to it, but on the receiver side the SMTP server remains primary responsible entity for the transaction. If the SMTP server encounters problems in e.g. DNS blacklist lookups, or PTR lookups etc. it can use the 'detail' part of the enhanced status code (3rd facet) to indicate what the problem was (room for 1,000 different codes). Providing information about a 3rd party in the 'subject' part of the ESC creates complexity: there is virtually no end to the number of parties that can be involved in a single transaction; apart from a 3rd party there can be a 4th party and possibly even a 5th party and so on. To give two examples:

   * A user at company A (1st party) is sending mail to a user at
     company B (2nd party). Company B is using a hosted AS/AV service,
     like MessageLabs (3rd party) for sending and receiving mail.
     MessageLabs in turn, enables the customer to use one or more
     public DNS blacklists (4th party) within it's Dashboard function.
     Is it important for the MTA of Company A to 'know' about the way
     the infrastructure of company B is designed and should Mlabs
     reflect part of this in the ESC it returns?

   * Company A sends a newsletter mailing on behalf of Company B using
     a Company B sender address. A receiving system at Company C,
     performs a Call Back Verificiation (CBV) to the mail server of
     Company B. Company B in turn is using a DNS Blacklist and finds
     that the IP address of Company B is listed. What ESC code should
     Company C use in its communication with Company B during the SMTP

There is a myriad of possible topologies and interactions here. Let's keep it simple: if (repeat: IF) the intent of ESCs is to make clear who should take action, use two different subjects, X if the client needs to take action and Y if the problem is on the server side. The 'Detail' in the ESC can then be used to distinguish between different types of problems.

As Jeff already mentioned, history has learned us:

So it seems the intent and implementation have actually drifted since
Keith came up with the codes.

As RFC3463 is widely used it seems to me it's too late to use ESCs to indicate which side of the SMTP connection needs to take action.

Why not simply use the x.7.y policy related codes and use the 'y' detail to differentiate between the various situations? If we want, we can reserve a range within 'y' for spam related reasons, like (2|4|5).7.[100-199]. But IMO _documenting_ the various codes in an RFC is more important than the actual codes we will use for this purpose.

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