Managing Mailing Lists 100
Managing Mailing Lists | |
author | Alan Schwartz |
pages | 261 |
publisher | O'Reilly & Associates |
rating | 8.5 |
reviewer | Luke Tymowski |
ISBN | 156592259x |
summary | The definititive mailing list manager manual |
The Scoop
You subscribe to a handful or more mailing lists. You decide to start one yourself to fill a hitherto ignored niche. Which Mailing List Manager (MLM) do you pick? Where do you find docs for them? And how best do you go about managing the list -- performing duties of list mom, keeping everyone on topic and trolls off the list?
Alan Schwartz's Managing Mailing Lists will be your trusty guide, provided, of course, you're using one of the MLMs he writes about (Majordomo, SmartList, LISTSERV Lite, Listproc). He summarises how mail and mailing lists work, the applicable RFCs, how to install and configure the MLMs, how to administer them, and provides a reference to each MLM. There's enough detail here to grow you from a basic, competent list administrator to a near-wizard.
What's to Like
Many of us may assume we already know all we need to know about the basics. I've been running my own server for several years, and I still learned a few things reading the introduction. In fact, it should be required reading for anyone running a mailing list, assuming they are not already in the wizard category. Too many list admins I know are comfortable running a list, but don't understand how all the components work together. Then they wet themselves when something doesn't work and they have no idea where to start looking for the problem.
Chapter 1 provides a quick tour of mail headers, the relevant RFCs, email programs (MUAs, eg, Mutt, Pine, Eudora), mail transport agents (MTAs, eg, Sendmail, Postfix, qmail, etc.), mail reflectors (eg, Sendmail's alias file), and, finally, mailing list managers -- what they do, don't do, what they do well, what they don't do well.
Chapter 2 describes how to design a mailing list, everything from naming a list, to posting guidelines, to moderated vs non-moderated, to exploders and newsgroups, to handling large lists, to choosing your MLM (philosophy, features, programming language and source availability). This is a long, detailed chapter with plenty of valuable tidbits for the budding list administrator.
Chapters 1 and 2 stand on their own as the best discussions of list construction, management and protocol that I've seen yet. Everyone running a list will find something of value here, whether technical or political.
Troubleshooting mailing lists is covered in Chapter 8 (why not chapter 3?), and, while it's very short, it is a good summary of what can go wrong and how to fix the problems. This is perhaps a more difficult issue today than when the book was published because in the fight to thwart spammers, it's getting more and more difficult to sort out just why some list members cannot receive or post mail.
Each MLM gets its own chapter to help you install and configure the product, a separate chapter to administer each MLM, and an appendix which summarises the commands and directory structures.
Did you know you can maintain your own lists with Sendmail? I didn't realise just how powerful it can be when combined with formail and procmail. While I use Postfix as my MTA, not Sendmail, Postfix is designed to replace Sendmail and therefore most of the tricks for managing lists with Sendmail work with Postfix. I spent a few entertaining hours exploring just what can be done with these few handy tools. Of course, neither Sendmail or Postfix are as powerful as dedicated MLMs, but you can still accomplish a great deal with them.
What's to Consider
The book is three years old. Each MLM was already a mature product when the book was written, and none have changed very much since 1998. The biggest change is perhaps with Listproc -- it's no longer free. But otherwise the products have undergone minor revisions, mostly bug fixes and small, new, features.
Mailman, the Gnu MLM isn't covered. But then Mailman either didn't exist in 1998 or it was too new to enjoy sufficient popularity to justify a chapter. qmail, which allows each user to create their own mailing lists, is mentioned, but isn't documented -- again probably because it didn't enjoy the popularity it has now.
Summary and Table of Contents
Managing Mailing Lists is still relevant despite its age. The introductory chapters are excellent and could hardly be improved upon if it were re-written today. If you're going to manage a mailing list and plan to use another MLM, Mailman for example, which is not documented in the book, it is still worthwhile buying a copy. If you already have some experience managing lists as either a list mom or server admin, you'll still learn something. It is, I think, one of the best O'Reilly books I've read -- and I've got a few shelves full of them.
- Introduction
- Designing a Mailing List
- Maintaining Lists with Listproc
- Maintaining Lists with Majordomo
- Maintaining Lists with Smartlist
- Maintaining Lists with LISTSERV Lite
- Maintaining Lists with Sendmail
- Troubleshooting Your Lists
- Administering Listproc
- Administering Majordomo
- Administering Smartlist
- Administering LISTSERV Lite
- Listproc Reference
- Majordomo Reference
- LISTSERV Lite Reference
- Index
You can purchase this book at Fatbrain.
MLM (Score:1)
This book is indeed spammer heaven!
Re:MLM (Score:1)
Re:MLM (Score:1)
Most people say "listserv" which isn't correct because LISTSERV is a mainframe based MLM.
Next book... (Score:4, Funny)
"digested people"?! (Score:1)
digested people (Score:4, Funny)
Re:digested people (Score:2, Informative)
Re:digested people (Score:1)
Ow, come on! Lets keep it mature, here!
Stefan.
Re:Next book... (Score:1)
Re:Next book... (Score:3, Informative)
However, it should be noted that typically, by default, new lists are created with "reply to list" enabled, no administravia checks, and no message limit.
In other words, these common problems with mailing lists are a result of poor list management and not from stupid users (at least most of the time). It takes but a few seconds to prepare these configurations in Majordomo, and thus there's no reason to not have them if that is something you want to enforce on your list.
Re:Next book... (Score:1)
I agree - also some simple human measures - how hard would it be for upon a subscription to a list, to point out a reference to (or even just inline) a quick 'netiquette' page or somesuch highlighting.... (quoting original post)
Not one mailing list I have subscribed to (okay, only a small few, but still) have done this?
Bad interface design (Score:3, Insightful)
As Jakob Nielsen says [useit.com], "provide a special email address for each of the main commands: subscribe, unsubscribe, post discussion group message, etc. Keep the list short and there is a chance that users will understand it".
You should get better software if you can't get better users.
0 Sales (Score:2)
Useless idea for a book, IMHO. People who read books and look up how to do things, don't commit the acts you describe.
But I guess such a book might make sense as a "gift item." Still, I predict that publishing such a book would be a great way to lose money.
Re:0 Sales (Score:2)
You've obviously never been thrown into the position of Mailing List Maintainer for an active list
It's a harrowing experience on an active list (the list I was thrust into has 400+ members at any given time with people subscribing and unsubscribing constantly, and averages 100+ messages per day). A book like this would have been an invaluable asset. Hell I still might pick it up.
One word to those who'll listen: If you're using Majordomo and Sendmail, use Bulkmailer. It gave me a logarithmic speed increase (literally: a 20 minute delivery became a 2 minute delivery time).
Re:Next book... (Score:2)
- not replying to all, not sending admin commands to the list, realising that digested people really don't like binaries.
Since no two mailing lists are ever quite the same, even when a common solution like Majodomo is used; Such a book would be be pretty difficult and near impossible to do well.
To blame the 'end users' for poor admin is out of order, mailing lists users are rarely newbies; so if even the old hands making mistakes, it's usually because of the lack of consistency and poorly implemented/managed lists, not miss-use.
Re:Next book... (Score:1)
--tangram
Mailing list software (Score:5, Interesting)
No EZMLM? (Score:3, Informative)
Re:No EZMLM? (Score:2)
Still, whatever floats your boat.
Re:No EZMLM? (Score:1)
What's wrong with it? It's my personal favourite, the only thing I don't like is its license...
Re:No EZMLM? (Score:1)
Why ezmlm+qmail is used for gcc.gnu.org lists (Score:3, Informative)
Some have wondered why GCC -- arguably the GNU project's flagship, after the Emacs operating system^W^Weditor -- doesn't use Mailman as a list manager.
Because Mailman has an annoying tendency to be web-based. You have to do the little password thing to do anything interesting, like subscribe.
ezmlm, on the other hand, is near totally administered via email commands. Which is damn handy for automating tasks. [Un]Subscribing, retrieving archives, even banning individual users, is all done by sending an email message to the software. Actually, the commands are all part of the address itself, you don't have to pay special attention to the formatting and contents of the subject line and message body.
And qmail can handle a metric buttload of message in parallel, which is quite handy.
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
i'm pretty sure that this statement is untrue, and that you can send list management commands via e-mail. unfortunately, the mailman documentation leaves something to be desired, and i couldn't find any specifics on this besides a few statements to the effect of "no, you don't have to use the web interface."
having said that, the web interface is a good thing for most users; it's fairly slick and easy to use. why bother explaining majordomo/whatever commands to a newbie when you can just point him/her to a web page?
jacob
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
Okay. I'm willing to be corrected.
Primarily, they do; for GCC at least. The page describing the mailing lists has a little sub/unsub form. Type in the address, select a list from a drop-down, etc, one click (whoa! amazon patent infringement! *grin*) and a server-size form assembles the empty email command.
For non-newbies, however, it's also wonderful. When I go on vacation for long stretches of time, I have a shell script which sends empty emails to the "command" addresses, suspending my subscription. And at one point, I used an at(1) job to send the renewal command emails, so that the list mail would start arriving at the same time I returned. :-) Then the airline industry allowed their schedules to become totally stochastic and nondeterministic, so I don't try to predict the return time anymore.
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
As a user, I hate Mailman.
Compare and contrast this sequence of actions:
With sane mailing list software:
With Mailman:
Now which was easier?
I use Smartlist for all my mailing lists. It's a huge pain in the ass to configure, but it does the "reply to this to confirm" trick completely painlessly from the end user's point of view, and not having that is a deal breaker for me.
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
In fairness to mailman, though, if you send a message with the body "unsubscribe" to foo-request, it will respond with a usage statement for the unsubscribe command. But then you're back to needing to know your password. :)
I imagine that the password feature is an attempt to cut down on unsolicited/unintended subscriptions and unsubscriptions. I've never been the victim of a prank unsubscription myself, though. :)
Nevertheless, I still like mailman's web interface. I manage a few majordomo mailing lists, and I ended up rolling a crude web interface because ordinary joes don't grok the e-mail interface and would constantly send admin requests to the mailing list itself. If you tell them just to go to http://blah.com/list.cgi, they usually can deal with that just fine.
Anyway, to each his own...
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
But that's exactly my point: it doesn't work for that. By which I mean, it provides no more protection than the "reply to this message to be subscribed" mechanism. So long as you can tell the web page to mail you your password, the only real validation that is going on is that the person issueing the subscribe request is a person capable of reading mail sent to the address they are subscribing.
It's important that mailing list software do this check, to avoid prank subscriptions. But the "reply to this" method is N less steps than the password-I-don't-know-I-have method, while being absolutely equivalent from a security point of view.
So the password thing is merely irritating and a waste of time: it has no benefits.
Corrections (Score:2)
Because Mailman has an annoying tendency to be web-based. You have to do the little password thing to do anything interesting, like subscribe.
The premise is incorrect. To see the extremely extensive list of e-mail-accessible options for any Mailman mailing list, send message text "help" to [listname-]request@[listserverhost].
Some have wondered why GCC -- arguably the GNU project's flagship, after the Emacs operating system^W^Weditor -- doesn't use Mailman as a list manager.
Almost certainly because it was set up a long time ago, before Mailman was available.
Rick Moenrick@linuxmafia.com
Re:Why ezmlm+qmail is used for gcc.gnu.org lists (Score:2)
Hm (Score:1, Insightful)
No mailman?
'seems to be the big one these days. Maybe it wasn't, back when the book was written.
Insightful? Read the review (Score:1)
Moderators: you should at least be reading the articles before you start throwing mod points around.
Lyris (Score:2, Interesting)
thanks.
dmarien
www.dmarien.com
Re:Lyris (Score:3, Informative)
As far as managing mailing lists goes, Lyris is definitely the best software I've seen - it's fast, reliable, stable, handles bounces well, and has a nice web interface for managing everything. It is also extremely scalable. That's the great part.
Unfortunately, I've also had some less than pleasant experiences trying to customize and extend Lyris. It has a number of hooks for extending it, and has it's own protocol (LCP) for communicating with the server that has bindings in Perl, Java, ASP, and PHP coming soon. However, the programming interfaces depend on a lot of knowledge about how Lyris does things internally, so expect a LOT of trial and error when doing anything interesting. That's the only bad part.
Overall, if you're handling important lists, and don't want to spend too much time on administration, and can afford it (it can get pricey for the high end versions) I would highly recommend Lyris.
Re:Lyris (Score:1)
How to handle mailing list vacation responses? (Score:1, Interesting)
Re:How to handle mailing list vacation responses? (Score:1)
Re:How to handle mailing list vacation responses? (Score:1)
Works for me!
A really good book, but needs a few updates (Score:4, Informative)
/me rubs eyes (Score:1)
"Maligning Mailing lists".
Heh, are mailing lists *that bad*?
Remember kids (Ed Asner voice) Reading Is Fundamental!! (RIF, god I'm {carbon?} dating my self, aren't I?)
Moose
Egroups (Score:4, Insightful)
Re:Egroups (Score:2, Insightful)
Re:Egroups (Score:1)
Re:Egroups (Score:1)
Re:Egroups (Score:1)
Re:Egroups (Score:1)
A Christian mailing list I'm on is about ready to have me set up a real list on our own server instead of a Yahoo list specifically because of those ads. Lately Yahoo's been showing a lot of skin.
Re:Egroups (Score:2, Informative)
This book taught me how to run Majordomo... I wasn't a complete novice, but mid level and it certainly made things go faster, especially when it came to hacking the aliases file and tying up some loose security knots.
eScribe (Score:1, Informative)
It's not the technology (Score:5, Insightful)
If we take mailing list technology as a given, there are still some pieces of advice that I think are required for anyone running a mailing list:
- Always moderate your mailing list. There are too many e-mail worms and other nasty crap that happens via e-mail these days. It's possible to infect hundreds of people instantaneously via an unmoderated mailing list. This stuff can be caught if a human reads every submission.
- Moderate daily. People hate seeing their messages sit in queue for too long.
- Moderate mistakes. One-line "I agree" posts, "fuck you" posts, posts that clearly were not intended for the list, and empty posts should never go to the list.
- Resist the urge to limit discussion. If someone has an opinion that you disagree with, this is exactly the sort of thing that you want to see on your list. Most moderators make the mistake (as they do on Slashdot) that because they disagree with the poster's opinion, it shouldn't be seen by anyone. A healthy disagreement is critical to the survival of any online forum.
Re:It's not the technology (Score:1)
For example, someone would post a "For sale" message. Someone else would reply to it, but send it to the entire list. That's why we were moderating.
The solution hit me one day while I was dozing. Change the list so that replies go to the original sender rather than the list (unless you hit reply to all). Worked like a charm, everyone was quite happy. And I didn't have to read a dozen or so messages a day just to approve them. (I also took the opportunity to add a header to the subject line and some other things to make it easier to use.)
I still subscribe to the list though I no longer run it. They're still using those settings.
--RJ
Re:It's not the technology (Score:1)
I do agree. Its nice to have a package dependant HOWTO, but that can be found in the man pages (hopefully). I can find all I want at ezmlm.org, but it doesn't tell me how to help keeping the people on the list happy.
They need to teach you:
Not how to give sendmail a -HUP.
Re:It's not the technology (Score:1)
There is no correct solution to Reply-To that works for everybody. I personally put the effort into manually forwarding messages to people that were incorrectly intended for the list. This means that discussions tend to end up on the list that might have originally been private. YMMV.
Which is the best? (Score:2)
The author of the review says, "Managing Mailing Lists is still relevant despite its age." Translation: This book may be useless if you are picking a mailing list manager now.
What is the best mailing list software? What is the best open source mailing list software, if the answer is different?
What should be the Response to Violence? [futurepower.org]
Re:Which is the best? (Score:2)
Mailman is a pretty good program. It's relatively easy to set up, and includes the whole bundle -- mailing lists, archiving, and web interface. These are all available for the other MLMs, but not generally bundled. I find Mailman's passwords annoying and useless (why do I need another completely unsecure password?) -- otherwise the interface is fairly good. I don't know about other MTAs, but I've set up Exim so that creating mailing lists is easy (no need to edit /etc/aliases).
No one should ever use listproc or listserv, they are old and pointless. I don't know anything about Smartlist. Majordomo is still an option -- I don't think it offers any features over ezmlm or Mailman, but with some work can be at least as functional. Still, I found it a little awkard to work with, and it seemed to take considerable work to patch in all the features that more modern MLMs have aquired.
I don't know why you'd ever want to use a commercial MLM. The free/OSS programs are all entirely sufficient -- if you are having problems setting them up, pay a consultant to help you. You'll get better service than you would with shrink-wrap software anyway. I know the Qmail site has a list of consultants for hire.
Which is the best? (Score:2)
Thanks for the great answer. I was impressed with the QMail web site.
Some of the posts have said that QMail is difficult to configure. It that true?
What would you recommend, Exim or EZMLM?
Re:Which is the best? (Score:2)
I use Debian, and Exim is the default MTA. I like it well enough. It's dead simple to set up Mailman as well -- you just install the package and you're off (though to avoid editing /etc/aliases you'll have to do some digging -- I wouldn't bother unless you were making lots of lists or someone untrained was going to make lists). I don't know about other distributions.
Which is the best e-mail package? (Score:2)
Thanks again. "Life with QMail" is astonishingly well-written.
However, open source software suffers from a high implementation cost. For example, here is a statement from "Life with QMail":
"For example, to run rblsmtpd under tcpserver, try something like: [script]"
I'm guessing that it would take maybe 50 hours to get started with QMail and EzMLM. So, realistically, it is a $3,000 package, or some amount like that.
Thanks again for the help. You've provided what's usually missing: top level help. I can handle the details once I choose what area needs to be handled.
Majordomo 2 (Score:1)
ezmlm (Score:1)
http://cr.yp.to/ezmlm.html [cr.yp.to]
Out of date? (Score:3, Interesting)
this book has been released back in 1998 (which is centuries ago in Internet time
maybe it's time for O'reilly to make a 2nd edition though...
Ricardo.
Re:Out of date? (Score:3, Interesting)
My playlist for MML2 would include mailman, majordomo2, listar, and ezmlm; greater discussion of non-sendmail MTAs (qmail, postfix, maybe exim), coverage of commercial options (running your own with lyris/listproc vs outsourcing vs. egroups.com approaches), and greater depth in terms of list policy, spam issues, legalities, and tips for specific kinds of lists (like opt-in marketing to established customers)
It was a thrill to see this on slashdot. :)
- Alan Schwartz (author of Managing Mailing Lists)
What about Listar? (Score:1)
Any mention of legal liability? (Score:2, Interesting)
More info (including the full text of the complaint) is available at http://216.168.47.67/psw/
The lawsuit is being brought by a merchant, against the list manager, and several list members. The list members had simply posted their negative comments about the quality (or lack thereof) of service they received from the merchant.
More useful than all the books on C? (Score:2)
"one whose subject probably would be useful to more people than books on any single programming language. "
I am guessing that this line comes from Timothy. Does he really think there are more people managing mailing lists than writing software in, for example, C? Bizzare!
Distribution only? (Score:1)
I think the features that are needed are:
- fast delivery/processing
- bounce detection/removal
- automatic unsubscribe facilities
Anybody know of any good distribution only lists?