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

Fri Sep 29 05:29:14 CEST 2006

Patches item #534298, was opened at 2002-03-25 00:18
Message generated for change (Comment added) made by mbp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: list administration
Group: Mailman 2.0.x
Status: Closed
Resolution: Out of Date
Priority: 1
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.  &quot;Positive action&quot; 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: 2006-09-29 13:29

Message:
Logged In: YES 
user_id=521

> Does this make you responsible for this behaviour? 

Since my patch was closed/out-of-date, presumably not.  At
any rate the behaviour is optional.

> (consider the case where the admin addres is bouncing)

Are you suggesting it will loop?  I'm not sure whether admin
messages are subject to normal bounce processing, but I
think not.  Anyhow, it will make it obvious that you need to
fix the admin address. :)

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

Comment By: Bron Gondwana (brong)
Date: 2006-09-29 11:15

Message:
Logged In: YES 
user_id=9941

Does this make you responsible for this behaviour?  Next 
time you're down in Melbourne remind me to buy you a beer 
and tip it over you.

(consider the case where the admin addres is bouncing)

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

Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:48

Message:
Logged In: YES 
user_id=34209

As mentioned in email, I'll re-check the other
bounce-detection patches, but the ones I checked didn't
apply to 2.1 for other reasons as well (like their original
module being completely rewritten.)

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

Comment By: Martin Pool (mbp)
Date: 2003-03-12 11:43

Message:
Logged In: YES 
user_id=521

&gt; Yeah, Mailman 2.1's bounce detection and handling was
&gt; largely rewritten. It also uses VERP now, so it should solve
&gt; most of your bounce problems, if not all.

Yes, we're using VERP now and it's beautiful.  In particular
we have a
lot of Exchange subscribers, and their bounce messages are
nearly
unintelligible.

&gt; I'm going to close this patch, as well as your other pending
&gt; bounce-detection patches, but if you see any new unhandled
bounces
&gt; (or find that previously-reported ones still fail to
detect) please
&gt; do open a new bug- or patch-report.

I am OK about closing this one, but please reopen the
others.  Since
Mailman still has the option of using a bounce parser rather
than VERP
it seems to make sense to have the parser be as smart as
possible.
Some people might not want to use VERP.  Unless the patches
no longer
merge, I would encourage you to put them in.

&gt; (Preferably with an example message for us to test on.)

I will do that in future.  I think that was not mentioned
when I sent
them, though I do think the patches have partial examples in
their
comments.

&gt; I promise we wont let it rest as long as this one has. :-)

Thanks.  I know it can be hard to get around to these things.

--
Martin

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

Comment By: Thomas Wouters (twouters)
Date: 2003-03-12 11:19

Message:
Logged In: YES 
user_id=34209

Yeah, Mailman 2.1's bounce detection and handling was
largely rewritten. It also uses VERP now, so it should solve
most of your bounce problems, if not all. I'm going to close
this patch, as well as your other pending bounce-detection
patches, but if you see any new unhandled bounces (or find
that previously-reported ones still fail to detect) please
do open a new bug- or patch-report. (Preferably with an
example message for us to test on.) I promise we wont let it
rest as long as this one has. :-)

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

Comment By: Martin Pool (mbp)
Date: 2003-03-11 12:16

Message:
Logged In: YES 
user_id=521

This seems to be already fixed in 2.1.

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

Comment By: Martin Pool (mbp)
Date: 2002-04-03 12: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-25 12: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 &quot;digester lucked out&quot; be considered
successful processing.

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

Comment By: Tim Potter (tpot)
Date: 2002-03-25 10: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