Consider the following situation:
1. Some users at our site are subscribed to external
Mailman-managed mailing lists that perform automatic bounce
2. Because the list owners are either unwilling are unable to
protect the lists from spam, the lists receive a fair amount
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 subject sub-code of the extended status code classifies the status
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
IMHO, this is an error. I propose modifying Bouncers/DSN.py as
1. Mailman tries to extract the status field from
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