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.)
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
