Previous Page TOC Index Next Page Home


Listservs and Mailing Lists

--by Philip Baczewski

So, you want to run your own mailing list. You too can join a mere 5000-8000 other mailing list owners who provide a unique service to the Internet. Sarcasm aside, it is getting easier to set up and run a mailing list. Not only is the supporting software more sophisticated and readily available, but the choice of host computing platforms has also become more varied. A potential world-wide pool of subscribers provided courtesy of the Internet now makes it possible to sustain mailing list on quite esoteric topics. More and more mailing lists are being created to support specific professional organizations or clubs. It is now likely, then, that if you are involved with using or supporting use of Internet facilities, you may be called upon to start and maintain an on-line mailing list (just like when the person who owned the computer used to end up doing the club newsletter).

At its simplest, a mailing list can just be a list of e-mail addresses which allows a single message to be sent to a group. To provide automated interaction between multiple subscribed individuals, however, usually requires some piece of software to accept subscription and sign-off requests, redistribute messages, maintain message archives, and possibly maintain a file distribution service. For many years, the Revised Listserv software written by Eric Thomas, was the only program which performed all of the above tasks and more. Listserv was primarily associated with the Bitnet educational and research network, and ran on IBM mainframe systems. The program utilized the IBM RSCS protocol supported on IBM operating systems and emulated by various software offerings on other non-IBM Bitnet nodes. More recently, a version of Listserv has been produced for a diverse set of computer platforms, and several additional programs are available to manage the tasks associated with running a mailing list.

The first step to starting a mailing list is finding a host to support it. This may be an individual computer workstation that you manage, or it could be an Internet-connected multiuser host system. It may even be a remote system where other mailing lists are maintained. If mailing list software is not installed, then you will either need to install one of the programs that are available, or request that it be installed by your system manager. In either case, you will need to carefully evaluate your requirements for mailing list management and select and acquire the software which best supports those requirements. The following discussion may serve as a head start on the process by offering some information on the most popular mailing list packages currently available.

Finding and Configuring Mailing List Software

There are several factors to keep in mind when "shopping" for mailing list software. You must know what kind of computer will be available to run the software. You should have some idea of the size and purpose of your intended mailing list or lists. You need to evaluate what other supporting features are required from your mailing list software (archives, file distribution, and so on). Often, question number one overrides any others. If your only available host is a Novell file server, then that may make the decision for you. However, all of the programs discussed below provide, at least, basic automated list management features and all of them are currently in use at a number of Internet sites.

An Overview of the Mercury NLM

David Harris, the programmer from New Zealand who provides many Novell file server installations with an e-mail program named Pegasus Mail (P-Mail), has also written an SMTP mail gateway to go along with that program. His name for that mail delivery gateway is Mercury (surprise) and it runs as a Netware Loadable Module (NLM). Novell types will remember that an NLM is a dynamically loadable extension to the Netware operating system which first appeared with Netware 3.0.

The Mercury NLM provides an interconnection between a Netware queue and a UNIX mail delivery agent (for example, sendmail), and allows P-Mail users to send Internet mail, if that UNIX system is on the Internet. An additional feature of the Mercury NLM is that it has automated mailing list capabilities built in. This is quite a handy feature for maintaining local discussion lists, but it will also just as easily support Internet mailing lists. Mercury is distributed along with Pegasus mail and is primarily available from in the /pub/network/pegasus directory.

List Management Features of the Mercury NLM

The Mercury NLM supports the basic commands needed to maintain an automated Internet e-mail discussion list. The part of the software that performs these tasks is referred to as Maiser. The supported commands operate in a similar fashion to some familiar and more established mailing list software packages. Subscribe listname and Unsubscribe listname commands are used to add or delete your name to a list. Mail to be distributed to the list is send to listname@internet.node. Commands such as Subscribe and Unsubscribe are usually sent to maiser@internet.node (maiser is short for mail server). A mail alias can also be defined in place of the name Maiser, if, for example, you wished people to send subscription requests to listmngr@your.internet.node.)

Is it Listserv or isn't it?

In the good old days, there was just one major mailing list software package; it was named Listserv, and it ran on Bitnet. Now a number of different software packages are available and they may be addressed as listserv but they are not always the "real" Listserv. The Revised Listserv, written by Eric Thomas, was, as its name implies, a revision and extension of a mailing list server program written by EDUCOM staff and installed at BITNIC, the Bitnet network information center, under the User ID LISTSERV. Apparently, no one holds a legal trademark on the name "listserv," but the program written by Thomas has clearly utilized that name for the longest period of time.

So, you say, "Listserv is to mailing lists what the Hershey bar is to chocolate, and Kleenex is to tissue, and Scotch tape is to cellophane tape, and the Internet is to networks. Does it really make a difference?" The answer is a resounding "probably." Because Listserv is the most established of the mailing list software—and in some ways, one of the most documented—people expect certain commands to work when they address a message to an entity named listserv.

