![[LISTSERV logo]](/images/LISTSERV-generic.gif)
![[Online documentation]](/images/HDR-doc.gif)
|
|
|
L-Soft international, Inc.
List Owner's Manual
for
LISTSERV™, version 1.8b
May 23, 1996
Revision 3
The reference number of this document is 9605-UD-02.
Information in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. L-Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of L-Soft international, Inc. For information about mirroring this manual on your local site, please contact manuals@lsoft.com.
Copyright © 1996, L-Soft international, Inc.
All Rights Reserved Worldwide.
L-SOFT, LISTSERV and LMail are trademarks of L-Soft international, Inc.
UNIX is a registered trademark of X/Open Company Limited.
AIX and IBM are registered trademarks of International Business Machines Corporation.
Alpha AXP, Ultrix and VMS are trademarks of Digital Equipment Corporation.
OSF/1 is a registered trademark of Open Software Foundation, Inc.
Microsoft is a registered trademark and Windows, Windows NT and
Windows 95 are trademarks of Microsoft Corporation.
HP is a registered trademark of Hewlett-Packard Company.
Sun is a registered trademark of Sun Microsystems, Inc.
IRIX is a trademark of Silicon Graphics, Inc.
PMDF is a registered trademark of Innosoft International.
All other trademarks, both marked and not marked, are the property
of their respective owners.
Reference Number 9605-UD-02
All of L-Soft's manuals for LISTSERV are available in ascii-text format via LISTSERV and in popular word-processing formats via ftp.lsoft.com. They are also available on the World Wide Web at the following URL:
URL: http://www.lsoft.com/manuals/index.html
L-Soft invites comment on its manuals. Please feel free to send your comments via e-mail to MANUALS@LSOFT.COM.
Preface: LISTSERV Command Syntax Conventions 1. About Mailing Lists and LISTSERV 2. Starting a Mailing List - The Basics
List Owner's Manual
for
LISTSERV™, version 1.8b
May 23, 1996
Revision 3
Preface: LISTSERV Command Syntax Conventions
Generally, parameters used in this document can consist of 1 to 8 characters from the following set:
A-Z 0-9 $#@+-_:
Deviations from this include:
fformat Netdata, Card, Disk, Punch, LPunch, UUencode,
XXencode, VMSdump, MIME/text, MIME/Appl, Mail
full_name first_name [middle_initial] surname (not your
e-mail address)
listname name of an existing list
node BITNET nodeid or Internet hostname of a BITNET
machine which has taken care of supplying an
':internet' tag in its BITEARN NODES entry;
or the fully-qualified domain name (FQDN) of
an Internet host.
pw a password containing characters from the set:
A-Z 0-9 $#@_-?!|%
userid Any valid RFC822 network address not longer than
80 characters; if omitted, the 'hostname' part
defaults to that of the command originator
Other deviations from the standard set will be noted along with the affected commands.
Also please note the following conventions for representing variable or optional parameters:
italic type always indicates required parameter names that must be replaced by appropriate data when sending commands to LISTSERV
< > Angle brackets may sometimes enclose required parameter names that must be replaced by appropriate data when sending commands to LISTSERV. Sometimes used for clarity when italic type is inappropriate
[ ] Square brackets enclose optional parameters which, if used, must be replaced by appropriate data when sending commands to LISTSERV
1. About Mailing Lists and LISTSERV
LISTSERV is a system that allows you to create, manage and control electronic "mailing lists" on a corporate network or on the Internet. Since its inception in 1986 for IBM mainframes on the BITNET academic network, LISTSERV has been continually improved and expanded to become the predominant system in use today. LISTSERV is now available for VM, VMS™, unix®and Windows NT™, and has already been ported to Windows 95™ (formerly Windows 4.0).
Consider for a moment what the users of your electronic mail system actually use electronic mail for. Do they discuss problems and issues that face your organization, down to the departmental level? In an academic setting, do your faculty and students communicate via electronic mail? As with "real world" distribution lists, electronic mailing lists can make it possible for people to confer in a painless manner via the written word. The electronic mail software simply replaces the copying machine, with its associated costs, delays and frustrations. In fact, electronic mail lists are easier to use than most modern copiers, and a lot less likely to jam at just the worst possible moment.
Because electronic mail is delivered in a matter of seconds, or occasionally minutes, electronic mailing lists can do a lot more than supplement the traditional paper distribution lists. In some cases, an electronic mailing list can replace a conference call. Even when a conference call is more suitable, the electronic mailing list can prove a powerful tool for the distribution of papers, figures and other material needed in preparation for the conference call. And, when the call is over, it can be used to distribute a summary of the discussion and the decisions that were made. What before might have been an exchange of views between two or three people can now become an ongoing conference on the issue or problem at hand. Announcement lists and even refereed electronic journals can be made available to your audience, which can be as small as a few people or as large as the entire Internet community.
If you need a further overview, please see Appendix D, Related Documents and Support, for information on how to get one.
2. Starting a Mailing List - The Basics
Before you start your list, it pays to do a careful search in several places to find out if you are duplicating an already-existing list, or if the name you are considering is already in use for a list on a differing subject.
The first place to check is the "List of Lists" maintained by LISTSERV itself. Send the command
LIST GLOBAL search_string
in the body of mail to LISTSERV@LISTSERV.NET (or to LISTSERV at any host site).
You will receive a mail message in return containing a list of all lists known
to LISTSERV where either the name of the list or the short list description
contains your search string. For instance, LIST GLOBAL IBM would result
in the following being returned to you:
-----------------------------------------------------------------------
Excerpt from the LISTSERV lists known to LISTSERV@PEACH.EASE.LSOFT.COM
on 6 Feb 1995 09:57
Search string: IBM
***********************************************************************
* To subscribe, send mail to LISTSERV@LISTSERV.NET with the following *
* command in the text (not the subject) of your message: *
* *
* SUBSCRIBE listname *
* *
* Replace 'listname' with the name in the first column of the table. *
***********************************************************************
Network-wide ID Full address and list description
--------------- ---------------------------------
9370-L 9370-L@NIC.SURFNET.NL
IBM 9370 and VM/IS specific topics list
AIBIBL AIBIBL@PLEARN.EDU.PL
ACADEMIC INITIATIVE IBM , PROJECT "LIBRARY SYSTEMS"
AIBIBL
AIX-L AIX-L@PUCC.PRINCETON.EDU
IBM AIX Discussion List
AIXNEWS AIXNEWS@PUCC.PRINCETON.EDU
IBM AIX News to Mail Distribution
-----------------------------------------------------------------------
Figure 2.1. Sample output of LIST GLOBAL IBM
(63 more lists were deleted for brevity)
You might want to make your search more specific, as this particular search locates every list that has IBM somewhere in its title. For instance, if you wanted to start a list on some aspect of the IBM 370, you might do better to search for IBM 370.
Alternative searches you can do include:
ftp sri.com
user: anonymous
password: your_user_id
cd netinfo
get interest-groups
ftp dartcms1.dartmouth.edu
user: anonymous
password: (not required by dartcms1)
cd siglists
get internet.lists
Note that all these files (except the large data stack) can also be retrieved from LISTSERV@DARTCMS1.DARTMOUTH.EDU.
You should already be familiar with your mailing system and text editor. Otherwise, there are no special skills required. It is the goal of this manual to give you what you need to know about LISTSERV user commands, privileged LISTSERV owner commands, and how to read and interpret RFC822 Internet-style mail headers. LISTSERV itself is designed to operate in an identical manner no matter which operating system it is running under. Thus the fact that LISTSERV is running under VM, VMS, some flavor of Unix, or Windows NT should not be a concern to the list owner, who may not even know which version of LISTSERV his lists are running on.
Additionally, we have made an attempt to give you a basic "list owner's course" in anticipation of some of the issues you may encounter in the course of moderating a list.
If you are looking for a site to host a list, consider the following:
Physically creating the list is the task of the LISTSERV maintainer (sometimes referred to as the "LISTSERV postmaster") at a given LISTSERV host site.[2] Specific procedures for requesting a list startup vary from institution to institution. It is usually best to contact the computing center at the site for more information.
How a LISTSERV mailing list performs its tasks is defined by its header keywords. There are several different categories of keywords, each of which is discussed below in general terms. A complete alphabetical listing of list header keywords, including default settings and all options available, is provided in Appendix B.
Access Control Keywords. These keywords designate the level of
"openness" for a list. They determine who can post to the list, who can review
the list of subscribers, and whether or not the list is open to general
subscription.
Distribution Keywords. This group has to do with how LISTSERV
distributes postings to subscribers, including whether or not acknowledgments
are sent back to posters, how many postings may go through the list daily,
whether or not the list is available in digest form and whether it is available
to USENET through a gateway. These keywords also determine whether or not list
topics are enabled, and how LISTSERV will configure outgoing postings for
replies.
Error Handling Keywords. Included under this group are the
keywords controlling automatic deletion, loop-checking, and to whom error
messages are sent for disposition when received by LISTSERV.
List Maintenance and Moderation Keywords. A fairly large group
of keywords having to do with how the list is operated, including definitions
for the list owner, list editor, and the list archive notebook; whether or not
(and who) to notify when users subscribe and sign off; how often subscriptions
must be renewed, and so forth. These are perhaps the most basic keywords that
can be set for a given list, and one of them ("Owner=") must be set for
a list to operate.
Security Keywords. These keywords control who can "see" the list
(that is, whether or not the list appears in the List of Lists for a given
user, based on the user's host site), whether or not the list is protected by a
password, and the level of security necessary for changes to the list itself.
The "Exit=" keyword is also contained in this group.
Subscription Keywords. These control whether or not the list is
open to general subscriptions, whether or not a mailing path confirmation is
required, and what user options are set by default upon
subscription.
Other Keywords. These control other aspects of list management
that are not generally changed from their defaults, and which do not fit
readily into the categories listed above.
Once your list has been created by the LISTSERV maintainer, you can have a copy
of the list sent to you for editing purposes. Simply issue the GET
listname command to LISTSERV. This will cause the server to mail
you a copy of the entire list (header and subscriber list).
If you want to change header keyword settings only, it is probably advisable to
issue the GET command with the (header switch:
GET listname (header
The GET command automatically locks the list so that no changes can be made to
the operating copy on the server until you do one of two things:
It is possible to request that LISTSERV not lock the list when it is sent to
you. This is accomplished by adding the (nolock switch to the
GET command. You can use (nolock and
(header together as in the following example:
GET listname (header nolock
(Note that the "(" switch character is used only once.)
CAUTION: It is not advisable to use the (nolock switch in at
least two cases:
LISTSERV maintainers should note one further caution: It is considered
extremely inadvisable to "hand-edit" subscriber lists, as columns at the
far right of each subscriber's entry contain list control codes corresponding
to the subscriber's personal option settings. The only case in which it might
be appropriate to "hand-edit" would be to delete a user entirely, and then only
if all attempts to delete the user via the DELETE command fail. For
instance, X.400 or X.500 addresses can cause DELETE to fail because of
their use of the "/" character. You can use wildcards to delete these
subscriptions. You can also enclose the address in double quotes:
DELETE XYZ-L "/ADMD=ABC/PRMD=DEF/...../@X400.SOMEHOST.COM".
List owners should be persons who will undertake the responsibility of managing
the list in all of its aspects. A list owner may be a moderator; a list owner
may be called upon to determine why a user can't unsubscribe from the list, or
to handle delivery errors, or to fix other problems that may arise.
The primary list owner (the first owner defined) has special responsibilities
as well. This owner is considered the Editor and the primary Moderator for
lists that have Send= Editor but do not have Editor= or
Moderator= defined. This owner receives all error messages when
Errors-To= is set to "Owner". In short, the primary list owner is
generally the person who is ultimately responsible for the workings of the
list.
Secondary list owners fall into two categories: Quiet and non-Quiet.
Note that all list owners defined after the * Owner= Quiet: line will be
quiet list owners.
You can define multiple owners on a single line by separating them with a
comma. Note that if you put "Quiet:" on a line with list owner userids, you
must place a comma after "Quiet:", e.g.
* Owner= Quiet:,ncbnet@linus.dc.lsoft.com,cheng@linus.dc.lsoft.com
There must always be at least one non-quiet list owner. Otherwise
LISTSERV sends all error messages and other administrative mail to the LISTSERV
maintainer by default.
When creating the list, the LISTSERV maintainer should assign a password for
the list. If this password was not assigned, it is highly recommended
that you GET the list header as described in section 2.10 (use the
(HEADER NOLOCK options) and add a line to the header as follows:
* PW=MYPASSWD
Replace "MYPASSWD" with the word you choose. Note that there should not
be a space between "PW=" and your password. This is the only way to change the
list password; for security's sake, there is no LISTSERV command that will
change it "on the fly". For additional security, the list password never
appears in the list header on subsequent GETs; to all intents and
purposes it is invisible once it is assigned.
You can change the list password whenever you store the list by assigning a new
value to the "PW=" keyword, but when you store the list with the changed
password, you must use the old password in the PUT command line (because
until you actually store the new password, LISTSERV will still be looking for
the old one). See section 2.9 (below) for an example of a list header ready to
be stored with a new password defined.
When you are ready to store your list back on the host, include the list file
in a mail message to LISTSERV. Ensure that the PW=XXXXXXXX command is
in the first line of the mail body. Change XXXXXXXX to the password you
have previously defined with the PW= list header keyword. Then send the
message.
If LISTSERV has trouble processing the edited list file, it will return a
discrepancy report to you with each error noted. If the errors are categorized
as "warnings only," LISTSERV will go ahead and store the list. However, if any
one error is categorized as a serious error, the list will not be stored and
the old version will be retained.
Caution: If you are using a mailer such as Pine or Microsoft Mail that allows
"attachments" to mail, do not "attach" the list file to your mail message. It
must be in plain text with the PUT line at the top. LISTSERV will not
translate encoded attachments.
LISTSERV always backs up the current list file before it stores a new copy.
Should you discover that you have made a mistake (for instance, you have
deleted all users by storing a header and adding users "on the fly"), it is
possible to retrieve the previous copy of the list by issuing a GET listname
(OLD command to the host server. You must then add the PUT listname
LIST PW=XXXXXXXX command to the top of the file and store it.
Once the LISTSERV maintainer has notified you that the basic list has been
created, you can send a GET command to the server to make any
modifications necessary. For instance,
GET MYLIST PW=MYPASSWD (HEADER
might cause LISTSERV to send you the following list header file:
Below, we've now edited the list header and it is ready to be included in a
mail message and sent back to LISTSERV. Note that the PUT command has
been modified to include the password assigned by the LISTSERV maintainer, and
note also the PW= keyword in the body of the list header which will define a
new password.
LISTSERV's security options are wide ranging, from almost no protection
(easiest to administer your list, but also most open to hacker attacks) to
total protection requiring validation of each and every command sent to
LISTSERV for your list. It is also possible to limit access to various aspects
of your list, such as who can subscribe, who can review the list of
subscribers, and who can access the list archives. You can hide your list from
the LIST command, either at the global level or from all requests, including
those from users on LISTSERV's local machine, or from a definable range in
between.
The VALIDATE= keyword controls the level of command validation desired
for your list. The default, VALIDATE= NO, requires password validation
only for storing the list on the server. This is often sufficient for general
needs. However, when a list is set this way, LISTSERV does not validate
commands it receives for the list, under the assumption that the mail it
receives is genuinely coming from a list owner. This level of validation does
not protect the list from commands issued by hackers who have forged mail in
the name of the list owner.
The next level is VALIDATE= YES. At this level, LISTSERV requires a
password for all of its "protected" commands. This password can be either the
list password or the sender's personal password as defined by the PW ADD
command. The commands protected by this level are those that affect
subscriptions or the operation of the list, e.g., DELETE or ADD.
Users will also have to validate most commands that affect their subscriptions,
but generally can do so using the "OK" mechanism rather than defining a
personal password. Note that some user commands will be forwarded to the list
owner for validation rather than accepting password validation from the user.
The next level is VALIDATE= YES,CONFIRM. At this level, LISTSERV will
require validation with the "OK" mechanism (see below) by default, but will
still accept passwords where appropriate. While the less-secure passwords are
still accepted, this is considered a good compromise between list security and
list owner and user convenience.
The next level is VALIDATE= YES,CONFIRM,NOPW. At this level, LISTSERV
will no longer accept passwords as validation for protected commands. The logic
is that because of the way the "OK" mechanism is implemented, passwords are not
as safe as "magic cookies". This is the recommended setting for lists that must
be kept secure.
Two other levels are VALIDATE= ALL,CONFIRM and VALIDATE=
ALL,CONFIRM,NOPW. These levels require "OK" validation for all commands
that cause a change in state except for the PUT command. If NOPW
is not specified, passwords are accepted where appropriate. With these levels,
commands that do not cause a change in state (e.g., QUERY) do not
require validation.
Note that LISTSERV requests coming from the local system via CP MSG or CP SMSG
on VM systems or via LCMD on VMS or Unix systems never require validation, as
they cannot be forged. See Appendix B for more information on the
VALIDATE= keyword.
You can control subscription requests by use of the SUBSCRIPTION=
keyword. By default, this keyword is set to SUBSCRIPTION= BY
OWNER, meaning that all subscription requests will be forwarded to the list
owner for disposition. You can also refuse all subscription requests by setting
SUBSCRIPTION= CLOSED.
To code a list for open subscriptions without list owner intervention, you set
SUBSCRIPTION= OPEN. If you would like to add protection against forged
subscription requests or bad return mailing paths, code SUBSCRIPTION=
OPEN,CONFIRM. The latter will cause a subscription confirmation request to
be sent to the prospective subscriber, which he or she must respond to using
the "OK" confirmation mechanism.
In order to restrict subscriptions to persons in a specific service area, see
the next section.
It may be desirable to restrict access to your list to people in a small area.
For instance, you probably would not want a list for students in a class
section at a university to be advertised or accessible by people all over the
world. However, without setting certain keywords appropriately, such a list
will be visible to a LIST GLOBAL command.
If you wish to simply hide your list from a LIST command, but still
allow people to subscribe to it if they know it is there, use the keyword
CONFIDENTIAL= YES. Note that users subscribed to the list as well as the
list owner(s) will be able to see the list if they issue a LIST
command.
If you wish to hide your list from and refuse subscription requests from users
outside the local area, you define two keywords:
For whatever reason, you may wish to restrict the ability to review the
subscriber list either to subscribers or to list owners. This is done by
setting the REVIEW= keyword appropriately.
To allow anyone, including non-subscribers, to review the list, set REVIEW=
PUBLIC (which is also the default).
To restrict reviews of the list to subscribers only, set REVIEW=
PRIVATE.
To restrict reviews of the list to list owners only, set REVIEW=
OWNERS.
You can also restrict reviews to users within the list's service area by
setting REVIEW= SERVICE , and defining the SERVICE= keyword
appropriately (see the preceding section).
Restricting access to the list's notebook archive files is similar to
controlling who may review the list. It is accomplished by setting the fourth
parameter of the NOTEBOOK= keyword to an appropriate value. For
instance,
Note: It is not advised to change the location (second) parameter of the
Notebook= keyword without prior approval from the LISTSERV maintainer. Setting
this parameter to an illegal value will generate errors that will cause
LISTSERV to place your list on hold until the error is corrected.
If enabled, notebook archives are private by default.
The Send= list header keyword is the basic control for who may post mail
to the list. If the list allows non-subscribers to post, set Send=
Public.
For a list that does not allow non-subscribers to post, set Send=
Private. For a list where all posts should be forwarded to a
moderator/editor, there are two settings:
Depending on the setting of the Validate= list header keyword, certain
LISTSERV commands have always required a password for execution. However, with
a recognition that mail can be forged ("spoofed") by just about anyone on the
Internet today, L-Soft introduced a "magic cookie" method of command validation
that is considered much more secure than passwords.
In essence, the "magic cookie" method requires that the sender of the command
must confirm his command via a reply containing only the text "OK". (This is
actually simplistic; see below.) If mail is spoofed from the list owner's user
id, the command confirmation request will always be sent to the list owner's
user id, thus preventing the spoofer from confirming the command. Moreover, the
"cookie" itself (a six-digit hexidecimal number) is registered to the "From:"
user id of the original command.
The general method of replying to a command confirmation request is as
follows:
If this does not work, it is possible that the Subject: line was corrupted in
transit and you may need to try the following:
Also note that the confirmations must come from the user id that originated the
command. You cannot send a command from one account and then approve it from
another.
The passwords recognized by LISTSERV for various operations (assuming that the
NOPW parameter is not used with the "Validate=" keyword) are of two
distinct types:
If you want to remove your password altogether, send the command
And finally, if you simply want to change your personal password, send the
command
Another security issue involves protecting the list from people who refuse to
play by the rules. LISTSERV includes several different levels of privilege
restriction for these users, some of which are available for use by list owners
without the intervention of the LISTSERV maintainer.
LISTSERV automatically produces a List of Lists that may be reviewed by users
anywhere on the Internet via the LIST GLOBAL command. This List of
Lists is made up of one-line entries containing the short listname and the
descriptive title of the list (up to about 60 characters in length). A sample
of the List of Lists format was shown in Chapter 2.
Note that it is possible to code a descriptive title in your list header that
is more than 40 columns long, but the List of Lists will include only the first
40 columns of that title. It is therefore important from this respect to be
sure that the descriptive title of your list is succinct and to the point.
Chapter 9, Customizing LISTSERV's Default Mail Templates, includes
details on how to include an informative paragraph in the information mail
template file for your list. When a user sends the command INFO
listname to your server, LISTSERV responds with either:
The NEW-LIST project was started in 1989 to promote mailing lists via a mailing
list. NEW-LIST@VM1.NODAK.EDU distributes announcements of new and changed
mailing lists to over 9500 subscribers every day. The NEW-LIST administration
asks only that your list be well-tested and ready for new subscriptions before
you send your announcement to them. You also want to make sure that your
announcement is as correct and comprehensive as possible, as news on the
Internet spreads quickly and a mistake in a NEW-LIST announcement may cause
problems for both you and other users months later.
For more information on the NEW-LIST project and what you need to use it, you
can:
Unlike many other lookup services on the Internet, the INTERNIC is not
necessarily free. Its three distinct sections are run by General Atomics,
Network Solutions, Inc. (NSI), and AT&T.
You can register your list with the INTERNIC, but be forewarned. A "basic"
listing is free, while an "extended" listing is not. (On the other hand,
anyone with net access can search the INTERNIC databases for free.)
For more information, point a Gopher or WWW client at the INTERNIC gopher,
rs.internic.net.
The Global List Exchange, or GLX, is a central clearinghouse for LISTSERV
subscriptions and List of List requests. For instance, If a user knows the
name of a list but not the name of the host server, GLX simplifies the process
by giving the user a single address where all subscription requests for lists
running on L-Soft's LISTSERV can be sent.
By adding the GLX address in all advertisements for your list, you help other
list owners as well as yourself by making it simple for users to subscribe to
any list. Additionally, if for some reason a user is unable to contact your
server directly, the GLX gives him an alternate subscription method.
The GLX address is LISTSERV@LISTSERV.NET.
It is generally considered a breach of netiquette to invade the privacy of
other lists with a broadcast announcement that your list is up and running.
The only time when this might be acceptable is when your list addresses
a concern of people already subscribed to another list. If you feel it
necessary to post an announcement on someone else's list, it is good manners to
first send private mail to the owner of that list and ask his or her permission
to do so. (The same policy applies to USENET newsgroups, though it may be more
difficult to find out who the moderator is.)
It is certainly a breach of netiquette (and many networks' appropriate use
policies) to blindly post multiple copies of your announcements to multiple
lists. This kind of behavior is termed a "spam", something about which you may
read more in Chapter 6, Moderating and Editing Lists. This kind of
announcement is guaranteed to reap a good deal of bad will and may well result
in the revocation of your network privileges.
A list owner may add and delete subscribers manually. The command syntax is:
ADD listname netaddress full_name
DELete listname netaddress
In a perfect world, subscribers would understand intuitively how to subscribe
and unsubscribe from mailing lists. Unfortunately, this is not always the
case. Depending on an individual's style of list management, a list owner may
choose to add or delete subscribers to the list manually, or send the potential
subscriber instructions on how it is done. (See Appendix C for sample
"boilerplate" instruction files that can be modified to suit local purposes.)
And for lists coded Subscription= By Owner or Subscription=
Closed, it is of course necessary to use the ADD command to
subscribe a user.
If the list is set to confirm mailing paths for new subscriptions
(Subscription= Open,Confirm), it is probably wisest to use the latter
option, since if a subscriber is added manually to a list, the confirmation
process is bypassed.
Note that full_name should contain at least two discrete words,
but it is also possible to add users without knowing the value for
full_name. Simply use an asterisk ("*") character. Note
that if the user is already subscribed to another list on the same host,
LISTSERV will pick up the value for full_name from its signup
files. Examples are:
RIGHT: ADD GOV-L vice-president@whitehouse.gov Al Gore
RIGHT: ADD GOV-L vice-president@whitehouse.gov *
WRONG: ADD GOV-L vice-president@whitehouse.gov Al
WRONG: ADD GOV-L vice-president@whitehouse.gov Al-Gore
When adding users, ADD will also accept a full RFC822 address that you
can cut and paste from the "From:" line of a message. Be sure that you remove
the "From:" part of the line. For example, the "From:" line
From: Al Gore <vice-president@whitehouse.gov>
becomes an ADD command as follows:
ADD GOV-L Al Gore <vice-president@whitehose.gov>
X.400 and X.500 addressing schemes can cause problems for the list owner who is
trying to delete one. These addressing schemes use the "/" character to
separate address elements, but to LISTSERV, "/" is a special character and you
would not be able to delete one of these addresses by simply cutting and
pasting it into a DELETE command.
For instance, you might have an address like:
/G=Joe/S=Randomuser/OU=403402ABD/O=SOME.CORP/@LANGATE.SOME.HOST.COM
In order to delete this address, there are two issues.
DELETE MYLIST *G=JOE*S=RANDOMUSER*@LANGATE.SOME.HOST.COM
which solves both the line wrap problem and the illegal character problem at
the same time.
Sometimes the list owner will get a message from a subscriber who says, in
essence, "I keep trying to (unsubscribe/change to digest/etc.) and LISTSERV
says I'm not subscribed. Can you help?" This requires some detective work.
There are a couple of strategies for figuring out what is wrong. List owners
should first use the powerful SCAN command to search for a pattern
anywhere in the subscriber list. The syntax is:
SCAN listname search-text
For instance, "SCAN TEST-L Nathan" might return:
> scan test-l Nathan
Note that SCAN is not case-sensitive. "Nathan", "NATHAN", and "nathan"
all return the same results.
Searches with SCAN should start out simple and become more complex as
needed. For instance, if there are only three people in the list with the
string "NATHAN" as part of their subscription record, it will be unlikely that
you will need to make the search any more complex. If you are looking for
"SMITH", however, it may be necessary to further qualify your search string,
say to look for "JOE SMITH". Another reason it is important to begin with a
simple search string is that your user may not be subscribed under the exact
address the error is returning to you. For instance, say you don't have the
user's id, but you have a host name. You can search for all occurrences of the
host name, but note that the search:
SCAN TEST-L MAIL.FOO.BAR.COM
will not find the user jsmith@foo.bar.com. If you run the following
search:
SCAN TEST-L BAR.COM
however, you will find Mr. Smith's subscription.
Another possibility is that the subscriber may be using more than one address
to work with his subscription. For instance, say the user's complaint to you
came from JOE@SUN6.SOMEUNI.EDU. Looking at the list, you find a subscription
for JOE@SUN8.SOMEUNI.EDU. LISTSERV has no way to know that JOE@SUN6 is the same
person as JOE@SUN8, even though Joe and you know they are. The solution to
Joe's problem above is for you to delete his SUN8 subscription and add his SUN6
address. Then Joe needs to be sure that he uses SUN6 in the future, if not for
reading mail, then at least for managing his own subscription.
Another strategy would be to submit a wildcard QUERY to the list. The
drawback to this method is that it might require multiple tries to find the
subscription, depending on the complexity of the wildcard query.
Note also that not only can this sort of problem arise from a subscriber using
more than one workstation to read mail, but it can also arise when a particular
site changes its domain configuration, forwards mail from the old addressing
scheme to the new addressing scheme, and doesn't inform its users of the
change. In these cases, users often don't realize there is a problem until
they try to unsubscribe or change personal options, because the change has been
transparent to them.
If you are moving a list from a non-LISTSERV site, you can quickly and easily
convert the existing list file to the LISTSERV format by following these
instructions:
where "listname" is the name of the new list, and
"user1", "user2" and other users are the entries
from the original list that you want to add to the new list. (You should remove
any lines from the original list that do not actually identify subscriber
addresses.)
Prepending the command word "QUIET" before any LISTSERV command that you
issue on behalf of a subscriber causes LISTSERV to suppress any notification to
the subscriber of the changes you have made. This is particularly helpful when
deleting subscribers whose accounts have expired and when setting subscribers
with full mailboxes to NOMAIL, as it will help avoid another error message from
the host when the notification message bounces. It is also helpful when adding
subscriptions to the list that should not receive any welcome mail, such as
redistribution lists and USENET newsgroups.
Examples of the usage of QUIET include:
QUIET ADD EXCEL-L comp.spreadsheets.excel@netnews.somenode.edu
A bounce is simply an undeliverable e-mail message. The term "bounce" is used
to describe it because normally the system that discovers the delivery error
"bounces" a copy of the message back to you with some sort of delivery error
message. Sometimes these messages are easy to decipher - "No such user at
foo.bar.com" - but uncomfortably often they are not that easy. Certain
systems, as noted above, kindly format error notifications in a format that
LISTSERV can understand, and if your list is configured for auto-deletion,
these bounces will be the least of your worries - in fact, they will not be
worrisome at all.
Here are a few of the typical mail errors you will have to deal with as a list
owner:
Most of the time, this is authoritative and indicates that the user's access
has been curtailed for some reason (graduation, no longer employed, etc.). A
quiet delete (syntax: "QUIET DELETE listname
userid@host") is in order unless you have reason to believe that the
message is not authoritative.
This is sometimes authoritative and sometimes not. If a host goes down or a
gateway fails, often this message is returned by an intermediate host or
gateway. If the user is bouncing a great deal of mail from a high-volume list,
it is probably best to set the user to NOMAIL (syntax: "SET
listname NOMAIL FOR userid@host") rather than to summarily
delete him. This way, the error messages stop, the user is sent an automatic
message telling him his personal options have been changed by the list owner,
and the user doesn't have to go through the subscription process again if the
problem has been solved in the interim.
The problem is that some hosts go down on a regular basis and this error
makes it impossible to tell if the host in question is gone forever or gone
until the local sysadmin reboots his machine. After a while, you will begin to
recognize the transient hosts and may elect to ignore them. If you choose to
set the user to NOMAIL, you should send a message to the user just in case the
system has come back up, and you should keep some sort of record of the users
you've set this way so you can follow up later with another message.
Similar to "no such host". Comes from a different lookup system, and
generally means the same thing.
A host is experiencing periodic failures, and the gateway or intermediate host
will store the message for n days and attempt redelivery. Usually there
is nothing wrong with the user address, so it is a list owner decision as to
whether it is worth waiting out the transient failure or going ahead and
setting the user to NOMAIL. Unfortunately, by the time you get this
message, the failure is n days in the past, the "transient failure" is
very probably over, and you are likely to receive further error messages for
n more days until the intermediate host's queue is exhausted.
Self explanatory. This usually happens on systems with tiny user mailbox
space, but it can happen on any system if a user subscribes to too many lists
or goes on an extended vacation without setting lists to NOMAIL. The
best solution is to set the user to NOMAIL yourself. Variations on this
message include VMS's "file extend failed writing to [disk.user]MAIL.MAI".
This is a favorite Unix sendmail configuration bounce. NOMAIL or
DELETE, according to your preference. Since it is a configuration
problem, it is usually transient. One system sent the following under
an "unknown mailer error 1" heading:
LLONG@StarShip@Dora: Mailbox full
Obviously this is not a properly-configured address (at least, not as far as
LISTSERV is concerned), and if you SCAN or QUERY the list for it, you will get
a negative response. If, however, you SCAN the list for LLONG, you may find a
user such as:
> scan test-l LLONG
This user can now be set to NOMAIL and the errors will stop after the
Banyan host has emptied its queue. If you do not find the user on the first
SCAN, try using another part of the address as your search text. Note
that a user may have his mail forwarded from the account that is actually
subscribed to an account on another machine where he reads his mail. If the
second machine is bouncing the mail, it may not be immediately apparent from
the bounce messages that the mail is actually being forwarded. It is important
to check for variants of the userid in the bounce message as it may be related
to the userid that is actually subscribed to the list.
Note that there are many forms of error messages. Many mail systems do not
conform to Internet "standards" (some of them even return non-English error
messages!) and LISTSERV's auto-deletion feature will not always catch their
bounces.
Perhaps the worst type of bounce is one that comes from a user who is "hiding"
behind an account that redistributes mail (a "redistribution list"), or a user
whose Internet address has changed slightly but who is still subscribed to your
list under his original address.
Redistribution lists typically (but not always) take some form of your list's
name (such as "xxxxx-L-REDIST@foo.bar.com"), and thus their subscriptions tend
to be easy to find. What is difficult is that you have no way of knowing which
users (or how many users) are hidden behind this interface, nor any way of
knowing what their userids are.
Forwarded accounts generally fall into one of two categories - those where the
user has forwarded his own mail from one account to another rather than
changing his subscription, and those where the user's system name has changed
and the old address is still valid but is forwarding mail to the new address
without the user being aware of it.
Let's say that suddenly you are bombarded with delivery errors for
someuser@baz.net. Your immediate reaction is to set this person to
NOMAIL or (in some cases) to delete him/her altogether. You therefore
send set xxxxx-L nomail for someuser@baz.net to LISTSERV. LISTSERV
responds: "No subscription for someuser@baz.net in list XXXXX-L."
In a best-case scenario, you can query the list for *@*.baz.net and find either
a user like someuser@glork.baz.net (the address has changed and the local
sysadmins didn't inform the user) or a redistribution-list account like
xxxxx-L@baz.net. These are easily-fixed redistribution bounces. In the first
case, you delete the user and let him or her resubscribe. In the second case,
you can try sending a message to owner-xxxxx-l@baz.net with a cc: to
postmaster@baz.net and inform them of the problem. If it persists, you could
send a further message informing them that you are suspending the
redistribution list's subscription until such time as they tell you the problem
on their end is fixed, and simply set xxxxx-l@baz.net to NOMAIL.
The worst-case scenario is as follows: baz.net may be bouncing the mail to
you, but there may not be a single subscription for baz.net in your list.
Here's where you have to do some careful sleuthing. First, run a wildcard
query such as QUERY xxxxx-l FOR *@*baz* or QUERY xxxxx-l FOR
*baz*@*. The former will find users at baz.com, for instance, where
baz.net is a synonym for baz.com. The latter query may seem somewhat strange,
but it's possible that the mail is being routed through a gateway and the
actual subscription is for xxxxx-l%baz.net@cunyvm.cuny.edu or something of that
sort.
LISTSERV supports several levels of automatic deletion based on error messages
passed back to it in LMail format by certain remote systems. While auto-delete
will not solve all of your bouncing mail problems, it has the potential to take
care of most "permanent" errors (including "no such user" and "no such host").
However, note that auto-delete ignores "temporary" errors such as "host
unreachable for 3 days", "system error", "disk quota exceeded", and so forth,
such that users whose accounts generate "temporary" errors are not summarily
deleted from the list.
By default, lists running under LISTSERV 1.8b and higher generate a report
which lets the list owner know what userids are causing problems, rather than
deleting users at the first error LISTSERV understands. If the Delay() and
Max() parameters are set to non-zero values for a list coded "Auto-Delete=
Yes", LISTSERV will not take immediate action on mail delivery errors. You
will receive an "auto-deletion monitoring report" daily to show you which
subscribers are bouncing mail, what the error is, when it started, when the
last error arrived, and how many errors have been received for the subscriber
in total. By default, LISTSERV will wait 4 days (or for a maximum of 100 error
messages per individual user) before deleting a subscriber.
If you code "Delay(0)", LISTSERV will not wait to take action, but will delete
the subscriber at the first error LISTSERV understands.
By default, lists with "Validate= All" are set "Auto-Delete= No", while all
other lists are set "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)".
Implementation of the "Auto-Delete=" keyword is discussed in detail in Appendix
B, List Keyword Alphabetical Reference, under "Error Handling
Keywords."
Making a big increase to the DELAY threshold to provide more leniency during a
holiday may not be a good idea. While it will indeed disable the monitor for
the duration of the holiday, switching back to the normal threshold when you
return will cause the monitor to delete all the users that had been bouncing
during the holidays. In general, you should avoid making temporary changes to
the DELAY threshold, because it takes the monitor a while to adapt to the new
settings.
The best way to relax the rules during a long holiday is to leave the DELAY
threshold unchanged but switch the monitor to passive mode ("Auto-Delete=
Yes,Manual"). No one will be deleted over the holidays, but the monitor's cycle
will not be perturbed. When you return, you should wait about a week before
switching back to automatic mode. This is because, after a long holiday such as
Christmas, it usually takes about 2 working days for system administrators to
solve all problems. In some cases, the problems will have caused bounces to
remain undelivered. So, by fixing the problems, the system administrators may
actually send a flood of new bounces corresponding to problems that have now
been solved. Unfortunately, since the monitor only receives NON-delivery
reports, it has no way to know that these problems have in fact been solved. As
a rule of thumb, you will note that your daily delivery error reports are much
longer than usual over the vacation. When you return, you should wait until
they are back to their normal size before switching back to automatic mode.
For lists coded "Subscription= Open", you can require confirmation on all new
subscription requests, thus ensuring that LISTSERV has a clear mailing path
back to the subscriber. In the past, a user could send a subscription for an
open subscription list to LISTSERV, which upon acceptance would immediately
start sending the user list mail. If the user was located behind a "broken" or
one-way gateway, this produced immediate bounced mail until the list owner
noticed and deleted the subscription. Note that requiring confirmation at the
time of subscription does not guarantee that the clear mailing path will
continue to exist permanently.
"Subscription= Open,Confirm" causes LISTSERV to send a Command Confirmation
Request to the potential subscriber before actually adding the user to the
list. The subscriber is requested to reply to the request by sending a
validation "cookie" back to LISTSERV (this "cookie" being the hexidecimal
number pulled from the subject line).
The Command Confirmation Request, while straightforward, has the potential to
cause confusion if users do not read carefully the instructions that make up
the request. LISTSERV expects confirmation codes to be sent in a specific way
because some mail gateways add lines to the header of the message that LISTSERV
doesn't understand. If a user forwards the request back to LISTSERV, or
creates a new mail message to send the 'cookie' back, it usually will not work
correctly. The sequence should thus be as follows:
You can code subscription renewal into your lists. This is one method to keep
lists "pruned down" and avoid having large lists that are actually distributing
mail to only a fraction of the users. For instance, you may have a number of
subscriptions set to NOMAIL for one reason or another. NOMAIL user(a) may have
forgotten that he has a subscription; user(b) may have set NOMAIL instead of
unsubscribing; user(c) may no longer exist because she graduated or no longer
works for the service provider; you may have set user(d) to NOMAIL because of
recurrent mail delivery errors. Requiring a periodic confirmation of
subscriptions is therefore a reasonable course of action for large, non-private
lists.
To add subscription renewal, you add the following keyword to the header of
your list:
* Renewal= interval
where interval is a period of time such as Weekly, Yearly,
6-monthly, or something similar, and Delay(number) is an integer
corresponding to how many days LISTSERV will wait for the renewal confirmation
to arrive. (See Appendix B for more information on renewal and delay
periods.)
The confirmation request mailing asks the subscriber to send the command
CONFIRM listname back to LISTSERV. If the subscriber does not do
so within a certain length of time, LISTSERV automatically deletes the
subscription. The default delay time is 7 days. If you wish to use the
default delay time, it is not necessary to code Delay() into your Renewal
parameters.
Note: You may wish to increase the delay time to accommodate users whose
subscriptions expire over holidays (such as the Christmas/New Year's week) in
order to avoid accidental deletions. Also, be aware that confused subscribers
can and will send the CONFIRM command back to the list, rather than to
LISTSERV. LISTSERV's default filter will catch these commands and forward them
to the userid(s) defined by the "Errors-To=" keyword.
It is possible to waive subscription renewal for certain users (such as list
owners, editors, redistribution lists, etc.). In order to do this, simply
issue the command
[QUIET] SET listname NORENEW FOR net-address
to LISTSERV. It is most advisable to do this in the case of redistribution
lists, as they broadcast the renewal notice to their users, who a) cannot renew
the subscription and b) become very confused when they see the notice, often
sending "what does this mean?" mail to the list.
You can also issue the CONFIRM command for a subscriber:
[QUIET] CONFIRM listname FOR net-address
If a user sends more than 21 consecutive invalid commands to LISTSERV, LISTSERV
automatically serves that user off so that further commands from that user will
be ignored. Should a user become served off in this fashion, it is possible
for the list owner or any other user to issue a SERVE
net-address command to restore that user's access. As with all
other LISTSERV commands, the SERVE command is sent to LISTSERV.
While served off, the user will be unable to set personal options and will be
unable to subscribe or unsubscribe to lists on that server. Note that a user
will likely be served off of one particular LISTSERV site but not others, and
also that the user may not even realize that he has been served off (in spite
of the fact that LISTSERV sends notification to the user to that effect).
Note that the SERVE command will not restore service to users who have been
manually served off by the LISTSERV maintainer.
Occasionally the need to split a very large list may arise. This was more
common when LISTSERV ran only on BITNET, whereas the TCP-IP version of LISTSERV
is not limited by BITNET constraints. However, because of the fact that
subscribers may be scattered all over the world, in rare cases it can make
sense to split (or "peer") a list and share the mail load among 2 or more
LISTSERV servers. Peering also makes it possible to have list archives located
in more than one place; for example, a list might be peered between a European
host and a North American host, making it possible for subscribers on each
continent to retrieve archives from the nearer host.
You should ALWAYS contact the LISTSERV maintainer before deciding to link your
list to another LISTSERV. Although there is no problem about linking to another
L-Soft LISTSERV list, linking to a non-L-Soft mailing list manager is not
supported and will cause serious problems (including mailing loops) for which
L-Soft international, Inc. could not be held responsible.
After the link operation has been completed, it is recommended that you define
"Peers=" keywords on lists you just linked. For lists running on LISTSERV for
VM, this makes it possible to EXPLODE them for better network
efficiency. (Because peering is not widely used today, it is unlikely that the
EXPLODE command will be ported to other platforms.)
You should be aware of the fact that a
1. Send mail to the list telling people that a new peer server is being linked
to the list, and that some subscribers will be moved to it.
2a. If the prerequisites for using the MOVE command are met, you should
use either individual MOVE commands (in the case that there are very few
users to move) or a batch-MOVE command with associated DDname
(see the LISTJOB MEMO guide for more information on commands-jobs) to move the
users. You may want to use the QUIET option to suppress notification if
there are a lot of users to move.
Warning: the MOVE command should not be used to move peer list servers.
See the MOVE command description for more details.
If you cannot use the MOVE command, you should try one of the following
two methods:
2b. For each user to be moved, issue the following commands in the following
order:
QUIET ADD listname userid@host full_name
QUIET SET listname options FOR userid@host
Wait until you get confirmation for the two previous commands
QUIET DELete listname userid@host (old server)
GET listname (new server)
If you are using VM XEDIT: Receive both files and use the XEDIT
"PUT" and "GET" commands to move users from one list to the other. You
must preserve the contents of columns 81-100 across the move.
If you are using another text editor: Make sure that the editor
you are using does not "imbed" control codes such as line breaks, tabs or
word-wrapping characters into the text when you edit it. (For instance, if you
are using Notepad in Microsoft Windows, ensure that "Word Wrap" is turned off.)
Use the cut and paste controls to copy lines in their entirety. You
must preserve the contents of columns 81-100 across the move.
Imbedded control codes and/or word wrap will generate errors when the list is
stored back on the server.
Store the two lists back on their respective servers.
ADDHere listname userid@host <full_name>
<PW=list_password>
The ADDHERE command is strictly identical to ADD,
with the exception that the
placement of the user is not checked against the list of peer servers, i.e. the
specified user is added to the local list without any further verification. (By
comparison, the ADD command causes LISTSERV to check automatically to see if
there is no better-suited peer list for the specified user.)
EXPLODE listname <F=fformat> [VM only]
The EXPLODE command provides a means whereby a list can be automatically
analyzed by LISTSERV to optimize the placement of its recipients over the
various peer servers hosting the list. It requires a "Peers=" keyword to be
defined in the list header (see Appendix B). Non-BITNET userids will be
exploded according to the network address of the corresponding gateway (as per
the SERVICE NAMES file), or ignored if the gateway could not be identified.
LISTSERV will create a commands-job file containing the necessary MOVE
command to transfer all the users which were found to be (possibly)
mis-allocated to the peer server which is nearest to them. This file will then
be sent to you so that you can review it before sending it back to the server
for execution.
MOVE listname userid@host <TO> newhost
<PW=list_password>
DD=ddname listid@newhost [VM only]
The MOVE command allows list owners to easily move users from one peer
server to another. It will move the complete user entry from the source server
to the destination one, including full name as it appears in the specified list
and all list distribution options. The MOVE operation will be done in
such a way that no mail can possibly be lost by the target while the
MOVE operation is in progress (duplicate mail might be received for a
short duration, however). Notification will be sent to the target user unless
the QUIET option was used.
If the source and destination list names are identical, only the destination
node ('newhost') needs be specified. Otherwise, the full network address
('listid@newhost') must be specified.
The MOVE command requires both source and destination lists to have the
same password. Since each server will have to send a password to the other to
validate the (special) ADD/DELETE commands it is sending to the other,
it has potentially a way to trap the password specified by the server, thus
thwarting any attempt at inventing a protocol to allow use of this command on
lists which have a different password. Besides, no MOVE operation will
be accepted on lists which do not have a password at all, because for technical
reasons it would allow unauthorized users to easily add someone to a list
(since there would be no password validation).
The MOVE command is the proper way to effect a move operation. You
should not use any other command/set of commands unless you cannot use
MOVE. THE MOVE COMMAND SHOULD NOT BE USED TO MOVE DISTRIBUTION
LISTS!!! Since a MOVE is basically an ADD + DELETE, with
the latter being done only AFTER the ADD is completed, moving a
distribution list address with the MOVE command can cause a duplicate
link to be defined for a short period of time. This could result in a transient
mailing loop, which could become permanent if the size of the looping mailfiles
is less than the size of the inter-servers "DELETE" command jobfile, and the
RSCS priority of the latter has been altered.
The syntax is similar to the subscriber's method of reviewing his options,
except that the list owner must specify for whom the options are being
checked.
Query listname FOR userid@host
Note that it is possible to use wildcards in the subscriber address. For
instance,
Q listname with DIGEST CONCEAL FOR *@*
will return option listings for subscribers such as JIMJ@UBVM,
JOHN@UBVMS.CC.BUFFALO.EDU, etc. This can be handy if you are searching the
list for someone whose subscription address differs from the address you are
given in an error report (see the examples, above, in "Dealing with bounced
mail").
Using the WITH qualifier, you can also query a list for users who have a
specific option set. For instance, you might want to know which users are set
to NOMAIL. Send the command
Q listname WITH NOMAIL FOR *@*
and LISTSERV will return a list of those users. It is also possible to query a
list for multiple options:
Q listname with DIGEST CONCEAL FOR *@*
will return a list of those subscribers who have set their subscription to
DIGEST and also to CONCEAL.
Again, the syntax is similar to the subscriber's method.
[QUIET] SET listname option FOR userid@host
Setting this option to Mail indicates that the subscriber will receive
mail from the list. NOMail is the complementary command that stops mail
but leaves the user subscribed to the list. (NOMail is often a good
compromise for users who are leaving the office for vacation or on extended
business trips, and who don't want a full mailbox on their return.) The format
of the messages received is controlled by the
DIGEST/INDEX/NODIGEST/NOINDEX options (see below).
Causes the subscriber to receive one posting per digest cycle (typically daily)
rather than individual messages as they are processed by LISTSERV.
In version 1.8b, the MAIL/NOMAIL option has been isolated from
DIGEST/INDEX. The MAIL/NOMAIL option controls whether messages
should be delivered, and the DIGEST/INDEX/NODIGEST/NOINDEX option
controls the format in which messages should be delivered. Thus,
switching to NOMAIL and back to MAIL now preserves the
digest/index/normal delivery setting. To provide as much compatibility with the
old syntax as possible, the four options operate as follows:
Note that in extreme cases, subscribers using the DIGEST option may
receive more than one digest per cycle if the digest limit is reached before
the end of the cycle.
Causes the subscriber to receive one posting per digest cycle containing only
an index of subject topics for all messages during that cycle. See the section
on DIGEST (above) for further information.
These three command words control the level of acknowledgment the
subscriber receives when posting to the list. ACK causes LISTSERV to
send a short confirmation message to the subscriber when the post has been
received and distributed. NOACK disables the confirmation feature for
the subscriber (although BITNET subscribers will receive a short interactive
message on their terminal). For BITNET subscribers, MSGack provides the
same information as ACK via interactive messages.
By specifying one of the following command words, the subscriber can control
the amount of mail header information prepended to list mail. The syntax is
SET listname headertype, where headertype is one of
the following:
FULLHdr "Full" mail headers (default) (formerly FULLBSMTP)
SHORTHdr Short headers (formerly SHORTBSMTP)
IETFhdr Internet-style headers
DUALhdr Dual headers, useful with PC or Mac mail programs
Note: In version 1.8b, the obsolete FULLHDR and SHORTHDR options were renamed
to FULL822 and SHORT822, while the normal BSMTP-style header options were
renamed to FULLHDR and SHORTHDR. The FULL822/SHORT822 options are only required
by a small number of ancient BITNET mail systems.
Quite a few non-technical users are relying on non-RFC822 user interfaces for
reading their mail. Quite often these user interfaces are user-friendly,
quality implementations of a proprietary mail protocol which the users are
proficient with, but which happens not to lend itself to bidirectional mapping
to RFC822. The users may have a good reason for using this particular program,
and they complain that it is not always clear what list the postings come from,
or who posted them. Other users have very primitive mail programs which do not
preserve the original RFC822 header and may not even have a "message subject"
concept. The user knows which list the message came from, but not who posted
it, making private replies impossible.
The DUALHDR (minimum abbreviation: DUAL) is provided to help solve this
problem. Dual headers are regular short (SHORTHDR) headers followed by a second
header inside the message body. This second header shows what list the message
is coming from ('Sender:'), the name and address of the person who posted it
('Poster:'), the poster's organization, if present, and the message subject.
The date is not shown because even the most primitive mail programs appear to
supply a usable message date.
Generally, users will be well-served by the FULL header option, which is the
default.
Occasionally, a subscriber may not want his presence to be known
to someone else making a casual REView of the list. Subscribers may
choose to "hide" their subscription from the REView command by using the
CONCEAL command. Conversely, a subscriber may choose to remove this
restriction by issuing the NOCONCEAL command. Note that the list owner
can always obtain a list of all subscribers, both concealed and unconcealed, by
issuing the GET listname (NOLock) command, or by issuing a QUERY
listname WITH CONCEAL FOR *@* command.
This option controls whether or not the subscriber will get a
copy of his or her own posts back from the list after they are processed.
Generally, if a subscriber's mail program is configured to file copies of the
subscriber's outgoing mail, or if the subscriber has one of the acknowledgment
options (ACK/MSGack) enabled, this option should be set to
NOREPro. If, on the other hand, the subscriber is set to NOACK
and doesn't keep a copy of outgoing mail, this option should probably be set to
REPro.
If list topics are enabled, this option allows the subscriber to
specify which topics he or she will receive. The syntax of a SET TOPICS
statement is significantly different from that of the other options. See
Chapter 6, Section 6, for more information on this syntax.
This option may be set only by list owners or the LISTSERV
maintainer. A subscriber set to NOPOST may not post to the list.
NOPOST gives the individual list owner the ability to serve out abusive
or obnoxious posters without having to add such users to the list's "Filter="
setting. Subscribers set to NOPOST will still receive list mail - they
just won't be able to post mail to the list.
The list owner or LISTSERV maintainer may issue the SET listname POST
FOR userid@host command to reverse a previously-set NOPOST.
Note for peered lists: NOPOST must be set globally or a user can bypass
the setting by simply posting to another peer. Thus you must add the user
manually to the other peers and then set the user to NOMAIL as well as
NOPOST on the peers.
This option may be set only by list owners or the LISTSERV
maintainer, and is effective only on moderated lists. A subscriber set to
EDITOR on an edited/moderated list may post directly to the list without
a moderator's intervention. It is virtually identical to adding the
subscriber's address to the "Editor=" keyword, but easier to manage. The only
difference between the EDITOR option and the "Editor=" keyword, other
than not being visible in the list header, is that the "Editor=" keyword also
defines a (seldom used) access level class which can then be used in keywords
such as "Review=". Thus, one could have a list with "Review= Editor",
indicating that only the users listed in the "Editor=" keyword are allowed to
review the list. The EDITOR option does not confer this privilege. Note
that the EDITOR option is only meaningful on moderated lists.
The list owner or LISTSERV maintainer may issue the SET listname
NOEDITOR FOR userid@host command to reverse a previously-set
EDITOR.
This option may be set only by list owners or the LISTSERV
maintainer. When a subscriber is set to REVIEW, all postings from
that subscriber are forwarded to the list editor or list owner for approval.
Approval for these postings is always via the OK mechanism - there is no need
to forward the posting to the list, simply reply to the approval confirmation
with "OK".
Note that if a list is unmoderated, it is still possible to direct
REVIEW postings to a specific person by adding an "Editor=" or
"Moderator=" keyword to the list header.
The list owner or LISTSERV maintainer may issue the SET listname
NOREVIEW FOR userid@host command to reverse a previously-set
REVIEW.
This option may be set only by list owners or the LISTSERV
maintainer. Enables or disables subscription renewal confirmation on an
individual subscriber basis. Setting a subscription to NORENEW is
particularly useful for exempting list owners, redistribution lists, and other
subscriptions which should not or must not receive the confirmation request
message from the renewal process.
The list owner or LISTSERV maintainer may issue the SET listname
RENEW FOR userid@host command to reverse a previously-set NORENEW.
The list owner may specify original defaults for many subscriber options by
using the "Default-Options=" keyword. This keyword takes regular SET options
as its parameters. Examples include:
* Default-Options= DIGEST,NOREPRO,NOACK
* Default-Options= REPRO,NONE
You may have more than one "Default-Options=" line in your header, as needed.
Note that any default topics are set with the "Default-Topics=" keyword. See
Appendix B for details on this keyword.
Please note that much of this chapter is subjective, based on personal
experiences during several years of list ownership, and may not necessarily
match your own philosophy of "the way things ought to be." The following
sections are offered as one way to run a list, and the author does not mean to
assert that the one way offered - his way - is the only way. As
we seem to say so often, "your mileage may vary."
One of the most important things you can do as a list owner is make it clear
from the outset what policies are in place and will be enforced if it becomes
necessary. Due to a potential for controversy, for instance, some lists may
require a formal "list charter" by which all subscribers must agree to abide
before they are allowed to subscribe. Other lists may be able to get by with a
simple welcome file (see below) that spells out basic netiquette, polices on
"flaming" and commercial posts, and anything else that seems appropriate (such
as how to get in touch with the list owner in an emergency, where the list
archives are located, etc.).
It is particularly important on open subscription lists that you make a
concerted effort to remind your subscribers on a regular basis of the policies
you have set for your list, as well as any other information they need in order
to make best use of your list. If you have a great deal of subscriber
turnover, it may be necessary to do this every few weeks. You may decide to
put together a quarterly or semi-yearly post for more stable lists. Ensure
that the subject line is indicative of what the administrative posting is so
that there is no question as to whether or not you posted it (even if
subscribers don't read it).
By default, the list owner becomes a moderator of sorts, even if the list in
question is neither edited nor officially moderated. This means that, as a
list owner, you must be prepared to maintain order if it becomes necessary. At
the same time, you must moderate yourself so that you do not alienate
users and cause your list and/or host institution to suffer as a result.
Thankfully, mailing lists have generally enjoyed relative peace and quiet over
the years in comparison to newsgroups, but mailing lists have unique problems
of their own.
Lists dedicated to controversial subjects are more likely to become arenas for
"flame wars" between subscribers with hard-held and differing opinions than
those dedicated to the discussion of popular software packages, but this does
not mean that the latter are immune any more than it means that the former are
constantly plagued by flames. The example set by you as list owner and as a
participating subscriber to the list is perhaps the most important factor in
whether or not your list becomes a site known for strife and controversy. In
other words, if you appear not to care about whether or not discussion is on
topic and/or civilized, no one else will, either. Yet if you become a policeman
- the other end of the spectrum - no one will want to subscribe or participate
for fear of your wrath. Either way, your list is unlikely to last very long.
The middle ground is, as in most things, the place to be when administering a
list. Some call this "firm but fair," letting things go pretty much as they
will but stepping in with a wry or gently chiding remark from time to time when
exchanges get heated. And they will! Software discussion lists are
particularly bad about this when new subscribers ask "frequently-asked
questions" (FAQs) and veteran subscribers respond in exasperated fashion with
"RTFM!" (Read The Fine Manual) and similar nasty retorts. Good list
owner practice at this point is likely to be a good-natured reminder from you
that flames belong in private mail, pointing out that new subscribers have no
way of knowing that the particular questions they ask have been asked (and
answered!) n random times before.
Finally, if your mailing list has an international audience, you will need to
be careful to account for language problems and cultural differences. You will
need to decide which languages are allowed or not allowed on the list; this
should be mentioned shortly in the list abstract or welcome message. In most
cases, the official language will be English. As your list grows, some
subscribers may object to this decision, arguing that people who have trouble
expressing themselves in English should be allowed to use their own language,
with the understanding that many people will be unable to understand what they
are saying. As the list owner, it will be your call. Usually, the best
compromise is to start a separate list for discussions in the new language.
However, you must be careful in wording your decision. In multi-lingual
cultures, it is usually considered a courtesy to use the other person's
language. It is certainly considered rude for people to demand that everyone
else should speak their language. Thus, if your native language is English, you
will be in a delicate position. To avoid a flame war, you will want to make
sure that your decision does not come out as a unilateral demand. Politely
suggesting a separate list, and tolerating an occasional non-English posting
when the poster genuinely cannot speak English, is often the best course of
action.
Another possible source of flame wars is unintended rudeness. It is easy to
forget that non native speakers are making an effort every time they post
something to the list. People will make mistakes, sometimes appearing rude when
they did not mean to, simply because they used the wrong word. Another cause of
apparent rudeness is cultural difference. Things which are perfectly normal in
one culture can be insulting in another. For instance, ad hominem
attacks are perfectly acceptable in some countries. Conversely, referring to
other people by their first name ("As Peter said in his last message, ...") can
be downright insulting in some cultures, where anything short of the full title
is at best condescending. But, of course, in other countries the use of the
full title is considered sarcastic... There is no middle ground here, because
there are too many conflicting cultures and too many languages. The only way to
successful cross-cultural communication is through the tolerance of other
people's cultural habits, in return for their tolerance of yours.
Edited lists are generally used for the purpose of "full moderation" or for
refereed electronic journals or the like, for which random postings from
subscribers and/or non-subscribers may not be welcome for general distribution.
This places the list owner and any editors in the position of being full-time
monitors of what is and is not allowed to go through to the list.
A word of warning to potential list editors: Rules on the Internet are
not set in stone. Some people will insist on their right to post without what
they will term "censorship" by the list editor. Some will become upset to the
point of threatening to report you to your local computing center
administrators for abridging their freedom of speech, or (in the U.S.) even
threatening to sue your institution and you personally for an abridgment of
their First Amendment rights. It is therefore vitally important to you that you
keep a "paper trail" of such complaints in the event that threats become
reality and you are asked about them. This common practice in the business
world should be common practice in list ownership as well.
Freedom of speech and copyright issues on the Internet have not yet been tested
in the courts as of this writing. These are both areas in which list editors
and list owners in general must tread carefully. Always document any
problems you may have in these areas.
Should you decide that an edited list is the way to go for your particular
situation, you need only add the following lines to your list header file:
* Send= Editor
where "userid@some.host.edu" should be replaced with the network address of
the person who will be handling submissions to your list.
There can be multiple editors as well (and multiple Editor= lines, if
desirable), and they do not have to be list owners:
* Send= Editor
Normally, LISTSERV forwards submissions only to the first editor defined by the
"Editor=" keyword. In the case above, all submissions would go to the primary
list owner.
NOTE CAREFULLY that the first editor CANNOT be an access-level; e.g., you cannot
use the notation "Editor= Owner" to define the first editor. LISTSERV requires
that the primary editor of a list must be the e-mail address of a real person.
Note also that this does not apply to second and subsequent editors. For instance,
in order to allow subscribers to post directly but have non-subscriber posts sent
to an editor for approval, you can code something like:
* Send= Editor
On a high-volume list, LISTSERV allows you to share the editing load via the
"Moderator=" keyword. By default, this keyword is set to the same value as the
first editor defined by "Editor=". When you define more network addresses with
the "Moderator=" keyword, LISTSERV sends submissions to each moderator in
sequence. The difference between the "Editor=" and "Moderator=" keywords lies
in the fact that while any editor can post directly to the list, only
moderators receive the forwarded submissions from non-editors.
Here is an example of a list with both Editor= and Moderator= keywords
defined:
* Send= Editor
This list will "load-share" the editing duties between Kent and Joe. Tony is
able to post directly to the list, but will not receive forwarded subscriber
posts for editing.
Note that whereas an Editor is not required to be a Moderator, a Moderator
should always be listed as an Editor. LISTSERV currently compares the
contents of the "Editor=" and "Moderator=" keywords and consolidates the two
sets of parameters if necessary, but coding lists this way is not considered
good practice and the "compare/consolidate" feature may be removed in a future
upgrade.
By default, LISTSERV forwards subscriber contributions to the Moderator/Editor
with the following paragraph prepended to the message body:
When you are ready to edit and/or submit the contribution to the list, simply
use the "Forward" function of your mail client. You can make any changes you
feel are appropriate to the message body, but be sure to read sections 6.2 and
6.3 above before deciding to do so.
LISTSERV includes an optional mechanism allowing you to simply "ok" messages
which are then posted with all the correct headers. This option is targeted
mainly at list moderators who just approve/reject messages, as opposed to
people who actually edit the content of messages. The option is also a good
choice if you have a mail client that does not insert "Resent-" header lines
into forwarded mail.
To activate this feature, code your list "Send= Editor,Hold" and be sure that
you have defined at least one editor who will be in charge of approving the
messages. This defaults to the primary list owner if no other editor is
defined. A copy of the message on "hold" is sent to the editor with minimal
instructions (in order to avoid adding a long message before the text needing
approval each time).
To approve a message forwarded to you with "Send= Editor,Hold", simply reply to
the approval request and type "OK" as the body of your reply. LISTSERV
will normally pick up the confirmation request number from the subject line. If
there is a problem, LISTSERV may ask you to resend the approval confirmation
along with the number. For instance,
OK 6A943C
If the message has been in the spool longer than the time-out period (LISTSERV
holds these jobs for a minimum of 7 days), you will receive
notification that the confirmation number does not match any queued job.
If you do not want the message to be forwarded on to the list, you need not do
anything. The message will expire automatically at the end of the time-out
period and will be deleted from the queue.
List topics provide powerful "sub-list" capabilities to a list. When properly
set up and used, topics give subscribers the ability to receive list postings
in a selective manner, based on the beginning of the "Subject:" line of the
mail header. It is important to note the following points about topics:
* Topics= topic1,topic2,...topic11
And the basic syntax used to set topics for users once they have been defined
is:
SET listname TOPICS: xxx yyy zzz for userid@host
where xxx, yyy, and zzz can be:
Finally, it is important to note that topics are active only when the
subscriber's subscription is set to MAIL. Digests are indexes always contain
all the postings that were made, because the same digest is prepared and sent
to all the subscribers.
With the "Default-Topics=" keyword, you can also set default topics for users
that will be effective as soon as they subscribe to the list. For instance,
* Default-Topics= NEWS,BENCH,OTHER
would set the new user to receive topics NEWS, BENCHmarks, and any messages
that are incorrectly labeled.
See Appendix B for more information on setting up and using list topics.
When a user subscribes and signs off of a list, LISTSERV looks for list
owner-supplied files called listname WELCOME and listname
FAREWELL, respectively. If found, it sends the user a copy of the appropriate
file in addition to its own administrative message. The WELCOME and FAREWELL
files allow the list owner to send a more personal message to the user that can
help set the tone for how the list is used. The WELCOME file may contain
information about the list charter and netiquette rules, or be simply a message
welcoming the user to the list. The FAREWELL file can be used to gather
feedback about how the list is serving users.
The procedure differs slightly on VM systems, but the following will work for
unix, VMS and Windows systems:
2.5. Retrieving and editing the list - some considerations
Leaving the list locked also prevents new subscribers from signing up. It is
therefore not advisable to leave the list locked for long periods of time.
This necessitates remembering to issue the UNLOCK command if you decide
not to make any changes.
Another caution: If you GET the header with the (header switch,
do not add new subscribers "on the fly" to the bottom of the header. If you
do, your subsequent PUT will replace the entire list online with what
you have sent, canceling the subscriptions of every user on the list (except
for the ones you added to the header). 2.6. Defining list owners
Here is a sample list header excerpt for a list with all three types of list
owners defined:
-----------------------------------------------------------------------
* Owner= NATHAN@LSOFT.COM (Nathan Brindle)
* Owner= nathan@linus.dc.lsoft.com
* Owner= Quiet:
* Owner= ncbnet@linus.dc.lsoft.com,cheng@linus.dc.lsoft.com
-----------------------------------------------------------------------
Figure 2.2. Example: How to define list owners in the list header file.2.7. Adding and changing a list password
2.8. Storing the list on the host machine
2.9. Fixing mistakes
2.10. A sample list header file
-----------------------------------------------------------------------
PUT MYLIST.LIST PW=XXXXXXXX
* The Descriptive Title of My List
*
* Owner= NATHAN@LSOFT.COM (Nathan Brindle)
* Notebook= Yes,A,Monthly,Public
* Errors-To= Owner
* Subscription= Open,Confirm
* Ack= Yes Confidential= No Notify= No
* Files= No Mail-Via= Distribute Validate= No
* Reply-to= List,Respect Review= Public Send= Public
* Stats= Normal,Private X-Tags= Yes
* Default-Options= NoFiles,NoRepro
*
* This list installed on 95/02/02, running under L-Soft's LISTSERV-TCP/IP
* version 1.8b for Windows NT.
*
* Comment lines...
*
-----------------------------------------------------------------------
Figure 2.3. A sample list header file for a list called MYLIST.
-----------------------------------------------------------------------
PUT MYLIST.LIST PW=MYPASSWD
* The Descriptive Title of My List
*
* Owner= NATHAN@LSOFT.COM (Nathan Brindle)
* Owner= Quiet:
* Owner= nathan@linus.dc.lsoft.com
* Owner= ncbnet@linus.dc.lsoft.com
* Notebook= Yes,A,Monthly,Public
* AutoDelete= Yes,Full-Auto
* Errors-To= ncbnet@linus.dc.lsoft.com
* Subscription= Open,Confirm
* Ack= Yes Confidential= No Notify= No
* Files= No Mail-Via= Distribute Validate= No
* Reply-to= List,Respect Review= Public Send= Public
* Stats= Normal,Private X-Tags= Yes
* Default-Options= NoFiles,NoRepro
* PW=NEWPASSWD
*
* This list installed on 95/02/02, running under L-Soft's LISTSERV-TCP/IP
* version 1.8b for Windows NT.
*
* Comment lines...
*
-----------------------------------------------------------------------
Figure 2.4. The edited list header file ready to be sent back to the
server.2.11. Security Options
2.11.1. First line of defense: The VALIDATE= keyword
2.11.2. Controlling subscription requests
2.11.3. Controlling the service area of your list
* SERVICE= bitnode1,bitnode2,some.host.edu
* CONFIDENTIAL= SERVICE
SERVICE= can also be set to SERVICE= LOCAL, meaning it will use
either LISTSERV's global definition of which machines are LOCAL, or the
machines defined by the list keyword LOCAL=. If you wish to set
SERVICE to LOCAL, you should check with your LISTSERV maintainer
to find out which nodes are considered local. If the global definition is not
suitable, you can override it by defining the LOCAL= keyword:
* LOCAL= bitnode1,bitnode2,some.host.edu,another.host.com
* SERVICE= LOCAL
* CONFIDENTIAL= SERVICE
If there are many subdomains within your primary domain, you may wish to use
the wildcard when defining the LOCAL or SERVICE keywords. For
instance:
* SERVICE= HOST.COM,*.HOST.COM
defines the service area as "HOST.COM and all subdomains ending in
.HOST.COM".2.11.4 Controlling who may review the list of subscribers
2.11.5 Controlling who may access the notebook files
* NOTEBOOK= Yes,A,Monthly,Public
defines a monthly notebook on LISTSERV's A disk that is accessible by anyone.
Change Public to Private if you wish only subscribers to be able
to access the notebooks. The same access-levels are available for this keyword
as for REVIEW=. (See Appendix B for a discussion of access-levels.)2.11.6 Controlling who may post mail to the list
Below is a sample of the editor-header for a list set to Send= Editor,Hold:
-----------------------------------------------------------------------
From:
"L-Soft list server at PEACH.EASE.LSOFT.COM (1.8b)"
<LISTSERV@PEACH.EASE.LSOFT.COM>
Subject: ACCESS-L: approval required (701AC4)
To: Nathan Brindle <NATHAN@LSOFT.COM>
This message was originally submitted by joe@unix1.foo.bar.com to the
ACCESS-L list at PEACH.EASE.LSOFT.COM. You can approve it using the "OK"
mechanism, ignore it, or repost an edited copy. The message will expire
automatically and you do not need to do anything if you just want to discard
it. Please refer to the list owner's guide if you are not familiar with the
"OK" mechanism; these instructions are being kept purposefully short for your
convenience in processing large numbers of messages.
------------------------ Original message (26 lines) --------------------------
-----------------------------------------------------------------------
Figure 2.5 The editor-header for a list set to Send= Editor,Hold
A final method (called "self-moderation") exists for lists where subscribers
should be allowed to post freely, but non-subscriber posts should always be
sent to an editor for approval. To enable self-moderation, set
Send= Editor[,Hold]
Editor= userid@host,(listname)
Ensure that "listname" is in parenthesis. Note that self-moderation will catch
all posts from non-subscribers--including posts from subscribers who are
posting from a different address. For instance, if the subscriber originally
signed up as joe@foo.com but is posting from joe@unix1.foo.com,
LISTSERV will treat his mail as non-subscriber mail. Self-moderation may
require some slight changes in individual user subscriptions in order for it to
work seamlessly.2.11.7. The "OK" confirmation mechanism
It is also possible to confirm multiple command confirmation requests with a
single message (for instance, if you have Send= Editor,Hold and have a
number of requests to be responded to). This eliminates multiple "Message
approved" mails from LISTSERV. However, make sure that you send the
confirmations in a new mail message rather than replying to one of them.2.11.8 Personal Passwords
To add a personal password, send mail to LISTSERV with the command
PW ADD newpassword
in the body of the message. LISTSERV will request a confirmation via the "OK"
mechanism (see above) before it adds the password.
PW RESET
This command will also require confirmation.
PW CHANGE newpassword [PW=oldpassword]
If you do not include the old password in the command (e.g., you've forgotten
it), LISTSERV will request an "OK" confirmation. Otherwise, it will act on the
command without need for further confirmation (unless, of course, the
oldpassword provided is incorrect).2.11.9 Restricting subscriber privileges
* Filter= Also,MACTALK-L@*
See Appendix B for more information on the Filter= syntax.
3. Advertising Your Public Mailing Lists
3.1. List of Lists
3.2. The INFO <listname> command and how to implement it
If listname.MAILTPL does not exist, the default response is sent. Also
note that the user may send the INFO listname command to any
L-Soft LISTSERV host (including the Global List Exchange discussed below),
which will forward the request to the appropriate server.3.3. The NEW-LIST project at North Dakota State
(The NEW-LIST Project also published a hard-copy version of their archive in
1992 with a newer edition in 1993 under the title Internet: Mailing
Lists [ISBN 0-133-27941-3], edited by Edward T. L. Hardie and Vivian
Neou.)3.4. The Internet Network Information Center (INTERNIC)
3.5. The Global List Exchange (GLX) and why you should mention
it
3.6. How NOT to advertise a mailing list
4. Managing Subscriptions
4.1. How to add and delete subscribers to/from a list
4.1.1 X.400 and X.500 addressing--Special Problems
To get around both of these issues, the wildcard character ("*") can be used.
You may not need the entire address in order to delete it, so you might just
use4.2. Finding users who do not appear in the list
Nathan Brindle <nbrindle@INDYCMS.IUPUI.EDU>
Somebody Else <nathan@LSOFT.COM>
Jonathan Smith <jsmith@FOO.BAR.COM>
SCAN: 3 matches.4.3. Converting mailing lists to LISTSERV from other systems
The IMPORT option speeds up the operation of adding many subscribers "in
bulk" at one time by causing LISTSERV to omit success messages and to relax
syntax checking.
//X DD *
user1
user2
/*
4.4. Using the QUIET option with commands
QUIET DELETE EXCEL-L Bouncemeister@somenode.edu4.5. Dealing with bounced mail
4.5.1. What is a bounce, and what can typically cause one?
4.5.2. What to do about several types of bounces
A particularly annoying error you may have to deal with comes from Banyan
networks and is of the form:
binmail: /usr/spool/mail/userid: too big to accept new messages.
It's size is 205735 bytes which is 935 bytes over quota.
mail: cannot open dead.letter
554 <userid@node>... unknown mailer error 1
This is apparently a "mailbox full" error, as "userid's" mail spool is "over
quota". It is also possible that it means your message would put the user over
quota by 935 bytes. Either way, there isn't enough space in the user's mailbox
to store your message (in this case, it was a daily digest). Note that "unknown
mailer error x" does not always mean the user's mailbox is full - what it
always means is that sendmail cannot identify the cause of the error.
Bill Smith <LLONG%StarShip%Dora@BOONDOCK.TERTIUS.COM>
SCAN: 1 match.4.5.3. Redistribution and forwarding
4.6. Automatic and semi-automatic deletion
4.6.1. Auto-Delete considerations for holidays
4.7. Subscription confirmation
Note that if a list owner adds a user manually, the confirmation process is
bypassed.4.8. Subscription renewal
or
* Renewal= interval,Delay(number)4.9. The SERVE command
4.10. "Peering" large lists
4.10.1 Moving users from one (peer) server to another:
Query listname FOR userid@host (old server), write down
the options.
2c. If there are a lot of users to move, the following method is preferred:
GET listname (old server)
4.10.2 Special commands for peered lists only
5. Setting Subscription Options For Subscribers
5.1. How to review current subscription options with QUERY
5.2. How to set personal subscription options for subscribers
5.3. Options that may be set
5.3.1. Mail/NOMail
5.3.2. DIGest/NODIGest
To revert from digest/index subscription mode to normal delivery, you can use
either the MAIL option as before, or the NODIGEST/NOINDEX option. The NODIGEST
and NOINDEX options were actually present in versions 1.7f and 1.8a, as
synonyms for the MAIL option. In other words, you can update your instructions
to indicate that the DIGEST/INDEX options are negated by the NODIGEST/NOINDEX
options, even if your server is not yet running version 1.8b. 5.3.3. INDex/NOINDex [VM only]
5.3.4. ACK/NOACK/MSGack
5.3.5. Options for mail headers of incoming postings
5.3.6. CONCEAL/NOCONCEAL
5.3.7. REPro/NOREPro
5.3.8. TOPICS
5.3.9. POST/NOPOST
5.3.10. EDITOR/NOEDITOR
5.3.11. REVIEW/NOREVIEW
5.3.12. RENEW/NORENEW
5.4. Setting original default options with the Default-Options=
keyword
6. Moderating and Editing Lists
6.1. List charters, welcome files, and administrative updates
6.2. The role of the list owner as moderator
6.3. The role of the list owner as editor
6.4. Setting up an edited list
* Editor= userid@some.host.edu
* Editor= alex@reges.org,joe@foo.bar.edu
* Editor= tony@tiger.com
* Editor= alex@reges.org,(MYLIST-L)
* Editor= joe@foo.bar.edu,tony@tiger.com,kent@net.police.net
* Moderator= kent@net.police.net,joe@foo.bar.edu6.5. Submitting subscriber contributions to an edited list
-----------------------------------------------------------------------
This message was originally submitted by JOE@FOO.BAR.COM to the ACCESS-L
list at PEACH.EASE.LSOFT.COM. If you simply forward it back to the list, using
a mail command that generates "Resent-" fields (ask your local user support or
consult the documentation of your mail program if in doubt), it will be
distributed and the explanations you are now reading will be removed
automatically. If on the other hand you edit the contributions you receive into
a digest, you will have to remove this paragraph manually. Finally, you should
be able to contact the author of this message by using the normal "reply"
function of your mail program.
------------------ Message requiring your approval (25 lines) -----------------
[message body]
-----------------------------------------------------------------------
Figure 6.1. The "editor-header" prepended by default to subscriber contributions
forwarded to the list moderator.
If you leave this paragraph prepended to the message, LISTSERV will strip it
off when it processes the message and to all intents and purposes the message
will appear to have come directly from the original sender. Warning: If your
mail program or client does not generate "Resent-" fields, the forwarded
postings will appear to be coming from you rather than from the original
sender. See Section 6.6 for an alternative if your mail program does not
generate these fields.6.6. Message Approval with Send= Editor,Hold
6.7. Using list topics
The basic keyword syntax for defining list topics in the list header file is:
The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted.
The subscriber should not forget to include the special OTHER topic if you want
to receive general discussions which were not labeled properly. On the other
hand, if the subscriber only wants to receive properly labeled messages it
should not be included. ALL does include OTHER.6.8. The listname WELCOME and listname FAREWELL files
6.8.1. Creating and storing the listname WELCOME and FAREWELL files