Listserv
List Owner's Survival Guide
Copyright TERENA 1995
Version 1, April 1995
This guide was written by staff members of TERENA (formed by the merger
of EARN and RARE), and is part of the series of documentation on Revised
Listserv which was originally undertaken by the EARN Association.
The List Owner's Survival Guide is a short document but it contains the
most important information that list owners need to know. It is not
however a comprehensive manual and does not cover all details of owning
a Listserv list.
The List Owner's Survival Guide is based on the original documentation
for Revised Listserv which was written by Eric Thomas, and on Eric's
release notes for later versions. The commands and keywords are correct
for Listserv version 1.8a. This guide has been checked with the NJE
version of Revised Listserv for VM, but it should be accurate and
suitable for use with other versions of Listserv as well.
Table of Contents
Chapter 1 - Introduction and background
1.1 Introduction
1.2 History and background
Chapter 2 - Overview
2.1 Starting a Listserv list
2.2 Maintaining a list
Chapter 3 - Commands for List Owners
3.1 Commands for list membership functions
3.2 Commands for list maintenance functions
Chapter 4 - The List Header File
4.1 The List Header File
4.2 The list header keywords
4.3 List name and address keywords
4.4 List membership keywords
4.5 List traffic keywords
4.6 List management keywords
4.7 List mail headers and body keywords
4.8 Other keywords
Chapter 5 - Annotated examples of list headers
5.1 Open international list
5.2 International peered list
5.3 International professional list
5.4 Private organisation's list
5.5 List on non-VM, non-NJE server
Chapter 6 - Other sources of information
6.1 Listserv lists
6.2 Basic Listserv documentation set
6.3 Listserv Release Notes
6.4 Listserv documentation from the EARN Association
6.5 Other documentation files
6.6 Usenet newsgroups
Chapter 1 - Introduction and background
1.1 Introduction
All Listserv lists have at least one owner, who has various
responsibilities towards the list and its users. The owner is usually
the person who wanted to start the list in the first place.
All Listserv servers have a maintainer, and he or she must decide
whether or not new lists can be accommodated on their server. A list
owner's first job is to persuade a Listserv maintainer to set up the
list on their Listserv server, and to undertake to maintain it there.
Server maintainers are responsible for the smooth running of the
Listserv software, and take care of any hardware decisions to do with
the list. The maintainer creates a list header file for each new list,
which the listowner can configure.
Each list owner is expected to keep a close eye on the mail distributed
to list members, even if the list membership is not restricted. The
owner must sort out any problems which may arise, such as loops, or
unsuitable messages, and may need to referee arguments and call a halt
to slanging matches! Some list owners choose to vet all mail which is
sent to a list, before allowing it to be distributed to list members.
If list membership is restricted, the list owner must vet all
subscription applications and respond to them within a reasonable time.
Lists which have a large membership can be divided into two or more
smaller lists, to be stored on two or more servers. These new smaller
lists are called peered lists; they have the same name and distribute
the same messages, but each server stores a different set of members.
Mail sent to a peered list is automatically distributed to the
membership list of each of its peers. When a list starts to get large,
it is up to the listowner to look for another Listserv server whose
maintainer is willing to host a peered list, and then to move some users
from the present list to the new peer.
Listowners must decide whether the list's messages will be archived on a
daily, weekly or monthly basis, or perhaps not at all. Listserv will
create a filelist based on the archive's contents, and will send it to
users in response to requests.
Other files can be stored on the filelist, and further filelists can be
created.
Chapter 2 of this guide describes in more detail how to set up a new
list and the tasks involved in maintaining it. Commands are provided to
help you carry out these tasks, and they are described in Chapter 3. The
start of the list header file is used to specify various aspects of the
list's operation, using keywords; the keywords and their values are
described in Chapter 4. Examples of header files from different types of
list are given in Chapter 5. Additional sources of information on
Listserv are given in Chapter 6.
1.2 History and background
Listserv was devised by the Bitnet Information Centre (BITNIC).
Originally there was only one server, which managed all the mailing
lists. Each list addressed a specific subject area and had an
independent set of list members. For example, para-psychologists who
were interested in the topic of near-death-experiences could establish
their own mailing list. Users from across the network who wished to
subscribe to this list could then do so by having their e-mail address
added to it. The Listserv server would subsequently distribute a copy of
any e-mail sent to this list to each of the list members.
The Listserv concept was later adopted and modified by Eric Thomas, who
produced a new version of the server - Revised Listserv - which included
many new and powerful features.
A fundamental improvement was that instead of one centralized Listserv
server controlling all the mailing lists, Revised Listserv is based on
many Listserv servers across the network, each managing their own,
independent set of lists. There is a high degree of inter-server
cooperation, so the benefits of a centralized service are retained,
while the efficiency and robustness of the service are improved. Each
mailing list is managed by one out of a number of different servers,
each server located at a different computer site. However, global
commands sent to one server are automatically propagated to all the
other Listserv servers on the network - for example, a global
sign-me-off-all-lists command will operate on all the lists on the
network.
Revised Listserv also introduced peered lists, which are created when
the membership of a large mailing list is divided between one or more
Listserv servers. Mail sent to a peered list is automatically
distributed to the membership list of each of its peers.
The decentralized topology of Revised Listserv resulted in the
development of powerful mail distribution algorithms which significantly
reduced the overall electronic mail traffic load on the EARN/BITNET
network, providing a fast and efficient service to all Listserv users.
All requests for subscription to or removal from mailing lists stored on
the original Listserv server had to be processed by the Listserv
administrator. As the popularity of the server increased, this
inevitably led to delays. Another major enhancement was the addition of
a command processor so that commands could be sent directly to any
Listserv server, which could process them without the intervention of a
human administrator. This not only reduced the administrative overhead
of the server but also ensured that the members of each list were an
up-to-date and interested audience.
Revised Listserv also introduced a database for each mailing list,
called a notebook database or list archive. This can hold a copy of
every mail message distributed on a mailing list, so that users can
search for and retrieve old mail messages. Revised Listserv servers can
also be used as file servers, to store files which are not connected
with any individual mail list. The server can be used as a central file
repository which can be interrogated and can respond to retrieval
requests from any user. Listserv users can also subscribe to files, so
that they will be informed of file updates or will automatically receive
an updated copy of a file. Another function added to Listserv was that
of a network information server. Information available on each server
includes details of individual EARN/BITNET computer sites, and of the
overall configuration of the network.
Chapter 2 - Overview
This chapter gives an overview of the tasks involved in starting up a
Listserv list, and in maintaining a list.
2.1 Starting a Listserv list
Does a list exist already?
A Listserv list called New-List, at vm1.nodak.edu (NDSUVM1.BITNET),
contains announcements about lists which are maintained on all the major
list management packages. This is a good place to look to find out
whether there is already a list dealing with a specific subject, and to
find a Listserv node willing to open a new list.
You should also get the file LISTSOFLISTS, available from
listserv@vm1.nodak.edu, for information on getting listings of
discussion lists on the net.
Which mailing list management software to use
This is usually the decision of the site at which the list will be
managed. For a discussion of the various possibilities, see the mailing
list management FAQ mentioned in Chapter 6.
This guide describes Revised Listserv.
Find a host Listserv
You need to find a host Listserv computer which will store and operate
your new list. It is very important that your email connection to the
host is quick and reliable, and that you and any other list owner(s)
have the cooperation of the Listserv postmaster, who will have several
tasks to carry out connected with your new list. Most sites have one
main postmaster and others who are also given postmaster rights so that
they can deal with problems when the main postmaster is not available.
In addition to the original version of Listserv for sites with NJE
connectivity, there is also a version of Listserv for sites with TCP/IP
connectivity only. A list of all the nodes running Listserv NJE can be
obtained by sending the following command to any Listserv:
GET PEERS NAMES
For a list of all nodes running Listserv TCP/IP send the command:
GET INTPEERS NAMES
You will receive files containing vital information about all the
Listserv host computers, including the institution which operates each
one, its location, and the name and electronic mail address of its
postmaster. You can use this information to select a suitable Listserv
server, and then contact its maintainer to ask whether that site is
willing to accept your proposed list.
You can also send a note to the NEW-LIST and LSTSRV-L mailing lists (see
Chapter 6) asking what site is willing to host your list. A number of
companies are also willing, for a fee, to set up mailing lists and even
to manage lists.
Establish the new list
A few actions must be performed at the Listserv site, by the Listserv
maintainer or other authorised personnel, to establish the list and to
allow it to receive and distribute mail.
1. A list header file for the new list must be installed in Listserv.
2. Some steps must be taken to ensure that mail which arrives for the
list will be correctly processed. In VM, a "dummy" account (i.e. an
account with no resources assigned to it) should be opened for the list.
When mail arrives addressed to this account, Listserv grabs it for
further processing. IBM VM/CMS user names can be no more than 8
characters, hence in VM each list must have a short name of 8 characters
or less. In addition, a longer name (up to 32 characters) can be given
to the list using the List-id keyword (see Chapter 4).
Publicise the new list
The success of any list depends on its membership, so one of the owner's
first jobs is to ensure that potential members are made aware of the
list's existence. The best place to advertise the establishment of a new
list is through existing related lists, but you should also make use of
any other sources of information for the target community.
Introductory letter
Listserv sends an introductory letter to each new member joining a list.
By default this will be a general letter containing administrative
information about the list; it is up to the list owner to write
something more informative if this is appropriate. Since this letter is
sent to people who have already joined the list, it should not include
instructions on subscribing. The owner can use it to lay down the ground
rules for list correspondence, and to set the proper tone for
discussions. The introductory letter for the list should be sent to the
postmaster, who will put it on the server as a file called `listname
MAILTPL'. Any owner can also set up a
`Welcome' letter to be distributed to new list members in addition to
the introductory letter.
2.2 Maintaining a list
The list header file
All the information specific to a Listserv list is stored in a header
file, which Listserv consults when processing mail addressed to a list.
The header file contains the list's name, a description of the list,
various configuration settings, a list of members' names and addresses,
and other status information for individual list members.
Here is a sample header file:
* Official List Title
*
* List-id= long-list-name
* Review= Public
* Subscription= Open
* Send= Editor
* Reply-to= Sender,Respect
* Confidential= Service
* Service= NOD*,*.sub.do.main
* Editor= USERID@some.domain.name
* Notebook= Yes,A,Monthly,Public
* Errors-To= Owner
* Password= not2reveal
* Owner= own1@NODE (First Owner's Name)
* Owner= own2@COMP.UNI.DOMAIN (Second Owner's Name)
*
* This is the place to put a lengthy description of the list and
* its activities, so that anyone using the REVIEW command will be
* able to decide if this list is worth joining.
*
MEMBER1@ANODE Member1's Name
MEMBER2@BNODE Member2's Name
All lines before the list member names and addresses must begin with an
asterisk (*). More than one parameter may be listed on the same line.
Keyword parameters which are not given values in the header file will
take default values.
This sample does not contain all the available keywords and parameters.
A complete list of these, with their default values and other possible
values, is given in Chapter 4. Several examples of list headers are
given in Chapter 5.
Some comments on the header file settings
Some keywords affect the information that Listserv gives about the list,
some affect the audience and level of participation in a list, some
affect the distribution of list traffic, and some determine the rights
and responsibilities connected to the list. New list owners must change
some of these values, and should be aware of the existence of the
others, and be aware that they can change them if necessary.
Changing header file settings
The keywords and their parameters at the head of the header file can be
changed by the list owner, or by the postmaster, using any standard text
editor. Caution should be exercised in editing the name and address
information in the list header file because Listserv stores status
information about each user in the rightmost columns of each name and
address line.
The command to obtain a copy of the header file is GET, and the command
to return it is PUT. These commands are described in Chapter 3.
The list owner will probably want to change the following settings:
The list title
Listserv assumes that the first non-blank character line contains the
official title of the list. This is the name which will appear, together
with the list's electronic mail address, on all mail which LISTSERV
distributes for the list and in all LISTSERV lists of lists. The title
should be informative, but short enough to fit on the same line in the
mail header as the network address. For example, if this were the header
file for list NAV-L at vm.earn.net and the official title was "Interest
Group in Omphaloskepsis", then all mail dis would contain the header
line:
Sender: Interest Group in Omphaloskepsis <NAV-L@vm.earn.net>
Information about the list
When a user sends a Review command, Listserv returns a message
containing all the 'asterisk' lines from the list's header file. It also
checks the Review parameter to see if the list of members should also be
sent.
The Confidential parameter determines whether the list will appear in
Listserv's list of lists. In the above header file example, the list
will be visible only to users within the list's service area, in this
case any computer in Bitnet whose node name begins with "NOD" (e.g.
NODEVM) or any computer in the domain ".sub.do.main" (e.g.
vms.sub.do.main).
Should the list have a password?
A password for the list is optional, but recommended. Make sure fellow
owners know it.
Should subscription be automatic?
Many lists do not limit subscriptions, and new users can join them
without the intervention of the list owner. On the other hand, a list
owner might want to limit, filter, or even prohibit subscriptions to a
particular list. This is done using the Subscription keyword.
Who can mail to the list?
The list owner must also specify criteria which Listserv will use to
process incoming mail. The Send parameter determines whether all mail
sent to the list will be forwarded to a list editor, and is also used to
specify who can send mail to the list. Permission to mail to the list
can be given to an individual, a group, users from a specified group of
computers, or everybody.
What "Reply-to:" address should be used?
Mail systems derive a return address from either the "From: ", "Sender:
", or "Reply-to: " fields in the incoming message; most mail systems
will use the "Reply-to: " field if it exists (this is the correct
behaviour according to the standards). Listserv's Reply-To parameter
indicates whether this field should contain the address of the list or
the address of the original sender, and whether to respect any
"Reply-to: " line in the original sender's message, or to replace it.
Should messages be archived?
The Notebook parameter determines whether messages will be stored in an
archive, and where in the Listserv host's disk space the archive will be
stored. It also indicates whether new archive files should be opened on
a yearly, monthly, weekly, or daily basis, or in a separate file for
each transmission. Archived messages can be retrieved by users, and the
archives can be searched using Listserv's database facility.
Who should get error messages?
Inevitably, some list messages for some list members will not reach
their destination, because the member's computer account is closed or
the computer is removed from the network or the mail system is
configured incorrectly or countless other problems, some temporary, some
permanent. When this happens an error message is usually sent back to
the list. Listserv employs various methods to identify these error
messages so that they won't be distributed to all list members. It is
usually the responsibility of the list owner to receive these error
messages and take action (delete the member from the list, change
appropriate members' settings to Nomail, or wait for further
developments).
Chapter 3 - Commands for List Owners
This chapter describes the Listserv commands which are available for use
by list owners. The commands are presented in two groups: those covering
list membership functions and those covering list maintenance functions.
Upper case letters are used in command descriptions to indicate valid
abbreviations of the command names.
3.1 Commands for list membership functions
These commands enable owners to manage the membership of their lists:
add members, remove them, view and change members' personal list
options, and move members between peer lists.
------------------------------------------------------------------------
ADD Add a user to one of your lists or to a peer
ADDHere Add a user to one of your lists, but not to a peer
EXPLODE Optimize the placement of members among peers
MOVE Move members from one peer to another
Query ... FOR ... View the settings of a list member
SET ... FOR ... Change the settings of a list member
QUIET Don't send notification to command target
------------------------------------------------------------------------
ADD listname userid@node <full_name> <PW=list_password> <DD=ddname>
Add a user to one of your lists. The list password need only be
specified if the list is protected by the "Validate= Yes" keyword, and
the command is issued from a remote node. The user will automatically
receive notification unless you use the QUIET command prefix.
The user's full name need not be given if the user is already known to
your Listserv server.
If the address specified is already subscribed to the list, the full
name specified will replace any previous full name associated with that
address.
Listserv will automatically check that there is no closer peer list for
the user. If there is one, the command will be automatically forwarded
to that server. You can use the ADDHERE command to override this
automatic command forwarding.
The "DD=ddname" syntax provides an efficient method of adding many new
users to your list at once. "ddname" is the name of a list which should
contain one "userid@node <full_name>" per line.
ADDHere listname userid@node <full_name> <PW=list_password> <DD=ddname>
This command is the same as the ADD command, except that Listserv will
not check to see if there is a closer peer list.
DELete listname userid@node <(options> <PW=list_password>
Remove a user from one of your lists. The user will automatically
receive notification unless you use the QUIET command prefix. The
wildcard '*' can be used to delete several members at once. The list
password need only be specified if the list is protected by the
"Validate= Yes" keyword, and the command is issued from a remote node.
The options are:
GLobal forward the delete request to all peers
LOCal don't forward to peers
TEST don't actually delete, just report what the results of the
command would be; this is useful when using wildcards
EXPLODE listname <(options> <F=fformat>
Analyse the optimal placement of list members among the various peers of
a particular list. This command can only be used for lists which have
the "Peers=" keyword defined in the list header (see Chapter 4). The
"With" option can be used to include in the analysis nodes which do not
at present host peered lists.
Listserv will create a commands-job file containing the necessary MOVE
command (see below) to transfer all users for whom a better peer has
been found. This file will then be sent to you so that you can look at
it before sending it back to Listserv for execution. The file will be
sent by email to non-NJE addresses, so there is usually no need to use
the "F=" parameter to specify the format in which the file will be sent.
An explanation of the possible values for this parameter is given in the
EARN Listserv Users Guide.
The options are:
BESTpeers n suggest the N best possible peers to add
Detailed provide a more detailed analysis
FOR node perform analysis from viewpoint of 'node'
PREFer node peer to prefer in case of equidistant peers
SERVice check that service areas of peers are respected
With(node1 <node2 <...>>>)
assume that specified nodes are peers
WITHOut(node1 <node2 <...>>>)
assume that specified nodes are not peers
MOVE listname user <TO> node <PW=list_password> DD=ddname
Move users from one peer server to another. The user will automatically
receive notification unless you use the QUIET command prefix. The
complete user entry will be moved including full name and personal list
options. If the source and target list names are identical, only the
target node need be specified. Otherwise, the full network address of
the target list must be given. The source and target lists must have the
same password. For security, the MOVE command will only be accepted for
lists which have a list password.
Query listname FOR user
View the personal list options of members of a list you own. The '*'
wildcard can be given in the user address to view the settings of
several list members, including concealed members (e.g. use *@* to get
the personal list options of all members). You can also use this
wildcard in the listname to view the personal options of a user (or of
several users) on all the lists that you own.
SET listname options FOR user <PW=list_password>
Change the personal list options for a member of a list that you own.
The user will automatically receive notification unless you use the
QUIET command prefix. Wildcards can be given in the user address to
change the options of several list members, including concealed members
(e.g. use *@* to change an option for all members). You can also use
wildcards in the listname to change an option of a user (or users) on
all lists that you own. An explanation of the personal list options is
given in the EARN Listserv Users Guide.
The following option can be set by list owners only:
NORENEW waive the need for periodic confirmation of subscription by a
member of a list. This exemption can be cancelled using the
RENEW option.
QUIET command-text
Suppress the sending of notification mail to the command target. For
example, you can use "QUIET DEL ..." to prevent notification mail from
being sent when you remove a list member whose computer account has been
closed.
3.2 Commands for list maintenance functions
These commands enable owners to manage the list header and the
functioning of their lists.
------------------------------------------------------------------------
GET listname Get a copy of the list header file for editing
PUT Replace the list header file for your list
HOLD Prevent postings to a list from being processed
FREE Negate HOLD; release postings for processing
UNLOCK Unlock a locked list
STATs ... RESET Reset the statistics on list traffic
------------------------------------------------------------------------
GET listname <(options> <F=fformat> <PW=list_password>
After using a GET command, you will be sent a copy of the list header,
which you can then edit, and the file on the server will be locked so
that no changes can be made to it until it is unlocked again. With the
list locked, you need not fear that another list owner or postmaster
will modify the header at the same time as you do, thus cancelling your
changes, nor that users will join or leave the list or change their
personal list options during this time; any such changes would be
negated when you put your copy of the list header back.
You will be sent the raw, unformatted list header file which you can
edit using a text editor. You can change users' name or address
information, but you must be careful not to alter the contents of
columns 81-100 of the file where the personal list options are stored.
The file will be sent by email to non-NJE addresses, so there is usually
no need to use the "F=" parameter to specify the format in which the
file will be sent. An explanation of the possible values for this
parameter can be found in the EARN Listserv Users Guide.
If the list is protected by a password (Chapter 4 includes an
explanation of the "PW=" keyword), you must use the PW= parameter in
your GET command.
The options are:
GLobal Forward the GET request to all peers.
HEADer Send just the header, i.e. the lines beginning with an
asterisk (*) and not the names and addresses of the members.
There are several advantages to this: the file sent will be
small; you will not ruin the information in columns 81- 100 of
the lines with names and addresses; when the list header is
put back it will be processed faster.
NOLock Do not lock the list - useful if you do not intend to make
changes to the list.
OLD Get the previous copy of the list (which is kept by Listserv
for backup).
PUT listname <PW=list_password>
Replace the information in the list header file. The PUT command must be
the first line of the mail message body or file which contains the
header file on its way back to Listserv. The password of the list can be
changed by adding a "PW= newpassword" keyword in the list header. If
this keyword is not present, the old password will be retained.
The names and addresses held in the header file will be automatically
re-formatted and sorted by node, so you do not have to worry about
inserting new names in the right order and at the right column.
Listserv will check the validity of the keyword values before replacing
the old version of the list header. If more than one "PW=" keyword is
found, or if a user is found to be subscribed twice to the list, the PUT
operation will be rejected and the old list will be retained. If this
happens, an email message is sent to the list owner explaining that the
PUT command has been rejected.
HOLD listname <(GLobal> <PW=list_password>
Suspend distribution of messages sent to the list. A note is sent to the
sender indicating that the message is being held. Held messages are
released and distributed to list members when a FREE command is received
(see below).
The GLobal option causes the HOLD command to be forwarded to all peer
servers.
FREE listname <(GLobal> <PW=list_password>
Release all messages held as a result of a previous HOLD command (see
above).
The GLobal option causes the FREE command to be forwarded to all peer
servers.
STats listname (RESET <LOCal> <PW=list_password>
Reset the statistics on list traffic. This command is automatically
forwarded to all peer servers, unless the LOCal option is used.
UNLOCK listname <PW=list_password>
Unlocks a list; useful if a list has been inadvertently left locked. A
successful PUT command automatically unlocks the list, so the UNLOCK
command is not normally needed. This command should be used only after
having checked with all the list owners and postmasters that no
modification is pending.
Chapter 4 - The List Header File
4.1 The List Header File
The names and addresses of a Listserv list's members are stored in a
file, which is stored on a Listserv server. This file also contains list
configuration information.
The configuration information is given at the start of the list header
file, on lines which must start with an asterisk. The first line must
hold the list's official title, and succeeding lines hold list keywords
(usually referred to as list header keywords) and their values. Any
words followed by an equals sign (=) are assumed to be keywords. When
all the keywords have been specified, it is usual for the next few lines
to contain a description of the list.
The rest of the file consists of name and address information for each
member of the list. These are given in the first 80 columns of lines
which do not start with asterisks. Listserv stores information about
each member's options and status on the same lines as the name and
address information, but to the right of column 80.
4.2 The list header keywords
The list header keywords and the possible values their parameters can
take are described below; default values are given at the start of each
description. Some parameters are used by several keywords, so the values
these parameters can take are described first. Where a parameter value
needs to be provided by the list owner, the parameter is shown in
uppercase.
4.2.1 Parameters used by several keywords
INTERNET-ADDRESS: An RFC822-compatible network address, usually of form
"userid@node.domain". Listserv puts addresses into
uppercase unless they are enclosed in double quotes.
ACCESS-LEVEL: Defines which users can access the information or
service to which this parameter applies.
Possible values are:
Public Anybody
Maintainer Only the Listserv maintainer
The following values for ACCESS-LEVEL can be used together; they must be
separated by commas.
Private Members of the current list
(LISTNAME) Members of the named list
Owner Owner of the current list
Owner(LIST) Owner of the named list
Service Members of the current list's service area
Service(LIST) Members of the service area of the named list
4.2.2 The keyword descriptions
Some keywords can take several parameters, and the parameters available
are shown separated by a comma in the descriptions below. Alternative
values for the same parameter are shown separated by a logical OR sign
(|).
Some parameters have parameters of their own. Alternative values for
these parameters are shown separated by a semicolon in the descriptions
below.
Where a parameter's value needs to be specified by the listowner, the
parameter is given in
uppercase.
In the list header file, commas are used to separate parameters.
More than one keyword and its values can be given on the same line of
the list header file, leaving one or more spaces between keywords.
One or more spaces are allowed after the equals sign (=) when specifying
keywords.
4.3 List name and address keywords
4.3.1 List-ID= LISTNAME
Defines an alias for the list; this is useful if a list is renamed, or
if two lists are merged.
Can be used to define an alternative name for the list, usually a longer
name than the default. This is useful for VM systems where listnames are
otherwise restricted to 8 characters. A longer name is more informative,
and can also be useful for peered lists. The maximum length for a
list-id is 32 characters.
Users can use the alias, or long name, as well as the usual short one in
commands such as Subscribe, Review, etc.
If the listowner has set up the List-Address keyword (see below), the
alias or long name will appear in mail distributed to list members.
4.3.2 List-Address= Listname|List-id, nje|fqdn|DOMAIN-NAME
This keyword is used most often with NJE/VM hosts. It specifies which
list name and address information Listserv presents when the list
address appears in the "From:", "Sender:" or "Reply-to:" fields of
messages delivered to the list.
"Listname" is the same as the name of the list header file, which is
limited in VM systems to 8 characters. "List-id" is set by the
"List-id=" keyword, so may not be available; if it is not, Listname will
be used. The words "List-id" or "Listname" are used, the actual name of
the list itself is not given here.
The second parameter specifies the particular host that you want
Listserv to use. The NJE option causes Listserv to use the NJE nodename,
and the FQDN option causes Listserv to use the Internet address of the
Listserv host. You can also type in a specific domain name, which can be
useful if the machine on which Listserv is running is known by several
names.
You only need to specify the part of the keyword which you want to
change. For example, to change the hostname, you can enter
"List-Address= XYZ.EDU" in the list header; the list name will be taken
from the value in the LOCAL SYSVARS file which is maintained by the
installation's Listserv maintainer. To change the list name only, you
can write, for example, "List- Address= List-id".
If you are specifying both parameters, you can use the "@" sign as
usual, but if you leave it out,
Listserv will supply it for you.
Here are a few examples:
"List-Address= fqdn" announces the list under the Internet address
for the Listserv host. This setting has no
effect for Bitnet-only sites.
"List-Address= List-ID@fqdn"
uses the long list name and the Internet
hostname.
"List-Address= Listname@xyz.edu"
uses the default list name and the hostname
xyz.edu.
4.3.3 Confidential= No|Yes|Service
Indicates whether the list will be included in the output of a "List"
command.
The default value is "No". "Service" indicates that the list is visible
only to users in the list's service area (as specified by the "Service="
keyword). "Yes" means that the list never appears in the "List" command
output.
4.4 List membership keywords
4.4.1 Subscription= By_owner|Open|Open, Confirm |Closed
Defines whether subscription requests are automatically accepted, and if
not, whether they are forwarded to the list owner.
By_owner Subscription requests are forwarded to the list owner.
This is the default.
Open Subscription requests are accepted automatically
Open,Confirm Subscription requests are accepted, but a request for
confirmation is sent to the user, who must reply before
being added to the list. This confirms the validity of the
user's address details.
Closed Subscription requests are rejected.
4.4.2 Confirm-Delay= HH
Defines the number of hours Listserv will wait after sending out a
confirmation message to a user who wishes to be subscribed. The default
is 48 hours. If the user fails to respond within this time, the
subscription request will lapse.
This keyword is effective only if the Subscription keyword is set to
"Subscription= Open, Confirm".
4.4.3 Renewal= None|Monthly;Yearly;Weekly;yy/mm/dd, Delay(n)
Defines the interval at which subscribers to the list will be asked to
confirm that they still want to be in the list. The default is None. If
enabled, Listserv will ask list members to confirm their subscription at
the stated intervals.
The interval can be specified in two ways:
1) As "Monthly", "Yearly" or "Weekly", optionally preceded by a number
by which to multiply the time unit. Thus, "6-Monthly" indicates an
interval of 6 months. The number must be followed by a dash.
2) A date in the form yy/mm/dd, mm/dd or just dd. The first form
specifies year yy, month mm and day dd, the second means "every year on
month mm, day dd", and the last one means "every month on day dd".
The second form is useful, for example if you know when your students'
accounts are going to expire.
"Delay(n)" defines the minimum delay in days between the time the user
is asked to confirm his subscription and the time he is automatically
removed from the list. The actual delay might be more than this number,
but not less. The default is one week (7 days).
4.4.4 Review= ACCESS-LEVEL
Specifies the category of users who are allowed to review the network
addresses and names of list members. The default value is "Public". A
description of ACCESS-LEVEL is given in the section "Parameters used by
more than one keyword" above.
4.5 List traffic keywords
4.5.1 Send= ACCESS-LEVEL|Editor| Editor,Semi-moderated
Defines who can send mail or files to the list. Can be used to put the
list under control of an
editor, after which any file or piece of mail sent to the list will be
forwarded to the editor, and only the editor and the list owner will be
able to distribute mail or files to list members.
The default value is "Public". The network address of the editor is
defined by the "Editor=" keyword (see 4.6.2). A description of
ACCESS-LEVEL is given in the section "Parameters used by more than one
keyword" above.
A semi-moderated list will treated messages in two different ways,
depending on the contents of the "Subject:" field of the message. If the
subject starts with "Urgent:" (case is ignored), the list is treated as
a non-moderated one and the message will not be forwarded to the editor
for processing. Messages with a subject beginning with "Re: Urgent:" are
treated the same as "Urgent:", so that replies to urgent letters are by
default considered urgent. Messages with any other subject are forwarded
to the editor.
4.5.2 Ack= Yes|Msg|No|None
Listserv normally sends an acknowledgement to the originator of each
incoming message, confirming that the message has been distributed to
list members. Some CPU and other technical statistics are usually
included.
This keyword defines how the acknowledgement will be sent, and if
statistics will be included in it. It sets the value of the "Ack/Noack"
distribution option which will be assigned to new list members. The
value can be altered later by individual list members, using the "SET"
command, but not by non-members of the list. This means that this option
will always be in effect when distributing mail from people who are not
on the distribution list.
Yes Acknowledgement is via email, including statistics.
Msg Acknowledgement is via NJE message, only received by Bitnet users,
and statistics are included.
No Acknowledgement is via NJE message, only received by Bitnet users,
and statistics are not included.
None No acknowledgement at all. Useful for archive-only lists.
4.5.3 Files= Yes|No
This keyword is important only in the VM NJE version of Listserv. It
indicates whether or not files can be sent to the list (using NJE
SENDFILE). The default value is "Yes".
If files are sent to a list, Listserv will make a "best guess" about
which form of encoding to use for files from non-NJE users, and this
encoding may not always be desirable. Also, some VM worm programs have
used lists to propagate themselves. For these reasons, it is advisable
to set Files=No for most lists.
4.5.4 Daily-Threshold= NUMBER
Defines the maximum number of messages that a list will process per day.
Upon reaching this limit, the remaining messages will be held until the
next day. Default is 50 messages per day.
4.5.5 Prime= Yes|No|"PRIMESPEC"
Defines whether the list will distribute mail and files to the list
members during certain peak periods. The default is "Yes", which allows
a list to operate during prime time as it is defined in the site's
Listserv server.
Prime=No may be specified to prevent the list from operating during the
installation's Primetime. Finally, "Prime="PRIMESPEC"" (note the double
quotes) can be used to enforce a particular "prime time" definition for
the list, which will over-ride the installation's Primetime setting.
Mail and files received during the list's prime time are held until the
end of prime time, without sending any notification to the originator.
The value for PRIMESPEC can comprise several DAYSPECs, separated by
semicolons. DAYSPEC is specified as:
DDD1-DDD2: TIMESPEC1 <TIMESPEC2 <...>>
where
DDD Mon, Tue, etc
TIMESPEC HH1:MM1-HH2:MM2
HH:MM hours:minutes on 24 hour clock
The special value of "-" for TIMESPEC specifies "never".
Examples:
"MON-FRI: 09:00-17:00; SAT-SUN: -" (This is the default SYSVAR)
"MON-FRI: 08:00-12:00 13:30-18:30; SAT-SUN: 09:00-17:00"
4.5.6 Topics= TOPIC, TOPIC,...
Allows the list owner to define up to 11 topics for the list, after
which each list member can specify which topics they want to know about.
Users who do not specify any topics will continue to receive all
messages; users who specify one or more topics will receive only the
messages which contain the topic as the first word in the "Subject:"
field.
The list owner could set "Topics=News,Benchmarks,Meetings,Beta-tests",
after which a user could define a personal topics parameter as
"Meetings,News" with the command: "SET listname TOPICS: MEETINGS NEWS".
Thereafter the user would not receive list mail with a subject line
beginning "Benchmarks:" or "Beta-tests:".
Topics should never be reordered. If you ever need to delete a topic,
leave a blank field where the topic used to be, for example:
"Topics=News,,Meetings". Any topic name can be used, except for the
words All, None, Other, Others and Re; care should be used with special
characters as well. In particular, a topic name may not begin with "+"
or "-".
4.5.7 Default-Topics= TOPIC, TOPIC,...
Specifies the initial topics for new subscribers. Default is all topics.
4.5.8 Digest= No|Yes, FM, Daily|Weekly|Monthly, WHEN, Size(N)
The number of messages handled each day varies greatly between lists. If
the number is large, the Digest= keyword can be used to enable
listowners and users to receive one large file containing all the
messages for a specified time period. Once Digest has been enabled by
the listowner, users may select it via the Set command.
The default is "Yes" if the list is archived, and "No" if the list is
not archived. If the value is "No", the other parameters are not used,
so they need not be specified.
The second parameter specifies a disk or directory where the digest will
be stored, such as "Same" to indicate the same location as the list
archives.
The third parameter indicates how often the digest is sent out; the
default is "Daily", other values are "Weekly" or "Monthly".
The fourth parameter, WHEN, is optional, and defines the time when the
digest is to be distributed. For daily digests, specify "HH:MM" or just
"HH" in the 00-23 scale. For weekly digests, specify a weekday, such as
"Tuesday". For monthly digests, specify a number from 1 to 31.
The last parameter specifies the maximum size, in lines, the digest is
allowed to reach. Once a digest reaches that size, it will be sent out
even if it is before the specified time, and another digest will be
started.
4.5.9 Stats= Normal|None, ACCESS-LEVEL
Indicates what statistics are to be maintained for the list, and who
is able to retrieve the
statistics reports. The default value is "Normal,Private".
Normal statistics include number of mailings and other information for
each user who has
sent mail or files to the list.
4.5.10 Mail-Via= Distribute|Direct|Dist2
Determines how the list messages should be distributed. Default is
"Distribute". "Direct" specifies that all recipients will be handled
directly from this Listserv.
"Distribute" and "Dist2" are now equivalent.
4.5.11 Internet-Via= DOMAIN-NAME
Defines which Internet gateway address should be used when delivering
the messages to Internet users. If omitted, the path used is the one
calculated by the server to be the "best" for each Internet recipient.
4.5.12 NJE-Via= NJE-NODE
Defines the NJE node to be used as a gateway for the list messages.
This and the "Internet-Via=" keyword are relevant only for the NJE
version of Listserv.
4.6 List management keywords
4.6.1 Owner= INTERNET-ADDRESS|ACCESS-LEVEL,...
Defines the person or list of people who "own" the list. List owners
control access to the list and define the list control keywords. This
keyword should always appear in the list header. The default value is a
list of the userids of the maintainers. Most combinations of explicit
network addresses and complex access-levels are acceptable, but some
access-level keywords such as "Public" are not meaningful. For example:
Owner= Big@Blue,(Staff-L),Owner(Main-L).
An interesting application of this keyword is to create a STAFF-L list
containing the userids of all the local Listserv staff members, and set
the "Owner=" keyword of all local lists to "Owner= (STAFF-L)".
Thereafter, when there is a change in the local LISTSERV management it
is not necessary to modify the headers of all the local lists - just
modify the Staff-L list.
4.6.2 Editor= INTERNET-ADDRESS, INTERNET-ADDRESS,...
Defines the list editor or editors. The "Send= Editor" option will cause
all mail sent to the list to be automatically forwarded to the first
person listed in the "Editor=" keyword, who will then decide whether to
send it back to the list. Only the editors and list owners will be
allowed to mail directly to the list. Any editor will be able to send
mail to the list, but only the first one will receive copies of mail
sent to the list.
The file will be forwarded to the editor "as is", without being included
in a mail envelope. This ensures that the "To:" keyword and any fields
such as "Resent-From:", "Resent-To:" or "Resent- Date:" are preserved.
The editor must be a human person, not a file server, list server,
mailer, or the like. Specifying a program's mailbox as "Editor=" could
result in a mailing loop.
4.6.3 Errors-To= INTERNET-ADDRESS|ACCESS-LEVEL,...
Defines the person or list of people who will receive rejection mail for
the list. The default value is "Owners".
It may be desirable for the owners to change this to
"Owners,Maintainer".
Most combinations of explicit network addresses and complex
access-levels are acceptable, but some access-level keywords such as
"Public" are not meaningful.
4.6.4 Loopcheck= None|Full|Noorigin|Nobody|Nocrc
Defines the behaviour of the loop checking mechanism of LISTSERV.
None disables loop checking.
Full enables complete loop checking.
Noorigin disables checking on the "known mailer origins" such as
MAILER, POSTMASTER, etc.
Nobody disables checking for blank messages.
Nocrc disables cyclic redundancy check.
The default is Full. Changes to this default may make the list
vulnerable to mailing loops with remote mailers.
4.6.5 Peers= PEER, PEER,...
Specifies a global list of the node-id or network addresses of all the
servers in the world which are peer-linked to the list, either directly
or via one or more other peer servers. This information is used by the
various list management commands to determine the "nearest" peer list to
a given user. For example, when a Subscribe command is received from a
user, it will automatically be forwarded to the nearest server holding a
peer list, even if this is not the Listserv which was specified by the
user.
If the name of the peer list is the same as the name of the local list
(which is usually the case), only the node name is needed. If the list
names are different, the full list network address is needed, e.g.
"REXX-L@UIUCVMD".
4.6.6 Service= AREA, AREA,...
Defines the "service area" beyond which subscription requests must not
be accepted. When a Subscribe command is received, the "Peers=" keyword
is checked to see if there is a nearer peer list in the network (the
"best placement" check). If so, the command is forwarded to that server.
If not, the service area is checked and if the recipient is not within
it, the subscription request is denied. When the Subscribe command is
forwarded, the destination server could itself deny access to the list
if the subscriber is outside its service area. The result of this is
that users may sometimes be unable to join a list, if they are outside
the designated geographical area of all the peers.
The service area check is made after the "best placement" check, to
allow several servers in the same country to share an identical service
area, e.g. "Service= Germany", within which users will be subscribed to
the nearest server.
AREA can be a node or list of nodes; possible values are:
- a network, e.g. EARN, Bitnet
- a country, e.g. Germany, Canada
- "Local", in which case it takes the value of the "Local=" keyword
- a node, e.g. EARNCC
- a simple wildcard nodename pattern such as FR*, *.AC.AT, *ESA*, etc.
4.6.7 Local= NODE, NODE,...
Defines the "local nodes" for both service area checking and mail header
grouping. The "real" local node is automatically considered as a "local
node" and does not have to appear in the list. Non-local list members
receive "grouped" mail if there is more than one member in their node,
but local members receive separate pieces of mail with a single
recipient in the "To:" field. NODE means "anything after the "at" sign
(@) in the network address". For instance, "GUMNCC" and
"gumncc.earn.net" are both valid node names.
This keyword is now used only for service area checking.
4.6.8 Auto-Delete= No|Yes, Semi-Auto|Full-Auto
Defines whether Listserv will attempt to remove users by analysing
rejection messages from mailers. Rejection messages from LMAIL, MX and
PMDF are currently supported. Default is "Yes".
4.6.9 Notify= Yes|No
Defines whether the list owner will receive notification of new
subscriptions, deletions and any option changes made by list members.
The default is "Yes".
4.6.10 Validate= No|Yes, Confirm, NoPW
Allows security verification to be performed on "sensitive" commands.
When set to "No", all commands except Put are accepted with no
validation, which leaves the list unprotected against hackers. For
compatibility reasons, this is the default. When set to "Yes", sensitive
commands such as Delete or Add require password validation. Both
personal and list passwords are accepted for list owner commands, some
user commands may accept a personal password, but other user commands
will be forwarded to the list owners for verification.
When "Yes,Confirm" is specified, sensitive commands are by default
validated by sending a message to the user requesting confirmation
before the command is carried out (the "OK" mechanism). Passwords are
also accepted where appropriate.
When "Yes,Confirm,NoPW" is specified, protected commands must be
validated using the "OK" confirmation mechanism, and passwords are not
accepted. This is the recommended setting for secure lists.
4.6.11 PW= PASSWORD
Defines a password which the list owner will need to give before using
sensitive commands. This parameter is optional, but its usage is
strongly recommended as a means of improving list security. The line
containing this keyword is removed from the copy of the list generated
by the Get command, so as not to reveal the password.
A new password can be created by including it in a new version of this
line, adding it back to the file before using the Put command. The old
password will be retained if this line is omitted.
See the Validate= keyword (4.6.10) for more information.
4.6.12 Default-Options= OPTION, OPTION,...
Defines the Set command options which will be used as defaults for new
members to the list. For example, "Default-Options=FullHDR" will cause
all new members to receive list messages with full headers. The Set
command is described in the Listserv Users Guide.
4.6.13 Filter= Also|Only|Safe, INTERNET-ADDRESS, INTERNET-ADDRESS,...
Any postings, including subscription requests, will be rejected if the
From: field matches any of the patterns in the Filter= keyword.
Wildcards are allowed, for example X400MAIL@* or
*@*.XYZ.EDU. The default value is no filter.
If "Also" is specified, the filter is used in addition to the standard
Listserv filter as specified in the LOCAL SYSVARS file of the site. The
Listserv filter is contained in the code and updated regularly.
If "Only" is used, the addresses you specify are the only ones tested by
Listserv.
Lists with the keyword value "Safe= Yes" (4.7.4) normally require only
minimal filtering. If "Safe" is used, then these safe lists will also
use strict filtering.
4.7 List mail headers and body keywords
4.7.1 Reply-to= DESTINATION, Respect|Ignore
Indicates whether the sender's "Reply-to:" tag file is to be preserved
or discarded, and gives the content of a new "Reply-to:" field if this
is needed.
The default value is "List,Respect".
DESTINATION Destination of a mail message or reply.
Possible destination values are given below:
List the list
Sender the sender of the original mail message
Both both the list and the original sender
None no reply message is sent at all
"INTERNET-ADDRESS"
a network address, enclosed in double quotes.
Some mailing systems cannot process a "Reply-To:" field which contains
multiple addresses, and may therefore treat the "Reply-to= Both" option
as "Reply-to= List".
Respect the original "Reply-to:" tag, if any, is kept.
Ignore the original "Reply-to:" tag is ignored and discarded.
4.7.2 Sender= INTERNET-ADDRESS1, INTERNET-ADDRESS2
Specifies the address to be used for the Sender: field of outgoing
messages. The first address given is used for most messages, and
ADDRESS2 is used for the headers of IETF messages.
Addresses must be enclosed within double-quotes.
4.7.3 X-Tags= Yes|No|Comment
The X-Tags option specifies how Listserv should treat the "X-" fields of
mail messages which it receives for distribution. The options are:
Yes Leave "X-" fields as RFC822 header fields in the outgoing
message. This is the default.
Comment Prepend the header field "Comment:" to "X-" fields in the
outgoing message.
No Remove "X-" fields from the outgoing message.
4.7.4 Safe= Yes|No
This keyword is mainly used with VM systems. It specifies whether the
BSMTP header of the mail distributed from this list will include
"owner-listname". Default is Yes for Netdata- capable mailers. If a site
is running XMAILER, this will cause the spool filename to be set to
"OWNER-xx MAIL".
4.7.5 Editor-Header= Yes|No
Enables/Disables an explanatory mail header which is added to list
messages forwarded to the editor, for lists configured with an editor.
Default is Yes for lists with an editor.
4.7.6 Sizelim= NUMBER
Defines the maximum size (in lines) of postings which will be accepted
for processing. Default is the value specified by the "mailmaxl"
variable in LOCAL SYSVARS, which has a default of 5000 lines.
This and other defaults will be increased in future versions of
Listserv.
4.7.7 Translate= Yes|No
Listserv normally removes control characters from files which it
distributes, but will retain them if this keyword is set to No. The
default is Yes.
4.8 Other keywords
4.8.1 Notebook= No|Yes, FM, INTERVAL|Separate, ACCESS-LEVEL
Indicates whether an automatic log or "notebook" is to be kept of all
mail sent to the list, defines at which interval of time the log file's
name must be changed, and specifies who is allowed to retrieve the log
file from the server. The default value is "No". If the value is "Yes",
then the default filemode (FM) is "A", the default interval is "Single",
and the default access-level is "Private".
FM This parameter is used in VM only. It specifies the filemode
of the disk on which the notebook is to be kept.
INTERVAL Possible "Interval" values are given below. The filetype of
the "notebook" file for the list is determined by this value;
the notebook's filename will always be the same as the list
name.
Single a single file of filetype "NOTEBOOK" is created.
Yearly filetype is "LOGyy"
Monthly filetype is "LOGyymm"
Weekly filetype is "LOGyymmw" (w in "A"-"E")
Separate a separate file is kept for each mail message (e.g. digests).
the filetype is "yy-nnnnn" (sequential counter).
Notebooks can be retrieved using the GET command, which is described in
the Listserv Users Guide. A list of all available notebooks can be
obtained using the command:
Get Notebook Filelist
4.8.2 Newsgroups= NEWSGROUP|None
Defines the RFC822 Newsgroup: header for this list. "None" will remove
the header completely.
4.8.3 Language= LANGUAGE
Defines the language in which information mail and messages are to be
sent to subscribers of the list. The maintainer must first have provided
the server with a data file containing messages in a different language.
The default language is "English". Information mail is currently
available in several languages.
4.8.4 Exit= FILENAME
Defines the list exit to be used with this list. The exit name must be
defined in the LOCAL SYSVARS file via the variable LIST_EXITS, and the
filename must exist on disk. A list exit allows the list owner to
customise Listserv's treatment of subscriptions, postings, removals and
most other tasks related to this list.
4.8.5 Long-Lines= Yes|No
Determines if long lines support is to be enabled or not. This keyword
was used for compatibility with Listearn and the intention is to remove
it in the near future.
Chapter 5 - Annotated examples of list headers
This chapter consists of the header files of five lists, with
discussions of the keywords and values used in them. The lists were
chosen as examples of different list types, and the header files can be
used as guidelines for settings that might be used with different kinds
of lists. However, the examples should not be copied blindly and used
unchanged: every keyword value should be checked to make sure it is
appropriate for any new list you may create.
5.1 Open international list
Here is an example of a totally open list: anyone anywhere may join and
anyone, whether a list member or not, may write to the group.
Keywords for CW-EMAIL@GUMNCC.BITNET:
*
* Campus-Wide Electronic Mail Systems discussion list
*
* Newsgroups= bit.listserv.cw-email
* Ack= Yes
* Review= Public
* Notebook= Yes,E1/194,Monthly,Private
* Send= Public
* Reply-to= List,Respect
* Subscription= Open,Confirm
* Stats= Extended,Private
* Formcheck= No
* Files= Yes
* Validate= Store only
* Errors-To= Owners
* Confidential= No
* Notify= No
* X-tags = Yes Mail-Via= DIST2
* Renewal= Yearly Auto-Delete= Yes,Full-Auto
*
* Owner= TURGUT@TREARN
*
* The recent developments in computer networking have created the need
* for unified E-Mail systems, capable of handling mail-type
* communications among users on many different kinds of computers
* (mainframes,superminis, personal computers), working for the
* same organization.
* This communication can be within the organization or directed to
* other users on the different networks (BITNET, ARPA Internet, etc.)
*
* This list strives to provide a forum for developers of such systems.
* Topics to be discussed are how to carry out such an effort,
* experiences in the implementation, recommended policies,
* hardware issues, etc. It is aimed primarily (but not limited
* to) developers of university campus-wide e-mail systems, hence
* its name.
*
Comments:
There can be more than one keyword per line, and several spaces are
allowed between a keyword name and its value.
Since this list is open to all, various keyword values are used to
reduce the number of bad addresses in the list. First of all, the use of
"Subscription= Open,Confirm" ensures that there is two-way communication
between Listserv and the user before adding the user to the list.
"Renewal= Yearly" will require list members to confirm their list
membership at least once a year. "Auto-Delete= Yes,Full-Auto" means that
Listserv will automatically delete from the list any address for which
it receives an error message with an error code indicating an
irreparable problem such as unknown user or unknown host computer name.
"Formcheck= " is now obsolete, but it is still found in many old lists
like this one. It is ignored by Listserv. "Validate= Store only" is the
old form of the current "Validate= No" and has the same effect.
5.2 International peered list
Here is one of the peers of a large open international list.
Keywords for BITNEWS@DEARN.BITNET:
* BITNET News List
*
* Newsgroups= Bit.Listserv.BitNews
* OWNER= QUIET:,RUSHING@BITNIC,CONKLIN@BITNIC,SNODGRAS@BITNIC
* OWNER= BITNET@BITNIC
* Peers= BITNIC,DEARN,HEARN,MARIST,UGA
* X-Tags= Comment Confidential= No
* Subscription= Open Send= Owner
* Validate= Store Only Notify= No
* Ack= No Files= No Stats= Normal,Public
* Errors-To= Postmaster Review= Public
* Notebook= Yes,B,Monthly,Public
*
* Owner= LISTMGR@BITNIC,NCC@DEARN,LISTMGT@HEARN,LSVMAINT@UGA
* Owner= HARRY@MARIST,QUIET:,HAROLD@UGA
*
*
* BITNEWS is the official medium of the BITNET Network Information
* Center for distributing BITNET news and administrative
* developments.
*
* List topology:
*
* MARIST <----+----> BITNIC <----> DEARN <----> HEARN
* UGA <----+
*
Comments:
In a peered list, all peers must be listed in the "Peers= " keyword,
even if they are not directly peered to this server. The list topology
diagram of the peers is not used by Listserv, but is very helpful for
human readers. The diagram shows us that BITNEWS@DEARN.BITNET is
directly peered to BITNEWS@BITNIC.BITNET and BITNEWS@HEARN.BITNET, and
so we find the following among the list members:
BITNEWS@BITNIC Peer Distribution List
BITNEWS@HEARN Peer Distribution List
You will notice that there are several owners, at least one from each of
the peer server sites. Thus, any owner can make changes in all the
peers, if necessary.
The use of a list password is highly recommended for peered lists (the
listing above was produced with the REView command, and thus the
password keyword does not appear.)
5.3 International professional list
In many lists an attempt is made to ensure that the list audience and
discussion are professional and focused.
Keywords for HUMANIST@BROWNVM.BITNET:
*
* HUMANIST: Humanities Computing
*
* owner= EDITORS@BROWNVM (Elaine Brennan & Allen Renear)
* owner= elaine@netcom.com (Elaine Brennan)
*
* editor= EDITORS@BROWNVM (Elaine Brennan & Allen Renear)
* editor= ALLEN@BROWNVM (Allen Renear)
* editor= ELAINE@BROWNVM (Elaine Brennan)
*
* notebook= yes,k,weekly,public
* review= private
* send= editor
* subscription= by_owner
*
* ack= no
* autodelete= no
* confidential= no
* editor-header= no
* errors-to= owner
* files= yes
* formcheck= yes
* mail-via= dist2 notify= yes
* reply-to= sender,respect
* renewal= Yearly,Delay(30)
* stats= normal,private validate= store only
* x-tags= comment
*
* HUMANIST: Humanities Computing list - created 07 MAY 87
*
Comments:
All requests for subscription are forwarded automatically to the list
owners ("subscription= by_owner"). The owners can then request
information about the potential list member before adding that person to
the list.
Since the editors organise submissions into digests, they have set
"editor-header= no". The editor header is helpful for editors who simply
want to check submissions and then forward them back to the list for
distribution.
5.4 Private organisation's list
The following is typical of a well-defined, relatively static group.
Keywords for TAU-LAW@TAUNIVM.BITNET:
* Tel Aviv University Law Faculty List
*
* Review= Private Subscription= By_owner
* Send= Private Notify= Yes
* Reply-to= Sender, Respect Files= Yes
* Validate= Store only Confidential= Yes
* X-Tags= Comment Ack= Msg
* Stats= Normal,Private
* Newsgroups= None Notebook= No
* Errors-To= Owner
* Owner= ZIMMER@TAUNIVM (Zehava Zimmer)
Comments:
Because this list is only for faculty members of Tel Aviv University,
"Confidential= Yes" is used so that TAU-LAW will not appear in the
global list of lists. It is mostly used for announcements of lectures
and other events, so it was decided that no logs need be kept
("Notebook= No"). Since it is used for announcements and not for
discussion, there is "Reply-to= Sender, Respect" so that queries will go
to the person making the announcement and not to the whole group. Note
the use of "Newsgroups= None" so that n line will appear in mail from
the list.
5.5 List on non-VM, non-NJE server
Keywords for EXCEL-L@PEACH.EASE.LSOFT.COM:
*
* Microsoft Excel Developers List
*
* Subscription= Open,Confirm
* Review= Private
* Send= Editor
* Editor= nathan@ubvm.cc.buffalo.edu,nathan@lsoft.com
* Editor= (EXCEL-L)
* Reply-to= List,Respect
* Files= No
* Confidential= Yes
* Notebook= Yes,F:\LISTSERV\ARCHIVES\EXCEL-L,Monthly,Private
* Default-options= NoRepro,NoFiles
* Ack= Msg
* Notify= No
* Validate= No
* Errors-To= nathan@linus.dc.lsoft.com
* Auto-Delete= Yes,Full-Auto
* Filter= ALSO,*@*LIBHITECH.COM
* Owner= nathan@ubvm.cc.buffalo.edu (Nathan Brindle - Admin only)
* Owner= Quiet:
* Owner= nathan@lsoft.com (Nathan Brindle:)
* Owner= nathan@linus.dc.lsoft.com (yup, Nathan Brindle:)
*
* Users should send list requests to the
* address(es) listed before "Owner= Quiet:".
*
* This list installed on 95/01/27, running under L-Soft's
* LISTSERV-TCP/IP for Windows NT version 1.8b.
*
Comments:
The same keywords are used on all platforms and for both the NJE and the
TCP/IP versions of Listserv.
The "Filter= " keyword is used to prevent users from a particular site
from joining the list or sending messages. The use of "ALSO" means that
this filter is in addition to the default filter for all lists
maintained by this server.
Chapter 6 - Other sources of information
6.1 Listserv lists
LSTOWN-L@SEARN.BITNET Listserv list owners' forum
This is THE list for list owners and moderators. This is the place for
discussing problems regarding Listserv which you have been unable to
solve through the normal support channels.
LSTSRV-L@SEARN.BITNET Listserv give-and-take forum (peered)
LSTSRV-L@UGA.BITNET Listserv give-and-take forum (peered)
This list is mainly for Listserv server maintainers, but owners who are
interested in the workings of the Listserv software also participate.
NEW-LIST@NDSUVM1.BITNET New list announcements
The NEW-LIST list is primarily for initial announcements of new mailing
lists, but it may also be used to find out if a list on a particular
subject already exists, after you have checked in the lists of lists.
LDBASE-L@UKANVM.BITNET Listserv database search capability list
This list is for discussion of the uses of the Listserv database
facilities. These facilites are of potential interest to list owners.
6.2 Basic Listserv documentation set
The documents which are relevant to list owners are:
LISTOWNR REFCARD
LISTOWNR MEMO
LISTKEYW MEMO
These documents are available from any Listserv server. They are listed
in INFO FILELIST. The first two will only be sent to you if you make
your request from an address which is listed as a list owner at that
server.
6.3 Listserv Release Notes
The Release Notes are detailed technical descriptions of the changes in
each new release of the Listserv software. The Release Notes are
available from listserv@searn.sunet.se in filelist LINFO as:
Vnna RELNOTES
where 'nna' indicates the release. For example, the Release Notes for
1.8a are available as V18A RELNOTES.
6.4 Listserv documentation from the EARN Association
The following documents were written by the staff of EARN (now TERENA).
They are available from listserv@gumncc.bitnet in the DOC filelist
LSVGUIDE MEMO - Listserv User Guide, plain text
LSVGUIDE PS - Listserv User Guide, Postscript
LISTSERV FILEDOC - Documentation for Listserv files, plain text
LISTSERV FILE-PS - Documentation for Listserv files, Postscript
LSVQUICK MEMO - Listserv quick reference, plain text
LSVQUICK PS - Listserv quick reference, Postscript
LSVSTART MEMO - Listserv starter guide, plain text
LSVSTART PS - Listserv starter guide, Postscript
LISTKEYW TXT - List header file keywords document, plain text
The last document, LISTKEYW TXT, is an update of the document LISTKEYW
MEMO from the basic Listserv documentation set, and thus is of
particular interest to list owners.
6.5 Other documentation files
Jim Gerland has written a set of short documents for list owners. They
can be obtained from listserv@ubvm.cc.buffalo.edu using the command: get
lsvowner package
The files in this package are:
LSVOWNER READY - 'Your List is Ready' information
LSVOWNER WELCOME - 'Welcome to this list' information
LSVOWNER TXT - Generic List Owner Instructions
LSVOWNER NEW-LIST - New List Announcement information
LSVOWNER GATEWAY - USENET News Gateway information
LSVOWNER HEADERS - List header instructions
LSVOWNER FIL-LIST - FILELIST instructions
Various documents are available from listserv@searn.sunet.se in the
LINFO FILELIST, including the following:
LISTSERV TIPS, written in 1991 by Lisa Covi while working for CREN. This
document is still valuable, but it must be used with caution because
many changes have been made to Listserv since it was written.
FSV GUIDE, written by Ben Chi. This guide explains how to make files
available using Listserv's file server capabilities. It is also
available from: listserv@albany.edu
MLM-SOFT FAQ, written by Norm Aleks. This is a guide to mailing list
management software and covers many different software packages in
addition to Listserv. This document is updated and posted monthly to
several Usenet newsgroups including comp.mail.list- admin.software and
news.answers.
6.6 Usenet newsgroups
Two Usenet newsgroups are devoted to mailing list management issues:
comp.mail.list-admin.policy
comp.mail.list-admin.software