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.