Quoting "Rick Moen" rick@linuxmafia.com:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
I'll also update http://lists.balug.org/listinfo.cgi/balug-announce-balug.org to make [1] a bit more clear (it's already quite clear on http://lists.balug.org/listinfo.cgi/balug-talk-balug.org and http://lists.balug.org/listinfo.cgi/balug-admin-balug.org ).
Intending no criticism, here, Michael, but I'll be curious to see what you'll be making a bit more clear.
It was perhaps subtle enough one might not even notice. Anyway, on: http://lists.balug.org/listinfo.cgi/balug-announce-balug.org I added (note also placement, emphapsis, and link used in the above) text: " (If you're subscribed to other BALUG list(s), but not this one we may subscribe you! See: BALUG-announce-do-not-auto-add.html if you want to be exempted from that and/or for additional related information.) " ... mostly just to round out covering the bases and for preventive maintenance purposes - e.g. scenario where someone's subscribed to "announce" and also subscribed to other BALUG list(s) - so they're not, perhaps repeatedly, surprised finding themselves resubscribed to "announce". It's covered rather/quite well elsewhere, ... but folks tend to forget. Not much of an issue yet, as the auto-add thing isn't yet fully automated (once I have the data - which I gather once in a while anyway for backup purposes (typically about monthly or so) - run a script, paste two places on the "mass subscribe" form, and the relevant folk(s) are added to "announce").
One reason not to try to make Mailman listinfo pages "a bit more clear" about unsubscribing is, in my experience, if you overexplain, people tend to think you're not serious, which then encourages them to say things like "unsubscribe me; I tried and it doesn't work."
Yes, point well taken (and you've made the point well before, too :-)). I tried to keep the additions/changes relatively minimalist, appropriately placed, easily referencing (but not directly including) details as appropriate (done via a link), and with the appropriate emphasis on key point(s).
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
It was perhaps subtle enough one might not even notice. Anyway, on: http://lists.balug.org/listinfo.cgi/balug-announce-balug.org I added (note also placement, emphapsis, and link used in the above) text:
[...]
OK, thanks.
Just to reconfirm something I said the very first time this came up, SVLUG solves the problem totally transparently to the members, as follows:
1. The svlug-announce@lists.svlug.org has as one of its members (subscribed addreses) the address svlug@lists.svlug.org, which is the posting address of SVLUG's main discussion mailing list.
2. The configuration for the mail discussion mailing list's setting "Privacy options", "Recipient filters", "Alias names (regexps) which [sic] qualify as explicit to or cc destination names for this list" has fill-in field "svlug-announce".
The result is that anything posted to svlug-announce goes to direct members of that mailing list _and_ (through rebroadcast) to all members of the svlug@lists.svlug.org mailing list.
At the time I suggested do likewise, I was told (here) that it was not possible to do it without problems.
Guess what? It's been working at SVLUG continuously since 1998 without problems -- and without need to run special auto-add scripts to subscribe anyone to SVLUG's -announce list.
Quoting "Rick Moen" rick@linuxmafia.com:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Just to reconfirm something I said the very first time this came up, SVLUG solves the problem totally transparently to the members, as follows:
(list subscribed to list ...)
At the time I suggested do likewise, I was told (here) that it was not possible to do it without problems.
I don't recall having said "problems" ... I did say "potential complications" ... perhaps not best wording, but in either case, each method has its own unique advantages and disadvantages. Either approach is valid and quite workable.
"Speaking" about the method chosen for BALUG, I earlier stated: < The above noted approach has the advantages of: < * it avoids the potential complications of lists subscribed to lists < and differing options/configurations (e.g. we want "announce" to be < non-digested, but we want folks to have digested form be option for < "talk"; if we subscribed "talk" to "announce", then those getting < "talk" digested, and not subscribed to "announce" would only see < "announce" within digested "talk" e-mails) < * it allows users to have separate per-list e-mail subscription < addresses if they desire such, and provides means for them to < request not being automatically added to "announce" based on < subscription to "talk" and/or "admin".
Anyway, ... those may not be exactly/precisely the various pros/cons comparing the different methods (and may also vary a bit depending on implementation details) ... but in any case, each method does have its own distinct advantages and disadvantages (e.g. list subscribed to list offers more simplicity in many/most ways; separate + (nearly) automagic addition +- exception mechanism allows some more flexibility, avoids some duplicate emails being sent to subscribers, allows users more per-list flexibility (e.g. distinct email addresses), but adds some more complexity for administration), ... and on and on one could go comparing them.
Anyway, the present BALUG method seems pretty well settled in and users (even newbies coming to the lists) seem to mostly understand it rather to quite well (as far as I'm aware, we haven't gotten a question or specific item about that from any subscriber (or potential subscriber) ... certainly not recently, perhaps not ever) ... and users seem to now mostly "do the right thing" when subscribing ... e.g. the number of folks I find subscribing to a BALUG list other than "announce", but not subscribing to "announce" is relatively small ... digging a bit more into list data (since the subscription totals don't reflect turnover information) ... between 2009-01-10 2009-03-27 total turnover on all BALUG's lists (adds and drops less auto-add) was 36 ... plus 3 auto-added ... so seems well over 90% get it right (rough small number statistics figure anyway - I don't think I saved more detailed historical "auto-add" data for more detailed analysis). So, ... being lazy(/efficient :-)) ... since it seems to work rather/quite well, I'm inclined to leave that general setup as it is (if it ain't broke, don't fix it). It also lends itself well to (future) automation. The script bits that do the "heavy lifting" (logic) - pretty compact, per wc(1): 7 40 365 With mailman CLI commands, cron, and a wee bit of glue logic/script, that can become fully automated process (well, except adding/removing email address from the "exception" list - but thus far there have been zero such requests - so that seems pretty easy to maintain).
references: http://lists.balug.org/pipermail/balug-admin-balug.org/2007-October/000419.h...
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
I don't recall having said "problems" ... I did say "potential complications" ... perhaps not best wording, but in either case, each method has its own unique advantages and disadvantages. Either approach is valid and quite workable.
A fair point, and I agree. I mainly wanted to dispel any doubts about whether SVLUG's approach works (it works perfectly), and describe how to do it.
I did find interesting, and appreciate, where you pointed out the one clear drawback of SVLUG's approach to a small group of people:
if we subscribed "talk" to "announce", then those getting "talk" digested, and not subscribed to "announce" would only see "announce" within digested "talk" e-mails)
This is a subtle point, that I'd actually forgotten about (mostly because I tend to forget all about digest mode, considering it pretty useless personally, and notice it mainly when people using it screw up Subject headers or quote entire digests to append two-line comments on one of the digest posts). Part of what you're driving at, I think, is that someone seeing "announce" posts only within "talk" digests conceivably might not get them in time at all -- and definitely might miss them when they're buried in discussion digests.
The counter to that point is that, if they _really_ want to see announcements, they'll just subscribe to the gosh-darned announce mailing list anyway: Considering we consistently keep it to 1-2 postings per month, objecting to the level of traffic's pretty comical.
On your other point:
it allows users to have separate per-list e-mail subscription addresses if they desire such
Wow, that's really stretching. Again, if Joe User wants SVLUG announcements (only) at his low-traffic work e-mail account, and other traffic at his (say) GMail bulk mailbox, then he/she can accomplish that, and can even filter out the reflected -announce postings within the MUA or LDA setup.
Anyway, I personally just think the SVLUG approach is a whole lot less baroque and fiddly. If nothing else, compare how baroque and fiddly the two groups' listinfo pages are.
This does seem like a good time to bring up a couple of other matters. One is that I have a mild ongoing bone to pick with my fellow BALUG admins, which I suspect means mainly you, Michael. That is, one or more of you has had a habit of fiddling around with the mailing list configurations without consulting with me first.
Why is it appropriate to consult with me first? I'm not even going to do more than mention in passing that I know mailing list administration, particularly with GNU Mailman, inside and out, and thus know to avoid a number of mistakes that the rest of you seem to have repeatedly rushed enthusiastically into. That's not really the point: The point is that, when you muck about with how our mailing lists operate, _I'm_ the guy you screw up.
Look at the bottom of the listinfo page for any of our three mailing lists. Notice where it says "[foo]" mailing list run by [bar]". In every case, [bar] is "rick at linuxmafia.com" and nobody else. I have repeatedly had you guys screw things up, and *I* have been left holding the buck.
Example: I carefully explained (here) why I had set the retention period to 3 days for all of our lists. Not long after, I found that somebody -- I believe, Michael -- had jacked that value to 21 days, resulting in a huge jump in spam volume in _my_ mailbox and not any other admin's. I then patiently explained in this space why I was adjusting it back, trying really hard not to jump down anyone's throat.
A while later, I explained that I was going to be out of the country on holiday, and that somebody would need to cover for me as listadmin. Nobody did, by the way -- but, when I got back, I noticed that someone in my absence had disabled the delivery of individual notices about messages held for listadmin attention.
Why was this a problem? Because it directly sabotaged my ability to diligently handle some of those posts. I could see in the daily summary of held messages that there _had_ been some non-spam held messages. However, because per-message delivery had been switched off, and because the messages had expired out of queue after 3 days, I was completely deprived of knowledge of the attempted postings' _contents_.
So, that was embarrassing, because essentially someone else on the admin team, without any idea what he was doing, had shot _me_ in the foot, preventing _me_ from doing my job, and making me look less competent at the job than I want to be.
This sort of thing makes me not a happy camper -- and the point is, _it keeps happening_. I have politely asked people before, in this space, to cease changing mailing list settings without checking with me. It has not worked.
I'm doing my best to be polite and constructive, but I keep getting the impression you're either not getting that you are interfering in my ability to do the job, or you don't care. Which is it?
The other matter: I'm getting a sense of deja vu from merely bringing this up at all, but I'm going to need someone to cover for me as listadmin, again.
This time, it is not my family going on holiday, but rather my having an upcoming hospital stay, April 30th to... I'm not sure -- for major surgery. I have a major health problem that is, fortunately, curable but will have me in Kaiser Santa Clara for n=1+ day, exact value of n to be determined, with (outpatient) convalescence for a couple of months after that.
(I do not feel like going into particulars, but, guys -- and I do mean guys especially -- do have your scheduled health checks as recommended and don't skip them just because you're absurdly healthy: It just might save your life. There's a reason why there are very few healthy old men, and it has to do with male human beings failing to visit doctors for routine screenings, not to mention also symptoms.)
I wrote:
This sort of thing makes me not a happy camper -- and the point is, _it keeps happening_. I have politely asked people before, in this space, to cease changing mailing list settings without checking with me. It has not worked.
In fact, on occasion, I read through the configuration screens of all three of our mailing lists, looking for things that have been whimsically changed without discussion. About half the time, I find some. Today's run:
1. Somebody doubled from 5 to 10 the permissible number of addresses on posts to balug-announce. Reverted.
2. Somebody switched off password reminders for balug-admin. Reverted.
3. Somebody added a large number of (probable) spammer addresses, most of them in .jp, to the roster of addresses from which postings to balug-talk will be automatically discarded. Reverted.
4. Somebody put Christian Einfeldt's GMail address in _this_ mailing list's roster of addresses from which postings will be automatically discarded. Reverted! That seems an incredibly harsh and unjustifiable thing to do to Christian, and I'm quite shocked that somebody did that. (I'm referring to "einfeldt@gmail.com", which is in fact a subscribed address in good standing on this mailing list.)
Now, with the exception of that last item, all of these are matters that might be worth considering upon discussion. The point was: There was no discussion -- and, when things like that get screwed up, it reflects badly on me much more than on the rest of you (my name being the one shown as listadmin), _and_ the public at large will naturally assume I'm the guy who did them.
Christian, my regrets on behalf of BALUG for whoever decided your postings to this list should be autodiscarded. (It was not I.)
Rick,
Regarding your emails[1][2] on BALUG list configuration changes, thanks for bringing these matters to our attention.
I had no idea that that many changes were going on - and many quite inappropriate. I certainly agree, they should be discussed and agreed upon - or at minimum, at least whomever does such should note the relevant bits to the "admin" list so that folks are aware what was changed (and why), and if there's reason to correct/revert/debate/whatever, at least folks have a clue what was done, by whom and what their rationale was (whether or not it makes sense overall for the list is another matter - but does help to know why someone did something - as there may be an issue/problem that should be addressed (or they thought should be addressed) ... but may have picked inappropriate or suboptimal approach to "fix"/address the issue).
In any case, it sounds like the level and number of changes going on are far exceeding what should be the case - particularly with lack of communication, and at least generally, agreement upon them. Of all the changes you mentioned, over the past several *years*, I've probably been guilty of transgressing 2 or perhaps 3 of them ... once each ... but sounds like there's a helluva lot more changes going on than are readily accounted for.
To that end, I'd *strongly* suggest it's (well past) time for new list admin password(s) - it's been a few zillion years since we changed them - and a rather large number of folks have been exposed to them (and they do go across the net in the clear :-/) ... anyway, I think it's time to change them.
As you probably use those passwords more frequently than anyone else (or at least I presume that should be the case) please feel free to pick good secure password(s) at your earliest convenience for all three lists (or if you prefer, let me know, and I'll pick password - but I tend to pick quite random cryptic ones). As to whom should get those passwords - let's start quite small - we can always expand that "small" circle if/when appropriate/warranted. As to who, I'd say we start with just these folks, and keep the admin list advised of any additional folks we share the password(s) with: Rick Moen rick@linuxmafia.com Michael Paoli Michael.Paoli@cal.berkeley.edu Jim Stockford jim@well.com (My) rationale for picking the above 3 - at least as initial set: Rick Moen rick@linuxmafia.com - does the most active (and best :-)) list management/wrangling for the BALUG lists (and thank you very much for all your work on that!) Michael Paoli & Jim Stockford - other than Michael Hubbard (Michael Hubbard hasn't been actively involved in BALUG list administration in quite a while, but he still has access ... and quite voluntarily foots the Dreamhost bill for BALUG (he's also got a bunch of his own stuff on Dreamhost)) ... Anyway, Michael Paoli & Jim Stockford have (delegated to them) most all the admin stuff that can possibly be delegated from Dreamhost (so - we have access to reset password, copy (or trash :-/) the database, main production website, etc.) ... so wouldn't make much sense to not share the password with the two of us - since we inherently have access anyway; also, other than Rick Moen, I probably play next most active role in list administration stuff (well, if we don't count the apparently large quantity of inappropriate changes going on).
Anyway, ... hopefully that will sufficiently cover it - at least for now. Most folks don't need to be on as list admins, ... three is probably a good (not too small or too large) number - we can adjust if/when appropriate.
Again, Rick, thanks much for your help and all your work on this, and sorry to hear that it was getting that out-of-hand. Time to reign in at least a fair chunk of that chaos.
references/footnotes 1. http://lists.balug.org/pipermail/balug-admin-balug.org/2009-April/000651.htm... 2. http://lists.balug.org/pipermail/balug-admin-balug.org/2009-April/000652.htm...
Michael Paoli wrote:
As to whom should get those passwords - let's start quite small
As I hold no official title with BALUG and have no technical expertise to add in this area, I would prefer not to be included in this small list.
-- Andrew Fife Untangle
650.425.3327 desk 415.806.6028 cell
Yes, fine, duly noted.
(I suggested just Rick, myself, and Jim, in [1]).
As, similarly, I sometimes end up saying to manager(s) or recommending someone say to their manager, something like: manager: <"demanding" root or other privileged password> admin: "Well, manager, just sign off here that you've been given that access, and that you are now also jointly responsible, and to be a considered among the suspects, at any and all times something inappropriate, unlawful, etc., is ever done with that ID."
So yes, ... best not to have more access than one more-or-less reasonably needs. :-)
Quoting "Andrew Fife" AFife@untangle.com:
Michael Paoli wrote:
As to whom should get those passwords - let's start quite small
As I hold no official title with BALUG and have no technical expertise to add in this area, I would prefer not to be included in this small list.
footnotes: 1. http://lists.balug.org/pipermail/balug-admin-balug.org/2009-April/000653.htm...
also duly noted. everything in this thread seems reasonable to me. NOTE: i consider myself a backup personage, willing to help out when need arises. jim
On Mon, 2009-04-13 at 23:47 -0700, Michael Paoli wrote:
Yes, fine, duly noted.
(I suggested just Rick, myself, and Jim, in [1]).
As, similarly, I sometimes end up saying to manager(s) or recommending someone say to their manager, something like: manager: <"demanding" root or other privileged password> admin: "Well, manager, just sign off here that you've been given that access, and that you are now also jointly responsible, and to be a considered among the suspects, at any and all times something inappropriate, unlawful, etc., is ever done with that ID."
So yes, ... best not to have more access than one more-or-less reasonably needs. :-)
Quoting "Andrew Fife" AFife@untangle.com:
Michael Paoli wrote:
As to whom should get those passwords - let's start quite small
As I hold no official title with BALUG and have no technical expertise to add in this area, I would prefer not to be included in this small list.
footnotes:
http://lists.balug.org/pipermail/balug-admin-balug.org/2009-April/000653.htm...
BALUG-Admin mailing list BALUG-Admin@lists.balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Yes, fine, duly noted.
(I suggested just Rick, myself, and Jim, in [1]).
OK, I'm just now changing the per-list listadmin password for each of http://lists.balug.org/listinfo.cgi/balug-announce-balug.org http://lists.balug.org/listinfo.cgi/balug-talk-balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
...to a new value, and will convey it, via whatever method is reasonable, to Michael and Jim.
Actually, I'm going to trust the key I fetched by doing: gpg --keyserver pgp.mit.edu --search-keys Michael.Paoli@cal.berkeley.edu ...and send Michael the new key via gpg-encrypted e-mail. (Yeah, lazy, I know: I'm not going to insist on a verifiable chain of trust from my key to his -- but this really isn't exactly the launch keys for NORAD.)
(Note to self: Self, time for some more keysigning gatherings.)
And I have Jim's cellular number, so I'll just telephone him.
Christian Einfeldt,
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.
At least to the extent I can, on behalf of BALUG, I wish to apologize for such error or inappropriate action/misconfiguration.
Hopefully we're taking steps[1] to substantially reduce the probability of such misconfigurations and/or inappropriate changes to the BALUG list configurations.
Quoting "Rick Moen" rick@linuxmafia.com:
- Somebody put Christian Einfeldt's GMail address in _this_ mailing
list's roster of addresses from which postings will be automatically discarded. Reverted! That seems an incredibly harsh and unjustifiable thing to do to Christian, and I'm quite shocked that somebody did that. (I'm referring to "einfeldt@gmail.com", which is in fact a subscribed address in good standing on this mailing list.)
Now, with the exception of that last item, all of these are matters that might be worth considering upon discussion. The point was: There was no discussion -- and, when things like that get screwed up, it reflects badly on me much more than on the rest of you (my name being the one shown as listadmin), _and_ the public at large will naturally assume I'm the guy who did them.
Christian, my regrets on behalf of BALUG for whoever decided your postings to this list should be autodiscarded. (It was not I.)
footnotes: 1. http://lists.balug.org/pipermail/balug-admin-balug.org/2009-April/000653.htm...
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.