WPC4 2BJv Zp|xTimes New Roman (TT)Times New Roman (TT)Symbol (TT)Arial (TT)CourierArial (TT)TimesHelveticaCourier New (TT)Line Printer 16.67cpiCG Times (Scalable)Univers (Scalable)Univers Condensed (TT)Antique Olive (TT)Garamond (TT)CG Omega (TT)Clarendon Condensed (Bold) (TT)Wingdings (TT)Arial Narrow (TT)Book Antiqua (TT)Bookman Old Style (Light) (TT)Century Gothic (TT)Century Schoolbook (TT)Monotype Corsiva (Italic) (TT)Monotype Sorts (TT)MS LineDrawAlgerian (TT)Arial Rounded MT Bold (Bold) (TT)Braggadocio (TT)Britannic Bold (Bold) (TT)Brush Script MT (Italic) (TT)Colonna MT (TT)Desdemona (TT)Footlight MT Light (Light) (TT)Impact (TT)Kino MT (TT)Wide Latin (TT)Matura MT Script Capitals (DemiBold) (TT)Playbill (TT)Stencil (TT)RomanScriptModernITC Avant Garde Gothic BookHelvetica-NarrowNew Century SchoolbookPalatinoITC Zapf Chancery Medium ItalicITC Zapf DingbatsC\  P6QPC\  P6QP,a\  P[AP9J2PQPEd6X@C@MJ2PQPYC\  PUP_`2PkCPid6X@DQ@HH{H H@;@c P7PixP7P%5P6QPFP{2QP}Vi P1QP1%YkP2QP5  p$Q#r P?pQP3<xzP"@QPFJz PQPYB  0*Q0yQ^P-0QPM P:+QP;6B>Hxx'QX}'' PV/QPSL7 @Q@HUP73QPAopL1 QXM6PhQP,^4pQ^H+ @xćQXg8. 0Q^0x=fP7bQP7O 0Q07KtPF QP-E 9PX6QPnJx PQP9x @P%Qp!uP:QPJ PRQPK\  P@QP#9 @HxUX*Ct0n U01d^P)CPMNxzPCP^e P['CPubX  Pg9CP~S*6j Hxg#CX''=PuP2?; phoenix#XP\  P6QXP# List Owner's Manual for LISTSERV Version 1.8a Nathan BrindleNathan BrindleCopyright (c) 1994, L-Soft International, Inc.2D|lZheading 1heading 1A7#XX2PQXP#  #XP\  P6QXP#heading 2heading 2>4#XX2PQXP# #XP\  P6QXP#heading 3heading 3  Default Paragraph FoDefault Paragraph Font 2vrnNormal IndentNormal Indent endnote referenceendnote reference footerfooter` hp x (#!!!!` hp x (#headerheader` hp x (#!!!!` hp x (#2Z! N    footnote referencefootnote reference 44#W\  P6QP##XP\  P6QXP#footnote textfootnote text ;1#B2PQP##XP\  P6QXP#EMailEMail ;1#d6X@DQ@##XP\  P6QXP#Research PaperResearch Paper ;1#Xx6X@DQX@##XP\  P6QXP#2$ !V"##Header 1Header 1 >4#g2PQP# #XP\  P6QXP#Body Text CenteredBody Text Centered;1#I2PQP##XP\  P6QXP#Body Text LeftBody Text Left;1#I2PQP##XP\  P6QXP#Section HeadingSection Heading>4#g2PQP# #XP\  P6QXP#2($%z&>'Section SubHeadingSection SubHeadingA7#XX2PQXP#  #XP\  P6QXP#Body SubHeadBody SubHeadA7#I2PQP#  #XP\  P6QXP#CommandsCommands;1#d6X@DQ@##XP\  P6QXP#Body Text IndentedBody Text Indented;1#I2PQP##XP\  P6QXP#2,4()l):,Dictionary HeaderDictionary HeaderA7#g2PQP#  #XP\  P6QXP#Dictionary SubHeadDictionary SubHead>4#g2PQP# #XP\  P6QXP#IndexIndex` hp x (#4 <DL!#B2PQP##XP\  P6QXP#4 <DL!` hp x (#FigureCaptionFigureCaption;1#B2PQP##XP\  P6QXP#2L00--./Code Example 2Code Example 2>4#P6X@DQ@# #XP\  P6QXP#Code Example 1Code Example 1>4#d6X@DQ@# #XP\  P6QXP#Bulleted ListBulleted List;1#I2PQP##XP\  P6QXP#Bulleted List IndentBulleted List Indent;1#I2PQP##XP\  P6QXP#263~0B12 l2Body Text Indented 2Body Text Indented 2;1#I2PQP##XP\  P6QXP#Bulleted List IndentBulleted List Indent 2;1#I2PQP##XP\  P6QXP#Body Text Hanging InBody Text Hanging Indent;1#I2PQP##XP\  P6QXP#page numberpage number 2!h3""4annotation referenceannotation reference!11#6\  P6QP##XP\  P6QXP#annotation textannotation text";1#C\  P6QP##XP\  P6QXP# XX   ]header` hp x (#!!!!!! #6\  P6QP# header!! 4 <DL!#;2PQP# 4 <DL!4 <DL!#XP\  P6QXP#] footer` hp x (#!!!!!!  footer!! 4 <DL!  Header 1#g2PQP# LSoft international, Inc. List Owner's Manual for LISTSERV#_2PQP#TM#g2PQP#, version 1.8b  Header 1#Body Text Centered##I2PQP# August 14, 1995 Revision 1 )Body Text Centered)Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%4 <DL!4 <DL!#XX2PQXP#The reference number of this document is 9505UD02. Wheader` hp x (#!!!!!! #6\  P6QP# header!! 4 <DL!#XP\  P6QXP#Wfooter` hp x (#!!!!!! #;2PQP#List Owners Manual for LISTSERV) version 1.8b footer!! 4 <DL!#XP\  P6QXP#ыHheader` hp x (#!!#XP\  P6QXP# header!!4 <DL!Hfooter` hp x (#!!#;2PQP#List Keyword Alphabetical Reference for LISTSERV) version 1.8b #XP\  P6QXP# footer!!4 <DL!бBody Text Left#I2PQP#4 <DL!4 <DL! #;2PQP#ёInformation in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. LSoft 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 LSoft international, Inc. #I2PQP#Copyright  1995, LSoft international, Inc. All Rights Reserved Worldwide. #;2PQP#LSOFT, LISTSERV and LMail are trademarks of LSoft 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 HewlettPackard 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. #I2PQP# #B2PQP#All of LSoft's manuals for LISTSERV are available in asciitext format via LISTSERV and in popular wordprocessing formats via #Z6X@DQ@# ftp.lsoft.com #B2PQP#. They are also available on the World Wide Web at the following URL: #Z6X@DQ@# URL: http://www.lsoft.com/manuals/index.html #B2PQP#LSoft invites comment on its manuals. Please feel free to send your comments via email to #Z6X@DQ@# MANUALS@LSOFT.COM #B2PQP#. #;2PQP# Reference Number 9505UD02%Body Text Left% Section Heading #g2PQP# ۑ Table of Contents &Section Heading&4 <DL!!`#XX2PQXP#Preface: LISTSERV Command Syntax ConventionspPreface1 1.p About Mailing Lists and LISTSERV#2PQP#)#XX2PQXP#Chapter12 2.p Starting a Mailing List ! The BasicsChapter23 !`4 !#&Q2PQ&P#2.1.pAvoid duplication of effort 2.2.pWhat skills do I need to start and maintain a LISTSERV mailing list? 2.3.pCreating a mailing list ! Where can it be done, and Who can do it? 2.4.pList Header Keywords and what they do 4 ! !2.4.1.pAccess Control Keywords 2.4.2.pDistribution Keywords 2.4.3.pError Handling Keywords 2.4.4.pList Maintenance and Moderation Keywords 2.4.5.pSecurity Keywords 2.4.6.pSubscription Keywords 2.4.7.pOther Keywords  !4 !2.5.pRetrieving and editing the list ! some considerations 2.6.pAdding a list password 2.7.pStoring the list on the host machine 2.8.pFixing mistakes 2.9.pA sample list header file 2.10.pSecurity options 4 ! !2.10.1. First line of defense: The VALIDATE= keyword 2.10.2pControlling subscription requests 2.10.3pControlling the service area of your list 2.10.4pControlling who may review the list of subscribers 2.10.5pControlling who may access the notebook files 2.10.6pControlling who may post mail to the list 2.10.7pThe OK confirmation mechanism  !4!` 4!`!`#XX2PQXP# 3.p Advertising Your Public Mailing ListsChapter315 !`4 !#&Q2PQ&P#3.1.pList of Lists 3.2.pThe INFO command and how to implement it 3.3.pThe NEWLIST project at North Dakota State 3.4.pThe Internet Network Information Center (INTERNIC) 3.5.pThe Global List Exchange (GLX) and why you should mention it 3.6.pHow NOT to advertise a mailing list 4 !4 !#XX2PQXP# 4 !!` 4.p Managing SubscriptionsChapter417 !`4 !#&Q2PQ&P#4.1.pHow to add and delete subscribers to/from a list 4.2.pFinding users who do not appear in the list 4.3.pConverting mailing lists to LISTSERV from other systems 4.4.pUsing the QUIET option with commands 4.5.pDealing with bounced mail 4 ! !4.5.1.pWhat is a bounce, and what can typically cause one? 4.5.2.pWhat to do about several types of bounces 4.5.3.pRedistribution lists and why they may cause you migraines  !4 !4.6.pAutomatic and semiautomatic deletion 4.7.pSubscription confirmation 4.8.pSubscription renewal 4.9.pThe SERVE command 4.10.p"Peering" Large Lists 4 !!`#XX2PQXP# 5.p Setting Subscription Options For SubscribersChapter528 !`4 !#&Q2PQ&P#5.1.pHow to review current subscription options with QUERY 5.2.pHow to set personal subscription options for subscribers 5.3.pOptions that may be set 4 ! !5.3.1.pMail/NOMail 5.3.2.pDIGest 5.3.3.pINDex 5.3.4.pACK/NOACK/MSGack/NONE 5.3.5.pOptions for mail headers of incoming postings 5.3.6.pCONCEAL/NOCONCEAL 5.3.7.pREPro/NOREPro 5.3.8.pTOPICS 5.3.9.pPOST/NOPOST 5.3.10.pEDITOR/NOEDITOR 5.3.11.pREVIEW/NOREVIEW 5.3.12.pRENEW/NORENEW  !4 !5.4.pSetting original default options with the DefaultOptions= keyword 4 !4 !#XX2PQXP# 4 !!` 6.p Moderating and Editing ListsChapter632 !`4 !#&Q2PQ&P#6.1.pList charters, welcome files, and administrative updates 6.2.pThe role of the list owner as moderator 6.3.pThe role of the list owner as editor 6.4.pSetting up an edited list 6.5.pSubmitting subscriber contributions to an edited list 6.6.pMessage approval with Send= Editor,Hold 6.7.pUsing list topics 6.8.pThe listname WELCOME and listname FAREWELL files 4 ! !6.8.1.pCreating and storing listname WELCOME and FAREWELL files 6.8.2.pUsing the listname WELCOME file as a moderation tool 6.8.3.pUsing the listname FAREWELL file as a feedback tool 6.8.4.pThe alternative to using WELCOME and FAREWELL files  !4 !6.9.pSocial conventions (netiquette) 6.10.pSpamming: what it is, and what to do about it 6.11.pAppropriate use policies: considerations 4 !4 !#XX2PQXP# 4 !!` 7.p Overview of List ArchivesChapter742 !`4 !#&Q2PQ&P#7.1.pWhat is the list archive? 7.2.pSetting up and managing archive notebooks 7.3.pDatabase Functions Overview 7.4.pWhere to find more information on Database Functions 4 !4` !#XX2PQXP# 4` !!` 8.p Overview of File ArchivesChapter845 !`4 !#&Q2PQ&P#8.1.pWhat is the file archive? 8.2.pStarting a filelist 8.3.pFilelist maintenance 8.4.pGiving other users access to files 8.5.pStoring files on the host machine 8.6.pAutomatic File Distribution (AFD) and File Update Information (FUI) 8.7.p"File Packages" 8.8.pWhere to find more information on File Archives 4 !!`#XX2PQXP# 9.p Customizing LISTSERV's Default Mail TemplatesChapter952 !`4 !#&Q2PQ&P#9.1.pWhat LISTSERV uses mail templates for 9.2.pThe DEFAULT.MAILTPL file and how to get a copy 9.3.pMail template format and embedded formatting commands 9.4.pCreating a .MAILTPL file for a list 9.5.pStoring the .MAILTPL file on the host machine 9.6.pOther template files: DIGESTH and INDEXH 4 !!`#XX2PQXP# 10.p Gatewaying to USENETChapter1061 !`4 !#&Q2PQ&P#10.1.pWhy would I want to? 10.2.pHow to go about it 10.3.pSpecial considerations and problems with gatewaying 4 !4 !#XX2PQXP# 4 !!` 11.p Solving ProblemsChapter1162 !`4 !#&Q2PQ&P#11.1.pHelping subscribers figure out the answers 11.2.pLoopchecking can cause occasional problems with quoted replies 11.3.pBroken and/or unhelpful mail servers 11.4.pBroken and/or oneway gateways 11.5.pFirewalls 11.6.pIf I can't find the answer, where do I turn? 11.7. pLSTOWNL@SEARN and LSTSRVL@UGA ! two other places to get help 4 !4 !#XX2PQXP# 4 !" !` Appendix A: pSystem Reference Library for LISTSERV#2PQP#)#XX2PQXP# version 1.8bAppendixA65 Appendix B: pList Keyword Alphabetical Reference for LISTSERV#2PQP#)#XX2PQXP# version 1.8bAppendixB72 Appendix C: pSample Boilerplate FilesAppendixC96 Appendix D: pRelated Documentation and SupportAppendixD99 Appendix E: pAcknowledgmentsAppendixE101 " !`4 <DL!Б Section Heading #g2PQP# #XX2PQXP#(this page left intentionally blank) &Section Heading& =  &Section Heading&footer` hp x (#!!!!!! #;2PQP#List Owners Manual for LISTSERV) version 1.8b, Page  footer!! 4 <DL!#XP\  P6QXP#&Section Heading&footer` hp x (#!!#;2PQP#Page , List Owners Manual for LISTSERV) version 1.8b #XP\  P6QXP# footer!!4 <DL!#g2PQP# LSoft international, Inc. &Section Heading& Header 1#g2PQP# List Owner's Manual for LISTSERV#_2PQP#TM#g2PQP#, version 1.8b  Header 1#Body Text Centered##I2PQP#August 14, 1995 Revision 1 )Body Text Centered)Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%#Body Text Centered##I2PQP#4 <DL!4 <DL! Copyright  1995, LSoft International, Inc. All Rights Reserved Worldwide )Body Text Centered)Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%The reference number of this document is 9505UD02. Body Text Left#I2PQP# %Body Text Left% Section Heading #g2PQP#  Preface: LISTSERV Command Syntax Conventions Preface  &Section Heading&Body Text Left#I2PQP# Generally, parameters used in this document can consist of 1 to 8 characters from the following set: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!AZ 09 $#@+_:#I2PQP# #d6X@DQ@# %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! Deviations from this include:#d6X@DQ@# 4 <DL!4 <DL!fformat #I2PQP##d6X@DQ@# Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail #I2PQP# #d6X@DQ@# full_name #I2PQP#first_name [middle_initial] surname (not your email address) #d6X@DQ@# listname #I2PQP#name of an existing list #d6X@DQ@# node #I2PQP#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 fullyqualified domain name (FQDN) of an Internet host. #d6X@DQ@# pw #I2PQP#a password containing characters from the set: #d6X@DQ@# AZ 09 $#@_?!|% userid #I2PQP#Any valid RFC822 network address not longer than 80 characters; if omitted, the 'hostname' part defaults to that of the command originator 4 <DL!4 <DL!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: 4 <DL!4 <DL! #d6X@DQ@# italic type #I2PQP#always indicates required parameter names that must be replaced by appropriate data when sending commands to LISTSERV < >Angle brackets may sometimes enclose required parameter names that must be replaced by appropriate data when sending commands to LISTSERV. Sometimes used for clarity when italic type is inappropriate [ ]Square brackets enclose optional parameters which, if used, must be replaced by appropriate data when sending commands to LISTSERV %Body Text Left% Section Heading #g2PQP# 4 <DL!4 <DL! 1. About Mailing Lists and LISTSERV Chapter1  &Section Heading&Body Text Left#I2PQP# 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#_2PQP#TM#I2PQP#, unix and Windows NT#_2PQP#TM#I2PQP#, and has already been ported to Windows 95#_2PQP#TM#I2PQP# (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. %Body Text Left% Section Heading #g2PQP# ۑ2. Starting a Mailing List ! The Basics Chapter2  &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL! 2.1. Avoid duplication of effort)Section SubHeading)# footnote reference##W\  P6QP#X0X01 Í  Í w)Section SubHeading) footnote text#W\  P6QP## footnote reference##W\  P6QP#4 <DL!4 <DL!Ѝ) footnote reference) Parts of this section were adapted from "Some Lists of Lists", compiled by Marty Hoag and available via Gopher to #Z6X@DQ@#vm1.nodak.edu#B2PQP# (path: #Z6X@DQ@#1/Local LISTSERV Resources/NEWLIST Project#B2PQP#).w#XX2PQXP#  )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Before you start your list, it pays to do a careful search in several places to find out if you are duplicating an alreadyexisting 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 %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!LIST GLOBAL search_string %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! 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, #d6X@DQ@# LIST GLOBAL IBM #I2PQP# would result in the following being returned to you: %Body Text Left%1!( @ddCode Example 2#P6X@DQ@# 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. * *********************************************************************** Networkwide ID Full address and list description © 9370L 9370L@NIC.SURFNET.NL IBM 9370 and VM/IS specific topics list AIBIBL AIBIBL@PLEARN.EDU.PL ACADEMIC INITIATIVE IBM , PROJECT "LIBRARY SYSTEMS" AIBIBL AIXL AIXL@PUCC.PRINCETON.EDU IBM AIX Discussion List AIXNEWS AIXNEWS@PUCC.PRINCETON.EDU IBM AIX News to Mail Distribution %Code Example 2%  FigureCaption#B2PQP#4 <DL!4 <DL! Figure 2.1.Sample output of #Z6X@DQ@# LIST GLOBAL IBM #B2PQP# $FigureCaption$Code Example 2#P6X@DQ@# 4 <DL!4 <DL! %Code Example 2%Body Text Left#I2PQP#(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 #d6X@DQ@# IBM 370 #I2PQP#. Alternative searches you can do include: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!"Check the archive on NDSUVM1 (or VM1.NODAK.EDU), where the NEWLIST project at North Dakota State University has been storing list announcements for several years. The NEWLIST 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 #d6X@DQ@# vm1.nodak.edu. #I2PQP# "Use a Gopher or WorldWide Web (WWW) client to access the InterNIC database services, where a list of lists is maintained. The InterNIC Gopher is located at #d6X@DQ@# rs.internic.net #I2PQP#. "Get a copy of the Interest Groups List of Lists maintained by SRI on its server at #d6X@DQ@# sri.com #I2PQP#. Note that this is a 500KB (or larger) file. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!ftp sri.com user: anonymous password: your_user_id cd netinfo get interestgroups %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!"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 oneline entries for each group. Again, this is a large file, so be sure you have room for it. Also available on the #d6X@DQ@# dartcms1 #I2PQP# server is a Macintosh Hypercard application that formats this file nicely (assuming you have a Macintosh). You may want to do a #d6X@DQ@# dir #I2PQP# of the files available in the #d6X@DQ@# siglists #I2PQP# directory to see if there is anything else there that might be useful. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!ftp dartcms1.dartmouth.edu user: anonymous password: (not required by dartcms1) cd siglists get internet.lists %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!Note that all these files (except the large data stack) can also be retrieved from LISTSERV@DARTCMS1.DARTMOUTH.EDU. "Check the Usenet newsgroups #d6X@DQ@# news.announce.newusers #I2PQP# and #d6X@DQ@# news.lists #I2PQP# , if they are available to you via your local news feed. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.2. What skills do I need to start and maintain a LISTSERV mailing list? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 Internetstyle 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.3. Creating a mailing list ! Where can it be done, and Who can do it? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! If you are looking for a site to host a list, you might consider the following: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!"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 LSTSRVL @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 LSoft's own EASESM service. Send the description and a request for further information to SALES@LSOFT.COM. $Bulleted List$Body Text Left#I2PQP# 4` <DL!4 <DL!Please note also that many sites (predominantly, but not necessarily limited to, those in .EDU domains) will not host commercial or potentiallycontroversial 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.%Body Text Left%# footnote reference##W\  P6QP#X01 Í  Í X01ÍÍ%Body Text Left% footnote text#W\  P6QP## footnote reference##W\  P6QP#ۍ) footnote reference) Note that the "LISTSERV postmaster" is not identical to the regular POSTMASTER address at a host site. The term "LISTSERV postmaster" is a canonical term from early in LISTSERV's history, and refers only to the person who is the actual LISTSERV maintainer at the host site. The term has fallen into disuse and its use is discouraged because of the potential confusion it may cause.#I2PQP# 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.4. List Header Keywords and what they do )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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. %Body Text Left%Body SubHead#I2PQP# 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.   #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP# 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.   #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP# Error Handling Keywords.  Included under this group are the keywords controlling automatic deletion, loopchecking, and to whom error messages are sent for disposition when received by LISTSERV. #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP# 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.   #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP# 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.  #Body SubHead#Body Text Left#I2PQP#‘ #Body SubHead# %Body Text Left%Body SubHead#I2PQP# 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.   #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP# 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.   #Body SubHead#Body Text Left#I2PQP# %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.5. Retrieving and editing the list ! some considerations )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# GET listname #I2PQP# 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 #d6X@DQ@# GET #I2PQP# command with the #d6X@DQ@# (header #I2PQP# switch: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!GET listname (header %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! 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: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!"Issue the #d6X@DQ@# UNLOCK listname #I2PQP# command (if you decide no changes are needed) "Send the list back to the server with the #d6X@DQ@# PUT #I2PQP# command. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! 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 #d6X@DQ@# UNLOCK #I2PQP# 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 #d6X@DQ@# (nolock #I2PQP# switch to the #d6X@DQ@# GET #I2PQP# command. You can use (nolock and (header together as in the following example: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!GET listname (header nolock %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! (Note that the "#d6X@DQ@# ( #I2PQP#" switch character is used only once.) CAUTION: It is not advisable to use the #d6X@DQ@# (nolock #I2PQP# switch in at least two cases: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!"Don't use the #d6X@DQ@# (nolock #I2PQP# switch if you are not the sole owner of the list. This prevents conflicting #d6X@DQ@# GET #I2PQP#s and #d6X@DQ@# PUT #I2PQP#s by different list owners. For instance, Owner(A) #d6X@DQ@# GET #I2PQP#s the list without locking it. Owner(B) then also #d6X@DQ@# GET #I2PQP#s the list. The owners make differing changes to the list header. Owner(B) #d6X@DQ@# PUT #I2PQP#s his changes back first. Owner(A) then #d6X@DQ@# PUT #I2PQP#s his changes back, erasing every change Owner(B) made. If Owner(A) had not used the #d6X@DQ@# (nolock #I2PQP# switch, Owner(B) would not have been able to #d6X@DQ@# GET #I2PQP# a copy of the list until Owner(A) either unlocked the list or #d6X@DQ@# PUT #I2PQP# 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 #d6X@DQ@# (nolock #I2PQP# 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 #d6X@DQ@# GET #I2PQP# the list and #d6X@DQ@# PUT #I2PQP# the list back. It is easier to deal with questions as to why they got the "listname has been locked since time by listowner" message than to explain why they got a subscription confirmation and now aren't getting list mail. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL!‘$Bulleted List$ Another caution: If you #d6X@DQ@# GET #I2PQP# the header with the #d6X@DQ@# (header #I2PQP# switch, do not add new subscribers "on the fly" to the bottom of the header. If you do, your subsequent #d6X@DQ@# PUT #I2PQP# 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 "handedit" 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 "handedit" would be to delete a user entirely, and then only if all attempts to delete the user via the #d6X@DQ@# DELETE #I2PQP# command fail. For instance, X.400 or X.500 addresses can cause #d6X@DQ@# DELETE #I2PQP# 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: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!DELETE XYZL /ADMD=ABC/PRMD=DEF/...../@X400.SOMEHOST.COM. %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.6. Adding a list password )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!* PW=MYPASSWD %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! 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 #d6X@DQ@# GET #I2PQP#s; to all intents and purposes it is invisible once it is assigned. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.7. Storing the list on the host machine )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# PW=XXXXXXXX #I2PQP# command is in the first line of the mail body. Change #d6X@DQ@# XXXXXXXX #I2PQP# to the password you have previously defined with the #d6X@DQ@# PW= #I2PQP# 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 #d6X@DQ@# PUT #I2PQP# line at the top. LISTSERV will not translate encoded attachments. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.8. Fixing mistakes )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# GET listname (OLD #I2PQP# command to the host server. You must then add the #d6X@DQ@# PUT listname LIST PW=XXXXXXXX #I2PQP# command to the top of the file and store it. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL! 2.9. A sample list header file )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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: %Body Text Left%1A( @ddCode Example 2#P6X@DQ@# PUT MYLIST.LIST PW=XXXXXXXX * The Descriptive Title of My List * * Owner= NATHAN@LSOFT.COM (Nathan Brindle) * Notebook= Yes,A,Monthly,Public * ErrorsTo= Owner * Subscription= Open,Confirm * Ack= Yes Confidential= No Notify= No * Files= No MailVia= Distribute Validate= No * Replyto= List,Respect Review= Public Send= Public * Stats= Normal,Private XTags= Yes * DefaultOptions= NoFiles,NoRepro * * This list installed on 95/02/02, running under LSoft's LISTSERVTCP/IP * version 1.8b for Windows NT. * * Comment lines... * %Code Example 2% Ĝ FigureCaption#B2PQP#4 <DL!4 <DL!Figure 2.2.A sample list header file for a list called MYLIST. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# PUT #I2PQP# 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. %Body Text Left%1ha( @ddCode Example 2#P6X@DQ@# 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,FullAuto * ErrorsTo= ncbnet@linus.dc.lsoft.com * Subscription= Open,Confirm * Ack= Yes Confidential= No Notify= No * Files= No MailVia= Distribute Validate= No * Replyto= List,Respect Review= Public Send= Public * Stats= Normal,Private XTags= Yes * DefaultOptions= NoFiles,NoRepro * PW=NEWPASSWD * * This list installed on 95/02/02, running under LSoft's LISTSERVTCP/IP * version 1.8b for Windows NT. * * Comment lines... * %Code Example 2% h FigureCaption#B2PQP#4 <DL!4 <DL!Figure 2.3.The edited list header file ready to be sent back to the server. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL!‘$FigureCaption$ %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!2.10. Security Options )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERVs 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 LISTSERVs local machine, or from a definable range in between. %Body Text Left%Body SubHead#I2PQP# 2.10.1. First line of defense: The VALIDATE= keyword  #Body SubHead#Body Text Left#I2PQP# The #d6X@DQ@# VALIDATE= #I2PQP# keyword controls the level of command validation desired for your list. The default, #d6X@DQ@# VALIDATE= NO #I2PQP#, 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 #d6X@DQ@# VALIDATE= YES #I2PQP#. At this level, LISTSERV requires a password for all of its protected commands. This password can be either the list password or the senders personal password as defined by the #d6X@DQ@# PW ADD #I2PQP# command. The commands protected by this level are those that affect subscriptions or the operation of the list, e.g., #d6X@DQ@# DELETE #I2PQP# or #d6X@DQ@# ADD #I2PQP#. 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 #d6X@DQ@# VALIDATE= YES,CONFIRM #I2PQP#. At this level, LISTSERV will require validation with the OK mechanism (see below) by default, but will still accept passwords where appropriate. While the lesssecure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience. The next level is #d6X@DQ@# VALIDATE= YES,CONFIRM,NOPW #I2PQP#. 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 #d6X@DQ@# VALIDATE= ALL,CONFIRM #I2PQP# and#d6X@DQ@# VALIDATE= ALL,CONFIRM,NOPW #I2PQP#. These levels require OK validation for all commands that cause a change in state except for the #d6X@DQ@# PUT #I2PQP# command. If #d6X@DQ@# NOPW #I2PQP# is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (e.g., #d6X@DQ@# QUERY #I2PQP#) 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 #d6X@DQ@# VALIDATE= #I2PQP# keyword. %Body Text Left%Body SubHead#I2PQP# 2.10.2. Controlling subscription requests  #Body SubHead#Body Text Left#I2PQP# You can control subscription requests by use of the #d6X@DQ@# SUBSCRIPTION= #I2PQP# keyword. By default, this keyword is set to #d6X@DQ@# SUBSCRIPTION= #I2PQP# #d6X@DQ@# BY OWNER #I2PQP#, meaning that all subscription requests will be forwarded to the list owner for disposition. You can also refuse all subscription requests by setting #d6X@DQ@# SUBSCRIPTION= CLOSED #I2PQP#. To code a list for open subscriptions without list owner intervention, you set #d6X@DQ@# SUBSCRIPTION= OPEN #I2PQP#. If you would like to add protection against forged subscription requests or bad return mailing paths, code #d6X@DQ@# SUBSCRIPTION= OPEN,CONFIRM #I2PQP#. 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. %Body Text Left%Body SubHead#I2PQP# 2.10.3. Controlling the service area of your list  #Body SubHead#Body Text Left#I2PQP# 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 #d6X@DQ@# LIST GLOBAL #I2PQP# command. If you wish to simply hide your list from a #d6X@DQ@# LIST #I2PQP# command, but still allow people to subscribe to it if they know it is there, use the keyword #d6X@DQ@# CONFIDENTIAL= YES #I2PQP#. 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 #d6X@DQ@# LIST #I2PQP# command. If you wish to hide your list from and refuse subscription requests from users outside the local area, you define two keywords: #d6X@DQ@# * SERVICE= bitnode1,bitnode2,some.host.edu * CONFIDENTIAL= SERVICE #I2PQP# #d6X@DQ@# SERVICE= #I2PQP# can also be set to #d6X@DQ@# SERVICE= LOCAL #I2PQP#, meaning it will use either LISTSERVs global definition of which machines are #d6X@DQ@# LOCAL #I2PQP#, or the machines defined by the list keyword #d6X@DQ@# LOCAL= #I2PQP#. If you wish to set #d6X@DQ@# SERVICE #I2PQP# to #d6X@DQ@# LOCAL #I2PQP#, 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 #d6X@DQ@# LOCAL= #I2PQP# keyword: #d6X@DQ@# * LOCAL= bitnode1,bitnode2,some.host.edu,another.host.com * SERVICE= LOCAL * CONFIDENTIAL= SERVICE #I2PQP# If there are many subdomains within your primary domain, you may wish to use the wildcard when defining the #d6X@DQ@# LOCAL #I2PQP# or #d6X@DQ@# SERVICE #I2PQP#keywords. For instance: #d6X@DQ@# * SERVICE= *.HOST.COM #I2PQP# defines the service area as all subdomains ending in .HOST.COM. %Body Text Left%Body SubHead#I2PQP# 2.10.4 Controlling who may review the list of subscribers  #Body SubHead#Body Text Left#I2PQP# 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 #d6X@DQ@# REVIEW= #I2PQP# keyword appropriately. To allow anyone, including nonsubscribers, to review the list, set #d6X@DQ@# REVIEW= PUBLIC #I2PQP# (which is also the default). ‘ To restrict reviews of the list to subscribers only, set #d6X@DQ@# REVIEW= PRIVATE #I2PQP#. To restrict reviews of the list to list owners only, set #d6X@DQ@# REVIEW= OWNERS #I2PQP#. You can also restrict reviews to users within the lists service area by setting #d6X@DQ@# REVIEW= SERVICE #I2PQP# , and defining the #d6X@DQ@# SERVICE= #I2PQP# keyword appropriately (see the preceding section). %Body Text Left%Body SubHead#I2PQP# 2.10.5 Controlling who may access the notebook files  #Body SubHead#Body Text Left#I2PQP# Restricting access to the lists notebook archive files is similar to controlling who may review the list. It is accomplished by setting the fourth parameter of the #d6X@DQ@# NOTEBOOK= #I2PQP# keyword to an appropriate value. For instance, #d6X@DQ@# * NOTEBOOK= Yes,A,Monthly,Public #I2PQP# defines a monthly notebook on LISTSERVs A disk that is accessible by anyone. Change #d6X@DQ@# Public #I2PQP# to #d6X@DQ@# Private #I2PQP# if you wish only subscribers to be able to access the notebooks. The same accesslevels are available for this keyword as for #d6X@DQ@# REVIEW= #I2PQP#. (See Appendix B for a discussion of accesslevels.) If enabled, notebook archives are private by default. %Body Text Left%Body SubHead#I2PQP# 2.10.6 Controlling who may post mail to the list  #Body SubHead#Body Text Left#I2PQP# The #d6X@DQ@# Send= #I2PQP# list header keyword is the basic control for who may post mail to the list. If the list allows nonsubscribers to post, set #d6X@DQ@# Send= Public #I2PQP#. For a list that does not allow nonsubscribers to post, set #d6X@DQ@# Send= Private #I2PQP#. For a list where all posts should be forwarded to a moderator/editor, there are two settings: """"""""4 <DL!4` <DL!1#d6X@DQ@# Send= Editor #I2PQP# forwards all postings to the list editor (see the #d6X@DQ@# Editor= #I2PQP# and #d6X@DQ@# Moderator= #I2PQP# 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. 1#d6X@DQ@# Send= Editor,Hold #I2PQP# forwards a copy of the posting to the editor but differs #d6X@DQ@# from Send= Editor #I2PQP# 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 wellsuited to lists where it is not often necessary to modify the text of a posting, and also is an excellent workaround if the editors mail program does not generate Resent headers in forwarded mail. 4` <DL!4 <DL! Below is a sample of the editorheader for a list set to #d6X@DQ@# Send= Editor,Hold #I2PQP#: %Body Text Left%1s( @ddCode Example 2#P6X@DQ@# %Body Text Left%From: #d6X@DQ@# "LSoft list server at PEACH.EASE.LSOFT.COM (1.8b)"     Subject: ACCESSL: approval required (701AC4)   To: Nathan Brindle     This message was originally submitted by joe@unix1.foo.bar.com to the   ACCESSL 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)  %Code Example 2% s FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 2.4The editorheader for a list set to #Z6X@DQ@# Send= Editor,Hold #B2PQP# $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! A final method (called selfmoderation) exists for lists where subscribers should be allowed to post freely, but nonsubscriber posts should always be sent to an editor for approval. To enable selfmoderation, set #d6X@DQ@# Send= Editor[,Hold] Editor= userid@host,(listname) #I2PQP# Ensure that listname is in parenthesis. Note that selfmoderation will catch all posts from nonsubscribers"including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as #d6X@DQ@# joe@foo.com #I2PQP# but is posting from #d6X@DQ@# joe@unix1.foo.com #I2PQP#, LISTSERV will treat his mail as nonsubscriber mail. Selfmoderation may require some slight changes in individual user subscriptions in order for it to work seamlessly. %Body Text Left%Body SubHead#I2PQP#   2.10.7. The OK confirmation mechanism  #Body SubHead#Body Text Left#I2PQP# Depending on the setting of the #d6X@DQ@# Validate= #I2PQP# 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, LSoft 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 owners user id, the command confirmation request will always be sent to the list owners user id, thus preventing the spoofer from confirming the command. Moreover, the cookie itself (a sixdigit 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: 4 <DL!4` <DL!1 REPLY to the command confirmation request with the text ok in the body of the reply. (Noncasesensitive) LISTSERV reads the cookie from the subject line and if it corresponds to a held job, the job is released and processed. 4` <DL!4 <DL! If this does not work, it is possible that the Subject: line was corrupted in transit and you may need to try the following: 4 <DL!4` <DL!1 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. 4` <DL!4 <DL! ‘It is also possible to confirm multiple command confirmation requests with a single message (for instance, if you have #d6X@DQ@# Send= Editor,Hold #I2PQP# 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. %Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ3. Advertising Your Public Mailing Lists Chapter3  &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 3.1. List of Lists )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV automatically produces a List of Lists that may be reviewed by users anywhere on the Internet via the #d6X@DQ@# LIST GLOBAL #I2PQP# command. This List of Lists is made up of oneline 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 3.2. The INFO command and how to implement it )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# INFO listname #I2PQP# to your server, LISTSERV responds with either: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!The default response, which simply sends a copy of the list header to the user; or The customized paragraph included in the listname.MAILTPL file. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! If listname.MAILTPL does not exist, the default response is sent. Also note that the user may send the #d6X@DQ@# INFO listname #I2PQP# command to any LSoft LISTSERV host (including the Global List Exchange discussed below), which will forward the request to the appropriate server. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 3.3. The NEWLIST project at North Dakota State )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! The NEWLIST project was started in 1989 to promote mailing lists via a mailing list. NEWLIST@VM1.NODAK.EDU distributes announcements of new and changed mailing lists to over 9500 subscribers every day. The NEWLIST administration asks only that your list be welltested 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 NEWLIST announcement may cause problems for both you and other users months later. For more information on the NEWLIST project and what you need to use it, you can: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!Gopher to vm1.nodak.edu and choose #d6X@DQ@# "Local LISTSERV Resources" #I2PQP#, then #d6X@DQ@# "NEWLIST Project" #I2PQP#; or Send the command #d6X@DQ@# GET NEWLIST PACKAGE #I2PQP# to #d6X@DQ@# LISTSERV@VM1.NODAK.EDU #I2PQP#. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! (The NEWLIST Project also published a hardcopy version of their archive in 1992 with a newer edition in 1993 under the title Internet: Mailing Lists [ISBN 0133279413], edited by Edward T. L. Hardie and Vivian Neou.) %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!‘%Body Text Left%3.4. The Internet Network Information Center (INTERNIC) )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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, #d6X@DQ@# rs.internic.net #I2PQP#. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 3.5. The Global List Exchange (GLX) and why you should mention it )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 LSoft'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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 3.6. How NOT to advertise a mailing list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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.%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ4. Managing Subscriptions Chapter4  &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 4.1. How to add and delete subscribers to/from a list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! A list owner may add and delete subscribers manually. The command syntax is: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# ADD listname netaddress full_name DELete listname netaddress %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# 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 #d6X@DQ@# Subscription= By Owner #I2PQP# or #d6X@DQ@# Subscription= Closed #I2PQP#, it is of course necessary to use the #d6X@DQ@# ADD #I2PQP# command to subscribe a user. If the list is set to confirm mailing paths for new subscriptions (#d6X@DQ@# Subscription= Open,Confirm #I2PQP#), 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 #d6X@DQ@# full_name #I2PQP# should contain at least two discrete words, but it is also possible to add users without knowing the value for #d6X@DQ@# full_name #I2PQP#. 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 #d6X@DQ@# full_name #I2PQP# from its signup files. Examples are: RIGHT: #d6X@DQ@# ADD GOVL vicepresident@whitehouse.gov Al Gore #I2PQP#RIGHT: #d6X@DQ@# ADD GOVL vicepresident@whitehouse.gov * #I2PQP#WRONG: #d6X@DQ@# ADD GOVL vicepresident@whitehouse.gov Al #I2PQP# WRONG: #d6X@DQ@# ADD GOVL vicepresident@whitehouse.gov AlGore #I2PQP# When adding users, #d6X@DQ@# ADD #I2PQP# 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 %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# From: Al Gore %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# becomes an #d6X@DQ@# ADD #I2PQP# command as follows: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# ADD GOVL Al Gore %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.2. Finding users who do not appear in the list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# SCAN #I2PQP# command to search for a pattern anywhere in the subscriber list. The syntax is: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# SCAN listname searchtext %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL! Ñ %Code Example 1% For instance, "#d6X@DQ@# SCAN TESTL Nathan #I2PQP#" might return: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# > scan testl Nathan Nathan Brindle Somebody Else Jonathan Smith SCAN: 3 matches. %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# Note that #d6X@DQ@# SCAN #I2PQP# is not casesensitive. "Nathan", "NATHAN", and "nathan" all return the same results. Searches with #d6X@DQ@# SCAN #I2PQP# 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: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# SCAN TESTL MAIL.FOO.BAR.COM %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# will not find the user jsmith@foo.bar.com. If you run the following search: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# SCAN TESTL BAR.COM %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# 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 #d6X@DQ@# QUERY #I2PQP# 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.3. Converting mailing lists to LISTSERV from other systems )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! If you are moving a list from a nonLISTSERV site, you can quickly and easily convert the existing list file to the LISTSERV format by following these instructions: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!%Body Text Left%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: $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# QUIET ADD listname DD=X IMPORT //X DD *  user1  user2 /* %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!where "#d6X@DQ@# listname #I2PQP#" is the name of the new list, and "#d6X@DQ@# user1 #I2PQP#", "#d6X@DQ@# user2 #I2PQP#" 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. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! The #d6X@DQ@# IMPORT #I2PQP# 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.4. Using the QUIET option with commands )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Prepending the command word "#d6X@DQ@# QUIET #I2PQP#" 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 #d6X@DQ@# QUIET #I2PQP# include: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# QUIET ADD EXCELL comp.spreadsheets.excel@netnews.somenode.edu %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# QUIET DELETE EXCELL Bouncemeister@somenode.edu %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.5. Dealing with bounced mail )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%Body SubHead#I2PQP#   4.5.1. What is a bounce, and what can typically cause one?    #Body SubHead#Body Text Left#I2PQP#A bounce is simply an undeliverable email 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 autodeletion, these bounces will be the least of your worries ! in fact, they will not be worrisome at all. %Body Text Left%Body SubHead#I2PQP#   4.5.2. What to do about several types of bounces  #Body SubHead#Body Text Left#I2PQP# Here are a few of the typical mail errors you will have to deal with as a list owner: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL! 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 #d6X@DQ@# quiet delete #I2PQP# (syntax: "#d6X@DQ@# QUIET DELETE listname userid@host" #I2PQP#) 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 highvolume list, it is probably best to set the user to #d6X@DQ@# NOMAIL #I2PQP# (syntax: "#d6X@DQ@# SET listname NOMAIL FOR userid@host" #I2PQP#) 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 n 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 #d6X@DQ@# NOMAIL #I2PQP#. 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 #d6X@DQ@# NOMAIL #I2PQP#. The best solution is to set the user to #d6X@DQ@# NOMAIL #I2PQP# 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. #d6X@DQ@# NOMAIL #I2PQP# or #d6X@DQ@# DELETE #I2PQP#, 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: $Bulleted List$Code Example 2#P6X@DQ@# 4` <DL!4 <DL!#I2PQP# #P6X@DQ@# binmail: /usr/spool/mail/userid: too big to accept new messages. #d6X@DQ@# It's size is 205735 bytes which is 935 bytes over quota.   mail: cannot open dead.letter   554 ... unknown mailer error 1  %Code Example 2%Bulleted List#I2PQP#4 <DL!4` <DL!#d6X@DQ@##I2PQP# 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. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! A particularly annoying error you may have to deal with comes from Banyan networks and is of the form: ‘ %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# LLONG@StarShip@Dora: Mailbox full %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# Obviously this is not a properlyconfigured 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: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# > scan testl LLONG Bill Smith SCAN: 1 match. %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# This user can now be set to #d6X@DQ@# NOMAIL #I2PQP# and the errors will stop after the Banyan host has emptied its queue. If you do not find the user on the first #d6X@DQ@# SCAN #I2PQP#, 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 nonEnglish error messages!) and LISTSERV's autodeletion feature will not always catch their bounces. %Body Text Left%Body SubHead#I2PQP#   4.5.3. Redistribution and forwarding    #Body SubHead#Body Text Left#I2PQP#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 "xxxxxLREDIST@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 #d6X@DQ@# NOMAIL #I2PQP# or (in some cases) to delete him/her altogether. You therefore send #d6X@DQ@# set xxxxxL nomail for someuser@baz.net #I2PQP# to LISTSERV. LISTSERV responds: "No subscription for someuser@baz.net in list XXXXXL." In a bestcase 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 redistributionlist account like xxxxxL@baz.net. These are easilyfixed 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 ownerxxxxxl@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 xxxxxl@baz.net to NOMAIL. ‘The worstcase 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 #d6X@DQ@# QUERY xxxxxl FOR *@*baz* #I2PQP#or #d6X@DQ@# QUERY xxxxxl FOR *baz*@* #I2PQP#. 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 xxxxxl%baz.net@cunyvm.cuny.edu or something of that sort. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.6. Automatic and semiautomatic deletion )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV supports several levels of automatic deletion based on error messages passed back to it in LMail format by certain remote systems. While autodelete 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 autodelete 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 nonzero values for a list coded "AutoDelete= Yes", LISTSERV will not take immediate action on mail delivery errors. You will receive an "autodeletion 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 "AutoDelete= No", while all other lists are set "AutoDelete= Yes,SemiAuto,Delay(4),Max(100)". Implementation of the "AutoDelete=" keyword is discussed in detail in Appendix B, List Keyword Alphabetical Reference, under "Error Handling Keywords." %Body Text Left%Body SubHead#I2PQP#   4.6.1. AutoDelete considerations for holidays  #Body SubHead#Body Text Left#I2PQP# 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 ("AutoDelete= 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 NONdelivery 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.7. Subscription confirmation )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 oneway 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: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!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. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! Note that if a list owner adds a user manually, the confirmation process is bypassed. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.8. Subscription renewal )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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, nonprivate lists. To add subscription renewal, you add the following keyword to the header of your list: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Renewal= interval %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP#or %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Renewal= interval,Delay(number) %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# where #d6X@DQ@# interval #I2PQP# is a period of time such as Weekly, Yearly, 6monthly, or something similar, and #d6X@DQ@# Delay(number) #I2PQP# 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 #d6X@DQ@# CONFIRM listname #I2PQP# 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 #d6X@DQ@# CONFIRM #I2PQP# 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 "ErrorsTo=" 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 %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# [QUIET] SET listname NORENEW FOR netaddress %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# 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 #d6X@DQ@# CONFIRM #I2PQP# command for a subscriber: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# [QUIET] CONFIRM listname FOR netaddress %Code Example 1%#Section SubHeading##XX2PQXP# ` <DL!4 <DL!#d6X@DQ@# #XX2PQXP#  #I2PQP##XX2PQXP# 4.9. The SERVE command )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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 #d6X@DQ@# SERVE netaddress #I2PQP# command to restore that user's access. As with all other LISTSERV commands, the #d6X@DQ@# SERVE #I2PQP# 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. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 4.10. "Peering" large lists )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Occasionally the need to split a very large list may arise. This was more common when LISTSERV ran only on BITNET, whereas the TCPIP 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 LSoft LISTSERV list, linking to a nonLSoft mailing list manager is not supported and will cause serious problems (including mailing loops) for which LSoft 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 #d6X@DQ@# EXPLODE #I2PQP# 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.) %Body Text Left%Body SubHead#I2PQP#   4.10.1 Moving users from one (peer) server to another:  #Body SubHead#Body Text Left#I2PQP# You should be aware of the fact that a #d6X@DQ@# MOVE #I2PQP# operation is not just an #d6X@DQ@# ADD #I2PQP# to the new server and a #d6X@DQ@# DELete #I2PQP# 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: 4 <DL!4 <DL!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. 4 <DL!4 <DL! 4 <DL!4 <DL!2a.If the prerequisites for using the #d6X@DQ@# MOVE #I2PQP# command are met, you should use either individual #d6X@DQ@# MOVE #I2PQP# commands (in the case that there are very few users to move) or a batch#d6X@DQ@# MOVE #I2PQP# command with associated #d6X@DQ@# DDname #I2PQP# (see the LISTJOB MEMO guide for more information on commandsjobs) to move the users. You may want to use the #d6X@DQ@# QUIET #I2PQP# option to suppress notification if there are a lot of users to move. 4 <DL!4 <DL! Warning: the #d6X@DQ@# MOVE #I2PQP# command should not be used to move peer list servers. See the #d6X@DQ@# MOVE #I2PQP# command description for more details. If you cannot use the #d6X@DQ@# MOVE #I2PQP# command, you should try one of the following two methods: 4 <DL!4 <DL!2b.For each user to be moved, issue the following commands in the following order: 4 <DL!4 <DL! 4 <DL! <DL!#d6X@DQ@# Query listname FOR userid@host #I2PQP# (old server), write down the options. #d6X@DQ@# QUIET ADD listname userid@host full_name #I2PQP# #d6X@DQ@# QUIET SET listname options FOR userid@host #I2PQP# Wait until you get confirmation for the two previous commands #d6X@DQ@# QUIET DELete listname userid@host #I2PQP# (old server)  <DL!4 <DL! 4 <DL!4 <DL!2c.If there are a lot of users to move, the following method is preferred: 4 <DL!4 <DL! 4 <DL! <DL!#d6X@DQ@# GET listname #I2PQP# (old server) #d6X@DQ@# GET listname #I2PQP# (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 81100 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 wordwrapping 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 81100 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.  <DL!4 <DL! %Body Text Left%Body SubHead#I2PQP#   4.10.1 Special commands for peered lists only  #Body SubHead#Body Text Left#I2PQP# #d6X@DQ@# ADDHere listname userid@host <full_name> #I2PQP# 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 bettersuited peer list for the specified user.) #d6X@DQ@# EXPLODE listname [VM only] #I2PQP# The #d6X@DQ@# EXPLODE #I2PQP# 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). NonBITNET 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 commandsjob file containing the necessary #d6X@DQ@# MOVE #I2PQP# command to transfer all the users which were found to be (possibly) misallocated 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. #d6X@DQ@# MOVE listname userid@host newhost DD=ddname listid@newhost [VM only] #I2PQP# The #d6X@DQ@# MOVE #I2PQP# 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 #d6X@DQ@# MOVE #I2PQP# operation will be done in such a way that no mail can possibly be lost by the target while the #d6X@DQ@# MOVE #I2PQP# operation is in progress (duplicate mail might be received for a short duration, however). Notification will be sent to the target user unless the #d6X@DQ@# QUIET #I2PQP# 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 #d6X@DQ@# MOVE #I2PQP# 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) #d6X@DQ@# ADD/DELETE #I2PQP# 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 #d6X@DQ@# MOVE #I2PQP# 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 #d6X@DQ@# MOVE #I2PQP# command is the proper way to effect a move operation. You should not use any other command/set of commands unless you cannot use #d6X@DQ@# MOVE #I2PQP#. THE #d6X@DQ@# MOVE #I2PQP# COMMAND SHOULD NOT BE USED TO MOVE DISTRIBUTION LISTS!!! Since a #d6X@DQ@# MOVE #I2PQP# is basically an #d6X@DQ@# ADD #I2PQP# + #d6X@DQ@# DELETE #I2PQP#, with the latter being done only AFTER the #d6X@DQ@# ADD #I2PQP# is completed, moving a distribution list address with the #d6X@DQ@# MOVE #I2PQP# 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 interservers "DELETE" command jobfile, and the RSCS priority of the latter has been altered. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  )Section SubHeading) Section Heading #g2PQP# 4 <DL!4 <DL!#I2PQP# #g2PQP# Ñ5. Setting Subscription Options For Subscribers Chapter5  &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 5.1. How to review current subscription options with QUERY )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! 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. %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# Query listname FOR userid@host %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# Note that it is possible to use wildcards in the subscriber address. For instance, %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# Q LSTOWNL FOR J*@UBVM* %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# 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 #d6X@DQ@# WITH #I2PQP# 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 #d6X@DQ@# NOMAIL #I2PQP#. Send the command %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# Q listname WITH NOMAIL FOR *@* %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# and LISTSERV will return a list of those users. It is also possible to query a list for multiple options: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# Q listname with DIGEST CONCEAL FOR *@* %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# will return a list of those subscribers who have set their subscription to DIGEST and also to CONCEAL. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 5.2. How to set personal subscription options for subscribers )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Again, the syntax is similar to the subscriber's method. %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# [QUIET] SET listname option FOR userid@host %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 5.3. Options that may be set )Section SubHeading)Body SubHead#I2PQP# 4 <DL!4 <DL!    5.3.1. Mail/NOMail  #Body SubHead#Body Text Left#I2PQP#Setting this option to #d6X@DQ@# Mail #I2PQP# indicates that the subscriber will receive mail from the list. #d6X@DQ@# NOMail #I2PQP# is the complementary command that stops mail but leaves the user subscribed to the list. (#d6X@DQ@# NOMail #I2PQP# is often a good compromise for users who are leaving the office for vacation or on extended business trips, and who don't want a full mailbox on their return.) The format of the messages received is controlled by the #d6X@DQ@# DIGEST/INDEX/NODIGEST/NOINDEX #I2PQP# options (see below). %Body Text Left%Body SubHead#I2PQP#     5.3.2. DIGest/NODIGest  #Body SubHead#Body Text Left#I2PQP#Causes the subscriber to receive one posting per digest cycle (typically daily) rather than individual messages as they are processed by LISTSERV. In version 1.8b, the #d6X@DQ@# MAIL/NOMAIL #I2PQP# option has been isolated from #d6X@DQ@# DIGEST/INDEX #I2PQP#. The #d6X@DQ@# MAIL/NOMAIL #I2PQP# option controls whether messages should be delivered, and the #d6X@DQ@# DIGEST/INDEX/NODIGEST/NOINDEX #I2PQP# option controls the format in which messages should be delivered. Thus, switching to #d6X@DQ@# NOMAIL #I2PQP# and back to #d6X@DQ@# MAIL #I2PQP# now preserves the digest/index/normal delivery setting. To provide as much compatibility with the old syntax as possible, the four options operate as follows: 4 <DL!4` <DL!1#d6X@DQ@# DIGEST: #I2PQP# enable digest delivery mode (which negates INDEX), enable mail delivery. No change from version 1.8a. 1#d6X@DQ@# INDEX: #I2PQP# enable index delivery mode (which negates DIGEST), enable mail delivery. No change from version 1.8a. 1#d6X@DQ@# NOMAIL: #I2PQP# disable mail delivery. No change from version 1.8a. 1#d6X@DQ@# MAIL: #I2PQP# restore mail delivery, without altering the digest/index/normal delivery setting (new behavior). For compatibility with 1.8a, if mail delivery was already active, the MAIL option negates INDEX/DIGEST. Thus, a user going from NOMAIL to MAIL will keep his previous delivery options, whereas a user going from DIGEST or INDEX to MAIL will in fact deactivate index/digest mode. 4` <DL!4 <DL! To revert from digest/index subscription mode to normal delivery, you can use either the MAIL option as before, or the NODIGEST/NOINDEX option. The NODIGEST and NOINDEX options were actually present in versions 1.7f and 1.8a, as synonyms for the MAIL option. In other words, you can update your instructions to indicate that the DIGEST/INDEX options are negated by the NODIGEST/NOINDEX options, even if your server is not yet running version 1.8b. Note that in extreme cases, subscribers using the #d6X@DQ@# DIGEST #I2PQP# option may receive more than one digest per cycle if the digest limit is reached before the end of the cycle. %Body Text Left%Body SubHead#I2PQP#     5.3.3. INDex/NOINDex [VM only]  #Body SubHead#Body Text Left#I2PQP#Causes the subscriber to receive one posting per digest cycle containing only an index of subject topics for all messages during that cycle. See the section on DIGEST (above) for further information. %Body Text Left%Body SubHead#I2PQP#     5.3.4. ACK/NOACK/MSGack  #Body SubHead#Body Text Left#I2PQP#These three command words control the level of acknowledgment the subscriber receives when posting to the list. #d6X@DQ@# ACK #I2PQP# causes LISTSERV to send a short confirmation message to the subscriber when the post has been received and distributed. #d6X@DQ@# NOACK #I2PQP# disables the confirmation feature for the subscriber (although BITNET subscribers will receive a short interactive message on their terminal). For BITNET subscribers, #d6X@DQ@# MSGack #I2PQP#provides the same information as #d6X@DQ@# ACK #I2PQP# via interactive messages. %Body Text Left%Body SubHead#I2PQP#     5.3.5. Options for mail headers of incoming postings  #Body SubHead#Body Text Left#I2PQP#By specifying one of the following command words, the subscriber can control the amount of mail header information prepended to list mail. The syntax is #d6X@DQ@# SET listname headertype#I2PQP#, where #d6X@DQ@# headertype #I2PQP# is one of the following: %Body Text Left%#Body Text Indented##I2PQP#4 <DL! DL!#d6X@DQ@# FULLHdr #I2PQP#"Full" mail headers (default) (formerly FULLBSMTP) #d6X@DQ@# SHORTHdr #I2PQP#Short headers (formerly SHORTBSMTP) #d6X@DQ@# IETFhdr #I2PQP#Internetstyle headers #d6X@DQ@# DUALhdr #I2PQP#Dual headers, useful with PC or Mac mail programs )Body Text Indented)Body Text Left#I2PQP# DL!4 <DL! Note: In version 1.8b, the obsolete FULLHDR and SHORTHDR options were renamed to FULL822 and SHORT822, while the normal BSMTPstyle header options were renamed to FULLHDR and SHORTHDR. The FULL822/SHORT822 options are only required by a small number of ancient BITNET mail systems. ‘ Quite a few nontechnical users are relying on nonRFC822 user interfaces for reading their mail. Quite often these user interfaces are userfriendly, quality implementations of a proprietary mail protocol which the users are proficient with, but which happens not to lend itself to bidirectional mapping to RFC822. The users may have a good reason for using this particular program, and they complain that it is not always clear what list the postings come from, or who posted them. Other users have very primitive mail programs which do not preserve the original RFC822 header and may not even have a "message subject" concept. The user knows which list the message came from, but not who posted it, making private replies impossible. The DUALHDR (minimum abbreviation: DUAL) is provided to help solve this problem. Dual headers are regular short (SHORTHDR) headers followed by a second header inside the message body. This second header shows what list the message is coming from ('Sender:'), the name and address of the person who posted it ('Poster:'), the poster's organization, if present, and the message subject. The date is not shown because even the most primitive mail programs appear to supply a usable message date. Generally, users will be wellserved by the FULL header option, which is the default. %Body Text Left%Body SubHead#I2PQP#   5.3.6. CONCEAL/NOCONCEAL  #Body SubHead#Body Text Left#I2PQP#Occasionally, a subscriber may not want his presence to be known to someone else making a casual #d6X@DQ@# REView #I2PQP# of the list. Subscribers may choose to "hide" their subscription from the #d6X@DQ@# REView #I2PQP# command by using the #d6X@DQ@# CONCEAL #I2PQP# command. Conversely, a subscriber may choose to remove this restriction by issuing the #d6X@DQ@# NOCONCEAL #I2PQP# command. Note that the list owner can always obtain a list of all subscribers, both concealed and unconcealed, by issuing the #d6X@DQ@# GET listname (NOLock) #I2PQP# command, or by issuing a #d6X@DQ@# QUERY listname WITH CONCEAL FOR *@* #I2PQP# command. %Body Text Left%Body SubHead#I2PQP#   5.3.7. REPro/NOREPro  #Body SubHead#Body Text Left#I2PQP#This option controls whether or not the subscriber will get a copy of his or her own posts back from the list after they are processed. Generally, if a subscriber's mail program is configured to file copies of the subscriber's outgoing mail, or if the subscriber has one of the acknowledgment options #d6X@DQ@# (ACK/MSGack) #I2PQP# enabled, this option should be set to #d6X@DQ@# NOREPro #I2PQP#. If, on the other hand, the subscriber is set to #d6X@DQ@# NOACK #I2PQP# and doesn't keep a copy of outgoing mail, this option should probably be set to #d6X@DQ@# REPro #I2PQP#. %Body Text Left%Body SubHead#I2PQP#   5.3.8. TOPICS  #Body SubHead#Body Text Left#I2PQP#If list topics are enabled, this option allows the subscriber to specify which topics he or she will receive. The syntax of a SET TOPICS statement is significantly different from that of the other options. See Chapter 6, Section 6, for more information on this syntax. %Body Text Left%Body SubHead#I2PQP#   5.3.9. POST/NOPOST  #Body SubHead#Body Text Left#I2PQP#This option may be set only by list owners or the LISTSERV maintainer. A subscriber set to #d6X@DQ@# NOPOST #I2PQP# may not post to the list. #d6X@DQ@# NOPOST #I2PQP# gives the individual list owner the ability to serve out abusive or obnoxious posters without having to add such users to the list's "Filter=" setting. Subscribers set to #d6X@DQ@# NOPOST #I2PQP# will still receive list mail ! they just won't be able to post mail to the list. The list owner or LISTSERV maintainer may issue the #d6X@DQ@# SET listname POST FOR userid@host #I2PQP# command to reverse a previouslyset #d6X@DQ@# NOPOST #I2PQP#. Note for peered lists: #d6X@DQ@# NOPOST #I2PQP# must be set globally or a user can bypass the setting by simply posting to another peer. Thus you must add the user manually to the other peers and then set the user to #d6X@DQ@# NOMAIL #I2PQP# as well as #d6X@DQ@# NOPOST #I2PQP# on the peers. ‘ %Body Text Left%Body SubHead#I2PQP#   5.3.10. EDITOR/NOEDITOR  #Body SubHead#Body Text Left#I2PQP#This option may be set only by list owners or the LISTSERV maintainer, and is effective only on moderated lists. A subscriber set to #d6X@DQ@# EDITOR #I2PQP# on an edited/moderated list may post directly to the list without a moderator's intervention. It is virtually identical to adding the subscriber's address to the "Editor=" keyword, but easier to manage. The only difference between the #d6X@DQ@# EDITOR #I2PQP# option and the "Editor=" keyword, other than not being visible in the list header, is that the "Editor=" keyword also defines a (seldom used) access level class which can then be used in keywords such as "Review=". Thus, one could have a list with "Review= Editor", indicating that only the users listed in the "Editor=" keyword are allowed to review the list. The #d6X@DQ@# EDITOR #I2PQP# option does not confer this privilege. Note that the #d6X@DQ@# EDITOR #I2PQP# option is only meaningful on moderated lists. The list owner or LISTSERV maintainer may issue the #d6X@DQ@# SET listname NOEDITOR FOR userid@host #I2PQP# command to reverse a previouslyset #d6X@DQ@# EDITOR #I2PQP#. %Body Text Left%Body SubHead#I2PQP#   5.3.11. REVIEW/NOREVIEW  #Body SubHead#Body Text Left#I2PQP#This option may be set only by list owners or the LISTSERV maintainer. When a subscriber is set to #d6X@DQ@# REVIEW #I2PQP#, all postings from that subscriber are forwarded to the list editor or list owner for approval. Approval for these postings is always via the OK mechanism ! there is no need to forward the posting to the list, simply reply to the approval confirmation with "OK". Note that if a list is unmoderated, it is still possible to direct #d6X@DQ@# REVIEW #I2PQP# postings to a specific person by adding an "Editor=" or "Moderator=" keyword to the list header. The list owner or LISTSERV maintainer may issue the #d6X@DQ@# SET listname NOREVIEW FOR userid@host #I2PQP# command to reverse a previouslyset #d6X@DQ@# REVIEW #I2PQP#. %Body Text Left%Body SubHead#I2PQP#   5.3.12. RENEW/NORENEW  #Body SubHead#Body Text Left#I2PQP#This option may be set only by list owners or the LISTSERV maintainer. Enables or disables subscription renewal confirmation on an individual subscriber basis. Setting a subscription to #d6X@DQ@# NORENEW #I2PQP# is particularly useful for exempting list owners, redistribution lists, and other subscriptions which should not or must not receive the confirmation request message from the renewal process. The list owner or LISTSERV maintainer may issue the #d6X@DQ@# SET listname RENEW FOR userid@host #I2PQP# command to reverse a previouslyset #d6X@DQ@# NORENEW #I2PQP#. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 5.4. Setting original default options with the DefaultOptions= keyword )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! The list owner may specify original defaults for many subscriber options by using the "DefaultOptions=" keyword. This keyword takes regular SET options as its parameters. Examples include: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * DefaultOptions= DIGEST,NOREPRO,NOACK * DefaultOptions= REPRO,NONE %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# You may have more than one "DefaultOptions=" line in your header, as needed. Note that any default topics are set with the "DefaultTopics=" keyword. See Appendix B for details on this keyword.%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ6. Moderating and Editing Lists Chapter6  &Section Heading&Body Text Left#I2PQP# Please note that much of this chapter is subjective, based on personal experiences during several years of list ownership, and may not necessarily match your own philosophy of "the way things ought to be." The following sections are offered as one way to run a list, and the author does not mean to assert that the one way offered ! his way ! is the only way. As we seem to say so often, "your mileage may vary." %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.1. List charters, welcome files, and administrative updates )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! One of the most important things you can do as a list owner is make it clear from the outset what policies are in place and will be enforced if it becomes necessary. Due to a potential for controversy, for instance, some lists may require a formal "list charter" by which all subscribers must agree to abide before they are allowed to subscribe. Other lists may be able to get by with a simple welcome file (see below) that spells out basic netiquette, polices on "flaming" and commercial posts, and anything else that seems appropriate (such as how to get in touch with the list owner in an emergency, where the list archives are located, etc.). It is particularly important on open subscription lists that you make a concerted effort to remind your subscribers on a regular basis of the policies you have set for your list, as well as any other information they need in order to make best use of your list. If you have a great deal of subscriber turnover, it may be necessary to do this every few weeks. You may decide to put together a quarterly or semiyearly post for more stable lists. Ensure that the subject line is indicative of what the administrative posting is so that there is no question as to whether or not you posted it (even if subscribers don't read it). %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.2. The role of the list owner as moderator )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! By default, the list owner becomes a moderator of sorts, even if the list in question is neither edited nor officially moderated. This means that, as a list owner, you must be prepared to maintain order if it becomes necessary. At the same time, you must moderate yourself so that you do not alienate users and cause your list and/or host institution to suffer as a result. Thankfully, mailing lists have generally enjoyed relative peace and quiet over the years in comparison to newsgroups, but mailing lists have unique problems of their own. Lists dedicated to controversial subjects are more likely to become arenas for flame wars between subscribers with hardheld and differing opinions than those dedicated to the discussion of popular software packages, but this does not mean that the latter are immune any more than it means that the former are constantly plagued by flames. The example set by you as list owner and as a participating subscriber to the list is perhaps the most important factor in whether or not your list becomes a site known for strife and controversy. In other words, if you appear not to care about whether or not discussion is on topic and/or civilized, no one else will, either. Yet if you become a policeman ! the other end of the spectrum ! no one will want to subscribe or participate for fear of your wrath. Either way, your list is unlikely to last very long. The middle ground is, as in most things, the place to be when administering a list. Some call this "firm but fair," letting things go pretty much as they will but stepping in with a wry or gently chiding remark from time to time when exchanges get heated. And they will! Software discussion lists are particularly bad about this when new subscribers ask "frequentlyasked questions" (FAQs) and veteran subscribers respond in exasperated fashion with "RTFM!" (Read The Fine Manual) and similar nasty retorts. Good list owner practice at this point is likely to be a goodnatured reminder from you that flames belong in private mail, pointing out that new subscribers have no way of knowing that the particular questions they ask have been asked (and answered!) n random times before. Finally, if your mailing list has an international audience, you will need to be careful to account for language problems and cultural differences. You will need to decide which languages are allowed or not allowed on the list; this should be mentioned shortly in the list abstract or welcome message. In most cases, the official language will be English. As your list grows, some subscribers may object to this decision, arguing that people who have trouble expressing themselves in English should be allowed to use their own language, with the understanding that many people will be unable to understand what they are saying. As the list owner, it will be your call. Usually, the best compromise is to start a separate list for discussions in the new language. However, you must be careful in wording your decision. In multilingual cultures, it is usually considered a courtesy to use the other persons language. It is certainly considered rude for people to demand that everyone else should speak their language. Thus, if your native language is English, you will be in a delicate position. To avoid a flame war, you will want to make sure that your decision does not come out as a unilateral demand. Politely suggesting a separate list, and tolerating an occasional nonEnglish posting when the poster genuinely cannot speak English, is often the best course of action. Another possible source of flame wars is unintended rudeness. It is easy to forget that non native speakers are making an effort every time they post something to the list. People will make mistakes, sometimes appearing rude when they did not mean to, simply because they used the wrong word. Another cause of apparent rudeness is cultural difference. Things which are perfectly normal in one culture can be insulting in another. For instance, ad hominem attacks are perfectly acceptable in some countries. Conversely, referring to other people by their first name ( As Peter said in his last message, ...) can be downright insulting in some cultures, where anything short of the full title is at best condescending. But, of course, in other countries the use of the full title is considered sarcastic... There is no middle ground here, because there are too many conflicting cultures and too many languages. The only way to successful crosscultural communication is through the tolerance of other peoples cultural habits, in return for their tolerance of yours. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.3. The role of the list owner as editor )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Edited lists are generally used for the purpose of "full moderation" or for refereed electronic journals or the like, for which random postings from subscribers and/or nonsubscribers may not be welcome for general distribution. This places the list owner and any editors in the position of being fulltime monitors of what is and is not allowed to go through to the list. A word of warning to potential list editors: Rules on the Internet are not set in stone. Some people will insist on their right to post without what they will term "censorship" by the list editor. Some will become upset to the point of threatening to report you to your local computing center administrators for abridging their freedom of speech, or (in the U.S.) even threatening to sue your institution and you personally for an abridgment of their First Amendment rights. It is therefore vitally important to you that you keep a "paper trail" of such complaints in the event that threats become reality and you are asked about them. This common practice in the business world should be common practice in list ownership as well. Freedom of speech and copyright issues on the Internet have not yet been tested in the courts as of this writing. These are both areas in which list editors and list owners in general must tread carefully. Always document any problems you may have in these areas. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!‘%Body Text Left% #I2PQP##XX2PQXP# 6.4. Setting up an edited list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Should you decide that an edited list is the way to go for your particular situation, you need only add the following lines to your list header file: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Send= Editor * Editor= Owner %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# There can be multiple editors as well (and multiple Editor= lines, if desirable), and they do not have to be list owners: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Send= Editor * Editor= Owner,joe@foo.bar.edu * Editor= tony@tiger.com %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# Normally, LISTSERV forwards submissions only to the first editor defined by the "Editor=" keyword. In the case above, all submissions would go to the primary list owner. On a highvolume list, LISTSERV allows you to share the editing load via the "Moderator=" keyword. By default, this keyword is set to the same value as the first editor defined by "Editor=". When you define more network addresses with the "Moderator=" keyword, LISTSERV sends submissions to each moderator in sequence. The difference between the "Editor=" and "Moderator=" keywords lies in the fact that while any editor can post directly to the list, only moderators receive the forwarded submissions from noneditors. Here is an example of a list with both Editor= and Moderator= keywords defined: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Send= Editor * Editor= joe@foo.bar.edu,tony@tiger.com,kent@net.police.net * Moderator= kent@net.police.net,joe@foo.bar.edu %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# This list will "loadshare" the editing duties between Kent and Joe. Tony is able to post directly to the list, but will not receive forwarded subscriber posts for editing. Note that whereas an Editor is not required to be a Moderator, a Moderator should always be listed as an Editor. LISTSERV currently compares the contents of the "Editor=" and "Moderator=" keywords and consolidates the two sets of parameters if necessary, but coding lists this way is not considered good practice and the "compare/consolidate" feature may be removed in a future upgrade. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.5. Submitting subscriber contributions to an edited list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! By default, LISTSERV forwards subscriber contributions to the Moderator/Editor with the following paragraph prepended to the message body: %Body Text Left%1*( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# This message was originally submitted by JOE@FOO.BAR.COM to the ACCESSL #d6X@DQ@# list at PEACH.EASE.LSOFT.COM. If you simply forward it back to the list, using   a mail command that generates "Resent" fields (ask your local user support or   consult the documentation of your mail program if in doubt), it will be   distributed and the explanations you are now reading will be removed   automatically. If on the other hand you edit the contributions you receive into   a digest, you will have to remove this paragraph manually. Finally, you should   be able to contact the author of this message by using the normal "reply"   function of your mail program.     é Message requiring your approval (25 lines)   [message body] %Code Example 2% * FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 6.1. The "editorheader" prepended by default to subscriber contributions forwarded to the list moderator. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! If you leave this paragraph prepended to the message, LISTSERV will strip it off when it processes the message and to all intents and purposes the message will appear to have come directly from the original sender. Warning: If your mail program or client does not generate Resent fields, the forwarded postings will appear to be coming from you rather than from the original sender.See Section 6.6 for an alternative if your mail program does not generate these fields. When you are ready to edit and/or submit the contribution to the list, simply use the "Forward" function of your mail client. You can make any changes you feel are appropriate to the message body, but be sure to read sections 6.2 and 6.3 above before deciding to do so. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.6. Message Approval with Send= Editor,Hold )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV includes an optional mechanism allowing you to simply "ok" messages which are then posted with all the correct headers. This option is targeted mainly at list moderators who just approve/reject messages, as opposed to people who actually edit the content of messages. The option is also a good choice if you have a mail client that does not insert Resent header lines into forwarded mail. To activate this feature, code your list "Send= Editor,Hold" and be sure that you have defined at least one editor who will be in charge of approving the messages. This defaults to the primary list owner if no other editor is defined. A copy of the message on "hold" is sent to the editor with minimal instructions (in order to avoid adding a long message before the text needing approval each time). To approve a message forwarded to you with Send= Editor,Hold, simply reply to the approval request and type #d6X@DQ@# OK #I2PQP# as the body of your reply. LISTSERV will normally pick up the confirmation request number from the subject line. If there is a problem, LISTSERV may ask you to resend the approval confirmation along with the number. For instance, %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# OK 6A943C %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# If the message has been in the spool longer than the timeout period (default 48 hours; can be increased with the ConfirmDelay=  keyword), you will receive notification that the confirmation number does not match any queued job. If you do not want the message to be forwarded on to the list, you need not do anything. The message will expire automatically at the end of the timeout period and will be deleted from the queue. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.7. Using list topics )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! List topics provide powerful "sublist" capabilities to a list. When properly set up and used, topics give subscribers the ability to receive list postings in a selective manner, based on the beginning of the "Subject:" line of the mail header. It is important to note the following points about topics: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!Topics are best employed on moderated lists. This makes it possible to review the "Subject:" header line to make sure that it conforms to one or more of the topics defined for the list before you forward the post to the list. Not only does this help catch simple errors (such as misspellings of the topic), but it also allows the moderator to add a topic into the subject line if one is not already there. If you employ topics on unmoderated lists, your subscribers must be welleducated in their use. Otherwise, there is no point in using them. Messages that do not conform to a specified topic are lumped into the reserved topic "Other" and are distributed only to subscribers who have explicitly defined "Other" as a topic they wish to receive. Therefore some subscribers will receive the message and some won't, and it is problematic as to whether the message will actually reach the entire audience for which it is intended. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! The basic keyword syntax for defining list topics in the list header file is: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Topics= topic1,topic2,...topic11 %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# And the basic syntax used to set topics for users once they have been defined is: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# SET listname TOPICS: xxx yyy zzz %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# where #d6X@DQ@# xxx #I2PQP#, #d6X@DQ@# yyy #I2PQP#, and #d6X@DQ@# zzz #I2PQP# can be: 4 <DL!4` <DL!A list of all the topics the subscriber wishes to receive. In that case these topics replace any other topics the subscriber may have subscribed to before. For instance, after 'SET XYZL TOPICS: NEWS BENCH', the subscriber will receive news and benchmarks, and nothing else. Updates to the list of topics the subscriber currently receives. A plus sign indicates a topic that should be added, a minus sign requests the removal of a topic. For instance, "SET XYZL TOPICS: +NEWS BENCH" adds news and removes benchmarks. If a topic name is given without a + or sign, + is assumed: "SET XYZL TOPICS: +NEWS BENCH" adds news and benchmarks. The first topic name must have the plus sign to show that this is an addition, and not a replacement. A combination of the above, mostly useful to enable all but a few topics: "SET XYZL TOPICS: ALL MEETINGS". 4` <DL!4 <DL! The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted. The subscriber should not forget to include the special OTHER topic if you want to receive general discussions which were not labeled properly. On the other hand, if the subscriber only wants to receive properly labeled messages it should not be included. ALL does include OTHER. Finally, it is important to note that topics are active only when the subscriber's subscription is set to MAIL. Digests are indexes always contain all the postings that were made, because the same digest is prepared and sent to all the subscribers. With the "DefaultTopics=" keyword, you can also set default topics for users that will be effective as soon as they subscribe to the list. For instance, #d6X@DQ@# * DefaultTopics= NEWS,BENCH,OTHER #I2PQP# would set the new user to receive topics NEWS, BENCHmarks, and any messages that are incorrectly labeled. See Appendix B for more information on setting up and using list topics. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!‘%Body Text Left%6.8. The WELCOME and FAREWELL files )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! When a user subscribes and signs off of a list, LISTSERV looks for list ownersupplied files called listname WELCOME and listname FAREWELL, respectively. If found, it sends the user a copy of the appropriate file in addition to its own administrative message. The WELCOME and FAREWELL files allow the list owner to send a more personal message to the user that can help set the tone for how the list is used. The WELCOME file may contain information about the list charter and netiquette rules, or be simply a message welcoming the user to the list. The FAREWELL file can be used to gather feedback about how the list is serving users. %Body Text Left%Body SubHead#I2PQP#   6.8.1. Creating and storing the listname WELCOME and FAREWELL files  #Body SubHead#Body Text Left#I2PQP# The procedure differs slightly on VM systems, but the following will work for unix, VMS and Windows systems: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.Create the file. If you place a "Subject:" line at the top of the document, i.e., as the first line, LISTSERV will pick that line up and use it as the RFC822 "Subject:" header line. Otherwise, LISTSERV places a generic subject line in the mail message. 2.Be sure that you have defined a "personal password" to LISTSERV with the #d6X@DQ@# PW ADD #I2PQP# command before you #d6X@DQ@# PUT #I2PQP# the welcome file. If you have done this but can't remember the password, send LISTSERV a #d6X@DQ@# PW RESET #I2PQP# command. You will then be able to add a new password with the #d6X@DQ@# PW ADD #I2PQP# command. 3.Send the file to LISTSERV with a #d6X@DQ@# PUT listname WELCOME PW=XXXXXXXX #I2PQP# command at the top of the file, just as if you were putting the list itself. Replace #d6X@DQ@# XXXXXXXX #I2PQP# with your personal password. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! The variation for VM systems is that the LISTSERV maintainer will have to create a fileid for the file before you can #d6X@DQ@# PUT #I2PQP# it on the server. Contact the LISTSERV maintainer before trying to store your WELCOME and/or FAREWELL files. Here is the format of a very simple WELCOME file. (Note that the FAREWELL file is created and stored in an identical manner.) %Body Text Left%1( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# PUT SONGTALK WELCOME PW=XXXXXXXX #d6X@DQ@# Subject: Welcome to Songtalk!  Welcome to Songtalk, the list for Songwriters talking about their work.  Your list owner is Susan Lowell (susan@lsoft.com). %Code Example 2% Ģ FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 6.2.Sample WELCOME file. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%Body SubHead#I2PQP#   6.8.2. Using the listname WELCOME file as a moderation tool  #Body SubHead#Body Text Left#I2PQP# The WELCOME file should contain information geared toward orienting the new subscriber to several areas. The outline of a suggested WELCOME file follows: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.The revision date for the WELCOME file. 2.A heading including the short and long names of the list, along with the name and network address of the primary list owner (or the list owner who handles subscription issues/problems). 3.Any warnings about the list that you want people to see immediately. These might include $Bulleted List$%Bulleted List Indent%#I2PQP#a notice regarding the volume of mail subscribers can expect from the list "any newsgroups that echo the list ftp sites for the list where to send LISTSERV commands where to find more indepth information about the list (if you do a quarterly administrative posting or have a FAQ, where can it be found?) +Bulleted List Indent+Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!4.A short abstract of what the list is all about. This might be a duplicate of the description you send to NEWLIST. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!5.The author includes the following paragraph at this point: $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! 4 <DL! <DL!#Z6X@DQ@# Users new to the use of LSoft's LISTSERV are encouraged to read the online files LISTSERV REFCARD and LISTSERV GENINTRO, which can be obtained by sending the following commands in the body of a mail message to LISTSERV@LISTSERV.NET: #d6X@DQ@##Z6X@DQ@# #d6X@DQ@##Z6X@DQ@# INFO REFCARD #d6X@DQ@##Z6X@DQ@# INFO GENINTRO  <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!6.Any guidelines for use of the list, including the list charter if you have one. 7.Information about the notebook archives and how to retrieve them. 8.Other listspecific information that might be important to new users. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! Naturally, list owners should write WELCOME files based on their own experience of what is needed. A WELCOME file should not be static ! review it once in a while to ensure that it continues to meet the needs of new subscribers. %Body Text Left%Body SubHead#I2PQP#   6.8.3. Using the listname FAREWELL file as a feedback tool  #Body SubHead#Body Text Left#I2PQP# The following FAREWELL file is used on ACCESSL@PEACH.EASE.LSOFT.COM, and is intended as a tool to get feedback from users. ACCESSL's list owner typically receives 35 responses to this message each week. %Body Text Left%1( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# Subject: Your ACCESSL Signoff Request #d6X@DQ@# I'm sorry to see that you're leaving ACCESSL. If there is anything  you believe ACCESSL should have offered but didn't, or there are any  other suggestions you may have for the list, please feel free to write  directly to me.    Sincerely,  Nathan Brindle   ACCESSL List Owner %Code Example 2% IJ FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 6.3.FAREWELL file used as a feedback tool. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%Body SubHead#I2PQP#   6.8.4. The alternative to using WELCOME and FAREWELL files  #Body SubHead#Body Text Left#I2PQP# It is possible to modify LISTSERV's default mail template so that only one message is sent to users when they subscribe and unsubscribe, rather than an administrative message from LISTSERV and a WELCOME or FAREWELL file from the list owner. See Chapter 9 for the details on modifying the default mail templates. However, it is likely that the average list owner will prefer to use the WELCOME and FAREWELL files over changing the morecomplicated templates. Thus both avenues are provided, and may be used depending on the list owner's level of comfort. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.9. Social conventions (netiquette) )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL!#I2PQP##XX2PQXP# Ñ )Section SubHeading) Like so many other things, network users tend to expend a great deal of virtual gunpowder about the subject of etiquette on the network (otherwise known as netiquette). Part of the culture of the network is built on the fact that an individual user can put forward any face he or she cares to present. Thus over time, the network has evolved various sets of rules that attempt to govern conduct. To avoid taking up a great deal of space arguing the merits of differing systems of netiquette, the following general pointers that should be accepted by most users are offered for the convenience of the list owner. %Body Text Left%Body SubHead#I2PQP#   Recognize and Accept Cultural and Linguistic Differences  #Body SubHead#Body Text Left#I2PQP# The Internet is international, and while English is generally accepted as the common language of the network, list owners and list subscribers cannot afford to take the position that everyone on the Internet understands English well. In a medium that is invariably connected to language, special understanding is required to deal with questions or statements from people for whom English is not the primary tongue. Often today (at least in the US) a person's first sustained interaction with others on an international basis is via the Internet. It is imperative that this interaction be on the highest level of cordiality and respect from the outset in order for all concerned to benefit. Additionally, care should be taken when using local idiom and slang. A common word or phrase used by Americans in everyday speech, for instance, might be taken as profanity or insult by those in other Englishspeaking countries, and may not be understood at all by nonnative speakers of English. When a list has a high international readership, it is probably best to avoid nonstandard English so as to provide the clearest and leastobjectionable exchange of ideas. %Body Text Left%Body SubHead#I2PQP#   Private Mail Should Dictate Private Responses    #Body SubHead#Body Text Left#I2PQP#If someone on a mailing list has sent a private message to you (i.e., not to the list at large) and you have lost that person's address but want to respond, do not post private mail to the list. The #d6X@DQ@# REVIEW #I2PQP# command will give you a copy of the list membership that you can search for the person's address. If this approach does not work, contact the local postmaster or the list owner for help. %Body Text Left%Body SubHead#I2PQP#   Flaming is (Usually) Inappropriate    #Body SubHead#Body Text Left#I2PQP#Flames (insults) belong in private mail, if they belong in mail at all. Discussions will often result in disagreements. Rebuttals to another person's opinions or beliefs should always be made in a rational, logical and mature manner, whether they are made publicly or privately. What is a flame can range from the obvious (ranting and raving, abusive comments, etc.) to the notsoobvious (comments about how many "newbies" seem to be on the list these days, "RTFM!" exhortations, etc.). %Body Text Left%Body SubHead#I2PQP#   Foul Language    #Body SubHead#Body Text Left#I2PQP#Subscribers should refrain from abusive or derogatory language that might be considered questionable by even the most liberal and openminded of networkers. If you wouldn't say it in front of your mother, don't say it in electronic mail. %Body Text Left%Body SubHead#I2PQP#   Unsolicited Advertising and Chain Letters  #Body SubHead#Body Text Left#I2PQP# Most of these are contrary to appropriate use policies governing the use of the poster's Internet access provider. Not only that, they are annoying and (in the case of chain letters) often illegal. See Section 6.10 on the subject of "spamming" for more details. %Body Text Left%Body SubHead#I2PQP# ‘%Body Text Left%Other Disruptive or Abusive Behavior  #Body SubHead#Body Text Left#I2PQP# Selfexplanatory. It is rarely possible to catalog all forms of antisocial network behavior. Be sure that you as a list owner cover as many bases as you think necessary when promulgating a code of netiquette for your list. Then ! be sure to adhere to it yourself. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.10. Spamming: what it is, and what to do about it )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! "Spamming" is a network term invented to describe the act of crossposting the same message to as many newsgroups and/or mailing lists as possible, whether or not the message is germane to the stated topic of the newsgroups or mailing lists that are being targeted. A "spam" is defined therefore as either (1) a specific act of spamming, such as the socalled "Green Card Spam", or (2) the message that actually comes to your list as a result of someone initiating a specific act of spamming ("The message you just saw was a spam, and it should be ignored"). Spams are fairly easy to recognize at a quick glance; they often have "To:" fields directed to large numbers of lists, usually in alphabetical order. If a spam gets through to your list, it will probably engender sarcastic replies (often with the spam quoted in its entirety) ! and if your list is coded "ReplyTo= List", they will likely come back to the list. It is therefore imperative that you make subscribers aware that when a spam occurs: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!The person responsible for the spam is probably not subscribed to the list, and any response back to the list will not reach that person. An appropriate response to a spam is to forward a single copy of the spam to the person in charge of the site from which the spam originated ("POSTMASTER", "ROOT", etc.) pointing out that the spammer is probably violating his site's appropriate use policies. It is inappropriate to attempt to flood the spammer's mailbox with network mail in response. This is probably in violation of your network's appropriate use policies, and it just wastes bandwidth. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! Perhaps the best policy an individual subscriber can adopt toward spammers is simply to ignore them and allow list owners and newsgroup moderators to take care of the problem. If this does not work and subscribers send their complaints to the list anyway, it might be a good idea to moderate the list for a few days until the furor dies down. LISTSERV attempts to detect "spams" using a variety of proprietary methods. When LISTSERV decides that a message is a spam, it locks out the user for 48 hours, worldwide in the case of backbone servers.%Body Text Left%# footnote reference##W\  P6QP# footnote text#W\  P6QP## footnote reference##W\  P6QP#` hp x (#4 <DL!#_2PQP#э) footnote reference) In reality this only works with version 1.8b or later servers. List owners running lists on pre1.8b servers can protect themselves from nonsubscriber spams by setting the Editor= parameters in an appropriate manner; however, this introduces new problems that may not be acceptable to the list owner, given the infrequent (but increasing) incidence of spamming. #I2PQP# While locked the user is still able to use LISTSERV normally and to post to mailing lists, but all messages will be forwarded to the list owners for human verification. The user is informed that this has happened but is not informed of which lists caught the message and which didn't, denying him any idea how successful he has been. LSoft will not document how LISTSERV decides a message is a spam because the point has been reached where a number of authors are writing and selling books detailing how to avoid such precautions. If LSoft were to document its methods, the next editions of these books would simply include updated instructions on how to bypass them. ‘ %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 6.11. Appropriate use policies: considerations )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! As a list owner, it is important that you take into consideration any appropriate use policies that might apply to your list. For instance, if your list is hosted by an educational site that has a policy restricting mail with commercial content from being sent out by its users, your list will technically be in violation of that policy if it distributes mail from users advertising commercial services. You would be well advised to request a copy of the appropriate use policy (if any) from your host site and make sure that your subscribers are aware of it by including pertinent sections in your WELCOME file and/or your administrative postings. Host sites are not the only entities that might have appropriate use policies. The network your host is a part of may have such policies as well.%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ7. Overview of List Archives &Section Heading&%.!) #7%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 7.1. What is the list archive? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! The list archive consists of all of the notebook logs for your list. (If your list is coded "Notebook= No", then it does not have a list archive, of course.) Users can find out what notebook logs are available for a specific list by sending the command #d6X@DQ@# INDex listname #I2PQP# to the appropriate LISTSERV host. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 7.2. Setting up and managing archive notebooks )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! If your list is coded "Notebook= No", you should consult your LISTSERV maintainer before changing the keyword to create list archive notebooks. The LISTSERV maintainer will have to tell you where the notebook should be kept (the second parameter in the "Notebook=" keyword). Also note that depending on local policies, you may or may not be allowed to archive your list, or keep more than a few months' or weeks' worth of archives available at a given time. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 7.3. Database Functions Overview [VM only] )Section SubHeading)Body SubHead#I2PQP# 4 <DL!4 <DL!    #Body SubHead#Body Text Left#I2PQP#In this section, we will detail the basics of a LISTSERV command job and show you a sample database query session. Please note that it is not the purpose of this manual to provide the user with a detailed database function reference. See Section 7.4 for more information. %Body Text Left%Body SubHead#I2PQP#     7.3.1. LISTSERV Command Job Language Interpreter    #Body SubHead#Body Text Left#I2PQP#The LISTSERV database command syntax used to access database functions is Englishlike in structure. This syntax is called LISTSERV Command Job Language Interpreter, or CJLI for short. Database commands are sent to LISTSERV in CJLI "batch jobs". When accessing the database in "batch" mode, you must construct a CJLI job which you must then submit to the appropriate server for execution. This means that you must know in advance what you want to do exactly. If you are not familiar with CJLI, you can use the following "job skeleton" to build up your database search job: %Body Text Left%1( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# // JOB Echo=No #d6X@DQ@# Database Search DD=Rules  //Rules DD *  command 1  command 2  ...  /* %Code Example 2% ą FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 7.1. Sample database job skeleton $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! This CJLI job is sent in email to the appropriate LISTSERV host. You will then receive by return email a "DATABASE OUTPUT" file containing the results of your search. This file might look like this: %Body Text Left% 1!( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# > Select * in TESTL #d6X@DQ@# é> Database TESTL, 4 hits.    > Index  Item # Date Time Recs Subject  é   000001 95/10/18 13:09 12 This is a test looking for upcasing  000002 95/08/24 09:18 9  000003 95/10/18 13:09 8 Test please acknowledge receipt  000004 95/10/18 13:09 7 Does ReplyTo=Both work correctly? %Code Example 2%  FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 7.2.Sample DATABASE OUTPUT: Each of the commands in the original job is echoed in the output file (unless specifically disabled). $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! If you realize that the items you were interested in are number 1 and 3, you will have to submit a new job to ask for a copy of them. The new job must include the "Select" command, as LISTSERV does not cache CJLI commands in the expectation that you will send another command job. %Body Text Left%Body SubHead#I2PQP#   7.3.2. A basic database session  #Body SubHead#Body Text Left#I2PQP# Let's say that you are looking for messages in the LSTOWNL mailing list that pertain to the list header keyword "Digest=". You set up a very simple CJLI job as follows and mail it to LISTSERV@SEARN.SUNET.SE: %Body Text Left%1yA( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# // JOB Echo=No #d6X@DQ@# Database Search DD=Rules  //Rules DD *  Select 'Digest=' in LSTOWNL  Index  /* %Code Example 2% y FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 7.3. Sample CJLI job. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! Figure 7.3, when sent to LISTSERV, says: "Look for the string 'Digest=' in all of the archives you have for list LSTOWNL. Then, send me back an index of all messages in the archives that include that string." LISTSERV at SEARN obligingly searches the LSTOWNL archives, finds the following, and sends it back to you in an email message: %Body Text Left%1a( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# > Select 'Digest=' in LSTOWNL #d6X@DQ@# é> Database LSTOWNL, 37 hits.    > Index  Item # Date Time Recs Subject  é   001215 93/01/06 21:58 50 New feature in 1.7f automatic digests  001339 93/01/18 02:46 110 New features for 1.7f "Filter=" and list keyword+  001375 93/01/28 10:02 19 Initial reports from 1.7f beta tests?  001401 93/02/08 16:39 58 Re: List of LISTSERV header keywords?  001616 93/03/18 13:42 70 DIGEST boilerplate announcement/reference  001727 93/04/04 15:22 916 Changes from release 1.7e to 1.7f  .... %Code Example 2%  FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 7.4. Part of the LISTSERV response to the CJLI job in Figure 7.3. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! The next step is to send a CJLI job to request the specific message(s) you are interested in. Let's say that you are interested in changes from one version of LISTSERV to another, and you therefore would like to see messages 1215, 1339, and 1727. You set up the following CJLI framework: %Body Text Left%1f( @ddCode Example 2#P6X@DQ@# %Body Text Left%// JOB Echo=No #d6X@DQ@# Database Search DD=Rules  //Rules DD *  Select 'Digest=' in LSTOWNL  Print 1215 1339 1727  /* %Code Example 2% f FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 7.5. CJLI job instructing LISTSERV to send specific messages to the requestor. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! This example says: "Look for the string 'Digest=' in all of the archives you have for list LSTOWNL. Then, send me back message numbers 1215, 1339 and 1727." LISTSERV will repeat the search from Figure 7.3 and will package the three messages you have requested into a return mail message and send it back to you. %Body Text Left%Body SubHead#I2PQP#   7.3.3. Narrowing the search  #Body SubHead#Body Text Left#I2PQP# It is possible to add further parameters to your search in order to narrow it. You can limit a search by date with a "since. . . " predicate. Likewise, you can limit by sender and/or by the subject line with a "where . . ." predicate. For instance: %Body Text Left%Code Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# Select 'Digest=' in LSTOWNL since 94/01/01 #d6X@DQ@# Select 'Digest=' in LSTOWNL where sender contains 'Thomas'  Select * in LSTOWNL where sender is ERIC@SEARN  Select * in LSTOWNL since 94/01/01 where subject contains 'Digest' %Code Example 2%Body Text Left#I2PQP##d6X@DQ@##I2PQP# are all valid search commands that will (hopefully) dramatically reduce the number of index or print entries returned to you. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 7.4. Where to find more information on Database Functions )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! You can get more detailed information on database functions and the database command syntax by requesting the file LISTDB MEMO from LISTSERV@LISTSERV.NET or from any other LISTSERV host. You can send either a "GET LISTDB MEMO" command or an "INFO DATABASE" command to retrieve the file.%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ8. Overview of File Archives &Section Heading&%.!) #8%Body Text Left#I2PQP# There are three file server systems currently in use or under development for LISTSERV: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!The VM (mainframe) version of LISTSERV supports the "traditional" file server system. While it is very powerful, this file server system dates back to 1986 and suffers from a few annoying limitations. In addition, it is written in a non portable language. This will be replaced with the "new" file server system, currently under development. The workstation and PC versions of LISTSERV support a "temporary" file server system, to provide an interim solution while the new system is being developed. This temporary system only supports a subset of the functions of the traditional system. The "new", portable file server system will be a superset of the traditional system, in terms of functionality. Most end user commands will continue to work as before. However, there is no guarantee that the internal data files manipulated by the file server functions will remain as before. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! In general, the three systems are compatible, with the understanding that the temporary system does not include all the possible options. However, the mechanism for registering files (defining them to the file server system) is different. Since the first two systems are going to be replaced by the third system (projected for the end of 1995), rather than providing an exhaustive chapter detailing all filelist aspects from the list owner side, we have provided only a basic overview of the two systems currently in the field, with pointers to where further information may be obtained. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.1. What is the file archive? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! The file archive consists of all files other than notebook logs that have been stored on the LISTSERV host for your list. Users can find out what files are available for a specific list by sending the command #d6X@DQ@# INDex listname #I2PQP# to the appropriate LISTSERV host. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.2. Starting a file archive for your list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! With the traditional system (running on the VM servers), the LISTSERV maintainer creates files called "xxxx FILELIST", which contain definitions for all the files belonging to a particular archive. With the temporary system, the LISTSERV maintainer stores these definitions in a file called SITE.CATALOG, in the MAIN directory. While files called "xxxx FILELIST" can be created and users can retrieve them, they do not in turn define further files. The new file server system will eliminate this confusion, but in the meantime you should be aware of the differences between VM and workstation file server functions as many list owners use a VM server with different conventions, and may give you incorrect advice. Under VM systems, FILELIST files must be created by the LISTSERV maintainer at the site before they can be edited by the list owner.%Body Text Left%# footnote reference##W\  P6QP#^ footnote text#W\  P6QP## footnote reference##W\  P6QP#` hp x (#4 <DL!#_2PQP#э) footnote reference)#;2PQP# #B2PQP#If you are interested in the mechanics of starting a VMtype filelist, the best reference is "Setting Up the LISTSERV File ServerA Beginner's Guide" by Ben Chi (bec@albany.edu). This publication is available from LISTSERV@ALBANY.EDU as FSV GUIDE.^#I2PQP# On workstation and PC systems, the LISTSERV maintainer must register files in the site catalog. While FILELIST files can be created on nonVM systems and can be retrieved by users, they do not in turn provide pointers for LISTSERV to other files existing on the server. Since the current system for workstations and PCs will be replaced, LSoft does not recommend that separate FILELISTs be created on these systems unless there is a pressing reason to do so. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.3. Filelist maintenance (VM systems only) )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Maintaining the filelist for your archive is not difficult. It requires only that you have a working knowledge of VM XEDIT (or your local system's editor) and understand how to send files via email. %Body Text Left%Body SubHead#I2PQP#   8.3.1 Retrieving the filelist  #Body SubHead#Body Text Left#I2PQP# To retrieve your filelist in an editable format, send the command %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# GET listname FILELIST PW=XXXXXXXX (CTL %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# to the LISTSERV host where the filelist is stored. The #d6X@DQ@# (CTL #I2PQP# switch causes LISTSERV to lock the filelist until you store it again or explicitly unlock it with an #d6X@DQ@# UNLOCK listname FILELIST #I2PQP# command. (If you don't want to lock the filelist, use #d6X@DQ@# (CTL NOLOCK #I2PQP# instead.) If your mail account is not located on the same host as LISTSERV, you will need to provide your personal password (same as your password for getting and putting your lists). A filelist retrieved with the (CTL option does not look like the filelist you get with an INDEX command. A sample (CTL option filelist appears below: %Body Text Left%1G( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# * Files associated with MYLIST and available to subscribers: #d6X@DQ@# * rec last change  * filename filetype GET PUT fm lrecl nrecs date time Remarks  *   MYLIST POLICY ALL OWN V 79 45 94/03/16 12:04:23 Mission Statement  MYLIST BOOKLIST ALL OWN V 79 177 94/04/19 16:24:57 Books of interest  MYLIST QUARTER ALL OWN V 73 113 95/03/11 08:57:04 Quarterly posting    * Listowner's files (not public)  MYLIST FAREWELL OWN OWN V 78 9 95/03/11 08:53:41 Goodbye memo  MYLIST WELCOME OWN OWN V 73 105 95/03/11 09:14:38 Hello memo %Code Example 2% G FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 8.1.Sample filelist retrieved with (CTL option. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! Note that the filelist does not include the comment lines you would normally see at the top of an INDEX filelist; nor does it include any notebook archives. LISTSERV creates these lines dynamically at the time the INDEX command is received from a user. If the filelist you have retrieved has any of this kind of material in it, either a) you have not retrieved the filelist correctly, or b) you or someone else has stored the filelist previously with this material included. If you did a GET with (CTL, you should be able to remove these extraneous lines by simply deleting them. If you do an INDEX of your archive and it has (for instance) two sets of comment lines or duplicate notebook archive listings, then you should GET the filelist with (CTL and edit out the offending lines. While the extra lines will not affect the operation of the file server, they are a source of potential confusion for your users. %Body Text Left%Body SubHead#I2PQP#     8.3.2 Adding file descriptors to the filelist  #Body SubHead#Body Text Left#I2PQP# "Adding a file to a filelist" is not exactly accurate terminology, although it is a widelyused phrase. Adding files to file archives is a twostep process: First, add a file descriptor to the appropriate filelist and store the filelist on the server. Second, store the file itself on the server. ‘ To add a file descriptor, start a line with a space and then type in your file's name, access codes, five dots (periods) and a short description, each separated by a space. For example: %Body Text Left%Code Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# MYLIST FAQ ALL OWN . . . . . FrequentlyAsked Questions for MYLIST %Code Example 2%Body Text Left#I2PQP##d6X@DQ@##I2PQP# Note that the line must begin with a space. Also, you must place five dots separated by spaces between the PUT file access code (here it is #d6X@DQ@# OWN #I2PQP#) and the short description. These dots are place holders for the record format (recfm), longest record length (lrecl), number of records (nrecs), and the date and time of the last update. If these dots are not present, LISTSERV will return an error message when you try to store the filelist. You will note that the line you have just added does not look like the other lines in the filelist. Ignore the "pretty" formatting. LISTSERV will reformat the information for you. After adding the line, your filelist should look like this: %Body Text Left%1( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# * Files associated with MYLIST and available to subscribers: #d6X@DQ@# * rec last change  * filename filetype GET PUT fm lrecl nrecs date time Remarks  *   MYLIST POLICY ALL OWN V 79 45 94/03/16 12:04:23 Mission Statement  MYLIST BOOKLIST ALL OWN V 79 177 94/04/19 16:24:57 Books of interest  MYLIST QUARTER ALL OWN V 73 113 95/03/11 08:57:04 Quarterly posting  MYLIST FAQ ALL OWN . . . . . FrequentlyAsked Questions for MYLIST    * Listowner's files (not public)  MYLIST FAREWELL OWN OWN V 78 9 95/03/11 08:53:41 Goodbye memo  MYLIST WELCOME OWN OWN V 73 105 95/03/11 09:14:38 Hello memo %Code Example 2% Ģ FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 8.2.Adding a file descriptor to the filelist $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! Note that you can add comment lines to the filelist by placing an asterisk in the leftmost column instead of a space. Comment lines can act as indexes, descriptions, or pointers to other resources. Once you are finished adding file descriptors, save the filelist to disk. %Body Text Left%Body SubHead#I2PQP#   8.3.3. File Access Codes (FAC) for user access  #Body SubHead#Body Text Left#I2PQP# FACs define which users have access to files in the file archive. The FAC for GET indicates who may retrieve the files, and the FAC for PUT indicates who may store the files on the server. (Note that some special FACs exist for "superusers" such as the LISTSERV maintainer(s) and the LISTSERV Master Coordinator, who may GET and PUT any file regardless of its GET/PUT permissions.) The basic FAC codes that are always available are: 4 <DL!4<DL!ALLuniversal access. PRVonly members of the associated mailing list have access. OWNonly the owners of the associated mailing list have access. 4<DL!4 <DL! (Note that this assumes the name of the filelist is identical to the name of the associated mailing list ! for instance, MYLIST@FOO.BAR.EDU would have a MYLIST LIST file and a MYLIST FILELIST file. Ask your LISTSERV maintainer for assistance if this is not the case or if you need special FACs added for special user access to files.) %Body Text Left%Body SubHead#I2PQP#       Ñ8.3.4 Deleting files from the filelist  #Body SubHead#Body Text Left#I2PQP# Before you delete files from the filelist, you should delete the files themselves from LISTSERV's archive disk. To do this, send the following command to LISTSERV without including any replacement data: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# PUT filename filetype filelist %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# For instance, %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# PUT MYLIST FAQ MYLIST %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# If this step is not followed, LISTSERV may not be able to find the file you want to delete after you edit the filelist and store it. %Body Text Left%Body SubHead#I2PQP#   8.3.5. Storing the filelist  #Body SubHead#Body Text Left#I2PQP# %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.Create a mail message to LISTSERV at the appropriate host. (Sending a filelist to LISTSERV@LISTSERV.NET will not work. The filelist must be sent to the host it resides on.) 2.Include the filelist file as plain text in the body of the mail message. Do not attach it with MIME or another encoding scheme, as LISTSERV does not translate encoded messages. 3.Make sure that your mail client does not automatically add a signature file to the bottom of your mail. If it does, your signature file will be treated as part of the filelist and will be stored along with it. 4.At the top of the filelist, add a single line as follows: $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# PUT filename FILELIST PW=XXXXXXXX %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!where #d6X@DQ@# XXXXXXXX #I2PQP#is your personal password for LISTSERV on that host. Note that this is similar to the PUT command used when storing the list file. 5.Send the filelist to LISTSERV. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! Once LISTSERV acknowledges the receipt and storage of the filelist, you can send the files that correspond to the file descriptors in your filelist. See section 8.5, below, for instructions. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.4. Giving other users access to files on workstation systems )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! To register a new file to the server on workstation systems, the LISTSERV maintainer adds a line to the SITE.CATALOG file. Here is what a typical SITE.CATALOG entry looks like: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# MY.FILE MY.FILE.C:\FILES\XYZ XXX YYY %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# The first item, MY.FILE, is the name by which the file is known to LISTSERV. That is, the users will use GET MY.FILE to order a copy of that file. The name should only contain one period. Only the first 8 characters of the name and the first 8 characters of the extension are shown by the INDEX command. This restriction will be removed with the new file server system. ‘The second item, MY.FILE.C:\FILES\XYZ, is the name LISTSERV will use for the actual disk file: filename, period, extension, period, directory. The strange format is because LISTSERV uses an operating system abstraction layer for file accesses, where all systemdependent attributes are relegated to the last item. Note that the directory must be created before you register the file. For security reasons, LISTSERV will not create the directory (or set the protections) for you. Note that LISTSERV will normally need full access to these files. The third and fourth items are "File Access Codes" (FACs). The first is for read accesses, and the second for writing. The following file access codes are available: 4 <DL!4<DL!ALLuniversal access. PRIVATE(xxx)only members of the xxx list have access. OWNER(xxx)only the owners of the xxx list have access. SERVICE(xxx)only users in the service area of the xxx list have access. NOTEBOOK(xxx)same access as the archives of the xxx list. user@hostthe user in question is granted access. 4<DL!4 <DL! Except for ALL, which must occur on its own, multiple file access code entries can be specified, separated by a comma with no intervening space. For instance: %Body Text Left%Code Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# MY.FILE MY.FILE.C:\FILES\XYZ JOE@XYZ.EDU,JACK@XYZ.EDU,PRIVATE(XYZL) CTL %Code Example 2%Body Text Left#I2PQP##d6X@DQ@##I2PQP# defines a file that Joe, Jack and the subscribers of the XYZL list can order via the GET command, but that only the LISTSERV administrator can update. IMPORTANT: These "file access codes" apply to LISTSERV commands (GET, PUT, INDEX) only, and not to the workstation or PC's file security system. It is your responsibility to protect the actual disk file by setting the file protections for the directory in which they are created. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.5. Storing files on the host machine )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! To store a file on any LISTSERV host, first ensure that it has been registered with an entry in a filelist or the site catalog. Then mail the file to LISTSERV with a single line at the top of the document: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.Edit your file and save it. Add a single line at the top of the file as follows: #d6X@DQ@# $Bulleted List$Code Example 1#d6X@DQ@# 4` <DL!` <DL! PUT filename.extension PW=XXXXXXXX %Code Example 1%Bulleted List#I2PQP#` <DL!4` <DL!#d6X@DQ@##I2PQP# (This line will not appear to people who GET the file from LISTSERV.) Replace #d6X@DQ@# XXXXXXXX #I2PQP# with your personal password. 2.Be sure that the file has been registered with an entry in a filelist or the site catalog. 3.Be sure that you have defined a "personal password" to LISTSERV with the #d6X@DQ@# PW ADD #I2PQP# command before you #d6X@DQ@# PUT #I2PQP# the new or edited file. If you have done this but can't remember the password, send a #d6X@DQ@# PW RESET #I2PQP# command to LISTSERV, then a new #d6X@DQ@# PW ADD #I2PQP# command. 4.Send the mail message to LISTSERV. $Bulleted List$#Section SubHeading##XX2PQXP# 4` <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP#  #I2PQP##XX2PQXP#  #I2PQP##XX2PQXP# Ñ8.6. Automatic File Distribution (AFD) and File Update Information (FUI) )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! AFD and FUI have not yet been ported to the workstation and PC environments. However, this feature is supported on VM and will be supported in the near future on the other platforms. These two features are similar in their command syntax, but do different things. AFD provides a method whereby users may subscribe to specific files, which will be sent to them any time the files are updated. For instance, if you have a FAQ file that is updated monthly, a user could send an AFD subscription to that FAQ file and LISTSERV would send it to the user every time you updated and stored the FAQ. FUI, on the other hand, is a method whereby a user subscribes to a file but receives only a notification that the file has been updated. The user can then GET the file at his own discretion. AFD and FUI can be passwordprotected to protect users from network hackers who might forge mail from the user subscribing him to large or frequentlyupdated files. If a password is not provided in an AFD or FUI ADD command, LISTSERV warns the user that it would be a good idea to password protect the subscription. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.7. File "Packages" )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! This feature has not yet been ported to the workstation and PC environments. However, this feature is supported on VM and will be supported in the near future on the other platforms. You can define a group of files as a "package" that can be retrieved by users with a single GET command. First, ensure that all the files in the package are defined in the appropriate filelist and stored on the server as detailed above. Next, create a file descriptor in the filelist for a file called #d6X@DQ@# filename $PACKAGE #I2PQP# , where filename is the name you have chosen for the group of files. Be sure that the filetype is $PACKAGE, with a $ sign, and store your filelist. Now create a file called #d6X@DQ@# filename $PACKAGE #I2PQP# that looks like this: %Body Text Left%Code Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# * MYLIST $PACKAGE #d6X@DQ@# * Packing list for MYLIST PACKAGE  *   * You can make other comments here, such as   * the contact email address.  *  * filename filetype filelist  *=======================  MYLIST $PACKAGE MYLIST  INTEREST FILE MYLIST  NETIQUET FILE MYLIST  ANOTHER FILE MYLIST %Code Example 2%Body Text Left#I2PQP##d6X@DQ@##I2PQP# Note that anything that is not the name of a file in the package must be commented out with an asterisk in the leftmost column of the line. It is possible to create a package file without any comment lines at all, but this is not preferable in practice. Often users will get the package file itself just to see what is in it. You should include a reference to the package file itself so that the user will get a copy of the "packing list" to check against the files he receives from LISTSERV. The final step is to send the package file to LISTSERV like any other file. ‘ Now users can do one of two things: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.They may get the entire package of files sent to them by sending LISTSERV the command #d6X@DQ@# GET filename PACKAGE #I2PQP# (without the $ sign); or 2.They may request that LISTSERV send only the package file itself by sending LISTSERV the command #d6X@DQ@# GET filename $PACKAGE #I2PQP# (with the $ sign). $Bulleted List$Body Text Left#I2PQP# Packages may be subscribed to with the AFD and FUI commands. 4` <DL!4 <DL! %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 8.8. Where to find more information on File Archives )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! A number of guides that refer to File Archive setup and maintenance are referenced in Appendix D, Related Documentation and Support.%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ9. Customizing LISTSERV's Default Mail Templates Chapter9  &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 9.1. What LISTSERV uses mail templates for )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Mail templates are used to generate some of the mail LISTSERV sends to users in response to commands it receives. Among these are the "You are now subscribed . . ." message, the message sent to users when LISTSERV cannot find a subscription for them in a specified list, and others. Note that certain administrative mail (for instance, the response to the STATS and RELEASE commands) is hardcoded into LISTSERV and cannot be changed. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 9.2. The DEFAULT.MAILTPL file and how to get a copy )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV stores the default mail template information in a file called DEFAULT.MAILTPL, which can be requested by list owners from LISTSERV with the GET command, just like any other file. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 9.3. Mail template format and embedded formatting commands )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Each template starts with a form name and subject line, such as: %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# >>> EXAMPLE1 This is the subject line %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# The template starts with the line containing the form name and subject, and ends with the next line starting with '#d6X@DQ@# >>> #I2PQP#', or at the end of the file. The subject line may contain substitutions (such as "#d6X@DQ@# &LISTNAME: &WHOM requested to join #I2PQP#"). Ensure that there is a blank space between #d6X@DQ@# >>> #I2PQP# and the name of the form, or LISTSERV will not recognize the form. The template contains text and, optionally, formatting/editing commands, which start with a period in column 1. All other lines are treated as normal text: sequences starting with an #d6X@DQ@# & #I2PQP# sign are substituted, then lines are joined together to form a paragraph, which is finally formatted like with any nonWYSIWYG text processor. You can suspend formatting with #d6X@DQ@# .FO OFF #I2PQP# and resume it with #d6X@DQ@# .FO ON #I2PQP#; when formatting is suspended, LISTSERV no longer joins lines to form a paragraph, but simply writes one line of text to the message for each line read from the template. This makes it possible to include tables or a textmode logo, but can create seriously imbalanced text if substitutions are used. For instance, a typical &WHOM substitution can range from a dozen characters to 60 or more, even though it only takes up 5 characters on your screen when you enter it. The following substitutions are always available: #d6X@DQ@# &DATE #I2PQP#Longstyle date (29 Jul 1993) #d6X@DQ@# &TIME #I2PQP#hh:mm:ss #d6X@DQ@# &WEEKDAY #I2PQP#Threeletter day of the week, in English 4 <DL!4 <DL!#d6X@DQ@# &MYNAMES #I2PQP#The substitution you will use most of the time when you need to refer to LISTSERV. For Internetonly or BITNETonly servers, this will display LISTSERV's only email address. For servers with both Internet and BITNET connectivity, it will say "LISTSERV@hostname (or LISTSERV@nodeid.BITNET)". 4 <DL!4 <DL! 4 <DL!4 <DL!#d6X@DQ@# &MYSELF #I2PQP#LISTSERV's address, in the form LISTSERV@XYZ.EDU or, if no Internet hostname is available, LISTSERV@XYZVM1.BITNET. 4 <DL!4 <DL!‘ 4 <DL!4 <DL!#d6X@DQ@# &MYNODE #I2PQP#LISTSERV's BITNET nodeid, without the '#d6X@DQ@# .BITNET #I2PQP#', or its Internet hostname if no NJE address is available. 4 <DL!4 <DL! 4 <DL!4 <DL!#d6X@DQ@# &MYHOST #I2PQP#LISTSERV's Internet hostname or, if none is available, its NJE address (with '#d6X@DQ@# .BITNET #I2PQP#'). 4 <DL!4 <DL! 4 <DL!4 <DL!#d6X@DQ@# &MBX(addr) #I2PQP#Looks up the specified address in LISTSERV's signup file and displays "name " if a name is available, or just the original address otherwise. This is typically used to give the name of the command originator or target, along with his email address: #d6X@DQ@# &MBX(&WHOM) #I2PQP# or #d6X@DQ@# &MBX(&INVOKER) #I2PQP#. #d6X@DQ@# &RELEASE #I2PQP#LISTSERVs release number (e.g., 1.8b). #d6X@DQ@# &OSTYPE #I2PQP#The operating system under which LISTSERV is running, e.g., VM/VMS/unix/Windows. #d6X@DQ@# &OSNAME #I2PQP#The full operating system name including the version number, e.g., VM/ESA 1.2.3, Windows NT 3.51, Linux 1.1.88, SunOS 5.4, etc. #d6X@DQ@# &HARDWARE #I2PQP#The type of machine LISTSERV is running on, e.g., Pentium (32M). 4 <DL!4 <DL!The following substitutions are also available for templates related to mailing lists: 4 <DL!4 <DL!#d6X@DQ@# &LISTNAME #I2PQP#The name of the list per the ListAddress=  keyword or its default value. #d6X@DQ@# &TITLE #I2PQP#Title of the list, or empty string. #d6X@DQ@# &KWD(kwd) #I2PQP#Value of the specified keyword for the list. You do not need to specify the name of the list it is implicit. You need not put quotes around the keyword names either, although quotes will be accepted if present. Optionally, you can specify a second numeric argument to extract just one of the terms of a list header keyword; for instance, if the list header contains "Notebook= Yes,L1,Monthly, Private", #d6X@DQ@# &KWD(NOTEBOOK,4) #I2PQP# has the value "Private". A third argument, also optional, specifies the default value for the keyword in case it was not initialized. It is meant to be used for conditional formatting in the default templates and list owners should not worry about it. 4 <DL!4 <DL! In addition, many templates have their own specific substitutions, meaningful only in their specific context. For instance, a message informing a user that he was removed from a mailing list may have an #d6X@DQ@# &INVOKER #I2PQP# substitution for the address of the person who issued the DELETE command. This is not meaningful for a template informing a user that he must confirm his subscription to a list within 10 days, so it is not generally available. If you attempt to use a substitution which is not available, the template processor writes an error message to the mail message it is generating, but sends it anyway, in the hope that the recipient will be able to figure out the meaning of the message in spite of the error. If you need to include a sentence with an ampersand character, you will have to double it to bypass the substitution process, as in "#d6X@DQ@# XYZ &&co. #I2PQP#" Any line starting with a period in column 1 is processed as a formatting command. Note that neither substitutions nor formatting commands are case sensitive. Here is a list of the formatting commands list owners may need to use: 4 <DL!4 <DL!#d6X@DQ@# .* #I2PQP#Comment: anything on this line is simply ignored. This is useful for recording changes to template files when there are multiple owners. Just add a comment line with the date and your initials every time you make a change, for the benefit of the other owners. #d6X@DQ@# .FO OFF #I2PQP#Turns off formatting: one template line = one line in the final message. You can resume formatting with #d6X@DQ@# .FO ON #I2PQP#. #d6X@DQ@# .CE text #I2PQP#Centers the text you specify (just the text you typed on the same line as the #d6X@DQ@# .CE #I2PQP# command). This can be useful to highlight the syntax of a command. #d6X@DQ@# .RE OWNERS #I2PQP#Adds a 'ReplyTo:' field pointing to the list owners in the header of the generated message. Use this command when you think users are likely to want to reply with a question. You can also use #d6X@DQ@# .RE POSTMASTER #I2PQP# to direct replies to the LISTSERV administrator, if this is more appropriate. #d6X@DQ@# .CC OFF #I2PQP#Removes all "cc:" message recipients, if any. You can also add message recipients by specifying a series of email addresses after the #d6X@DQ@# .CC #I2PQP# statement, as in #d6X@DQ@# .CC JOE@XYZ.EDU #I2PQP#. PC mail users should note that in this context "cc:" is a RFC822 term that stands for "carbon copy". RFC822 messages may have "cc:" recipients in addition to their "primary" recipients. There is no real technical difference between the two, the "cc:" indicator just denotes a message that is being sent for your information. Some administrative messages sent to list owners are copied to the user for their information, and viceversa; this behavior can be disabled by adding a #d6X@DQ@# .CC OFF #I2PQP# statement to the template. #d6X@DQ@# .TO #I2PQP#Replaces the default recipients of a message with the value specified. For instance, if you use the ADDREQ1 template to send new subscribers a questionnaire, application form or similar material, you will need to add a '.TO &WHOM' instruction to your modified template, as by default the user will not receive a copy. #d6X@DQ@# .QQ #I2PQP#Cancels the message. LISTSERV stops reading the template and does not send anything. This is useful if you want to completely remove a particular message; note however that this can be confusing with certain commands, as LISTSERV may say "Notification is being sent to the list owners" when in fact nothing will be sent because of the #d6X@DQ@# .QQ #I2PQP# command in the template. 4 <DL!4 <DL!A number of more advanced commands are available to list owners with more sophisticated needs and some programming experience. If you encounter one of these commands in a template, you will probably want to leave it alone. 4 <DL!4 <DL! #d6X@DQ@# .IM name #I2PQP#Imbeds (inserts) another template at this point in the message. This is used to avoid duplicating large pieces of text which are mostly identical, such as the templates for "you have been added to list X by Y" and "your subscription to list X has been accepted". #d6X@DQ@# .DD ddname #I2PQP#Copies the contents of the specified DD into the message. This is meaningful only if a DD has been set up by LISTSERV for this purpose. As a rule of thumb, you should either leave these statements unchanged or remove them. #d6X@DQ@# .BB cond #I2PQP#Begin conditional block. The boolean expression following the keyword is evaluated and, if false, all the text between the #d6X@DQ@# .BB #I2PQP# and #d6X@DQ@# .EB #I2PQP# delimiters is skipped. Conditional blocks nest to an arbitrary depth. The expression evaluator is recursive but not very sophisticated; the restriction you are most likely to encounter is that all subexpressions have to be enclosed in parentheses if you are using boolean operators. That is, "#d6X@DQ@# .BB &X = 3 #I2PQP#" is valid but "#d6X@DQ@# .BB &X = 3 and &Y = 4 #I2PQP#" is not. String literals do not require quoting unless they contain blanks, but quotes are accepted if supplied. Comparison operators are #d6X@DQ@# = <> ^= IN #I2PQP# and #d6X@DQ@# NOT IN #I2PQP# (the last two look for a word in a blankseparated list of options, such as a keyword value). These operators are not casesensitive; #d6X@DQ@# == #I2PQP# and #d6X@DQ@# ^== #I2PQP# are available when case must be respected. Boolean operators are #d6X@DQ@# AND #I2PQP# and#d6X@DQ@# OR #I2PQP#. 4 <DL!4 z <DL!#d6X@DQ@# .SE var text #I2PQP#Defines or redefines a substitution variable. This is convenient for storing temporary (text) expression results which need to be used several times. Even standard variables such as #d6X@DQ@# &LISTNAME #I2PQP# can be redefined at your own risk. You must enclose the text expression in single quotes if you want leading or trailing blanks. 4 z <DL!4 <DL! #d6X@DQ@# .TY text #I2PQP#Types one line of text on the LISTSERV console log. This can be useful to the LISTSERV maintainer for debugging, and also to record information in the console log. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 9.4. Creating and editing a .MAILTPL file for a list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Make a copy of DEFAULT.MAILTPL on your local machine and name it listname.MAILTPL.%Body Text Left%# footnote reference##W\  P6QP#Q footnote text#W\  P6QP## footnote reference##W\  P6QP#` hp x (#4 <DL!#_2PQP#э) footnote reference) If your local machine is running MSDOS and/or Windows 3.x, obviously this will not workyou will have to conform to the 8.3 naming convention. Probably the best thing to do in this case is simply name the file listname.mai, then rename it when you upload it to a mainframe or network workstation account.Q#I2PQP# Keep the original DEFAULT.MAILTPL around in case you make a mistake and need to start over. At this point, you could theoretically store the listname.MAILTPL back on the LISTSERV host. However, without making any changes that would be somewhat pointless. At the very least you should edit the INFO section before storing the template. Note also that you need only store the sections of the template that you have changed. For instance, if you edit the INFO section but leave the rest of the template untouched, you can delete the rest of the template and store the INFO section alone as listname.MAILTPL. The benefit to this approach is that any administrative changes to the rest of the default template are automatically applicable to your list as soon as they are made, rather than requiring that you edit your mail template individually to reflect such changes. LSoft recommends that this approach be followed as the default. %Body Text Left%Body SubHead#I2PQP#   9.4.1. The INFO section  #Body SubHead#Body Text Left#I2PQP# The first section of DEFAULT.MAILTPL is called the INFO section, and it is LISTSERV's response to the command #d6X@DQ@# INFO listname #I2PQP#. By default, it contains the following: %Body Text Left%1-( @ddCode Example 2#P6X@DQ@# %Body Text Left% >>> INFO Information about the &LISTNAME list #d6X@DQ@# There is no information file for the &LISTNAME list. Here is a copy of  the list "header", which usually contains a short description of the  purpose of the list, although its main purpose is to define various  list configuration options, also called  "keywords". If you have any question about the &LISTNAME list, write to  the list owners at the generic address:    .ce &LISTNAMERequest@&MYHOST    .dd &LISTHDR %Code Example 2% - FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 9.1.The default contents of the INFO section of DEFAULT.MAILTPL. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! Note the replaceable parameters #d6X@DQ@# &LISTNAME #I2PQP# and #d6X@DQ@# &MYHOST #I2PQP#. Don't change #d6X@DQ@# &MYHOST #I2PQP#; LISTSERV replaces it with the correct value for the name of the host site. #d6X@DQ@# &LISTNAME #I2PQP# automatically inserts the name of the list. It's probably best to use #d6X@DQ@# &LISTNAME #I2PQP# to refer to the list throughout the document rather than to replace it with something like "MYLISTL". This ensures that the mail template will be consistent with the default and will be simpler to debug should a problem arise. Also, in the event the name of the list changes, it will be unnecessary to edit the mail template (although it would have to be renamed to match the new name of the list, of course). Should it be desirable to replace the default INFO section with information about the list, it is probably best to remove the #d6X@DQ@# .dd &LISTHDR #I2PQP# line. This line instructs LISTSERV to read in the header of the list and add it to the response in lieu of any other data about the list. Many list owners add descriptive comment lines to their list headers, thus this default. Here is a minimallyedited sample INFO section for a list called MONKEYS:%Body Text Left%# footnote reference##W\  P6QP#7 footnote text#W\  P6QP## footnote reference##W\  P6QP#` hp x (#4 <DL!#_2PQP#э) footnote reference) Thanks to Marty Hoag of NEWLIST.7#I2PQP# %Body Text Left%1( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# >>> INFO Information about the &LISTNAME list #d6X@DQ@# &LISTNAME is an open, unmoderated discussion list featuring  monkeys. Things such as how to care for a pet monkey, monkey  diseases, monkey lore, endangered species of monkeys, and  monkey psychology are likely to be discussed. The list is  NOT intended for discussion of Darwinism and/or theories of  evolution.    If you have any question about the &LISTNAME list, write to  the list owners at the generic address:    .ce &LISTNAMERequest@&MYHOST %Code Example 2% Ċ FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 9.2.Sample edited INFO section for a mail template. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! %Body Text Left%Body SubHead#I2PQP#   9.4.2. Other useful templates  #Body SubHead#Body Text Left#I2PQP# Version 1.8b introduced many new configurable message templates, and, in particular, two new types of message templates for "linear" and optional messages. Traditionally, message templates have contained the text of "long" administrative messages, such as messages informing subscribers that they have been removed from a mailing list. These notices were sent unconditionally, as a separate message. The template processor now supports "linear" messages, which are sent as a normal command reply and allow the list owner to modify the replies from selected commands, and "optional" messages, which are only sent if a template for this action has been specifically provided by the list owner. Here is a list of these template messages: 4 <DL!4` <DL!1#d6X@DQ@# SUB_CLOSED #I2PQP# (linear): this is the message that is sent to a subscriber attempting to join a list with "Subscription= Closed". The default is "Sorry, the #d6X@DQ@# &LISTNAME #I2PQP# list is closed. Contact the list owner (#d6X@DQ@# &OWNER #I2PQP#) for more information." 4` <DL!4 <DL!‘ 4 <DL!4` <DL!1#d6X@DQ@# SUB_OWNER #I2PQP# (linear): this message is sent to a subscriber attempting to join a list with "Subscription= By owner". The default is "Your request to join the #d6X@DQ@# &LISTNAME #I2PQP# list has been forwarded to the list owner for approval. If you have any question about the list, you can reach the list owner at #d6X@DQ@# &OWNER #I2PQP#." Because this is a linear template (see below), it is not the best place to put long questionnaires, application forms, terms and conditions, or other material that the subscriber should be required to review prior to joining the list. See the "Tips" section below. 4` <DL!4 <DL! 4 <DL!4` <DL!1#d6X@DQ@# POST_EDITOR #I2PQP# (linear): this is the message LISTSERV sends to people attempting to post to the list, if it is moderated. The default is "Your #d6X@DQ@# &MESSAGE #I2PQP# has been submitted to the moderator of the #d6X@DQ@# &LISTNAME #I2PQP# list: #d6X@DQ@# &MBX(&MODERATOR) #I2PQP#." 4` <DL!4 <DL! 4 <DL!4` <DL!1#d6X@DQ@# TOP_BANNER #I2PQP#, #d6X@DQ@# BOTTOM_BANNER #I2PQP# (optional): when these templates are present, their contents are automatically inserted at the top (respectively bottom) of each and every message posted to the list. Typically, the top banner would be used for a copyright or short legal warning which absolutely has to be seen by each and every reader. The bottom banner could contain instructions for signing off the list, a disclaimer, an acknowledgement of a sponsor's contribution, a "tip of the week", etc. 4` <DL!4 <DL! 4 <DL!4` <DL!1#d6X@DQ@# REQACK1 #I2PQP#: this message is sent automatically in reply to any message sent to the xxxrequest address. The message acknowledges receipt, explains the difference between the LISTSERV and xxxrequest addresses, and contains instructions for joining and leaving the list. To suppress this message for your list, simply redefine it in the 'listname.MAILTPL' and use the #d6X@DQ@# .QQ #I2PQP# instruction: 4` <DL!4 <DL! %Body Text Left%Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# >>> REQACK1 This message is not wanted for our list .QQ %Code Example 1%Body Text Left#I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# 4 <DL!4` <DL!1#d6X@DQ@# AUTODEL1 #I2PQP#: this is the message that is sent to users who are deleted by the delivery error monitor. You can customize it to fit your needs, or suppress it using the same procedure as for #d6X@DQ@# REQACK1 #I2PQP#. 1#d6X@DQ@# POSTACK1 #I2PQP# (optional): when present, this message is sent in reply to any message posted to the list. This is very useful for creating "infobots", or just for returning a standard acknowledgement to contributors. The #d6X@DQ@# &SUBJECT #I2PQP# variable contains the subject of the original message, and naturally the usual substitutions (#d6X@DQ@# &LISTNAME #I2PQP#, #d6X@DQ@# &DATE #I2PQP#, #d6X@DQ@# &TIME #I2PQP#) are available. 4` <DL!4 <DL! 4 <DL!4` <DL!1#d6X@DQ@# ADDREQ1 #I2PQP# (changed): this message, which was already present in version 1.8a, is sent to the list owner when a user requests to join a list with "Subscription= By owner". In version 1.8a, a copy of the message was sent to the subscriber, to confirm that the request had indeed been forwarded to the list owner. Unfortunately this was confusing to the many novice users who do not understand the difference between primary and secondary message recipients ('To:' vs 'cc:'). In version 1.8b, only the list owner is sent a copy of the #d6X@DQ@# ADDREQ1 #I2PQP# template. If you were using this template to send new subscribers a questionnaire, application form or similar material, you will need to add a '#d6X@DQ@# .TO &WHOM #I2PQP# instruction to your modified template, as by default the user will no longer receive a copy. 4` <DL!4 <DL! In a linear message, most special instructions are ignored. This is because the contents of the template are just a few lines out of a larger message that is being prepared by LISTSERV to contain the reply to the user's command(s). For instance, you do not have any control over the "ReplyTo:" field of the message, because the message in question is shared with other commands and, in fact, may not be a mail message at all but an interactive message to the user's terminal, a GUI request, etc. Generally speaking, with a linear message you are providing the TEXT of the reply to be shown to the user, but you do not have any control over the methods used for delivering this information. %Body Text Left%Body SubHead#I2PQP#   9.4.3. Tips for using templates  #Body SubHead#Body Text Left#I2PQP# 4 <DL!4` <DL!1Many list owners require prospective subscribers to fill in a little questionnaire before being added to the list, or to explicitly state that they have read the list charter and agree to follow all rules or be removed from the list. The most convenient method, for both list owner and subscriber, is to have the SUBSCRIBE command return a copy of the questionnaire (or list charter, etc), and not forward the request to the owner. The user answers the questions and returns them directly to the list owner, who then adds the subscriber manually. Naturally, it is more convenient for the user if this information arrives in a separate message, with a 'ReplyTo:' field pointing to the list owner's address. Thus, you should not use the #d6X@DQ@# SUB_OWNER #I2PQP# template for this purpose, because it is a linear template and does not give you any control over the 'ReplyTo:' field. The #d6X@DQ@# SUB_OWNER #I2PQP# template could be modified to read "A copy of the list charter is being sent to you, please read it carefully and follow the instructions to confirm your acceptance of our terms and conditions." The list charter would then be sent separately, through the #d6X@DQ@# ADDREQ1 #I2PQP#template. You would use the #d6X@DQ@# .RE OWNERS #I2PQP# command to instruct LISTSERV to point the 'ReplyTo:' field to the list owners, and #d6X@DQ@# .TO &WHOM #I2PQP# to change the destination from list owner to subscriber. If you want to receive a copy of the message, you can use #d6X@DQ@# .TO &WHOM cc: xxx@yyy #I2PQP#. 4` <DL!4 <DL! 4 <DL!4` <DL!1When writing templates, it is a good idea to use substitutions (#d6X@DQ@# &XXXX #I2PQP#) for information which may change in the future. In particular, it is not uncommon for lists to have to be moved from one host to another, and this will be a lot easier if the template uses substitutions for the list address and list host. The #d6X@DQ@# &LISTADDR #I2PQP# substitution translates the full address of the list (XYZL@XYZ.COM), whereas #d6X@DQ@# &LISTNAME #I2PQP# is just the name (XYZL). For references to the server and host, use #d6X@DQ@# &MYHOST #I2PQP# for the Internet hostname, #d6X@DQ@# &MYSELF #I2PQP# for the server address (normally #d6X@DQ@# LISTSERV@&MYHOST #I2PQP#), and #d6X@DQ@# &OWNER #I2PQP# for the xxxrequest mailbox address. These substitutions are "universal" and can be used in all templates. For instance, if you decide to make a bottom banner with instructions for leaving the list, the text could read: "To leave the list, send a SIGNOFF #d6X@DQ@# &LISTNAME #I2PQP# command to #d6X@DQ@# &MYSELF #I2PQP# or, if you experience difficulties, write to #d6X@DQ@# &OWNER #I2PQP#." 4` <DL!4 <DL! %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 9.5. Storing the .MAILTPL file on the host machine )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! The procedure differs slightly on VM systems, but the following will work for unix, VMS and Windows systems: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!1.Get a copy of DEFAULT.MAILTPL and edit it. 2.Be sure that you have defined a "personal password" to LISTSERV with the #d6X@DQ@# PW ADD #I2PQP# command before you #d6X@DQ@# PUT #I2PQP# the template file. If you have done this but can't remember the password, send a #d6X@DQ@# PW RESET #I2PQP# command to LISTSERV, then a new #d6X@DQ@# PW ADD #I2PQP# command. . 3.Send the file to LISTSERV with a #d6X@DQ@# PUT listname MAILTPL PW=XXXXXXXX #I2PQP# command at the top of the file, just as if you were storing the list itself. Replace #d6X@DQ@# XXXXXXXX #I2PQP# with your personal password. $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! ‘The variation for VM systems is that the LISTSERV maintainer will have to create a fileid for the file before you can #d6X@DQ@# PUT #I2PQP# it on the server. Contact the LISTSERV maintainer before trying to store your template file. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# phoenix[NB]950620002)Section SubHeading)9.6. Other template files: DIGESTH and INDEXH )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Two other template files that are available pertain to the automatic digestification feature. You may create and store files called #d6X@DQ@# listname DIGESTH #I2PQP# and #d6X@DQ@# listname INDEXH #I2PQP#. These files define custom digest headers and custom index headers, respectively. You use the same formatting commands and replacable parameters in the #d6X@DQ@# DIGESTH #I2PQP# and #d6X@DQ@# INDEXH #I2PQP# files as you do in the #d6X@DQ@# MAILTPL #I2PQP# file, and the instructions for storing them on the server are identical. (Note that you can't add a digest or index footer because anything after the end of the digest text is supposed to be discarded.)%Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ10. Gatewaying to NewsgroupsChapter10 &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 10.1. Why would I want to? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! There are a number of reasons why it might be reasonable to gateway a list. Some users may not be able to reach your LISTSERV host (or viceversa) via email, but have a good USENET connection. Others may have limited mailbox space and prefer to use a news reader. Still others may have no experience with mailing lists at all before they encounter USENET. In any case, if you are looking for a wider audience for a list, gatewaying it to a newsgroup may be a logical step. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 10.2. How to go about it )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! If you are contemplating gatewaying a list, get the document NETGATE POLICY from LISTSERV@AMERICAN.EDU. This document was written by Jim McIntosh of American University (jim@american.edu), and outlines the procedures you will need to follow in order to gateway a LISTSERV list to USENET. NETGATE POLICY is also available via anonymous ftp to american.edu (cd netnews). You can also get a package of related files by sending a GET NETGATE PACKAGE command to LISTSERV@AMERICAN.EDU. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 10.3 Special considerations and problems with gatewaying )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Wellbehaved newsgroup gateways will identify themselves as the source of postings. This makes it possible for NetNews postings to come to the list if you have coded your list Send= Private (or "Send= Editor" and "Editor= userid@host,(listname)" ! in any case, any configuration that prevents nonsubscribers from posting to the list), since the USENET gateway is subscribed to your list. Misconfigured gateways may not include this information, causing gatewayed mail to bounce. If your list is coded for automatic subscription renewal with the "Renewal=" keyword, the subscription for a news gateway should always be exempted from the subscription renewal process (#d6X@DQ@# SET xxxxx@yyyyy NORENEW #I2PQP#). This will keep LISTSERV from sending the renewal message through the gateway and confusing users who are not subscribed to your list. Spamming (see Chapter 6.9) was originally created on USENET, and is much more prevalent there than on mailing lists because it is easier to do. If you gateway to NetNews, be forewarned that you will be opening your list up to spamming via that source. If the topic of your list is particularly controversial, you may want to think twice before gatewaying. Flame wars are much more common on USENET than on mailing lists (although this position could be argued from both sides on certain mailing lists). If you are considering gatewaying to an existing newsgroup, take some time to read the postings there before making a final decision. Above all, poll your subscribers about the change before making a final decision. Some may have no objections ! others may have violent objections. Gatewaying a list can be a touchy subject, particularly if some of your subscribers are exUSENET users. %Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# Ñ11. Solving ProblemsChapter11 &Section Heading&#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP#  #I2PQP##XX2PQXP# 11.1. Helping subscribers figure out the answers )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! As the saying goes: "Give a man a fish, feed him for a day; teach a man to fish, feed him for life." The analogy can and should be extended to all Internet users, not the least of whom are your own subscribers. Depending on your own preferences, some requests from subscribers for operations that they can perform for themselves can be fulfilled by you as the list owner, or by the subscribers with some coaching from you. While it is a negative approach, the list owner can never assume that the subscriber reads or saves the materials sent to him at the time of subscription. Thus you will have to deal on a regular basis with users who ask how to unsubscribe, or how to get archive files, or how to set their subscription to DIGEST or NOMAIL. Often these requests for help are posted directly to the list. The proactive approach to this problem is to do one or both of two things: %Body Text Left%Bulleted List#I2PQP#4 <DL!4` <DL!Respond to the list with the answer so that all can benefit Respond privately to the subscriber with the answer if it has been posted repeatedly $Bulleted List$Body Text Left#I2PQP#4` <DL!4 <DL! If a user asks a question about a topic that has been discussed previously, you might suggest in a tactful way that the answer can be found in the archives. If your host server supports the LISTSERV database functions, you might even include a sample DATABASE JOB that the user can "clip and send" to LISTSERV. Often it is tempting to simply "get things over with" and take care of the user's request in many cases ! the user wants to be set to NOMAIL because he's going on vacation, the user wants off the list, etc. ! but while this solves the shortterm problem, it doesn't teach the user anything. Naturally it takes more time to be a coach than it does to be the allpowerful list administrator, but the goodwill you can create by being proactive rather than reactive outweighs the convenience of simply sending the command yourself. You will find that many subscribers appreciate the fact that someone takes the time to explain the complexities of LISTSERV to them. In order to cut down on the time it takes to respond in "coaching" situations, many list owners prepare "boilerplate" files with the answers to common questions that they can simply "cut and paste" into return mail. (Several such "boilerplate" files are included in Appendix C.) %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 11.2. Loopchecking can cause occasional problems with quoted replies )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! By default, LISTSERV's internal loopchecking routines look for anything in the body of a mail message that looks like a header line ! specifically anything that looks like a "To:", "Sender:", or "ReplyTo:" header line. If it finds anything like this, LISTSERV intercepts the message and sends it to the list owner (or the person(s) designated by the "ErrorsTo=" keyword) as an error. Often a user who replies to list mail includes all or part of the message he is replying to as part of his reply ("quoting"). While this is a questionable practice to begin with, unfortunately a number of popular mail programs make it worse by including the quoted message in its entirety (including header lines) in the body of the reply. For instance, the following message ended up in the author's error mailbox: %Body Text Left%1P !( @ddCode Example 2#P6X@DQ@# %Body Text Left%The enclosed message, found in the ACCESSL mailbox and shown under the spool #d6X@DQ@# ID 6305 in the system log, has been identified as a possible delivery error  notice for the following reason: "Sender:", "From:" or "ReplyTo:" field  pointing to the list has been found in mail body.    é Message in error (42 lines)   Received: by access.mbnet.mb.ca id AA05697  (5.67b/IDA1.4.4 for Microsoft Access Database Discussion List   ); Wed, 1 Mar 1995 10:26:29 0600  Date: Wed, 1 Mar 1995 10:26:29 0600  From: xxxxxx xxxxxxxxx   MessageId: <199503011626.AA05697@access.mbnet.mb.ca>  To: Microsoft Access Database Discussion List   MessageId: <199503011626.AA05697@access.mbnet.mb.ca>  To: Microsoft Access Database Discussion List     Subject: Re: Re: Foxpro listserv address  XMailer: AIR Mail 3.X (SPRY, Inc.)      < Begin Included Message >  Date: Thu, 23 Feb 1995 01:17:36 0500  From: xxxxxxx@xxx.com  Sender: Microsoft Access Database Discussion List    Subject: Re: Foxpro listserv address  To: Microsoft Access Database Discussion List      >BTW, I don't know why she is still on Foxpro, I thought they went out  >into the desert??    < End Included Message >    (subscriber's reply deleted) %Code Example 2% P  FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 11.1.Sample error message with included headers. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! The problem with this reply was twofold, from a list owner's standpoint. First (a netiquette issue), the sender didn't bother to remove unnecessary header lines from his reply. If properly formatted, however, this would not normally cause an error. Second, the mail software he was using didn't include ">" characters at the beginning of every line of the included message. Had it done so, the message would have passed through LISTSERV unhindered. One variation on this error is mail software that quotes messages by adding the ">" character followed by a space for esthetic reasons. For instance, using the above error as an example: %Body Text Left%1A( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# > Date: Thu, 23 Feb 1995 01:17:36 0500 #d6X@DQ@# > From: xxxxxxx@xxx.com  > Sender: Microsoft Access Database Discussion List    > Subject: Re: Foxpro listserv address  > To: Microsoft Access Database Discussion List      > BTW, I don't know why she is still on Foxpro, I thought they went out  > into the desert?? %Code Example 2%  FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 11.2.A slightly different sample error message with included headers. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! This won't work either. Generally this is a client configuration problem and it can be fixed by setting the quoting character in the client's configuration file. On the other hand, the following quote would have worked: ‘ %Body Text Left%1a( @ddCode Example 2#P6X@DQ@# #I2PQP# #P6X@DQ@# >Date: Thu, 23 Feb 1995 01:17:36 0500 #d6X@DQ@# >From: xxxxxxx@xxx.com  >Sender: Microsoft Access Database Discussion List    >Subject: Re: Foxpro listserv address  >To: Microsoft Access Database Discussion List      >BTW, I don't know why she is still on Foxpro, I thought they went out  >into the desert?? %Code Example 2%  FigureCaption#B2PQP#4 <DL!4 <DL!#d6X@DQ@##B2PQP#Figure 11.3.A correctlyformatted message with included headers. $FigureCaption$Body Text Left#I2PQP#4 <DL!4 <DL! The ultimate solution to the problem is to warn subscribers to limit their quoting to a minimum, and in any case to be sure to delete anything that looks like a header line in the body of their reply. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 11.3. User can't unsubscribe and/or change personal options )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! See Chapter 4, section 4.1 where this is discussed in detail. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 11.4. Firewalls )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Firewalls on the Internet are set up for essentially the same reason firewalls are designed into buildings and automobiles ! to keep dangerous things (in this case, hackers, viruses, and similar undesirable intruders) from getting in and wreaking havoc with sensitive data. Unfortunately, they don't always keep people from behind them from sending mail out, and this can cause problems when users from such sites attempt to subscribe to lists. If your list is set to confirm all subscriptions with the "magic cookie" method ( Subscription= Open,Confirm), you will receive an error message any time a user from a firewalled site attempts to subscribe, since the "cookie" confirmation message will bounce off the firewall. If your list is not set to confirm subscriptions, the same user will be able to subscribe to your list but all mail sent to him will bounce. Some firewalls reportedly can recognize "friendly" LISTSERV mail and let it through, but because of security considerations, it is unlikely that this problem will ever completely go away. Thankfully it does not seem to be a major cause of mailing list errors. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# 11.5. If I can't find the answer, where do I turn? )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Two LISTSERV lists exist for list owner and LISTSERV maintainer questions. LSTSRVL is the LISTSERV giveandtake forum. Its primary mission is to provide assistance to LISTSERV maintainers, but it can also be of interest to list owners who desire a more indepth knowledge of the workings of the system. To subscribe to LSTSRVL, send your subscription request to LISTSERV@LISTSERV.NET. LSTOWNL is the LISTSERV list owners' discussion list, where list owners can get assistance on list maintenance and other aspects of list ownership. To subscribe to LSTOWNL, send your subscription request to LISTSERV@LISTSERV.NET.%Body Text Left% Section Heading #g2PQP# 4 <DL! <DL!#I2PQP# #g2PQP# ÑAppendix A:System Reference Library #I2PQP##g2PQP# for LISTSERV#2PQP#)#g2PQP# version 1.8bAppendixA #I2PQP##g2PQP# &Section Heading&Body Text Left#I2PQP# <DL!4 <DL!This document is available separately. It can be retrieved in plain text from any server running LSoft's LISTSERV#_2PQP#)#I2PQP# with the command INFO REFCARD. Commands are listed in alphabetical order, with the minimum acceptable abbreviation in capital letters. Angle brackets are used to indicate optional parameters. All commands which return a file accept an optional 'F=fformat' keyword (without the quotes) that lets you select the format in which you want the file sent; the default format is normally appropriate in all cases. Some esoteric, historical or seldomused commands and options have been omitted. %Body Text Left%Body SubHead#I2PQP#   List subscription commands (from most to least important)  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL![has to be updated from new refcard] SUBscribe listname full_nameSubscribe to a list, or change your name if already subscribed SIGNOFFRemove yourself: 4 DL!4 D%L!listname From the specified list * From all lists on that server * (NETWIDE  From all lists in the network 4 D%L!4 DL! SET listname options Alter your subscription options: 4 DL!4 D%L!ACK/NOACK/MSGack >Acknowledgments for postings CONCEAL/NOCONCEAL >Hide yourself from REVIEW Files/NOFiles >Toggle receipt of nonmail files from the list Mail/NOMail >Toggle receipt of mail DIGests/INDex >Ask for digests or message indexes rather than getting messages as they are posted REPro/NOREPro >Copy of your own postings? 4 D%L!4 D%L!TOPICS:ALL >Select topics you are subscribed to <+/> topicname(add/remove one or replace entire list) 4 D%L!4 DL! Options for mail headers of incoming postings (choose one): 4 DL!4 D%L! FULLHdr or FULL822>"Full" mail headers (default) IETFhdr >Internetstyle headers SHORTHdr or SHORT822>Short headers DUALhdr >Dual headers, useful with PC or Mac mail programs 4 D%L!4 DL! CONFIRM listname1 <listname2 <...>>Confirm your subscription (when LISTSERV requests it) %Body Text Left%Body SubHead#I2PQP# 4 DL!4 <DL!  Other listrelated commands  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL! INDex listname Sends a directory of available archive files for the list, if postings are archived 4 DL!4 D%L!Lists <option>Send a list of lists as follow: (no option) >Local lists only, one line per list Detailed >Local lists, full information returned in a file Global >All known lists, one line per list, sent as a (large!) file Global /xyz >Only those whose name or title contains 'xyz' SUMmary >Membership summary for all lists on specified host SUMmary ALL >For all hosts (long output, send request via mail!) SUMmary TOTAL >Just the total for all hosts 4 D%L!4 DL! Query listname Query your subscription options for a particular list (use the SET command to change them) 4 DL!4 D%L!* >Query all lists you are subscribed to on that server 4 D%L!4 DL! REGisterfull_name Tell your name to LISTSERV, so that you don't have to specify it on subsequent SUBSCRIBE's OFF Make LISTSERV forget your name REView listname <(options> Get information about a list 4 DL!4 D%L!BY sort_field >Sort list in a certain order: 4 D%L!4 D%L!Country by country of origin Name by name (last, then first) NODEid by hostname/nodeid Userid by userid 4 D%L!4 D%L!BY (field1 field2) >You can specify more than one sort field if enclosed in parentheses: BY (NODE NAME) Countries >Synonym of BY COUNTRY LOCal>Don't forward request to peers Msg>Send reply via interactive messages (BITNET users only) NOHeader> Don't send list header Short> Don't list subscribers 4 D%L!4 DL! SCAN listname text Scan a list's membership for a name or address STats listname <(options> Get statistics about a list LOCal > Don't forward to peers %Body Text Left%Body SubHead#I2PQP# 4 DL!4 <DL!  Informational commands  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL! Help Obtain a list of commands Info <topic>Order a LISTSERV manual, or get a list of available ones (if no topic was specified) <listname>Get information about a list hosted on the server Query File fn ft <filelist> <(options> Get date/time of last update of a file, and GET/PUT file access code 4 DL!4 D%L!FLags >Get additional technical data (useful when reporting problems to experts) 4 D%L!4 DL! RELEASE Find out who maintains the server and the version of the software and network data files SHOW <function> Display information as follows: 4 DL!4 D%L!ALIAS node1 <node2 <...>> >BITNET nodeid to Internet hostname mapping BITEARN (VM only)>Statistics about the BITEARN NODES file DISTribute >Statistics about DISTRIBUTE DPATHs host1 <host2 <...>>>DISTRIBUTE path from that server to specified host(s) DPATHs *>Full DISTRIBUTE path tree FIXes (VM only)>List of fixes installed on the server (nonVM see LICENSE) HARDWare or HW>Hardware information LICense>License/capacity information and software build date LINKs node1 <node2 <...>> >Network links at the BITNET node(s) in question NADs node1 <node2 <...>> > Addresses LISTSERV recognizes as node administrators NETwork (VM only)>Statistics about the network NODEntry node1 <node2 <...>> >BITEARN NODES entry for the specified node(s) NODEntry node1 /abc*/xyz >Just the ':xyz.' tag and all tags whose name starts with 'abc' PATHs snode node1 <node2 <...>>>BITNET path between 'snode'and the specified node(s) STATs >Usage statistics (default option) VERSion>Same as RELEASE command (no function) >Same as SHOW STATS 4 D%L!4 DL! %Body Text Left%Body SubHead#I2PQP# 4 DL!4 <DL!  Commands related to file server functions  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL! AFDAutomatic File Distribution ADD fn ft <filelist <prolog>> Add file or generic entry to your AFD list DELete fn ft <filelist> Delete file(s) from your AFD list (wildcards are supported) List Displays your AFD list For node administrators: FOR user ADD/DEL/LIST etc.Perform requested function on behalf of a user you have control over (wildcards are supported for DEL and LIST) FUI File Update Information: same syntax as AFD, except that FUI ADD accepts no 'prolog text' GET fn ft <filelist> <(options> Order the specified file or package 4 DL!4 D%L!PROLOGtext xxxx >Specify a 'prolog text' to be inserted on top of the file 4 D%L!4 DL! GIVE fn ft <filelist> userSends a file to someone else INDex <filelist>Same as GET xxxx FILELIST (default is LISTSERV FILELIST) PW function Define/change a "personal password" for protecting AFD/FUI subcriptions, authenticating PUT commands, and so on 4 DL!4 D%L!ADD firstpw >Define a password for the first time CHange newpw >Change password RESET >Reset (delete) password 4 D%L!4 DL! SENDme Same as GET %Body Text Left%Body SubHead#I2PQP# 4 DL!4 <DL!  Other (advanced) commands  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL! DATAbasefunction Access LISTSERV database: 4 DL!4 D%L!Search DD=ddname >Perform database search (see INFO DATABASE for more information on this) List >Get a list of databases available from that server REFRESH dbname >Refresh database index, if suitably privileged 4 D%L!4 DL! DBaseSame as DATABASE DISTribute <type> <source> <dest> <options> Distribute a file or a mail message to a list of users (see INFO DIST for more details on the syntax) Type: 4 DL!4 D%L!MAIL >Data is a mail message, and recipients are defined by '<dest>' FILE >Data is not mail, recipients are defined by '<dest>' RFC822 >Data is mail and recipients are defined by the RFC822 'To:'/'cc:' fields Source: DD=ddname >Name of DDname holding the data to distribute (default: 'DD=DATA') Dest:  user1 <user2 <...>> >List of recipients  DD=ddname >One recipient per line Options for the general user: ACK=NOne/MAIL/MSG >Acknowledgement level (default: ACK=NONE) CANON=YES >'TO' list in 'canonical' form (uid1 host1 uid2 host2...) DEBUG=YES >Do not actually perform the distribution; returns debug path information INFORM=MAIL >Send file delivery message to recipients via mail TRACE=YES >Same as DEBUG=YES, but file is actually distributed Options requiring privileges: FROM=user >File originator FROM=DD=ddname >One line: 'address name' 4 D%L!4 DL! SERVE user Restore service to a disabled user THANKs Check to see if the server is alive UDDAccess the User Directory Database (there are 18 functions and many subfunctions, so the syntax is not given here) %Body Text Left%Body SubHead#I2PQP# 4 DL!4 <DL!  File management commands (for file owners only)  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL! AFD/FUI Automatic File Distribution GET fn ft <filelist> Get a list of people subscribed to a file you own GET fn FILELIST <(options> Special options for filelists: 4 DL!4 D%L!CTL >Return filelist in a format suitable for editing and storing back NOLock >Don't lock filelist (use in conjunction with CTL) 4 D%L!4 DL! 4 DL!4 D%L!PUT fn ft <filelist > Update a file you own >Accept request even if current version of the file is more recent than the version you sent  >Set file date/time  >Supply your password for command authentication > >Select fixedformat file (not to be used for text files)  >Send reply to another user  >Don't send any reply  >Request reply via interactive messages, not mail (BITNET only) <"parameters"> >Special parameters passed to FAVE routine, if any  Standard parameters supported for all files:  TITLE=file title >Change file "title" in filelist entry REFRESH filelist <(options> Refresh a filelist you own NOFLAG >Don't flag files which have changed since last time as updated (for AFD/FUI) UNLOCK fn FILELIST Unlock filelist after a GET with the CTL option if you decide not to update it after all 4 D%L!4 DL! %Body Text Left% Body SubHead#I2PQP# 4 DL!4 <DL!  ÑList management functions  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 DL!Commands that support the QUIET keyword are marked (*) ADD(*) listname user <full_name> Add a user to one of your lists, or update his name 4 DL!4 D%L!listname DD=ddname >Add multiple users, one address/ name pair per line 4 D%L!4 DL! ADDHere(*) Same as ADD, but never forwards the request to a possibly closer peer DELete(*) listname user <(options> Remove a user from one of your lists, or from all local lists if listname is '*' 4 DL!4 D%L!GLobal >Forward request to all peers LOCal >Don't try to forward request to closest peer if not found locally TEST >Do not actually perform any deletion (useful to test wildcard patterns) 4 D%L!4 DL! EXPLODElistname <(options> Examine list and suggest better placement of recipients, returning a readytosubmit MOVE job 4 DL! D%L!BESTpeers n >Suggest the N best possible peers to add Detailed>More detailed analysis FOR node >Perform analysis as though local node were 'nodeid' PREFer node >Preferred peer in case of tie (equidistant peers) SERVice >Check service areas are respected With(node1 <node2 <...>>>) >Perform analysis as though specified nodes ran a peer WITHOut(node1 <node2 <...>>>)>Opposite effect  D%L!4 DL! FREE listname <(options> Release a held list 4 DL!4 D%L!GLobal >Forward request to all peers 4 D%L!4 DL! GET listname <(options> Get a copy of a list in a form suitable for editing and storing list and lock it 4 DL!4 D%L!GLobal >Forward request to all peers HEADer >Send just the header; on the way back, only the header will be updated NOLock >Do not lock the list OLD >Recover the "old" copy of the list (before the last PUT) 4 D%L!4 DL! HOLD listname <(options> Hold a list, preventing new postings from being processed until a FREE command is sent 4 DL!4 D%L!GLobal >Forward request to all peers 4 D%L!4 DL! MOVE(*) listname user node Move a subscriber to another peer 4 DL!4 D%L!listname DD=ddname >Move several subscribers to various peers 4 D%L!4 DL! PUT listname LIST Update a list from the file returned by a GET command Querylistname FOR user Query the subscription options of another user (wildcards are supported)  * FOR user Searches all the lists you own SET(*) listname options Alter the subscription options of another  * user or set of users (when using wildcards) Additional options for list owners: 4 DL!4 D%L!NORENEW/RENEW >Waive subscription confirmation for this user NOPOST/POST >Prevent user from posting to list EDITOR/NOEDITOR >User may post without going through moderator REVIEW/NOREVIEW >Postings from user go to list owner or moderator even if user is allowed to post 4 D%L!4 DL! STats listname (RESET Resets statistics for the list UNLOCK listname Unlock a list after a GET, if you decide not to update it after all 4 DL!4<DL! %Body Text Left%Body SubHead#I2PQP# 4<DL!4 <DL!  Syntax of parameters  #Body SubHead#Body Text Left#I2PQP#4 <DL!4<DL! 4<DL!4m N <DL!filelist =1 to 8 characters from the following set: #d6X@DQ@# AZ 09 $#@+_: #I2PQP#fformat =Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail fn =(filename) same syntax as 'filelist' ft =(VM "filetype" or VMS/unix/DOS "extension") same syntax as 'filelist' full_name =firstname surname (*not* your email address); sometimes referred to as "your real name" host=Internet hostname listname =name of an existing list node =BITNET nodeid or Internet hostname of a BITNET machine which has taken care of supplying a ':internet.' tag in its BITEARN NODES entry pw =1 to 8 characters from the set: #d6X@DQ@# AZ 09 $#@_?!|% #I2PQP# user =Any valid RFC822 network address not longer than 80 characters; if omitted, the 'hostname' part defaults to that of the command originator%Body Text Left% Section Heading #g2PQP# 4m N <DL! <DL!#I2PQP# #g2PQP# Ñ Appendix B:List Keyword Alphabetical Reference #I2PQP##g2PQP# for LISTSERV#2PQP#)#g2PQP# version 1.8bAppendixB &Section Heading& Header 1#g2PQP#  <DL!4 <DL!#I2PQP# #g2PQP#  Header 1Body Text Left#I2PQP#4 <DL!4 <DL!This document is available separately as reference number 9412UD01. It can be retrieved in plain text from any server running LSoft's LISTSERV#_2PQP#)#I2PQP# with the command INFO KEYwords. %Body Text Left%"Dictionary Header"#g2PQP# #I2PQP# #g2PQP# The List Header  (Dictionary Header(Body Text Left#I2PQP# The list header contains configuration information for the list. To edit it, use the #d6X@DQ@# GET listname (HEADER #I2PQP# command, edit the header, and send it back to LISTSERV with the #d6X@DQ@# PUT listname PW=XXXXXXXX #I2PQP# command. For more details on this procedure, consult the List Owner's Manual for LISTSERV, version 1.8b (LSoft document reference number 9502UD02). Each line of the header must begin with an asterisk ("*"). The first line of the header must contain the list title, which must fit on a single line and not exceed 4050 characters. Succeeding lines hold list control keywords and their values. Any words in the list header followed by the "=" character are assumed to be keywords. Following the list of keywords, you may add a few lines containing a brief description of the purpose of the list. These lines must also begin with an asterisk ("*"). This document is a description of the list control keywords that appear in the header of each list. Whenever default values are supplied for the keywords, they are listed first in the description. Words in italics are "generic parameters" which define a set of possible values for a keyword operand, as described below: %Body Text Left%"Dictionary Header"#g2PQP# #I2PQP# #g2PQP# Generic parameters  (Dictionary Header(Body Text Left#I2PQP#4 <DL!4 <DL! netaddressDescribes an Internet address, such as JACK@XYZ.COM. 4 <DL!4 <DL! 4 <DL!4 <DL!accesslevelControls which category of users has access to the information or service to which this parameter applies. accesslevel can be either: 4 <DL! DL! Public Everybody has access to the information. Postmaster Only the postmaster (i.e. LISTSERV operations staff) has access to the information. A1,A2,... with Ai being either:  DL!DL! DL!VDL! Private Only users subscribed to the list have access to the information. (listname) Only the subscribers of the named list have access to the information. Owner Only the list owner can access the information. Owner(list) Only the owner of the named list can access the information. Service Only people in the service area of the list can see the information. Service(list) Only subscribers of the named list's service area can see the information. VDL!4 <DL! 4 <DL!4 <DL!destinationIndicates the destination of a piece of mail, message or reply. 4 <DL!4 <DL! 4 <DL! DL! List The reply message is sent to the list. Sender The reply message is sent to the sender of the original piece of mail. Both The reply message is sent both to the list and to the original sender. None No reply message is sent at all. "address" The reply message is sent to the specified network address if enclosed in double quotes  DL!4 <DL! 4 <DL!4 <DL!intervalIs a time interval that indicates how frequently an operation is to be renewed. Note that depending on the operation being performed, some of the options may not be available. For example, "Notebook= Yes,A,Daily" is not available. 4 <DL!4 <DL! 4 <DL! DL! Yearly } Monthly }  DL! <DL! Weekly }Selfexplanatory  <DL! DL! Daily } Hourly }  DL! <DL! Single The operation is to be done only a single time.  <DL!4 <DL! 4 <DL!4 <DL!peerIs the nodeid or network address of a peer list. If the name of the peer list is the same as the name of the local list (which will usually be the case), only the node name needs be given. If the list names are different, the full list network address must be given, e.g. "REXXL@UIUCVMD". 4 <DL!4 <DL! 4 <DL!4 <DL!areaIs a means whereby a node or list of nodes can be identified. An area can be either: 4 <DL!4 <DL! 4 <DL! <DL!The name of a network, e.g. EARN, BITNET The name of a country, e.g. Germany, Canada 'Local', in which case it is equated to the value of the "Local=" keyword (q.q.v.). A node name, e.g. SEARN A simple wildcard nodename pattern such as FR*, *11, *ESA*, D*ESA*, etc.  <DL!4 <DL! 4 <DL!4 <DL!monaddressIs a means whereby 'list monitors' can be identified (the term 'list monitor' refers to a human person who monitors the activity of a list). A 'monaddress' can be: 4 <DL!4 <DL! 4 <DL! <DL!A single network address, e.g. INFO@TCSVM 'Postmaster', which indicates the "main" postmaster 'Postmasters', which indicates ALL the postmasters, main and alternate 'Owner', which indicates the "main" list owner (the first to be listed in the "Owner=" keyword) 'Owners', which indicates ALL list owners  <DL!4 <DL! Some keywords can take more than one parameter. Where multiple parameters are accepted, they will be separated by a logical OR sign (|). Unless specified otherwise, commas have "higher priority" than OR signs, that is to say, "Public|Private, Open|Closed" means "(Public|Private), (Open|Closed)", not "Public|(Private,Open)|Closed". ‘Keywords fit into several different classifications. These classifications, and the associated keywords, are as follows: %Body Text Left%Body SubHead#I2PQP#   Access Control Keywords (page keyAccess76)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#Files=Determines whether nonmail files may be distributed by the list #I2PQP##B2PQP#Filter=Gives list owners control over problem users and/or gateways #I2PQP##B2PQP#Review=Restricts who may review the list of subscribers #I2PQP##B2PQP#Send=Restricts who may send postings to the list #I2PQP##B2PQP#Stats=Determines whether or not list statistics are available, and to whom IndexBody SubHead#I2PQP# 4 <DL!4 <DL!    Distribution Keywords (page keyDistribution78)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#Ack=Controls the level of acknowledgement messages to those posting messages #I2PQP##B2PQP#DailyThreshold=Limits the total number of messages that will be processed by the list per day before the list is held #I2PQP##B2PQP#Digest=Controls the automatic digestification option #I2PQP##B2PQP#InternetVia=Determines through which gateway Internet mail will be sent #I2PQP##B2PQP#MailVia=Determines how LISTSERV distributes list mail #I2PQP##B2PQP#Newsgroups=Defines USENET newsgroups linked to the list #I2PQP##B2PQP#NJEVia=Determines through which gateway NJE mail will be sent #I2PQP##B2PQP#Prime=Controls whether or not mail will be processed during "prime time" #I2PQP##B2PQP#ReplyTo=Sets a default for the "ReplyTo:" field in the header of list mail #I2PQP##B2PQP#Sender=Defines the value LISTSERV places in the "Sender:" header field of list mail #I2PQP##B2PQP#Topics=Defines up to 11 subtopics for a list IndexBody SubHead#I2PQP# 4 <DL!4 <DL!    Error Handling Keywords (page keyError83)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#AutoDelete=Sets parameters for the autodeletion feature #I2PQP##B2PQP#Errorsto=Determines the network address to whom mail delivery errors are directed #I2PQP##B2PQP#Loopcheck=Defines the type of mailing loop checking performed by LISTSERV #I2PQP##B2PQP#Safe=Determines which builtin address filter is used by LISTSERV IndexBody SubHead#I2PQP# 4 <DL!4 <DL!    List Maintenance and Moderation Keywords (page keyListMaint85)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP#4 <DL!4z <DL!#I2PQP##B2PQP#Editor=Defines an editor or editors for moderated lists #I2PQP##B2PQP#EditorHeader=Controls if an explanatory mail header is added to list messages forwarded to the list editor (if one is defined) #I2PQP##B2PQP#ListAddress=Determines how the list address is announced in message headers #I2PQP##B2PQP#ListID=Defines a long listname alias for the list #I2PQP##B2PQP#Moderator=Defines the editors on moderated lists who will receive postings for approval. #I2PQP##B2PQP#NewList=Sets forwarding when a list is moved to a different LISTSERV host #I2PQP##B2PQP#Notebook=Controls the notebook archive for a list #I2PQP##B2PQP#NotebookHeader=Determines the type of header information included in the notebook archive #I2PQP##B2PQP#Notify=Defines whether or not (or to whom) subscription notification is sent #I2PQP##B2PQP#Owner=Defines the owner (or owners) of the list #I2PQP##B2PQP#Peers=Defines peers for the list #I2PQP##B2PQP#Renewal=Controls whether or not subscription renewal is implemented, and how #I2PQP##B2PQP#Sizelim=Controls the maximum size of any single message posted to the list #I2PQP##B2PQP#XTags=Controls whether "Xto:" and "Xcc:" tags are included in list mail headers 4z <DL!4 <DL!#I2PQP##B2PQP# IndexBody SubHead#I2PQP# 4 <DL!4 <DL!  Security Keywords (page keySecurity89)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#Confidential=Determines whether or not an entry for the list appears in the List of Lists #I2PQP##B2PQP#Exit=Defines a list "exit" which modifies the default behavior of LISTSERV #I2PQP##B2PQP#Local=Defines which nodes are considered "local" for this list #I2PQP##B2PQP#PW=Sets a password used for validation of list maintenance commands #I2PQP##B2PQP#Service=Defines an area or areas outside which subscription requests are not accepted #I2PQP##B2PQP#Validate=Determines whether or not list commands must be validated with a password or the "OK" mechanism #I2PQP##B2PQP# IndexBody SubHead#I2PQP# 4 <DL!4 <DL!  Subscription Keywords (page keySubscription92)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#ConfirmDelay=Defines a default number of hours LISTSERV holds jobs requiring confirmation #I2PQP##B2PQP#DefaultOptions=Defines what options should be set by default for new subscribers #I2PQP##B2PQP#Subscription=Defines how new subscriptions are handled, and if confirmation is required #I2PQP##B2PQP# #I2PQP##B2PQP#ё IndexBody SubHead#I2PQP# 4 <DL!4 <DL!  Other Keywords (page keyOther94)  #Body SubHead#Index` hp x (#4 <DL!#B2PQP##I2PQP##B2PQP#Indent=Defines the minimum number of columns allowed for list addresses in a REVIEW #I2PQP##B2PQP#Language=Defines the language in which information mail and messages are sent #I2PQP##B2PQP#LongLines=Controls whether longlines support is enabled #I2PQP##B2PQP#Translate=Controls how LISTSERV handles control characters in list mail #I2PQP##B2PQP# IndexBody SubHead#I2PQP# 4 <DL!4 <DL!  Default Values for All Keywords (page keyDefaultValues95) #Body SubHead# "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑAccess Control KeywordskeyAccess  (Dictionary Header(Body Text Left#I2PQP# Files=Yes | No %Body Text Left%#Body Text Indented##I2PQP#(NJE only; obsolete in other versions) Indicates whether NJE files can be sent to the list or not. The default value is "No". "Files= No" may prevent some nonRFC822 mailer users from posting to lists. )Body Text Indented)Body Text Left#I2PQP# Filter= Only | Also | Safe,netaddress1,netaddress2,.... %Body Text Left%#Body Text Indented##I2PQP# "Filter=" is checked when a user attempts to post or subscribe to a list (but not when the list owner issues an ADD command). The first word of this keyword is either "Only", "Also" or "Safe", and it is followed by a list of patterns such as 'X400MAIL@*' or '*@*.XYZ.EDU' (without the quotes). If "Also" is specified, your filter is used in addition to the standard LISTSERV filter; this is useful to register additional looping mailers, to prevent users behind broken gateways from subscribing until the problem is addressed, or to ban anonymous posters. LISTSERV has two builtin filters: a "minimal" one, which is used for safe lists, and a "safe" one which is used for lists running with "Safe= No". That is, the unsafe lists need a safe filter to avoid mailing loops; safe lists only need the minimal filter, but can be made even safer by selecting "Filter= Safe". This, however, prevents usernames such as 'root' from posting to the list, because they are included in the safe filter. If "Filter= Only" is used, the addresses you specify are the only ones which LISTSERV prevents from posting to the list. CAUTION: You should not use this option unless you also code "Safe= Yes", and even then you will want to ask your LISTSERV maintainer for permission. This option has been added mostly for LISTSERV maintainers with very specific problems to solve. The minimal filter is very small and you should never need to override it. Messages sent to the LISTSERV userid for execution are always checked with the minimal filter, as people with userids such as 'root' would otherwise not be allowed to subscribe to lists which were set up to allow them. Note that LISTSERV extracts as many email addresses as it can from the userid being checked and runs them all through the filter. For instance if your list receives mail from 'searn.sunet.se!mailer@xyz.edu', LISTSERV will check 'searn.sunet.se!mailer@xyz.edu', 'mailer@searn.sunet.se' and 'mailer@searn' (via the 'internet.' tag). )Body Text Indented)Body Text Left#I2PQP# Review= accesslevel %Body Text Left%#Body Text Indented##I2PQP#This keyword defines the categories of users who are allowed to review the Internet addresses and names of the persons subscribed to a list. The default value is "Public". )Body Text Indented)Body Text Left#I2PQP# Send= accesslevel [,Confirm]   Editor [,Hold] %Body Text Left%#Body Text Indented##I2PQP#Defines the categories of users who can mail or send files to the list. Possibly puts the list under control of an editor. The default value is "Public". When the list is controlled by an editor, any file or piece of mail sent to the list is forwarded to the editor, who is the only person (with the list owner) to be able to actually mail or send files to the list. The network address of the editor is defined by the "Editor=" keyword (see below under "List Maintenance and Moderation"). )Body Text Indented)Body Text Left#I2PQP# %Body Text Left%%Bulleted List Indent%#I2PQP#4 <DL!4` <DL!%Body Text Left%When the Hold option is enabled (#d6X@DQ@# Send= Editor,Hold #I2PQP#), the moderator(s) may approve postings using the OK mechanism rather than forwarding the posts back to the list. Hold is valid only with Editor. +Bulleted List Indent+Body Text Left#I2PQP#4` <DL!4 <DL! Stats= Normal | None,accesslevel [VM only] %Body Text Left%#Body Text Indented##I2PQP#Indicates whether or not statistics are to be maintained for the list and if yes, which level of statistics is desired and who is able to retrieve the statistics reports. The default value is "Normal,Private". Normal statistics include number of mailings for each user on the list, and similar information for file distribution. )Body Text Indented)Body Text Left#I2PQP#%Body Text Left% "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑDistribution KeywordskeyDistribution  (Dictionary Header(Body Text Left#I2PQP# Ack= Yes | Msg | No | None %Body Text Left%#Body Text Indented##I2PQP#Defines the default value of the "ACK/NOACK" distribution option for the corresponding list, i.e. the value assigned to new users when they subscribe to the list. This value can be altered by subscribers ("SET" command), but not by users who are not signed on to the list. This means that this option will always be in effect when distributing mail from people who are not on the distribution list. 4 <DL!4 <DL!YesA short acknowledgment with statistical information on the mailing will be sent back to you. This is the default. MsgMessages will be sent when your mail file is being processed. Statistical information will be sent via messages, but no acknowledgment mail will be sent. [BITNET only] NoFor Internet users, no acknowledgement will be sent. For BITNET users, a single interactive message will be sent as the message is processed. NoneNo messages of any kind are sent when your mail file is processed. [same as No for nonBITNET] )Body Text Indented)Body Text Left#I2PQP#4 <DL!4 <DL! DailyThreshold= number %Body Text Left%#Body Text Indented##I2PQP#This keyword limits the number of postings that may be processed by the list in a 24 hour period. The default is DailyThreshold= 50. When the keyword's value is reached, the list is automatically placed on hold, and the list owner or LISTSERV maintainer must issue the FREE listname command. Note that it may or may not be advisable to increase this parameter for highervolume lists ! individual list owners should study the issue carefully before increasing the daily threshold of their highvolume lists. )Body Text Indented)Body Text Left#I2PQP# Digest= No  Yes,where | Same,frequency,when,maxsize %Body Text Left%#Body Text Indented##I2PQP#This keyword controls the automatic digestification function allowing subscribers who do not have the time to read large numbers of messages as they arrive to subscribe to a digestified or indexed version of the list. The list owner decides whether digests are available or not, the frequency at which they are issued and the day of week or time of day when the digest should be distributed.)Body Text Indented)# footnote reference##W\  P6QP# footnote text#W\  P6QP## footnote reference##W\  P6QP#` hp x (#4 <DL!#_2PQP#э) footnote reference)The digests conform to RFC1153 with an acceptable deviation from the recommended subject line (verified with the RFC author).#I2PQP# Digests are larger messages containing all the postings made by list subscribers over a certain period of time. Unlike realworld digests, LISTSERV digests are not edited; what you see is exactly what was posted to the list. The only difference is that you get all the messages for a given day, week or month in a single batch. This is mostly useful if you are just "listening in" to the list and prefer to read the postings at your leisure. Digests are kept separately from list archives and can be made available for mailing lists which do not archive postings (i.e. which run with "Notebook= No"). Indexes, on the other hand, only provide a few lines of information for each posting: date and time, number of lines, name and address of poster, subject. The actual text is not included. You select just the messages you are interested in, and order them from the server. This is useful for mailing lists where most messages really don't interest you at all, or as an alternative to SET NOMAIL: when you come back from vacations, you can quickly order the messages you are most interested in. Note that, since indexes are not useful without the ability to order a copy of the messages you do want to read, they are not made available unless the list is archived and digests are enabled. Users sign up for digestified rather than immediate delivery with 'SET listname DIGests', while indexes are selected with 'SET listname INDex'. These two new options are alternatives to MAIL and NOMAIL. When switching around between these delivery options, users will observe the following behavior (digests will be assumed to be daily for the sake of clarity): 4 <DL! <DL!When switching to NOMAIL: delivery stops immediately. The day's digest is not sent, as the user is assumed to desire immediate termination of traffic from the list.  <DL!4 <DL! 4 <DL! <DL!When switching from any option to DIGESTS or INDEX: mail delivery stops immediately, and the first index or digest may contain some items the user has already seen (if switching from MAIL to DIGESTS/INDEX). This is because the digests and indexes are global to the list they are the same for everyone, just like regular issues of newspapers.  <DL!4 <DL! 4 <DL! <DL!When switching from DIGESTS or INDEX to MAIL, the current, unfinished digest or index is immediately mailed to the user. New messages are delivered normally, as they arrive. Thus, a "trick" to get a copy of the current digest is to switch to MAIL and then back to DIGESTS. You can send both commands in the same mail message to make sure they are executed together.  <DL!4 <DL! The list owner controls the availability and frequency of digests through the new "Digest=" list header keyword, which defaults to "Digest= No" for lists without an archive and "Digest= Yes,Same,Daily" for archived lists. Again, it is not necessary for the list to be archived to keep a digest; LISTSERV just attempts to avoid having to store large amounts of digest data on its private area for lists which, lacking a "Notebook= Yes,xxx" keyword, do not specify any suitable directory for the digest data. Conversely, having daily as the default frequency keeps the additional cost in disk space to a minimum. The syntax of the keyword is "Digest= Yes,where,frequency,when,maxsize" when digests are enabled, or then "Digest= No". The second parameter is a disk or directory specification, just as with the "Notebook=" keyword, or "Same", which means that the digest must be stored on the same disk as the list archives. The third parameter is either "Daily" (the default), "Weekly" or "Monthly". The third parameter is optional and specifies when the digest is to be actually distributed. For daily digests, specify 'hh:ss' or just 'hh' in the usual 0023 scale (24 is also accepted for midnight). For weekly digests, specify a weekday such as "Tuesday". For monthly digests, you may specify a number from 1 to 31 corresponding to the day of the month when the digest will be distributed, although this is not recommended. The purpose here is to make it possible for digests to be issued at midmonth rather than on the first of the month if you code a number larger than 28, you may not get a digest every month. Finally, the last and optional parameter takes the form "Size(nnnn)" and specifies the maximum size the digest is allowed to reach before a "special issue" is cut. Bear in mind that most unix systems do not accept messages larger than 100 kilobytes, so values larger than 1500 should be avoided. The default is to have virtually no limit 10,000 lines. The list owner must take special care when disabling digests for a list, as LISTSERV does not presently have any facility which would allow it to alter subscription options automatically on the basis of changes to the list header. Subscribers who had opted for digests would continue not to receive mail as it arrives, but would not get the digests either. The best way to solve this problem is to announce the change long enough in advance, so that people can switch back before digests are suspended. The reason nothing has been done to remove this limitation is that it is not expected to be a frequent condition. Daily digests take up very little disk space and there is no reason to disable them for a typical list. )Body Text Indented)Body Text Left#I2PQP# InternetVia= netaddress %Body Text Left%#Body Text Indented##I2PQP#There is no default value. This parameter determines whether or not mail bound for Internet addresses is routed through a specific Internet gateway. )Body Text Indented)Body Text Left#I2PQP# MailVia= Direct | DISTRIBUTE | DIST2 %Body Text Left%#Body Text Indented##I2PQP#The default value is MailVia= DISTRIBUTE. DIST2 is functionally equivalent to DISTRIBUTE, and is included for historical reasons. MailVia= Direct causes LISTSERV to ignore the DISTRIBUTE algorithm for subscribers on the local system, but mail to nonlocal subscribers will still go out on the DISTRIBUTE backbone. )Body Text Indented)Body Text Left#I2PQP# Newsgroups= None | usenet_newsgroup1,usenet_newsgroup2... %Body Text Left%#Body Text Indented##I2PQP#This keyword defines the RFC822 "Newsgroups:" header for a list. This field may be required by certain news gatewaying software and should only be defined if the list is gatewayed to usenet and if the gatewaying software does require it. The default is "Newsgroups= None". A typical setting for this keyword might be: #d6X@DQ@# * Newsgroups= bit.listserv.lstownl #I2PQP# )Body Text Indented)Body Text Left#I2PQP# NJEVia= netaddress %Body Text Left%#Body Text Indented##I2PQP#There is no default value. This parameter determines whether or not mail bound for NJE addresses is routed through a specific gateway. )Body Text Indented)Body Text Left#I2PQP# Prime= Yes | No | when %Body Text Left%#Body Text Indented##I2PQP#Determines whether or not mail for the list is processed during "prime time", a value that is determined by the LISTSERV maintainer and is kept in the system configuration file. The default is "Prime= Yes". This can be most useful in controlling the load on the machine running LISTSERV. "Prime=" may also be set to an explicit time specification, e.g., )Body Text Indented)Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# Prime= MONFRI: 09:0017:00; SUNSAT:  %Code Example 1%#Body Text Indented##I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# )Body Text Indented)Body Text Left#I2PQP# ReplyTo= destination,Respect | Ignore | Both %Body Text Left%#Body Text Indented##I2PQP#Indicates whether the "Replyto:" tag supplied by the sender of the mail file is to be preserved or discarded (if present), and, if discarded or omitted, what should be placed in the new "Replyto:" generated by the server. The default value is "List,Respect". Note that some mailing systems are unable to process a "ReplyTo:" field with multiple addresses correctly and may therefore disregard the "Replyto= Both" option and treat it as "Replyto= List". 4 <DL!4 <DL!Respect:The original "Replyto:" tag, if any, is kept. Ignore:The original "Replyto:" tag is ignored and discarded. )Body Text Indented)Body Text Left#I2PQP#4 <DL!4 <DL! Sender= LIST | NONE | "list title <netaddress>",ietfaddress %Body Text Left%#Body Text Indented##I2PQP#Used to define the value LISTSERV will place in the RFC822 "Sender:" field. The second parameter is optional, and is included to allow the specification of a second mailbox for use with IETF headers. The first value is used for nonIETF headers and is expected to contain the name and address of the list, or the keywords LIST or NONE. The second mailbox is used for IETF headers; if it is omitted, the generic "ownerlistname" mailbox is substituted. Example: )Body Text Indented)Commands#d6X@DQ@##I2PQP##P6X@DQ@# * Sender= "Test List ",ownertest@listserv.x.edu Commands#Body Text Indented##I2PQP##d6X@DQ@##I2PQP# Note that the first address must be contained in quotes. )Body Text Indented)Body Text Left#I2PQP# Topics= topic1,topic2,...topic11 %Body Text Left%#Body Text Indented##I2PQP#List topics provide a way to run a mailing list (preferably moderated) where several subtopics are being discussed in parallel but some subscribers are only interested in a subset of the topics. For instance, a working group might have general discussions, decisions, and messages related to meetings. People who cannot attend the meetings can then opt out of last calls for hotel reservations and discussions about seafood restaurants, whereas people who have no time to follow the discussions can elect to get just the decisions. At any rate, such a compartmented list requires a certain discipline in order to be successful, as the posters must label their messages to indicate which topic(s) they belong to. Through the "Topics=" keyword, the list owner can define up to 11 topics for the list. For instance, the list owner could code: #d6X@DQ@# Topics= News,Benchmarks,Meetings,Betatests    4 <DL! <DL! #I2PQP# 1(p dd WARNING YOU MUST NEVER REORDER THE TOPICS= KEYWORD Ķ    <DL!4 <DL!  To save disk space, LISTSERV remembers which topics users have selected through their ordering in the "Topics=" keyword. That is, "News" is "topic number 1" for LISTSERV, "Benchmarks" is "topic number 2", and so on. This means you can change the name of a topic without requiring users to alter their subscriptions (for instance, you could decide that "Tests" is a better name than "Betatests" and just make the change). However, you must never change the order of the topics in the "Topics=" keyword. If you want to remove a topic, replace it with a comma. For instance, to remove the "Meetings" topic, you would change the keyword to: #d6X@DQ@# * Topics= News,Benchmarks,,Betatests #I2PQP# This restriction might be removed in a future release. Topic names can contain any character except space, colon and comma; the use of double quotes or equal signs is discouraged, as they require special attention when coding list header keywords. In addition, topic names may not start with a plus or minus sign, and the words ALL, NONE, RE, OTHER and OTHERS are reserved. Posters label their messages through the subject field. LISTSERV first skips any possible sequence of 'Re:' keywords, and takes anything to the left of a colon as a list of topics, separated by commas. The posting is considered to belong to all the topics listed before the colon. If none of these topics is valid for the list, it is classified in a special, 12th topic, "Other". If some of the topics are valid but others are undefined, the invalid ones are ignored. At any rate the subject field is left unchanged. Here is an example: Subject: Benchmarks,News: Benchmarks for XYZ now available! ‘Messages which should be read by everyone can be posted to the special topic "All". Topic names can be shortened to any unambiguous abbreviation. In our example, "Be" is ambiguous because it could be either "Betatests" or "Benchmarks", but "Bench" is acceptable. Subscribers select the topics they wish to receive with the SET command. The syntax is 'SET listname TOPICS: xxx' where 'xxx' can be: 4 <DL! <DL!A list of all the topics the user wishes to receive. In that case these topics replace any other topics the user may have subscribed to before. For instance, after 'SET XYZL TOPICS: NEWS BENCH', the user will receive news and benchmarks, and nothing else.  <DL!4 <DL! 4 <DL! <DL!Updates to the list of topics the user currently receives. A plus sign indicates a topic that should be added, a minus sign requests the removal of a topic. For instance, 'SET XYZL TOPICS: +NEWS BENCH' adds news and removes benchmarks. If a topic name is given without a + or sign, + is assumed: 'SET XYZL TOPICS: +NEWS BENCH' adds news and benchmarks. The first topic name must have the plus sign to show that this is an addition, and not a replacement.  <DL!4 <DL! 4 <DL! <DL!A combination of the above, mostly useful to enable all but a few topics: 'SET XYZL TOPICS: ALL MEETINGS'.  <DL!4 <DL! The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted. Do not forget to include the special OTHER topic if you want to receive general discussions which were not labeled properly. On the other hand, if you only want to receive properly labeled messages you should not include it. ALL does include OTHER. Finally, it is important to note that topics are active only when your subscription is set to MAIL. Digests are indexes always contain all the postings that were made, because the same digest is prepared and sent to all the subscribers. (See also DefaultTopics .) )Body Text Indented)Body Text Left#I2PQP#%Body Text Left% "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑError Handling Keywords keyError   (Dictionary Header(Body Text Left#I2PQP# AutoDelete= No %Body Text Left%#Body Text Indented##I2PQP# Yes,SemiAuto | FullAuto | Manual,Delay(number),Max(number) LISTSERV includes support for automatic deletion of users whose account has expired or whose system has permanently disconnected. When the delivery error is generated by LMail (any version), MX V3.2 or higher, PMDF V4.2 or higher, or LSMTP(TM) , which all implement the same delivery error format, LISTSERV may be able to automatically process the delivery error and take action based on the value of the "AutoDelete=" list header keyword. The unix versions of LISTSERV also support sendmails delivery error format. If the list has been coded "AutoDelete= No", or if the delivery error is not in LMail format and LISTSERV cannot understand it, LISTSERV simply passes it to the list owner. Otherwise LISTSERV processes the message automatically. The algorithm may be refined in a future version, but at present the following steps are taken: 4 <DL! <DL!1LISTSERV looks for "permanent" errors (no such user, no such host, and so on). If the failing recipients are subscribed to the list, LISTSERV removes them and notifies you. No action is required from the list owner.  <DL!4 <DL! 4 <DL! <DL!1If there are permanent errors for users LISTSERV could not find on the list for instance because the account subscribed to the list is a totally different one which forwards mail to a dead account), or if there are only "temporary" errors (host unreachable for 3 days, system error, disk quota exceeded, and so on), LISTSERV further examines the "AutoDelete=" keyword and passes the message to the list owner unless the list is coded "AutoDelete= Yes,FullAuto".  <DL!4 <DL! 4 <DL! <DL!1When running in fullauto mode, LISTSERV never passes back a delivery error unless it took action on it. This means that certain errors may remain unsolved, as LISTSERV presently ignores temporary errors and some of them are virtually permanent (if the owner of the account has left but for some reason his account was not closed, his disk quota is bound to remain exceeded until someone takes action). Fullauto mode is to be used only when the list owner positively does not have the time to handle the delivery errors LISTSERV sends every day.  <DL!4 <DL! 4 <DL! <DL!1When running in manual mode, the autodelete monitor informs the list owner of the error(s) and takes no further action on delivery errors.  <DL!4 <DL! Some considerations for configuring the autodelete monitor parameters: 4 <DL! <DL!1Setting the Delay(number) option. The default is 4. This is the number of days that a subscriber's mail needs to bounce before he's automatically deleted. If "Delay(0)" is coded, LISTSERV won't wait.  <DL!4 <DL! 4 <DL! <DL!Most delivery errors occur on weekends when systems are taken down for maintenance, system administrators are not around to reboot after crashes, and the like. Because of this, most delivery errors only last for 23 days and may not be "permanent" even if they seem to be at first. The nature of delivery errors is such that LISTSERV has no way to establish that a problem has been fixed because it receives only negative acknowledgements when a message bounces. This taken together with the transient, "weekend" nature of most delivery errors indicates that it is not a good idea to set Delay() to a value close to 7. For instance, if Delay(7) and a subscriber's mail regularly bounces on the weekend, LISTSERV will wait until the next weekend to decide whether or not to delete him, at which point the subscriber will bounce mail again and start the process all over. The bottom line is that LISTSERV might as well have gone ahead and deleted the subscriber as soon as the first bounce occurred.  <DL!4 <DL! 4 <DL! <DL!1Setting the Max(number) option. To prevent autodeletion monitoring from getting out of hand, subscribers are deleted after a specified number errors regardless of how many days it has been going on. The default is Max(100). This is so LISTSERV won't spend its life monitoring 50 bogus users x 100 messages = 5000 a day.  <DL!4 <DL! 4 <DL! <DL!1When you take a vacation, note that it is best to switch autodelete to MANUAL. Then do not restore to auto on the day you come back, because you will have a number of subscribers on file ready to be deleted. Wait DELAY+n days before changing back to FullAuto or SemiAuto, where n is an adjustment to account for the fact that people don't fix all problems right away at 09.00 on the day your vacation ends. n=2 is a reasonable choice.  <DL!4 <DL! The default value is "AutoDelete= No" for lists with "Validate= All" and "AutoDelete= Yes,SemiAuto,Delay(4),Max(100)" for other lists. )Body Text Indented)Body Text Left#I2PQP# ErrorsTo= monaddress1,monaddress2,... %Body Text Left%#Body Text Indented##I2PQP#Defines the person or list of persons that are to receive rejection mail for the list. The default value is 'Postmaster', and it is recommended that the owners change it to 'Owners' or 'Owners,Postmaster' as soon as they become familiar with LISTSERV. )Body Text Indented)Body Text Left#I2PQP# Loopcheck= Full | None | Noorigin | Nobody | NoCRC | NoSpam %Body Text Left%#Body Text Indented##I2PQP#Determines the type of loop checking performed by LISTSERV to avoid perpetuating mail loops. The default is "Loopcheck= Full". )Body Text Indented)Body Text Left#I2PQP# Safe= Yes | No %Body Text Left%#Body Text Indented##I2PQP#The list header keyword, "Safe= Yes/No", controls the email address LISTSERV places in the SMTP MAIL FROM: field, which is where wellbehaved mailers will return delivery errors. With "Safe= No", these errors are sent to the list address as before, hopefully to be intercepted by the loop detector and passed on to the list owner. With "Safe= Yes", the error address is set to 'ownerlistname', and delivery errors sent to that address are passed on to the list owner without the risk of creating a mailing loop. The default is "Safe= Yes". IMPORTANT: The use of "Safe= Yes" does not guarantee that all errors will go to the 'ownerlistname' mailbox. Unfortunately, there are many noncompliant mailers which will continue to send the error back to the list (usually because it is listed in the 'ReplyTo:' or 'Sender:' field). The use of the "Safe= Yes" option significantly decreases the potential for mailing loops, but not enough to actually code "Loopcheck= No", unless you are sure that all your subscribers have compliant mailers. )Body Text Indented)Body Text Left#I2PQP#%Body Text Left% "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑList Maintenance and Moderation KeywordskeyListMaint  (Dictionary Header(Body Text Left#I2PQP# Editor= netaddress1,netaddress2,... %Body Text Left%#Body Text Indented##I2PQP#Defines the list editor(s). When used in conjunction with the "Send=Editor" option, it causes all mail sent to the list to be automatically forwarded to the first person listed in the "Editor=" keyword, who will then send it back to the list at his discretion. The editors are the only persons (with the list owners) who are allowed to mail directly to the list. Note that ANY editor can send mail to the list while only the FIRST one will receive copies of mail sent to the list (but see also Moderator=). The file will be forwarded to the editor 'as is', without being included in a mail envelope. This method makes sure that the original "Resent" tags (if any) and "To:" keyword are preserved. Note that the first editor must be a network address (e.g., #d6X@DQ@# someuser@foo.bar.com #I2PQP#) and not an accesslevel. Subsequent editors may be accesslevels. For instance, you can code )Body Text Indented)Code Example 1#d6X@DQ@# 4 <DL!` <DL!#I2PQP# #d6X@DQ@# * Editor= joe@baz.net,(MYLISTL) %Code Example 1%#Body Text Indented##I2PQP#` <DL!4 <DL!#d6X@DQ@##I2PQP# which allows all subscribers from the MYLISTL list to post without going through the editor, and diverts all nonsubscriber mail to joe@baz.net for approval. IMPORTANT NOTE: The first editor MUST be a human person, not a file server, list server, mailer, or suchlike. Specifying a program's mailbox as the primary editor could result in a mailing loop for which LSoft international, Inc., could not be held responsible. )Body Text Indented)Body Text Left#I2PQP# EditorHeader= Yes | No %Body Text Left%#Body Text Indented##I2PQP#If an editor is defined (see Editor= ), this keyword determines whether or not special header information is prepended to list messages forwarded to the editor. The default (for lists configured with an Editor) is "EditorHeader= Yes". )Body Text Indented)Body Text Left#I2PQP# ListAddress= name_info@host_info This keyword determines how LISTSERV announces its list address in the header of messages delivered to the list: NJE vs. Internet address, short vs. long list name, etc. The default options (when neither "ListAddress=" or LIST_ADDRESS are defined) are long list name and Internet address. A corresponding LIST_ADDRESS configuration option must be added to the LISTSERV configuration file. The first token (name_info) can be either LISTNAME or LISTID. Do not attempt to specify the actual list name. Use LISTNAME if you want LISTSERV to use the "short" list name (always available), and LISTID if you would rather see the "long" list name ("ListID=" keyword). If there is no "long" name, the short name is substituted. The second token (host_info) can be either NJE, FQDN, or the fully qualified domain name of your choice. That is, you may type the actual hostname that you want LISTSERV to use, which may be useful if the machine on which LISTSERV is running is known under several hostnames. If you only want to override one of the two parts of the list address, you do not need to specify the other. For instance, if you only want to change the hostname, you can enter "ListAddress= XYZ.EDU" in the list header and let the lefthand part default from the value of the system default in the LISTSERV configuation file. Similarly, "ListAddress= ListID" takes the righthand part from the system default. To avoid bad surprises, LISTSERV will also accept a comma in lieu of @sign in the list header, or a blank in the LISTSERV configuration file. Here are a few examples: 4 <DL! <DL!"ListAddress= FQDN" announces the list under the Internet address for the LISTSERV host, if one is available (for BITNETonly sites this setting has no effect).  <DL!4 <DL! 4 <DL! <DL!"ListAddress= ListID@FQDN" uses the long list name and the Internet hostname.  <DL!4 <DL! 4 <DL! <DL!"ListAddress= Listname@XYZ.EDU" uses the short list name and the hostname XYZ.EDU.  <DL!4 <DL! 4 <DL! <DL!"ListAddress= XYZL@XYZ.EDU" is not valid. Always specify LISTNAME or LISTID for the lefthand part.  <DL!4 <DL! ListID= name %Body Text Left%#Body Text Indented##I2PQP#On VM systems, this keyword allows the list owner to specify a long list ID in addition to the normal 8character list name. This is particularly useful for peered or gatewayed lists that have names longer than 8 characters. On nonVM systems, if the normal list name is longer than 8 characters and the list is being migrated from a VM system, it may be a good idea to specify the first 8 characters of the list name in this keyword, at least temporarily. This way subscribers who were used to the old 8character name can continue to use it on the new system. NonVM systems may use this keyword for aliasing. )Body Text Indented)Body Text Left#I2PQP# Moderator= <netaddress1>,<netaddress2>.... %Body Text Left%#Body Text Indented##I2PQP#This keyword defines which editors of a moderated list receive postings for forwarding to the list. The default is the first editor as defined by the "Editor=" keyword. If multiple moderators are defined, the load is spread across them. Note that all editors may still post directly to the list, but only those editors defined by "Moderator=" will have messages from noneditors forwarded to them. )Body Text Indented)Body Text Left#I2PQP# phoenix[NB]950620001%Body Text Left% NewList= netaddress %Body Text Left%#Body Text Indented##I2PQP#When a list is moved to a different LISTSERV host, this keyword can be added to the list header left on the original host. This facilitates forwarding of administrative commands and postings from the original host to the new host. Users posting to the old address will also receive a short note in return listing the new address. )Body Text Indented)Body Text Left#I2PQP# Notebook= No | (Yes,where,interval|Separate,accesslevel) %Body Text Left%#Body Text Indented##I2PQP#Indicates whether or not an automatic log of every piece of mail sent to the list is to be kept, and defines at which interval of time its file name must be changed and who is allowed to retrieve it from the server. The default values are "Notebook= No,A,Single,Private". 4 <DL!4 <DL!where is the filemode of the minidisk (VM) or the disk and directory (nonVM) on which the notebook is to be kept. intervalDefines the filetype or extension of the "notebook" file for the list, as indicated below (the filename will always be the same as the list name): 4 <DL!uDL! Single:A single file with the extension "NOTEBOOK" is created. Yearly:A new file is started each yearly, extension is "LOGyy" Monthly:The extension is "LOGyymm" Weekly:The extension is "LOGyymmw" (w in "A""E") Separate:A separate file is kept for each mailing (e.g. announcements, newsletters). The extension is "yynnnnn" (sequential counter). uDL!4 <DL! Note: Notebooks may be retrieved by means of the GET command. A list of all available notebooks can be obtained with a GET NOTEBOOK FILELIST command. )Body Text Indented)Body Text Left#I2PQP# NotebookHeader= Short | Full %Body Text Left%#Body Text Indented##I2PQP#Determines whether or not individual message in notebook archives are stored with full Internet header information or with "short" headers. The default is "NotebookHeader= Short". )Body Text Indented)Body Text Left#I2PQP# Notify= Yes | No | monaddress %Body Text Left%#Body Text Indented##I2PQP#Defines whether the list owner (or the person indicated by "Notify= monaddress") is to receive notification of new subscriptions and deletions, etc. The default is "Yes". )Body Text Indented)Body Text Left#I2PQP# Owner= netaddress1 | monaddress1,... %Body Text Left%#Body Text Indented##I2PQP#Defines the person or list of persons who "own" the list. They are responsible for controlling access to the list and defining the list control keywords which are best suited to the purpose of the list. The default value for this keyword which should ALWAYS appear in the list header is the list of the userids of the postmasters. Any combination of explicit network addresses and complex accesslevels is acceptable, for example: Owner= BIG@BLUE,(STAFFL),Owner(MAINL) An interesting application is to create a STAFFL list containing the userids of all the local LISTSERV staff members and set the "Owner=" keyword of all local lists to "Owner= (STAFFL)". This way when there is a change in the local LISTSERV management it is not necessary to modify the headers of all the lists ! just modify the STAFFL list. )Body Text Indented)Body Text Left#I2PQP# Peers= peer1,peer2,... %Body Text Left%#Body Text Indented##I2PQP#Defines the (global) list of all the servers in the world that are peerlinked to the list, either directly or via one or more other peer servers. This information is used by the various list management commands to determine the "nearest" peer list to a given user. For example, when a SUBSCRIBE command is received from a user and it is determined that there is a better (nearer) peer list for him, the subscription request is automatically forwarded to the appropriate LISTSERV. Be sure to read the appropriate sections of the LISTSERV List Owner's Manual before peering any list. )Body Text Indented)Body Text Left#I2PQP# Renewal= interval1,interval2...,intervalx,Delay(number) %Body Text Left%#Body Text Indented##I2PQP#This keyword controls whether or not subscribers are required to renew their subscriptions on a regular basis, and what the subscription period is. Multiple intervals can be set, each interval being one of several things: ‘ 4 <DL! <DL!Monthly, Yearly, Weekly, or a numeric variation such as 3Monthly (meaning, quarterly). An absolute date in the format yy/mm/dd (once on this specific day), the format mm/dd (once yearly on this day), or the format dd (once monthly on this day). The confirmation delay, in the format Delay(n), where (n)=the number of days between the time the subscriber is asked to confirm the subscription and the day the user is removed from the list. This default is Delay(7), or seven days.  <DL!4 <DL! A typical Renewal= configuration might be: #d6X@DQ@# * Renewal= 6Monthly,Delay(14) #I2PQP# Conceivably Renewal= could also be set to something like: #d6X@DQ@# * Renewal= 6Monthly,95/07/04,12/25,15,Delay(14) #I2PQP# which would cause LISTSERV to send renewal requests once every six months on the anniversary date of the user's original subscription, a specific request on 4 July 1995, a request every year on Christmas Day, and a request every month on the 15th day of the month. Note that this is provided ONLY as an example. LSoft does not recommend using a renewal scheme of this sort. )Body Text Indented)Body Text Left#I2PQP# Sizelim= number %Body Text Left%#Body Text Indented##I2PQP#If set, causes LISTSERV to truncate all messages to the list to the number of lines indicated. This can be helpful in discouraging subscribers from posting long screeds or uuencoded files to your lists. It can also be set higher than the LISTSERV default if desired; check with your LISTSERV maintainer before changing this upward. (Generally "Sizelim= 250" is large enough for long posts but short enough to discourage postings of uuencoded binaries, but of course, your mileage may vary.) )Body Text Indented)Body Text Left#I2PQP# XTags= Comment | Yes | No %Body Text Left%#Body Text Indented##I2PQP#Indicates whether "XTo:" and "Xcc:" tags are to be included in the output mail files to list recipients of the original mail file (other than the list userid) or not, and how they should appear in the RFC822 header. 4 <DL!4 <DL!Yes:This information must be provided in the form of "XTo:" and "Xcc:" tags in the RFC822 header (similar to the "To:" and "cc:" tags). This is the default. Comment:This information must be provided in the form of "Comment:" tags, i.e. "Comment: XTo:" and "Comment: Xcc:". No:This information must not appear at all in the mail header. )Body Text Indented)Body Text Left#I2PQP#4 <DL!4 <DL!%Body Text Left% "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑSecurity KeywordskeySecurity  (Dictionary Header(Body Text Left#I2PQP# Confidential= No | Yes | Service %Body Text Left%#Body Text Indented##I2PQP#Indicates whether the list should be hidden from users or not. A confidential list will not appear on the "List" command output. "No" is the default value and indicates that the list is not confidential. "Service" indicates that the list is to be hidden from users who are not in the list's service area (see "Service=" keyword) but not from other users. "Yes" means that the list is unconditionally confidential. )Body Text Indented)Body Text Left#I2PQP# Exit= filename %Body Text Left%#Body Text Indented##I2PQP#Background for nontechnical users: an "exit" is a program supplied by the customer to modify the behavior of a product (such as LISTSERV) in ways that the supplier of the product could not anticipate, or could not afford to support via standard commands or options. The product checks for the presence of the "exit" program and calls it on a number of occasions, called "exit points". In some cases, the "exit" program supplies an answer ("return code") to the main program, which adjusts its behavior accordingly. For instance, LISTSERV may ask an exit program "Is it OK to add JOE@XYZ.EDU to the ABCL list?", and the program will answer yes or no, and possibly send a message to the user explaining why his subscription was accepted or rejected. In other cases, the "exit point" call is purely informative: the exit program gets a chance to do something, such as sending an informational message to a user, but does not return any answer. Because this "exit" is a computer program, it must be prepared by a technical person and installed by the LISTSERV maintainer. Starting with version 1.8a, list "exits" are available to control the major events associated with list maintenance. This makes it easier to tailor the behavior of LISTSERV to local requirements that are too specific to be addressed through standard facilities. An exit is enabled by adding "Exit= filename" to the list header. For security reasons, all exits must be explicitly declared in the LIST_EXITS configuration variable (in the LISTSERV configuration file). This prevents list owners from causing the invocation of arbitrary executable files through the use of the "Exit=" keyword. This keyword is not generally usable by list owners without specific intervention by the LISTSERV maintainer, and thus is not otherwise documented here. )Body Text Indented)Body Text Left#I2PQP# Local= node1,node2,... %Body Text Left%#Body Text Indented##I2PQP#Defines the nodes which are to be considered as 'local nodes' for both service area checking. The local node is automatically considered as a 'local node' and does not have to appear in the list. Subscribers from any of the local nodes will receive separate pieces of mail with a single recipient in the "To:" field ! in other words, they will never receive a grouped piece of mail as nonlocal recipients would if there are more than one recipient in their node. Note that 'node' is a generic term that means "anything after the '@' sign in the network address". For instance, "SEARN" and "SEARN.SUNET.SE" are both valid node names. )Body Text Indented)Body Text Left#I2PQP# PW= listpassword Defines the list password. When sending the list back to the server, the password is prefixed to the list file for validation (see the Validate command for more specifics). The PW= parameter is "invisible" once it is defined; that is, for security reasons, it does not appear either when the list is reviewed or when it is retrieved with a GET command by the list owner. ‘ Service= area1,area2,... %Body Text Left%#Body Text Indented##I2PQP#Defines the 'service area' outside of which subscription requests must not be accepted. When a SUBSCRIBE command is received, the "Peers=" keyword is checked first to see if there is a nearer peer list in the network. If it is the case, the command is forwarded to this nearer server. If not, the service area is checked to ensure that the recipient is acceptable; if it is not, the subscription request is denied. When the command is forwarded, the destination server might still deny access to the list if the subscriber is outside its own service area, if any. It is important to note that the service area check is made only after the "best placement" check. This allows several servers in the same country to share an identical service area, e.g. "Service= Germany", and still have users subscribed to the best possible server. )Body Text Indented)Body Text Left#I2PQP# Validate= No | Yes,Confirm,NoPW %Body Text Left%#Body Text Indented##I2PQP#Under LSoft's LISTSERV, lists are protected by a password which must be specified by the list owner when he sends an updated version of the list back to the server. When "Validate= Yes", password validation applies to ALL the commands that modify the contents of the list, e.g. SIGNOFF, SET, etc. This implies that users cannot use these commands since they do not know the list password. A notable exception is the SUBscribe command, which can still be used (if enabled) to get on the list; however, sending a second SUBscribe command for the same list (to correct a spelling error in your name) would result in the command being forwarded to the list owner and not immediately executed. This is to protect you from network hackers who might issue a command "from" your userid@node to change list settings, such as who has the ability to GET and PUT the list, review concealed subscribers, etc. The default is "No", but it is recommended that "serious" or "important" lists be changed to "Validate= Yes". This keyword was revised substantially in versions 1.7f and 1.8a. The "OK" command confirmation mechanism was introduced in version 1.7f, where it was used to implement the "Subscription= Open,Confirm" address verification mechanism. When a user tries to subscribe to a mailing list with that setting, he is mailed a confirmation request with a randomly generated confirmation key, also known as "magic cookie". The user replies to the message, types "OK" in the message body, and the command is confirmed. If for any reason the user's address cannot be replied to, the confirmation request is never received (or the "OK" message never arrives) and the user is not added. In versions 1.8x, this procedure is also used for authentication purposes. Since the confirmation codes are valid only for a single command, this provides better security than personal passwords, while simplifying bookkeeping. As before, the security level of the mailing list is controlled through the "Validate=" keyword. The contents of this keyword, however, have changed from earlier versions (the old values are still accepted for compatibility reasons, but generate a warning with an explanatory message when you update the list header. This may change in subsequent versions, so it is advisable to use the new values). The following security settings are available: 4 <DL! <DL!"Validate= No" (formerly "Validate= Store only"): all commands except PUT are taken at face value with no validation. While users are not bothered with validation requests, the list is totally unprotected from attacks by hackers. For compatibility reasons, this is the default setting.  <DL!4 <DL! 4 <DL! <DL!"Validate= Yes" (formerly "Validate= All commands"): "protected" commands, such as DELETE or ADD, require password validation. For list owner commands, both personal and list passwords are accepted. Some user commands may accept a personal password, while others will cause the request to be forwarded to the list owners for verification.  <DL!4 <DL! 4 <DL! <DL!"Validate= Yes,Confirm" (new level): protected commands are validated using the "OK" mechanism by default, although passwords are also accepted where appropriate. This is a good compromise between list security and list owner convenience.  <DL!4 <DL! 4 <DL! <DL!"Validate= Yes,Confirm,NoPW" (new level): protected commands are validated using the "OK" mechanism. Passwords are not accepted, as they are not as safe as "cookies". This is the recommended setting for secure lists.  <DL!4 <DL! 4 <DL! <DL!"Validate= All,Confirm" and "Validate= All,Confirm,NoPW" (new levels): all commands causing a change in state, except the PUT command, are validated using the "OK" mechanism, with or without a password alternative. Commands such as QUERY do not require any validation.  <DL!4 <DL! 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. The PUT command must always be validated with the list password, because there is presently no mechanism to suspend execution of a request to which a file is attached. If the list password is used only for that purpose, the exposure is minimal as PUT operations are not part of everyday list management routine. Note that PUT requests require no validation when submitted via SENDFILE from the machine on which LISTSERV is running, as the operating system then guarantees the authenticity of the transaction. For lists operating with "Validate= Yes" (without the "Confirm" option), LISTSERV may still use the "OK" mechanism in certain cases if it is deemed appropriate. LISTSERV's rationale is that the "Validate=" keyword describes the desired behavior for interaction with the list owner and people who can be expected to use the list on a regular basis. SIGNOFF requests and DELETE requests from registered node administrators on behalf of a user on their machine, for instance, may be validated using the "OK" mechanism even though that was not requested, because users and node administrators are not generally expected to have a password with which to validate such requests. )Body Text Indented)Body Text Left#I2PQP#%Body Text Left% "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑSubscription KeywordskeySubscription  (Dictionary Header(Body Text Left#I2PQP# ConfirmDelay= number %Body Text Left%#Body Text Indented##I2PQP#This parameter is an integer representing the number of hours LISTSERV will hold subscription jobs requiring confirmation before flushing them from its queue. For instance, if Subscription= Open,Confirm and ConfirmDelay= 72, LISTSERV will accept a subscription request pending confirmation, send the "cookie" command confirmation request, and will wait 3 days (72 hours) for that confirmation to be received. If the period expires before the "cookie" is received, the subscription request is deleted and the subscriber must resubmit his or her request. The default setting is 48 hours (2 days). Many unreliable gateways have a turnaround time of several days, and this is another way to filter them: if the confirmation delay is long enough, they will never manage to subscribe and you will not have to put up with gateways that take a week to realize that the subscriber's account has expired and return a week's worth of delivery errors. On the other hand, if you do want to let these people in, you will have to increase the confirmation delay to a week or so (1 week=168 hours). See also Subscription= . )Body Text Indented)Body Text Left#I2PQP# DefaultOptions= option1,option2,... %Body Text Left%#Body Text Indented##I2PQP#A "DefaultOptions" keyword is available to define initial personal options for new subscribers. The syntax is the same as for the SET command, except that options are separated by commas in the usual fashion. DefaultOptions does not affect existing subscribers. A typical DefaultOptions setting might be: #d6X@DQ@# * DefaultOptions=Nofiles,Norepro,Msg #I2PQP# )Body Text Indented)Body Text Left#I2PQP# DefaultTopics= topic1,topic2,... %Body Text Left%#Body Text Indented##I2PQP#A "DefaultTopics=" list header keyword is available to define the initial topics for new subscribers. The syntax is the same as for the SET command, except that topic names are separated by commas in the usual fashion and that the first topic may not start with a + or sign (there is nothing to add to, as this is a new subscription). This is similar to "DefaultOptions=" in that it does not affect existing subscribers. Users who signed up before topics were enabled on the list are automatically subscribed to all topics. )Body Text Indented)Body Text Left#I2PQP# Subscription= By owner | Closed | Open ,Confirm %Body Text Left%#Body Text Indented##I2PQP#This keyword defines whether or not new users are allowed to subscribe to the list, and if not, whether their subscription requests are to be forwarded to the list owner or not. 4 <DL!4 <DL!Open:The users are allowed to subscribe to the list. By owner:The users are not allowed to subscribe, but their requests will be forwarded to the list owner. This is the default. Closed:The users are not allowed to subscribe, and their requests are not to be forwarded to the list owner. 4 <DL!4 <DL! One problem plaguing some mailing lists is oneway or nonrepliable addresses. Most of the time this is due to a small number of faulty gateways, which one can just ban from the list until their maintainers address the problem. But sometimes the very topic of the list is bound to attract a large number of people connected through such gateways, and the amount of domains to filter out becomes unmanageable. This is particularly problematic when the gateway keeps quiet for a few days, and suddenly returns hundreds of delivery errors with a promise to keep doing so every day for another 6 days. This problem can be avoided by probing the return address before accepting the subscription. If the address cannot be replied to, only one delivery error will be bounced to the list owner (perhaps for several days, but there will be a single undeliverable message). With a gateway that waits 3 days before sending its first delivery error, however, there can be hundreds of messages "in the pipe" if the subscription is accepted directly. This probing is activated by specifying "Subscription= Open,Confirm" in the list header. When a user attempts to subscribe to the list, he is mailed a confirmation request with a randomly generated "confirmation code". The procedure for confirming the subscription is simple you just reply to the message, type "OK", and send. If the return address does not work, the request will never be confirmed and the user will not be subscribed. And since the user cannot guess the confirmation code he will be assigned, he cannot "cheat" by sending the confirmation along with his request. The subscription request also expires after a certain amount of time, as determined by the "ConfirmDelay=" keyword (the default is 48h).)Body Text Indented) "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑOther Keywords keyOther   (Dictionary Header(Body Text Left#I2PQP# Language= idiom %Body Text Left%#Body Text Indented##I2PQP#Defines the language in which information mail and messages are to be sent to subscribers of the list. The postmaster must have provided the required data file to the server, of course. The default language is "English", of course. Currently only information mail is available in several languages. )Body Text Indented)Body Text Left#I2PQP# Indent= number %Body Text Left%#Body Text Indented##I2PQP#Determines the minimum number of columns allowed for list addresses in response to the REVIEW command. The default is Indent= 40. )Body Text Indented)Body Text Left#I2PQP# LongLines= Yes | No %Body Text Left%#Body Text Indented##I2PQP#Enables or disables "longlines" support. This keyword was added to maintain compatibility with LISTEARN and will be removed in a future version of LISTSERV. The default is "LongLines= Yes". It is unlikely that this keyword will need to be set for any list. )Body Text Indented)Body Text Left#I2PQP# Translate= Yes | No %Body Text Left%#Body Text Indented##I2PQP#Determines whether LISTSERV keeps or removes control characters from files which it distributes. "Translate= Yes" removes control characters; "Translate= No" keeps them. The default setting is "Translate= Yes".)Body Text Indented) "Dictionary Header"#g2PQP# #I2PQP# #g2PQP# ÑDefault Values for all keywordskeyDefaultValues  (Dictionary Header(Body Text Left#I2PQP# Ack= Yes AutoDelete= No if Validate= Yes, Yes,Delay(4),Max(100) otherwise Confidential= No ConfirmDelay= 48 DailyThreshold= 50 DefaultOptions= DefaultTopics= Digest= Yes,Daily,Same if Notebook= Yes, No otherwise Editor= EditorHeader= Yes ErrorsTo= Owner Exit= Files= No Filter= Indent= 40 InternetVia= Language= English ListAddress= (per LIST_ADDRESS system default) ListID= Local= LongLines= Yes Loopcheck= Full MailVia= DISTRIBUTE Moderator= (defaults to first Editor if Editor=  is defined)) NewList= Newsgroups= NJEVia= Notebook= No,A,Single,Private NotebookHeader= Short Notify= Yes 4 <DL!4" <DL!Owner= (This is a mandatory parameter which must be filled with at least one person's network address in userid@node or userid@fqdn format) 4" <DL!4 <DL!Peers= Prime= Yes PW= Renewal= ReplyTo= List,Respect Review= Public Safe= Yes Send= Public Sender= List Service= Sizelim= Stats= Normal,Private Subscription= Open Topics= Translate= Yes Validate= No XTags= Yes %Body Text Left%#XP\  P6QXP# Section Heading #g2PQP# #C\  P6QP# #g2PQP# ÑAppendix C: Sample Boilerplate FilesAppendixC &Section Heading&Body Text Left#I2PQP# Socalled "boilerplate" files are handy for list owners who find themselves answering the same questions over and over again. Usually these questions refer to basic LISTSERV usage. You can save yourself a lot of time by keeping files online such as the ones below to cut and paste into replies. Feel free to edit these to suit your own tastes (or compose your own!). (Be sure to insert the appropriate list names and LISTSERV hosts as required.) %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.1. Subscription requests sent to the list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV subscription requests need to be sent to the LISTSERV address rather than to the list itself. You do this by sending mail to LISTSERV@host with the command SUB listname Your Name as the body of the message. If you are unfamiliar with LISTSERV and its associated commands, I suggest that you add the commands INFO GENINTRO INFO REFCARD as additional lines of your message. LISTSERV will then send you a file containing a General Introduction to Revised LISTSERV that will give you some instruction on the service and a Quick Reference Card of the various commands. Thanks for your interest. If you have trouble subscribing with this method, please let me know and I will attempt to help. [if you have #d6X@DQ@# Subscription= Open,Confirm #I2PQP# you might want to add the following:] Because LISTSERV verifies mailing paths for new subscribers (a process not implemented when the list administrator adds people manually), it is preferred that users subscribe themselves by the method outlined above. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.2. User is sending other commands to the list, or to the *request address for the list )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! On Sun, 20 Mar 1994 22:44:25 0800 (PST) you said: >"INFO REFCARD" You need to redirect LISTSERV commands like the above (minus the double quotes by the way :)), to . The *request type addresses are for reaching the person that run the list. [another version:] You've sent mail that appears intended for a mailing list to one of the addresses used to reach the list owner. That is, rather than sending your mail to listname@host you've sent the note to OWNERlistname@host or listnameĩREQUEST@host. Please resend the appended note to the list address if you haven't done so already. © original message follows: %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!‘%Body Text Left%C.3. User isn't subscribed but complains that he's getting mail anyway )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! [Use this one after you have done an exhaustive search of the list and determined that the person simply isn't on the list. Typically the user is subscribed to a redistribution list and doesn't realize it.] Unfortunately I can't unsubscribe you from listname because you aren't subscribed to listname@host. I have run a check to see if you might be subscribed under a slightly different network address and have not found anything. There are a few possibilities you should look into. Are you getting a digest? Are you perhaps getting a redistributed copy of postings, possibly from a redistribution list? If you look at the mail headers, and there is an indication that you may be getting the postings from another source, you will have to ask the people that run the other source to remove you from their list. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.3. User unsubscribed successfully but is still getting list mail )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! I've done a search of listname for a possible duplicate subscription for you and have not found anything. It's possible that the mail you are receiving was actually sent from listname before your unsubscribe request was processed. Depending on the routing, it could take anywhere from 24 to 48 hours for all such messages to get through the network, so please be patient. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.4. Quoted replies from user's mail client includes message headers in the mail body, causing them to be bounced to the list owner )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! [If you forward such messages to the list, or back to the sender, you can add the following at the beginning. I ran across this one in the CBAYL mailing list archives, and edited it slightly.] This message was sent to me from LISTSERV instead of the list. The original message included the entire message being replied to, including the mail headers. These headers in the body pointed to the list itself. LISTSERV has mailloop avoidance code and when it sees headers that it thinks it generated itself, it bounces the message to the list owner. If your mail client does this, please remember to delete such "included header lines" from the body of your list replies. ©original message %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.5. Asking a postmaster for help on a bounced address you've set to NOMAIL, with a cc: to the bounced address )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Postmaster(s), Can you shed any light on the following error message? Please let me know what you find as I have removed the email address from the mailing list in question and would like to restore service as soon as is feasible. Thanks. Aside to user: Should this note reach you (meaning that the mail delivery problems have been resolved), you can reenable your mail service by sending mail to listserv@host with the command, SET listname MAIL %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!‘%Body Text Left% #I2PQP##XX2PQXP# C.6. You get a delivery error that doesn't specify which user account is causing the bounce )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Postmaster, I received the appended mail delivery report from your system and need help isolating the email address that is causing the error. That is, there are multiple recipients from your system on the list but the delivery error doesn't explicitly mention any of the users on the list. I'm including a list of subscribers from your system. If any of them are no longer valid, or aren't usable address for some other reason, please let me know. © list of email address on the indicated list follows: %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# C.7. You've set a user to DIGEST because of bouncing mail and the user is asking why he is now getting the digest )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! I received a mail delivery error for your address and issued a SET listname DIGEST on your behalf to minimize the number of bounce messages. I also sent a copy of the error I received to your postmaster (or the postmaster of the mail gateway that generated the error), asking for help. And since such delivery problems are often transient, I CC'd a copy of that note to your address, and included instructions for turning your mail back on. Apparently I didn't hear anything from your postmaster, or he/she said not to turn your mail back on until the problem was resolved. If they had responded and said the problem was resolved, I would have set you back to MAIL.. The other possibility is that I received a mail message indicating that there was some temporary problem with your account. In that case, for example if you had exceeded your disk quota and couldn't receive any new mail, I would not have bothered your postmaster. I have a different form letter that I send when that happens. Again it explains what has occurred and includes instructions for reenabling your mailing list subscription. But I only send that one to the address the list member. Either way, whatever was wrong has been corrected, and you'd probably like to start receiving mail again. So, here's how you can restore your mail service. If you have any problems doing so, please let me know and I'll help. But since I don't know which of the three mail service options you had chosen before, I can't do it for you without guessing. You can reenable your mail service by sending mail to listserv@host with one of the following commands SET listname MAIL SET listname DIGEST (if you want digestformat mail) SET listname INDEX (if you want digestindexformat mail) in the *body* of the mail message. Please note that these settings are mutually exclusive, you can't choose more than one. :) %Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# ÑAppendix D: Related Documentation and SupportAppendixD &Section Heading&Body Text Left#I2PQP# %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# D.1. Official LSoft Documentation )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! Perhaps the best general overview of LISTSERV readily available at this time can be found in a document called "LISTSERV for the nontechnical user", which is available from LISTSERV@LISTSERV.NET in several formats: NSC93.MEMO(plain ASCII text) NSC93US.PS(for US users) NSC93A4.PS(for European users and others using A4 paper size) Subscribers to LISTSERV mailing lists will find answers to many of their questions in the User's Guide to LISTSERV Version 1.8b. (This document will be available in late 1995.) LISTSERV Maintainers will be interested in the LISTSERV Maintainer's Manual for LISTSERV 1.8b, which will be available by the end of 1995. All of LSoft's manuals for LISTSERV are available in asciitext format via LISTSERV and in popular wordprocessing formats via #d6X@DQ@# ftp.lsoft.com #I2PQP#. They are also available on the World Wide Web at the following URL: #d6X@DQ@# URL: http://www.lsoft.com/manuals/index.html #I2PQP#LSoft invites comment on its manuals. Please feel free to send your comments via email to MANUALS@LSOFT.COM. %Body Text Left%#Section SubHeading##XX2PQXP# 4 <DL!4 <DL!#I2PQP# #XX2PQXP# D.2. UserCreated Documentation )Section SubHeading)Body Text Left#I2PQP#4 <DL!4 <DL! LISTSERV began as a noncommercial product, with fairlycomplete but terse documentation. Over time, list owners and LISTSERV maintainers found that it was necessary to amplify some of the documentation, and wrote their own manuals. Some of these manuals, while they may be dated, are still of value and are still available. %Body Text Left%Body SubHead#I2PQP#   D.2.1 LSVOWNER package available from UBVM  #Body SubHead#Body Text Left#I2PQP# The LSVOWNER package contains some handy LISTSERV List Owner files created by Jim Gerland, gerland@ubvm.cc.buffalo.edu. To have LISTSERV send you the files, send a GET LSVOWNER PACKAGE command to LISTSERV@UBVM.CC.BUFFALO.EDU. Here are the files currently (1 March 1995) available: LSVOWNER READY'Your List is Ready' boilerplate LSVOWNER WELCOME'Welcome to this list' boilerplate LSVOWNER TXTGeneric List Owner Instructions LSVOWNER NEWLIST New List Announcement boilerplate LSVOWNER GATEWAY USENET News Gateway boilerplate LSVOWNER HEADERS List header instructions LSVOWNER FILLIST FILELIST instructions Jim adds: "You can subscribe to the package by sending an AFD ADD LSVOWNER PACKAGE command. You will then receive a new version of the filelist as updates are received by the server, with only the updated files being sent to you. You can also subscribe to File Update Information notices for the package by sending a FUI ADD LSVOWNER PACKAGE command." ‘ %Body Text Left%Body SubHead#I2PQP#   D.2.2. LISTSERV TIPS  #Body SubHead#Body Text Left#I2PQP# LISTSERV TIPS is a document with the formal title "List Management Tips for LISTSERV Postmasters and List Owners". It was compiled in 1991 by Lisa Covi. LISTSERV TIPS can be retrieved from the LISTSERV hosts at SEARN and UBVM (among others) with the usual GET command. The document has never been updated and is very BITNEToriented, but is still quite useful as a basic information source on running a list. %Body Text Left%Body SubHead#I2PQP#   D.2.3. FSV GUIDE  #Body SubHead#Body Text Left#I2PQP# FSV GUIDE (formal title: "Setting Up the LISTSERV File Server ! A Beginner's Guide") is really aimed at LISTSERV maintainers, but it is a handy guide for list owners who have filelists on VM systems as well. Ben Chi (bec@albany.edu) is the author of this fine document about the VM LISTSERV file server system. You can get a copy from LISTSERV@ALBANY.EDU. %Body Text Left%Body SubHead#I2PQP#   D.2.4. NetNews Gatewaying (See also Chapter 10)  #Body SubHead#Body Text Left#I2PQP# The following files are available from LISTSERV@AMERICAN.EDU (and also by anonymous ftp to american.edu (cd netnews)) relating to the NetNews gatewaying service there. NETGATE POLICYProcedure for Establishing a Gateway NETGATE GATELISTList of Gatewayed LISTSERV Lists NETGATE MODLISTSimilar to news.admin Post You can subscribe to the package by sending an AFD ADD NETGATE PACKAGE command. You will then receive a new version of the file as updates are received by the server, with only the updated files being sent to you. You can also subscribe to File Update Information notices for the package by sending a FUI ADD NETGATE PACKAGE command. %Body Text Left% Section Heading #g2PQP# #I2PQP# #g2PQP# ÑAppendix E: AcknowledgmentsAppendixE &Section Heading&Body Text Left#I2PQP# %Body Text Left%Body SubHead#I2PQP#   Acknowledgments  #Body SubHead#Body Text Left#I2PQP#Over the years, a number of people have written valuable documentation of the LISTSERV product. This documentation was constantly consulted by this writer in the course of producing LSoft's official manuals. In no particular order, I would like to acknowledge the efforts of Lisa Covi, Ben Chi, Jim Gerland, Marty Hoag, and (of course) Eric Thomas in producing the basis for this work. Thanks also go to John Harlan for helping me get my start in owning lists. I wouldn't be writing this today without his initial willingness to assist me. And I promised myself that I wouldn't forget to mention Pete Weiss. Thanks for keeping me on my toes, Pete! Another invaluable source of information was list owner discussion lists. Heavy use was made of the archives from LSTOWNL@SEARN in particular. Thanks to the subscribers there who probably know LISTSERV better than anyone alive, aside from Eric. Thanks also to Susan Lowell, Elena Nolen and Jim Jones of LSoft for reading and making valuable comments on several drafts. ©Nathan Brindle (nathan@lsoft.com) %Body Text Left%Body SubHead#I2PQP#   Revisions:  #Body SubHead#Body Text Left#I2PQP#4 <DL!4 <DL!950620001Added NewList=  keyword to Appendix C 950620002Documented DIGESTH and INDEXH 950808001Expanded Section 6.6 to explain the Editor,Hold confirmation procedure 950808002Added Section 2.10 to document list security options and the OK validation procedure 950808003Reconciled TOC to actual contents 950808004Updated Appendix C, Send=  950808005Updated Appendix C, Editor=