Table of Contents Previous Next Index

Section 7 Creating and Maintaining Lists

Section 7 Creating and Maintaining Lists
You can create and maintain lists from any userid listed in the POSTMASTER keyword of LISTSERV’s site configuration file. Note that a LISTSERV maintainer has the authority to GET and PUT any list, filelist, catalog, or archive file on the server (although for any list not set to "Send= Public", the LISTSERV maintainer must be subscribed to the list in order to post to it, and must additionally be a list Editor if the list is set to "Send= Editor...").
This section deals with the "manual" method of creating lists that has been available since LISTSERV first was written. Most users will probably prefer to use the web administration interface to create lists, for which, please see Section 11 Using the Web Administration Interface.
7.1 Basic List Creation
At its simplest, creating a list is a matter of setting certain keywords to desired values in a file (called the "list header file") and storing the file in a place where LISTSERV can find it. The format of a typical list header file is relatively free-form, with only a few basic rules:
1. All header lines (including those inserted for "white space") must begin with the character "*" (ASCII 0x2A).
2. Header lines can be up to 100 characters long (including the initial "*" character). However in practice you will probably want to limit them to no more than 80.
3. All words ending with the character "=" (ASCII 0x3D) are evaluated as keywords.
4. The first non-"white space" line of the header file is evaluated as the descriptive name of the mailing list, and will be displayed as such by the LIST command.
Additionally, for PUT operations, you must add a line of the format
PUT listname.LIST PW=password
to the top of the file before mailing it. This PUT line does not begin with an asterisk. (Note that the filename for the list can be either in the format listname LIST or listname.list. The "." character is not necessary, but the word LIST is always necessary.)
Here is a sample of a basic list header with its PUT command at the top:
Figure 7-1 Sample List Header
The preferred method of creating a new list is as follows:
1. Using a text editor, prepare a "list header", for instance using the sample in figure above. You can also get the header of an existing (L-Soft) LISTSERV list and use it as a sample.
2. The first line of the list header MUST be as follows:
PUT LISTNAME.LIST PW=CCCCCCCC
Replace "LISTNAME" with the name of your list, for example,
PUT MYLIST-L.LIST PW=CCCCCCCC
Then replace "CCCCCCCC" after "PW=" with the value of "CREATEPW=" in your site configuration file. If your CREATEPW is FIATLUX, then your complete PUT line for a list called MYLIST-L would be as follows:
PUT MYLIST-L.LIST PW=FIATLUX
Note: One of the most common errors made by new LISTSERV users is to leave out the ".LIST" part of the PUT command. If you leave this part out, LISTSERV will bounce the header back to you with the comment that it does not have any file by the name "MYLIST-L PW=FIATLUX".
3. Following the PUT line, you insert as many "list header" lines as you need (see the sample). Each of these lines must begin with an asterisk in column 1, for example,
* Notebook= Yes,C:\LISTS\PUBLIC,Monthly,Public
If your mail software indents paragraphs by default, you must turn off paragraph indentation, or an attempt to store the list will be returned to you with a message that there did not appear to be any list header lines.
Each "list header" line contains information needed by LISTSERV to operate your list. Most of this information is provided by you in the form of values for standard keywords. You can use the sample header provided above as an example; a complete list of keywords recognized by LISTSERV along with descriptions of their functions can be found in the List Keyword Reference document.
4. Mail the resulting file to the LISTSERV address.
The "LISTSERV address" is the address formed by "LISTSERV@" + the value you defined in the site configuration file for NODE=. For instance, if you defined NODE=XYZ.COM, the LISTSERV address would be LISTSERV@XYZ.COM.
This mail must be sent as Internet mail from a username defined as a "postmaster" in the LISTSERV configuration. For instance, from a VMS™ system, you would save your list file (say, in a file called 'newlist.create'), and then do:
$ mail
MAIL> send newlist.create
To: in%"listserv@xyz.com"
Subj:
MAIL>
Or, from a unix® system:
$ mail listserv@xyz.com < newlist.create
On a PC, you would use your POP client or other GUI-based mail program. Make sure to cut+paste the file via the Clipboard and not send it as an "attachment" or use drag and drop. "Attachment" mechanisms are often proprietary or PC-specific and cannot be guaranteed to work. Sending plain text pasted from the Clipboard always works.
The above is the preferred method for creating and editing list headers. LISTSERV will respond with a report that either the list has been successfully created or that various problems (fatal and/or non-fatal) have been detected. If only non-fatal problems are detected, the list will be stored anyway (non-fatal problems include no list password having been defined). Any fatal problem detected will abort the storage operation.
Notes: A less-desirable method of creating lists is to copy the list header file into LISTSERV’s main directory and restart LISTSERV. LISTSERV will log a message to the effect that the list is not formatted properly and will then reformat the list. This assumes that the list header has been constructed properly and that there are no errors in the file that will cause LISTSERV to crash or to reject the list file. This method is useful only for creating lists; never attempt to edit a production list file in place and restart the server. The GET and PUT operations are the only supported methods for editing list files. Particularly under unix and Windows, LISTSERV will not always accept the edited list file because some editors will insert control characters or CR-LF combinations that LISTSERV cannot parse. Under VM or VMS, it is always possible that hand-editing the list will introduce some sequence that will cause an operational error. L-Soft suggests that this method be used sparingly, if at all, and does not support it. The first method is always preferable to the second.

BITNET users may also use the LSVPUT utility to store lists on BITNET-connected servers. However, LSVPUT is not documented here as the number of sites with BITNET connectivity is dropping rapidly and fewer and fewer users will be using LSVPUT.
7.2 Architecture-Specific Steps for List Creation
7.2.1 Unix: Creating a List
In order to create a new list, you must:
1. Prepare a "list header", for instance using the sample provided below. You can also get the header of an existing (L-Soft) LISTSERV list and use it as sample.
2. Fill in the PW=CCCCCCCC on the first line with the "CREATEPW" you chose when con­figuring LISTSERV. The PW=XXXXXXX line at the end defines the password you want to assign to your list. This is the password that the list owner will have to supply with sending commands via mail, if you select "Validate= Yes". Alternatively, you can select "Validate= Yes,Confirm" to use the "OK" mechanism, which does not require any password.
3. Mail the resulting file to the LISTSERV address, from a username defined as "post­master" in the LISTSERV configuration. For instance:
mail listserv@xyz.edu < newlist.create
Tip: If you have questions about list creation, keywords, list management and other high-level or system-independent LISTSERV topics, the best place to ask them is the LSTOWN-L list, an open forum of LISTSERV list owners.

