L-Soft international, Inc. ****************************** * List Owner's Manual * * for * * LISTSERV(tm), version 1.8b * ****************************** August 14, 1995 Revision 1 The reference number of this document is 9505-UD-02 ================================================================================ Information in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. L- Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of L-Soft international, Inc. Copyright (c) 1995, L-Soft international, Inc. All Rights Reserved Worldwide. L-SOFT, LISTSERV and LMail are trademarks of L-Soft international, Inc. UNIX is a registered trademark of UNIX Systems Laboratories. AIX and IBM are registered trademarks of International Business Machines Corporation. Alpha AXP, Ultrix and VMS are trademarks of Digital Equipment Corporation. OSF/1 is a registered trademark of Open Software Foundation, Inc. Microsoft is a registered trademark and Windows, Windows NT and Windows 95 are trademarks of Microsoft Corporation. HP is a registered trademark of Hewlett-Packard Company. Sun is a registered trademark of Sun Microsystems, Inc. IRIX is a trademark of Silicon Graphics, Inc. PMDF is a registered trademark of Innosoft International. All other trademarks, both marked and not marked, are the property of their respective owners. All of L-Soft's manuals for LISTSERV are available in ascii-text format via LISTSERV and in Rich Text Format (RTF) and Postscript (PS) format via ftp.lsoft.com. They are also available on the World Wide Web at the following URL: URL: http://www.lsoft.com/manuals/index.html L-Soft invites comment on its manuals. Please feel free to send your comments via e-mail to MANUALS@LSOFT.COM. ================================================================================ ********************* * Table of Contents * ********************* Preface: LISTSERV Command Syntax Conventions 1. About Mailing Lists and LISTSERV(tm) 2. Starting a Mailing List - The Basics 2.1. Avoid duplication of effort 2.2. What skills do I need to start and maintain a LISTSERV mailing list? 2.3. Creating a mailing list - Where can it be done, and Who can do it? 2.4. List Header Keywords and what they do 2.4.1. Access Control Keywords 2.4.2. Distribution Keywords 2.4.3. Error Handling Keywords 2.4.4. List Maintenance and Moderation Keywords 2.4.5. Security Keywords 2.4.6. Subscription Keywords 2.4.7. Other Keywords 2.5. Retrieving and editing the list - some considerations 2.6. Adding a list password 2.7. Storing the list on the host machine 2.8. Fixing mistakes 2.9. A sample list header file 2.10. Security Options 2.10.1. First line of defense: The VALIDATE= keyword 2.10.2. Controlling subscription requests 2.10.3. Controlling the service area of your list 2.10.4. Controlling who may review the list of subscribers 2.10.5. Controlling who may access the notebook files 2.10.6. Controlling who may post mail to the list 2.10.7. The "OK" confirmation mechanism 3. Advertising Your Public Mailing Lists 3.1. List of Lists 3.2. The INFO command and how to implement it 3.3. The NEW-LIST project at North Dakota State 3.4. The Internet Network Information Center (INTERNIC) 3.5. The Global List Exchange (GLX) and why you should mention it 3.6. How NOT to advertise a mailing list 4. Managing Subscriptions 4.1. How to add and delete subscribers to/from a list 4.2. Finding users who do not appear in the list 4.3. Converting mailing lists to LISTSERV from other systems 4.4. Using the QUIET option with commands 4.5. Dealing with bounced mail 4.5.1. What is a bounce, and what can typically cause one? 4.5.2. What to do about several types of bounces 4.5.3. Redistribution lists and why they may cause you migraines 4.6. Automatic and semi-automatic deletion 4.7. Subscription confirmation 4.8. Subscription renewal 4.9. The SERVE command 4.10. "Peering" Large Lists 5. Setting Subscription Options For Subscribers 5.1. How to review current subscription options with QUERY 5.2. How to set personal subscription options for subscribers 5.3. Options that may be set 5.3.1. Mail/NOMail 5.3.2. DIGest 5.3.3. INDex 5.3.4. ACK/NOACK/MSGack/NONE 5.3.5. Options for mail headers of incoming postings 5.3.6. CONCEAL/NOCONCEAL 5.3.7. REPro/NOREPro 5.3.8. TOPICS 5.3.9. POST/NOPOST 5.3.10. EDITOR/NOEDITOR 5.3.11. REVIEW/NOREVIEW 5.3.12. RENEW/NORENEW 5.4. Setting original default options with the Default-Options= keyword 6. Moderating and Editing Lists 6.1. List charters, welcome files, and administrative updates 6.2. The role of the list owner as moderator 6.3. The role of the list owner as editor 6.4. Setting up an edited list 6.5. Submitting subscriber contributions to an edited list 6.6. Message approval with Send= Editor,Hold 6.7. Using list topics 6.8. The listname WELCOME and listname FAREWELL files 6.8.1. Creating and storing listname WELCOME and FAREWELL files 6.8.2. Using the listname WELCOME file as a moderation tool 6.8.3. Using the listname FAREWELL file as a feedback tool 6.8.4. The alternative to using WELCOME and FAREWELL files 6.9. Social conventions (netiquette) 6.10. Spamming: what it is, and what to do about it 6.11. Appropriate use policies: considerations 7. Overview of List Archives 7.1. What is the list archive? 7.2. Setting up and managing archive notebooks 7.3. Database Functions Overview 7.4. Where to find more information on Database Functions 8. Overview of File Archives 8.1. What is the file archive? 8.2. Starting a filelist 8.3. Filelist maintenance 8.4. Giving other users access to files 8.5. Storing files on the host machine 8.6. Automatic File Distribution (AFD) and File Update Information (FUI) 8.7. "File Packages" 8.8. Where to find more information on File Archives 9. Customizing LISTSERV's Default Mail Templates 9.1. What LISTSERV uses mail templates for 9.2. The DEFAULT.MAILTPL file and how to get a copy 9.3. Mail template format and embedded formatting commands 9.4. Creating a .MAILTPL file for a list 9.5. Storing the .MAILTPL file on the host machine 10. Gatewaying to USENET 10.1. Why would I want to? 10.2. How to go about it 10.3. Special considerations and problems with gatewaying 11. Solving Problems 11.1. Helping subscribers figure out the answers 11.2. Loop-checking can cause occasional problems with quoted replies 11.3. Broken and/or unhelpful mail servers 11.4. Broken and/or one-way gateways 11.5. Firewalls 11.6. If I can't find the answer, where do I turn? 11.7. LSTOWN-L@SEARN and LSTSRV-L@UGA - two other places to get help Appendix A: System Reference Library for LISTSERV* version 1.8b Appendix B: List Keyword Alphabetical Reference for LISTSERV(tm) version 1.8b Appendix C: Sample Boilerplate Files Appendix D: Related Documentation and Support Appendix E: Acknowledgments ************************************************ * Preface: LISTSERV Command Syntax Conventions * ************************************************ Generally, parameters used in this document can consist of 1 to 8 characters from the following set: A-Z 0-9 $#@+-_: Deviations from this include: fformat Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail full_name first_name [middle_initial] surname (not your e-mail address) listname name of an existing list node BITNET nodeid or Internet hostname of a BITNET machine which has taken care of supplying an ':internet' tag in its BITEARN NODES entry; or the fully-qualified domain name (FQDN) of an Internet host. pw a password containing characters from the set: A-Z 0-9 $#@_-?!|% userid Any valid RFC822 network address not longer than 80 characters; if omitted, the 'hostname' part defaults to that of the command originator Other deviations from the standard set will be noted along with the affected commands. Also please note the following conventions for representing variable or optional parameters: < > Angle brackets always indicate required parameter names that must be replaced by appropriate data when sending commands to LISTSERV [ ] Square brackets enclose optional parameters which, if used, must be replaced by appropriate data when sending commands to LISTSERV **************************************** * 1. About Mailing Lists and LISTSERV * **************************************** LISTSERV is a system that allows you to create, manage and control electronic "mailing lists" on a corporate network or on the Internet. Since its inception in 1986 for IBM mainframes on the BITNET academic network, LISTSERV has been continually improved and expanded to become the predominant system in use today. LISTSERV is now available for VM, VMS(tm), unix(r) and Windows NT(tm), and has already been ported to Windows 95(tm) (formerly Windows 4.0). Consider for a moment what the users of your electronic mail system actually use electronic mail for. Do they discuss problems and issues that face your organization, down to the departmental level? In an academic setting, do your faculty and students communicate via electronic mail? As with "real world" distribution lists, electronic mailing lists can make it possible for people to confer in a painless manner via the written word. The electronic mail software simply replaces the copying machine, with its associated costs, delays and frustrations. In fact, electronic mail lists are easier to use than most modern copiers, and a lot less likely to jam at just the worst possible moment. Because electronic mail is delivered in a matter of seconds, or occasionally minutes, electronic mailing lists can do a lot more than supplement the traditional paper distribution lists. In some cases, an electronic mailing list can replace a conference call. Even when a conference call is more suitable, the electronic mailing list can prove a powerful tool for the distribution of papers, figures and other material needed in preparation for the conference call. And, when the call is over, it can be used to distribute a summary of the discussion and the decisions that were made. What before might have been an exchange of views between two or three people can now become an ongoing conference on the issue or problem at hand. Announcement lists and even refereed electronic journals can be made available to your audience, which can be as small as a few people or as large as the entire Internet community. If you need a further overview, please see Appendix D, Related Documents and Support, for information on how to get one. ******************************************** * 2. Starting a Mailing List - The Basics * ******************************************** 2.1. Avoid duplication of effort ================================ Before you start your list, it pays to do a careful search in several places to find out if you are duplicating an already-existing list, or if the name you are considering is already in use for a list on a differing subject. The first place to check is the "List of Lists" maintained by LISTSERV itself. Send the command LIST GLOBAL in the body of mail to LISTSERV@LISTSERV.NET (or to LISTSERV at any host site). You will receive a mail message in return containing a list of all lists known to LISTSERV where either the name of the list or the short list description contains your search string. For instance, LIST GLOBAL IBM would result in the following being returned to you: -------------------------------------------------------------------------------- Excerpt from the LISTSERV lists known to LISTSERV@PEACH.EASE.LSOFT.COM on 6 Feb 1995 09:57 Search string: IBM *********************************************************************** * To subscribe, send mail to LISTSERV@LISTSERV.NET with the following * * command in the text (not the subject) of your message: * * * * SUBSCRIBE listname * * * * Replace 'listname' with the name in the first column of the table. * *********************************************************************** Network-wide ID Full address and list description --------------- --------------------------------- 9370-L 9370-L@NIC.SURFNET.NL IBM 9370 and VM/IS specific topics list AIBIBL AIBIBL@PLEARN.EDU.PL ACADEMIC INITIATIVE IBM , PROJECT "LIBRARY SYSTEMS" AIBIBL AIX-L AIX-L@PUCC.PRINCETON.EDU IBM AIX Discussion List AIXNEWS AIXNEWS@PUCC.PRINCETON.EDU IBM AIX News to Mail Distribution -------------------------------------------------------------------------------- Figure 2.1. Sample output of LIST GLOBAL IBM (63 more lists were deleted for brevity) You might want to make your search more specific, as this particular search locates every list that has IBM somewhere in its title. For instance, if you wanted to start a list on some aspect of the IBM 370, you might do better to search for IBM 370. Alternative searches you can do include: * Check the archive on NDSUVM1 (or VM1.NODAK.EDU), where the NEW-LIST project at North Dakota State University has been storing list announcements for several years. The NEW-LIST archive contains information about LISTSERV lists as well as about lists running on other types of servers. This information is accessible either via LISTSERV database searches or by Gopher to vm1.nodak.edu. * Use a Gopher or World-Wide Web (WWW) client to access the InterNIC database services, where a list of lists is maintained. The InterNIC Gopher is located at rs.internic.net. * Get a copy of the Interest Groups List of Lists maintained by SRI on its server at sri.com. Note that this is a 500KB (or larger) file. ftp sri.com user: anonymous password: cd netinfo get interest-groups * Get a copy of the Interest Groups list maintained by David Avery at Dartmouth College. This is a merged list of the LISTSERV list of lists and the Internet Groups list, with one-line entries for each group. Again, this is a large file, so be sure you have room for it. Also available on the dartcms1 server is a Macintosh Hypercard application that formats this file nicely (assuming you have a Macintosh). You may want to do a dir of the files available in the siglists directory to see if there is anything else there that might be useful. ftp dartcms1.dartmouth.edu user: anonymous password: (not required by dartcms1) cd siglists get internet.lists Note that all these files (except the large data stack) can also be retrieved from LISTSERV@DARTCMS1.DARTMOUTH.EDU. * Check the Usenet newsgroups news.announce.newusers and news.lists , if they are available to you via your local news feed. 2.2. What skills do I need to start and maintain a LISTSERV mailing list? ========================================================================= You should already be familiar with your mailing system and text editor. Otherwise, there are no special skills required. It is the goal of this manual to give you what you need to know about LISTSERV user commands, privileged LISTSERV owner commands, and how to read and interpret RFC822 Internet-style mail headers. LISTSERV itself is designed to operate in an identical manner no matter which operating system it is running under. Thus the fact that LISTSERV is running under VM, VMS, some flavor of Unix, or Windows NT should not be a concern to the list owner, who may not even know which version of LISTSERV his lists are running on. Additionally, we have made an attempt to give you a basic "list owner's course" in anticipation of some of the issues you may encounter in the course of moderating a list. 2.3. Creating a mailing list - Where can it be done, and Who can do it? ======================================================================= If you are looking for a site to host a list, you might consider the following: * First, find out if your computing center maintains a LISTSERV host. * If not, write a short description of your proposed list, including the proposed name, general topic, target audience, estimated number of subscribers and estimated number of messages to be processed daily. Send this proposal, with a subject line of "Searching for a host site" (or something similar) to LSTSRV-L @UGA.CC.UGA.EDU. * If the first two options do not bear fruit, you might consider a commercial LISTSERV site. There are a number of such sites, including L-Soft's own EASE(sm) service. Send the description and a request for further information to SALES@LSOFT.COM. Please note also that many sites (predominantly, but not necessarily limited to, those in .EDU domains) will not host commercial or potentially-controversial lists because of internal policies regarding appropriate use of their computing facilities. In such a case, your only option may be to seek a commercial LISTSERV site. Physically creating the list is the task of the LISTSERV maintainer (sometimes referred to as the "LISTSERV postmaster") at a given LISTSERV host site. Specific procedures for requesting a list startup vary from institution to institution. It is usually best to contact the computing center at the site for more information. 2.4. List Header Keywords and what they do ========================================== How a LISTSERV mailing list performs its tasks is defined by its header keywords. There are several different categories of keywords, each of which is discussed below in general terms. A complete alphabetical listing of list header keywords, including default settings and all options available, is provided in Appendix B. Access Control Keywords ----------------------- These keywords designate the level of "openness" for a list. They determine who can post to the list, who can review the list of subscribers, and whether or not the list is open to general subscription. Distribution Keywords --------------------- This group has to do with how LISTSERV distributes postings to subscribers, including whether or not acknowledgments are sent back to posters, how many postings may go through the list daily, whether or not the list is available in digest form and whether it is available to USENET through a gateway. These keywords also determine whether or not list topics are enabled, and how LISTSERV will configure outgoing postings for replies. Error Handling Keywords ----------------------- Included under this group are the keywords controlling automatic deletion, loop-checking, and to whom error messages are sent for disposition when received by LISTSERV. List Maintenance and Moderation Keywords ---------------------------------------- A fairly large group of keywords having to do with how the list is operated, including definitions for the list owner, list editor, and the list archive notebook; whether or not (and who) to notify when users subscribe and sign off; how often subscriptions must be renewed, and so forth. These are perhaps the most basic keywords that can be set for a given list, and one of them ("Owner=") must be set for a list to operate. Security Keywords ----------------- These keywords control who can "see" the list (that is, whether or not the list appears in the List of Lists for a given user, based on the user's host site), whether or not the list is protected by a password, and the level of security necessary for changes to the list itself. The "Exit=" keyword is also contained in this group. Subscription Keywords --------------------- These control whether or not the list is open to general subscriptions, whether or not a mailing path confirmation is required, and what user options are set by default upon subscription. Other Keywords -------------- These control other aspects of list management that are not generally changed from their defaults, and which do not fit readily into the categories listed above. 2.5. Retrieving and editing the list - some considerations ========================================================== Once your list has been created by the LISTSERV maintainer, you can have a copy of the list sent to you for editing purposes. Simply issue the GET listname command to LISTSERV. This will cause the server to mail you a copy of the entire list (header and subscriber list). If you want to change header keyword settings only, it is probably advisable to issue the GET command with the (header switch: GET (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 (header nolock (Note that the "(" switch character is used only once.) CAUTION: It is not advisable to use the (nolock switch in at least two cases: * 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. Another caution: If you GET the header with the (header switch, do not add new subscribers "on the fly" to the bottom of the header. If you do, your subsequent PUT will replace the entire list online with what you have sent, canceling the subscriptions of every user on the list (except for the ones you added to the header). LISTSERV maintainers should note one further caution: It is considered extremely inadvisable to "hand-edit" subscriber lists, as columns at the far right of each subscriber's entry contain list control codes corresponding to the subscriber's personal option settings. The only case in which it might be appropriate to "hand-edit" would be to delete a user entirely, and then only if all attempts to delete the user via the DELETE command fail. For instance, X.400 or X.500 addresses can cause DELETE to fail because of their use of the "/" character. You can use wildcards to delete these subscriptions. You can also enclose the address in double quotes: DELETE XYZ-L "/ADMD=ABC/PRMD=DEF/...../@X400.SOMEHOST.COM". 2.6. Adding a list password =========================== When creating the list, the LISTSERV maintainer should assign a password for the list. You can change this password when you store the list (with the "PW=" keyword), but the first time you store the list, you must use the original password if it has been assigned. Note that not all LISTSERV maintainers do this by default; if you are not given a password to use with your list, it is highly recommended that you assign it one yourself by adding a "PW=" header line as follows: * PW=MYPASSWD Replace "MYPASSWD" with the word you choose. Note that there should not be a space between "PW=" and your 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. 2.7. Storing the list on the host machine ========================================= When you are ready to store your list back on the host, include the list file in a mail message to LISTSERV. Ensure that the PW=XXXXXXXX command is in the first line of the mail body. Change XXXXXXXX to the password you have previously defined with the PW= list header keyword. Then send the message. If LISTSERV has trouble processing the edited list file, it will return a discrepancy report to you with each error noted. If the errors are categorized as "warnings only," LISTSERV will go ahead and store the list. However, if any one error is categorized as a serious error, the list will not be stored and the old version will be retained. Caution: If you are using a mailer such as Pine or Microsoft Mail that allows "attachments" to mail, do not "attach" the list file to your mail message. It must be in plain text with the PUT line at the top. LISTSERV will not translate encoded attachments. 2.8. 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 PUT listname LIST PW=XXXXXXXX command to the top of the file and store it. 2.9. A sample list header file ============================== Once the LISTSERV maintainer has notified you that the basic list has been created, you can send a GET command to the server to make any modifications necessary. For instance, GET MYLIST PW=MYPASSWD (HEADER might cause LISTSERV to send you the following list header file: -------------------------------------------------------------------------------- PUT MYLIST.LIST PW=XXXXXXXX * The Descriptive Title of My List * * Owner= NATHAN@LSOFT.COM (Nathan Brindle) * Notebook= Yes,A,Monthly,Public * Errors-To= Owner * Subscription= Open,Confirm * Ack= Yes Confidential= No Notify= No * Files= No Mail-Via= Distribute Validate= No * Reply-to= List,Respect Review= Public Send= Public * Stats= Normal,Private X-Tags= Yes * Default-Options= NoFiles,NoRepro * * This list installed on 95/02/02, running under L-Soft's LISTSERV-TCP/IP * version 1.8b for Windows NT. * * Comment lines... * -------------------------------------------------------------------------------- Figure 2.2. A sample list header file for a list called MYLIST. Below, we've now edited the list header and it is ready to be included in a mail message and sent back to LISTSERV. Note that the PUT command has been modified to include the password assigned by the LISTSERV maintainer, and note also the PW= keyword in the body of the list header which will define a new password. -------------------------------------------------------------------------------- PUT MYLIST.LIST PW=MYPASSWD * The Descriptive Title of My List * * Owner= NATHAN@LSOFT.COM (Nathan Brindle) * Owner= Quiet: * Owner= nathan@linus.dc.lsoft.com * Owner= ncbnet@linus.dc.lsoft.com * Notebook= Yes,A,Monthly,Public * AutoDelete= Yes,Full-Auto * Errors-To= ncbnet@linus.dc.lsoft.com * Subscription= Open,Confirm * Ack= Yes Confidential= No Notify= No * Files= No Mail-Via= Distribute Validate= No * Reply-to= List,Respect Review= Public Send= Public * Stats= Normal,Private X-Tags= Yes * Default-Options= NoFiles,NoRepro * PW=NEWPASSWD * * This list installed on 95/02/02, running under L-Soft's LISTSERV-TCP/IP * version 1.8b for Windows NT. * * Comment lines... * -------------------------------------------------------------------------------- Figure 2.3. The edited list header file ready to be sent back to the server. 2.10. Security Options ====================== LISTSERV’s security options are wide ranging, from almost no protection (easiest to administer your list, but also most open to hacker attacks) to total protection requiring validation of each and every command sent to LISTSERV for your list. It is also possible to limit access to various aspects of your list, such as who can subscribe, who can review the list of subscribers, and who can access the list archives. You can hide your list from the LIST command, either at the global level or from all requests, including those from users on LISTSERV’s local machine, or from a definable range in between. 2.10.1. First line of defense: The VALIDATE= keyword ----------------------------------------------------- The VALIDATE= keyword controls the level of command validation desired for your list. The default, VALIDATE= NO, requires password validation only for storing the list on the server. This is often sufficient for general needs. However, when a list is set this way, LISTSERV does not validate commands it receives for the list, under the assumption that the mail it receives is genuinely coming from a list owner. This level of validation does not protect the list from commands issued by hackers who have forged mail in the name of the list owner. The next level is VALIDATE= YES. At this level, LISTSERV requires a password for all of its "protected" commands. This password can be either the list password or the sender’s personal password as defined by the PW ADD command. The commands protected by this level are those that affect subscriptions or the operation of the list, e.g., DELETE or ADD. Users will also have to validate most commands that affect their subscriptions, but generally can do so using the "OK" mechanism rather than defining a personal password. Note that some user commands will be forwarded to the list owner for validation rather than accepting password validation from the user. The next level is VALIDATE= YES,CONFIRM. At this level, LISTSERV will require validation with the "OK" mechanism (see below) by default, but will still accept passwords where appropriate. While the less-secure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience. The next level is VALIDATE= YES,CONFIRM,NOPW. At this level, LISTSERV will no longer accept passwords as validation for protected commands. The logic is that because of the way the "OK" mechanism is implemented, passwords are not as safe as "magic cookies". This is the recommended setting for lists that must be kept secure. Two other levels are VALIDATE= ALL,CONFIRM and VALIDATE= ALL,CONFIRM,NOPW. These levels require "OK" validation for all commands that cause a change in state except for the PUT command. If NOPW is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (e.g., QUERY) do not require validation. Note that LISTSERV requests coming from the local system via CP MSG or CP SMSG on VM systems or via LCMD on VMS or Unix systems never require validation, as they cannot be forged. See Appendix B for more information on the VALIDATE= keyword. 2.10.2. Controlling subscription requests ----------------------------------------- You can control subscription requests by use of the SUBSCRIPTION= keyword. By default, this keyword is set to SUBSCRIPTION= BY OWNER, meaning that all subscription requests will be forwarded to the list owner for disposition. You can also refuse all subscription requests by setting SUBSCRIPTION= CLOSED. To code a list for open subscriptions without list owner intervention, you set SUBSCRIPTION= OPEN. If you would like to add protection against forged subscription requests or bad return mailing paths, code SUBSCRIPTION= OPEN,CONFIRM. The latter will cause a subscription confirmation request to be sent to the prospective subscriber, which he or she must respond to using the "OK" confirmation mechanism. In order to restrict subscriptions to persons in a specific service area, see the next section. 2.10.3. Controlling the service area of your list ------------------------------------------------- It may be desirable to restrict access to your list to people in a small area. For instance, you probably would not want a list for students in a class section at a university to be advertised or accessible by people all over the world. However, without setting certain keywords appropriately, such a list will be visible to a LIST GLOBAL command. If you wish to simply hide your list from a LIST command, but still allow people to subscribe to it if they know it is there, use the keyword CONFIDENTIAL= YES. Note that users subscribed to the list as well as the list owner(s) will be able to see the list if they issue a LIST command. If you wish to hide your list from and refuse subscription requests from users outside the local area, you define two keywords: * SERVICE= bitnode1,bitnode2,some.host.edu * CONFIDENTIAL= SERVICE SERVICE= can also be set to SERVICE= LOCAL, meaning it will use either LISTSERV’s global definition of which machines are LOCAL, or the machines defined by the list keyword LOCAL=. If you wish to set SERVICE to LOCAL, you should check with your LISTSERV maintainer to find out which nodes are considered local. If the global definition is not suitable, you can override it by defining the LOCAL= keyword: * LOCAL= bitnode1,bitnode2,some.host.edu,another.host.com * SERVICE= LOCAL * CONFIDENTIAL= SERVICE If there are many subdomains within your primary domain, you may wish to use the wildcard when defining the LOCAL or SERVICE keywords. For instance: * SERVICE= *.HOST.COM defines the service area as "all subdomains ending in .HOST.COM". 2.10.4 Controlling who may review the list of subscribers --------------------------------------------------------- For whatever reason, you may wish to restrict the ability to review the subscriber list either to subscribers or to list owners. This is done by setting the REVIEW= keyword appropriately. To allow anyone, including non-subscribers, to review the list, set REVIEW= PUBLIC (which is also the default). To restrict reviews of the list to subscribers only, set REVIEW= PRIVATE. To restrict reviews of the list to list owners only, set REVIEW= OWNERS. You can also restrict reviews to users within the list’s service area by setting REVIEW= SERVICE , and defining the SERVICE= keyword appropriately (see the preceding section). 2.10.5 Controlling who may access the notebook files ---------------------------------------------------- Restricting access to the list’s notebook archive files is similar to controlling who may review the list. It is accomplished by setting the fourth parameter of the NOTEBOOK= keyword to an appropriate value. For instance, * NOTEBOOK= Yes,A,Monthly,Public defines a monthly notebook on LISTSERV’s A disk that is accessible by anyone. Change Public to Private if you wish only subscribers to be able to access the notebooks. The same access-levels are available for this keyword as for REVIEW=. (See Appendix B for a discussion of access-levels.) If enabled, notebook archives are private by default. 2.10.6 Controlling who may post mail to the list ------------------------------------------------ The Send= list header keyword is the basic control for who may post mail to the list. If the list allows non-subscribers to post, set Send= Public. For a list that does not allow non-subscribers to post, set Send= Private. For a list where all posts should be forwarded to a moderator/editor, there are two settings: * Send= Editor forwards all postings to the list editor (see the Editor= and Moderator= keywords). This setting allows the editor to make changes before forwarding the message back to the list. Note that your mail program must be capable of inserting "Resent-" header lines in your forwarded mail--if it is not capable of this, all such posts forwarded to the list will appear to be coming from the editor. Check with your system administrator if you are not sure whether or not your mail program inserts the "Resent-" headers. * Send= Editor,Hold forwards a copy of the posting to the editor but differs from Send= Editor in that LISTSERV holds the posting for a period of time (usually 7 days) until the editor confirms the message with the "OK" mechanism (see below). Unconfirmed messages simply expire and are flushed by LISTSERV, so there is no need to formally disapprove a posting. This method of message confirmation is well-suited to lists where it is not often necessary to modify the text of a posting, and also is an excellent workaround if the editor’s mail program does not generate "Resent-" headers in forwarded mail. Below is a sample of the editor-header for a list set to Send= Editor,Hold: -------------------------------------------------------------------------------- From: "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8b)" Subject: ACCESS-L: approval required (701AC4) To: Nathan Brindle This message was originally submitted by joe@unix1.foo.bar.com to the ACCESS-L list at PEACH.EASE.LSOFT.COM. You can approve it using the "OK" mechanism, ignore it, or repost an edited copy. The message will expire automatically and you do not need to do anything if you just want to discard it. Please refer to the list owner's guide if you are not familiar with the "OK" mechanism; these instructions are being kept purposefully short for your convenience in processing large numbers of messages. ------------------------ Original message (26 lines) -------------------------- -------------------------------------------------------------------------------- Figure 2.4 The editor-header for a list set to Send= Editor,Hold A final method (called "self-moderation") exists for lists where subscribers should be allowed to post freely, but non-subscriber posts should always be sent to an editor for approval. To enable self-moderation, set Send= Editor[,Hold] Editor= userid@host,(listname) Ensure that "listname" is in parenthesis. Note that self-moderation will catch all posts from non-subscribers--including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as joe@foo.com but is posting from joe@unix1.foo.com, LISTSERV will treat his mail as non-subscriber mail. Self-moderation may require some slight changes in individual user subscriptions in order for it to work seamlessly. 2.10.7. The "OK" confirmation mechanism Depending on the setting of the Validate= list header keyword, certain LISTSERV commands have always required a password for execution. However, with a recognition that mail can be forged ("spoofed") by just about anyone on the Internet today, L-Soft introduced a "magic cookie" method of command validation that is considered much more secure than passwords. In essence, the "magic cookie" method requires that the sender of the command must confirm his command via a reply containing only the text "OK". (This is actually simplistic; see below.) If mail is spoofed from the list owner’s user id, the command confirmation request will always be sent to the list owner’s user id, thus preventing the spoofer from confirming the command. Moreover, the "cookie" itself (a six-digit hexidecimal number) is registered to the "From:" user id of the original command. The general method of replying to a command confirmation request is as follows: * REPLY to the command confirmation request with the text "ok" in the body of the reply. (Non-case-sensitive) LISTSERV reads the "cookie" from the subject line and if it corresponds to a held job, the job is released and processed. If this does not work, it is possible that the Subject: line was corrupted in transit and you may need to try the following: * SEND a new message to LISTSERV with the text "ok xxxxxx" (where xxxxxx is the command confirmation number from the original confirmation request) in the body of the reply. It is also possible to confirm multiple command confirmation requests with a single message (for instance, if you have Send= Editor,Hold and have a number of requests to be responded to). This eliminates multiple "Message approved" mails from LISTSERV. However, make sure that you send the confirmations in a new mail message rather than replying to one of them. Also note that the confirmations must come from the user id that originated the command. You cannot send a command from one account and then approve it from another. ********************************************* * 3. Advertising Your Public Mailing Lists * ********************************************* 3.1. List of Lists ================== LISTSERV automatically produces a List of Lists that may be reviewed by users anywhere on the Internet via the LIST GLOBAL command. This List of Lists is made up of one-line entries containing the short listname and the descriptive title of the list (up to about 60 characters in length). A sample of the List of Lists format was shown in Chapter 2. Note that it is possible to code a descriptive title in your list header that is more than 40 columns long, but the List of Lists will include only the first 40 columns of that title. It is therefore important from this respect to be sure that the descriptive title of your list is succinct and to the point. 3.2. The INFO command and how to implement it ======================================================== Chapter 9, Customizing LISTSERV's Default Mail Templates, includes details on how to include an informative paragraph in the information mail template file for your list. When a user sends the command INFO listname to your server, LISTSERV responds with either: * The default response, which simply sends a copy of the list header to the user; or * The customized paragraph included in the .MAILTPL file. If .MAILTPL does not exist, the default response is sent. Also note that the user may send the INFO command to any L-Soft LISTSERV host (including the Global List Exchange discussed below), which will forward the request to the appropriate server. 3.3. The NEW-LIST project at North Dakota State =============================================== The NEW-LIST project was started in 1989 to promote mailing lists via a mailing list. NEW-LIST@VM1.NODAK.EDU distributes announcements of new and changed mailing lists to over 9500 subscribers every day. The NEW-LIST administration asks only that your list be well-tested and ready for new subscriptions before you send your announcement to them. You also want to make sure that your announcement is as correct and comprehensive as possible, as news on the Internet spreads quickly and a mistake in a NEW-LIST announcement may cause problems for both you and other users months later. For more information on the NEW-LIST project and what you need to use it, you can: * Gopher to vm1.nodak.edu and choose "Local LISTSERV Resources", then "NEW-LIST Project"; or * Send the command GET NEW-LIST PACKAGE to LISTSERV@VM1.NODAK.EDU. (The NEW-LIST Project also published a hard-copy version of their archive in 1992 with a newer edition in 1993 under the title Internet: Mailing Lists [ISBN 0-133-27941-3], edited by Edward T. L. Hardie and Vivian Neou.) 3.4. The Internet Network Information Center (INTERNIC) ======================================================= Unlike many other lookup services on the Internet, the INTERNIC is not necessarily free. Its three distinct sections are run by General Atomics, Network Solutions, Inc. (NSI), and AT&T. You can register your list with the INTERNIC, but be forewarned. A "basic" listing is free, while an "extended" listing is not. (On the other hand, anyone with net access can search the INTERNIC databases for free.) For more information, point a Gopher or WWW client at the INTERNIC gopher, rs.internic.net. 3.5. The Global List Exchange (GLX) and why you should mention it ================================================================= The Global List Exchange, or GLX, is a central clearinghouse for LISTSERV subscriptions and List of List requests. For instance, If a user knows the name of a list but not the name of the host server, GLX simplifies the process by giving the user a single address where all subscription requests for lists running on L-Soft's LISTSERV can be sent. By adding the GLX address in all advertisements for your list, you help other list owners as well as yourself by making it simple for users to subscribe to any list. Additionally, if for some reason a user is unable to contact your server directly, the GLX gives him an alternate subscription method. The GLX address is LISTSERV@LISTSERV.NET. 3.6. How NOT to advertise a mailing list ======================================== It is generally considered a breach of netiquette to invade the privacy of other lists with a broadcast announcement that your list is up and running. The only time when this might be acceptable is when your list addresses a concern of people already subscribed to another list. If you feel it necessary to post an announcement on someone else's list, it is good manners to first send private mail to the owner of that list and ask his or her permission to do so. (The same policy applies to USENET newsgroups, though it may be more difficult to find out who the moderator is.) It is certainly a breach of netiquette (and many networks' appropriate use policies) to blindly post multiple copies of your announcements to multiple lists. This kind of behavior is termed a "spam", something about which you may read more in Chapter 6, Moderating and Editing Lists. This kind of announcement is guaranteed to reap a good deal of bad will and may well result in the revocation of your network privileges. ****************************** * 4. Managing Subscriptions * ****************************** 4.1. How to add and delete subscribers to/from a list ===================================================== A list owner may add and delete subscribers manually. The command syntax is: ADD DELete In a perfect world, subscribers would understand intuitively how to subscribe and unsubscribe from mailing lists. Unfortunately, this is not always the case. Depending on an individual's style of list management, a list owner may choose to add or delete subscribers to the list manually, or send the potential subscriber instructions on how it is done. (See Appendix C for sample "boilerplate" instruction files that can be modified to suit local purposes.) And for lists coded Subscription= By Owner or Subscription= Closed, it is of course necessary to use the ADD command to subscribe a user. If the list is set to confirm mailing paths for new subscriptions (Subscription= Open,Confirm), it is probably wisest to use the latter option, since if a subscriber is added manually to a list, the confirmation process is bypassed. Note that should contain at least two discrete words, but it is also possible to add users without knowing the value for full_name. Simply use an asterisk ("*") character. Note that if the user is already subscribed to another list on the same host, LISTSERV will pick up the value for from its signup files. Examples are: RIGHT: ADD GOV-L vice-president@whitehouse.gov Al Gore RIGHT: ADD GOV-L vice-president@whitehouse.gov * WRONG: ADD GOV-L vice-president@whitehouse.gov Al WRONG: ADD GOV-L vice-president@whitehouse.gov Al-Gore When adding users, ADD will also accept a full RFC822 address that you can cut and paste from the "From:" line of a message. Be sure that you remove the "From:" part of the line. For example, the "From:" line From: Al Gore becomes an ADD command as follows: ADD GOV-L Al Gore 4.2. Finding users who do not appear in the list ================================================ Sometimes the list owner will get a message from a subscriber who says, in essence, "I keep trying to (unsubscribe/change to digest/etc.) and LISTSERV says I'm not subscribed. Can you help?" This requires some detective work. There are a couple of strategies for figuring out what is wrong. List owners should first use the powerful SCAN command to search for a pattern anywhere in the subscriber list. The syntax is: SCAN For instance, "SCAN TEST-L Nathan" might return: > scan test-l Nathan Nathan Brindle Somebody Else Jonathan Smith SCAN: 3 matches. Note that SCAN is not case-sensitive. "Nathan", "NATHAN", and "nathan" all return the same results. Searches with SCAN should start out simple and become more complex as needed. For instance, if there are only three people in the list with the string "NATHAN" as part of their subscription record, it will be unlikely that you will need to make the search any more complex. If you are looking for "SMITH", however, it may be necessary to further qualify your search string, say to look for "JOE SMITH". Another reason it is important to begin with a simple search string is that your user may not be subscribed under the exact address the error is returning to you. For instance, say you don't have the user's id, but you have a host name. You can search for all occurrences of the host name, but note that the search: SCAN TEST-L MAIL.FOO.BAR.COM will not find the user jsmith@foo.bar.com. If you run the following search: SCAN TEST-L BAR.COM however, you will find Mr. Smith's subscription. Another possibility is that the subscriber may be using more than one address to work with his subscription. For instance, say the user's complaint to you came from JOE@SUN6.SOMEUNI.EDU. Looking at the list, you find a subscription for JOE@SUN8.SOMEUNI.EDU. LISTSERV has no way to know that JOE@SUN6 is the same person as JOE@SUN8, even though Joe and you know they are. The solution to Joe's problem above is for you to delete his SUN8 subscription and add his SUN6 address. Then Joe needs to be sure that he uses SUN6 in the future, if not for reading mail, then at least for managing his own subscription. Another strategy would be to submit a wildcard QUERY to the list. The drawback to this method is that it might require multiple tries to find the subscription, depending on the complexity of the wildcard query. Note also that not only can this sort of problem arise from a subscriber using more than one workstation to read mail, but it can also arise when a particular site changes its domain configuration, forwards mail from the old addressing scheme to the new addressing scheme, and doesn't inform its users of the change. In these cases, users often don't realize there is a problem until they try to unsubscribe or change personal options, because the change has been transparent to them. 4.3. Converting mailing lists to LISTSERV from other systems ============================================================ If you are moving a list from a non-LISTSERV site, you can quickly and easily convert the existing list file to the LISTSERV format by following these instructions: 1. Have the LISTSERV maintainer at your new site create the new list header and install it on the machine. 2. Create an add job as follows: QUIET ADD listname DD=X IMPORT //X DD * /* where "listname" is the name of the new list, and "user1", "user2" and other users are the entries from the original list that you want to add to the new list. (You should remove any lines from the original list that do not actually identify subscriber addresses.) 3. Send the job to LISTSERV. The IMPORT option speeds up the operation of adding many subscribers "in bulk" at one time by causing LISTSERV to omit success messages and to relax syntax checking. 4.4. Using the QUIET option with commands ========================================= Prepending the command word "QUIET" before any LISTSERV command that you issue on behalf of a subscriber causes LISTSERV to suppress any notification to the subscriber of the changes you have made. This is particularly helpful when deleting subscribers whose accounts have expired and when setting subscribers with full mailboxes to NOMAIL, as it will help avoid another error message from the host when the notification message bounces. It is also helpful when adding subscriptions to the list that should not receive any welcome mail, such as redistribution lists and USENET newsgroups. Examples of the usage of QUIET include: QUIET ADD EXCEL-L comp.spreadsheets.excel@netnews.somenode.edu QUIET DELETE EXCEL-L Bouncemeister@somenode.edu 4.5. Dealing with bounced mail ============================== 4.5.1. What is a bounce, and what can typically cause one? ---------------------------------------------------------- A bounce is simply an undeliverable e-mail message. The term "bounce" is used to describe it because normally the system that discovers the delivery error "bounces" a copy of the message back to you with some sort of delivery error message. Sometimes these messages are easy to decipher - "No such user at foo.bar.com" - but uncomfortably often they are not that easy. Certain systems, as noted above, kindly format error notifications in a format that LISTSERV can understand, and if your list is configured for auto-deletion, these bounces will be the least of your worries - in fact, they will not be worrisome at all. 4.5.2. What to do about several types of bounces ------------------------------------------------ Here are a few of the typical mail errors you will have to deal with as a list owner: 1. no such user at host Most of the time, this is authoritative and indicates that the user's access has been curtailed for some reason (graduation, no longer employed, etc.). A quiet delete (syntax: "QUIET DELETE ") is in order unless you have reason to believe that the message is not authoritative. 2. no such host This is sometimes authoritative and sometimes not. If a host goes down or a gateway fails, often this message is returned by an intermediate host or gateway. If the user is bouncing a great deal of mail from a high-volume list, it is probably best to set the user to NOMAIL (syntax: "SET listname NOMAIL FOR userid@host") rather than to summarily delete him. This way, the error messages stop, the user is sent an automatic message telling him his personal options have been changed by the list owner, and the user doesn't have to go through the subscription process again if the problem has been solved in the interim. The problem is that some hosts go down on a regular basis and this error makes it impossible to tell if the host in question is gone forever or gone until the local sysadmin reboots his machine. After a while, you will begin to recognize the transient hosts and may elect to ignore them. If you choose to set the user to NOMAIL, you should send a message to the user just in case the system has come back up, and you should keep some sort of record of the users you've set this way so you can follow up later with another message. 3. no MX or A records for host Similar to "no such host". Comes from a different lookup system, and generally means the same thing. 4. Transient failure: cannot deliver for days A host is experiencing periodic failures, and the gateway or intermediate host will store the message for n days and attempt redelivery. Usually there is nothing wrong with the user address, so it is a list owner decision as to whether it is worth waiting out the transient failure or going ahead and setting the user to NOMAIL. Unfortunately, by the time you get this message, the failure is n days in the past, the "transient failure" is very probably over, and you are likely to receive further error messages for n more days until the intermediate host's queue is exhausted. 5. mailbox full Self explanatory. This usually happens on systems with tiny user mailbox space, but it can happen on any system if a user subscribes to too many lists or goes on an extended vacation without setting lists to NOMAIL. The best solution is to set the user to NOMAIL yourself. Variations on this message include VMS's "file extend failed writing to [disk.user]MAIL.MAI". 6. unknown mailer error x This is a favorite Unix sendmail configuration bounce. NOMAIL or DELETE, according to your preference. Since it is a configuration problem, it is usually transient. One system sent the following under an "unknown mailer error 1" heading: binmail: /usr/spool/mail/userid: too big to accept new messages. It's size is 205735 bytes which is 935 bytes over quota. mail: cannot open dead.letter 554 ... unknown mailer error 1 This is apparently a "mailbox full" error, as "userid's" mail spool is "over quota". It is also possible that it means your message would put the user over quota by 935 bytes. Either way, there isn't enough space in the user's mailbox to store your message (in this case, it was a daily digest). Note that "unknown mailer error x" does not always mean the user's mailbox is full - what it always means is that sendmail cannot identify the cause of the error. A particularly annoying error you may have to deal with comes from Banyan networks and is of the form: LLONG@StarShip@Dora: Mailbox full Obviously this is not a properly-configured address (at least, not as far as LISTSERV is concerned), and if you SCAN or QUERY the list for it, you will get a negative response. If, however, you SCAN the list for LLONG, you may find a user such as: > scan test-l LLONG Bill Smith SCAN: 1 match. This user can now be set to NOMAIL and the errors will stop after the Banyan host has emptied its queue. If you do not find the user on the first SCAN, try using another part of the address as your search text. Note that a user may have his mail forwarded from the account that is actually subscribed to an account on another machine where he reads his mail. If the second machine is bouncing the mail, it may not be immediately apparent from the bounce messages that the mail is actually being forwarded. It is important to check for variants of the userid in the bounce message as it may be related to the userid that is actually subscribed to the list. Note that there are many forms of error messages. Many mail systems do not conform to Internet "standards" (some of them even return non-English error messages!) and LISTSERV's auto-deletion feature will not always catch their bounces. 4.5.3. Redistribution and forwarding ------------------------------------ Perhaps the worst type of bounce is one that comes from a user who is "hiding" behind an account that redistributes mail (a "redistribution list"), or a user whose Internet address has changed slightly but who is still subscribed to your list under his original address. Redistribution lists typically (but not always) take some form of your list's name (such as "xxxxx-L-REDIST@foo.bar.com"), and thus their subscriptions tend to be easy to find. What is difficult is that you have no way of knowing which users (or how many users) are hidden behind this interface, nor any way of knowing what their userids are. Forwarded accounts generally fall into one of two categories - those where the user has forwarded his own mail from one account to another rather than changing his subscription, and those where the user's system name has changed and the old address is still valid but is forwarding mail to the new address without the user being aware of it. Let's say that suddenly you are bombarded with delivery errors for someuser@baz.net. Your immediate reaction is to set this person to NOMAIL or (in some cases) to delete him/her altogether. You therefore send set xxxxx-L nomail for someuser@baz.net to LISTSERV. LISTSERV responds: "No subscription for someuser@baz.net in list XXXXX-L." In a best-case scenario, you can query the list for *@*.baz.net and find either a user like someuser@glork.baz.net (the address has changed and the local sysadmins didn't inform the user) or a redistribution-list account like xxxxx- L@baz.net. These are easily-fixed redistribution bounces. In the first case, you delete the user and let him or her resubscribe. In the second case, you can try sending a message to owner-xxxxx-l@baz.net with a cc: to postmaster@baz.net and inform them of the problem. If it persists, you could send a further message informing them that you are suspending the redistribution list's subscription until such time as they tell you the problem on their end is fixed, and simply set xxxxx-l@baz.net to NOMAIL. The worst-case scenario is as follows: baz.net may be bouncing the mail to you, but there may not be a single subscription for baz.net in your list. Here's where you have to do some careful sleuthing. First, run a wildcard query such as QUERY xxxxx-l FOR *@*baz* or QUERY xxxxx-l FOR *baz*@*. The former will find users at baz.com, for instance, where baz.net is a synonym for baz.com. The latter query may seem somewhat strange, but it's possible that the mail is being routed through a gateway and the actual subscription is for xxxxx- l%baz.net@cunyvm.cuny.edu or something of that sort. 4.6. Automatic and semi-automatic deletion ========================================== LISTSERV supports several levels of automatic deletion based on error messages passed back to it in LMail format by certain remote systems. While auto-delete will not solve all of your bouncing mail problems, it has the potential to take care of most "permanent" errors (including "no such user" and "no such host"). However, note that auto-delete ignores "temporary" errors such as "host unreachable for 3 days", "system error", "disk quota exceeded", and so forth, such that users whose accounts generate "temporary" errors are not summarily deleted from the list. By default, lists running under LISTSERV 1.8b and higher generate a report which lets the list owner know what userids are causing problems, rather than deleting users at the first error LISTSERV understands. If the Delay() and Max() parameters are set to non-zero values for a list coded "Auto-Delete= Yes", LISTSERV will not take immediate action on mail delivery errors. You will receive an "auto-deletion monitoring report" daily to show you which subscribers are bouncing mail, what the error is, when it started, when the last error arrived, and how many errors have been received for the subscriber in total. By default, LISTSERV will wait 4 days (or for a maximum of 100 error messages per individual user) before deleting a subscriber. If you code "Delay(0)", LISTSERV will not wait to take action, but will delete the subscriber at the first error LISTSERV understands. By default, lists with "Validate= All" are set "Auto-Delete= No", while all other lists are set "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)". Implementation of the "Auto-Delete=" keyword is discussed in detail in Appendix B, List Keyword Alphabetical Reference, under "Error Handling Keywords." 4.6.1. Auto-Delete considerations for holidays ---------------------------------------------- Making a big increase to the DELAY threshold to provide more leniency during a holiday may not be a good idea. While it will indeed disable the monitor for the duration of the holiday, switching back to the normal threshold when you return will cause the monitor to delete all the users that had been bouncing during the holidays. In general, you should avoid making temporary changes to the DELAY threshold, because it takes the monitor a while to adapt to the new settings. The best way to relax the rules during a long holiday is to leave the DELAY threshold unchanged but switch the monitor to passive mode ("Auto-Delete= Yes,Manual"). Noone will be deleted over the holidays, but the monitor's cycle will not be perturbed. When you return, you should wait about a week before switching back to automatic mode. This is because, after a long holiday such as Christmas, it usually takes about 2 working days for system administrators to solve all problems. In some cases, the problems will have caused bounces to remain undelivered. So, by fixing the problems, the system administrators may actually send a flood of new bounces corresponding to problems that have now been solved. Unfortunately, since the monitor only receives NON-delivery reports, it has no way to know that these problems have in fact been solved. As a rule of thumb, you will note that your daily delivery error reports are much longer than usual over the vacation. When you return, you should wait until they are back to their normal size before switching back to automatic mode. 4.7. Subscription confirmation ============================== For lists coded "Subscription= Open", you can require confirmation on all new subscription requests, thus ensuring that LISTSERV has a clear mailing path back to the subscriber. In the past, a user could send a subscription for an open subscription list to LISTSERV, which upon acceptance would immediately start sending the user list mail. If the user was located behind a "broken" or one-way gateway, this produced immediate bounced mail until the list owner noticed and deleted the subscription. Note that requiring confirmation at the time of subscription does not guarantee that the clear mailing path will continue to exist permanently. "Subscription= Open,Confirm" causes LISTSERV to send a Command Confirmation Request to the potential subscriber before actually adding the user to the list. The subscriber is requested to reply to the request by sending a validation "cookie" back to LISTSERV (this "cookie" being the hexidecimal number pulled from the subject line). The Command Confirmation Request, while straightforward, has the potential to cause confusion if users do not read carefully the instructions that make up the request. LISTSERV expects confirmation codes to be sent in a specific way because some mail gateways add lines to the header of the message that LISTSERV doesn't understand. If a user forwards the request back to LISTSERV, or creates a new mail message to send the 'cookie' back, it usually will not work correctly. The sequence should thus be as follows: 1. SEND the subscription request to LISTSERV. 2. REPLY to the confirmation request ('ok') 3. SEND the confirmation code (if necessary) ('ok 23CBD8', for example) 4. Send mail to the list owner (not to the list) if the subscription request fails after step 3. Note that if a list owner adds a user manually, the confirmation process is bypassed. 4.8. Subscription renewal ========================= You can code subscription renewal into your lists. This is one method to keep lists "pruned down" and avoid having large lists that are actually distributing mail to only a fraction of the users. For instance, you may have a number of subscriptions set to NOMAIL for one reason or another. NOMAIL user(a) may have forgotten that he has a subscription; user(b) may have set NOMAIL instead of unsubscribing; user(c) may no longer exist because she graduated or no longer works for the service provider; you may have set user(d) to NOMAIL because of recurrent mail delivery errors. Requiring a periodic confirmation of subscriptions is therefore a reasonable course of action for large, non-private lists. To add subscription renewal, you add the following keyword to the header of your list: * Renewal= or * Renewal= ,Delay() where is a period of time such as Weekly, Yearly, 6-monthly, or something similar, and Delay() is an integer corresponding to how many days LISTSERV will wait for the renewal confirmation to arrive. (See Appendix B for more information on renewal and delay periods.) The confirmation request mailing asks the subscriber to send the command CONFIRM listname back to LISTSERV. If the subscriber does not do so within a certain length of time, LISTSERV automatically deletes the subscription. The default delay time is 7 days. If you wish to use the default delay time, it is not necessary to code Delay() into your Renewal parameters. Note: You may wish to increase the delay time to accommodate users whose subscriptions expire over holidays (such as the Christmas/New Year's week) in order to avoid accidental deletions. Also, be aware that confused subscribers can and will send the CONFIRM command back to the list, rather than to LISTSERV. LISTSERV's default filter will catch these commands and forward them to the userid(s) defined by the "Errors-To=" keyword. It is possible to waive subscription renewal for certain users (such as list owners, editors, redistribution lists, etc.). In order to do this, simply issue the command [QUIET] SET NORENEW FOR to LISTSERV. It is most advisable to do this in the case of redistribution lists, as they broadcast the renewal notice to their users, who a) cannot renew the subscription and b) become very confused when they see the notice, often sending "what does this mean?" mail to the list. You can also issue the CONFIRM command for a subscriber: [QUIET] CONFIRM FOR 4.9. The SERVE command ====================== If a user sends more than 21 consecutive invalid commands to LISTSERV, LISTSERV automatically serves that user off so that further commands from that user will be ignored. Should a user become served off in this fashion, it is possible for the list owner or any other user to issue a SERVE net-address command to restore that user's access. As with all other LISTSERV commands, the SERVE command is sent to LISTSERV. While served off, the user will be unable to set personal options and will be unable to subscribe or unsubscribe to lists on that server. Note that a user will likely be served off of one particular LISTSERV site but not others, and also that the user may not even realize that he has been served off (in spite of the fact that LISTSERV sends notification to the user to that effect). Note that the SERVE command will not restore service to users who have been manually served off by the LISTSERV maintainer. 4.10. "Peering" large lists =========================== Occasionally the need to split a very large list may arise. This was more common when LISTSERV ran only on BITNET, whereas the TCP-IP version of LISTSERV is not limited by BITNET constraints. However, because of the fact that subscribers may be scattered all over the world, in rare cases it can make sense to split (or "peer") a list and share the mail load among 2 or more LISTSERV servers. Peering also makes it possible to have list archives located in more than one place; for example, a list might be peered between a European host and a North American host, making it possible for subscribers on each continent to retrieve archives from the nearer host. You should ALWAYS contact the LISTSERV maintainer before deciding to link your list to another LISTSERV. Although there is no problem about linking to another L-Soft LISTSERV list, linking to a non-L-Soft mailing list manager is not supported and will cause serious problems (including mailing loops) for which L- Soft international, Inc. could not be held responsible. After the link operation has been completed, it is recommended that you define "Peers=" keywords on lists you just linked. For lists running on LISTSERV for VM, this makes it possible to EXPLODE them for better network efficiency. (Because peering is not widely used today, it is unlikely that the EXPLODE command will be ported to other platforms.) 4.10.1 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: 1. Send mail to the list telling people that a new peer server is being linked to the list, and that some subscribers will be moved to it. 2a. If the prerequisites for using the MOVE command are met, you should use either individual MOVE commands (in the case that there are very few users to move) or a batch-MOVE command with associated DDname (see the LISTJOB MEMO guide for more information on commands-jobs) to move the users. You may want to use the QUIET option to suppress notification if there are a lot of users to move. Warning: the MOVE command should not be used to move peer list servers. See the MOVE command description for more details. If you cannot use the MOVE command, you should try one of the following two methods: 2b. For each user to be moved, issue the following commands in the following order: * Query FOR (old server), write down the options. * QUIET ADD * QUIET SET options FOR * Wait until you get confirmation for the two previous commands * QUIET DELete (old server) 2c. If there are a lot of users to move, the following method is preferred: * GET (old server) * GET (new server) * If you are using VM XEDIT: Receive both files and use the XEDIT "PUT" and "GET" commands to move users from one list to the other. You must preserve the contents of columns 81-100 across the move. * If you are using another text editor: Make sure that the editor you are using does not "imbed" control codes such as line breaks, tabs or word- wrapping characters into the text when you edit it. (For instance, if you are using Notepad in Microsoft Windows, ensure that "Word Wrap" is turned off.) Use the cut and paste controls to copy lines in their entirety. You must preserve the contents of columns 81-100 across the move. Imbedded control codes and/or word wrap will generate errors when the list is stored back on the server. * Store the two lists back on their respective servers. 4.10.1 Special commands for peered lists only --------------------------------------------- ADDHere [PW=] The ADDHERE command is strictly identical to ADD, with the exception that the placement of the user is not checked against the list of peer servers, i.e. the specified user is added to the local list without any further verification. (By comparison, the ADD command causes LISTSERV to check automatically to see if there is no better-suited peer list for the specified user.) EXPLODE [F=] [VM only] The EXPLODE command provides a means whereby a list can be automatically analyzed by LISTSERV to optimize the placement of its recipients over the various peer servers hosting the list. It requires a "Peers=" keyword to be defined in the list header (see Appendix B). Non-BITNET userids will be exploded according to the network address of the corresponding gateway (as per the SERVICE NAMES file), or ignored if the gateway could not be identified. LISTSERV will create a commands-job file containing the necessary MOVE command to transfer all the users which were found to be (possibly) mis-allocated to the peer server which is nearest to them. This file will then be sent to you so that you can review it before sending it back to the server for execution. MOVE [PW=] DD= [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. **************************************************** * 5. Setting Subscription Options For Subscribers * **************************************************** 5.1. How to review current subscription options with QUERY ========================================================== The syntax is similar to the subscriber's method of reviewing his options, except that the list owner must specify for whom the options are being checked. Query FOR Note that it is possible to use wildcards in the subscriber address. For instance, Q LSTOWN-L FOR J*@UBVM* will return option listings for subscribers such as JIMJ@UBVM, JOHN@UBVMS.CC.BUFFALO.EDU, etc. This can be handy if you are searching the list for someone whose subscription address differs from the address you are given in an error report (see the examples, above, in "Dealing with bounced mail"). Using the WITH qualifier, you can also query a list for users who have a specific option set. For instance, you might want to know which users are set to NOMAIL. Send the command Q WITH NOMAIL FOR *@* and LISTSERV will return a list of those users. It is also possible to query a list for multiple options: Q with DIGEST CONCEAL FOR *@* will return a list of those subscribers who have set their subscription to DIGEST and also to CONCEAL. 5.2. How to set personal subscription options for subscribers ============================================================= Again, the syntax is similar to the subscriber's method. [QUIET] SET