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:
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.