Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

Mailing list management software FAQ

(MultiPage )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]
Archive-name: mail/list-admin/software-faq
Posting-Frequency: every 28 days
Version: 1.1 (last revised 1995/01/24 16:46:57)

See reader questions & answers on this topic! - Help others by sharing your knowledge
*This FAQ is in digest format. In rn and trn, ^G skips to the next section.*

                              C O N T E N T S

Part 0:  Administrivia

0.00  Copyright
0.01  Introduction

Part 1:  Do you really need an MLM?

1.00  Running your list without an MLM
1.01  Using someone else's MLM

Part 2:  Things to think about when choosing an MLM

2.00  What's your preferred software-design philosophy?
2.01  How much money, time, and expertise do you have?
2.02  Are you tied to a particular operating system?
2.03  Do you need to modify the MLM's source code?
2.04  Performance and system-load issues related to server activity
2.05  Performance and system-load issues related to mail delivery
2.06  Features and usability for administrators
2.07  Features and usability for users
2.08  Loop detection and elimination

Part 3:  Specifics per package

3.00  MLM's in general
3.01  Almanac [v. 1.5.1b]
3.02  BMW [v. 5.0]
3.03  IDG
3.04  ListProc, free version [v. 6.0c]
3.05  CREN ListProc [v. 7.1]
3.06  LISTSERV [v. 1.8a]
3.07  Mailbase
3.08  MAISER (part of the Mercury Mail Transport System) [v. 1.13]
3.09  Majordomo [v. 1.92]
3.10  MReply [v. 1.71]
3.11  MXSERV (MX/MLF, part of the Message Exchange system) [v. 4.1]
3.12  SmartList [v. 3.10]
3.13  Smof Listserver for DOS/KA9Q. [v. 05l]
3.14  TULP [v. 4.0.0]

Part 4:  Appendices

4.00  Where to get the current version of this FAQ
4.01  Changes in this version
4.02  Acknowledgements
4.03  Acronyms explained (FAQ, MLM, MTA, MUA)
4.04  URL's -- how to read them and use them

