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.
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.
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 risc.ua.edu in the /pub/network/pegasus directory.
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?
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
|
Subscribe to the indicated mailing list |
|
UNSUBSCRIBE listname
|
Sign off from the mailing list |
|
ENUMERATE listname
|
Receive a listing of mailing list members |
|
LIST |
Receive an inventory the mailing lists available at this host |
|
HELP |
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) |
|
INDEX |
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) |
|
BOUNCE |
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. |
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 (neale@acs.unt.edu), 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.
#
[General]
myname: acs.unt.edu # 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
[Mercury]
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: ricevm1.rice.edu # 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
[MercuryC]
host: 129.120.1.1 # 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
return
failfile: SYS:SYSTEM/MERCURY/FAILURE.MER # Delivery failure template
timeout: 300
[MercuryS]
switch: 1
debug: 1 # Whether or not to show session progress
discard: 20000
[MercuryP]
scratch : SYS:SYSTEM/MERCURY
switch : 2
[Groups]
# Alias for group Actual NetWare group name
[Domains]
# NetWare Server Domain name
ACS : acs.unt.edu
ACS : ACS
[Maiser]
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"
;
gcba-l
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
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.
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 ftp.greatcircle.com,
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.
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 majordomo@listsite.internet.site (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 |
|
lists |
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:
|
help |
Returns a informational help file; |
|
end |
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.
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 owner-list_name: owner@somenode.com list_name-request: "|/majordomo/wrapper request-answer list_name" list_name-approval: owner@somenode.com
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 list_name.info, containing the list's welcoming information. Other variations are described in Majordomo's documentation, and sample configurations are included.
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 (tasos@cs.bu.edu). 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 (cs.bu.edu, 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 listproc-info@listproc.net or cren@cren.net.
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}
mail ACK|NOACK|POSTPONE|DIGEST
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}
-or-
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 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.
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.
"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 pacoid@io.com, 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 metaverse.io.com 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 io.com/usr/ftp/pub/fwi/STAFF/pacoid.bio
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:
To: fringeware-request@io.com
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:
mail fringeware-request@io.com
In text body:
subscribe
"Rover" (InfoBot):
mail fringeware-request@io.com
Include commands in text body.
Anonymous FTP:
Gopher:
gopher io.com
Look under the "commercial" section.
The WELL:
go fringeware
Mosaic:
...http://io.com/commercial/fringeware/home.html
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 sales@lsoft.com.
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.
SUBscribe listname First_name Last_name
SIGNOFF listname
SIGNOFF *
SIGNOFF * (NETWIDE
SET listname (options
ACK|NOACK|MSGack
CONCEAL|NOCONCEAL
Files|NOFiles
Mail|NOMail
REPro|NOREPro
FULLhdr -or- FULLBsmtp
IETFhdr
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
nodes:
Help
INDex listname
Info topic
Lists {option}
Detailed
Global
Global /string
SUMmary node
SUMmary ALL
SUMmary TOTAL
Query File fn ft filelist options
Query FLags
RELEASE
REView listname {(options}
BY sort_field
Country
Name
NODEid
Userid
BY (sort_field sort_field)
Countries
LOCal
MSG
NOHeader
Short
SHOW {function}
ALIAS node {node} ...
BITEARN
DISTribute
DPATHs node {node} ...
DPATHs *
FIXes
LINKs node {node} ...
NADs node node ...
NETwork
NODEntry node node ...
NODEntry node /string*/string
PATHs node node {node} ...
STATs
SCAN listname string
STats listname {(options}
LOCal
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}
List
REFRESH dbname
DBase function
Search DD=ddname {ECHO=NO}
List
REFRESH dbname
DISTribute type source dest options
MAIL
FILE
RFC822
DD=ddname
{TO} address {address} ...
{TO} DD=ddname
ACK=NOne|MAIL|MSG
CANON=YES
DEBUG=YES
INFORM=MAIL
PRIOR=nn
TRACE=YES
FROM=address
FROM=DD=ddname
FOR address command
SERVE address
UDD (User Directory Database)
AFD GET fn ft {filelist}
FUI GET fn ft {filelist}
GET fn filelist {options}
CTL
NOLock
PUT fn ft {filelist parms}
NODIST
CKDATE=NO
DATE=yymmddhhmmss
PW=pw
RECFM=F {LRECL=nnn
REPLY-TO=address
REPLY-TO=NONE
REPLY-VIA=MSG
TITLE=file title
REFRESH filelist {(options}
NOFLAG
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}
GLobal
LOCal
TEST
{QUIET} MOVE listname address {TO} node
{QUIET} MOVE listname DD=ddname
{QUIET} SET listname options {FOR address}
{QUIET} SET * options {FOR address}
NORENEW|RENEW
EXPLODE listname {(options}
BESTpeers n
Detailed
FOR node
PREFer node
SERVice
With(node {node} ...)
WITHOut(node {node} ...)
FREE listname {(options}
GLobal
GET listname {(options}
GLobal
HEADer
NOLock
OLD
HOLD listname {(options}
GLobal
PUT listname LIST
Query listname FOR address
Query * FOR address
STats listname (RESET
UNLOCK listname
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 * * Mail-Via= DISTRIBUTE * * 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 = <NMONTHED@vm.acs.unt.edu> (Dr. Philip Baczewski)
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.
There are several good discussions about setting up a mailing list available in print or electronic format (the file LISTSERV TIP, available from listserv@bitnic.educom.edu 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.
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.
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.
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.
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 (tale@uunet.uu.net) maintains a list of gatewayed newsgroups that is posted to bit.admin on a monthly basis. Jim McIntosh
(jim@american.edu) 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 new-admin@american.edu.
More information on mailing list software or its use can be found via the following Internet services:
|
Majordomo-Users on majordomo@greatcircle.com | |
|
Majordomo-Announce on majordomo@greatcircle.com | |
|
cren-list@yukon.cren.org |
(Listproc 7 discussion) |
|
unix-listproc on listproc@avs.com | |
|
lstown-l@uga.cs.uga.edu |
(Listserv mailing-list owners) |
|
lstrev-l@uga.cs.uga.edu |
(Listserv Review) |
|
lstsrv-l@uga.cs.uga.edu |
(Listserv discussion list) |
|
lstsrv-e@searn.sunet.se |
(Listserv evaluation package discussion list) |
|
lstsrv-m@searn.sunet.se |
(Listserv maintainer's list) |
|
sales@lsoft.com | |
|
support@lsoft.com | |
|
UseNet: bit.admin |
(Listserv lists posted to Usenet) |
|
Usenet: news.lists |