In order to 1) be honest with people, and 2) give them the most efficient use of mailing list facilities, it is probably best to avoid using the name listserv as the alias for one of the non-Listserv packages. This is not a value judgement in relation to any of the software, but more of a practical comment. If people know they are not dealing with a familiar Listserv installation, they are more likely to request a help file (or consult some other reference) before trying to utilize that facility. This will save the headache (not to mention, the possible expense) of having to receive and deal with rejection messages for unsupported commands. While most packages support your basic subscribe command, in some cases the similarity ends there.

Even Brent Chapman (of Majordomo fame) says the following in the readme file distributed with his program: "I used to suggest using listserv, but I don't any more; Majordomo is not compatible with Bitnet Listserv, and calling it listserv confuses people." The bottom line, from my point of view, is if it's not Listserv, don't call it listserv.

Maiser supports a number of different list configuration options. Lists can be moderated (only the moderator can post messages), restricted (only members of the list may post), or fully public. Open subscription as well as moderator-controlled subscription options are also available. One installation can support multiple lists, moderated by different people. MAISER supports a number of list user and list management commands, as shown in the following list. You will notice that some commands have one or more variations.

User Command

Enables You to

SUBSCRIBE listname
SUB listname

Subscribe to the indicated mailing list

UNSUB listname
SIGNOFF listname

Sign off from the mailing list

ENUMERATE listname
REVIEW listname

Receive a listing of mailing list members


Receive an inventory the mailing lists available at this host


Receive a copy of the help file defined in the MAISER section of the MERCURY.INI file

LOOKUP string

Search the associated host's NetWare bindery for usernames matching string—the string can contain the wild cards * and ? (the file server manager can disable lookup by excluding the LOOKUPFILE entry in the MAISER section of the MERCURY.INI file)


