[aprssig] Mailman considered harmful - list bounce settings are bad

[Matti Aarnio]

On Tue, Jul 07, 2009 at 06:35:23AM -0500, Jason KG4WSV wrote:
> 
> I'm glad you've got the resources to manage a lot of email list
> traffic by hand.  Most of us don't have that luxury.  In the absence
> of infinite time and money, I've found mailman to do a good job of
> managing my own list traffic, and I certainly don't have any
> complaints for the folks who manage the TAPR lists.
> 
> Excessive bounces can put a strain on a server trying to deliver
> messages to an address that is bouncing.  A valid message is delivered
> in seconds; a bounce can sit around trying for days.

Then that system is just using MTA that has no decent understanding
of queues.   vger.kernel.org  is deliverying several million emails 
per day, most with individual VERP addresses, and it has still idle
processors and IO available.   It is doing that very smartly, and we
sysadmins chose this completely strange way because a) it existed back
in 1990es when we started, and b) all "modern" things are just worse.

We coalesc arriving errors (bounces, whatnot), and if address X is
bouncing everything, then we say "right, fine, lets drop that", but
if it is bouncing just 3 spams (that did leak in on our OPEN lists),
then we ignore those bounces.

Our big receivers, like google, do know our list policy - posting is
open for anybody, subject to filters.   And that we prefer to err on
a bit too open policy instead of blocking legitimate ones. Therefore
they do not count it against us, that we do leak spams.

What is wrong with blind "I see bounce from address X" way that mailman
does, is just that blindness.  There are genuine bounces, and there are
false bounces - and then those anti-spam bounces...  genuine and false.

We do not let automatics to kick subscribers away just because somewhere
was a network glitch.  We can not use such concentrated artificial
stupidity approach that mailman is so fine example of.  With present
mailman, I see no safe settings for automatic unsubscribe (posting disable)
based on arriving bounces.  Having the option ENABLED BY DEFAULT, when
a new list admin steps on (list is created), teaches approach that in my
thinking is seriously wrong.

I smell some SQL in the morning mist..., I think it is high time to
write The New List Manager, which does things the way that VGER wants to
run them...  There must be some good reason that central (and peripheral)
Linux lists keep migrating to vger.  We must be doing something better
than others,  yet we do not provide list archives via web, we just deliver
email  (and have our real day jobs, some work on Linux, some do not...)

I will make there something new that does a decent work on this, but it
will not have automatic unsubscribe option at all. Maybe there is a genuine
subset of responses where such automatics can be used, but I have also
seen MODERN MTA softwares (at least modern copies, old genealogy) say
"5xx user unknown", when they have internal troubles to access database
(like NIS+) and they should be telling "4xx internal troubles, retry latter" 
On UNIX platforms that relates on how indecently bad error status reports
are on  getpwnam()  library function.

> Oh, and lots of the work I do with mailman is at the unix command line.

There is hope for you  :-)

> -Jason
> kg4wsv

73 de Matti, oh2mqk