[Mailman-Developers] Suggestions about Mailman bounce processing

[Superticker2 (Mark)]

Let me respond to each of your comments:

1) 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?

2) 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:
> > 
> > 1) 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.
>
> > 2) 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.)