List Owners'
Primer
alpha 0.192
by Michael S. Johnson
msj@u.washington.edu
nausicaa-request@brownvm.brown.edu
http://weber.u.washington.edu/msj
at the University of Washington; Seattle, WA
(c) Spring 1995
Acknowledgments
For their valuable feedback during the development cycle of this documentation:
John Blankenship dmt@u.washington.edu NAUSICAA Theo Hua quark@u.washington.edu NAUSICAA
For their enthusiastic support for this project, I am grateful to the following list owners:
Bob Chandler bobgc@uwindsor.ca CSOCWORK Brian Fisk bfisk@netspace.org Craig Gjerde clgjerde@facstaff.wisc.edu Dave Kinnaman kinnaman@tenet.edu Dan Lester alileste@idbsu.idbsu.edu WORDS-L Darlene Peckham nera@netcom.com Leon D. Wald ldwald@mmm.com
And last, but not least–for providing the BITNET and Unix world with LISTSERV:
Eric Thomas eric@searn.sunet.se LSTOWN-L
LSTSRV-L
Dedications
This primer is dedicated to John, Theo, subscribers of LSTOWN-L, and novice LISTSERV list owners everywhere, who I hope will find this documentation a little more readable than most MEMOs or REFCARDs.
Disclaimers
This primer is being produced as a homework assignment for the Computer Documentation class Technical Communications 407, under the instruction of Professor Hunter Thompson. As such, time constraints prevent this documentation from becoming a novice list owner's panacea. The aim is to provide a list owner with enough rough-and-ready information to handle basic list administrative tasks.
Although this document has caught the interest of a number of people on the list owner's mailing list, I must stress that the original intended audience for this documentation was limited to John and Theo, the two co-owners of the NAUSICAA mailing list that I run. I am more familiar with what they know and do not know, and what terminology I can use and get away with. It also helps that I'm within easy reach and available for questioning. This means that any other audience may not be properly served by the scope or presentation of the material herein. I apologize for this, but given the constraints of a class project and my limited knowledge of LISTSERV, I must make certain sacrifices, up to and including sleep.
Copyright and Distribution
This document is to be released into the public domain with limited permission granted to copy and redistribute in any oncommercial form, so long as copyright remains with the myself, mention is made of this source in any derivative works, and I am notified of any such redistribution. Donations are welcome but not required. Your mileage may vary.
Where can I find a copy?
FTP: host: ftp.u.washington.edu
directory: /public/LISTSERV
WWW: URL: http://weber.u.washington.edu/msj/LISTSERV/
ftp://ftp.u.washington.edu/public/LISTSERV/
Table of contents // rubbish! // edit this
Introduction
Background information what is LISTSERV? what does LISTSERV do? where do I, as
list manager, fit in? what are my responsibilities?
List-management tasks
Handling subscriptions troubleshooting subscription problems subscribing a user
to the mailing list unsubscribing a user from the mailing
list changing a user's subscription information
Controlling mail troubleshooting delivery problems suspending mail
delivery to subscribers delivery to a subscriber resuming mail delivery to a
subscriber changing frequency of mail delivery to a
subscriber
Performing list changing list ownership changing list behavior adding
maintenance [might not files to be stored on the list server [will not be
be documented due to documented due to lack of experience with this task]
lack of time and retrieving files stored on the list server updating files
advanced nature of these stored on the list server deleting files stored on the
tasks] list server troubleshooting problems with list's behavor.
Reference
further reference command syntax glossary index
What am I reading?
This booklet is a guide to LISTSERV list maintenance tasks. It is intended to be used by novice list owners who need to get up to speed with LISTSERV and basic list maintenance responsibilities quickly.
How to use this guide
This guide is split up into sections for easy reference. Each section answers broad questions such as "What is LISTSERV?", and contains subsections which answer more and more detailed questions such as "How do I prevent mail being distributed to the list from a troublesome user?"
There are three main sections, each of which answers a few basic questions:
Section: Applicable Questions:
Introduction What is this guide? What is LISTSERV?
List-management tasks What can I do with LISTSERV? How do I
fix problems with my list?
Reference What do these terms mean? How do I use
the X command? Where can I learn more
about LISTSERV?
Conventions
used in this primerTypefaces used
"LISTSERV" will always appear in boldfaced, monospaced typewriter font (Courier New).
COMmands TO LISTSERV
...will be CAPITALIZED and italicized except for the parts of command names which are optional, or parts of the command which need to be replaced with nonfictional values before they can be used properly.
Examples of email are enclosed in a box wide enough for 80 characters
and centered on the page, with text in monospaced typewriter font.
Text which may appear in an email message, or may for any reason appear on your computer screen (if, for instance, you are asked to type it in) will appear in monospaced typewriter font. This includes email addresses, whether or not they appear in a boxed example.
Which LISTSERV am I referring to?
I refer to LISTSERV in several contexts, each with slightly different meanings. Sometimes it refers to the list server program and all of the information it handles. Sometimes, just the program. Otherwise, its email address. Sometimes I'm referring to a particular LISTSERV–maybe yours, maybe mine, maybe the one in Sweden that Eric Thomas uses. Otherwise, I'm referring to any or all of them, as if they all behaved identically, which is almost always the case. I'm going to wave my hands, mumble "hocus pocus" and assume they all do.
Introduction to LISTSERV
What is LISTSERV?
In my examples, I will either refer to it as "the list server", LISTSERV@brownvm.brown.edu, or simply LISTSERV. Note that the second one is the email address of the list server for my list, NAUSICAA[1], the Hayao Miyazaki Discussion Group.
What does LISTSERV do?
It hosts the mailing list in question: where its archives are stored, where its messages are sent, where the LISTSERV that manages the list resides.
Where do I, as list owner or list manager, fit in? What are my responsibilities?
You are the person in charge of maintaining the smooth, error-free operation of the mailing list. You define or maintain the policies against which message traffic on the mailing list will be judged. You control the behavior of the list and guard it from abuse and malfunction. You are the person on whom the world dumps its blame and scorn when things go wrong. In other words, you are providing a service to others and with this comes the curse upon all persons involved with the service industry.
Of course, you aren't completely powerless. There are standard ways to deal with the problems that you will encounter, and most of them are pretty simple to take care of. You can even solve all your problems by deleting all the subscribers and closing the list! This is known as curing the disease by killing the patient.
Before you begin
Important: if you are not familiar with sending electronic mail (email), you are out of luck until you do. This documentation requires at least a basic familiarity with email, so it is beyond the scope of this primer to provide instructions on how to send and receive email. I will assume you have at least a basic familiarity with the sending and receiving email, how to recognize the various parts of a message, and what those parts mean. If not, I have tried to provide definitions for terminology used in this primer in the Glossary on page 45.
Sending commands to LISTSERV first requires that you know its email address. In other words, you need to know how to contact the list server before you can tell it what to do. I will assume you know what this address is.
I will also assume you know the difference between sending messages to the mailing list and messages to LISTSERV itself. Typically, messages to a mailing list are addressed to listname@your.list.server.host, whereas email to LISTSERV itself are addressed to LISTSERV@your.list.server.host.
Overview
List server commands are lines of text packaged inside email messages addressed to LISTSERV. In some cases, each line represents one command. In other cases, a command can be so long as to span more than one line, or may involve a command followed by data that LISTSERV requires to process the command properly.
A simple message to LISTSERV
One of the simplest email messages to send a LISTSERV, giving thanks to the powers that be, might look like this:
To: listserv@listserv.net
Subject: this gets ignored by LISTSERV, anyway
Thanks
That's it! Note that the command THANKS didn't need to appear in ALL CAPS. Let's see what we get back in return:
Date: Tue, 2 May 1995 06:29:35 -0400
From: "L-Soft list server at BROWNVM (1.8a)" <LISTSERV@BROWNVM.brown.edu>
To: "Michael S. Johnson - List Owner" <msj@U.WASHINGTON.EDU>
Subject: Output of your job "msj"
> thanks
You're welcome!
Summary of resource utilization
-------------------------------
CPU time: 0.002 sec Device I/O: 0
Overhead CPU: 0.003 sec Paging I/O: 0
CPU model: 9121 DASD model: 3390
So what happened here? Let's take this message apart and identify each part:
Identifying the Message Header:
Date: Tue, 2 May 1995 06:29:35 -0400
From: "L-Soft list server at BROWNVM (1.8a)" <LISTSERV@BROWNVM.brown.edu>
To: "Michael S. Johnson - List Owner" <msj@U.WASHINGTON.EDU>
Subject: Output of your job "msj"
The top four lines make up the header of the message. The header of any email message provides information about the message such as when it was sent (not when it was received), who it was sent by (in this case LISTSERV@BROWNVM.brown.edu), to whom it was sent (this can be important if you want to see who else was sent a copy), and what the message is about (the subject).
Identifying the Message Body:
> thanks
You're welcome!
Summary of resource utilization
-------------------------------
CPU time: 0.002 sec Device I/O: 0
Overhead CPU: 0.003 sec Paging I/O: 0
CPU model: 9121 DASD model: 3390
The body of the message is everything below the header. It contains the meat of the email message. What we see here is an echo of the command we sent to LISTSERV (">thanks"), and LISTSERV's response to that command ("You're welcome!"). Since we only sent one command, there is only one result. However, at the bottom of most commands sent to LISTSERV, there is a table of information with six numbers which describes how much of the computer's resources LISTSERV used when asked to respond to the command. For trivial commands like this one, the time involved is negligible. The bulk of the time between when the comand was sent and the response was received can be accounted for by the speed (or slowness) of the network and by how busy the list server was when it received the new command from us. Chances are, you'll spend most of your time waiting for the results of commands to make their round-trip journey rather than reading them.
Date: Tue, 2 May 1995 06:21:57 -0400
From: "L-Soft list server at BROWNVM (1.8a)" <LISTSERV@BROWNVM.brown.edu>
To: "Michael S. Johnson - List Owner" <msj@U.WASHINGTON.EDU>
Subject: Output of your job "msj"
> help
LISTSERV version 1.8a - most commonly used commands
Info <topic|listname> Order documentation
Lists <Detail|Short|Global> Get a description of all lists
SUBscribe listname <full name> Subscribe to a list
SIGNOFF listname Sign off from a list
SIGNOFF * (NETWIDE - from all lists on all servers
REView listname <options> Review a list
Query listname Query your subscription options
SET listname options Update your subscription options
INDex <filelist_name> Order a list of LISTSERV files
GET filename filetype Order a file from LISTSERV
REGister full_name|OFF Tell LISTSERV about your name
There are more commands (AFD, FUI, PW, etc). Send an INFO REFCARD for a
comprehensive reference card, or just INFO for a list of available
documentation files.
This server is managed by:
Peter DiCamillo <CMSMAINT@BROWNVM.BITNET>
Summary of resource utilization
-------------------------------
CPU time: 0.006 sec Device I/O: 0
Overhead CPU: 0.002 sec Paging I/O: 1
CPU model: 9121 DASD model: 3390
dList-management tasks
List management requires the ability to send commands to the list server (LISTSERV). There are at least two ways to do so, but this primer will only concern itself with the one method, electronic mail, by which all list owners can control their lists.
Before you begin
If you are not famliar with sending commands to LISTSERV via electronic mail, you will not be able to manage your list(s) effectively. Please read the How to send LISTSERV commands section on page 13 for a tutorial on how to send LISTSERV commands via email.
Overview
List management involves:
· sending commands to LISTSERV via email
· receiving responses information and error messages from LISTSERV
· interacting with subscribers, postmasters and system administrators
Handling subscriptions
Subscribing someone to the mailing list:
See page 36 in the Command Syntax section for the syntax of the ADD command.
Unsubscribing a user from the mailing list:
DELete[2] listname email-address-of-subscriber
listname is the name of the mailing list you run. This is usually a word
or acronym of up to eight letters in length.
email-address-of-subscriber is the email address that the subscriber has list messages
delivered to.
Changing a user's subscription information–General:
SET listname option FOR email-address-of-subscriber
listname is the name of the mailing list you run. This is usually a word
or acronym of up to eight letters in length.
option is one of: ACK, NOACK, CONCEAL, NOCONCEAL, DIGEST, INDex, Files,
NOFiles, MAIL, NOMAIL, REPro, and NOREPro.3 These are explained
in more detail below.
email-address-of-subscriber is the email address that the subscriber has list messages
delivered to.
These
options are explained in more detail below.
Changing a user's subscription information–Mail delivery:
SET listname NOMAIL FOR email-address-of-subscriber
NOMAIL tells LISTSERV not to deliver messages from the list to this
subscriber. This is useful for people who go on vacation or
otherwise can't read their mailfor long periods of time. Note
that NOMAIL is not the same as unsubscribing; this person is
still a subscriber.
SET
listname MAIL FOR email-address-of-subscriber
MAIL tells LISTSERV to allow delivery of messages from the list to
this subscriber from this time forward. No messages the
subscriber has missed in the meantime will be delivered because
there is no record kept of which messags were not delivered.
Changing
a user's subscription information–Privacy:SET listname CONCEAL FOR email-address-of-subscriber
CONCEAL tells LISTSERV to hide this subscriber from the output of the
REVIEW command. This is useful for protecting the privacy of a
subscriber who doesn't want people to know s/he is subscribed to
the list in question. Otherwise, this doesn't affect any other
subscription information for this person.
SET
listname NOCONCEAL FOR email-address-of-subscriber
NOCONCEAL tells LISTSERV to allow the REVIEW command to reveal this
subscriber in its list of (non-CONCEALed) subscribers.
Changing
a user's subscription information–Feedback about messages sent to the
list:SET listname ACK FOR email-address-of-subscriber
ACK tells LISTSERV to send an acknowledgement back to the person who
sent a message to the mailing list. This is useful for giving
the subscriber peace-of-mind s/he is worried that her/his
messages aren't being properly delivered to the mailing list.
SET
listname NOACK FOR email-address-of-subscriber
NOACK tells LISTSERV to not send any such acknowledgement, whether or
not the mail was successfully distributed to the other
subscribers of the list.
SET
listname REPro FOR email-address-of-subscriber
REPro tells LISTSERV to also send a copy of a message back to the
sender. This can also serve as an acknowledgment of delivery,
and is useful for subscribers who like to keep copies of the
messages they send to the mailing list.
SET
listname NOREPro FOR email-address-of-subscriber
NOREPro tells LISTSERV to not send a copy of a message back to the
sender. This does not affect the ACK/NOACK setting; a
subscriber may still receive acknowlegement of a message without
receiving a REPro copy from LISTSERV.
NOTE:
ACK and REPro are not mutually exclusive. ACK REPro, ACK NOREPro, NOACK REPro,
and NOACK NOREPro are perfectly valid combinations. Whether some of these
combinations are useful to you or your subscribers is another matter.
Changing a user's subscription information–Bulk versus individual message delivery:
SET listname DIGests FOR email-address-of-subscriber
DIGests tells LISTSERV to send the subscriber several messages in a
batch, or all messages sent to the list within a given time
period, instead of sending every message separately. You may be
familiar with Reader's Digest, or you may be famliar with the
difference between a daily newspaper and a weekly. Similar
concepts. This is useful to a subscriber who may want all of
the mailing list traffic delivered in bulk at regular intervals
rather than individually at all hours of the day and night.
SET
listname INDex FOR email-address-of-subscriber
INDex tells LISTSERV to only send an index or table of contents of the
DIGested messages. The subscriber will then have to
specifically ask for the content of any messages s/he wants to
read.
SET
listname NOMAIL FOR email-address-of-subscriberSET listname MAIL FOR email-address-of-subscriber
NOMAIL MAIL this pair of commands in this order tells LISTSERV to switch
back from DIGest (bulk) message delivery to regular mail
delivery (individual messages) for this user.
Troubleshooting
subscription problems–Introduction to error messages:When everything works smoothly, it's business-as-usual. But when things go wrong, you're likely to be the first person to hear about it. Either from the LISTSERV or from the subscribers themselves. Learning to handle these problems requires you to recognize the symptoms and decide upon a solution.
LISTSERV reports errors to the list owner(s) via email. This is important. This means that you are responsible for keeping up with your email on a regular basis. A list owner that cannot be contacted to solve problems with the list is a negligent one, bound to be a source of irritation to both the subscribers and the LISTSERV management at the site that hosts your mailing list.
So how do you recognize error messages? By their Subject, which always follows a particular pattern:
LISTNAME: error report from HOST
LISTNAME: this is the name of the mailing list for which the error
occurred, usually in CAPS.
error report from this tells us that this message contains a report about one or
more errors that LISTSERV wants to bring to our attention.
HOST this is the name of the machine that generated the error
message, usually in CAPS.
Typical error messages will look like the example shown under the heading Example Error Message from LISTSERV on page 40.
Troubleshooting subscription problems–Types of errors:
Now that you know what a typical error message looks like, here are some extracts from common types of error messages and references to likely causes:
Error Message: Where to find it: Likely Causes: Brief Solution:
Subject: LISTNAME: in the first A message from your mailing Read the rest of the
error report from Subject header list could not be delivered message for further
list-server-host to one or more subscribers. information about the
error(s).
<user@host> in the second A message from your mailing For more information,
(unrecoverable error) message body (the list could not be delivered look for more details
one forwarded by to that subscriber and no related to the address
LISTSERV that further attempts will be <user@host>. There is
contains the made to redeliver that usually another, more
actual error message. specific, message such
messages) as "user unknown" or
"host unknown" further
along in the error
report.
<user@host> in the second A message from your mailing For more information,
(transient failure) message body list could not be delivered look for more details
to that subscriber, but about the failure, such
further attempts will be as "message undelivered,
made to redeliver that will keep trying until 8
message. days old".
continued...
Error Message: Where to find it: Likely Causes: Brief Solution:
User unknown in the second Two possibilities: (1) the See user unknownHow to
message body subscriber is truly gone, handle "User unknown"
or (2) the subscriber's errors (p. 29).
machine is malfunctioning,
and "forgot" s/he existed.
user@host auto-deleted in the first LISTSERV recognized a "user See auto-deleted
Subject header unknown" message and usersHow to handle
unsubscribed this user from "auto-deleted"
the list automatically. subscribers (p. 29).
Host unknown in the second Two possibilities: (1) the See host unknownHow to
message body host4 really doesn't exist handle "Host unknown"
(anymore), or (2) the errors (p. 29).
machine that should have
known where it was is
malfunctioning and "forgot"
how to contact it.
Host is unreachable in the second Two possibilities: (1) the See host unreachableHow
message body host cannot be contacted, to handle "Host
or (2) a machine between unreachable" errors (p.
LISTSERV and the host isn't 29).
responding.
continued...
Error Message: Where to find it: Likely Causes: Brief Solution:
Connection timed out in the second Two possibilities: (1) the See host unreachableHow
/ Connection refused message body host itself can't respond, to handle "Host
or (2) is refusing to unreachable" errors (p.
(probably because it is too 29).
busy already).
transfer failure; MTA in the second This unusual message arose See host unreachableHow
congested or not message body when subscribers in Spain to handle "Host
running could not be reached by unreachable" errors (p.
LISTSERV@brownvm. 29).
There
are many other possible error messages, but listing them all would be
impossible. The more common ones are listed above. Others may be variations
on these, worded differently. The point is: when mail can't be delivered, it's
because (1) the subscriber doesn't exist, (2) the subscriber's machine is too
busy or can't be reached, (3) the person is prevented from sending a message to
the list because of a "filter" defined for this purpose (see Configuring the
list–changing its behavior, p. 32).
Troubleshooting subscription problems–Handling various errors:
It is difficult to say how to handle these errors properly, since many methods vary among list owners and the types of lists that they run. The list owner's personality can be just as important a factor as the size, age, or maturity of the list. Lazy list owners will ignore some errors until they go away by themselves, or unsubscribe the users who "cause" the errors. Aggressive list owners will have an arsenal of network utilities at hand to hunt down network problems and "unknown" subscribers.
How to handle "User unknown" errors
How to handle "auto-deleted" subscribers
How to handle "Host unknown" errors
How to handle "Host unreachable" errors
Controlling mail delivery to subscribers
Changing a user's subscription information–Mail delivery:
SET listname NOMAIL FOR email-address-of-subscriber
NOMAIL tells LISTSERV not to deliver messages from the list to this
subscriber. This is useful for people who go on vacation or
otherwise can't read their mailfor long periods of time. Note
that NOMAIL is not the same as unsubscribing; this person is
still a subscriber.
SET
listname MAIL FOR email-address-of-subscriber
MAIL tells LISTSERV to allow delivery of messages from the list to
this subscriber from this time forward. No messages the
subscriber has missed in the meantime will be delivered because
there is no record kept of which messags were not delivered.
Changing a user's subscription information–Feedback about messages sent to the list:
SET listname ACK FOR email-address-of-subscriber
ACK tells LISTSERV to send an acknowledgement back to the person who
sent a message to the mailing list. This is useful for giving
the subscriber peace-of-mind s/he is worried that her/his
messages aren't being properly delivered to the mailing list.
SET
listname NOACK FOR email-address-of-subscriber
NOACK tells LISTSERV to not send any such acknowledgement, whether or
not the mail was successfully distributed to the other
subscribers of the list.
SET
listname REPro FOR email-address-of-subscriber
REPro tells LISTSERV to also send a copy of a message back to the
sender. This can also serve as an acknowledgment of delivery,
and is useful for subscribers who like to keep copies of the
messages they send to the mailing list.
SET
listname NOREPro FOR email-address-of-subscriber
NOREPro tells LISTSERV to not send a copy of a message back to the
sender. This does not affect the ACK/NOACK setting; a
subscriber may still receive acknowlegement of a message without
receiving a REPro copy from LISTSERV.
NOTE:
ACK and REPro are not mutually exclusive. ACK REPro, ACK NOREPro, NOACK REPro,
and NOACK NOREPro are perfectly valid combinations. Whether some of these
combinations are useful to you or your subscribers is another matter.
Configuring the list–changing its behavior
It is possible to redefine how the mailing list behaves in certain respects. The file that contains the information that controls the list's behavior is called the list header. This is similar to a mail header in that they both precede other pieces of information. Where a mail header precedes a message, a list header precedes the list of subscribers and their email addresses. The file that contains the header and subscriber list is stored on the same host that has the LISTSERV software, so that LISTSERV can refer to the list of subscribers when distributing mail and can refer to the definition of the list's behavior if that differs from a default.
This means that the list header is only part of a larger file that does have a name, which is listname LIST. listname is, of course, to be replaced by name of your list. There are two ways to look at this file. One is by requesting that LISTSERV send you the file by name with a command called GET, or by using a command called REVIEW. Both are described below.
GET filename [filetype]
GET asks LISTSERV to deliver a file to you via email.
filename [filetype] are two components to a file name, with the square brackets
indicating which part is, in certain cases, optional. You do
not type in the square brackets as part of the command. If a
filetype is not provided, the filename is assumed to be the name
of a mailing list. and the full file name filename LIST will be
the file returned to you, which is in fact the list header.
REView listname ( options
REView asks LISTSERV to deliver information about a mailing list to you
via email.
listname is the name of the mailing list you are requesting information
about. You must provide the name of a list, otherwise LISTSERV
will send an error message back to you describing what you
forgot to tell it.
( options If no options are specified, the whole list header is sent.
This header contains the configuration information and the list
of non-CONCEALED subscribers. (See also Changing a user's
subscription information–Privacy, p. 21.) The first option must
be preceeded by a left-parenthesis "(", but no right-parenthesis
is required.
valid options are:
NOHeader Don't send the list-behavior settings, just the list of
subscribers.
Short Don't send the list of subscribers, just the list-behavior
settings.
BY Name Sort the list of subscribers by last name, then first name.
BY Country Sort the list of subscribers by country (determined by their
host name).
These
options may be combined in ways you might expect, as long as they aren't
mutually exclusive. For example: "REView NAUSICAA ( NOHeader BY Country".
the list header, what is it?
Performing list changing list ownership changing list behavior adding maintenance [might not files to be stored on the list server [will not be be documented due to documented due to lack of experience with this task] lack of time and retrieving files stored on the list server updating files advanced nature of these stored on the list server deleting files stored on the tasks] list server troubleshooting problems with list's behavor.
Reference
reference
Further reference
further reference
Command Syntax
ADD
ADD is the name of the LISTSERV command that will add a new
subscriber to your list.
listname is the name of the mailing list you run. This is usually a word
or acronym of up to eight letters in length.
email-address-of-subscriber is the email address that the new subscriber would like to have
messages from the list delivered to. This may be different from
their email address for personal (non-list) messages.
name-of-subscriber is the subscriber's name.5 This can be quite long, does not
need to be "enclosed in quotation marks", and will include all
words on the same line after the listname.
Examples
Examples
Example acknowledgement message
Return-Path: <LISTSERV@SEARN.SUNET.SE>
Date: Tue, 2 May 1995 07:13:09 +0200
Subject: Message ("Your message dated Mon, 1 May 1995 22:16:33 -0700...")
To: "Michael S. Johnson" <msj@CAC.WASHINGTON.EDU>
Your message dated Mon, 1 May 1995 22:16:33 -0700 (PDT) with subject ""Error
while logging mail . . ." (fwd)" has been successfully distributed to the
LSTOWN-L list (265 recipients).
This message from LISTSERV indicates that it received and properly
forwarded my message to the subscribers of the LSTOWN-L mailing list.
What is implied however, is that these recipients don't have NOMAIL set. If
there were 270 total subscribers, and five of them had SET LSTOWN-L NOMAIL,
then only these 265 would have received a copy of my message.
Example output of the REVIEW command
Return-Path: <owner-LISTSERV@BROWNVM.BROWN.EDU>
Date: Sun, 23 Apr 1995 16:12:53 -0400
Subject: File: "NAUSICAA LIST"
To: "Michael S. Johnson" <msj@CAC.WASHINGTON.EDU>
PUT NAUSICAA LIST PW=XXXXXXXX
*
* Hayao Miyazaki Discussion Group
*
* Review= Public Subscription= By_owner Send= Public
* Notify= Yes Reply-to= List,Respect Files= Yes
* Validate= Store only Stats= Normal,Private
* Confidential= No X-tags= No Safe= No
* Ack= Msg Notebook= Yes,U,Weekly,Public
* Mail-Via= Dist2
*
* Owner= msj@u.washington.edu (Michael S. Johnson)
* Owner= dmt@u.washington.edu (John Blankenship)
* Owner= quark@u.washington.edu (Theo Hua)
* Owner= Quiet:
* Owner= msj@cac.washington.edu (Michael S. Johnson)
* Owner= sfeldman@vmsvax.simmons.edu (Steven Feldman)
* Owner= ar402004@brownvm.brown.edu (Steven Feldman)
* Owner= ar402004@brownvm (Steven Feldman)
* Errors-to= Owners
*
* * * * * * * * * * * * * * * * * * * * * * * *
*
* Abstract:
*
* This list is a forum for the discussion of subjects related to the
* anime (Japanese animation) & manga (Japanese comics) of Hayao Miyazaki
[...lots of descriptive text here...]
*
[...here is the list of subscribers...]
dmt@U.WASHINGTON.EDU John Blankenship
hachiman@U.WASHINGTON.EDU Matt Downer
msj@U.WASHINGTON.EDU Michael S. Johnson - List Owner
quark@U.WASHINGTON.EDU Theodore Hua
[...but this was only an extract...]
*
* Total number of users subscribed to the list: 205
* Total number of local node users on the list: 1
*
[...and this is the end of the output of the REVIEW command.]
Example Error Message from LISTSERV
Let's face it: nothing works perfectly. Problems will arise, and
LISTSERV will need to bring them to your attention. You will need to
recognize the format of error reports that will find their way into your
electronic mailbox. The following pages will describe the components of one
long error message received from LISTSERV regarding problems with mail delivery
to certain subscribers. The contents of the message are split up into several
figures, each of which will be described.
Identifying the Message Header
Return-Path: <owner-LISTSERV@BROWNVM.BROWN.EDU>
Date: Sat, 22 Apr 1995 17:24:09 -0400
Subject: NAUSICAA: error report from LISTSERV.BROWN.EDU
To: John Blankenship <DMT@U.WASHINGTON.EDU>,
"Michael S. Johnson - List Owner" <MSJ@U.WASHINGTON.EDU>,
Theodore Hua <QUARK@U.WASHINGTON.EDU>
X-Lsv-Listid: None
X-Status:
The part above is called the message header. This is information about the mail message that describes where it came from (Return-Path:), when it was written (Date:), what it's about (Subject:), who it's addressed to (To:), and contains some extra header information with the pattern "X-something-something:" which we can ignore for now.
Identifying the Message Body:
The message body is defined as everything after the message header. This includes any nested messages (messages quoted within messages) and their headers and bodies.
Skipping the jargon:
The enclosed message, found in the NAUSICAA mailbox and shown under the spool
ID 2824 in the system log, has been identified as a possible delivery error
notice for the following reason: "Sender:", "From:" or "Reply-To:" field
pointing to the list has been found in mail body.
Sometimes, you can ignore parts of the message which only summarize information
provided below. This part above can be summarized as follows: "LISTSERV
encountered problems delivering mail for the NAUSICAA list."
Identifying the Error Report Header
------------------------ Message in error (83 lines) --------------------------
Return-Path: <>
Received: from BROWNVM [...]
Date: Sat, 22 Apr 1995 17:24:28 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@listserv.brown.edu>
Here we see the header of the error report sent to LISTSERV. Multiple "Received:" lines, which only describe the path this message took to reach its destination (you), were deleted for brevity. The "MAILER-DAEMON" is the program that reported the mail-delivery errors to LISTSERV.
Subject: Returned mail: User unknown
Now we have a better idea what the nature of the problem is. "User unknown"
indicates that the subscriber might no longer have an email account anymore. I
say "might" because that this is not the only reason a user might be "unknown"
to the system. Other reasons include errors with the database of users: the
system that hosts the subscriber's account could have some malfunction that
caused it to "forget" that the subscriber exists. Disambiguating this
information can be difficult, but will be dealt with later.
Identifying the Error Message Body
Message-Id: <199504222124.RAA05025@listserv.brown.edu>
To: <NAUSICAA@BROWNVM.BROWN.EDU>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="RAA05025.798585868/listserv.brown.edu"
This is a MIME-encapsulated message
--RAA05025.798585868/listserv.brown.edu
The original message was received at Sat, 22 Apr 1995 17:10:23 -0400
from stanley.cis.brown.edu [128.148.176.55]
Below the error message header, which ends with the last line that begins with
a keyword and colon, lies its body. This message body contains the copy of the
error message. You might notice that, according to the "To:" header, this
message was originally going to be reported to the whole mailing list
(NAUSICAA, in this example); however it was caught by LISTSERV and
delivered to the list owners for their attention instead. Don't be confused by
the reference to the machine called stanley–sometimes delivering mail may
involve cooperation among many machines, any or all of which can potentially
report errors.
Identifying an Error Message–Unrecoverable Error
----- The following addresses had delivery problems -----
<thudson@SDCC13.UCSD.EDU> (unrecoverable error)
This indicates that mail from the mailing list to the subscriber
(thudson@SDCC13.UCSD.EDU) encountered some problem that could not be corrected
by making further attempts to deliver the message.
Identifyfing an Error Message–Host Unreachable
----- Transcript of session follows -----
<bogawa@SEAS.UCLA.EDU>... Deferred: Host is unreachable
<marcon@KAIWAN.COM>... Deferred: Host is unreachable
We now begin to see a transcript of the error messages that were reported to
LISTSERV. This message tells us that the hosts SEAS.UCLA.EDU and
KAIWAN.COM, the machines to which mail for the users "bogawa" and "marcon"
should be delivered, could not be contacted, but that further attempts to
deliver the mail would be deferred (scheduled for later ).
Identifyfing an Error Message–Connection Refused
<bb297@SCN.ORG>... Deferred: Connection refused by scn.org.
This is an error similar to the one above. In this case, however, the host
SCN.ORG could be contacted, but was probably too busy to handle more email
traffic at the time. As in the previous case, attempts at redelivery are
scheduled automatically by LISTSERV.
Identifyfing an Error Message–User Unknown
... while talking to sdcc13.ucsd.edu.:
>>> RCPT To:<thudson@SDCC13.UCSD.EDU>
<<< 550 <thudson@SDCC13.UCSD.EDU>... User unknown
550 <thudson@SDCC13.UCSD.EDU>... User unknown
We are now given information about delivery errors to subscribers at the host
sdcc13.ucsd.edu, which finally explains which user was "unknown":
thudson@sdcc13.ucsd.edu, and that links it to the "unrecoverable error" above,
meaning that LISTSERV has decided that it will be pointless to try to
redeliver mail to an address that is reported to not exist anymore. Whenever
you see a three-digit number that begins with "5", as with "550 [...] User
unknown" above, it represents some sort of unrecoverable failure–in this
case, failure to deliver the email to thudson@sdcc13.ucsd.edu.
Identiryfing an Error Message–Connection Timed Out
<users-nausicaa@NNTP-SERVER.CALTECH.EDU>... Deferred: Connection timed out durin
g initial connection with nntp-server.caltech.edu.
This is an interesting variation on the connection problem. A connection that has timed out can be thought of as a phone call that you hang up on after being put on hold for too long, or after listening too long to the phone ringing at the other end. In other words, the MAILER-DAEMON became impatient waiting for the machine nntp-server.caltech.edu to "answer the phone." Note also that this is not a single user, but a gateway[6] to a Usenet newsgroup that is local to Caltech. The clues are: "users-nausicaa", which certainly implies more than one person is a recipient, and a host name containing "NNTP", which is an acronym for "Network News Transfer Protocol" or something similar.
<lanwong@EIS.CALSTATE.EDU>... Deferred: Connection timed out during initial conn
ection with bedstraw.calstate.edu.
The last error message here indicates that another machine was too slow to pick
up the phone in response to the MAILER-DAEMON 's request to deliver mail for
the subscriber "lanwong".
Identiryfing the End of an Error Message
----- Original message follows -----
Finally, the bottom of the error message may contain a copy of the message that was not delivered properly. Some systems that report errors do not give you a copy of the original message. Some systems only provide the header, which may contain valuable clues such as the original "Subject:" line. Your mileage may vary.
glossary
Index
A
C
D
E
F
H
I
L
R
S
T
U
W