For something labeled under "Anti-Spam" related, I like the idea of
building a consensus for something along the lines of a "Alert Status"
(i.e. LOW, MED, HIGH) that provides the BCP for these X.8.YYY codes:
Code: 5.8.11
Sample Text: IDENTITY has been compromised
Associated Basic Status Code: 550
Alert Status: HIGH, Local Operator should be notified
I mean, what will most receivers do when the receivers detect and
determine the need to issues these X.8.YYY codes? There was a reason
for it and many of these are pretty serious where a) you don't want to
encourage a retry, thus 55x 5.8.YYY is issued and b) the local
operator may needs to notified rather than just log it.
--
Sincerely
Hector Santos
http://www.santronics.com
Laura Atkins wrote:
On May 11, 2011, at 7:01 AM, Murray S. Kucherawy 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.)
I haven't implemented this, but I have to say I really like this approach.
Perhaps the proposal would benefit from making such distinctions in the new
codes it's registering.
If you're going to make the second facet of the status code be who probably needs to fix the problem, you could also make the third facet point to where they need to go to fix it.
It doesn't even need to be that detailed. 1 for this is internal (so you need to contact the recipient domain) and 2 for this is external (so you need to contact a third party). Then follow that with a URL pointing to the third party or the postmaster / internal troubleshooting pages.
laura