[Mailman-Developers] Re: Bounce removal parameters default values

Barry Warsaw barry at python.org
Fri Sep 26 11:47:19 EDT 2003

On Wed, 2003-09-24 at 11:57, Greg Stark wrote:

> I should not be removed from a mailing list purely on the basis of bounces of
> uncontrolled messages. The messages that bounced could have been spam or
> outlook worms or whatever.

In the default configuration, you won't be.  You might get /disabled/
but you won't get removed, unless your MTA also bounces the 3 notices
that Mailman sends out at regular intervals to warn disabled users of
their subscription status.

> Before removing a subscriber mailman should send a message with known content
> testing the address. Only if such a message bounces should a user be dropped.

That's what it does.  The default is to send 3 notices over the course
of 3 weeks.  Each of those notices contains a url you need to click on
to re-instate your subscription.  We can't test for a negative (i.e.
that the notices don't bounce) so you need to take explicit action to
get re-enabled.

> As it is I'm being removed from mailing lists whenever a new Outlook worm
> appears and sends multiple messages in a row. Or a new spammer discovers a
> list I'm on and sends multiple messages in a row to the list.
> It's especially bad on low-volume lists where it's quite possible for spam or
> Outlook worm messages to be the only messages for days.

Admins of low volume lists might want to change some of the bounce
processing defaults.  However, by default if a list gets no bounces from
you in 7 days, it considers any previous bounce info to be stale and
throws it away.  So the list would need to get one bounce per day from
you for 5 days in a row for you to get disabled.

The other option I would suggest is that list owners start turning on
personalization, in order to take advantage of VERP.  I think it's
harder to get spoof-disabled when VERP is enabled because then Mailman
looks for the bouncing address in the encoded recipient header.

But I'm open to specific suggestions for improvement.

More information about the Mailman-Developers mailing list