Let me respond to each of your comments:
- We are a University campus group and the University currently provides a Mailman service to us. During our bi-annual university Club Fair, we can
collect 200 email addresses--on paper--from prospective students/staff wanting on our list. Many are Asian students, and their English handwriting is poor at best, but we even have trouble reading American email addresses. We guess on the bad handwriting and 10% (20 of them) bounce. We can correct those write away and get most of them working on the second try (or do an LDAP lookup on the problem ones).
Using a paper sign-up list for our booth at the Club Fair is _not_ ideal, but it's all we have available in this theater. It's nice you don't have too use a paper sign-up list like we do.
I appreciate your suggestion to set bounce_processing=1, bounce_score_threshold=0, but wouldn't this would cause "existing addresses" with scores at "2" to be removed immediately, which we don't want to do. We want the existing addresses to remain until their bounce score reaches 2.5.
Or are you saying the existing scores will be unaffected by temporarily setting bounce_processing=1,threshold=0 for just the Mass Subscribe operation? If so, maybe you're on to something. But wouldn't it be prudent to make this the default behavior for all Mass Subscribes/Invites? Isn't it better to correct typos and such right away 100% of the time?
- I agree with your comments. But I currently run a 1500 subscriber announcement-only Majordomo list for a monthly newsletter with very good success processing my own bounces manually. I get about 8 to 10 "hard" bounces per newsletter, which I can handle. Yes, the soft bounces (over quota) are annoying.
But for a discussion list (not announcement-only) with messages everyday, you would be crazy not to run automatic bounce processing. I totally agree there.
The big advantage with manual bounce processing (small, monthly, announcement-only list) is you can just fix the bouncing problems yourself if you know everyone on the list. That would be the _only_ reason to disable bounce processing, that is, for manual bounce processing.
Thanks for listening and your suggestion for #1. I'll try that, but I still maintain that for any Mass Operation, you should be informed immediately of the typos--no special temporary settings required. Happy computing to you, Mark
*********** REPLY SEPARATOR ***********
On 12/27/2010 at 10:11 PM Stephen J. Turnbull wrote:
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.)