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.
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:
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.)
Replace "LISTNAME" with the name of your list, for example,
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:
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,
|
$ mail
MAIL> send newlist.create
To: in%"listserv@xyz.com"
Subj:
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.
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 installation guide 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:
|
•
|
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:
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.
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:
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.
|
2.
|
If Notebook= Yes, then make the appropriate directory and make sure that LISTSERV 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.
|
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.
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:
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.
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.
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.
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).
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.
|
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).
|
•
|
Issue the UNLOCK listname command (if you decide no changes are needed)
|
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:
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:
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:
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).
(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).
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.
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.
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:
|
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.
|
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.
|
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.
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.
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:
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>
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
= instead.
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
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:
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.
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).
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.
* 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,
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
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".
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.
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.
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.
* Send= Editor,Confirm* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= someuser@somehost.com,yetanotheruser@his.host.com
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
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
"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
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.
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.
(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.
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.
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.
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.
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:
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.
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.
|
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:
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,
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.
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
----------------------------------------------------------------
-----------------------------------------------------------
// JOB
ADD &LISTNAME &WHOM &USERNAME
// EOJ
-----------------------------------------------------------.fo on
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.
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.
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:
|
•
|
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.
|
•
|
Query listname FOR userid@host (old server), write down the options.
|
|
•
|
GET listname (old server)
|
|
•
|
GET listname (new server)
|
|
•
|
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.
|
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.
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.
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. Only the LISTSERV maintainer can create a super-list, for security reasons. Concretely, the "Sub-lists=" keyword is protected from owner tampering in the same fashion as "Notebook=". The value is a comma separated list of all the sub-lists, which must all be on the same (local) machine. For instance:
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.
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
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:
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.
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.
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.
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
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
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.
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:
Note: The first digest sent from the new site will say "First ever".
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.)
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,
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.
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).
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.
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.
|
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.
|
|
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.
|
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 comments 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 Notebook= 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.
|
|
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 "Confidential=". You can set
|
|
14.
|
Issue a FREE JOESLIST-L command to LISTSERV. (You should not need to issue a FREE MYLIST-L command.)
|
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.
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.
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.
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.
[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.
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:
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.
|
•
|
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.
Subject::Action: REJECT Please resubmit your message with a non-blank subject.
Action: ALLOWAction: REJECT reason
Action: DISCARD comment
Action: MODERATE
>>> 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 -0500From: "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>
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.
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.
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.
