FYI: Mailman config summary for our three lists
(Larry, please note apology near bottom for a huge factual error I recently made, here, about balug-announce. Sorry!) A couple of months ago, Larry was kind enough to give me the changed administrative password -- which he said had to be changed because one of the listadmins inadvertantly revealed the old one on one of the public lists. So, as mentioned, I am (once again) physically _able_ to tweak any of the settings -- but would not do so except in close consultation with other listadmins. That same access also lets me _view_ the current settings. (Unfortunately, there's no Mailman administration "view" right grantable separately from the "edit" one.) So, for the sake of collective knowledge, here's how they're currently set up: balug-admin-balug.org (this list) --------------------- Administrative e-mail addresses: balugadmin@balug.org, balugadmin-admin@xav.to Explanation: These are the people who'll receive "Administer me!" nagmails from Mailman, e.g., when a posting is held for listadmin approval. Analysis: 1. Note that this roster is entirely distinct from the set of people possessing the listadmin password. A person might be in one group only, the other group only, or both. (Being in the roster of people who get nagmail but lacking access to act on it really sucks; that's the situation I've been in since early 2005 on several SVLUG lists.) 2. I'm not sure it's a good idea to list "role" e-mail addresses here, since it obscures who's involved in list administration. E.g., I really have no idea who other than Larry is looking after our lists, and this roster gives me no clues. A terse phrase identifying this list: [null] Analysis: Bad. We really should have a list description. An introductory description - a few paragraphs - about the list. It will be included, as html, at the top of the listinfo page: [null] Analysis: Bad. We really should have a descriptive paragraph. Where are replies to list messages directed: Poster Explanation: I.e., we aren't doing Reply-To munging. Send monthly password reminders: No. Analysis: Doesn't really matter much; many people dislike the periodic reminders, or raise time-wasting fusses over their supposedly "bad security", so maybe this is just as well. Subscribers who _want_ a password reminder can trigger one manually at any time. List-specific text prepended to new-subscriber welcome message: [null] Analysis: Not a complaint, but this is a missed opportunity to say something non-generic to new arrivals. Check postings and intercept ones that seem to be administrative requests: No. Explanation: Messages that seem to say only "subscribe", "unsubscribe", etc. would be held for listadmin scrutiny rather than sent directly out to the membership. Analysis: In my view, this Mailman feature works amazingly well and should _always_ be left on absent a very strong reason otherwise. Maximum length in kilobytes (KB) of a message body: 40kb Discard held messages older than this number of days. Use 0 for no automatic discarding: 0 Analysis: Since 99% of held messages are spam, I'd say "3". Languages supported by this list: English-USA (only) Analysis: Since you can offer the other 29 languages too, without any disadvantages, why not? (It's obviously not a problem, though.) How big in Kb should a digest be before it gets sent out: 30 Should a digest be dispatched daily when the size threshold isn't reached: Yes. Advertise this list when people ask what lists are on this machine: Yes Analysis: Normally, this would mean you could browse at the top of the Mailman HTML tree, to see what lists are on the hosts, and find this one described there, but Dreamhost's rather odd configuration makes http://lists.balug.org/listinfo.cgi/ entirely uninformative. So, the main entry point to the three lists is the explicit hyperlinks to their individual listinfo pages on BALUG's Web pages. Who can view subscription list: List members. Explanation: Can be set to Anyone, List members, or List admin only. Show member addresses so they're not directly recognizable as email addresses: Yes. Analysis: I personally like these two settings for most lists, as they nicely balances openness with a little bit of privacy protection. People wanting more can set a per-subscription option to "hide" their presence on the membership roster from everyone except listadmins. Action to take for postings from non-members for which no explicit action is defined: Hold Analysis: This catches and holds legitimate posts from non-member addresses (which can then be added to an approved roster for subsequent postings, at the time an admin clears the posting). However, mostly, it catches and holds spam, which for practical purposes can be otherwise controlled (prevented, rejected) only earlier, at the MTA. Since BALUG cannot administer the MTA (only Dreamhost can), this probably means a boatload of spam ever day to whoever is reading mail at balugadmin@balug.org and balugadmin-admin@xav.to. Must posts have list named in destination (to, cc) field (or be among the acceptable alias names, specified below): Yes. Alias names (regexps) which qualify as explicit to or cc destination names for this list: balug-admin@lists.balug.org, balug-admin@balug.org, balug-admin-balug.org@lists.balug.org Analysis: 1. You can thank whatever thoughtful person expanded that alias list for your ability to use reasonable names, and not just the rather over-elaborate _main_ name. 2. However, I believe the first entry's redundant, being the main, official name and thus automatically honoured. Ceiling on acceptable number of recipients for a posting: 10 Analysis: This blocks some spam from the dumber spammers, plus hideously excessive crossposts. One might reduce it to 5 without problems. Is archive file source for public or private archival: Public Analysis: Again, in my view, best unless you have a _real_ need for secrecy and don't mind discouraging new participants. How often should a new archive volume be started? Monthly. Analysis: With this low traffic, I'd have picked quarterly, myself. balug-talk-balug.org -------------------- (Options and comments same as before, except as noted.) List of non-member addresses whose postings should be automatically accepted: rick@linuxmafia.com, larry.platzek@gmail.com, rms@gnu.org Analysis: 1. This is redundant but harmless if the address _is_ subscribed, which mine (rick@linuxmafia.com) is -- so I'm removing it. Still, the thought's appreciated. 2. FYI, this roster is where addresses get autoadded to, when a listadmin approves a held post from a non-subscribed address _and_ also checks the nearby checkbox to allow postings from this address in the future. List of non-member addresses whose postings will be automatically discarded: service@amazon.com, morinokumasan66@ocn.ne.jp Analysis: (Not a complaint, just an observation) This reflects listadmin action against a spammer, i.e., a checkbox similar to the one noted above, but to _discard_ all future postings arriving from this address. One should be careful about being fooled by forged headers, though. Also, there's really not a lot of point individually blocking sender usernames like "morinokumasan66" that are probably script-generated by the millions. balug-announce-balug.org ------------------------ (Options and comments same as before, except as noted.) By default, should new list member postings be moderated? Yes. Analysis: OOPS! I've made a huge error in my earlier post: The "announce" mailing list _is_ set as moderated. Larry, my apologies -- and I now dimly recall that this matter has come up before. Sorry, I'm on so many mailing lists, I can't always keep them stright. Anyhow, for the record, only the subscribed addresses of Larry, Art Tyde, and David Sifry are set so they can post without being held for listadmin scrutiny (no moderated flag). List of non-member addresses whose postings will be automatically discarded: zonal_info1@yahoo.co.uk, eqhla.eqhla@aucma.com.cn, fred@ugramail.ru
Thanks Rick. Lots of good information - particularly for those of us not having the access to read those configuration details. Perhaps at our next BALUG meeting, at one table we can go over some of these administrivia details, and get a consensus (or at least strong plurality) of how we should handle/adjust these things. I'd guestimate one of the trickier areas may be the "approvers" and such for the "announce" list (and the Mailman nag recipients). Seems we would want a relatively small number (e.g. approximately 3 or so?) of folks that could "approve" "announce" items and/or send directly to "announce" without another's approval, and that this same small number of folks (at least the approvers) would get the Mailman "nag" reminders (e.g. things held pending approval). I'd think by structuring and "advertising" (documenting, e.g. the lists and their usage) in appropriate manners, we could minimize the "burden" of the "announce" approvers. E.g. if we have policy that more-or-less says don't send stuff to announce, it will almost certainly get rejected, then I'd think it a bit easier for the "announce" approvers to handle the Mailman nag messages, as those would all be simple rejects. But we'd need to set up some reasonable means for folks to bring to our attention stuff we might want to include, or include in part (or provide pointer to more details) on some "announce" item(s). Not quite sure right off the top of my head what might be the best way to do that (the "admin" list doesn't quite work for that, as folks need to be subscribed to it to post to it, otherwise it's held for administrative action, and we add another layer of steps/complication ... but we don't want random spammers to be able to send straight through to "admin" postings either). Anyway, I'm sure we'll come up with ways to improve the process (like dropping stuff that's held more than 32 days ... some of the stuff that went out on "annouce" was more than 60 days old!). references: http://lists.balug.org/pipermail/balug-admin-balug.org/2006-June/000158.html et. seq.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Thanks Rick. Lots of good information - particularly for those of us not having the access to read those configuration details.
Yr. very welcome.
Perhaps at our next BALUG meeting, at one table we can go over some of these administrivia details, and get a consensus (or at least strong plurality) of how we should handle/adjust these things.
Discussing these matters _with_ Internet access is pretty important when you get down to specifics, in my experience. Discussion over dinner _without_ Internet access tends to be vague and fuzzy. Maybe consensus can be arrived at on this mailing list, or on IRC? It'd also have the advantage of speed. I _could_ fix things pretty well right now, acting alone, and anything I misjudge can be tweaked by other listadmins (whoever they are), but I don't want to step on any toes.
I'd guestimate one of the trickier areas may be the "approvers" and such for the "announce" list (and the Mailman nag recipients). Seems we would want a relatively small number (e.g. approximately 3 or so?) of folks that could "approve" "announce" items and/or send directly to "announce" without another's approval, and that this same small number of folks (at least the approvers) would get the Mailman "nag" reminders (e.g. things held pending approval).
I sort of slept on that very question. Based on experience elsewhere, I'm guessing that having one's e-mail address in the "nag" roster brings a significant daily spam harvest, getting bigger all the time. Spam is a big enough burden that you don't want more than one or two people's e-mail addresses (and -not- _role_ e-mail accounts, I'd say -- which is exactly what we have at present) on the nagmail roster. One is fine, two is fine -- because you _also_ have one or two people possess the listadmin password but _not_ have e-mail addresses on the roster, as a safety fallback. The former (those on the roster) are the working listadmins. The latter are people who've agreed to sit on their hands and not interfere, but are the human equivalent of the envelope containing root passwords stored in the company safe. All agree to inform the others promptly (preferably by telephone or in person) if it's ever necessary to change a list's listadmin password.
I'd think by structuring and "advertising" (documenting, e.g. the lists and their usage) in appropriate manners, we could minimize the "burden" of the "announce" approvers.
You can't do much about held spam at the Mailman level, only at the MTA level. ISP-managed MTAs tend to relatively spammy; that's just part of the package and can't be fixed by individual customers. I mention that because shovelling spam typically is the lion's share of listadmin "burden" -- and is irreducible unless you run your own MTA. The best way to manage/lessen the remainder in my experience is to have a clear, very brief per-list policy posted right where people expect to find it, on the individual list's listinfo page. And then, yes, you pick people willing and able to do the job. ;-> Whoever approved those jobs postings on balug-announce _might_ be on this mailing list (balug-admin) -- or might not. If you are, nobody's going to beat you up. ;-> For one thing, there's no posted policy, eh? Having people possess the listadmin password but _not_ be on this (balug-admin) mailing list would suck, but is distinctly possible. Imagine someone who really doesn't know anything about running mailing lists, but who'd been given that password. One day, he/she gets around to trying it out, and wanders around the administrative screens with his/her Web browser, and stumbles across a queue of seven held postings that (for whatever reason) nobody'd dealt with. Either not bothering to read specifics, or being unclear on what's offtopic, he/she thinks "Oh, well, as a listadmin I'm supposed to approve posts -- and here's a bunch." So, that person picks the Approved radio button on each, then the big page-wide Submit button. Job done. Not being a reader of this mailing list, the person never even learns that the action was unwise.
But we'd need to set up some reasonable means for folks to bring to our attention stuff we might want to include, or include in part (or provide pointer to more details) on some "announce" item(s).
OK, FYI, every Mailman list has an inherent -owner role address that automatically reaches everyone on the list's nagmail roster. So, the list policy could say something like "Please submit non-BALUG announcements you think might interest our members to balug-announce-owner@lists.balug.org."
Anyway, I'm sure we'll come up with ways to improve the process (like dropping stuff that's held more than 32 days.
Let's please take pity on volunteers asked to wade through held spam, and make it no more than 5 days.
Quoting rick (rick):
A couple of months ago, Larry was kind enough to give me the changed administrative password -- which he said had to be changed because one of the listadmins inadvertantly revealed the old one on one of the public lists. So, as mentioned, I am (once again) physically _able_ to tweak any of the settings -- but would not do so except in close consultation with other listadmins.
OK, I've acted just a tiny bit, in the areas where I think we're all in agreement. Why? Because I noticed another jobs listing in the moderation queue for balug-announce. This one was: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Systems Engineer and Sales Engineer positions, San Francisco ISP Thread-Index: AcaOQanLzTKYPCmrQ9e7k+ZirPYeJg== From: "David Hecht" <david@servepath.com> To: <balug-announce@lists.balug.org> Message-ID: <S1Fpplq-000883-Lg@smtp1.servepath.com> My company has open positions for both a Sales Engineer and a Systems Engineer. If you are looking to take your career to the next level, consider the challenge of San Francisco's largest and fastest growing Internet service provider. With over 2000 customers you will work on a wider variety of issues and deploy more types of production systems than almost anywhere else. You won't be bored. Red Hat * Fedora * Debian * FreeBSD Full job descriptions here: http://www.servepath.com/about/jobs.htm Questions welcome, though I am not in charge of hiring for these positions. Thanks, David Phone 415.869.7003 | eFax 415.680.2912=20 360 Spear Street | 2nd Floor | San Francisco, CA 94105 =20 Dedicated Server Hosting: http://www.ServePath.com=20 San Francisco Colocation: http://www.ColoServe.com Streaming Media Services: http://www.UpStreamNetworks.com Since we don't know who's been approving such postings recently, I felt I should step in (and, hey, I _am_ a listadmin) to politely turn it down, as the first thing. Here's my reject text: Despite a recent error by one of the moderators, balug-announce is NOT a jobs mailing list, and is not intended to be open to postings by the general public: It's primarily intended as a means to announce upcoming BALUG meetings to the membership. That having been done, I addressed one of the omissions that created this situation in the first place: The "terse phraes identifying the list" (shown near the top of the listinfo page) now reads: Announcements for and by BALUG The "introductory paragraph" below that on the same listinfo page now says: This is a low-volume announce-only (non-discussion) mailing list primarily for BALUG's meeting announcements to its members. Please send any other announcement to the moderators at balug-announce-owner@lists.balug.org, and they'll decide whether to post it. The membership roster is open to all listmembers. I've also made a couple of other changes that I hope will be non-controversial. (Listadmins are welcome to revise my changes.) "(Administrivia filter) Check postings and intercept ones that seem to be administrative requests?": Changed from No to Yes. "Discard held messages older than this number of days. Use 0 for no automatic discarding.": Changed from 0 to 7. On balug-talk, "terse phrase" is now: General discussion list for BALUG "Introductory paragraph" is: This is a public discussion mailing list for Bay Area Linux User Group, which meets monthly in Chinatown, San Francisco. Postings are publicly archived, and the membership roster is available to any subscriber. And I duplicated the other two changes cited above for balug-announce. On balug-admin (this list), "terse phrase" is now: Discussion among those who make BALUG work "Introductory paragraph" is: This is a low-traffic public mailing list among BALUG members who run its Web site and mailing lists, find speakers/topics for its monthly meetings in Chinatown, San Francisco, and run those meetings. All interested or curious people are quite welcome, but this is a working rather than social forum. Posts are publicly archived, and the membership roster is available to any member. Again, I duplicated the other two changes cited above for balug-announce. On all three lists, I also added my e-mail address to the "nagmail" roster.
participants (2)
-
Michael Paoli
-
Rick Moen