Subject: 0.00 Copyright The MAILING LIST MANAGEMENT SOFTWARE FAQ is copyright (c) 1994 and 1995 Norm Aleks <naleks@Library.UMMED.EDU> First-person singular pronouns used in this document refer to Norm Aleks. I grant you, the reader, permission to redistribute this document and to quote it in whole or in part, provided 1) that you make no charge for the copy OR for whatever the copy is included in, and 2) that you include an attribution with, at minimum, my name and e-mail address, the FAQ's revision date and version number, and at least two locations from which a current version may be retrieved (see Section 4.0) -- i.e., as is always the case when you quote someone else's work, you must use a footnote or its equivalent. For any other use, you must obtain my written permission. Here's a suitable reference for quotes from this version of the FAQ: Aleks N. <naleks@Library.UMMED.EDU>. _Mailing List Management Software FAQ_ (ver. 1.1, revised 1995/01/24 16:46:57). Published monthly on USENET in news.answers, comp.answers, and, and archived at URL "". (It's not really necessary to include the revision time -- you see it above only because I can't stop my revision-control software from showing it.)
Subject: 0.01 Introduction MAILING LIST MANAGEMENT SOFTWARE FAQ, v. 1.1 (1995/01/24 16:46:57) Perhaps you have a topic you're dying to discuss on your very own e-mail discussion list. Perhaps you need to set up a up a mailing list manager ("MLM") for others to use. In either case, you have many alternatives for managing mailing lists. This FAQ outlines some criteria that may be useful to you in deciding whether you need an MLM, and which one is right for you. It also includes listings of many available MLM's, along with pointers to where to get them and where to talk about them. About the examples used in this document: non-Unix software isn't covered well, I know -- but only out of ignorance, not because it shouldn't be covered. Representation in the examples is biased toward Majordomo, LISTSERV, and ListProc 6.0c, partly because they're popular and representative of several points I want to make, and partly because those are the systems I have administered :-). I spend a fair amount of time here talking about features and optimizations necessary for large lists, and that means I also talk a lot about the features available in LISTSERV and ListProc, the two very-high-end packages I know well. (Mailbase also falls into this category, I believe, but I don't have the right hardware for Mailbase so I've never managed it.) Think of feature discussions as a guide toward what to look for and think about, not as a "must-have" list. And finally, keep in mind what *you* need -- I talk about busy servers because they're interesting, but if you expect low activity, much of this discussion is irrelevant to you. Here are some ways I currently want to add to or change this FAQ: 1. Discuss various packages' support for languages besides English. 2. Talk more about what non-sysops can do to run lists. 3. Minimize the display of my own biases, which now are prominent. 4. Cleanly compare MLMs' feature lists, for "feature shoppers." 5. Talk about the facilities each package offers for spam control. 5. Collect all the "philosophy" issues into one section. Please send suggestions for additions or changes to naleks@Library.UMMED.EDU, and I will try to include them in the next version of the FAQ.
Subject: 1.00 Running your list without an MLM You don't need a mailing-list manager to run a mailing list -- some very low-tech solutions do just fine, especially if your subscribership is stable. If your list is moderated (i.e. you check that each message is appropriate before distributing it to the list), all you need to do is maintain a list of subscribers in your favorite e-mail program. When a message arrives, you forward it to the list. Two hints if you do take this route: If your mail program has a "bounce" function, you should use it -- that will preserve the "From:" header indicating who originally sent the message, listing your e-mail address as "Resent-From:", which is more appropriate. You also should consider putting your list of addressees on the "Bcc:" line rather than the "To:" line, so that if people reply to a message it comes back only to you, and not to the list (bypassing you and your moderation function). You can set up a fully automatic mail reflector, if you're on a Unix system running Sendmail, by using the Sendmail "alias" function (described well in _Sendmail_, the O'Reilly & Associates "bat book"). If your system administrator is willing to set up a special alias for your list, you can maintain the list simply by editing the file to which the alias points, and people sending mail to the alias will have their mail bounced out to the whole list. (Some systems include specific support for lists, i.e. DG/UX's use of a "lists" directory for aliases as noted by <>.) Be warned, though, that this approach has a lot of problems -- mailing loops are a distinct possibility, and there's absolutely no control over who can post to the list, or what they can post. If you must have automatic distribution of messages, you should look into using an MLM.
Subject: 1.01 Using someone else's MLM If your system isn't well connected or you're not the system administrator, you may be better off using the MLM on someone else's system. Alternatively, there are a few MLM's that can be installed and run on Unix systems without root access (though you'll always want a few new aliases set up, and the system administrator has to get involved in making those). Three packages that are designed to work well for non-root administrators are SmartList, MReply, and IDG; others may work well, too, and I will check on that more carefully for future versions of this FAQ. Many commercial services now provide MLM services to their subscribers. Using your provider's MLM, you don't need to worry about the system's care and feeding, or the heavy loads an MLM can generate (though many large lists do run well on small machines). Contact your provider for details. If your list is not for profit, you may find someone to host it on their MLM for free. If you're an academic in the U.K., the people at may be able to help you: read about Mailbase below, then write to its maintainers, telling them how many subscribers the list will have, how many messages you expect each day, and whether you will need any storage space for message archives or associated files. Outside the U.K., check with the large and friendly community of LISTSERV administrators on Subscribe to LSTSRV-L as described in the LISTSERV section below, then post a message asking (politely! and giving the same information as outlined for Mailbase) if anyone has the facilities and the interest to run your list for you. Both LISTSERV and Mailbase are built for remote administration, so if you have just an e-mail account this is a good way to go.
Subject: 2.00 What's your preferred software-design philosophy? One of two philosophies is behind any program's design: "big is beautiful" or "small is beautiful." AT&T's original design for Unix was "small is beautiful": small tools exist for every purpose, and they can be linked together in defined ways to accomplish most goals. On the other hand, Larry Wall designed Perl, a program many people now think of as an essential Unix tool, in the "big is beautiful" model: by combining features of sed, awk, C, and the shell, he came up with something he and others believe is more than the sum of its parts. Why should you care? Well, maybe you don't need to, but this "big vs. small" dichotomy goes a long way toward describing the differences between the available MLM's. Look at the differences between Majordomo and LISTSERV as examples of each approach, and see which appeals to you more. (TULP is probably an even better example than Majordomo, but I know Majordomo better and will therefore use it for this discussion.) When Brent Chapman originally wrote Majordomo, it was clearly a "small is beautiful" program. He had tried to compile and set up ListProc and gotten frustrated; he whipped together something in Perl that would do what he needed. What he needed, specifically, was something to automatically manage the addition and removal of subscriber names from his Sendmail alias lists. As Majordomo was originally written, maintaining the alias lists was the entire extent of its job -- *all* other work was handled by other programs. Majordomo has expanded considerably since then (certainly beyond Brent's original plans -- he has written that he thinks even the addition of file server functions was a mistake, as they can be served as well or better by dedicated archive servers), but the people working on it have tried to maintain its purity of vision. Majordomo tends to see most things in terms of Unix regular expressions and Sendmail alias lists: for example, the Majordomo equivalent of the LISTSERV "set digest" and "set nomail" commands (which cause a user's mail to be batched, or not to be sent) is simple: to stop getting mail, the user unsubscribes; to get digests, the user unsubscribes, then resubscribes to a separate digest list. This approach obviously has limits -- LISTSERV offers dozens of options, for example, and there can't be a list for each combination -- but that's OK, because Majordomo doesn't want to provide every option, it wants to manage lists and let other programs handle other jobs. Because Majordomo is relatively small and focused, it is comprehensible as a whole by many of the people who use it. This, along with its free source code, can explain much of its popularity. LISTSERV, on the other hand, is the MLM poster child for "big is beautiful" programs. As its users needed more features for various functions, Eric Thomas added them to LISTSERV; his program attempts to satisfy every need a mailing-list subscriber could have, and it does it in a fairly integrated way. However, LISTSERV and kin (primarily ListProc and Mailbase) are more complex programs than the simple MLM's like Majordomo and TULP.
Subject: 2.01 How much money, time, and expertise do you have? LISTSERV and CREN ListProc are commercial products, licensed by the year (more or less -- each has several licensing plans and you should contact their vendors for details). In exchange for your money you get a product that's stable, documented, and pretty simple to set up, with paid support people to help you out if you get into trouble. The other MLM's are free, with varying levels of support from their users and maintainers. Each package has a mailing list for users, on which you can ask questions like "digesting doesn't work, what do I do?" Many people are satisfied with this sort of support; you may or may not be. Talk to current users of each package you're considering to get a feel for whether you're comfortable with its combination of administrative burden and software cost.
Subject: 2.02 Are you tied to a particular operating system? [This section, obviously, is under development. Help me out, please] A frequent question about MLM's is "Can I run one on my Mac?" Or, "What's available for a PC?" Or, "How about Brand X Unix?" Here are some listings of what's available by platform. For information on where to find them, etc., see the more detailed references at the end of the FAQ. (asbestos shorts time) To me, MLM's for Mac-OS and DOS are like piano-playing poodles -- I'm reluctant to evaluate them in terms of performance because it's remarkable that they work at all. In the first place, both OS's crash too much to make good servers; in the second, their multitasking is weak or non-existent. But if you have very limited needs for an MLM and you absolutely don't want to deal with a new operating system -- and that certainly is a legitimate concern -- check out these packages: for DOS, the "Smof Listserver"; for the Mac, MailShare (which, while not an MLM proper, is said to provide MLM functions -- check, I haven't seen it myself). Peter Lewis, who has written several Mac TCP/IP programs, is supposed to be working on a new Mac MLM as well, which will be nice to see. If you have a NetWare server, you may want to check out the Mercury Mail Transport System, which includes an MLM called MAISER. If you just want to run your MLM on PC hardware, you have many choices. The easiest thing is to run Unix on your PC -- Linux (which is free), BSDi, SCO, Solaris, and NeXT are some of your choices. Once you run Unix, you can run most of the packages on this list. Alternatively, you can run Windows NT, for which LISTSERV is available and ListProc support has been pre-announced. OS/2 is a solid operating system and should also be an option, but I don't know of any MLM's running under it. Please write me if you do. If you have a bizarre flavor of Unix, there's still a good chance that SmartList will run on it, out of the box. If not, the two Perl packages (Majordomo and BMW) shouldn't be too hard to port if you have Perl and Sendmail available. On IBM mainframes, your choice is LISTSERV, which runs only under VM/CMS. Under VMS, you have a choice between LISTSERV, MX, and PMDF Mailserv (sold by Innosoft, but about which I know nothing more -- someone, please fill me in).
Subject: 2.03 Do you need to modify the MLM's source code? If you have specific needs not handled in the packages described here, you may want to modify an available package's source code. You may even want to write your own MLM, in which case we'll add an entry to this list :-). Almanac, BMW, Majordomo, MReply, SmartList, and TULP come with source that's free to modify. ListProc 6.0c comes with source, but there are restrictions on what you can modify, AND you're not allowed to distribute your changes -- this means that, except for bug fixes released by its author, the free version of ListProc will develop no further. CREN ListProc, LISTSERV, Mailbase, Mercury MAISER, MX, and Smof come as binaries only, although ListProc, LISTSERV, and Mailbase each include strategic hooks for shell scripts, allowing you to modify the system's behavior. Of the systems for which you get source code, Almanac, ListProc 6.0c, MReply, and TULP are written in C (with some shell scripts in ListProc and one optional Perl script in TULP), BMW and Majordomo are written in Perl (one C routine in Majordomo), and SmartList is written in a mixture of C, shell scripts, and Procmail's rule-processing language, and IDG is written in the Korn shell.
Subject: 2.04 Performance and system-load issues related to server activity The system load an MLM imposes is affected by how it organizes its work in command processing. Just about any method is OK if your MLM isn't going to have much activity (in both postings and server requests), but when you get into bigger systems the MLM's efficiency turns into a real concern. "Big," here, means a server processing dozens of messages, tens of thousands of recipients, hundreds of requests -- numbers like that, or bigger. Really big LISTSERV systems, for example (I use them as an example because their statistics are posted monthly on LSTSRV-L) may send out an average of half a million messages a day, meaning they may do a million on a busy day. A decent guideline for evaluating an MLM's potential load on your system is, how many processes does it start under light, moderate, and heavy loads? Let's look first at the minimum load imposed by each Majordomo, SmartList, ListProc, LISTSERV, and TULP, and then at what happens when they're busy. "Low load": Majordomo and SmartList are started by Sendmail only when a message arrives, so that in a baseline state they occupies no resources at all. ListProc, LISTSERV, and TULP each keep a server daemon running at all times, so that even idle they increase the baseline load on your system by some amount (the penalty is mostly in swap space). "Heavy load": the tables turn. Majordomo starts up a Perl process, and possibly a couple of Sendmail processes, for every message that arrives. Because Perl is interpreted, and because each new Majordomo and Sendmail process must interpret its configuration files from scratch, there is substantial overhead involved in processing each message. There is no mechanism to serialize requests, either: if several messages come in at once, Sendmail fires up an independent Majordomo for each one, and the load multiplies -- even more so because the independent Majordomos don't organize to manage file locks, and many of them will sit around for a while (occupying system resources) as they wait for some other process to release a lock. In a message onslaught, your poor system will start to thrash, and you'll be distressed :-). SmartList starts up a Procmail process, and possibly a couple of Sendmail processes, for each message that arrives. Although Procmail also uses an interpreted language and like Majordomo needs to read its configuration files from scratch, SmartList has a lower impact on system resources because the Procmail interpreter is smaller and (for its job) more efficient than Perl. SmartList, by default, handles list submissions in parallel and administrative requests serially per mailing list, or per arbitrary group of mailing lists. In contrast to Majordomo and SmartList, the ListProc, LISTSERV, and TULP daemons serialize all requests without multiplying. Your outgoing mail queue may build up, but even that's not a problem in most cases because Sendmail (or any other MTA you may use) can be configured to queue mail when the system is heavily loaded. As a final optimization, LISTSERV even maintains an open connection to your system's port 25 for delivery of outgoing mail; its assumption is that requests will come in fairly regularly, and that the average load of maintaining an open Sendmail process is less than that of starting one, then tearing it down for each new request that arrives. The bottom line with a daemon-running MLM is that there is a decreased load on busy systems, and an increased load for lightly-used systems, but the biggest benefit is that the load is *predictable*. Of course, just looking at process count is simplistic, but it gives you an idea of the things the higher-end MLM's do to reduce system load. When you get into really big lists, other features start to make a difference. As another small example, without getting too deep into these issues (salespeople can do that if you're running a gigantic server): LISTSERV maintains hashed indices to all of its lists so that it can guarantee quick name lookups even on very large lists. Think: when a list has 25,000 subscribers, even a grep through it takes a non-trivial time, and that database of names needs to be checked *every* time a request comes in. If you're running a list with a LOT of activity (say, as some people have, you visualize tens of thousands of people subscribing within a single day), you can't afford to have a single subscription taking more than a second or two of CPU time, in total. The point is, if you are going to run big lists, it's worth your while to check out what each system does to manage it efficiently. Most approaches don't scale well, when pressed.
Subject: 2.05 Performance and system-load issues related to mail delivery The main issue in distributing to large lists is, how quickly can you get the mail out? Most MLM's leave routing and optimization decisions up to the MTA (Mail Transport Agent, usually Sendmail under Unix), but some other systems -- notably ListProc, LISTSERV, and SmartList -- take a more active approach in managing network load. To illustrate, let's look at the path mail takes to delivery in each of these four systems. Majordomo (a good example of the "leave-it-to-Sendmail" model), once it decides to forward a message to a list, passes it to a single Sendmail process along with the addresses for the entire list. Sendmail then does what it can to optimize delivery (i.e. sorting by MX record), and starts connecting to each machine in series. The result on a 200-subscriber list, with everyone in the U.S. and most with different mail exchangers, is that there's about an hour's delay between the first delivery and the last. This delay is dependent more on the speed of the recipient machines than on the speed of the host or the network link, so it varies pretty much linearly with the number of systems Sendmail has to connect to. This can be a big problem on a large and active list, because people late in the delivery queue will see and reply to "new" messages that others have seen (and perhaps replied to) several hours before -- conversations will get "out of sync." On the other hand, much longer delays might not matter for a list that consisted only of infrequent announcements, without discussion. ListProc speeds up the delivery process for large lists by passing each message off to your MTA (usually Sendmail, but ListProc doesn't care, it just connects to port 25 with SMTP) in chunks of N addresses, where N is defineable. Depending on how the MTA is configured, delivery will usually be faster because deliveries are parallelized -- the longest list is of size N. However, Sendmail can't optimize deliveries as much, because no particular Sendmail process has the entire list to work with. Thus network efficiency can go down (not actually a big problem, because ListProc produces "chunks" sorted by domain). Also, the peak load on your system increases because several Sendmails are running at once. (To avoid extreme loads on your system, ListProc can be configured to wait some number of seconds every X addresses -- this gives Sendmail a breather. Note that CREN recommends that Zmailer be used as the MTA for large lists; Zmailer does more flexible and efficient queueing than Sendmail's, eliminating many of these problems.) SmartList uses a method similar to ListProc's, splitting up the address list into chunks of a configurable size before passing them to the MTA (via the command line, not by port 25). However, it goes one better in that instead of simply controlling the number of addresses per chunk, SmartList lets the system administrator control maximum and minimum sizes per chunk, thus letting SmartList attempt to make "smart" choices about breaks between the chunks -- e.g. it would try to avoid breaking apart a group of addresses within a domain. Also, instead of simply specifying "send this many addresses and wait," with SmartList the administrator can specify, per list, the maximum number of MTA processes that should run simultaneously, thus managing the load-vs.-speed issues more directly. Finally, LISTSERV uses a specialized "distribute" routine (described briefly in RFC1429) that takes advantage of the cooperation of LISTSERV systems around the world. First, it sends copies of the message to all "local" subscribers, connecting to your MTA through port 25 as ListProc does. Then, it scans the list to find recipients who are in other LISTSERV sites' local areas, and it passes all those addresses, with a single copy of the message, to the nearest LISTSERV core site, which assures delivery with no further involvement by your system. Finally, it takes the "leftover" addresses -- the ones it couldn't recognize as "belonging" to any particular LISTSERV site -- and delivers them as if they were local. ("Local" deliveries, passed to your own MTA, are batched using the same method as ListProc.) Especially when LISTSERV can map many of your subscribers to other LISTSERV territories (it works best with non-U.S. and .edu addresses), and if many of those subscribers are across slow or expensive links from you, this can result in very high efficiency -- for example, a U.S. message destined for 1000 European users on different hosts would cross the Atlantic just once and then "fan out." Thus, DISTRIBUTE can both reduce network load and make it possible for small machines to handle large lists -- it can also result in high speed delivery, because in the best case more than 100 servers will work on your job simultaneously. However, it helps less for lists with few distant users, and it also results in each site taking on local deliveries for others, thus increasing the local delivery load. Why doesn't everyone use DISTRIBUTE, you might ask. There are a few reasons. A big one is that it currently runs only on LISTSERV, and many people associate that with BITNET and big IBM iron (distasteful to many Unix natives). Another reason is that DISTRIBUTE isn't an *ideal* solution to mass mailings on the Internet -- it's a BITNET tool that's been moved over and works pretty well, but not ideally. The big problem is that DISTRIBUTE computes routes using static tables (updated periodically by L-Soft). This is a fine method on BITNET, where network topology is known and stable, but not perfect for the Dynamic Internet(tm). You just can't get any granularity with a static table when things are always changing around you -- in fact, *any* centralized database will be a hassle. This problem was recognized a long time ago in relation to Internet host names, and the solution was the Domain Name System. The DNS is likely to play a big part in the ideal mail-distribution system, as well: there has been talk of extending the MX-record system with a bulk-mail-recipient record, but nothing definitive has been proposed. The bottom line for now is that someday, whether it's another proprietary system or it's a new Internet standard, something will replace DISTRIBUTE ... but for now it's the most efficient, widely used mass-mailing distribution system out there. If you're willing to do the work to coordinate with other people, you can set your list up with something like DISTRIBUTE on a custom basis. Just arrange for "exploder" MLM's in appropriate places (that is, across slow or expensive links and centered in a group of subscribers), and send mail to each of these exploders as part of your mail job. They will then distribute to their own people, and you'll get the network efficiency of DISTRIBUTE plus parallelized delivery -- a nice deal! The problem is that you have to make sure everyone is subscribed at the correct site, but with a disciplined subscribership it can work. (LISTSERV actually supports this arrangement as well, as a holdover from pre-DISTRIBUTE days -- the various lists are considered to be "peered," and on request the system allocates users among the servers based on network proximity and system load.)
Subject: 2.06 Features and usability for administrators Administrator load is affected by how many decisions the MLM can make on its own using administrator guidelines, and by how much "required feedback" it gives the administrator. It is also affected by how well the MLM supports subscribers, of course; if they're confused, they'll ask the system administrator or list owner for help -- but that's treated in the next section. Finally, there are some basic functions, usually invisible, the MLM should provide to prepare mail for widespread distribution and to protect users from others who try to impersonate them. Do you want to be told each time a user subscribes or unsubscribes to a list? How about when a password fails? How about when a user makes a mistake? Some systems make these choices configurable on a list-by-list basis. If your site is busy, this can save you a lot of "useless" mail; if it's not, you may want to hear about everything. As your lists grow, interpreting delivery failures will occupy more and more of your time. Some systems automatically interpret delivery error messages to, say, automatically remove the address of a cancelled account, and this certainly can save you time. Don't expect miracles, though: none of these systems is perfect, mostly because of the wide variety of error messages returned by MTA's. LISTSERV and ListProc include an error-interpretation capability in their base distribution; each tries to distinguish between "permanent" failures and "non-permanent" failures, removing a user only after a permanent failure (account closed, etc.). Majordomo's approach, out of the box, is a "bounce" script the administrator can run upon receiving error mail, which removes the address in question from the main list and adds it to a list called "bounces," which is then sent periodic "you've been bounced" notes. (A new Majordomo script is being developed which will work in somewhat the same way as LISTSERV's and ListProc's bad-address function.) SmartList's delivery-error routines are the most sophisticated: When it receives a bounce message, it first attempts to decide (as LISTSERV and ListProc do) whether the bounce is temporary or permanent. Then, it passes the error message through several increasingly fuzzy filters, trying to find the address that was the problem (a difficult task even for a human). If it does find the address, SmartList increments a counter for that address's total consecutive bounces; when the count exceeds some threshold defined by the administrator, the address is unsubscribed (unless SmartList wasn't "sure" about the address, in which case it will merely inform the administrator). One bounce before the unsubscribe threshold, SmartList attempts to send a final warning to the subscriber, including the text of the bounce error message. If you plan to have your lists administered by people who don't have accounts on your system, you will want a system that is easy to configure by mail. LISTSERV is probably the easiest in this regard; it uses a single "list header" file that contains subscriber addresses plus some control keywords, most of which are optional. CREN ListProc is pretty good too, though its use of separate commands to set each option makes it more difficult to get an overview of the list's setup. Mailbase is supposed to be quite good, but I haven't tried it. Majordomo 1.9 is also very good; its configuration file, which always lists all options, can be forbidding to a novice list owner but always reminds you of what's available. SmartList and MReply both include facilities for administration by users who *do* have shell accounts on your system; other programs and the older versions of ListProc (6.0c and back) and Majordomo (1.62 and back) can't satisfactorily be configured by list owners, but require the involvement of the system administrator. When mail is forwarded to a list, some headers shouldn't be included -- one example is the "Return-receipt-to:" header, which if distributed to the list can result in an overwhelming flood of automated responses to the sender's system. There are two main approaches to sanitizing the headers: excluding known dangerous headers, and passing only known safe headers. Majordomo uses the forbidden-headers approach, stripping them in its "resend" routine. ListProc uses the opposite approach, passing only the headers it knows and stripping the rest. Both can have their criteria modified by the system administrator; such changes are system-wide. (By the way, ListProc 6.0c has a problem with MIME no matter how it's configured: it passes only the first line of a "MIME-Version:" header, thus trashing complex MIME documents. CREN ListProc fixes this.) SmartList lets you choose either approach, on a list-by-list basis. LISTSERV also lets you use either approach, but on a per subscription basis, with the list owner choosing the list default. It does this by offering four types of message headers selectable by the subscriber: "Short" headers are like ListProc's; "Full" headers are like Majordomo's; "IETF" headers are the absolutely unmodified originals, with nothing stripped; and "Dual" headers are for users of rotten PC MUA's that don't show headers (they result in a "Short" RFC822 header, followed by a message body repeat of the most important header information). Sometimes the MLM needs to be sure the person sending it a command is truly who he or she says. Forging mail is trivial, so the From: line really can't be trusted -- even so it's the only identification most MLM's require. Three exceptions: 1. ListProc 6.0c uses the envelope "From_" line, which is annoyingly different (the distribution does include a patch to make it use "From:" like everyone else). 2. Majordomo lets a sender reset his or her identity by using the "Reply-To:" header -- after all, if forging is so easy, why not make legitimate use easier? (This may sound scary, but it can save you a lot of hassle when people subscribe from one address then move to another -- if they understand Majordomo, they don't have to get the list owner involved in changing addresses.) 3. SmartList reads *all* the sender fields, including "From_", "From:", "Sender:", "Reply-To:", and the signature text if any, then chooses one based on the needs of the operation at hand. For low-security jobs like message posting, MLM's usually just accept the "From:" line and cross their fingers. If more security is needed (for example for a command that shuts down the server, or unsubscribes someone, etc.), there are four general ways an MLM can provide it. 1. lowest security, and most common: the MLM can send a message back to the "sender" confirming the command. If the mail was forged, the confirmation will still go to the person on whose behalf the message was processed, and the command can be reversed (we hope). 2. higher security: a password can be required in the command message. Majordomo requires this, for example, when processing list-owner commands -- in fact, Majordomo trusts *only* the password, accepting it in combination with any From: address. 3. A confirmation message with a magic cookie can be sent from the server, requiring a response with the same cookie before the command will be executed. LISTSERV does this as an optional alternative to passwords, or, if set by the list owner, when someone first subscribes to a list (the idea is that the dialog between the server and the new subscriber proves that the mail connection works). 4. highest security, and I don't think anyone is doing this yet: encrypted signatures could be required on request mail. People are currently working on integrating PGP signatures into Majordomo; it will be interesting to see how this works out.
Subject: 2.07 Features and usability for users MLM's are basically low-tech communication tools. Sure, they can accomplish lofty goals, but one of the biggest reasons they get used is that e-mail is the closest thing to ubiquitous that we have on the Internet. People who feel uncomfortable and intimidated with everything else, feel just fine using e-mail to write messages to their loved ones :-). So, an MLM should make life EASY for users. It should be tolerant of their mistakes, and of their mailers' mistakes (yes, many people aren't using perfect mail systems). Its error messages, when necessary, should not only be friendly but should also suggest to the user what to do next. It should be flexible enough to give users on different sorts of systems, with different sorts of reading styles, their list mail in the format they need. And while it should be simple as a telephone, for the computerphobes, it should also provide services to let more advanced users save time and take advantage of the information resources your lists will generate. The first thing a user needs to do is to get commands to the server, usually by mail. Well, some subscribers will have broken mailers. Perhaps they won't be able to control their subject line, or every message they send will have a huge memo-like thing at the top of the message body with date and organization name, or the message body will always be indented, etc., etc. There is no end to the perverted mail gateways out there. If you get one of these people trying to subscribe to your list, will your software be able to handle it? Specifically: ListProc and Mailbase, in their default setups, stop reading a message upon the first error ... thus people whose mailers include a fancy header in the body are out of luck; Majordomo stops reading commands at the first line that starts with at least two hyphens "--", thus people whose fancy headers include that line are out of luck. To work around these problems: ListProc can be set to ignore errors (which has negative consequences, like causing mail *entirely* in error to be ignored entirely -- but it does let the server read past these "stationery" headers). Majordomo's code can be hacked, if necessary, although the "--" is part of its loop detection system, and removing it opens up possibilities for some new problems. I'm not sure what could be done with Mailbase, since it doesn't come with source. To see an MLM gracefully handle bad mailers, look at LISTSERV: it reads up to 20 error lines before rejecting a message, usually enough to get past the fancy headers. If 20 lines isn't enough, it also includes a specific command for saying "this is the start of the job," before which everything will be ignored. (Note that this simple command *completely* solves the problem. Johan Vromans's excellent "Squirrel" archive server has a similar function -- but in most MLM's, only an "end processing" command is available. That's useful, but only half the solution.) Of course, some users get lost a little earlier -- they can't figure out which address to send mail to :-). But truly, it's not an easy decision. There is, to date, no standard address to which users should send commands: manually-maintained Unix lists typically use "listname" for the list, and "listname-request" for a human being who takes care of it; automated servers have all kept the "listname" address for the list, but use unique addresses for the server: LISTSERV uses "LISTSERV"; Majordomo uses "majordomo"; ListProc uses "listproc"; Almanac uses "almanac"; etc. Why should users have to know which server you're running? Chances are it's just a name to them anyway. So, there's been some move toward standardization of these addresses, but unfortunately it seems not to be getting better: SmartList takes its commands at "listname-request" (emulating the manual-list model), but has no "smartlist" address; LISTSERV has created a new, generic address at which it takes commands -- "listname-server" -- but has reserved "listname-request" for reaching the list owner directly; Majordomo and MX accept commands at a server address as well as "listname-request," but don't recognize "listname-server," and so on. A standardized addressing system would be very useful, there's no doubt. Everyone has their own opinion on what the best choice would be, and I have mine, but most of all I would like to see the MLMs' writers agree on *some* standard. Just my opinion -- but it certainly would help the end users. Ignorance is sometimes not an excuse, though: some users are just clueless. No matter how many reminder notes you send out, people send "subscribe," "unsubscribe," etc. to the list address rather than to the server. Your MLM should catch and bounce these bogus messages, rather than delivering them to the list -- this protects the sender from embarrassment, and the other members of the list from stupid mail. Many MLM's do this (in TULP it's via an optionally-installed Perl script); some are better than others. Majordomo has a kind of "hair-trigger" filter that results in many false positives, usually when the message has the word "help" in the first few lines, but it does manage to stop most administrative messages from reaching the list. The bounces go to the list owner instead of to the sender, which can be a pain. ListProc, LISTSERV, and SmartList have aggressive and fairly selective filters that trap common commands and their misspellings in either the subject line or the message body. Both ListProc and LISTSERV, by default, return the bounced message to its sender -- a blessing for the owner and instant feedback for the sender. SmartList, by default, executes the command if it can decipher it. (It can also be configured to return the mail to the sender, a choice that is yours to make. While some say it's best to accomodate the users' foibles, others say that if users are accomodated when sending commands to the list, they will never learn not to -- and eventually they will send a command that won't be caught, annoying everyone.) So the user has gotten mail to the server -- now the server needs to write back, both with responses to commands, and with list mail. Do problems show up here? You bet. Of the many bad Internet mail gateways, one particularly bad specimen is associated with Microsoft Mail. Because MS Mail only supports one "from" address, while RFC822/821-based mailers support at least two ("envelope sender" and "message sender", aka "From_" and "From:"), the MS Mail gateway simply throws one away as mail arrives. The address Microsoft has chosen to keep is the "envelope from", to which delivery errors are normally sent, instead of the "message from," which is usually the address of the person who wrote the message. The result is that Microsoft Mail people often reply to the delivery-errors mailbox on your MLM, not to the server or the message originator. Quite annoying. (Other e-mail systems do this too, I'm just using Microsoft Mail as an example.) One way to the fix this situation is to change the address your MLM puts into the "envelope from" line to point back to the list (a configuration many allow, though it violates RFC822). However, this removes one level of loop prevention -- in simpler MLM's, the only level -- so it may open you up to new and interesting mailing loops. Another solution is to include the relevant information in the message *body*, where the MS Mail gateway can't wreck it. That's the purpose, in LISTSERV, of the "dual headers" option ("SET listname DUAL" -- see the paragraph on headers in the previous section) -- an ugly, but useful, workaround. The point I'm making is that even a low-tech tool like e-mail isn't quite as universal as you might think -- there are some things to think about if you want to shoot for universal access. Many people out there sit behind an Internet-unfriendly gateway, and you have to decide *before* you commit to an MLM whether you want to support those unfortunates. If you know you'll be dealing only with good mailers, or you're willing to deal with the occasional problem by hand, you can do whatever you want. But if your entire user base is on PROFS or Microsoft Mail, be careful and do a lot of testing. OK, now the user is connected to your MLM both to send commands and to get feedback. At this point, he or she needs to work with the MLM's command set. If your users are already used to a particular system -- say, Majordomo, LISTSERV, Mailbase, or manually-maintained "-request" lists -- you have a strong motive to use the same system or one that emulates its command set. For example, TULP is made to emulate LISTSERV, and while it has a more limited feature set, what it does do acts much the same. ListProc similarly originated as a "Unix LISTSERV," but it has diverged over the years; it now has a command set that feels "comfortable but different" to LISTSERV users. If your users are used to manually-maintained lists, you probably should consider SmartList, which does the best job of adapting to the habits they will have developed. Try to put yourself in the user's shoes: how easy is the system to use, overall? A selfish motive for asking this question is that an easier system may mean fewer questions for you. Are error messages clear? How about user and list-owner documentation? For example, ListProc 6.0c's documentation and help files are famously bad (though the CREN version's is much better; they are taking some care with it). On the other hand, LISTSERV and Mailbase are known for command structures and error reports that are comprehensible to novices. Talk to people who already use the system you plan to install. ONLY when you have people CONNECTED TO and COMFORTABLE WITH your system does it matter whether it has feature X or feature Y. That said :-), here are some specific features your users may find useful: * mailing methods other than separated messages (digest, index, no-mail). Digests can be useful for very active lists when subscribers would rather get one message summarizing the day's (or the week's) activity, either because they don't want lots of messages cluttering their mailbox or because they pay by the message; indexes are a LISTSERV extension of this idea, where only information about the day's subjects and authors is sent, along with information on how to retrieve the messages from the archives. Majordomo handles digesting with an optionally-installed digest script, and it treats the digest as a separate list that users can subscribe to (possibly in addition to the regular list); SmartList's digesting works with separate lists, much the same as Majordomo's, except that no additional script needs to be installed; LISTSERV and ListProc do digesting "out of the box" as an option each user can set as he or she chooses (i.e. "SET listname DIGEST"). * archive delivery and search features (GET, etc.). Just about every package includes simple "get" and "file index" facilities. Some go beyond that: Majordomo can be linked to an ftp-by-mail server, which can then get quite sophisticated. ListProc, in addition to basic GET, does automatic splitting and uuencoding of large files. LISTSERV supports those formats plus several others, at the user's request. SmartList, if Metamail is installed on your system, will use it to provide full and automatic MIME support, including uuencoding and base64 coding. To be honest, though, these systems really don't differ much on basic file delivery: all do the job, but none is a meant as an archive server. If archive service is what you need, you should read Piero Serini's "Archive Server FAQ", at <>. LISTSERV and CREN ListProc offer a "file subscription" service, where users can elect to be told when a particular file changes, and optionally to have it delivered at that time. One sophisticated feature that truly *can* be of great use to your list's subscribers is archive searching, available in ListProc, LISTSERV, SmartList, and (in a limited form) Smof. The idea is, someone reading your list of policy announcements knows that in 1991 there was a message about "eating papayas on the job," and they want to find it. Rather than retrieving all the archives for that year, they ask the MLM to search them for the word "papaya." In ListProc the command is "search policy 'papaya'", where "policy" is the name of the list. ListProc then returns a simple "grep" of its archive, giving you the lines that matched your pattern along with the file names they're from. With SmartList, you'd send mail to "policy-request" with a subject or message body of "archive search papaya", "archive find papaya", or a few other synonyms. SmartList returns the matching filenames, line numbers, and total lines, up to some list-owner specified limit (to protect users from searches that retrieve enormous amounts of information). Smof lets you use standard "dir" and "get" commands with a parameter indicating "search header field X for word Y," so it's less flexible than the others (though still useful). In LISTSERV, finally, the command message is very complicated, and I won't even show it here: most people keep a search template in their inbox, editing it whenever they need to do a search (quite a change from the simplicity of most LISTSERV commands). There is some return on its complexity: LISTSERV's output can be individual messages, an index, or just about anything else you'd expect from a full-text database. It even does fuzzy matching ("sounds like"). But ah, it surely is complex. * access through methods other than e-mail. Putting message archives up for ftp access is trivial. ListProc also offers an "Interactive ListProcessor" client for telnet-like connections to the server; CREN is working on enhancing this with Mac, Windows, and X clients. LISTSERV, in its VM version, has a Gopher interface to its archives. Mailbase has both Gopher and native WWW interfaces. Various people have written hacks to interface practically every other package (including ListProc) to Gopher and WWW. One available package that stands out for its power and ease isn't even produced by the writers of an MLM. Logika's "InfoMagnet" (for Windows and OS/2: get it at <>) works only with LISTSERV lists, but in that range it lets you, in a pretty Windows interface, search for interesting lists, subscribe to them, change your subscription options, and search the list archives -- all without ever sending a single LISTSERV command (that is, InfoMagnet sends them for you). It even lets you set up "magazines" for individuals or organizations, for which it runs daily searches and has LISTSERV mail to you only the "interesting" messages. Nice.
Subject: 2.08 Loop detection and elimination One of the worst things that can happen to your list is to have a mailing loop develop. Especially when they involve big lists, loops are a huge waste of time and also terribly embarrassing for you as an administrator. By definition, they happen when two servers start sending mail to each other, neither realizing the other is a machine, and while that's bad enough, when it's on a mailing list a whole bunch of "innocents" get to listen in on the exchange. The most typical offenders in mailing loops are mail-to-news gateways, mail hosts that send error messages helter skelter, vacation programs that reply "I'm away" to *everything* that arrives, and other MLM's. If everything is set up "right," mailing loops never should happen. "Right" means that the headers of list mail are generated correctly (precedence "bulk", for example, stops many vacation programs from replying), that the errors-to address for list mail points somewhere besides the list submission address, and several other points that are better covered elsewhere. No matter how well *your* MLM sets things up, though, some misconfigured system elsewhere can always return mail to you in a way that provokes a loop. In this situation, detecting and stopping the loop *immediately* is paramount. Mail-to-news gateways and linked mailing lists are a special case in terms of the looping problems they generate. The concept isn't difficult, but gateways open up whole new possibilities for bad days -- you can get systems that don't respond with the correct error messages, or local mail-to-news gateways whose territories overlap, or two systems each stripping the markers the other had put in for loop detection, or, or, or ... If you plan to gate your mailing list to USENET, look *very hard* at the facilities each MLM offers for detecting and eliminating mailing loops. ListProc and LISTSERV are currently the best at this function, and SmartList offers good facilities as well; it could be added to any of the source-provided packages, and you'd be doing us all a service :-). The basic strategy used by both ListProc and LISTSERV is to maintain a cache of recent messages they've delivered (say, the past several hundred or thousand messages), in which they store both the Message-ID field and a checksum created from the message body excluding white space. They then will refuse later messages that generate the same checksum or have the same Message-ID header. SmartList also runs a cache, but keeps in it only the Message-ID header. (A ListProc FAQ which I will briefly answer here is: ListProc 6.0c calculates its checksums using the Unix "sum" program, which often results in non-unique numbers, and thus false positives on the test. A patch is available for the server so that it uses the much more effective MD5 checksum system, and you should apply that patch if you use ListProc 6.0c.) All three MLM's add headers of their own to each message, then check for such headers when a new message arrives (if they're found, that's good evidence of a loop). They also check subject lines and senders to avoid common goofs: i.e. they refuse postings from any user named "listproc" or "listserv" because that's almost certainly a server, and they also recognize that subject lines starting with "Delivery delayed:" are worth suspicion. ListProc and LISTSERV go a few steps farther, scanning the message body for common signs of re-posting (a second From: or Message-ID: line, for example), and doing other tricks the authors consider proprietary and won't reveal :-) When a duplicate message is found, ListProc and SmartList forward it to the list owner. CREN ListProc, as it does so, also calculates a checksum on the error report it's forwarding (excluding the attached message text, if any), so that if the list owner's MTA bounces the message a secondary loop can be avoided. LISTSERV returns the duplicate to the sender, with a note on why it's being returned and how to change the text if it is in fact legitimate. With LISTSERV's strategy, which was designed for the list owner's convenience, new loops can (and do) develop between it and other servers. However, they're invisible to the list and they're always limited: LISTSERV "serves off" (ignores) any address that generates ten error mails in a row, thus breaking the loop on its tenth iteration. When all other strategies fail, the final damage-control step in both ListProc and LISTSERV is to count and limit the messages that can be distributed per list, per day. Most list owners set the limit around 50 on LISTSERV, so 50's the maximum number of bogus messages that can go out to your list (!). If you get a bad loop, and they are rare, the *final* step for you to take is: post a copy of the loop's result to the relevant MLM's support list, with a message saying "what happened?" You will either find out that there is something you can do to avoid the loop in the future, or you will see that the next version of the software has been enhanced to detect it :-) With ListProc, if the problem was that the server didn't recognize a mailer address or returned-message subject, you can also edit its configuration file to add items to the list of checks, thus protecting yourself until the new and improved version arrives.
Subject: 3.00 MLM's in general MLM's in general are discussed on; to subscribe, write "sub list-managers YourAddress" in the body of a message to On USENET, and its sibling c.m.l.policy will probably interest you. Both get fairly low traffic and, for USENET at least, fairly low noise. You will also probably enjoy comp.mail.misc and, if your system uses sendmail, comp.mail.sendmail. MLM functions overlap with those of archive servers, though no single package is really excellent at both jobs. If archive service is a large part of your needs, you should also read Piero Serini's "Mail Archive Server Software List," at <>.
Subject: 3.01 Almanac [v. 1.5.1b] Date: 17 Oct 94 [More information is needed about Almanac. Please write me if you're knowledgeable.] Source code is available at <> To subscribe to the Almanac discussion list, write "subscribe alm-core-mg" in the body of a message to
Subject: 3.02 BMW [v. 5.0] Date: 28 Nov 94 The Black Marble Wombat is a simple MLM written in Perl. It was developed by Clay Luther of Monsta Incorporated <> to run some lists on gaming. The software is available free under the GNU license. Unusually, digests are requested through a separate subscribe command (called DIGEST, logically enough). Subscribing to a list digest simultaneously unsubscribes a user from the regular list; to unsubscribe once he or she is on the digest list, the user uses the UNDIGEST command. BMW optionally archives messages on a monthly basis. Beyond that, BMW is pretty minimalist: available user features are automatic subscription and unsubscription, archive sending and listing, and list review. Pick BMW up at <>.
Subject: 3.03 IDG Date: 21 Jan 95 IDG stands for "Internet Discussion Group," a package written to support a discussion list for the California Department of Transportation. Its most outstanding feature is that it requires only a single address, so that it can run from a single, "normal" account. IDG commands are sent in the subject line of a message; if the system decides any given message is not a command, it forwards it to the list. This can be seen as an advantage, in that list subscribers need remember only a single address; it also can be seen as a disadvantage in that many subscribers are going to mis-form or mis-spell their commands, thus causing IDG to send bogus messages to the list. IDG is feature-rich, though probably not suitable for large lists. Besides "subscribe" and "unsubscribe," it supports "get," "put," and "rm" by general users (maintaining knowledge of which subscriber "owns" each file, for purposes of allowing and disallowing its deletion or change -- though IDG's subscriber authentication is pretty low security), as well as "grep" for searching the database of files. It offers daily-digest-format delivery. It also supports two functions that, to my knowledge, are unique among MLM's. With "filter" (similar to the LISTSERV "set topics" command, but more general purpose), each subscriber can define a list of keywords which IDG will then use to determine which messages should be forwarded to him or her -- that is, if one of the subscriber's "filter" keywords is found in a new message's header or body, IDG will send it to that subscriber; if it isn't, IDG won't. (This function, while probably very useful, would be a resource hog on big lists: it requires greping each message once for every subscriber who has a filter set.) IDG also offers a simple, built-in vote management function: once the list administrator initializes a voting session, subscribers use the "vote" command to cast their ballots "yes" or "no." IDG tallies the votes as it receives them, returning to each voter the status of the vote to date. To try out IDG, send mail to <> with a subject line of "help". To get a copy of the software itself, send mail to <> with no subject and a message body of: connect get software/internet/idg quit If you have specific questions, you may want to write directly to IDG's author, Don Stone <>.
Subject: 3.04 ListProc, free version [v. 6.0c] Date: 17 Oct 94 Source code is at <> This is the final no-charge version of ListProc. It will not be enhanced except for bug fixes. Read the section above on "Do you need to modify the MLM's source code?" for notes on restrictions associated with this package. Some background relating to ListProc's name: you may see references to this product as "Unix Listserv." Be careful, and try to clarify if the "listserv" in question is the Eric Thomas/"BITNET" version, or really ListProc. When Anastasios Kotsikonas ("Tasos") first wrote ListProc at Boston U., it was called "Unix LISTSERV," and it included a note in the documentation that some read to mean it was related to the Eric Thomas software. This made Eric mad, and he complained for years that these "Unix Listserv" users thought he sanctioned the software or that it was a port of his VM/CMS LISTSERV. When he formed L-Soft and took LISTSERV commercial, lost sales became part of the issue. The situation finally escalated to the point where, voila! ListProc was born :-). ListProc versions below 6.0c *were* called "Unix LISTSERV" or "Unix Listserver," but they're still ListProc, and you should call them ListProc. It's less confusing that way. To discuss ListProc 6.0c, subscribe to by writing "sub unix-listproc Your Name" in the body of a message to This is also ListProc 6.0c's technical-support list; most support is provided by users, although Tasos also reads the list regularly and sometimes comments.
Subject: 3.05 CREN ListProc [v. 7.1] Date: 20 Nov 94 CREN, the Corporation for Research and Educational Networking, has purchased the rights to ListProc and now sells it commercially. In this document I call the product "CREN ListProc," though they don't -- if you prefer, read every reference to "CREN ListProc" as "ListProc 7.0 and up." You can't ftp an evaluation copy of CREN ListProc, but CREN is willing to make arrangements for trial use; write to them at the sales address below. Supported platforms: ListProc 7.1 runs on AIX, HP-UX 9, Irix 5, OSF/2, Solaris, SunOS, and Ultrix. "Windows NT is planned for the future" (personal correspondence from For sales information, write to You can also browse through <gopher://> or <>. To discuss CREN ListProc, subscribe to by writing "sub cren-list <Your Name>" in the body of a message to This is not a technical-support list.
Subject: 3.06 LISTSERV [v. 1.8a] Date: 20 Nov 94 [1/17/94: version 1.8b is in beta test and will be released soon. It includes several features LISTSERV users have wanted for a while, as well as one that will be relevant more and more in the future: a spam control function, in which LISTSERV's core servers will exchange information on potential spams and automatically take action to limit their spread. I will cover this more in a future version of the FAQ.] LISTSERV is sometimes called "BITNET LISTSERV," but it's not just for BITNET any more! As of version 1.8a, it's a commercial product sold by L-Soft International, a company started by LISTSERV's author Eric Thomas (ERIC@LSOFT.COM). It is probably the fullest-featured of the MLM's; it also is one of the easiest to configure remotely. However, it's not free :-). Evaluation kits are at <>. They are fully functional except that they support a limited number of lists and subscribers, and include an "evaluation system" message in all outgoing mail. Supported platforms: LISTSERV is available for AIX, BSDi, HP-UX, Irix, Linux, OSF/1, Solaris, SunOS, and Ultrix, as well as VMS, VM/CMS, and Windows NT. To find out the basics about using LISTSERV, write "HELP" in the body of a message to LISTSERV@LISTSERV.NET. To get more in-depth information, send it the command "INFO" for a listing of informational files, and then "GET" the files that sound interesting to you. Release notes for the past few years' worth of LISTSERV can be retrieved from by sending it "GET LINFO FILELIST" in the body of a message ("LINFO" being L-Soft Info). For sales information, send mail to SALES@LSOFT.COM. To discuss LISTSERV with sysadmins, subscribe to LSTSRV-L by writing "sub LSTSRV-L Your Name" in the body of a message to You may also be interested in LSTOWN-L, for owners of LISTSERV lists -- discussion here will give you a feel for what it's like to remotely administer a LISTSERV list. Subscribe by writing "sub LSTOWN-L Your Name" to You can browse through back issues of either of these lists at <gopher://>. (Note: LISTSERV systems participate in a global directory of lists, so commands and postings for these lists and all other public LISTSERV lists can also be sent to LISTSERV@LISTSERV.NET, for commands, or <listname>@LISTSERV.NET, for postings. This shortcut doesn't apply to getting files, though, because file names don't imply a server site.)
Subject: 3.07 Mailbase Date: 17 Oct 94 Mailbase is funded by the Joint Information Services Committee of the Higher Education Funding Councils for England, Scotland, and Wales. Its services are very popular in the U.K., and the program itself provides many useful features, friendly command syntax and user messages, and good efficiency. Source code is not available. However, the binaries can be licensed at no charge; write to To find out the basics of using Mailbase, write "send mailbase user-guide" in the body of a message to Or, take a look through <> or <gopher://> ... lots of Mailbase documentation is available there, as well as searching facilities for Mailbase lists and archives. Supported platforms: Mailbase is available for SunOS 4.1.1 and 4.1.3 on Sun 4/4m/4c's, and for Solaris 2.3. For Mailbase to run, your system must also have two other packages installed: Ingres 6.3 (or later) and Perl. To save the Mailbase developers' sanity, you should have some understanding of Ingres, Unix, and Mailbase itself (as a list owner/member) before you attempt to install Mailbase.
Subject: 3.08 MAISER (part of the Mercury Mail Transport System) [v. 1.13] Date: 22 Nov 94 [1/17/94: version 1.20 of Mercury has been released, including a new version of MAISER. According to its author, notable new features in MAISER 1.20 include MIME-format digests, message archiving, and full anonymous mailing.] David Harris, who writes Pegasus Mail, the great DOS/Windows/Mac mail system, also writes the Mercury MTA for NetWare servers. Mercury includes a simple but functional MLM, "MAISER." MAISER supports subscribe, unsubscribe, and review commands for lists (which can be moderated or not, closed or not, with posting restricted to list members or not), as well as file-archive index and get commands. It also supports a finger command to help track down users on the server's Pegasus Mail system. MAISER is *not* meant to be a high-end system, but if you want to run a small MLM and already have a NetWare server on the Internet, you may like it. Both Pegasus and Mercury are free software, but they are distributed as executables only. David makes his money selling manuals, though decent on-line documentation is included with everything he distributes. Get Pegasus and Mercury at <>. The discussion list for both packages is PMAIL@UA1VM.UA.EDU; subscribe by sending "subscribe PMAIL Your Name" in the body of a message to LISTSERV@UA1VM.UA.EDU.
Subject: 3.09 Majordomo [v. 1.92] Date: 20 Nov 94 [1/17/94: version 1.93 has been released. It includes a few bug fixes including one of a race condition that allowed any user of the system on which Majordomo was installed to replace any Majordomo-owned file; it also has some updates to functions like its administrative-message detection. I haven't tried the new version, but will update the FAQ later to cover it.] Majordomo is probably the fastest-growing package out there, certainly in terms of the number of sites installing it. Why? Aside from the general explosion in mailing lists, Majordomo has the advantages of being free, of a manageable size and complexity, and written in a language (Perl) that many feel comfortable with. Development is active, and it's likely that whatever gadget you want for it, someone is in the process of writing. However, Majordomo has some real performance problems if you're going to run a very busy MLM (meaning dozens of messages a day, or thousands of subscribers), so be warned. (Future versions will address these problems, it is said.) Source code is at <>. You will need a recent version of Perl 4.0 on your system. Out of the box, Majordomo assumes you're using Sendmail, but people have made it work with all sorts of MTA's. Discuss Majordomo with other users on -- to subscribe, send "subscribe majordomo-users" in the body of a message to David Barr <> maintains the Majordomo FAQ. Get it from his Majordomo site by sending "get file majordomo-faq" to, from comp.mail.misc or news.answers, or from any news.answers archive, for example <>.
Subject: 3.10 MReply [v. 1.71] Date: 28 Nov 94 MReply is an interesting little package, sort of a construction kit for MLM's. Some of its big advantages are that it requires no root access to be set up (though you would like to have new aliases set up, and that has to involve your system's mail administrator), and that it allows almost total flexibility in how the lists are run. This second feature could also act as a *dis*advantage, if you make some change to an MReply script that causes mail to bounce oddly, for example. You shouldn't have to change much, though; MReply comes with sample scripts that probably are enough to get you started. (These samples are endearing in that they open every reply from the server with "Hi, Norm" -- at least if your name is Norm, and mine is :-) ) MReply includes the standard subscribe, unsubscribe, get, and archive index features, as well as automatic uuencoding, shar'ing, and splitting of outgoing files and the ability to apply uudecode to incoming files. It tries to filter administrative requests from distribution to the mailing list, and it also includes simple mail-loop detection and blocking. Finally, it lets you define your own commands if you choose (makes sense, since the sample configuration files you start with are what define the "standard" commands in the first place). MReply is written by Tor Slettnes <>; its source can be retrieved from <>. You can subscribe to the MReply users list by sending "subscribe mreply-list" in the body of a message to For more information on using MReply, send "help" in the body of a message to the same address.
Subject: 3.11 MXSERV (MX/MLF, part of the Message Exchange system) [v. 4.1] Date: 28 Nov 94 MX (for "Message Exchange") is a free mail system for VMS, designed to work with VMS Mail. Its architecture is that of a central "router" surrounded by independent delivery agents -- one for UUCP, one for SMTP, one for DECNET, etc. One delivery agent you can choose to install is MLF, the "Mailing List/File Server" package, giving you free MLM capabilities under VMS. (MX also includes hooks to LISTSERV, if you choose to use that system instead.) MX runs on OpenVMS VAX (VAX/VMS) versions 5.0 and up, and on all versions of OpenVMS AXP. To act as an Internet MTA, MX requires prior installation of one of several vendors' TCP/IP packages. The mailing-list portion of MX/MLF is usually reached at the address MXSERV or MXSERVER, but is also reachable at "listname-request." It supports basic user commands including subscribe, unsubscribe, review, help, and "query" (i.e. "which lists am I on"), as well as a "set" command by which users can control whether they are sent copies of their own postings and whether they are listed in a review of subscribers. The file server portion, usually reached at the address FILESERV, supports directory and get commands as well as an "address" directive to redirect output to another user. From the administrator's perspective, MX/MLF supports open and closed subscription, reviewable and and private subscription lists, and open as well as owner-moderated posting, all configured through the same interface used to set up the rest of MX's functions. Get MX at <>. Its user discussion list is MX-List@WKUVX1.BITNET; subscribe by sending "subscribe" in the body of a message to MX-List-Request@WKUVX1.BITNET.
Subject: 3.12 SmartList [v. 3.10] Date: 28 Nov 94 Depending in large part on the intelligence of the (wonderful) Procmail local delivery agent for Unix, SmartList is a surprisingly small package that does many nice and unique things. It also does those things in a unique way, with a unique user interface -- specifically, from the user's perspective it looks more like a manually-maintained list (the kind with a human being at "listname-request"), than it does like the "machine at a server" model of most packages, as pioneered by LISTSERV. SmartList is specifically designed to do what users expect without imposing any particular syntax on them. It imposes no strict format on subscribe and unsubscribe messages, accepting all common formats including commands in the Subject line and most requests in "plain English." It also does fuzzy matching on addresses (as described in the "user features" section), which can be important in processing unsubscribe requests and bounces. Administration of SmartList lists is easiest for users who have accounts on the server system. Limited administration can also be done by mail; however, commands are sent in the message *header*, instead of the body, which limits the MUA's a remote administrator can use (most PC packages are right out). Beyond the "philosophy" issues described above, which can be either an advantage or a disadvantage depending on your biases, SmartList offers these advantages: it imposes a low load on your system yet offers high performance in delivery, thus it is suited to run fairly large lists; it handles bounced mail better than any other package; and it probably already runs on your Unix system. Its primary disadvantage, for some sites anyway (again excluding philosophy issues) is that users don't get a unified view of the lists on your server: each "-request" address stands alone. Stephen R. van den Berg ("AKA BuGless"), who writes both Procmail and SmartList, provides quick and friendly support on their discussion lists. To run SmartList, you also need Procmail. Get the sources for both at: <> and <> (replace ".gz" with ".Z" if you don't have the GNU gzip package) Discussion lists: subscribe to and/or by writing a subscribe message (any format, even plain English) to or, as appropriate.
Subject: 3.13 Smof Listserver for DOS/KA9Q. [v. 05l] Date: 24 Nov 94 Tim Illingworth has fit a surprising number of features into this package, which is still in beta test: besides the standard subscribe and unsubscribe commands, it also supports moderated lists, digests, and "get" and "index" file server functions with limited searching abilities. There is no support for detecting mailing loops or administrative messages sent to the list. The package runs on DOS, a plus if you don't want to learn a new OS -- though setting up KA9Q may be a rude shock if you're new to it. There are some very rough spots due to its dependence on DOS and KA9Q -- for example, in this version, subscribe and unsubscribe commands cause the program to exit KA9Q (closing down all network services), run an alias-updater from DOS, and then return to KA9Q. This is a consequence of Smof's design for a dial-up, pay-by-the-minute IP environment. Because the package is still in beta test, Tim is distributing it for free. He writes that when he is satisfied with it, he will release it as shareware, probably for US$30. Get the latest version at <>.
Subject: 3.14 TULP [v. 4.0.0] Date: 28 Nov 94 TULP, like ListProc, started life when LISTSERV ran only under VM/CMS, as a program for people who wanted a LISTSERV feel on a Unix box. Unlike ListProc, however, TULP has stayed extremely true to the LISTSERV syntax, at least for the minimal feature set it supports -- it has also, surprisingly, remained very simple. In terms of the "philosophy dichotomy," TULP quietly thinks "small is beautiful" (it actually stays closer to this philosophy than any of the other packages), but it emulates a program that shouts: "BIG is beautiful!" The result, to someone used to LISTSERV, is sort of strange. While TULP is reliable and useful, it feels schizophrenic, or perhaps like a tease ... its *commands* look like LISTSERV's, its *output* looks like LISTSERV's, and it typically answers at the listserv user id, but it doesn't execute any but the simplest requests -- there's no digest facility, no alternate headers, no database searching, minimal loop detection, and no global directory. Many people never use a command beyond the basics, though, and for them TULP will feel comfortably like LISTSERV. For administrators, TULP retains a LISTSERV feel, with its configuration file taking a subset of LISTSERV keywords. However, the file must be edited locally; remote administration is limited to the addition and removal of subscriber addresses and the approval of messages for moderated lists (using an "Approved:" header). TULP has two advantages over the other simple programs: first, most of its messages are centralized into one file, making it less difficult to write translations for other languages (French is already available). Second, it runs as a daemon, so that the maximum overhead it imposes on the system is fairly low. Note however that if you use TULP's Perl "deliver" routine, which is necessary to filter administrative messages from your mailing lists, you will have a (short) invocation of Perl for every message that arrives. TULP's author writes: "No other features are planned for this package. The author [plans] to develop a new freely available product named 'ML' which will be as simple as TULP [in its] installation and management, but which should add better management features. Development has not yet started and is not decided." ( to, 25 Nov 94) Source code is available at <> To discuss TULP, subscribe to by writing "sub listnix Your Name" in the body of a message to
Subject: 4.00 Where to get the current version of this FAQ This FAQ is posted monthly on, comp.answers, and news.answers. It is then archived at news.answers archives including <>. In addition, the current version may be retrieved from these mail servers: Write "get doc mlm-software-faq" in the body of mail to Write "get mlm-software faq" in the body of mail to Write "get file mlm-software-faq" in the body of mail to Write "archive get FAQ/mlm-software" in the subject or body of mail to
Subject: 4.01 Changes in this version 1.1: not many changes (though I am collecting a long list of changes to make later, when I have more time). Some errors are corrected (see section 4.02). Notations are made in the LISTSERV, MAISER, and Majordomo sections that new versions are out or soon to be out. The section on IDG is new.
Subject: 4.02 Acknowledgements In version, the first posted to news.answers, I depended heavily on the kindness of the various MLMs' authors. Without their annotations and corrections it would have been a misleading document. Two people who were *very* patient with me were Eric Thomas (author of LISTSERV) and Stephen van den Berg (author of SmartList). Especially Stephen :-). Also, David Barr, author of the Majordomo FAQ, is the man who suggested I turn this document into a FAQ in the first place -- I originally intended for it to be just a few paragraphs in his document, and somehow it ballooned ... In version 1.1, most changes I made were to correct errors that various people spotted and pointed out to me. Specifically: Bob Bagwill <> pointed out that SmartList's remote administration by mail requires placement of commands in the message header. Brent Chapman <Brent@GreatCircle.Com> corrected my misapprehension that he was the author of Majordomo's link to ftpmail :-) while kindly taking the time to read over the FAQ as a sort of historical consultant. Michelle Dick <> has written several messages that changed my *view* of some issues (this goes back to the first version) -- so I can't quite point to which section she changed, but her influence is in there. Joe Sparrow <> was the first to point out to me that my discussion of MTA's and MUA's under VM was incorrect, and to give me a clear view of what the situation really is. David W. Tamkin <> caught my use of "priority" when I meant "precedence." Windigo the Feral <> sent a very nice description of a particular type of built-in mailing list support, in DG/UX Sendmail. Needless to say, I am responsible for all errors that remain.
Subject: 4.03 Acronyms explained (FAQ, MLM, MTA, MUA) "FAQ": Frequently Answered Question -- something that comes up a lot on USENET and mailing lists, annoying the "regulars." Also refers to a document containing a collection of these frequently asked questions and their answers. This document is therefore a FAQ. "MLM": Mailing-List Manager -- the software handling the subscription list and (usually) distribution of mail. In contrast, the person who owns or moderates a list is usually called the list owner (though this is debated). "MTA": Mail Transport Agent -- the program handling actual delivery of mail. On Unix systems this is usually Sendmail, Smail, or Zmailer. On IBM mainframes running VM (I don't know about other IBM OS's), you may see LMAIL, XMAILER, or IBM's SMTP product; on VMS systems you may see PMDF or MX. "MUA": Mail User Agent -- the program the user interacts with to read and write e-mail. On Unix systems, popular MUA's are Elm, Pine, mail, mailx, mush, etc. On PC's, some common MUA's are cc:Mail, Pegasus (PMAIL), Microsoft Mail, etc. On IBM mainframes, you see mostly Rice Mail (MailBook) under VM, and others like PROFS under the other OS's. On VMS systems, common MUA's are VMS Mail and All in 1.
Subject: 4.04 URL's -- how to read them and use them URL stands for "Uniform Resource Locator" -- it tends to be associated with the World-Wide Web, though it's a more general-purpose tool than that. In this document, URL's are used to specify where to get something by ftp, like this: "". The URL's in this document are surrounded by angle brackets "<>". If you're lucky (depends on the software you're using to read this FAQ), you may be able to "follow" these references automatically by clicking on them. If you can't, here's how to read and use them: The part before the colon ("ftp" in this example) is the service type. Some common service types are "ftp," "telnet," "gopher," and "http" (which is Hypertext Transfer Protocol, used in the World-Wide Web). The part between the "//" and the next slash is the name of the host you should connect to, sometimes with a specific port specified. For example, "telnet://" would mean "use the telnet protocol to connect to on (non-standard) port 1999." Finally, the part after the host name is the "path" you should follow to your destination, and its use varies depending on which protocol is involved. If HTTP is the protocol, just type the whole reference into your World-Wide Web browser (in fact, you can type *any* URL into a WWW browser, which makes life easy). If FTP is the protocol, which is mostly the case in this document, follow this recipe: use your ftp program to connect to the named host, and log in as "anonymous," giving your e-mail address as a password. (If you are lucky, your ftp program will take care of the login for you.) Then, use the cd command to change to the first directory listed, in this example "pub." Then cd to the next directory, in this case "blah." Continue until you get to the last part, which is a file name -- switch to binary mode if appropriate (it usually is), and get the file: "get blah.Z". If the URL ends in a slash, it means the file is somewhere in the specified directory: get to the directory and look around using "dir". ******* End of the Mailing List Management Software FAQ *******

User Contributions:

Comment about this article, ask questions, or add new information about this topic:


[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:

Last Update March 27 2014 @ 02:11 PM