--On 8 August 2006 05:10:41 -0500 Brad Knowles <brad@stop.mail-abuse.org> wrote:
When it comes to parsing the actual reasons behind a message bouncing, the RFC is not sufficient. Indeed, I'm not convinced that it's even necessary. And you'd have to be specific which RFC you're talking about, because some of them are mutually incompatible
The original proposal referred to error codes defined in rfc1893. The parsing of such error codes is relatively trivial.
<http://www.ietf.org/rfc/rfc1893.txt>
Which RFCs are incompatible?
Here's a more specific proposal:
If there is no rfc1893 error code, then treat the message as a recipient bounce (count it against the recipient address).
If there is an rfc 1893 code, and the first digit is '2' or '4' then do nothing.
If there is an rfc 1893 code and the first digit is '5', then do nothing, except as noted below, where count+ means count against the recipient, count- means count in favour, admin means optionally notify the administrator (who may wish to notify the remote admin, or may even happen to be be the remote admin).
X.1.0 Other address status X.1.1 Bad destination mailbox address count+ X.1.2 Bad destination system address count+ X.1.3 Bad destination mailbox address syntax count+ X.1.4 Destination mailbox address ambiguous count+ X.1.5 Destination mailbox address valid count- X.1.6 Mailbox has moved count+ X.1.7 Bad sender's mailbox address syntax X.1.8 Bad sender's system address X.2.0 Other or undefined mailbox status X.2.1 Mailbox disabled, not accepting messages count+ X.2.2 Mailbox full X.2.3 Message length exceeds administrative limit. X.2.4 Mailing list expansion problem admin X.3.0 Other or undefined mail system status X.3.1 Mail system full admin X.3.2 System not accepting network messages X.3.3 System not capable of selected features X.3.4 Message too big for system X.4.0 Other or undefined network or routing status X.4.1 No answer from host X.4.2 Bad connection X.4.3 Routing server failure X.4.4 Unable to route X.4.5 Network congestion X.4.6 Routing loop detected X.4.7 Delivery time expired X.5.0 Other or undefined protocol status X.5.1 Invalid command X.5.2 Syntax error X.5.3 Too many recipients X.5.4 Invalid command arguments X.5.5 Wrong protocol version X.6.0 Other or undefined media error X.6.1 Media not supported X.6.2 Conversion required and prohibited X.6.3 Conversion required but not supported X.6.4 Conversion with loss performed X.6.5 Conversion failed
Actually, for the moment, I'd be happy if everything except count+ were ignored (but logged). In future, it may be possible to implement other desirable behaviours for other error codes. In particular, the local sysadmin may want to know about many of these things when the recipient is local.
-- Ian Eiloart IT Services, University of Sussex