[Balug-Admin] List confuguration changes/tweaks

[Rick Moen]

I wrote (about CABAL policies on
http://linuxmafia.com/mailman/listinfo/conspire):

> I should actually cut the length of that in half, and probably will,
> now that I've notice that _it_ also is a bit too wordy.

Policy is now amended to:

  General Linux forum for San Francisco Bay Area's CABAL user group, also
  gated to local NNTP newsgroup "cabal.conspire":  For NNTP access, send
  your fixed IP address to postmaster@linuxmafia.com.

  Our policy: the subscriber roster and public message archives will
  display unobscured addresses.  If attempting to hide an e-mail address
  from spammers, don't post from it.

  Jobs postings must be e-mailed to postmaster@linuxmafia.com, who'll post
  them or not.  Reasons why not have included their posting to other local
  mailing lists.  (We get tired of seeing the same posts everywhere.)

That's maybe 30% shorter, I think.


> I've had a lot of experience with the Mailman "moderator" (as opposed to
> listadmin) mechanism, and find it not very useful, and to have
> problematic characteristics.  I'd frankly urge continuing to ignore it.
> The reasons are a bit complex, and are most easily discussed in person.
> (I'm not saying there's any secrecy about it:  It's just that it'd be
> more efficient to go into those details in person.)

In brief, Mailman's "moderator" role is a bit like a listadmin, but
with deliberately curtailed powers.  (This is per se a useful concept.
What makes it of limited use is the implementation.)


In NON-brief {/me takes a deep breath}:

Within any given Mailman list's configuration, you can set two list-wide
passwords:  listadmin password, and moderator password.  

The administrative login prompt (Web page) will authenticate you with 
either password:  If you give the current listadmin password, you have 
access to all configuration and informational items.  You can view all 
settings, change anything whatsoever about it, edit the Mailman-generated 
Web pages, view and process the admin queue, etc.  You can also delete 
the entire mailing list, via a single Web-page pushbutton (with
confirmation).

If you login using the current moderator password, you're shown, and can 
change, the admin queue _only_.  On each held post, you can defer,
approve, reject, or discard.  In so doing, you can optionally check a
checkbox beneath the held posting to add the sender address to a roster
of senders to be either approved, rejected, or discarded prospectively.

During the several years when I was cleaning up and fixing SVLUG's
mailing lists, I found a number of e-mail addresses on some of the
mailing lists' autodiscard and autoreject rosters that almost certainly
should not have been there:  I recognised at least one, that of Anthony 
Ettinger, as that of a quit innocuous Web developer from Saratoga.  
Seeing no conceivable reason why his postings should be autodiscarded,
I removed that listing and wrote to him, to explain this (as well as I
could) and apologise on behalf of SVLUG for what was either some
vanished volunteer's mishap or act of malice.

SVLUG, you see, had been issuing a "moderator" password to some
volunteers to assist with held postings.  All it takes is for one to
frob the "add this sending address to the autodiscard roster" checkbox,
and that person is killfiled indefinitely.  Moreover, the moderator
cannot review such actions to catch such errors, and cannot correct
them even if he/she figures them out.

Probably, some such person at SVLUG messed up, at one point, and either 
didn't realise he/she had just backstabbed Anthony, or realised it but
was powerless to fix the deed.  A number of other such entries seemed
doubtful, so I ended up removing all but a few obvious spambot ones.

So, the Mailman "moderator" role is one with extremely unlimited powers
granted intentionally, plus one excessive and destructive power granted
by accident.  (Note that an unscrupulous "moderator" can use that
privilege to killfile arbitrary addresses that aren't currently
subscribed:  Just sent mail to the list forged to apparently come from 
that address, wait for it to show up in the admin queue, then discard it
and check the "autodiscard future posts" checkbox.)  Mainly for this 
reason, I consider the role nearly useless pragmatically, and also an
accident waiting to happen.

And therefore recommend that BALUG not use it.

What Mailman _really_ needs is (1) a role that allows someone to view
all admin settings + admin queue but change nothing, (2) a role that
allows one to view & process the admin queue + the autodiscard,
autoreject, and autoapprove rosters, and (3) a role that allows someone
to use the "invite" function without access to other admin settings
except to view the membership roster.  But it doesn't have those.