[Mailman-Developers] suggested improvement for Mailman's bounce processing

Ian Eiloart iane at sussex.ac.uk
Tue Aug 8 12:46:34 CEST 2006

--On 8 August 2006 05:10:41 -0500 Brad Knowles <brad at stop.mail-abuse.org> 

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


Which RFCs are incompatible?

Here's a more specific proposal:

1. If there is no rfc1893 error code, then treat the message as a recipient 
bounce (count it against the recipient address).

2. If there is an rfc 1893 code, and the first digit is '2' or '4' then do 

3. 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
       X.1.2     Bad destination system address
       X.1.3     Bad destination mailbox address syntax
       X.1.4     Destination mailbox address ambiguous
       X.1.5     Destination mailbox address valid
       X.1.6     Mailbox has moved
       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
       X.2.2     Mailbox full
       X.2.3     Message length exceeds administrative limit.
       X.2.4     Mailing list expansion problem

       X.3.0     Other or undefined mail system status
       X.3.1     Mail system full
       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 

Ian Eiloart
IT Services, University of Sussex

More information about the Mailman-Developers mailing list