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. Let's take one example: 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 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, usually 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 incentive 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: