--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.