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

James Ralston qralston+ml.mailman-developers at andrew.cmu.edu
Fri Jul 28 23:36:31 CEST 2006


Consider the following situation:

    1.  Some users at our site are subscribed to external
        Mailman-managed mailing lists that perform automatic bounce
        processing.

    2.  Because the list owners are either unwilling are unable to
        protect the lists from spam, the lists receive a fair amount
        of spam.

    3.  Our MX servers are configured to reject outright incoming
        messages that are obviously spam.

Most of you can see the impending train wreck already, but for
completeness' sake, here's the problem:

    1.  Mailman distributes obvious spam to the list.

    2.  We detect the spam and reject it during the SMTP dialog with a
        550 reply code (5.7.0 extended status code).

    3.  Mailman receives a DSN message because we bounced the message.

    4.  Mailman assumes that the bounce is due to the recipient's
        address being invalid, and disables the subscription.

    5.  Much wailing and gnashing of teeth ensues.

>From looking at Bouncers/DSN.py, although Mailman takes the time to
pick apart each message/delivery-status subpart and extract the
"action" field, it blissfully ignores the "status" field, which must
be present and must contain the extended status code which generated
the DSN.

The subject sub-code of the extended status code classifies the status
as follows:

    X.0.XXX Other or Undefined Status
    X.1.XXX Addressing Status
    X.2.XXX Mailbox Status
    X.3.XXX Mail System Status
    X.4.XXX Network and Routing Status
    X.5.XXX Mail Delivery Protocol Status
    X.6.XXX Message Content or Media Status
    X.7.XXX Security or Policy Status

Of these, some subject sub-codes (e.g.: X.2.XXX) pertain directly to
the validity of the destination address.  But some do *not* pertain to
the destination address: for example, X.6.XXX clearly means that the
*content* of the message (not the source or destination address)
caused the DSN.

Regardless, Mailman ignores all of the status field information: if
the action is "failed", Mailman counts it as a bounce, and that's
that.

IMHO, this is an error.  I propose modifying Bouncers/DSN.py as
follows:

    1.  Mailman tries to extract the status field from
        message/delivery-status subpart.

    2.  If Mailman cannot extract the status field, it operates solely
        on the action field.

    2.  If Mailman can extract the status field, and the subject
        sub-code is X.6.XXX or X.7.XXX, Mailman assumes that the DSN
        was generated by the fluke content of a specific message, and
        ignores the DSN.

I admit that this algorithm isn't perfect.  But I think it's better
than what Mailman does currently, which is to ignore the status field
entirely.

Thoughts?  Arguments?

James



More information about the Mailman-Developers mailing list