home *** CD-ROM | disk | FTP | other *** search
- Path: senator-bedfellow.mit.edu!faqserv
- From: naleks@Library.UMMED.EDU
- Newsgroups: comp.mail.list-admin.software,comp.answers,news.answers
- Subject: Mailing list management software FAQ
- Supersedes: <mail/list-admin/software-faq_803550313@rtfm.mit.edu>
- Followup-To: poster
- Date: 17 Jul 1995 11:21:23 GMT
- Organization: none
- Lines: 1527
- Approved: news-answers-request@mit.edu
- Expires: 28 Aug 1995 11:19:59 GMT
- Message-ID: <mail/list-admin/software-faq_805979999@rtfm.mit.edu>
- Reply-To: naleks@Library.UMMED.EDU
- NNTP-Posting-Host: bloom-picayune.mit.edu
- Summary: Mailing list managers are the programs operating mail-based
- discussion lists -- ListProc, LISTSERV, and Majordomo are three well-
- known examples. This FAQ briefly describes the popular packages, tells
- you where they can be found, and offers advice on how to choose one.
- X-Last-Updated: 1995/01/24
- Originator: faqserv@bloom-picayune.MIT.EDU
- Xref: senator-bedfellow.mit.edu comp.mail.list-admin.software:691 comp.answers:13133 news.answers:48600
-
- Archive-name: mail/list-admin/software-faq
- Posting-Frequency: every 28 days
- Version: 1.1 (last revised 1995/01/24 16:46:57)
-
- *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 comp.mail.list-admin.software, and archived
- at URL "ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq".
- (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 <windigo@thepoint.com>.)
- 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 mailbase.ac.uk
- 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 LSTSRV-L@uga.cc.uga.edu.
- 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 sumex-aim.stanford.edu, 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
- <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/wimag.exe>) 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 list-managers@greatcircle.com; to
- subscribe, write "sub list-managers YourAddress" in the body of a message to
- majordomo@greatcircle.com.
-
- On USENET, comp.mail.list-admin.software 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 <ftp://ftp.uu.net/usenet/news.answers/mail/archive-servers/faq>.
-
- ------------------------------
-
- 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 <ftp://ftp.oes.orst.edu/pub/>
-
- To subscribe to the Almanac discussion list, write "subscribe alm-core-mg" in
- the body of a message to almanac@oes.orst.edu.
-
- ------------------------------
-
- 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 <bmw@gojira.monsta.com> 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 <ftp://gojira.monsta.com/pub/src/>.
-
- ------------------------------
-
- 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 <dot%t3ew@dot.ca.gov> with a subject line of
- "help". To get a copy of the software itself, send mail to
- <ftpmail%t3ew@dot.ca.gov> 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 <dstone%trmx2@dot.ca.gov>.
-
- ------------------------------
-
- Subject: 3.04 ListProc, free version [v. 6.0c]
- Date: 17 Oct 94
-
- Source code is at <ftp://cs-ftp.bu.edu/pub/listserv/current_version.Z>
-
- 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 unix-listproc@avs.com by writing "sub
- unix-listproc Your Name" in the body of a message to listproc@avs.com. 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 tasos@avs.com).
-
- For sales information, write to listproc-info@listproc.net. You can also
- browse through <gopher://info.cren.net/> or <ftp://info.cren.net/>.
-
- To discuss CREN ListProc, subscribe to cren-list@cren.org by writing "sub
- cren-list <Your Name>" in the body of a message to listproc@cren.org. 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 <ftp://ftp.spc.edu/listserv/>. 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 LISTSERV@searn.sunet.se 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 LISTSERV@uga.cc.uga.edu. 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
- LISTSERV@searn.sunet.se. You can browse through back issues of either of
- these lists at <gopher://searn.sunet.se/>. (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 mailbase-helpline@mailbase.ac.uk.
-
- To find out the basics of using Mailbase, write "send mailbase user-guide" in
- the body of a message to mailbase@mailbase.ac.uk. Or, take a look through
- <http://www.mailbase.ac.uk/> or <gopher://gopher.mailbase.ac.uk/> ... 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 <ftp://risc.ua.edu/pub/network/pegasus/>.
-
- 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 <ftp://ftp.greatcircle.com/pub/majordomo/majordomo.tar.Z>.
- 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 majordomo-users@greatcircle.com -- to
- subscribe, send "subscribe majordomo-users" in the body of a message to
- majordomo@greatcircle.com.
-
- David Barr <barr@pop.psu.edu> maintains the Majordomo FAQ. Get it from his
- Majordomo site by sending "get file majordomo-faq" to majordomo@pop.psu.edu,
- from comp.mail.misc or news.answers, or from any news.answers archive, for
- example <ftp://ftp.uu.net/usenet/news.answers/mail/majordomo-faq>.
-
- ------------------------------
-
- 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 <tor@netcom.com>; its source can be
- retrieved from <ftp://ftp.netcom.com/pub/to/tor/mreply/>.
-
- You can subscribe to the MReply users list by sending "subscribe mreply-list"
- in the body of a message to mreply-request@netcom.com. 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 <ftp.spc.edu://pub/mx/>. 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:
- <ftp://ftp.informatik.rwth-aachen.de/pub/packages/Procmail/Procmail.tar.gz>
- and
- <ftp://ftp.informatik.rwth-aachen.de/pub/packages/Procmail/SmartList.tar.gz>
- (replace ".gz" with ".Z" if you don't have the GNU gzip package)
-
- Discussion lists: subscribe to Procmail@informatik.rwth-aachen.de and/or
- SmartList@informatik.rwth-aachen.de by writing a subscribe message (any
- format, even plain English) to Procmail-request@informatik.rwth-aachen.de
- or SmartList-request@informatik.rwth-aachen.de, 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 <ftp://ftp.demon.co.uk/pub/ibmpc/listutils/>.
-
- ------------------------------
-
- 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." (wolf@pasteur.fr to naleks@library.ummed.edu, 25 Nov 94)
-
- Source code is available at
- <ftp://ftp.univ-lyon1.fr/pub/systems/unix/mail/list-servers/tulp/>
-
- To discuss TULP, subscribe to listnix@grasp.insa-lyon.fr by writing "sub
- listnix Your Name" in the body of a message to listserv@grasp.insa-lyon.fr.
-
- ------------------------------
-
- Subject: 4.00 Where to get the current version of this FAQ
-
- This FAQ is posted monthly on comp.mail.list-admin.software, comp.answers,
- and news.answers. It is then archived at news.answers archives including
- <ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq>.
-
- In addition, the current version may be retrieved from these mail servers:
-
- Write "get doc mlm-software-faq" in the body of mail to
- ListProc@avs.com
-
- Write "get mlm-software faq" in the body of mail to
- LISTSERV@listserv.net
-
- Write "get file mlm-software-faq" in the body of mail to
- Majordomo@pop.psu.edu
-
- Write "archive get FAQ/mlm-software" in the subject or body of mail to
- SmartList-request@informatik.rwth-aachen.de
-
- ------------------------------
-
- 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 1.0.1.0, 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 <bagwill@sst.ncsl.nist.gov> 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 <artemis@netcom.com> 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 <jsparrow@uwm.uvic.ca> 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 <dattier@wwa.com> caught my use of "priority" when I meant
- "precedence."
-
- Windigo the Feral <windigo@thepoint.com> 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: "ftp://foo.bar.edu/pub/blah/blah.Z".
-
- 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://foo.bar.edu:1999/" would mean "use the telnet protocol to connect
- to foo.bar.edu 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 *******
-
-