Партнёры:
Хостинг:
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 *******
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |