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. "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: 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 > 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. 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. > 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. 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. > (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. > 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 "digester lucked out" 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