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
<ftp://ftp.uu.net/usenet/news.answers/mail/archive-servers/faq>.

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 <ftp://ftp.clark.net/pub/magnet/>) 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.