Superticker2 (Mark) writes:
I'm not a subscriber to this list, so please include me superticker2{at}iastate.edu on your cc: line.
I have two suggestions I would like to make concerning Mailman bounce processing:
- All bounces from either a Mass Subscribe or Mass Invite operation should be unconditionally and immediately sent to the list owner.
-1
You seem to be confusing your personal (including job-related) idiosyncracies with universal requirements. Mailman is used by many different people with many different needs. For example, in my use case, I don't want to see such bounces; I never hand-type addresses, but rather use cut and paste from mails sent to me personally or one of my administrative aliases (incorrectly; my target users are sophisticated users, and are expected to handle subscriptions themselves). If that bounces, there is *nothing* I can do to correct it (as it turns out, in over ten years of this practice AFAIK I have never made a mistake in the process of copy/paste; doesn't mean it won't happen tomorrow but I'm not going to worry about it!), and ordinary bounce processing works fine for cleaning the list. (It takes about a month for an address to be removed, but during that period it is disabled and uses negligible resources.)
It is possible to set up bounce processing so that your requirements are met (bounce_processing = 1, bounce_score_threshold = 0.0, bounce_you_are_disabled_warnings = 0, bounce_notify_owner_on_removal = 1 -- granted, the user is removed from the list ;-).
AFAIK those conditions apply to bounces from admin-originated mail as well as ordinary list traffic. If not, I agree that it should be made possible, and probably there should be an option to have different options applied to bounces caused by admin-originated mail, although if it's that important that admin-originated mail be checked, you probably want to know immediately if a subscriber goes AWOL, too.
- All bounces should be immediately directed to the list owner if bounce processing is switched off.
-1
Bounce processing is on by default. If an owner switches it off, presumably they know what they're doing.
For small lists, it makes the most sense for the list owner to handle bounces manually.
Not if the list address is visible from the "InterSewer". Eventually either the -bounce address will be used as a Sender by a spammer or it will end up on the spammer's To list. Enough of these will get through to make the list owner's task not merely a chore, but a disgusting chore.
Not to mention that a large fraction of bounces are actually due to transient causes (host goes offline on a holiday weekend, for example). And in many use cases the most common cause of bounces is "undeliverable; over-quota".
Doesn't bounce_processing = 1, bounce_unrecognized_goes_to_list_owner = 1 do exactly what you want? If it doesn't, it should be fixed to do so. Hm ... see below.
As it stand today, there could be 100s of bad addresses on an email list without anyone's knowledge if bounce processing is off; this is bad design.
Looks like an oversight to me. The people I know just don't run without automatic bounce processing in this day and age if they want to do useful work besides manually processing bounces, so nobody has noticed the bug. At l.224 of Mailman/Queue/BounceRunner.py, this change should allow you to configure things so that you get all the bounces you want (and if the addresses of your lists are visible from the InterNet, quite a few you don't want):
# List isn't doing bounce processing?
if not mlist.bounce_processing:maybe_forward(mlist, msg) return
(This is Mailman 2.10, my host is a bit behind the times, so the line number may be a bit off.)