For assistance with problems specific to evaluation kits, join the LSTSRV-E list or contact Support@LSOFT.COM for a prompt reply. Please don't forget to tell us which brand and version of unix you are running!
Note: LISTSERV will not create archive directories automatically. You must issue the appropriate "mkdir" command yourself. And when creating such directories, remember that the file permissions must grant the LISTSERV account write access to the directory. Also, directories should be specified as full path names.
Following is a sample list header file that can be modified, then cut and pasted into a mail message to be sent to your LISTSERV server. For help with the various header keywords (not all are shown here), please refer to the LISTSERV List Owners Manual.
--------------------------- Cut here -----------------------------
PUT SAMPLE.LIST PW=CCCCCCCC
*
* Title of sample LISTSERV list
*
* Review= Public Subscription= Open Send= Public
* Notify= Yes Reply-to= List,Respect Validate= No
* Notebook= Yes,/some/directory,Monthly,Public
*
* Owner= someone@somewhere.com
*
* PW= XXXXXXXX
---------------------------- Cut here ----------------------------
(If you use this sample, be sure to change "/some/directory" in the Notebook= keyword specification to a directory that actually exists on your machine. Also be sure to put a valid e-mail address in the Owner= keyword.)
Once you have constructed a list header file, and sent it to your LISTSERV, you need to instruct your mail system to route mail for that new list to the LISTSERV mail interface.
(If you are running Software.Com's Post.Office or Netscape Mail Server as your MTA rather than sendmail, please see the section above entitled "Telling Post.Office and Netscape Mail Server about LISTSERV" for specifics on how to create "program delivery" aliases.)
Telling the MTA how to route mail to LISTSERV involves adding entries to your Sendmail aliases file, much like you did when installing the server itself. For each new list, you'll need to add eight entries to the aliases file. The format of those lines is as follows,
NAME: "|/BBB/lsv_amin /SSS NAME"owner-NAME: "|/BBB/lsv_amin /SSS owner-NAME"
NAME-request: "|/BBB/lsv_amin /SSS NAME-request"
NAME-search-request: "|/BBB/lsv_amin /SSS NAME-search-request"
NAME-server: "|/BBB/lsv_amin /SSS NAME-server"
NAME-signoff-request: "|/BBB/lsv_amin /SSS NAME-signoff-request"
NAME-subscribe-request: "|/BBB/lsv_amin /SSS NAME-subscribe-request"
NAME-unsubscribe-request: "|/BBB/lsv_amin /SSS NAME-unsubscribe-request"
where "NAME" is the name of the mailing list, "/BBB" in the directory where the mail interface was installed (BINDIR in the Makefile), and "/SSS" is the LISTSERV spool directory (LSVSPOOL in the Makefile).
For example, assuming the default values were chosen for BINDIR and LSVSPOOL, and LSVROOT is /home/listserv, the aliases for a new list called "newt" would be,
newt: "|/usr/local/bin/lsv_amin /home/listserv/spool newt"
owner-newt: "|/usr/local/bin/lsv_amin /home/listserv/spool owner-newt"
newt-request: "|/usr/local/bin/lsv_amin /home/listserv/spool newt-request"
newt-search-request: "|/usr/local/bin/lsv_amin /home/listserv/spool newt-search-request"
newt-server: "|/usr/local/bin/lsv_amin home/listserv/spool newt-server"
newt-signoff-request: "|/usr/local/bin/lsv_amin /home/listserv/spool newt-signoff-request"
newt-subscribe-request: "|/usr/local/bin/lsv_amin /home/listserv/spool newt-subscribe-request"
newt-unsubscribe-request: "|/usr/local/bin/lsv_amin /home/listserv/spool newt-unsubscribe-request"
Note: /etc/aliases does not use line continuation characters and will not operate properly unless each alias is on a line by itself. Thus, all of the aliases above should be on a single physical line, and never wrapped.
Once you've added the new aliases to the file, you need to issue the "newaliases" command and send your Sendmail daemon a hangup (HUP) signal before they will take effect.
As with the earlier step where adding mail aliases was necessary, the commands documented above can be automatically invoked by using the "make" command. If you system stores aliases in /etc/aliases, and the newaliases command can be used to compile that file, and if the command "kill -HUP `cat /etc/aliases`" will cause your Sendmail to reload the alias file, then the automated method should work. To add the mail aliases for a new list, and to direct your Sendmail to use those new aliases immediately, enter "make list name=XXX" where "XXX" is the name of the new list.
7.2.2 Unix: Creating the Required Sendmail Aliases
This section is only for use by Unix sites running Sendmail.
Note: The file you need to edit in this step and the commands you need to issue will require root privileges. Also, while the procedure for manually modifying the sendmail aliases file is described below, you can also enter "make list name=listname" (where listname is the name of the list) to have the installation program complete this step automatically. The automated procedure assumes that your sendmail stores aliases in the file /etc/aliases, that the "newaliases" command will rebuild the aliases database, and finally that "kill -HUP `cat /etc/sendmail.pid`" will cause Sendmail to read in the updated alias list (in case running "newaliases" doesn't do that itself).
LISTSERV accepts and responds to several e-mail addresses. Even before you setup mailing lists, mail sent to listserv and owner-listserv should be handed to LISTSERV (see the previous section for details). The link between LISTSERV and your mail system is the lsv_amin program. If you are running Sendmail, the best way to route incoming mail to lsv_amin is by adding entries to your "aliases" file. Refer to the manual pages for sendmail on your system if you are not sure where the alias file is stored. On many systems the file will be called /etc/aliases. If you are not running sendmail, please see the LISTSERV installation guide for unix for further information.
Once you have constructed a list header file, and sent it to your Unix LISTSERV server, you need to instruct your mail system to route mail for that new list to the LISTSERV mail interface. That involves adding entries to your aliases file, much as you did when installing the server itself. For each new list, you'll need to add eight entries to the aliases file. The format of those lines is as follows,
NAME: "|/BBB/lsv_amin /SSS NAME"
owner-NAME: "|/BBB/lsv_amin /SSS owner-NAME"
NAME-request: "|/BBB/lsv_amin /SSS NAME-request"
NAME-search-request: "|/BBB/lsv_amin /SSS NAME-search-request"
NAME-server: "|/BBB/lsv_amin /SSS NAME-server"
NAME-signoff-request: "|/BBB/lsv_amin /SSS NAME-signoff-request"
NAME-subscribe-request: "|/BBB/lsv_amin /SSS NAME-subscribe-request"
NAME-unsubscribe-request: "|/BBB/lsv_amin /SSS NAME-unsubscribe-request"
where "NAME" is the name of the mailing list, "/BBB" in the directory where the mail interface was installed (BINDIR in the Makefile), and "/SSS" is the LISTSERV spool directory (LSVSPOOL in the Makefile). Note that "/SSS" can be either:
An explicit directory definition, for example, /var/spool/listserv ; or
The switch -t, which is equivalent to the value in LSVSPOOL. (Note that the "make list" command makes aliases using -t.)
Note: If you use the precompiled copy of lsv_amin from the distribution kit rather than compiling your own from the source at install time, you cannot use the -t switch because the LSVSPOOL value is not compiled into the precompiled program. For this reason, the default installation uses the "paths" option, which provides the explicit directory definition.
For example, assuming the default values were chosen for BINDIR and LSVSPOOL, the aliases for a new list called "mylist" (using the default explicit path option) would be,
mylist: "|/usr/local/bin/lsv_amin /home/listserv/spool mylist"
owner-mylist: "|/usr/local/bin/lsv_amin /home/listserv/spool owner-mylist"
mylist-request: "|/usr/local/bin/lsv_amin /home/listserv/spool mylist-request"
mylist-search-request: "|/usr/local/bin/lsv_amin /home/listserv/spool
mylist-search-request"
mylist-server: "|/usr/local/bin/lsv_amin /home/listserv/spool mylist-server"
mylist-signoff-request: "|/usr/local/bin/lsv_amin /home/listserv/spool
mylist-signoff-request"
mylist-subscribe-request: "|/usr/local/bin/lsv_amin /home/listserv/spool
mylist-subscribe-request"
mylist-unsubscribe-request: "|/usr/local/bin/lsv_amin /home/listserv/spool
mylist-unsubscribe-request"
Note: The aliases may not wrap to the next line in /etc/aliases.
If you should decide to use the -t definition for the LSVSPOOL parameter, then the aliases would look like this instead:
mylist: "|/usr/local/bin/lsv_amin -t mylist"
and so forth.
Once you've added the new aliases to the file, you need to issue the "newaliases" command and (on some systems) send your Sendmail daemon a hangup (HUP) signal before they will take effect.
7.2.3 OpenVMS: Creating the Required PMDF Aliases
This section is for use only by OpenVMS sites running Innosoft International, Inc.'s PMDF® product, version 4.2 or later.
Note: You will require system level privileges to edit the file in this step.
If PMDF is installed, in addition to the listserv and owner-listserv aliases which you've created in PMDF_ROOT:[TABLE]ALIASES at install time, you will need to add the following eight aliases for each new mailing list you create, where listname is the name of the list:
owner-listname:
listname-request:
listname-search-request:
listname-server:
listname-signoff-request:
listname-subscriber-request:
listname-unsubscribe-request:
Note: You can get around this (and also solve a problem with address probing under VMS with PMDF as documented in Section 13.5.3 OS-Specific Issues with Probing) simply by creating a dedicated domain for LISTSERV (e.g., LISTSERV.XYZ.COM) and adding a rewrite rule to redirect all traffic for that host to the LSV channel. This also simplifies the creation of new lists since it is no longer necessary to make all of the PMDF aliases shown above every time you make a new list.
7.3 Sample Checklist for Creating Lists
1. Check to see that the list name is legal and not duplicated elsewhere (particularly if the list will be publicly and generally accessible). You can use the CataList as one resource for the latter.
2. If Notebook= Yes, then make the appropriate directory and make sure that LIST­SERV has appropriate r/w permissions in it.
3. If Notebook= No but Digest= Yes, then make the appropriate directory and make sure that LISTSERV has appropriate r/w permissions in it.
4. Optionally, add the list to the quota file (ISP scope licenses only).
5. VM: Optionally, make a listname.FILELIST for this list (see Section 8 File and Notebook Archives for details). Non-VM: Optionally, make an entry in SITE.CATA­LOG for a sub-catalog belonging to this list (see Section 8 File and Notebook Archives for details) and create a dummy listname.CATALOG in the specified directory.
6. Non-VM: Optionally, assuming that Notebook= Yes and you have installed the web archive interface as described in Section 5 Configuring Your LISTSERV Site, create the listname directory under the base 'archives' directory. If you do this now, you won't have to GET/PUT the list header later to initialize things.
7. Create and store the list header with the list owner and you as the only subscribers.
8. Architecture-specific steps:
a. Unix, running Sendmail: Create the required Sendmail aliases for the list, either by hand or by using 'make list name=listname'. Note that this is a required step for unix servers; if you don't make the Sendmail aliases, the list won't work. See Section 7.2.2 Unix: Creating the Required Sendmail Aliases for details.
b. OpenVMS, running PMDF®: Create the required PMDF aliases for the list in PMDF_ROOT:[TABLE]ALIASES. Note that this is a required step for VMS servers running PMDF; if you don't make the aliases, the list won't work. See Section 7.2.3 OpenVMS: Creating the Required PMDF Aliases for details (and an alternative work around).
9. Send a boilerplate "your list has been created" message to the list as the final test that the list works--if it doesn't, go back and find out why, then return here. See Appendix B Sample Boilerplate Files for a sample boilerplate message for this step, or use your own.
10. Delete yourself from the list (assuming you don't want to be subscribed).
At this point the list should be ready for use.
7.4 Naming Conventions
When naming a list, there are a few conventions and restrictions that you should keep in mind.
7.4.1 The "-L" Convention
The "-L" convention isn't required, but it can help people to realize that the mail is coming from a mailing list rather than from a real person. The people we are referring to here are people who run Internet mail systems, who may see a great deal of mail coming from a single host and begin to wonder why. If it comes from a userid that ends in a "-L", they will be more likely to recognize it as list mail.
7.4.2 Reserved Names
You may not create lists whose names match the following wildcards:
owner-*
*-request
*-search-request
*-server
*-signoff-request
*-subscribe-request
*-unsubscribe-request
For instance, lists cannot be made with names like "owner-loyalty", "linux-server", and "donation-request". While it is physically possible to create a list with a name that matches one of the above wildcards, attempts to send mail to the list (for example, a list called "linux-server") will result in an error, logged as follows in the LISTSERV log:
4 Dec 2001 11:47:02 -> Invalid list (LINUX), generating bounce.
These "pseudo-mailboxes" have a special meaning to LISTSERV, which has internal rules that govern how mail sent to these addresses is handled. See Section 17.3 Communicating with List Owners for more information on what happens to mail sent to these special addresses.
7.4.3 Reserved Characters
In general, you want to avoid "special" characters such as the ones above the number keys on your keyboard. For example, don't use:
sometimes reserved by non-unix systems (specifically on NT, it has a special meaning to the shell). However, please note that use of this character in the name of a list or in a sendmail alias for a list will cause LISTSERV on unix to choke. Note that it is possible under unix to create a list with a "&" character in the name quite easily, and it is also possible to create a sendmail alias with a "&" character in the alias. That does not mean it will work.
should be avoided because recent versions of sendmail deliver mail addressed to "user+whatever@somedomain" to "user@somedomain." Whether or not this is an intelligent thing to do on sendmail's part is left as an exercise for the user, but it can affect mail being sent to a list with a "+" character in the listname.
Although on some systems it is physically possible to create lists with a dot character in the name, LISTSERV will not accept this nomenclature. The only place a dot can or should be used is before the word "LIST" in the PUT command; for example, PUT MYLIST-L.LIST is equivalent to PUT MYLIST-L LIST.
It is best if you avoid the use of special characters altogether and stick exclusively to the letters A-Z, numbers 0-9, and the underscore and hyphen characters when naming lists. Note that the "_" (underscore) character may cause problems with some non-compliant receiving systems. Also note that the space character (ASCII 0x20) is illegal in a list name, and L-Soft recommends that, although apostrophes (aka "single-quotes", ASCII 0x27) are valid in an RFC822 username, they should not be used in list names since some mail programs may not accept them.
If you have any question about the validity of a particular name, you can of course refer to RFC822 or the updated RFC2822 for the Internet standards for e-mail addressing.
7.4.4 Maximum Length of the List Name
The length of the list name (that is, the name of the list file and thus the "official" name of the list) is restricted as follows:
VM: 8 characters
Non-VM: unlimited (but see below)
If you need a longer list name for a list running on a VM server, then you should use the List-ID= keyword (see the List Keyword Reference document).
Note: L-Soft recommends using names of 32 characters or less whenever possible as they provide for correct alignment of the results returned by certain commands. Very long (for example, program-generated) list names are likely to conflict with mail system limits and L-Soft recommends other solutions to the problem of dynamically generated lists. As a rule, list names in excess of 70 characters are likely to result in mail delivery problems.
7.4.5 Making the List Name User-Friendly
While you can (within limits) name a LISTSERV mailing list just about anything you want, you will probably want to follow a couple of simple guidelines:
1. Keep the name simple.
2. Keep the name as short as possible without causing confusion.
No doubt you could name a list MY-LIST-FOR-MATH-STUDIES, but who wants to type that? Conversely, MLFMS-L wouldn't mean much to Joe Random User. Somewhere in the middle is a reasonable compromise, for example, MATH-STUDIES (or even just MATH-S).
7.5 List Header Keywords
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. We will discuss these keywords in detail in subsequent sections, and a complete alphabetical listing of list header keywords, including default settings and all options available, is provided in the List Keyword Reference document.
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.
7.6 Retrieving and Editing a List
Warning: Never attempt to hand-edit a production list file in place and restart the server. The GET and PUT operations are the only supported methods. Particularly under unix and Windows, LISTSERV will not always accept the hand-edited list file because some editors will insert control characters or CR-LF combinations that LISTSERV cannot parse. Under VM or VMS, it is always possible that hand-editing the list will introduce some sequence that will cause an operational error. L-Soft suggests that this method be used sparingly, if at all, and does not support it.
Once the list has been created, 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:
Issue the UNLOCK listname command (if you decide no changes are needed)
Send the list back to the server with the PUT command.
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.
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: The "(" switch character is used only once.
Caution: It is not advisable to use the (NOLOCK switch in at least two cases:

Don't use the (NOLOCK switch if you are not the sole owner of the list. This prevents conflicting GETs and PUTs by different list owners. For instance, Owner(A) GETs the list without locking it. Owner(B) then also GETs the list. The owners make differing changes to the list header. Owner(B) PUTs his changes back first. Owner(A) then PUTs his changes back, erasing every change Owner(B) made. If Owner(A) had not used the (NOLOCK switch, Owner(B) would not have been able to GET a copy of the list until Owner(A) either unlocked the list or PUT his copy back. (Owner(B) could also unlock the list himself, but it would be advisable to ask Owner(A) if he was finished editing the list header before doing so.)

Don't use the (NOLOCK switch if you get the entire list rather than just the header. You will erase all subscriptions for users who subscribed between the time you GET the list and PUT the list back. It is easier to deal with questions as to why they got the "listname has been locked since time by list-owner" message than to explain why they got a subscription confirmation and now aren't getting list mail.
Note: A PUT command containing new subscribers added "on the fly" will result in only the header of the list being updated and a warning being generated that says if you really wanted to PUT the entire list, subscribers and all, that you should use the PUTALL command.
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:
DELETE XYZ-L *ADMD=ABC*PRMD=DEF*@X400.SOMEHOST.COM
You can also enclose the address in double quotes:
DELETE XYZ-L "/ADMD=ABC/PRMD=DEF/...../@X400.SOMEHOST.COM"
7.7 Adding a List Password
This section is obsolete since 1.8c, but it is retained for compatibility with those sites still running 1.8b or earlier, or for sites running peered lists (all peers must have the same password).
When creating the list, the LISTSERV maintainer should assign a password for the list. However, note that in 1.8c and later, if the LISTSERV maintainer does not assign a password at the time of the list's creation, LISTSERV will generate a random password for the list. This random password can be changed later, but until and unless it is changed, administrators must provide their personal LISTSERV password (created with the "PW ADD password" command) when updating the list.
Compatibility Note: When upgrading to LISTSERV 1.8d and later from 1.8b or earlier, lists without passwords will not be altered during the upgrade. However, the first PUT operation for such lists after the upgrade will cause LISTSERV to add the random password to the list. List owners should be encouraged prior to the upgrade to create personal passwords for themselves with the "PW ADD password" command (if they have not done so already) and plan to use those passwords after the upgrade.
The list owner can change this password when storing the list (with the "PW=" keyword), but the first time the list owner stores the list, the original password or the list owner's personal password must be used. Note that not all LISTSERV maintainers assign list passwords by default; the new random password feature addresses that. However, for pre-1.8c servers it is highly recommended that one be assigned by adding a "PW=" header line as follows:
* PW=MYPASSWD
Replace "MYPASSWD" with the word chosen. Note that there should not be a space between "PW=" and the password. The list password is never changed unless specified explicitly in the list header when it is stored on the server. For additional security, the list password will not appear in the list header on subsequent GETs; to all intents and purposes it is invisible once it is assigned.
L-Soft’s position on list passwords is that they have become obsolete with version 1.8c (they were actually obsolete as far back as 1987) except for the single exception of peered lists, and that personal passwords should be used instead to validate commands (such as the PUT command).
7.8 Storing a Modified List on the Host Machine
(If you are creating a list, see Section 7.1 Basic List Creation. These instructions are for storing a list once it already exists on the server, for instance, if changes have been made to the list header after a GET operation.)
When you are ready to store your list 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. 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 that could actually affect the correct operation of the list, the list will not be stored and the old version will be retained. (For instance, creating a list with no list password defined in the header will generate a "soft" error under 1.8b and before, and the list will be stored. On the other hand, setting a list to "Send= Editor" and not defining an editor with "Editor=" is considered a "hard" error, and you will have to fix the error before LISTSERV will accept the list for storage.)
Caution: If you are using a mailer such as Eudora, Pegasus, 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.
If your mail software inserts page formatting (margins) or quoting characters (such as ">") in forwarded mail, you need to either turn these features off or you must cut and paste the header into a new mail message. The PUT line MUST be on the first line of the message, and all header lines including the PUT MUST start in column 1. Specific problems have been noted with cc:Mail (where top and left margins get inserted) and with certain POP clients including Eudora and Microsoft Exchange (where forwarded mail is quoted with ">" by default).
Also, be sure to turn off your signature file (if you use one) before sending a PUT command to LISTSERV. If you don't, LISTSERV will attempt to parse the data in your signature file as RFC822 addresses to be added to the list, and you will receive either an error to the effect that the file includes invalid RFC822 addresses and it has therefore not been stored, or a warning that your PUT operation contains new subscriber information and only the list header has been stored (see Section 7.6 Retrieving and Editing a List for information on the PUTALL command).
7.9 Fixing Mistakes
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 PUTALL listname LIST PW=XXXXXXXX command to the top of the file and store it.
It is also possible for the LISTSERV maintainer to restore the list by deleting or moving the listname.LIST file from LISTSERV's A directory and renaming the listname.OLDLIST file to listname.LIST. Naturally this method requires that the LISTSERV maintainer in question have appropriate access to LISTSERV's files and directories or be able to log in as the 'listserv' user.
7.10 Sample List Header File
A basic list header file for a list to be created might look like this (CREATEPW must be replaced with the appropriate password):
Figure 7-2 Sample List Header File for a List Called MYLIST
A list owner might take the created list and modify it as shown below. Note that the PUT command has been modified to include the password you've assigned with the PW ADD command.
Figure 7-3 The Edited List Header File Ready to be Sent Back to the Server
7.11 Deleting a List
For security reasons, LISTSERV does not have an explicit command for deleting lists, although lists can be deleted through the web administration interface (see Section 11 Using the Web Administration Interface).
For those who prefer to delete lists the old, manual way, the LISTSERV administrator simply deletes the list file from the system command prompt with the appropriate file system command (CMS ERASE for VM, DEL for VMS, ERASE for Windows, rm for Unix). A suggested procedure for deleting an established list (one with archives and so forth) follows:
1. Back up any files you wish to keep, such as notebook archives
2. For a digested list, you may want to send a QUIET SET listname NODIGEST FOR *@* command. This will cause LISTSERV to send out its accumulated digest to those who were set to DIGEST mode. If the list hasn't been active or if it's not “digestified”, you don't need to take this step.
3. Delete the listname.LIST file with the appropriate file system command.
4. If the list has web archives, then delete the /archives/listname.html file and the /archives/listname/listname.ind* files. You can also remove/delete the /archives/listname directory at this time.
5. Although it is not absolutely necessary, stopping and restarting LISTSERV will com­plete the procedure. If you do not stop and restart LISTSERV, LISTSERV will fairly quickly notice that the list is gone, and will take care of this on its own.
7.12 Adding HTML to a List Header for the CataList
L-Soft's CataList service allows users to search the global list of LISTSERV lists via the World Wide Web. Adding an HTML description to a list is easy, and can do a lot to enhance the appearance of a list in the database. All the list owner or LISTSERV maintainer has to do is update the list header and add the text of your choice. Here is an example:
L-Soft's CataList service allows users to search the global list of LISTSERV lists via the World Wide Web. Adding an HTML description to a list is easy, and can do a lot to enhance the appearance of a list in the database. All the list owner or LISTSERV maintainer has to do is update the list header and add the text of your choice. Here is an example:
* The coffee lovers' list
*
* Review= Public Subscription= Open Send= Public
* Notify= Yes Reply-to= List,Respect
* Notebook= Yes,L,Monthly,Public
*
* Owner= claudia@espresso.xyz.it (Claudia Serafino)
*
* <HTML>
* COFFEE-LOVERS is an open list for, well, coffee lovers! Our
* motto is: <cite>"Instant just say no!"</cite>
* That's pretty much our whole charter, although there are a
* few other <a href="http://www.coffee.org/charter.html">
* rules</a> that you may want to read before joining. For
* instance, we don't allow flame wars about decaf: if you like it,
* well, it's your body after all.
*
* <p>The list is maintained by
* <a href="http://www.coffee.org/claudia.html">Claudia
* Serafino</a> (that's me!) and you will find all sorts of
* useful info about coffee on my home page.
* </HTML>
*
In other words, you just insert your HTML text in the list header and bracket it with <HTML> and </HTML> tags (these tags tell the web interface where the HTML text begins and ends – they are not actually sent to the web browser). There are three simple rules that you must follow when inserting your HTML data:
1. The <HTML> and </HTML> tags must appear on a separate line, as shown in the example above. You cannot have anything else on that line and, in particular, you cannot mix keyword definitions with HTML data.
2. The HTML data you are providing is embedded into the document shown by the web interface when users query your list. Because you are given some space between two horizontal rules on an existing page, rather than a whole new page. you should not include tags that affect the whole document, like for instance <TITLE>.
3. While this procedure is compatible with all versions of LISTSERV, there are a few restrictions on the placement of equal signs within your HTML text with versions that do not have any specific support for the <HTML> and </HTML> markers. In practice, you can ignore this rule unless you get an error message while storing your list.
When reformatting your list header description for HTML, bear in mind that the text will not always be viewed using a web browser. It is best to keep the formatting as clear as possible and minimize the usage of HTML tags, since there are still many people without WWW access. For instance, do not hesitate to use white space between paragraphs for clarity.
7.12.1 Update Latency
Barring network outages, a list header update takes a maximum of 24h to be reflected in the distributed LISTS database. Database updates are usually scheduled to be broadcast at night, so the changes take place overnight. Once the LISTS database has been updated, it can take a maximum of 24h for the frozen copy of the database used by the web interface to be updated. In most cases, both the LISTS database and its frozen copy on the web server will be updated overnight. However, if the site hosting your lists is several time zones west of the site hosting the web server, and if that server only updates itself once a day, you may have to wait two days for your update to be reflected.
7.12.2 Inserting a Pointer to Another List
Sometimes it may be useful to link a number of related lists together so that the viewer can quickly examine all the lists without having to go back to the search screen and retyping the names you are providing. You can do this using the special HTML sequence:
<!--#listref listname@hostname-->
This sequence is internally translated to an <a> tag with a URL that will bring up information about the list you indicated. You must then provide a suitable caption and a closing </a> tag. Example:
Don't forget to take a look at
<!--#listref COFFEE-L@COFFEE.ORG-->
the coffee list!</a>
7.12.3 Restrictions on the Placement of Equal Signs
While all versions of LISTSERV are supported, servers which have no specific support for the <HTML> and </HTML> tags will process your HTML data as an ordinary list header line and attempt to determine whether it contains a list header keyword or descriptive text. The exact algorithms vary from one version to another, but in general the parser looks for a single word followed by an equal sign. With HTML text, it is possible (if unlikely) to generate such patterns. Here is an example:
*
* Sample list with problem pattern
*
* <HTML>
* For more information on the list, just check <a
* href="http://www.xyz.edu/mypage.html">my home page.</a>
* </HTML>
*
In that case, you can just reorder the HTML data so that the equal sign does not appear in this position. Alternatively, if the equal sign was meant to be actually displayed as an equal sign (as opposed to being part of some HTML tag), you can use the HTML escape sequence &#61; instead.
7.13 Setting Up Lists for Specific Purposes
You can create certain types of lists from standard templates via the web administration interface. See Section 11 Using the Web Administration Interface for information on how to access the web administration interface.
7.13.1 Public Discussion Lists
Public discussion lists have always been the "classic" type of LISTSERV mailing list. Such lists are available to discuss just about everything imaginable. In the last few years it has become desirable to secure mailing lists against random spamming and mail bombing, but no discussion of different types of lists would really be complete without talking about this kind of list.
Typically, a public discussion list is wide-open (although some things, like the ability to review the subscribership, may be restricted). Anyone can subscribe (with a confirmation to verify the mailing path), anyone can post, anyone can read the messages in the archives, and security is set fairly low. Very large lists (hundreds or even thousands of users with hundreds of postings every week) may likely be set up this way as it is a "low-maintenance" way to run a list (and most spams tend to be caught by LISTSERV's anti-spamming filters anyway). For instance, you might have
* My public discussion list (MYLIST-L)
* Subscription= Open,Confirm
* Ack= Yes
* Confidential= No
* Validate= No
* Reply-to= List,Respect
* Review= Owners Send= Public Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\MYLIST-L,Weekly,Public
For more security, you might want to code
* Validate= Yes,Confirm
and if you want to cut down on the amount of "me-too"ism on the list, you could set
* Reply-to= Sender,Respect
to force the default Reply-To: header to point back to the original poster instead of to the list. Note that the ",Respect" option means that if a user sends mail to the list that contains a "Reply-To:" header pointing back to the list (unlikely that this may be), LISTSERV will "respect" that header and use it. If you absolutely do not want this to be possible, you should code the following instead:
* Reply-to= Sender,Ignore
Caution: "Reply-To:" are not universally honored!
Note: There is one major caveat with regard to the use of the Reply-To= list header keyword. Setting this parameter guarantees only one thing -- that LISTSERV will generate an appropriate RFC822 Reply-To: header in the mail it distributes to subscribers. THERE IS UNFORTUNATELY NO GUARANTEE THAT THE MAIL TRANSFER AGENT (MTA) OR MAIL CLIENT ON THE RECEIVING END WILL HONOR THE Reply-To: HEADER. This is because some mail clients, out-of-office robots, and Internet MTAs either simply do not recognize the existence of Reply-To: or do not implement it properly. Specifically RFC2076 "Common Internet Message Headers" reports that the use of Reply-To: is "controversial", that is, "The meaning and usage of this header is controversial, meaning that different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations." (RFC2076, page 4). While L-Soft recognizes that it is sometimes important to provide an explicit Reply-To: header to indicate a response path, L-Soft cannot and will not be held responsible for problems arising from the inability of a remote server to properly process Reply-To: headers.
7.13.2 Private Discussion Lists
Private discussion lists are similar to public discussion lists, but with varying restrictions on who may subscribe, who may post and who may view the archives. Such lists are relatively safe from random spamming since typically only a subscriber can post (but note that a spammer spoofing mail from a subscriber's address will probably be successful unless first caught by the anti-spamming filters). For instance:
* My private discussion list (PRIVATE-L)
* Subscription= By_Owner
* Ack= Yes
* Confidential= Service
* Validate= No
* Reply-to= List,Respect
* Review= Owners
* Send= Private
* Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\PRIVATE-L,Weekly,Public
is a low-security private discussion list where subscriptions requests are passed on to the list owner(s) for review, only subscribers may post, and only subscribers may view the list archives. Here again, for more security you might want to set "Validate= Yes,Confirm", and of course you can have replies go to the original poster rather than to the list with "Reply-To= Sender,Respect" (with the same caveats as noted above in Section 7.13.1 Public Discussion Lists).
7.13.3 Edited Lists
An edited list is one that requires a human editor to approve messages sent to the list. Some list software and most USENET newsgroups refer to this as "moderation", but to avoid confusion between two types of moderated LISTSERV lists, the present example will be referred to as an "edited" list.
Examples of edited lists range from refereed electronic journals to lists where the list owner simply wishes to exercise control over which postings are allowed to go to the list.
To set up a basic edited list, simply add
* Send= Editor
* Editor= someuser@somehost.com
to the basic list header. Note that the primary Editor= specification (that is, the first editor defined by an Editor= keyword for the list) must be a human person who will be able to act on postings sent to him or her for approval. You may not use an access-level specification (such as "Owner") when defining the primary editor for a list.
Please note that L-Soft recommends setting "Send= Editor,Confirm" so as to add a level of security against malicious users forging mail from an "Editor=" address to get around your moderation settings, or against badly-configured "vacation" programs that simply reflect the message back to the list in a manner that makes it appear that the mail is coming from the editor’s address. The "Confirm" option causes LISTSERV to request an "OK" confirmation from an editor when it receives mail claiming to be from that editor.
You can define multiple editors, but only the first editor will receive postings for approval. Anyone defined as an editor may post directly to the list without further intervention. Multiple editors can be defined on separate Editor= lines or can be grouped several on a line, for example,
* Editor= someuser@somehost.com,anotheruser@anotherhost.com
* Editor= yetanotheruser@his.host.com
To approve postings with the above configuration, the editor simply forwards (or "resends", or "bounces"--the terminology is unclear between various mail programs) the posting back to the list address after making any desired changes to the content. This should be done with a mail program that supports "Resent-" fields. if "Resent-" fields are not found by LISTSERV in the headers of the approved posting, then the posting will appear as coming from the editor's address rather than from the original poster. If your mail program does not support "Resent-" fields, you should use the "Send= Editor,Hold" option and approve messages with the "OK" mechanism described below.
If you do not need to physically edit the content of your users' posts (for instance, to remove anything considered "off-topic" or to remove included mail headers and so forth), you can code
* Send= Editor,Hold
The "Hold" parameter causes LISTSERV to send you a copy of the posting along with a "command confirmation request". To approve the posting, you simply reply to the confirmation request with "ok".
For security purposes, you can code
* Send= Editor,Confirm
which will cause LISTSERV to request a command confirmation ("ok") from the editor sending the approved posting back to the list. This makes it impossible for an outside user to "spoof" mail from an Editor address.
Naturally, you can also code
* Send= Editor,Hold,Confirm
Finally, please note that the NOPOST subscriber option will take precedence over Editor=, if set for someone defined as an editor. This means that if you have "Default-Options= NOPOST" for your list and you add an editor as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor can successfully approve postings but is then told that he or she cannot post to the list.
7.13.4 Moderated Lists
Note: The Moderator= keyword is disabled in LISTSERV Lite.
A moderated list is similar to an edited list, but for LISTSERV's purposes it refers to a list that uses the Moderator= list header keyword to "load-share" posting approvals among several editors. It is set up similarly to an edited list, as follows:
* Send= Editor,Confirm
* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= yetanotheruser@his.host.com
This list will "load-share" the approval process between the three moderators, who will each receive one-third of the postings for approval. Note that a primary editor should still be defined.
If it is desired to have one editor handle more than a single share of the approvals, you simply define the editor more than once in Moderator=. For instance,
* Send= Editor,Confirm
* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= someuser@somehost.com,yetanotheruser@his.host.com
would cause every other posting to be forwarded to someuser@somehost.com for approval.
If the parameter "All" is coded at the beginning of the list of moderators, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be
* Moderator= All,kent@net.police.net,joe@bar.edu
Please note that something like
* Moderator= kent@net.police.net,All,joe@bar.edu,alex@reges.com
is not valid. "All" must appear at the beginning of the list of moderators.
Assuming "Send= Editor, Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that the message cannot be found and has probably expired (since the cookie for that message will be gone).
If the message body is edited in any way before it is approved (i.e., by forwarding an edited copy back to the list), and more than one moderator is involved, duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator. Note carefully that this means if the "All" parameter is used in "Moderator=" with "Send= Editor" (that is, without the "Hold" parameter), again a separate synchronization method will have to be used to prevent duplicates, as two moderators are unlikely to make exactly the same edits to the message. Even if LISTSERV were able to identify the two submissions as being the same message, it would not know which to choose over the other.
The "Hold" and "Confirm" options for "Send=" can also be used with these examples, if desired. L-Soft recommends that "Confirm" be used by default.
Note: The NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
Note for moderation "OK" requests and MIME attachment display: In versions previous up to LISTSERV 1.8e, an OK confirmation request for a message coming to a moderated list displayed the message to be approved in its "raw" format; that is, there was no attempt made to display/decode MIME attachments that might be present in the message to be approved. LISTSERV now addresses the problem by including a copy of the first text/plain part (if one exists in the message) for the purpose of quick screening. The following restrictions apply:

1.) This is only done for MIME messages (even simple single-part ones, but they must have MIME headers).

2.) The text part in question is sent pretty much 'as is', that is, as an extra text/plain part in the message, with all the options and encoding and what not supplied in the original message. The reason is quite simply that it would be a lot of work and, in some extreme cases (incompatible code page, etc.), completely impossible, to embed it into the first text/plain part with the LISTSERV message. The drawback is that some mail agents might conceivably only show the first part until you take some kind of clicking action.

It is important to understand that only the first text/plain part is extracted in this fashion. The goal was to make it easier to approve or reject simple text messages, not to build a factory around a simple problem. The ENTIRE message is available at an extra click.

Where security is a concern, it is important to review the ENTIRE original message and not just the plain text part. There could be an obscene GIF or another text part or a text/html part not matching the contents of the text/plain part or whatever. This is why, again, you are given the ENTIRE original message.

List owners using certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" in the Send= list header keyword; for instance,

* Send= Editor,Hold,NoMIME
7.13.5 Semi-Moderated Lists
"Semi-moderation" was developed some years ago after a great debate on whether or not an "urgent" message should be allowed to be posted to an edited list without having to go through the approval process. Although this option is still available, it can be misused by anyone who knows about it, and is therefore not generally recommended for use. However, should this feature be deemed necessary, it is activated by setting
* Send= Editor,Semi-Moderated
Then, any subsriber needing to send an "urgent" message to the list simply types "Urgent:" in the subject line of their mail, followed by the subject of the message. Messages that do not have the "Urgent:" subject are forwarded to the list editor for approval as usual.
In order to minimize the chance of spam slipping through without editorial approval, messages with an "Urgent:" subject originating from non-subscribers will be rejected.
7.13.6 Self-Moderated Lists
So-called "self-moderated" lists were invented in 1993 or 1994 when the current epidemic of spamming was beginning to get cranked up and before the "spam filter" was developed by L-Soft. With the spam filter in operation, self-moderation is not as much of an issue anymore, but some lists still run this way.
Self-moderation takes advantage of the ability to make an access-level a secondary list editor, and is implemented as follows:
* Send= Editor,Confirm
* Editor= someone@someplace.com,(listname)
(The "Hold" and "Confirm" parameters for "Send=" may naturally be used if required. L-Soft recommends that "Confirm" be used by default.)
Usually, one of the list owners is the primary editor (here "someone@someplace.com") and the specification of (listname) makes all of the subscribers of the listname list editors, and thus eligible to send messages directly to the list without editor intervention. Postings from non-subscribers (e.g., spammers) are deflected to the primary owner for his or her disposition.
There is one caveat to this kind of list. If a user subscribes to the list, and later his mail address changes (for instance, the hostname changes slightly but mail sent to the old address is automatically forwarded to the new address), any postings from him to the list from the new address will be forwarded to the editor because the new address is not subscribed to the list. Thus there is a certain amount of list-owner overhead on this kind of list in keeping track of users whose addresses have changed and modifying the subscriber list to reflect those changes. The "CHANGE" command can be of help in this regard.
7.13.7 Private Edited/Moderated Lists
This type of edited or moderated list allows subscribed users to post with editor or moderator intervention, but rejects postings received from non-subscribers with a note to the poster stating that they are not allowed to post.
Using the same header you would create for an private discussion list (see Section 7.13.2 Private Discussion Lists), simply add the following line to the header:
* Default-Options= REVIEW
You should also add Editor= and (optionally) Moderator= keyword settings to the list. At least one editor must be defined to handle the message approval chores, otherwise the first listed list owner will receive the messages for approval.
The following rules apply:
For brand-new lists or existing lists which have no subscribers, all subscribers added to the list after this option is set will be set to REVIEW, and nothing further needs to be done.
For existing lists with existing subscribers, you will need to set the existing subscribers to the REVIEW option manually, that is, with the command
QUIET SET listname REVIEW FOR *@*
New subscribers who sign up or are added after you add the Default-0ptions= keyword setting will automatically be set to the REVIEW option.
Finally, the list editor will also be set to REVIEW if he is subscribed to the list under this scenario. This can be important if the list editor wants to approve even his own postings (for instance, to help avoid someone spoofing mail to the list from his address). If the list editor does not require this "suspenders and belt" level of security, he can simply set himself to NOREVIEW.
7.13.8 Auto-Responders
Since LISTSERV Lite does not support list-level mail templates, this functionality is effectively not available in LISTSERV Lite.
An "auto-responder" is a type of list that simply responds with a set message whenever it receives mail from someone. This kind of list can be useful for things like service messages or upgrade availability, or even to simply send back a standardized message to a user who has sent mail to a "support" address.
A simple auto-responder header might look like this:
* Auto-responder for service messages
* Owner= someone@someplace.com
* Send= Public Notebook= No Subscription= Closed
In other words, it can be very simple, since you probably don't want notebook archives for this kind of auto-responder, you don't want people to subscribe to the list as it isn't really a mailing list, and so forth. To make the auto-response message for this list, you'd then create a listname.MAILTPL file (see Section 10 Interpreting and Managing Log Files for details) that includes a POSTACK1 template, like the following:
>>> POSTACK1 Service Message for &MYNAMES
&MYNAMES will be down Sunday from 0200 EST until 0500 EST for backups and upgrades. For more information contact LSTMAINT@&MYHOST.
This particular template would inform the user that LISTSERV would be down (&MYNAMES translates to LISTSERV@NODE where NODE is the value of NODE= in the system configuration file) and to send questions to LSTMAINT@ the local host. In order to change the service message, it would be necessary only to change the POSTACK1 template.
7.13.9 Announce-Only Lists
An "announce-only" list would be used to distribute a newsletter or other timely information where responses to the list are neither expected nor desired. A typical announce-only list header might look like this:
* The FOO Product Announcment List
* Owner= foo@myhost.com
* Owner= Quiet:
* Owner= anotheruser@myhost.com
* Owner= yetanotheruser@myhost.com
* Editor= foo@myhost.com
* Editor= anotheruser@myhost.com
* Editor= yetanotheruser@myhost.com
* Notebook= No
* Errors-To= Owner
* Subscription= Open,Confirm
* Validate= No
* Review= Owners
* Send= Editor,Confirm
* Reply-To= foo@myhost.com,Ignore
* Sender= None
This list is set up so that generally any response to postings will go back to foo@myhost.com, which might be a special account set up specifically to handle such things, or a mail alias pointing to another account. The newsletter can be posted by foo, or anotheruser, or yetanotheruser, all of whom are editors, but the likelihood is that it would be posted from the foo userid so that the From: line would read "From: foo@myhost.com".
L-Soft strongly recommends that all announce-only lists use the "Send= Editor,Confirm" or "Send=Editor,Hold,Confirm" setting. The ",Confirm" parameter tells LISTSERV to require a confirmation for any posting sent by a user defined as an Editor=. This is important for two reasons:
Security – This setting tells LISTSERV to request confirmation from the Editor for all postings it receives that purport to be from that Editor. This prevents hackers from forging mail under an Editor's address, because any forgeries will require that the Editor in question approve them before they go to the list.
Loop Protection – Certain broken mailers can and will bounce mail back to your list in a "reflected" manner, that is, the bounce will appear to be a legitimate posting from the Editor to the list instead of looking like an error. This is different from a forgery attempt because (it is assumed) the mailer on the other end is not doing this with malicious intent. Requiring the editor confirmation will stop these potential loop-generating messages from getting through to the list.
To stop a posting from going to the list under this scenario, simply don't OK it and delete the confirmation request message.
7.13.10 Restricted Subscription Lists with Automatically-Generated Questionnaire
Since LISTSERV Lite does not support list-level mail templates, this functionality is effectively not available in LISTSERV Lite.
Sometimes it is desired to send out a little questionnaire before approving a subscription to a list with a very narrowly-defined topic or to lists created for members of specific organizations. By setting "Subscription= By_Owner", you can of course force all potential subscriptions to require list owner approval. In the "old days", if you wanted more information before you approved the subscription request, you had to manually send a questionnaire out to the user and wait for him or her to return it to you.
By setting "Subscription= By_Owner" and adding two simple template forms to your listname.MAILTPL (as explained in Section 9 Creating and Editing Mail and Web Templates), you can now have LISTSERV send your questionnaire out automatically, as soon as the subscription request is received.
The first template form you need to add to listname.MAILTPL is called SUB_OWNER, and in this case it would typically look like this:
>>> SUB_OWNER &LISTNAME: &WHOM requested to join
.TO &WHOM
A copy of the &LISTNAME membership questionnaire has been sent to you. Please read it carefully and follow the instructions to complete it and return it to the list owners.
The .TO &WHOM directive is required so that the message is sent to the subscriber rather than to the list owner. If you want the non-quiet list owners to receive a copy of this message (which is admittedly unlikely), you can simply add CC: &OWNERS to the end of the .TO line, for example,
.TO &WHOM CC: &OWNERS
Or, if you want to cc: a specific user such as joe@unix1.example.com, use
.TO &WHOM CC: joe@unix1.example.com
Note: You cannot format the SUB_OWNER template; it all comes out as one long paragraph without formatting no matter what you do, because it is a "linear" template. But you should modify it from the default to let people know that they will receive a questionnaire to be filled out and returned.
The second template form you need to add to listname.MAILTPL is called ADDREQ1 and it can be as simple or as detailed as you want. All of the available template formatting commands can be used in ADDREQ1. For instance:
>>> ADDREQ1 &LISTNAME Membership Survey
.RE OWNERS
.TO &WHOM
.CE &LISTNAME Membership Survey
NOTE: Please make sure when you send this back that it goes to the address &LISTNAME-Request@&MYHOST. Thanks.
This is a standard questionnaire required for all prospectivesubscrib­ers to &LISTNAME. Blah blah blah...
In this case, you want the message to go to the subscriber, with a Reply-To: header pointing back to the (non-quiet) list owners. The first line indicating the return address is added for those users with mail clients that don't recognize Reply-To: headers.
You can also put a pre-formatted ADD job into the questionnaire to simplify your job when the questionnaire comes back. For instance,
.fo off
----------------------------------------------------------------
For List Owner's Use Only -- Be sure to include with your Reply
-----------------------------------------------------------
// JOB
ADD &LISTNAME &WHOM &USERNAME
// EOJ
-----------------------------------------------------------
.fo on
For more detailed information on mail templates, see Section 9 Creating and Editing Mail and Web Templates.
7.13.11 Peered Lists
This functionality is not available in LISTSERV Lite.
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 two 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.
Although there is no problem about peering to another L-Soft LISTSERV list, linking to a non-L-Soft mailing list manager is not supported and can and will cause serious problems (including mailing loops) for which L-Soft international, Inc. could not be held responsible.
7.13.11.1 Linking Two or More LISTSERV Mailing Lists
Please observe the following points:
All lists should have a Peers= keyword setting that includes all of the other peers in the group as its arguments. For example, consider a peer group containing ListA, ListB, and ListC. ListA must have "Peers= ListB@its.host.com,ListC@its.host.com", whereas ListB must have "Peers= ListA@its.host.com,ListC@its.host.com" and finally ListC must have "Peers= ListA@its.host.com,ListB@its.host.com".
For lists running on LISTSERV for VM, setting the Peers= keyword 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.)
All lists must have the same list-level password, set with the PW= list header keyword. If this point is ignored, messages approved on one peer will not be accepted by the other peer and an error message will be generated, i.e.,
The approval request code received together with your posting for the MYLIST-L list is incorrect. For a peered list, this may be a normal condition. The approval protocol is not guaranteed to work among peer chains with pre-1.8b servers, and will also fail if the peers have a different password. For a non-peered list, the only likely explanation is a failure in the mail system or a recent change in mail system version or configuration. At any rate, please resubmit your message and go through the approval procedure a second time, and contact the LISTSERV administrator if the problem persists.
------------------- Rejected message (73 lines) -------------------
This means that you must explicitly set the PW= list header keyword for each peer and not use the password LISTSERV generates automatically at list creation time. (This is the only case in which it is important and indeed required to manually set PW= for a list.)
Each peer must be subscribed to at least one other peer, and the "real name" field for the subscription MUST be set to "Peer Distribution List".
7.13.11.2 Moving Users From One (Peer) Server to Another
You should be aware of the fact that a MOVE operation is not just an ADD to the new server and a DELete to the current one. This would effectively transfer the person from the old server to the new one but his distribution options would be lost in the process. Besides, you should make sure that the user does not lose any mail in the process. The proper course of action to be taken when people are moved from one list to the other is the following:
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.
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:
For each user to be moved, issue the following commands in the following order:
Query listname FOR userid@host (old server), write down the options.
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)
If there are a lot of users to move, the following method is preferred:
GET listname (old server)
GET listname (new server)
If you are using VM XEDIT, then 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, then 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. 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.
7.13.11.3 Special Commands For Peered Lists Only
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; in other words, 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 the List Keyword Reference document). 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.
7.13.12 Super-Lists and Sub-Lists
This functionality is not available in LISTSERV Lite.
It is possible to define a "super-list" (as in opposite of sub-list), that is a "container" list that includes all the subscribers in a predefined set of sub-lists. This can be done recursively to any depth. Site maintainers can create super-lists consisting of any of the lists on the server, regardless of who owns them. A non-maintainer list owner may convert a standard list that they own into a super-list, but they may only add other lists that they own to the Sub-Lists= setting. Attempts by non-maintainer list owners to add non-owned lists to their super-list will result in an error when the list configuration is stored, and the configuration will be left unchanged.
The value is a comma separated list of all the sub-lists, which must all be on the same (local) machine. For instance:
* Sub-lists= MYLIST-L,MYOTHERLIST-L
The default value for this keyword is null, that is, to have no sublists. In addition, the super-list and all of its sublists must reside on the same LISTSERV server.
The only difference between a normal list and a super-list is what happens when you post to it. With the super-list, the membership of all the sub-lists is added (recursively) and duplicates are suppressed. Other than that, the super-list is a normal list with its own archives, access control, etc. You can even subscribe to it, and this is actually an important aspect of the operation of super-lists. If you are subscribed to the super-list itself, the subscription options used to deliver super-messages to you are taken from your subscription to the super-list, just like with any other list. All combinations are allowed, and in particular NOMAIL is allowed, meaning you don't want to get messages posted to the super-list. When you are subscribed to multiple sub-lists, on the other hand, things work differently:
NOMAIL subscriptions are ignored. You will get the super-message if you have an active (not NOMAIL) subscription to at least one sub-list. The idea is that the super-message must be equivalent to posting to all the sub-lists, without the duplicates. Since all it takes to get a message posted to all the sub-lists is a single non-NOMAIL subscription, this is how the super-list works. The only way not to get the super-messages is to subscribe to the super-list directly and set yourself to NOMAIL.
The DIGEST and INDEX options are ignored and internally converted to MAIL. The first reason is that, since in most cases the user will be on multiple sub-lists (otherwise you don't need a super-list in the first place), the only safe method to set subscription options for super-messages is by subscribing to the super-list so that there is no ambiguity. The second reason is that, in most cases, super-lists will be used for out of band administrative messages rather than for large volume discussions, so it is actually preferable to have the message sent directly. The third reason is that the super-list and sub-lists may not necessarily offer the same options (DIGEST and INDEX). In particular it is expected that many super-lists will not have archives. If you want a DIGEST or INDEX for the super-messages, you must subscribe to the super-list directly.
Topics, if defined, are evaluated on a per-list basis. That is, for every sub-list (and for the super-list), LISTSERV determines whether the topic of the message is one that you want to see. If not, it acts as if you were not subscribed to this particular list. Roughly speaking, this works very well if all the sub-lists have the same set of topics (or a well-defined set of common topics), and doesn't work well at all if every list has its own set of topics.
Postings to a super-list are always archived in the super-list's notebooks (if enabled), and never in the notebooks of the sub-lists. This is because by its nature a posting to the super-list is not equivalent to cross-posting a message to all of the sub-lists. Rather, LISTSERV recourses into the sub-lists and generates an "on the fly" listing of all of the users on the super-list and the sub-lists (this is how it avoids duplicates, among other things) and then treats this "on the fly" listing as if it were the subscriber list of the super-list itself. You will note that a super-list posting is always identified as coming from the super-list, regardless of whether a given user is subscribed to the super-list or to one or more of the sub-lists.
Note: A REVIEW command sent for the super-list will not recourse into the sub-lists pointed to by the super-list. If you have a super-list called SUPER and you send a REVIEW SUPER command, LISTSERV will respond with only the people who are subscribed directly to SUPER. The only way to find out what users are covered by the super-list is to send REVIEW commands for the super-list and all of its sub-lists.
The REPRO subscriber option is recursive and will be honored for users who are subscribed to the sub-lists.
Access to the super-list's notebook archives is not automatically recursive. If you want sub-list subscribers to be able to access the archives of the super-list (but don't want the sub-list subscribers to have to subscribe to the super-list), then you must configure the Notebook= keyword for the super-list so that it contains references to each of the sublists. For example, say we have a super-list called SUPER and two sub-lists called SUB-A and SUB-B. We want the subscribers of both SUB-A and SUB-B to be able to read the archives of SUPER (since postings to SUPER won't be archived in SUB-A or SUB-B), but we don't want people who aren't subscribed to any of the three lists to be able to access the archives. So we set
* Notebook= Yes,C:\LISTS\SUPER,Monthly,Private,(SUB-A),(SUB-B)
and anyone subscribed to the SUPER list or to the SUB-A or SUB-B lists can access the SUPER archives.
If you have many sub-lists, you can specify multiple Notebook= lines, for example,
* Notebook= Yes,C:\LISTS\SUPER,Monthly,Private,(SUB-A),(SUB-B)
* Notebook= (SUB-C),(SUB-D),(SUB-E),(SUB-F)
LISTSERV will read these two (or more) Notebook= lines and concatenate the values.
7.13.13 Cloning Lists
Some sites may have a need for many lists that are essentially identical. For instance, a series of class section lists for a university department may have the same owner, allow the same class of users to subscribe, and so forth. LISTSERV makes it possible to maintain large collections of lists by "including" keywords from an external file.
For instance, consider a mathematics course with ten sections. Each section should have its own list (for instance, called M101-001, M101-002, and so forth), but the lists will otherwise be identical. The LISTSERV maintainer simply creates a text file (in this case called M101 KEYWORDS) containing the keyword definitions that will be shared by the lists, as follows:
PUT M101 KEYWORDS PW=createpw
* Owner= mathwhiz@someuni.edu (Professor J. Random User)
* Owner= Quiet:
* Owner= gradasst@someuni.edu (Joe Doakes, Graduate Assistant)
* Notebook= Yes,/home/listserv/archives/m101,Monthly,Private
* Auto-Delete= No
* Errors-To= gradasst@someuni.edu
* Subscription= Closed
* Notify= Yes Confidential= Yes Validate= Yes,Confirm,NoPW
* Reply-to= List,Ignore Review= Owners Send= Private
* Default-Options= Repro
Next, the LISTSERV maintainer stores this file in the usual way, by first making a filelist or catalog entry for it (as outlined in Section 8 File and Notebook Archives) and then storing it with a PUT operation. Generally the GET and PUT FACs for this file should specify that the list owner(s) should be able to retrieve and store it. The file must be stored in LISTSERV’s A directory (the same directory that contains the *.LIST files).
Note: It is also possible to create this file directly in LISTSERV’s A directory with a text editor; if you do so, make sure that you do not include the PUT command shown above. You should still make the filelist or catalog entry for the file so that the list owners can retrieve and store it.
Next, the LISTSERV maintainer creates and stores a skeleton list header for each of the section lists. The first section list (M101-001) is illustrated below:
PUT M101-001 LIST PW=createpw
* Math 101 Section 001 Mailing List
* .IK M101
The .IK command tells LISTSERV that whenever it uses this list, it should read the keyword definitions from the file M101 KEYWORDS (note carefully that the syntax is ".IK M101", not ".IK M101 KEYWORDS"). Now, whenever the professor in charge of the class wants to make a change to all of the M101 lists (for instance, he has a new graduate assistant), he simply GETs the file M101 KEYWORDS, makes the changes, and PUTs the file back, instead of having to GET separate headers for each list and make the changes to all of them individually.
Notes: On some servers it may be necessary to stop and restart LISTSERV (or do a GET+PUT of all of the list headers involved) to make changes to the KEYWORDS file appear. This is because LISTSERV may have the KEYWORDS file and/or the list headers that use it cached at the time you modify it.

In order to see the complete list header, send a REVIEW listname command. The response to a GET will be only the skeleton header with the .IK command. If GET did not work this way, you would not be able to change or remove the .IK command line once you set it.

The sample KEYWORDS file above includes a Notebook= keyword. This will cause the notelogs for all of the lists that use this KEYWORDS file to be written in the same directory, per the example, /home/listserv/archives/m101. This means that in that directory you would have notelogs for the M101-001 list, the M101-002 list, and so forth (depending of course on what lists use the example M101 KEYWORDS file). If this behavior is not desired, simply don't put a Notebook= keyword in the KEYWORDS file, and define it in the list header for the cloned list instead, either before or after the .IK directive.

For the web archive interface, note carefully that if you do use the same directory for all of the cloned lists' notelogs, you will still have to make separate web archive directories for each list under your WWW_ARCHIVE_DIR directory if you intend to serve the archives via the web interface. In other words, the web interface doesn't care where you keep a list's notelogs as long as it has a directory specified under WWW_ARCHIVE_DIR for it to write the list's web archive indexes into. So while all of your notelogs may go into /home/listserv/archives/m101, regardless of the name of the cloned list, you still need to make (for example) /usr/local/etc/httpd/htfiles/archives/m101-001 and so forth in order to serve the notelogs on the web.
7.14 Merging existing LISTSERV lists
It is sometimes desirable (or necessary) to merge two or more existing lists. There are a couple of different ways to do this.
7.14.1 Merging List A into List B; List A User Options Not Preserved
This is perhaps the simplest merge operation and requires only that you get the list of subscribers from list A and add them to list B, probably with a bulk operation as explained in Section 7.17 Bulk Operations (ADD and DELETE). User options are not preserved across the move and the users from list A will be subscribed to list B with whatever default options are set for list B.
7.14.2 Merging List A into List B; List A User Options Preserved
In this case you need to GET both lists A and B, header and all (so you do not use the (HEADER switch in this case). LISTSERV will return copies of the entire list files to you including all of the subscribers along with an encoded option string for each subscriber. Usually this will look something like this:
* My test list
* (remaining header lines removed for clarity)
*
xxxxx@APK.NET Pxxxx Axxxxx
2AAARAA4HAAA
xxxxxxxxxx@AOL.COM Rxxxxx Axxxx
2AAARAA2bAAA
xxxxxx@LSOFT.COM Nxxxxx Bxxxxxx
2AAARAA2bAAA
xxxxxxxx@CS.ROSE-HULMAN.EDU Mxxx Dxxxxxx
2AAARAA3nAAA
Depending on how your mail client handles long lines, the subscriber lines will be either:
1. Kept as one single long line in which the option string starts in column 81 of the line.
or –
2. Split into two separate lines, the subscriber address and real name on one line fol­lowed by the option string on the next line.
If case 1, then you should have no problem with the following operations. If case 2, then you must either:
Reformat the lines so that the option strings start in column 81 rather than being on separate lines; or
If your mail program supports MIME, re-order the file as a MIME/TEXT attachment by adding F=MIME/TEXT to your GET command (e.g., GET MYLIST-L F=MIME/TEXT). This should preserve the long lines without inserting end-of-line characters.
In any case a correctly-formatted subscriber line looks like this:
nxxxxx@LSOFT.COM Nxxxxx Bxxxxxx 2AAARAA2bAAA
Next, assuming that the subscriber lines are correctly formatted, cut and paste list B into a new mail message addressed to LISTSERV. Make sure that your mail client has all formatting options turned off; for instance, make sure line wrap and any automatic "rich text" or HTML mail formatting is turned off. If you do not do this there is no guarantee that the list file will reach LISTSERV properly formatted.
At the bottom of this new message, you can cut and paste the subscribers from list A. Note that you don't want the header of list A, just the subscriber lines. Make sure that there is no blank line between the subscribers you pasted from list B and the subscribers you have just pasted from list A.
Finally, you can now PUT your new merged copy of list B.1
7.14.3 Merging List A and List B into List C
In this case (where you may be starting a completely new list and want to merge two old lists into it), follow the directions above depending on whether or not you want to preserve user options across the merge or not. The only difference is that you will be combining the subscribers from two lists into another list instead of combining subscribers from one list into a second list. In this case you do need to be careful not to add duplicate addresses, as LISTSERV will not catch them when you PUT the new list file. In fact it is probably more sensible to set appropriate defaults to the new list and store the header by itself, then add the users with a bulk operation (not preserving their old options) so that LISTSERV can catch any duplicates you might add.
7.15 Migrating Lists From One Site to Another
In migrating lists to LISTSERV, there are three typical possibilities:
1. You are migrating lists from an existing LISTSERV site (e.g., moving from VM to unix).
2. You are migrating lists from a non-LISTSERV site to LISTSERV.
3. You are creating a LISTSERV list from a Sendmail alias or other database of email addresses.
7.15.1 Migrating Lists From One LISTSERV Site to Another LISTSERV Site
Naturally, this is the simplest migration, but it still requires a few important steps. The preferred method (and the one that generally works the best) is to GET the list from the old server, make any changes necessary to the header (e.g., location of Notebook archives) and PUT the resulting list file on the new server. This method (assuming no corruption or reformatting of the list file by intervening mail systems) is preferred because it involves LISTSERV's internal syntax checking and other error-handling functions, LISTSERV knows exactly where to put the files, and the migration isn't restricted by possible architecture-specific problems.
The drawback to the preferred method is that you have to migrate one list at a time, which may not be acceptable if you need to migrate many lists in a short period of time. In general, you can simply FTP your list files from the old server to the new server, but note the following:
You can migrate only from VM to non-VM, or from non-VM to non-VM. You cannot migrate using the FTP method from non-VM back to VM (unless you are prepared to reconstruct your list files and so forth from scratch). Naturally a GET and PUT will work if you need to move from non-VM to VM.
If migrating from VM to non-VM, then be sure to FTP the list files, archives, and so forth in ASCII mode. If you use binary mode, the files will be unreadable on your new system.
If migrating from non-VM to non-VM, you can FTP the list files in binary mode and any other files in ASCII mode. Please note that if moving the list files by binary FTP does not work, you will have to migrate the list using the preferred method outlined above. You could also create a new list header on the new server and add the users with an ADD IMPORT job as detailed in the next section.
Once you have FTP'd the files to the new server, decide where you want things to go. The list file itself should go into LISTSERV's A directory (typically ~listserv/home on unix systems, LISTSERV\MAIN on Windows systems, and LISTSERV_ROOT:[MAIN] on VMS systems). You may want to make a separate directory on your new server for archives, then subdirectories of that directory for each list (see Section 5.8 Setting Up Archive and Notebook Directories for Use with LISTSERV). If so, make the appropriate directories and move the archive files there. (This is particularly important if you intend to use the ISP options such as the file quota subsystem.) If you are copying non-notebook archives, you should read Section 8 File and Notebook Archives in order to set up a filelist or catalog file for these files.
Next, you should restart LISTSERV. This is particularly important when moving lists from VM to other platforms, as LISTSERV will need to reformat the file into the binary format used on non-VM machines. If this is successful, you will see two messages in the console log:
6 May 1996 12:50:14 Invalid record format for list XXXXX-L.
6 May 1996 12:50:14 -> List reformatted successfully.
If this is not successful, you will need to open the list file in a text editor and look for anything that might have caused a problem. Note that list header lines have a limit of 100 characters in length.
Before releasing the list to the general public, be sure to GET the list header and make any changes that need to be made. Typically, changes will need to be made to the location parameters of the Notebook= and/or Digest= keywords, particularly if you are moving from one platform to another.
Note: The first digest sent from the new site will say "First ever".
7.15.2 Migrating Lists from Non-LISTSERV Sites
Non-LISTSERV list files (notably from Majordomo and ListProc, but from other MLM software as well) are not directly compatible with LISTSERV. While it is probably possible to write a script or batch file for the purpose of converting one format to the other, it is outside the scope of this manual to describe this process.
Majordomo users will note that LISTSERV does not require two separate lists for those who want individual messages and those who want digested summaries. LISTSERV handles digesting internally for those who have set the personal option DIGEST for the list. Thus those sites migrating to LISTSERV from Majordomo will probably want to merge the digested and non-digested subscribers into one single list and let all subscribers know that they can set themselves to DIGEST mode with the SET listname DIGEST command. (It would also be possible to send commands to LISTSERV to set all of the old digest subscribers to DIGEST before releasing the list to the public.)
Under most conditions, the method recommended by L-Soft for migrating a non-LISTSERV list into LISTSERV format is the following:
Create a list header for your list as noted above and store it on the LISTSERV server. If you plan to set "Validate=" to any value but "No", set it to "No" until the following steps are completed.
Create a LISTSERV command language job as follows:
QUIET ADD listname DD=X IMPORT
//X DD *
internet-address1
internet-address2
/*
where "listname" is the name of the new list, and "internet-address1", "internet-address2" and other users are the internet addresses from the original list that you want to add to the new list. Optionally, you can add the user's "real name" field, for example,
QUIET ADD listname DD=X IMPORT
//X DD *
internet-address1 full_name
internet-address2 full_name
/*
You should remove any lines from the original list that do not actually identify subscriber addresses. If you are converting to LISTSERV from ListProc, note that LISTSERV will not convert ListProc user options to their LISTSERV equivalents; you must take a line like
user1@somehost.com POSTPONE NEWLIST NO user's name
and reduce it at least to
user1@somehost.com user's name
Otherwise, the ListProc options will become part of the full_name field.
Send the command language job to LISTSERV.
You will receive in return a confirmation that the job executed and whether or not it was successful:
> QUIET ADD XXXXX-L DD=X IMPORT
ADD: no error, 2 recipients added, no entry changed, none forwarded.
List archive notebooks from non-LISTSERV sites can be copied into a file archive area for the list and registered in the listname FILELIST (VM) or listname.CATALOG (non-VM), but it is not recommended that non-LISTSERV notebooks be renamed with LISTSERV naming conventions, as this may cause problems with LISTSERV's database functions. For instance, if you have ListProc or Majordomo notebook archives that were kept monthly, L-Soft does not recommend renaming them with the listname.logyymm format.
For information about how to convert non-LISTSERV archives to LISTSERV format, please see Section 8.10.3 Migrating Old Notebook Archives (Non-LISTSERV to LISTSERV).
Alternate method of creating the list 2: You can send the list header and subscriber list to LISTSERV in the body of an e-mail (attachments will be ignored, the header and subscriber list MUST be plain text in the body of the mail message). Only one list can be created per e-mail, and the body of the mail must look like this:
PUT listname LIST PW=createpw
* Long title of list
* (more list header lines, must begin with asterisks in column 1)
userid1@example.com His Name
userid2@example.net Her Name
In the above syntax example, "listname" is the name of the list, and "createpw" is the CREATEPW value from your site configuration file. The text of all lines must begin in column 1. All header lines must begin with an asterisk. There must not be any blank lines anywhere in the text (they would be considered as end-of-file markers).
Subscribers added in this fashion will inherit any Default-Options and Default-Topics from the list header.
7.15.3 Migrating Lists from Sendmail Alias Files, Databases, Etc.
In general, you will follow the same procedure outlined in 7.15.2 to migrate from these types of lists. You may wish to write an executable script of some sort to pull the addresses and names (if you have them) from your database and surround them with the appropriate CJLI commands, particularly if your database is made from a web site and you need to run a periodic job to add users to your lists.
7.16 Changing the Name of an Existing List
Changing the name of an existing list on the same server as opposed to migrating a list from another server is somewhat different. Here is a checklist of the basic steps involved in renaming an existing list. For the purpose of this example we will assume that the list is named MYLIST-L and we want to rename it to JOESLIST-L.
Note: Operations that call for using OS-level commands are not performed by issuing commands to LISTSERV, but rather by opening a console session and typing the commands at your system's command prompt.
1. Stop LISTSERV.
2. Find the mylist-l.list file. LIST files are kept on LISTSERV's A disk (VM) or in its A directory (non-VM). The A directory for non-VM servers is normally located at ~listserv/home for unix servers, LISTSERV_ROOT:[MAIN] for VMS servers, and LISTSERV\MAIN for Windows servers.
3. Copy (using your OS's command for copying files) mylist-l.list to joeslist-l.list. (Under unix you must name the file in lower case. Copying the list file will preserve all subscribers and all subscriber options.)
4. If necessary, create the directory for joeslist-l's archives. If you had mylist-l's archives in ~listserv/lists/mylist-l; for instance, you should create the directory ~listserv/lists/joeslist-l. Once this directory is created, you can copy the mylist-l archive notebooks over to it, and then rename any of the mylist-l.* files to joeslist-l.*. (You will want to copy the current notebook over again later, to make sure you get all of the postings up to the time of the switch.)
Note: It is not necessary (and probably not desirable in any case) to copy the DBNAMES, DBINDEX, DBRINDEX, or -RAC files as they will be rebuilt automatically by LISTSERV. Also, you don't need to copy the DIGEST or SUBJECTS files as we're going to take care of them later.
5. Again, if necessary, you should also copy over any files referenced by the list's cata­log or filelist and make a new catalog or filelist for joeslist-l. You will also need to make an entry in site.catalog (non-VM) or listserv.filelist (VM) for the new joeslist-l catalog or filelist.
6. If the list was available through the web archive interface, make a joeslist-l directory for the web archive indexes (see Section 5 Configuring Your LISTSERV Site for details).
7. Restart LISTSERV.
8. Issue a GET JOESLIST-L (HEADER NOLOCK command to get the header. Make any changes you feel necessary; for instance, in the list's description or in the com­ments which may or may not contain the old list's name. You will also need to make changes to any keyword that contains a directory reference; for instance, the Note­book= and Digest= keywords, so that they point to the right place. PUT the list header back on the server. (This PUT will cause LISTSERV to build web archive indexes for the list.)
9. Issue a HOLD JOESLIST-L command to keep the list from processing any postings from earlybird users.
At this point you are finished copying the old list to the new list. Now you need to do some housekeeping before notifying the users of the change.
10. Issue a QUIET SET MYLIST-L NODIGEST NOINDEX FOR *@* command to LISTSERV. This will force LISTSERV to send out the accumulated MYLIST-L digest and index issues to all users who had those options set.
11. Issue a HOLD MYLIST-L command to LISTSERV.
12. Copy the final MYLIST-L notebook archive file over to the JOESLIST-L directory so that you have all of the postings up to the time you issued the HOLD.
13. Get the header of the MYLIST-L list. You can now add a "New-List=" keyword to the header to let people know that the name of the list has been changed. This requires that you remove all other keywords from the header except "Owner=" and "Confi­dential=". You can set
* New-List= JOESLIST-L@LISTSERV.MYHOST.COM
* Confidential= Yes
in the list header so that a) the list no longer appears in the global List of Lists and in the CataList and b) so that all mail and inquiries sent to the old list address will be forwarded on to the new one. When you've made the changes to the header, PUT it back on the server.
14. Issue a FREE JOESLIST-L command to LISTSERV. (You should not need to issue a FREE MYLIST-L command.)
Congratulations, you've finished renaming the list. At this point you should probably announce the change and let people know where to find the archives, etc.
7.17 Bulk Operations (ADD and DELETE)
It is possible to use "bulk" operations to "front-load" or otherwise simplify the job of adding and/or deleting users from lists. This will typically be used on very large announce-type lists but the functionality is naturally available for all lists.
7.17.1 Bulk ADD Operations
To front-load or just to add a large number of users to an existing list, you construct a LISTSERV JOB framework as follows and then send it to LISTSERV. The QUIET and IMPORT command words are optional; omit the square brackets if you use them. The "full name" field is optional as long as you use the IMPORT option; otherwise you must either specify "*" (for an anonymous subscription) or a full name consisting of at least two separate words.
[QUIET] ADD listname DD=ddname [IMPORT] PW=yourpassword
//ddname DD *
userid1@host1.com [full name]
userid2@host2.com [full name]
...
useridn@hostn.com [full name]
/*
The IMPORT option implies a QUIET ADD (in other words you do not need to specify QUIET if you use IMPORT) and otherwise vastly speeds up the ADD process by loosening syntax checking and omitting success messages. If you do not use the IMPORT option and do not specify QUIET, the users you bulk add will receive the normal SIGNUP message and/or WELCOME file as usual.
It is also possible to do bulk operations through the Web Administration Interface; see Section 11 Using the Web Administration Interface for details.
7.17.2 Bulk DELETE Operations
If you have a large number of users to delete at one time, you can use a bulk delete syntax that is similar to the bulk ADD documented above. However please note that there is no "IMPORT"-type option for this feature, and as usual for the DELETE command you specify only the user's address in the data DD.
There is, however, a BRIEF option that can be specified, which is useful when you don't want a long list of "userid@host has been deleted from list xxxx" messages, one for each user deleted. Use of the BRIEF option tells LISTSERV to return only a count of the users that were deleted.
Once again you construct a LISTSERV JOB framework as follows and then send it to LISTSERV:
[QUIET] DELete listname DD=ddname PW=yourpassword
//ddname DD *
userid1@host1.com
userid2@host2.com
...
useridn@hostn.com
/*
You will probably want to use the QUIET modifier when doing a bulk delete, in order to suppress the notification message to the users being deleted.
It is also possible to do bulk operations through the Web Administration Interface; see Section 11 Using the Web Administration Interface for details. However, note that very large bulk ADD and DELETE jobs should be sent via email in preference to using the Web Interface.
7.18 Content Filtering
This feature is not available in LISTSERV Lite.
This feature is intended primarily to filter out-of-office messages and the like. It is not intended as a profanity filter. Attempts to configure it to filter profanity will most likely prove to be futile in the long run and are not recommended by L-Soft.
The CONTENT_FILTER mail template form, if present, contains filtering rules, one rule per line, empty lines ignored. Each rule has the following format:
[prefix:] pattern
The prefix, if present, can be a mail header tag (e.g. "Subject:"); "Header:" to check the whole header; or "Text:" to search the message text. The latter is the default if no prefix is supplied, it is provided in case the pattern contains a colon in the first word. If there are multiple mail header tags with the specified name (e.g. "Received:"), each such tag is searched and it is enough for one of them to match the pattern. If the requested tag is not present in the header, there is (surprise!) no match. A text search will search every line of the first text/plain part in the message. If there is no text/plain part, there is no match. Again, this is designed to filter read receipts, loops, chain letters, spam, you name it. There was no attempt on the developers' part to make this a profanity filter, and future versions will not be "enhanced" to make futile attempts at (for instance) decoding Word documents to look for obscene words.
Regular comparisons such as those described above are not case sensitive. Patterns are standard LISTSERV patterns, that is, the asterisk is the wildcard character. If there is no asterisk in the pattern, it is replaced with "*pattern*" much like the SCAN command.
Documented Restriction: You cannot match literal asterisk characters in a string as there is no way to escape them. Any asterisk in a pattern will always be evaluated as a wildcard.
The content filter also supports "exact match" comparisons, which are triggered by a double colon. For instance:
Subject::
There are two significant differences between exact and regular match:
You must supply your own wildcard characters in an exact match (if you want to use wildcards, that is). A regular match will insert leading and trailing wildcards if none are found. Thus, an exact match is the only way to make a comparison without wildcards.
You can make an exact match for the empty string. Empty regular matches are ignored since they map to a wildcard comparison for **, which would be always true. This also makes it possible to apply an exact match to a message that does not contain a specified header. For instance, if you want all messages to contain a (mythical) KABOOM: RFC822 header, with an exact match you can tell LISTSERV to perform one of the content-filtering actions if the the header is not present. This is not possible with a regular match.
Note: You cannot differentiate a header with an empty KABOOM field from a header with no KABOOM field.
One of the most handy uses for the exact match syntax is to be able to write a rule to reject messages with blank subject lines. For instance:
Subject::
Action: REJECT Please resubmit your message with a non-blank subject.
Every rule can, optionally, be followed by an action rule. This has the following format:
Action: ALLOW
Action: REJECT reason
Action: DISCARD comment
Action: MODERATE
(The available actions are the same for both regular and exact comparisons.) For instance,
>>> CONTENT_FILTER
Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
Subject: Auto-Generated:
Action: REJECT
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
Subject::
Action: REJECT Please resubmit with a non-blank subject.
Subject: copyright
Action: MODERATE
To: friend@public.com
Action: DISCARD This guy is a spammer
The default is "Action: REJECT" with no specified reason. REJECT means that the message is rejected. MODERATE means that the message is to be forwarded to the list editor to be manually approved or rejected. DISCARD means that the message is to be dropped on the floor without further processing; any text following DISCARD is echoed to the LISTSERV console (and is thus logged).
ALLOW means that the message is allowed and all remaining rules are ignored. This could be used in moderated lists to allow the list moderator to bypass certain filters, for instance:
>>> CONTENT_FILTER
Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
From: JOE@EXAMPLE.COM
Action: ALLOW
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
In the example above, messages with Subject: lines containing "Out of office" are rejected. Messages containing the text "Click here to be removed" are also rejected UNLESS they come from joe@example.com.
The text of the rejection is fetched from the BAD_CONTENT mail template form, with the reason supplied as a variable called &COMMENT. The rejection message looks like this:
Date: Tue, 4 Dec 2001 22:03:42 -0500
From: "L-Soft list server at LISTSERV.EXAMPLE.COM (1.8e)"
<LISTSERV@LISTSERV.EXAMPLE.COM>
Subject: Rejected posting to TEST@LISTSERV.EXAMPLE.COM
To: Joe User <joe@EXAMPLE.COM>
Your posting to the TEST list has been rejected by the content filter. OOO messages are not allowed on this list.
followed by the text of the posting including all mail headers. (In this case the body of the message contained the text "out of office" and the rule above was applied.)
A default site-wide CONTENT_FILTER template form may be defined in SITE.MAILTPL for use by lists whose owners do not prefer to provide their own custom versions in their listname.MAILTPL files.
7.19 DomainKeys Message Signing
This feature is not available in LISTSERV Lite.
DomainKeys message signing is available to sites running LISTSERV Classic or LISTSERV Classic HPO. Current LISTSERV maintenance is also required. For more information on how to configure LISTSERV for DomainKeys support, please refer to Section 5.12 LISTSERV DomainKeys Support.
Assuming that it is available for your use, DomainKeys support for lists is enabled by default. This means that all list postings and administrative messages related to a list will be signed to assert that they actually originated from your LISTSERV server.
If for some reason you wish to disable DomainKeys message signing for a given list, you can do so by adding
* Misc-Options: NO_DKIM_SIGNATURE
to your list header. Or, if you prefer to disable it server-wide by default, you can add NO_DKIM_SIGNATURE to the DEFAULT_MISC_OPTIONS site configuration variable setting.
Incoming DomainKeys or DKIM signatures submitted to a mailing list will be removed unless "Misc-Options= KEEP_DKIM_SIGNATURE" is set in the list configuration. This is necessary because these signatures almost never match after the message has been processed. The worst thing that could possibly happen to your deliverability is a DomainKeys signature that does not match and causes the message to be flagged as suspicious.
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DomainKeys is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for subscribers on systems that have implemented the client side of DomainKeys. The DKIM specification may be more robust in this respect, but even DKIM signatures will probably not survive when posted through a mailing list. Use the KEEP_DKIM_SIGNATURE option at your own risk.
 
 

1
There is an alternate method of doing this kind of merge which requires access to the machine LISTSERV is running on. You can simply use the 'listview' program to output the list files in text format, and redirect them into editable files (with 'listview -a listname > listname.txt', for instance). Then you can use a text editor to combine the two lists and either mail the resulting merged list to LISTSERV or store the merged file as listname.list and restart LISTSERV to reformat the file (as explained above in Section 7.1). However, note carefully that the latter method (save and restart LISTSERV) is not recom­mended, nor is it the supported method for storing lists, as it bypasses a number of checks LISTSERV does when you use PUT.

2
Another alternate (but unsupported) method of creating the list. Note that you can also create the list, header and subscriber list together, using a text editor. Simply start adding subscribers right after the last header line, save the file with the extension ".list", and restart LISTSERV as noted above in 7.15.1 to reformat the list. Do not, however, attempt to edit the list with a text editor once it has been created--use only LISTSERV commands sent via mail, the VM console, or the LCMD utility to make changes. And note carefully that subscribers added in this fashion (i.e., without a pre-existing user options string) DO NOT inherit any default options set in the header, and would require that any required options be set manually (that is, with the command QUIET SET listname options FOR *@*). You can avoid this problem by not using this method.