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.