Receive a copy of an index to any files associated with this installation (this command sends the file INDEX.TXT from the "files to send" directory of the Mercury installation

SEND filename

Receive a copy of a file listed in the index file (the file server manager can disable this feature by excluding the SEND_DIR entry in the MAISER section of the MERCURY.INI file)

Moderator Command

Enables You to

ADD listname address

Add a new user to the indicated list (for moderators only)

REMOVE listname address

Remove a user from the indicated list (for moderators only)


Return a message to the sender, with the headers intact

VERIFY address

Returns a message indicating

whether the address specified is valid on the local host.

Setting up a Mercury Mailing List

Once the Mercury NLM is installed on the file server, creating a list is an easy task. This will usually need to be done by the NetWare file server manager or someone with an equivalent level of access. List service configuration statements are added to the mercury.ini file (Mercury's configuration file) and a "list of lists" file will need to be created and reference in the mercury.ini file. The list file contains the definitions for the mailing lists supported by that Mercury installation.

The following examples show how a mailing list could defined using the Mercury NLM. This mercury.ini example appears courtesy of Eriq Neale (, Academic Computing Services file server manager at the University of North Texas. The Maiser section of the file is seen at the end. Statements preceding the Maiser section define the environment for performing the SMTP gateway function.

Anything after a # to the end of the line is a comment, and # is stripped out before parsing. Trailing and leading white space is also stripped before parsing.

myname:          # Canonical name for this server
timezone:    GMT+6                # Time Zone to add to date fields
mailqueue:   MAILQ                # Where mail should be put for delivery
smtpqueue:   MAILQ                # Where the SMTP client should look for
                                  # mail
                                  # note: smtpqueue and mailqueue can be the
                                  # same
failfile:    SYS:SYSTEM/MERCURY/FAILURE.MER  # Delivery failure notification
                                             # template
confirmfile: SYS:SYSTEM/MERCURY/CONFIRM.MER  # Delivery confirmation template
aliasfile:   SYS:SYSTEM/MERCURY/ALIAS.MER    # System-wide alias file
synfile:     SYS:SYSTEM/MERCURY/SYNONYM.MER  # User synonym database
listfile:    SYS:SYSTEM/MERCURY/LISTS.LST    # List of lists
logfile:     SYS:SYSTEM/MERCURY/MERCURY.LOG  # Traffic logging file
bitnethost:     # Relay host for ".bitnet" rewrites
poll:        10                   # Seconds between queue polling cycles
gullible:    0
scratch:     SYS:SYSTEM/MERCURY   # Where we can write temp files
switch:      1                    # number of ms to yield per op on heavy I/O
returnlines: 15                   # How many lines of failed messages to
                                  # return
postmaster:  NEALE                # NetWare UIC of postmaster
swapids:     1
host:          # mail mail host which relays for us
scratch:     SYS:SYSTEM/MERCURY   # Where we can write temp files
poll:        30                   # Seconds between queue polling cycles
switch:      1                    # number of ms to yield per op on heavy I/O
returnlines: 15                   # How many lines of failed messages to
failfile:    SYS:SYSTEM/MERCURY/FAILURE.MER  # Delivery failure template
timeout:     300
switch:      1
debug:       1                    # Whether or not to show session progress
discard:     20000
scratch              :     SYS:SYSTEM/MERCURY
switch               :     2
# Alias for group          Actual NetWare group name
# NetWare Server           Domain name
ACS             :
ACS             :       ACS
Maiser               :     Maiser
Helpfile             :     SYS:SYSTEM/MERCURY/MAISER.HLP
Lookupfile           :     SYS:SYSTEM/MERCURY/MAISER.LKP
Send_dir             :     SYS:SYSTEM/MERCURY/SENDABLE
Logfile              :     SYS:SYSTEM/MERCURY/MAISER.LOG
Notify               :     SYS:SYSTEM/MERCURY/TMP
Local_only           :     Y

The following is an example mailing list definition (gcba-l). "Green Chili Burp and the Aftertaste" are a band playing in a style the author has coined "facetious rock." Eriq Neale happens to be the band leader (the Burp, as it were).

;   Example entry from a "list of lists"
    file:           sys:system/mercury/gcbal.lst
    title:          Green Chili Burp and the Aftertaste List
    welcome:        sys:system/mercury/gcbalw.txt
    moderated:      N
    Public:         Y
    Reply_To_List:  Y
    enumerate:      Y

More on Mercury

Mercury and Maiser work only on Novell file servers, but there are a lot of those around. Mercury provides a robust mailing list management solution within the bounds of a Netware environment. Now when you see "Maiser" referenced in those mailing list announcements, you will know from what kind of system that list originates.

Introducing MajorDomo

Majordomo, written by Brent Chapman, is a relative newcomer to the set of mailing list software offerings. Because it is written primarily in Perl, it is usable on UNIX systems only. The primary source for distribution is the site, in the directory pub/majordomo. Majordomo is simple to install (on most systems) and is flexible enough to support several mailing list configuration variations.

Majordomo will need to be installed on a UNIX system by someone with root (su) privilege. The Majordomo manager (who creates the lists and so on) need not be the system manager, however. Each list created will have at least one owner. Majordomo supports both closed and open lists. Being added to a closed list requires the approval of the list owner.

Majordomo supports a number of different list types, some of which can be utilized in combination. An open list is one to which anyone can subscribe with no restrictions. Addition to a closed list requires approval of the list owner. A private list's members can be listed only by other list members. Messages to a moderated list can be posted only by the list owner. An auto list allows subscription and other commands to be automatically processed without needing any approval by the owner. You can also restrict lists to a specific Internet domain. These various configurations make it possible to define the type of list needed for the particular purpose.

Majordomo Commands

The commands supported by Majordomo are similar in concept to those of other mailing list software. They can be sent via an e-mail message to the address (or to whatever alias has been defined for Majordomo). At the heart of any such software are the subscribe and unsubscribe commands, and Majordomo is no different. It does provide a slight variation on these commands, however.

The following shows a summary of Majordomo user and list owner commands. The parameters in braces ({}) are optional. A vertical bar (|) stands for OR.

To add your name to a Majordomo list you can use the format:

subscribe listname {address}

To remove your name from a list, use the following command:

unsubscribe listname {address}

Here, listname is the name of the mailing list and address is an optionally specified address different from the one from which the mail is sent.

Several other commands can provide you with information about a list or about the lists maintained on a Majordomo installation:

info listname

Returns information about the specified list

which {address}

Returns the listnames to which you are subscribed or to which the optionally specified address is subscribed;

who listname

Returns a list of all addresses subscribed to the specified list name


Returns the names of all mailing lists maintained on that particular Majordomo installation

index listname

Returns a list of files associated with a particular mailing list.

get listname filename

Returns a copy of the requested file name

Two additional commands are available to all users:


Returns a informational help file;


Used to terminate a sequence of one-line Majordomo commands, so that subsequent lines of a message will not be processed (like a signature, for example)

In addition to these "general user" commands are some available only to list owners:

approve password subscribe|unsubscribe listname address

enables a list owner to approve a request to subscribe to, or sign off from, a closed list; the password (set initially by the Majordomo manager) is necessary to validate that the command is coming from the list owner;

passwd listname old_value new_value

enables list owners to change their password;

newinfo listname password

enables the list owner to set or change the information returned about list as the result of an info command.

This may seem like a limited set of commands, but they are enough to maintain your basic Internet mailing list.

Defining a Majordomo List

Installing Majordomo involves doing some UID and directory management, compiling some code, customizing a configuration file, and defining some alias values, the details of which are found in the documentation distributed with the package. Once Majordomo is installed, defining a list is relatively simple. At least four aliases are defined for each list: a pointer to the list of subscribers, a pointer to the list owner, a pointer to a handler for list requests, and a pointer to where requests are forwarded for any necessary approval. Sample aliases for a list might appear as follows:

list_name: :include:/majordomo/lists/list_name
list_name-request: "|/majordomo/wrapper request-answer list_name"

In addition to the aliases, several files must be created. In the previous example, list_name would be a file whose name matches the name of the list. This file will ultimately contain the addresses of the list's members. Along with it would be files named list_name.passwd, containing the approval password, and, containing the list's welcoming information. Other variations are described in Majordomo's documentation, and sample configurations are included.

Summing up Majordomo

Majordomo is a fairly straightforward package and is not at all overwhelming to install or configure. As with any e-mail operation, care must be taken to avoid generating e-mail loops and other nasty conditions. So far on the Internet, Majordomo seems to be proving itself as a useful list-management option.


Listprocessor (listproc for short) is a UNIX-based Listserv alternative that was developed by Anastasios Kotsikonas ( Its command set is similar but not identical to Listserv. Listproc was a freely distributed program through version 6, and you may still find version 6 on anonymous FTP sites (, for one). In 1994, the Corporation for Research and Educational Networking (CREN) purchased the ownership rights to Listproc and eventually issued version 7.0. This version is available at no charge to CREN members, with a yearly licensing fee for other nonprofit or for-profit organizations. More information about the availability of this software can be attained via e-mail from or

Listproc Commands

Listproc is a full-featured mailing list package that includes some list digest features and limited file serving. Both unmoderated and moderated lists are supported. Lists can be private or open. The commands shown in the following list indicate a higher level of complexity (as well as utility) than is seen in the previously discussed alternatives. The commands subscribe and unsubscribe once again show up in this command set. Notice that some of the Listproc commands will be familiar if you have any experience with Listserv (not a coincidence).

The following is a summary of Listproc 7.0 commands. The parameters in braces ({}) are optional. A vertical bar (|) stands for OR. Where the meaning of a command is not necessarily evident, a brief description is provided in parentheses.

Commands to join a list or modify your access:

subscribe listname your name -or- join listname your name

unsubscribe listname -or- signoff listname

purge password (Removes your address from all lists)

which (Finds out to which lists you are subscribed)

set listname {option arguments}
password old_password new_password
address password new_address
conceal YES|NO
preference preferences

query listname (Returns your settings)

Commands to retrieve list or general information:

help <topic>

help listproc

(Receives information on Listproc)

help live

(Receives information on interactive connection)

lists {local|global {keywords}}

release -or- version

(Listproc version)

information {listname}

recipients listname

(Lists subscribers)

review listname {short|description|subscribers}

statistics listname {subscriber_addresses | -all}

run listname {password cmd {arguments}}

(Runs a special command)

index {archive|path} {password} {-all}

search archive|path} {password} {-all} pattern

(pattern can be a regular expression)

get archive|path file {password} {# of parts}

view archive|path} {password} {# of parts} (Views files on the screen when connected interactively)

fax FAX# archive|path file {password} {# of parts}

(FAXes files to specified number)

{quiet} add listname password address name

{address name} ...

(Adds user or users—quiet specifies no notification to address)

{quiet} delete listname password address {address} ...

{quiet} set listname {option arguments} for address

{address} ...

purge password address {address} ... (Removes addresses from mailing list)

approve listname password msg tag # {msg tag #} ... (Approves messages for a moderated list)

discard listname password msg tag # {msg tag #} ...

configuration listname password {option {arguments}} ... (Sets list configuration options—send help configuration for a list of options and arguments)

edit listname password file {-nolock} (Retrieves a list file for editing)

hold listname password (suspend list mail delivery)

free listname password (resume list mail delivery)

lock listname password (suspend list requests)

unlock listname password (resume list requests)

initialize password {alias list_address config_options}


new-list password alias list_address config_options

put listname password keyword {arguments}

reports listname password

system listname password user_address commands (Issues commands for users)

Installing and Configuring Listproc

Installing Listproc does require system manager privileges to accomplish some tasks. Other than setting up the appropriate accounts, aliases must be set up, software must be compiled and configured, and file permissions must be set. A config file defines the parameters of the Listproc system, including elements like organization name, server definition and options, Listproc manager, and list definitions. The total number of parameters is quite numerous.

Lists are defined in the config file while the server is not running. Elements to define are a list alias (listname), list e-mail address, list owner's address, and a password. After they are defined, lists can be maintained by the Listproc manager through use of a list command supplied with the program distribution. Lists can be changed to moderated, message reply options can be set, message forwarding can be set, and several other parameter changes are possible.

One More Word on Listproc

For a number of years, Listproc was the alternative system for UNIX sites that wanted to run a mailing list server. With recent releases the software seems to be coming into its own, and CREN is certainly hoping to establish it in a manner similar to the proliferation of Listserv. As the following sections show, however, it is not without competition, and continual addition of a features may be necessary for this package to catch up to the more firmly established mailing list system.

Paco Xander Nathan

--by Tod Foley

"Overall, Rover represents an ongoing AI project, intended to explore the use of automated e-mail to help obviate most needs for a marketing department :)

Seems like OTHER magazines have even copied our research efforts, but we won't mention any names now, ahem, will we WiReD??!?!?!?!??!"

--Paco Xander Nathan; speaking of the FringeWare Infobot "Rover"

Paco Xander Nathan, also known as, is a programmer, writer, lecturer, and exemplary entrepreneur from 15 minutes into the future. He is perhaps best and most widely known as the cofounder of FringeWare Inc., a decidedly alternative hardware/software vendor and publishing company that does a majority of its business online. FringeWare's customers, clients, and cohorts keep in touch with Paco and his partner Jon Lebkowsky via an e-mail list, an automated file server, an anonymous FTP site, a Gopher site, a conference on The WELL, and a newly-created Mosaic site. But that isn't enough for these fabulous furry fringe brothers—they're currently creating their own virtual building in Steve Jackson Games' "Metaverse" MOO (telnet 7777).

Paco is a master of UNIX and telecommunications programming, and a well-known cyberjournalist as well. He is the creator of a wide variety of programs, from the rudimentary AI "Pets" that serve his online interests to a digital lunar calendar designed to assist in the prediction of menstrual cycles. His written works have appeared in the pages of bOING-bOING, Fringe Ware Review, Mondo 2000, PIX-Elation, Whole Earth Review, Wired, and 2600 magazines.

TF: How did FringeWare Inc. begin, and how is it structured?

PXN: Well, Jon and I noticed a fundamental shift in the nature of media + communities + entreprenuring + art, so we created FW as an experiment/survival-measure. Over the following two years, we've collected a nifty community of talented, like-minded folks—and, very importantly, alienated others whom we felt needed to be alienated. So, on the foundation, we're a Net-savvy publisher. That lends us cachet to maintain "property" within what might otherwise be considered "public" areas: a kind of "news service" (i.e., the e-mail list) with over 1000 primary and perhaps 5000 secondary subscribers worldwide. Plus, we have the worldwide circulation of our magazine, Fringe Ware Review, and these projects have prospered based on our formulation of Net-based economics and behavior. From this base, we've built another pillar: Our publications are registered in the Library of Congress and archived at an anonymous FTP site. On top of that, we've built means for access via Gopher and the Infobot. Atop that, we have an even niftier, more interactive method for access: our WWW pages. Altogether, we'll call this a "structure" :) , at least until we come up with some better name. P'haps it's all the Infobot....

TF: So you've got a built-in base, which covers all available Internet services. How do you make use of this "structure" in day-to-day business?

PXN: We manage to slip in our product catalog at each level, along with public access to product info and discussions. This is all based on info-on-demand and not broadcast or direct marketing, so I don't see it as "evil commercialization of the Net." Rather, it's a new kind of marketplace; a formalized, nurtured version of what's been going on since the dawn of e-mail anyway. We also manage to slip in feedback loops: (1) the various intelligent agents that comprise our infobot also generate files within our archives; (2) the business itself generates part of the archives, since our product and vendor and store databases are automatically converted into WWW pages; (3) the community develops a narrative about the business and the infobot; and (4) the infobot's agents analyze and publish the narratives and participation within the community. So, due to the feedback and automation issues, this Thing, this Structure falls under the domain of cybernetics; for example, the use of the term "Infobot."

TF: The InfoBot—a "pet" you refer to as "Rover"—exhibits a high level of interactivity that some might describe as a rudimentary form of "artificial intelligence." Some of your other "pets" are known to wander around the Net, and to make strange interpolations and collections of words and phrases they encounter, as if attempting to interparse meaning into substance... and yet at root we're talking about a mail server. At what point did you first make that conceptual leap, in which a UNIX mailing list becomes the kernel of an intelligent agent?

PXN: I think the moment is defined when enough interest and attention focus on that mailing list or address as something of worth. Rover really is a pet, in one sense, because I "tend" it and sort of take it for walks—I like to have Rover walk in front and let people deal with it instead of me. Then I watch how they try to interact, and add functions to make Rover smarter. That fulfills a kind of feedback loop, in the sense of Norbert Weiner's definition of cybernetics. Some people have parsed our intentions; some even recognize how this Thing has become my "pet" in nearly every sense. But most haven't yet seen the real subtext of how it's only a half-step away from being interactive TV.

People try to reach us, and if Rover doesn't understand a message, it sends back a polite "I have no idea what you're saying, but here's what I understand" response. That fulfills another feedback loop. These loops provide the scientific basis for some kind of AI, turning the list+server into something more than a news pipe or TV broadcast. I could quote from Steven Levy's text on ALife [Artificial Life], but basically these lists/servers/agents are starting to fulfill the criteria.

TF: The implications are indeed staggering, especially when you bear in mind that the predominant trend in Net programming these days seems to be integration of services into integrated "environments." But at this point many people would ask, "Why go to all the trouble? Why hassle to create and continually modify a program that does things humans can do themselves?"

PXN: Because of the level of interest we've generated. There simply is no humanly possible way for us to have a real person answering all the questions. We couldn't afford that—probably ever. If you provide wires, people will pull them. Telemarketing people with their phones and 800 numbers have no idea what's in store for them as the Net grows. We stick in a robot instead; it's a matter of numbers. I could personally respond to only, say, N people with any comprehension and still have time to put food on the table. So I and some associates have a list instead—that reaches N*500. But then even more people try to reach us whenever we get a magazine review, interview, etc., and rather than repeat ourselves silly, we add an intelligent agent. That covers, say, N*5000, provided we supply a help archive of files and hypertext for Rover to draw from.

I receive hundreds of calls/letters/e-mail each week, mostly from people asking for some kind of assistance. If any of those people really needed help they'd be dialing the local emergency number, or in counseling or somesuch, instead of being wired to a terminal. The volume makes all notions of communication with me—except for maybe a half-dozen of my closest friends—surreal.

-- from

TF: How do your customers and readers use the InfoBot?

PXN: Here's a summary of commands for Rover:

subscribe to join the list
unsubscribe to leave the list
list to list the available files
get FILE to send you the file name "FILE"
find KEY to send you a list of files containing "KEY"
help to send you the intro file (same as "get readme")
ping to check whether the list knows your address
daily to receive daily msgs instead of weekly digest
digest to receive weekly digest instead of daily msgs
quit to quit scanning a msg, in case you have a .sig

For example, if you were to send the following message:


get prices

Rover would send back to you a current price list for products listed in our online catalog (which can also be found in the back of Fringe Ware Review).

TF: What are some of your other "pets," and what do they do?

PXN: Well, there's Spewy and Chewy, who handle the basic mailing-list/news-service functions and digest service, respectively. I have one called Nosey, which uses various means to keep tabs on people I like to keep tabs on. I have another named Snoop, which runs the markov chain synthesis for us and updates our "memes" lexicon. It ends up building a lot of cool new words, which we like to think of as the "memetic interstices" of our discussions—a kind of quick-fix for our group narrative. There's a new one called Dopey, which has been learning how to parse error messages from all over the Net. If you think trying to correspond with N thousand people is weird, just wait until hundreds of those addresses start generating multiple bounces on a given day! I'm not aware of any other project like this, but it's a huge problem. As every new host plugs into the internetwork, more and more error reports and new formats spring up.

There's another pet, but it's been pulled for bad behavior. That was my personal agent, sniffer, spider, whatever the word is these days. It looks for any references to things I find interesting—great for research :)—but it chewed up too many system resources and locked up matters, and had to be suspended. Of course, we also have our Gopher and WWW and hope to put in a WAIS server (although we do that function via Rover now), which are all agents in a sense. Source code for all our intelligent agents can be found in our archives.

TF: What sort of communications are not handled automatically?

PXN: Well, I have another personal agent called "Ron Lieberman" who gets politely nasty at times with people who bug me via e-mail....


You can check out Fringe Ware Inc. using any of these methods:

FringeWare Email List:


In text body:


"Rover" (InfoBot):


Include commands in text body.

Anonymous FTP:

...ftp: /pub/fwi



Look under the "commercial" section.


go fringeware




Listserv, written by Eric Thomas, is probably the most widely-used and established mailing-list software. This is true to the extent that many people use listserv as a synonym for any mailing list software, and even in reference to an individual mailing list (for example, "send a message to the Volkswagen owners' Listserv and may be you'll find out whether Beetle or Bug is the official name of that car"). Listserv is the most fully functioning of the packages discussed here. It includes mailing-list management, file services, and database services (not only can you store and distribute archive files, you and your Listserv users can search them using Listserv database capabilities).

Listserv supports interoperation between installations, allowing the production of a global list of mailing lists and subscriptions to any known mailing list via any Listserv installation. Listserv also has a "distribute" feature, which will send one copy of a message to an installation for distribution to those addresses maintained at (or close to) that installation.

For many years, Listserv ran only on IBM mainframe VM/CMS operating systems and was primarily associated with members of the Bitnet network. This association changed somewhat, when Dr. Thomas formed a company called L-Soft International, Inc., for the distribution of a new commericial version of Listserv and a VM/CMS mailer package called LMail. L-Soft has provided Listserv availability for those who are not part of Bitnet.

The first new development on the Listserv front was the release of version 1.8 for VM/CMS, which provided for operation of the Listserv software using TCP/IP protocols. The Bitnet network was originally (and still is, to a great degree) based upon the IBM Remote Spooling Communications Subsystem (RSCS) networking protocols. The Network Job Entry (NJE) portion of RSCS supports the exchange of mail and files on Bitnet for VM/CMS, MVS/SP, and VAX/VMS and other systems running RSCS-emulation software. (Today, most Bitnet traffic is carried via NJE under IP protocols, with transmission occurring mostly over the NSFNet Internet backbone.) The availability of Listserv 1.8 provides the ability to run Listserv independent of an RSCS network (Bitnet, for example).

The second development was the release of Listserv 1.8 for UNIX. The UNIX version will run on AIX, BSDi, Irix, OSF/1, Solaris, SunOS, and Ultrix systems. This version will interoperate with other versions of Listserv on TCP/IP. Existing lists based on VM/CMS systems can be ported to run under the UNIX version of the product. This release brings the Listserv feature set to platforms other than IBM VM/CMS. Versions for VAX/VMS and Windows NT are also announced. Any questions with regard to the availability of these products can be addressed to

The many functions of Listserv are reflected in its command set. Some of these commands may be familiar even if you haven't used Listserv before, since Listserv set a standard in this regard that has been copied by other programs. Because it has been the workhorse of the Bitnet network, Listserv also has the capability to provide information about the node structure of that network (via the SHOW command).

The following is a summary of Listserv user and owner commands through version 1.8. The parameters in braces ({}) are optional. A vertical bar (|) stands for or. Where the meaning of a command is not necessarily evident, a brief description is provided in parentheses. Portions of the commands or options in uppercase represent the minimal abbreviations possible.

User Commands

SUBscribe listname First_name Last_name
SIGNOFF   listname
SET       listname (options
                      FULLhdr -or- FULLBsmtp
                      SHORThdr -or- SHORTBsmtp
CONFIRM   listname {listname} ...
Query     listname
Query     *
REGister  First_name Last_name
REGister  OFF
Commands to find out information about a list, lists, or BITNET
INDex     listname
Info      topic
Lists     {option}
           Global /string
           SUMmary node
           SUMmary ALL
           SUMmary TOTAL
Query      File fn ft filelist options
Query      FLags
REView     listname {(options}
                        BY sort_field
                        BY (sort_field sort_field)
SHOW       {function}
            ALIAS node {node} ...
            DPATHs node {node} ...
            DPATHs *
            LINKs node {node} ...
            NADs node node ...
            NODEntry node node ...
            NODEntry node /string*/string
            PATHs node node {node} ...
SCAN       listname string
STats      listname {(options}
THANKs    (check status of server)
AFD        ADD fn ft filelist prolog (Automatic File Distribution)
AFD        DELete fn ft filelist
AFD        List
AFD        FOR address ADD|DEL|LIST      (node administrators only)
FUI     (File Update Information)
GET        fn ft filelist {(options}
                                   PROLOGtext text
GIVE       fn ft filelist {TO} address
INDex      {filelist}
PW         function
            ADD pw
            CHange newpw PW=oldpw
            DELete oldpw
SENDme     fn ft filelist {(options}
                                  PROLOGtext text
DATAbase   function
           Search DD=ddname {ECHO=NO}
           REFRESH dbname
DBase      function
           Search DD=ddname {ECHO=NO}
           REFRESH dbname
DISTribute type   source  dest    options
                              {TO} address {address} ...
                              {TO} DD=ddname
FOR        address command
SERVE      address
UDD        (User Directory Database)

Mailing List Owner Commands

AFD        GET fn ft {filelist}
FUI        GET fn ft {filelist}
GET        fn filelist {options}
PUT        fn ft {filelist parms}
                                 RECFM=F {LRECL=nnn
                                 TITLE=file title
REFRESH    filelist {(options}
UNLOCK     fn filelist
{QUIET} ADD        listname address first_name last_name
{QUIET} ADD        listname DD=ddname
{QUIET} ADDHere    listname address first_name last_name
{QUIET} ADDHere    listname DD=ddname
{QUIET} DELete     listname address {(options}
{QUIET} MOVE       listname address {TO} node
{QUIET} MOVE       listname DD=ddname
{QUIET} SET        listname options {FOR address}
{QUIET} SET        *          options {FOR address}
EXPLODE    listname {(options}
                        BESTpeers n
                        FOR node
                        PREFer node
                        With(node {node} ...)
                        WITHOut(node {node} ...)
FREE       listname {(options}
GET        listname {(options}
HOLD       listname {(options}
PUT        listname LIST
Query      listname FOR address
Query      *          FOR address
STats      listname (RESET
UNLOCK     listname

Listserv Installation and Management

After it is acquired, Listserv will need to be installed by the system administrator. A separate individual can be set as the Listserv manager (the LISTSERV POSTMASTER), with the ability to create and modify mailing lists, and, if necessary, shut down and restart the Listserv software. List owners, once defined, also have a great deal of control over their list. A new list is created by the Listserv manager through creation of a file defining the list configuration parameters. The file name matches the mailing list name and the file type (CMS systems) is list. The LSVPUT command is used to create the new list within the Listserv system. Configuration options are the same as seen in the header of a REView command.

The following shows an example configuration for the Listserv mailing list NETMONTH, used to distribute an electronic periodical.

*  NetMonth Magazine
*  Newsgroups= bit.listserv.netmonth
*  Review= Owner     Subscription= Open         Send= Owner
*  Notify= No                                 Files= Yes
*  Validate= Store Only
*  Stats= Extended,Public    Ack=MAIL
*  Errors-To= Owners
*  Reply-To= "Dr. Philip Baczewski <NMONTHED@UNTVM1>",Respect
*  Renewal= Yearly
*  Local= MARIST*
*  Notebook= Yes,E,Separate
*  Owner=  NMONTHED@UNTVM1  (Dr. Philip Baczewski)
*  Owner=  XXXXX@XXXXXX   (A. Harry Williams)
*  Owner = quiet: <XXXX@UNTVM1> (Dr. Philip Baczewski)
*  Owner = <> (Dr. Philip Baczewski)

A Closing Word on Listserv

Listserv is surely testament to the fact that a good idea, implemented well, will go a long way. With the Listserv mailing list count above 5000, Listserv's place within the arena of international networking is well-established. One factor in the success of Listserv has been its association with the Bitnet network. Bitnet, while in some ways technologically primitive, was easy and inexpensive to connect to and thus grew to include many U.S. colleges and universities. The free access to Listserv software by these sites led to the establishment of a service that has grown far beyond the Bitnet network. It remains to be seen what effect the commercialization of the Listserv software will have on the maintenance of its role as a leader in list-management services. The freeing of the software from the exclusive dominions of IBM's VM/CMS software environment, however, should have a positive effect on Listserv's continued proliferation.

Some Aspects of Setting up Your Own List

There are several good discussions about setting up a mailing list available in print or electronic format (the file LISTSERV TIP, available from or the file or Diane Kovac's LISTS START-UP file available from listserv@uottawa.bitnet, for example). While these sources provide technical and organizational advice for starting a mailing list, there are several other factors which can be important. One of these is the type of forum you choose for your list.

Choosing a Forum

The success of a forum may depend upon the intended audience and can range from the very controlled to the fully open. Your choice may depend upon the ratio of "signal" to "noise" that is tolerable by you and your subscribers. On a mailing list, "signal" is messages and information pertinent to the list topic, while "noise" is inappropriate or inadvertent posts (like signoff commands, messages like "Bill, got your message on the mailing list—How are the kids—," or comments like "Wow, how about that perfect game by Texas Ranger Kenny Rogers!"—except if that last one is sent to a sports-related mailing list).

The types of mailing lists, going from most signal to least, can be classified as follows:

Electronic journal

The most signal, because the content is generally controlled by an editor or editorial board; the least spontaneity and serendipity, since general posts are not allowed.

Mailing list digest

Incoming messages are screened, and the most pertinent messages are posted in groups to the mailing list.

Moderated list

Incoming messages are screened by a list moderator and only those pertinent to the list topic are distributed to list subscribers.

Open list

All incoming messages are redistributed to the entire list of subscribers (usually the most noise).

Not all open lists are noisy. If you have a group of dedicated and knowledgeable subscribers, the level of signal can be quite high. Some groups, however, will be unable to tolerate even the slightest level of noise. This seems to be true of college professors subscribed to scholarly mailing lists. Perhaps it's because a high signal level in publications is so intrinsic to the academic environment. Obviously, the intentions for which the list was created will also dictate the tolerable level of noise. A general discussion forum provides more leeway than one on a very specific topic.

Mailing Lists and Usenet

The interaction of mailing lists and Usenet news is continually on the rise. Often the largest possible audience will be available via both facilities. There are a number of ways that information can be cross-posted. Piping selected information from Usenet can be an important service for those without Usenet access. Providing mailing list access via Usenet allows people to read messages without having to subscribe and receive all messages.

Usenet Digests

Perhaps one of the easiest ways to share information between Usenet and a mailing list is via a digest. Interesting Usenet posts can be gathered and redistributed to a mailing list. It takes the work of a digest editor to accomplish this task, but a news system's built-in features can make it a simple one (log or concatenate posts to a single file and redistribute that file to the mailing list, for example). Because of the extra work involved and the one-way flow of information, this technique is usually more appropriate for a special-interest area than a general discussion list.

Usenet Echoes

Numerous mailing lists are echoed on Usenet or vice versa (chicken versus egg, you know). The largest single collection of these is located in the bit.listserv news hierarchy, which, as its name indicates, gateways numerous Bitnet Listserv mailing lists to Usenet. Mailing list and Usenet pairs also exist in the alt, comp (numerous), rec, soc, sci, and vmsnet hierarchies. David Lawrence ( maintains a list of gatewayed newsgroups that is posted to bit.admin on a monthly basis. Jim McIntosh ( at The American University runs a gateway for most of the bit.listserv hierarchy. That gateway is bidirectional, but other gateways might be one way only.

It is possible to set up your own gateway by having your news server subscribe to a mailing list the way a regular user would. There are some procedural items to follow. You will need to get permission from the mailing list manager (if it is not you) and also get appropriate approval from the Usenet hierarchy. It is also advisable to get agreement from the list members before expanding the distribution scope of their messages. More information in this regard can be found in a policy document that is regularly posted to bit.admin or by posting inquiries there or to the mailing list

For More Information[el]

More information on mailing list software or its use can be found via the following Internet services:

Majordomo-Users on

Majordomo-Announce on

(Listproc 7 discussion)

unix-listproc on

(Listserv mailing-list owners)

(Listserv Review)

(Listserv discussion list)

(Listserv evaluation package discussion list)

(Listserv maintainer's list)

UseNet: bit.admin

(Listserv lists posted to Usenet)

Usenet: news.lists

Previous Page TOC Index Next Page Home