[BALUG-Admin] BALUG list (mis)configurations, etc.

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

> While I don't know how it happened, who did it, or if it was intentional
> or accidental, in any case, your email address having apparently gotten
> onto the "automatically discarded" list as Rick apparently discovered,
> certainly should not have happened.

There's a rather bizarre way the addresses of posters to a Mailman list
_can_ end up on an autodiscard, or autoreject, or autohold roster
entirely by accident.

Imagine someone who uses one of the three[1] listadmin passwords usable
for a Mailman mailing list, who uses it to visit the administrative
queue Web page for that list.  Like, for example, the admin queue for
balug-talk, accessible (for those with a password) at
http://lists.balug.org/admindb.cgi/balug-talk-balug.org, includes an
item I'll simulate in ASCII like this:

                    From:zdmvio@securitycenter.com

  Click on the message number to view the individual message, or you can
  view all messages from zdmvio@securitycenter.com {linl}

  {1}  Subject:  Notification from PayPal (ID: X87HF)
       Size:  2255 bytes
       Reason:  Post by non-member to a members-only list
       Received:  Fri Apr 10 10:08:08 2009

  Action to take on these held messages:

  Defer (o)  Accept ( )   Reject ( )  Discard ( )

  [ ] Preserve messages for the site administrator
  [ ] Forward messages (individually) to: 
  _______balug-talk-owner@lists.balug.org_________

  [ ] Add zdmvio@securitycenter.com to one of these sender filters:

  Accepts ( )  Holds ( )  Rejects ( )  Discards (o)
  [ ] Ban zdmvio@securitycenter.com from ever subscribing to this
   mailing list




(In the above, I've used parentheses to stand for sets of radio buttons,
square brackets to stand for checkboxes, and curly brackets to stand for 
hyperlinks.  The reference to "_these_ held messages" (plural) is
becuse, if there were more than one post from a claimed sending address,
they'd be grouped together as items {1}, {2}, {3}, etc.)

Someone wandering around the admin screen might easily mark a checkbox
for "ban [user]" or "Add [user] to one of these sender filters", in
which case the user would go straight to the ban roster or the
autodiscard roster, respectively.

I'm guessing that the latter's what happened to Christian.

The only cures for those mishaps are to (1) have only fairly careful
people wield the listadmin passwords, and (2) have alert people check
those rosters, occasionally.



[1] First, for any given Mailman installation, there's a site-wide
listadmin password that automatically works on all lists, as a "skeleton
key" password.  In the case of BALUG's lists, that password is doubtless
posessed only by Dreamhost NOC staff.  The root user can reset it by
running $MAILMANHOME/bin/change_pw.py .

Second, each individual Mailman _can_ have a per-list administrative
password (if it's been set).   This is the one we use for BALUG, and for
simplicity's sake we keep the password for all three lists the same.
Note that you have absolutely no way of knowing how many people posess
this password at any given time (unless you've set it yourself and told
nobody else ;->  ).  Also, please note that there's zero correlation
between the persons who have this password and the parties identified on
the bottom of the per-list listadmin page as administrators.  The two
groups don't even need to overlap.  The people listed at the bottom of
the listadmin page is merely the roster of addresses that will receive 
"administration needed" nagmail notices.

Persons possessing the per-list listadmin password can not only process
the admin queue but also can take any other action to administer or
reconfigure the mailing list, up to and including deletion of the list.

Third, each mailing list _can_ have a separate per-list password called
the "moderator" password.  Giving the moderator password gains you access 
to the admin queue screens only (and the ability to process that queue), 
but grants no access to other administrative functions.  Among other
things, this means that, if someone with the moderator password
accidentally uses the above-described checkboxes to ban someone or add
him/her to the autodiscard roster and then realises his/her error,
there's nothing that person can do to fix the error, since ability to
edit those rosters' contents is on different admin screens.