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
session?
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.
/rolf