[Mailman-Developers] [ mailman-Patches-534298 ] forward unhandled bounces to admin

[noreply@sourceforge.net]

Patches item #534298, was opened at 2002-03-24 08:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_id=103

Category: list administration
>Group: Mailman 2.0.x
Status: Open
Resolution: None
Priority: 7
Submitted By: Martin Pool (mbp)
Assigned to: Nobody/Anonymous (nobody)
Summary: forward unhandled bounces to admin

Initial Comment:
samba.org handles a lot of mail messages, and therefore
suffers a lot of bounced messages.  Mailman's automatic
bounce handling is great, but the problem is that
people keep dreaming up new and wierd bounce messages. 

With Mailman 2.0.8, if I turn on automatic bounce
handling then some bouncing addresses are not correctly
detected and therefore keep generating large amounts of
traffic indefinitely.  If I turn it off, we get about
3000 bounces per day. 

Some of these are just not handled yet by the
BouncerAPI and need patches.  In some cases there is in
fact no deterministic way to work out the bouncing
address (at least until we have VERP), and human
intervention is required.  For example, Novell's
brilliant mail software includes no information in the
Received lines or bounce message to indicate what the
bouncing address is!

Anyhow, this patch changes the behaviour of the bounce
handler so that bounce messages which do not cause any
positive action are forwarded to the list
administrator.  "Positive action" can mean noticing
that the address is already disabled, or marking it as
bouncing, or similar things.  It doesn't include
addresses which don't seem to be on the list, which
probably means that we have not interpreted the message
properly and more help is required.  

So in summary bounces which can be automatically
handled will be, and others will go to the admin.

I'm not sure this is the perfect behaviour, but it
certainly seems like an improvement.  Perhaps you want
to make it more configurable.  Please merge this, or
something like it.

----------------------------------------------------------------------

Comment By: Martin Pool (mbp)
Date: 2002-04-02 21:18

Message:
Logged In: YES 
user_id=521

Tim, that's not quite so much of a problem as you might
think.  When excessive bounces are detected Mailman only
*disables* addresses rather than removing them.  With or
without this patch, bouncing addresses which are already
disabled are noted in the log file and not further action is
taken.

Problems can occur if the address is actually removed.  This
can arise in two ways.

One way is that the mail administrator might explicitly
remove the user from the list because of manual bounce
processing.  In that case, any later bounces will also go
through to the admin.  That's the reason for my patch to add
--disable to remove_members.

Secondly, users might unsubscribe themselves and then have
their address start bouncing.

You can imagine Mailman remembering previously-subscribed
members so that it could handle these cases, but that's a
much bigger project, and probably best done in conjunction
with VERP.

----------------------------------------------------------------------

Comment By: Martin Pool (mbp)
Date: 2002-03-24 20:03

Message:
Logged In: YES 
user_id=521

This patch modifies the behaviour when handling bounce
messages with multiple addresses, such as from Postfix.  Now
messages in which any of the bouncing addresses cannot be
automatically handled are forwarded to the administrator.

Eventually it might be nice to put a notice in the message
explaining the problem -- e.g. user not found, is not a
member, etc.

This update also makes "digester lucked out" be considered
successful processing.

----------------------------------------------------------------------

Comment By: Tim Potter (tpot)
Date: 2002-03-24 18:18

Message:
Logged In: YES 
user_id=9949

The scenario where addresses which don't seem to be on the
list can be caused by bounces received after the user has
been disabled due to the size of the mail queue.  It may
cause confusion forwarding them to the admin as there is
nothing they can do about it except puzzle over why it was
received.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_id=103