Listserv List Owner's Survival Guide Copyright TERENA 1995 Version 1, April 1995 This guide was written by staff members of TERENA (formed by the merger of EARN and RARE), and is part of the series of documentation on Revised Listserv which was originally undertaken by the EARN Association. The List Owner's Survival Guide is a short document but it contains the most important information that list owners need to know. It is not however a comprehensive manual and does not cover all details of owning a Listserv list. The List Owner's Survival Guide is based on the original documentation for Revised Listserv which was written by Eric Thomas, and on Eric's release notes for later versions. The commands and keywords are correct for Listserv version 1.8a. This guide has been checked with the NJE version of Revised Listserv for VM, but it should be accurate and suitable for use with other versions of Listserv as well. Table of Contents Chapter 1 - Introduction and background 1.1 Introduction 1.2 History and background Chapter 2 - Overview 2.1 Starting a Listserv list 2.2 Maintaining a list Chapter 3 - Commands for List Owners 3.1 Commands for list membership functions 3.2 Commands for list maintenance functions Chapter 4 - The List Header File 4.1 The List Header File 4.2 The list header keywords 4.3 List name and address keywords 4.4 List membership keywords 4.5 List traffic keywords 4.6 List management keywords 4.7 List mail headers and body keywords 4.8 Other keywords Chapter 5 - Annotated examples of list headers 5.1 Open international list 5.2 International peered list 5.3 International professional list 5.4 Private organisation's list 5.5 List on non-VM, non-NJE server Chapter 6 - Other sources of information 6.1 Listserv lists 6.2 Basic Listserv documentation set 6.3 Listserv Release Notes 6.4 Listserv documentation from the EARN Association 6.5 Other documentation files 6.6 Usenet newsgroups Chapter 1 - Introduction and background 1.1 Introduction All Listserv lists have at least one owner, who has various responsibilities towards the list and its users. The owner is usually the person who wanted to start the list in the first place. All Listserv servers have a maintainer, and he or she must decide whether or not new lists can be accommodated on their server. A list owner's first job is to persuade a Listserv maintainer to set up the list on their Listserv server, and to undertake to maintain it there. Server maintainers are responsible for the smooth running of the Listserv software, and take care of any hardware decisions to do with the list. The maintainer creates a list header file for each new list, which the listowner can configure. Each list owner is expected to keep a close eye on the mail distributed to list members, even if the list membership is not restricted. The owner must sort out any problems which may arise, such as loops, or unsuitable messages, and may need to referee arguments and call a halt to slanging matches! Some list owners choose to vet all mail which is sent to a list, before allowing it to be distributed to list members. If list membership is restricted, the list owner must vet all subscription applications and respond to them within a reasonable time. Lists which have a large membership can be divided into two or more smaller lists, to be stored on two or more servers. These new smaller lists are called peered lists; they have the same name and distribute the same messages, but each server stores a different set of members. Mail sent to a peered list is automatically distributed to the membership list of each of its peers. When a list starts to get large, it is up to the listowner to look for another Listserv server whose maintainer is willing to host a peered list, and then to move some users from the present list to the new peer. Listowners must decide whether the list's messages will be archived on a daily, weekly or monthly basis, or perhaps not at all. Listserv will create a filelist based on the archive's contents, and will send it to users in response to requests. Other files can be stored on the filelist, and further filelists can be created. Chapter 2 of this guide describes in more detail how to set up a new list and the tasks involved in maintaining it. Commands are provided to help you carry out these tasks, and they are described in Chapter 3. The start of the list header file is used to specify various aspects of the list's operation, using keywords; the keywords and their values are described in Chapter 4. Examples of header files from different types of list are given in Chapter 5. Additional sources of information on Listserv are given in Chapter 6. 1.2 History and background Listserv was devised by the Bitnet Information Centre (BITNIC). Originally there was only one server, which managed all the mailing lists. Each list addressed a specific subject area and had an independent set of list members. For example, para-psychologists who were interested in the topic of near-death-experiences could establish their own mailing list. Users from across the network who wished to subscribe to this list could then do so by having their e-mail address added to it. The Listserv server would subsequently distribute a copy of any e-mail sent to this list to each of the list members. The Listserv concept was later adopted and modified by Eric Thomas, who produced a new version of the server - Revised Listserv - which included many new and powerful features. A fundamental improvement was that instead of one centralized Listserv server controlling all the mailing lists, Revised Listserv is based on many Listserv servers across the network, each managing their own, independent set of lists. There is a high degree of inter-server cooperation, so the benefits of a centralized service are retained, while the efficiency and robustness of the service are improved. Each mailing list is managed by one out of a number of different servers, each server located at a different computer site. However, global commands sent to one server are automatically propagated to all the other Listserv servers on the network - for example, a global sign-me-off-all-lists command will operate on all the lists on the network. Revised Listserv also introduced peered lists, which are created when the membership of a large mailing list is divided between one or more Listserv servers. Mail sent to a peered list is automatically distributed to the membership list of each of its peers. The decentralized topology of Revised Listserv resulted in the development of powerful mail distribution algorithms which significantly reduced the overall electronic mail traffic load on the EARN/BITNET network, providing a fast and efficient service to all Listserv users. All requests for subscription to or removal from mailing lists stored on the original Listserv server had to be processed by the Listserv administrator. As the popularity of the server increased, this inevitably led to delays. Another major enhancement was the addition of a command processor so that commands could be sent directly to any Listserv server, which could process them without the intervention of a human administrator. This not only reduced the administrative overhead of the server but also ensured that the members of each list were an up-to-date and interested audience. Revised Listserv also introduced a database for each mailing list, called a notebook database or list archive. This can hold a copy of every mail message distributed on a mailing list, so that users can search for and retrieve old mail messages. Revised Listserv servers can also be used as file servers, to store files which are not connected with any individual mail list. The server can be used as a central file repository which can be interrogated and can respond to retrieval requests from any user. Listserv users can also subscribe to files, so that they will be informed of file updates or will automatically receive an updated copy of a file. Another function added to Listserv was that of a network information server. Information available on each server includes details of individual EARN/BITNET computer sites, and of the overall configuration of the network. Chapter 2 - Overview This chapter gives an overview of the tasks involved in starting up a Listserv list, and in maintaining a list. 2.1 Starting a Listserv list Does a list exist already? A Listserv list called New-List, at vm1.nodak.edu (NDSUVM1.BITNET), contains announcements about lists which are maintained on all the major list management packages. This is a good place to look to find out whether there is already a list dealing with a specific subject, and to find a Listserv node willing to open a new list. You should also get the file LISTSOFLISTS, available from listserv@vm1.nodak.edu, for information on getting listings of discussion lists on the net. Which mailing list management software to use This is usually the decision of the site at which the list will be managed. For a discussion of the various possibilities, see the mailing list management FAQ mentioned in Chapter 6. This guide describes Revised Listserv. Find a host Listserv You need to find a host Listserv computer which will store and operate your new list. It is very important that your email connection to the host is quick and reliable, and that you and any other list owner(s) have the cooperation of the Listserv postmaster, who will have several tasks to carry out connected with your new list. Most sites have one main postmaster and others who are also given postmaster rights so that they can deal with problems when the main postmaster is not available. In addition to the original version of Listserv for sites with NJE connectivity, there is also a version of Listserv for sites with TCP/IP connectivity only. A list of all the nodes running Listserv NJE can be obtained by sending the following command to any Listserv: GET PEERS NAMES For a list of all nodes running Listserv TCP/IP send the command: GET INTPEERS NAMES You will receive files containing vital information about all the Listserv host computers, including the institution which operates each one, its location, and the name and electronic mail address of its postmaster. You can use this information to select a suitable Listserv server, and then contact its maintainer to ask whether that site is willing to accept your proposed list. You can also send a note to the NEW-LIST and LSTSRV-L mailing lists (see Chapter 6) asking what site is willing to host your list. A number of companies are also willing, for a fee, to set up mailing lists and even to manage lists. Establish the new list A few actions must be performed at the Listserv site, by the Listserv maintainer or other authorised personnel, to establish the list and to allow it to receive and distribute mail. 1. A list header file for the new list must be installed in Listserv. 2. Some steps must be taken to ensure that mail which arrives for the list will be correctly processed. In VM, a "dummy" account (i.e. an account with no resources assigned to it) should be opened for the list. When mail arrives addressed to this account, Listserv grabs it for further processing. IBM VM/CMS user names can be no more than 8 characters, hence in VM each list must have a short name of 8 characters or less. In addition, a longer name (up to 32 characters) can be given to the list using the List-id keyword (see Chapter 4). Publicise the new list The success of any list depends on its membership, so one of the owner's first jobs is to ensure that potential members are made aware of the list's existence. The best place to advertise the establishment of a new list is through existing related lists, but you should also make use of any other sources of information for the target community. Introductory letter Listserv sends an introductory letter to each new member joining a list. By default this will be a general letter containing administrative information about the list; it is up to the list owner to write something more informative if this is appropriate. Since this letter is sent to people who have already joined the list, it should not include instructions on subscribing. The owner can use it to lay down the ground rules for list correspondence, and to set the proper tone for discussions. The introductory letter for the list should be sent to the postmaster, who will put it on the server as a file called `listname MAILTPL'. Any owner can also set up a `Welcome' letter to be distributed to new list members in addition to the introductory letter. 2.2 Maintaining a list The list header file All the information specific to a Listserv list is stored in a header file, which Listserv consults when processing mail addressed to a list. The header file contains the list's name, a description of the list, various configuration settings, a list of members' names and addresses, and other status information for individual list members. Here is a sample header file: * Official List Title * * List-id= long-list-name * Review= Public * Subscription= Open * Send= Editor * Reply-to= Sender,Respect * Confidential= Service * Service= NOD*,*.sub.do.main * Editor= USERID@some.domain.name * Notebook= Yes,A,Monthly,Public * Errors-To= Owner * Password= not2reveal * Owner= own1@NODE (First Owner's Name) * Owner= own2@COMP.UNI.DOMAIN (Second Owner's Name) * * This is the place to put a lengthy description of the list and * its activities, so that anyone using the REVIEW command will be * able to decide if this list is worth joining. * MEMBER1@ANODE Member1's Name MEMBER2@BNODE Member2's Name All lines before the list member names and addresses must begin with an asterisk (*). More than one parameter may be listed on the same line. Keyword parameters which are not given values in the header file will take default values. This sample does not contain all the available keywords and parameters. A complete list of these, with their default values and other possible values, is given in Chapter 4. Several examples of list headers are given in Chapter 5. Some comments on the header file settings Some keywords affect the information that Listserv gives about the list, some affect the audience and level of participation in a list, some affect the distribution of list traffic, and some determine the rights and responsibilities connected to the list. New list owners must change some of these values, and should be aware of the existence of the others, and be aware that they can change them if necessary. Changing header file settings The keywords and their parameters at the head of the header file can be changed by the list owner, or by the postmaster, using any standard text editor. Caution should be exercised in editing the name and address information in the list header file because Listserv stores status information about each user in the rightmost columns of each name and address line. The command to obtain a copy of the header file is GET, and the command to return it is PUT. These commands are described in Chapter 3. The list owner will probably want to change the following settings: The list title Listserv assumes that the first non-blank character line contains the official title of the list. This is the name which will appear, together with the list's electronic mail address, on all mail which LISTSERV distributes for the list and in all LISTSERV lists of lists. The title should be informative, but short enough to fit on the same line in the mail header as the network address. For example, if this were the header file for list NAV-L at vm.earn.net and the official title was "Interest Group in Omphaloskepsis", then all mail dis would contain the header line: Sender: Interest Group in Omphaloskepsis Information about the list When a user sends a Review command, Listserv returns a message containing all the 'asterisk' lines from the list's header file. It also checks the Review parameter to see if the list of members should also be sent. The Confidential parameter determines whether the list will appear in Listserv's list of lists. In the above header file example, the list will be visible only to users within the list's service area, in this case any computer in Bitnet whose node name begins with "NOD" (e.g. NODEVM) or any computer in the domain ".sub.do.main" (e.g. vms.sub.do.main). Should the list have a password? A password for the list is optional, but recommended. Make sure fellow owners know it. Should subscription be automatic? Many lists do not limit subscriptions, and new users can join them without the intervention of the list owner. On the other hand, a list owner might want to limit, filter, or even prohibit subscriptions to a particular list. This is done using the Subscription keyword. Who can mail to the list? The list owner must also specify criteria which Listserv will use to process incoming mail. The Send parameter determines whether all mail sent to the list will be forwarded to a list editor, and is also used to specify who can send mail to the list. Permission to mail to the list can be given to an individual, a group, users from a specified group of computers, or everybody. What "Reply-to:" address should be used? Mail systems derive a return address from either the "From: ", "Sender: ", or "Reply-to: " fields in the incoming message; most mail systems will use the "Reply-to: " field if it exists (this is the correct behaviour according to the standards). Listserv's Reply-To parameter indicates whether this field should contain the address of the list or the address of the original sender, and whether to respect any "Reply-to: " line in the original sender's message, or to replace it. Should messages be archived? The Notebook parameter determines whether messages will be stored in an archive, and where in the Listserv host's disk space the archive will be stored. It also indicates whether new archive files should be opened on a yearly, monthly, weekly, or daily basis, or in a separate file for each transmission. Archived messages can be retrieved by users, and the archives can be searched using Listserv's database facility. Who should get error messages? Inevitably, some list messages for some list members will not reach their destination, because the member's computer account is closed or the computer is removed from the network or the mail system is configured incorrectly or countless other problems, some temporary, some permanent. When this happens an error message is usually sent back to the list. Listserv employs various methods to identify these error messages so that they won't be distributed to all list members. It is usually the responsibility of the list owner to receive these error messages and take action (delete the member from the list, change appropriate members' settings to Nomail, or wait for further developments). Chapter 3 - Commands for List Owners This chapter describes the Listserv commands which are available for use by list owners. The commands are presented in two groups: those covering list membership functions and those covering list maintenance functions. Upper case letters are used in command descriptions to indicate valid abbreviations of the command names. 3.1 Commands for list membership functions These commands enable owners to manage the membership of their lists: add members, remove them, view and change members' personal list options, and move members between peer lists. ------------------------------------------------------------------------ ADD Add a user to one of your lists or to a peer ADDHere Add a user to one of your lists, but not to a peer EXPLODE Optimize the placement of members among peers MOVE Move members from one peer to another Query ... FOR ... View the settings of a list member SET ... FOR ... Change the settings of a list member QUIET Don't send notification to command target ------------------------------------------------------------------------ ADD listname userid@node Add a user to one of your lists. The list password need only be specified if the list is protected by the "Validate= Yes" keyword, and the command is issued from a remote node. The user will automatically receive notification unless you use the QUIET command prefix. The user's full name need not be given if the user is already known to your Listserv server. If the address specified is already subscribed to the list, the full name specified will replace any previous full name associated with that address. Listserv will automatically check that there is no closer peer list for the user. If there is one, the command will be automatically forwarded to that server. You can use the ADDHERE command to override this automatic command forwarding. The "DD=ddname" syntax provides an efficient method of adding many new users to your list at once. "ddname" is the name of a list which should contain one "userid@node " per line. ADDHere listname userid@node This command is the same as the ADD command, except that Listserv will not check to see if there is a closer peer list. DELete listname userid@node <(options> Remove a user from one of your lists. The user will automatically receive notification unless you use the QUIET command prefix. The wildcard '*' can be used to delete several members at once. The list password need only be specified if the list is protected by the "Validate= Yes" keyword, and the command is issued from a remote node. The options are: GLobal forward the delete request to all peers LOCal don't forward to peers TEST don't actually delete, just report what the results of the command would be; this is useful when using wildcards EXPLODE listname <(options> Analyse the optimal placement of list members among the various peers of a particular list. This command can only be used for lists which have the "Peers=" keyword defined in the list header (see Chapter 4). The "With" option can be used to include in the analysis nodes which do not at present host peered lists. Listserv will create a commands-job file containing the necessary MOVE command (see below) to transfer all users for whom a better peer has been found. This file will then be sent to you so that you can look at it before sending it back to Listserv for execution. The file will be sent by email to non-NJE addresses, so there is usually no need to use the "F=" parameter to specify the format in which the file will be sent. An explanation of the possible values for this parameter is given in the EARN Listserv Users Guide. The options are: BESTpeers n suggest the N best possible peers to add Detailed provide a more detailed analysis FOR node perform analysis from viewpoint of 'node' PREFer node peer to prefer in case of equidistant peers SERVice check that service areas of peers are respected With(node1 >>) assume that specified nodes are peers WITHOut(node1 >>) assume that specified nodes are not peers MOVE listname user node DD=ddname Move users from one peer server to another. The user will automatically receive notification unless you use the QUIET command prefix. The complete user entry will be moved including full name and personal list options. If the source and target list names are identical, only the target node need be specified. Otherwise, the full network address of the target list must be given. The source and target lists must have the same password. For security, the MOVE command will only be accepted for lists which have a list password. Query listname FOR user View the personal list options of members of a list you own. The '*' wildcard can be given in the user address to view the settings of several list members, including concealed members (e.g. use *@* to get the personal list options of all members). You can also use this wildcard in the listname to view the personal options of a user (or of several users) on all the lists that you own. SET listname options FOR user Change the personal list options for a member of a list that you own. The user will automatically receive notification unless you use the QUIET command prefix. Wildcards can be given in the user address to change the options of several list members, including concealed members (e.g. use *@* to change an option for all members). You can also use wildcards in the listname to change an option of a user (or users) on all lists that you own. An explanation of the personal list options is given in the EARN Listserv Users Guide. The following option can be set by list owners only: NORENEW waive the need for periodic confirmation of subscription by a member of a list. This exemption can be cancelled using the RENEW option. QUIET command-text Suppress the sending of notification mail to the command target. For example, you can use "QUIET DEL ..." to prevent notification mail from being sent when you remove a list member whose computer account has been closed. 3.2 Commands for list maintenance functions These commands enable owners to manage the list header and the functioning of their lists. ------------------------------------------------------------------------ GET listname Get a copy of the list header file for editing PUT Replace the list header file for your list HOLD Prevent postings to a list from being processed FREE Negate HOLD; release postings for processing UNLOCK Unlock a locked list STATs ... RESET Reset the statistics on list traffic ------------------------------------------------------------------------ GET listname <(options> After using a GET command, you will be sent a copy of the list header, which you can then edit, and the file on the server will be locked so that no changes can be made to it until it is unlocked again. With the list locked, you need not fear that another list owner or postmaster will modify the header at the same time as you do, thus cancelling your changes, nor that users will join or leave the list or change their personal list options during this time; any such changes would be negated when you put your copy of the list header back. You will be sent the raw, unformatted list header file which you can edit using a text editor. You can change users' name or address information, but you must be careful not to alter the contents of columns 81-100 of the file where the personal list options are stored. The file will be sent by email to non-NJE addresses, so there is usually no need to use the "F=" parameter to specify the format in which the file will be sent. An explanation of the possible values for this parameter can be found in the EARN Listserv Users Guide. If the list is protected by a password (Chapter 4 includes an explanation of the "PW=" keyword), you must use the PW= parameter in your GET command. The options are: GLobal Forward the GET request to all peers. HEADer Send just the header, i.e. the lines beginning with an asterisk (*) and not the names and addresses of the members. There are several advantages to this: the file sent will be small; you will not ruin the information in columns 81- 100 of the lines with names and addresses; when the list header is put back it will be processed faster. NOLock Do not lock the list - useful if you do not intend to make changes to the list. OLD Get the previous copy of the list (which is kept by Listserv for backup). PUT listname Replace the information in the list header file. The PUT command must be the first line of the mail message body or file which contains the header file on its way back to Listserv. The password of the list can be changed by adding a "PW= newpassword" keyword in the list header. If this keyword is not present, the old password will be retained. The names and addresses held in the header file will be automatically re-formatted and sorted by node, so you do not have to worry about inserting new names in the right order and at the right column. Listserv will check the validity of the keyword values before replacing the old version of the list header. If more than one "PW=" keyword is found, or if a user is found to be subscribed twice to the list, the PUT operation will be rejected and the old list will be retained. If this happens, an email message is sent to the list owner explaining that the PUT command has been rejected. HOLD listname <(GLobal> Suspend distribution of messages sent to the list. A note is sent to the sender indicating that the message is being held. Held messages are released and distributed to list members when a FREE command is received (see below). The GLobal option causes the HOLD command to be forwarded to all peer servers. FREE listname <(GLobal> Release all messages held as a result of a previous HOLD command (see above). The GLobal option causes the FREE command to be forwarded to all peer servers. STats listname (RESET Reset the statistics on list traffic. This command is automatically forwarded to all peer servers, unless the LOCal option is used. UNLOCK listname Unlocks a list; useful if a list has been inadvertently left locked. A successful PUT command automatically unlocks the list, so the UNLOCK command is not normally needed. This command should be used only after having checked with all the list owners and postmasters that no modification is pending. Chapter 4 - The List Header File 4.1 The List Header File The names and addresses of a Listserv list's members are stored in a file, which is stored on a Listserv server. This file also contains list configuration information. The configuration information is given at the start of the list header file, on lines which must start with an asterisk. The first line must hold the list's official title, and succeeding lines hold list keywords (usually referred to as list header keywords) and their values. Any words followed by an equals sign (=) are assumed to be keywords. When all the keywords have been specified, it is usual for the next few lines to contain a description of the list. The rest of the file consists of name and address information for each member of the list. These are given in the first 80 columns of lines which do not start with asterisks. Listserv stores information about each member's options and status on the same lines as the name and address information, but to the right of column 80. 4.2 The list header keywords The list header keywords and the possible values their parameters can take are described below; default values are given at the start of each description. Some parameters are used by several keywords, so the values these parameters can take are described first. Where a parameter value needs to be provided by the list owner, the parameter is shown in uppercase. 4.2.1 Parameters used by several keywords INTERNET-ADDRESS: An RFC822-compatible network address, usually of form "userid@node.domain". Listserv puts addresses into uppercase unless they are enclosed in double quotes. ACCESS-LEVEL: Defines which users can access the information or service to which this parameter applies. Possible values are: Public Anybody Maintainer Only the Listserv maintainer The following values for ACCESS-LEVEL can be used together; they must be separated by commas. Private Members of the current list (LISTNAME) Members of the named list Owner Owner of the current list Owner(LIST) Owner of the named list Service Members of the current list's service area Service(LIST) Members of the service area of the named list 4.2.2 The keyword descriptions Some keywords can take several parameters, and the parameters available are shown separated by a comma in the descriptions below. Alternative values for the same parameter are shown separated by a logical OR sign (|). Some parameters have parameters of their own. Alternative values for these parameters are shown separated by a semicolon in the descriptions below. Where a parameter's value needs to be specified by the listowner, the parameter is given in uppercase. In the list header file, commas are used to separate parameters. More than one keyword and its values can be given on the same line of the list header file, leaving one or more spaces between keywords. One or more spaces are allowed after the equals sign (=) when specifying keywords. 4.3 List name and address keywords 4.3.1 List-ID= LISTNAME Defines an alias for the list; this is useful if a list is renamed, or if two lists are merged. Can be used to define an alternative name for the list, usually a longer name than the default. This is useful for VM systems where listnames are otherwise restricted to 8 characters. A longer name is more informative, and can also be useful for peered lists. The maximum length for a list-id is 32 characters. Users can use the alias, or long name, as well as the usual short one in commands such as Subscribe, Review, etc. If the listowner has set up the List-Address keyword (see below), the alias or long name will appear in mail distributed to list members. 4.3.2 List-Address= Listname|List-id, nje|fqdn|DOMAIN-NAME This keyword is used most often with NJE/VM hosts. It specifies which list name and address information Listserv presents when the list address appears in the "From:", "Sender:" or "Reply-to:" fields of messages delivered to the list. "Listname" is the same as the name of the list header file, which is limited in VM systems to 8 characters. "List-id" is set by the "List-id=" keyword, so may not be available; if it is not, Listname will be used. The words "List-id" or "Listname" are used, the actual name of the list itself is not given here. The second parameter specifies the particular host that you want Listserv to use. The NJE option causes Listserv to use the NJE nodename, and the FQDN option causes Listserv to use the Internet address of the Listserv host. You can also type in a specific domain name, which can be useful if the machine on which Listserv is running is known by several names. You only need to specify the part of the keyword which you want to change. For example, to change the hostname, you can enter "List-Address= XYZ.EDU" in the list header; the list name will be taken from the value in the LOCAL SYSVARS file which is maintained by the installation's Listserv maintainer. To change the list name only, you can write, for example, "List- Address= List-id". If you are specifying both parameters, you can use the "@" sign as usual, but if you leave it out, Listserv will supply it for you. Here are a few examples: "List-Address= fqdn" announces the list under the Internet address for the Listserv host. This setting has no effect for Bitnet-only sites. "List-Address= List-ID@fqdn" uses the long list name and the Internet hostname. "List-Address= Listname@xyz.edu" uses the default list name and the hostname xyz.edu. 4.3.3 Confidential= No|Yes|Service Indicates whether the list will be included in the output of a "List" command. The default value is "No". "Service" indicates that the list is visible only to users in the list's service area (as specified by the "Service=" keyword). "Yes" means that the list never appears in the "List" command output. 4.4 List membership keywords 4.4.1 Subscription= By_owner|Open|Open, Confirm |Closed Defines whether subscription requests are automatically accepted, and if not, whether they are forwarded to the list owner. By_owner Subscription requests are forwarded to the list owner. This is the default. Open Subscription requests are accepted automatically Open,Confirm Subscription requests are accepted, but a request for confirmation is sent to the user, who must reply before being added to the list. This confirms the validity of the user's address details. Closed Subscription requests are rejected. 4.4.2 Confirm-Delay= HH Defines the number of hours Listserv will wait after sending out a confirmation message to a user who wishes to be subscribed. The default is 48 hours. If the user fails to respond within this time, the subscription request will lapse. This keyword is effective only if the Subscription keyword is set to "Subscription= Open, Confirm". 4.4.3 Renewal= None|Monthly;Yearly;Weekly;yy/mm/dd, Delay(n) Defines the interval at which subscribers to the list will be asked to confirm that they still want to be in the list. The default is None. If enabled, Listserv will ask list members to confirm their subscription at the stated intervals. The interval can be specified in two ways: 1) As "Monthly", "Yearly" or "Weekly", optionally preceded by a number by which to multiply the time unit. Thus, "6-Monthly" indicates an interval of 6 months. The number must be followed by a dash. 2) A date in the form yy/mm/dd, mm/dd or just dd. The first form specifies year yy, month mm and day dd, the second means "every year on month mm, day dd", and the last one means "every month on day dd". The second form is useful, for example if you know when your students' accounts are going to expire. "Delay(n)" defines the minimum delay in days between the time the user is asked to confirm his subscription and the time he is automatically removed from the list. The actual delay might be more than this number, but not less. The default is one week (7 days). 4.4.4 Review= ACCESS-LEVEL Specifies the category of users who are allowed to review the network addresses and names of list members. The default value is "Public". A description of ACCESS-LEVEL is given in the section "Parameters used by more than one keyword" above. 4.5 List traffic keywords 4.5.1 Send= ACCESS-LEVEL|Editor| Editor,Semi-moderated Defines who can send mail or files to the list. Can be used to put the list under control of an editor, after which any file or piece of mail sent to the list will be forwarded to the editor, and only the editor and the list owner will be able to distribute mail or files to list members. The default value is "Public". The network address of the editor is defined by the "Editor=" keyword (see 4.6.2). A description of ACCESS-LEVEL is given in the section "Parameters used by more than one keyword" above. A semi-moderated list will treated messages in two different ways, depending on the contents of the "Subject:" field of the message. If the subject starts with "Urgent:" (case is ignored), the list is treated as a non-moderated one and the message will not be forwarded to the editor for processing. Messages with a subject beginning with "Re: Urgent:" are treated the same as "Urgent:", so that replies to urgent letters are by default considered urgent. Messages with any other subject are forwarded to the editor. 4.5.2 Ack= Yes|Msg|No|None Listserv normally sends an acknowledgement to the originator of each incoming message, confirming that the message has been distributed to list members. Some CPU and other technical statistics are usually included. This keyword defines how the acknowledgement will be sent, and if statistics will be included in it. It sets the value of the "Ack/Noack" distribution option which will be assigned to new list members. The value can be altered later by individual list members, using the "SET" command, but not by non-members of the list. This means that this option will always be in effect when distributing mail from people who are not on the distribution list. Yes Acknowledgement is via email, including statistics. Msg Acknowledgement is via NJE message, only received by Bitnet users, and statistics are included. No Acknowledgement is via NJE message, only received by Bitnet users, and statistics are not included. None No acknowledgement at all. Useful for archive-only lists. 4.5.3 Files= Yes|No This keyword is important only in the VM NJE version of Listserv. It indicates whether or not files can be sent to the list (using NJE SENDFILE). The default value is "Yes". If files are sent to a list, Listserv will make a "best guess" about which form of encoding to use for files from non-NJE users, and this encoding may not always be desirable. Also, some VM worm programs have used lists to propagate themselves. For these reasons, it is advisable to set Files=No for most lists. 4.5.4 Daily-Threshold= NUMBER Defines the maximum number of messages that a list will process per day. Upon reaching this limit, the remaining messages will be held until the next day. Default is 50 messages per day. 4.5.5 Prime= Yes|No|"PRIMESPEC" Defines whether the list will distribute mail and files to the list members during certain peak periods. The default is "Yes", which allows a list to operate during prime time as it is defined in the site's Listserv server. Prime=No may be specified to prevent the list from operating during the installation's Primetime. Finally, "Prime="PRIMESPEC"" (note the double quotes) can be used to enforce a particular "prime time" definition for the list, which will over-ride the installation's Primetime setting. Mail and files received during the list's prime time are held until the end of prime time, without sending any notification to the originator. The value for PRIMESPEC can comprise several DAYSPECs, separated by semicolons. DAYSPEC is specified as: DDD1-DDD2: TIMESPEC1 > where DDD Mon, Tue, etc TIMESPEC HH1:MM1-HH2:MM2 HH:MM hours:minutes on 24 hour clock The special value of "-" for TIMESPEC specifies "never". Examples: "MON-FRI: 09:00-17:00; SAT-SUN: -" (This is the default SYSVAR) "MON-FRI: 08:00-12:00 13:30-18:30; SAT-SUN: 09:00-17:00" 4.5.6 Topics= TOPIC, TOPIC,... Allows the list owner to define up to 11 topics for the list, after which each list member can specify which topics they want to know about. Users who do not specify any topics will continue to receive all messages; users who specify one or more topics will receive only the messages which contain the topic as the first word in the "Subject:" field. The list owner could set "Topics=News,Benchmarks,Meetings,Beta-tests", after which a user could define a personal topics parameter as "Meetings,News" with the command: "SET listname TOPICS: MEETINGS NEWS". Thereafter the user would not receive list mail with a subject line beginning "Benchmarks:" or "Beta-tests:". Topics should never be reordered. If you ever need to delete a topic, leave a blank field where the topic used to be, for example: "Topics=News,,Meetings". Any topic name can be used, except for the words All, None, Other, Others and Re; care should be used with special characters as well. In particular, a topic name may not begin with "+" or "-". 4.5.7 Default-Topics= TOPIC, TOPIC,... Specifies the initial topics for new subscribers. Default is all topics. 4.5.8 Digest= No|Yes, FM, Daily|Weekly|Monthly, WHEN, Size(N) The number of messages handled each day varies greatly between lists. If the number is large, the Digest= keyword can be used to enable listowners and users to receive one large file containing all the messages for a specified time period. Once Digest has been enabled by the listowner, users may select it via the Set command. The default is "Yes" if the list is archived, and "No" if the list is not archived. If the value is "No", the other parameters are not used, so they need not be specified. The second parameter specifies a disk or directory where the digest will be stored, such as "Same" to indicate the same location as the list archives. The third parameter indicates how often the digest is sent out; the default is "Daily", other values are "Weekly" or "Monthly". The fourth parameter, WHEN, is optional, and defines the time when the digest is to be distributed. For daily digests, specify "HH:MM" or just "HH" in the 00-23 scale. For weekly digests, specify a weekday, such as "Tuesday". For monthly digests, specify a number from 1 to 31. The last parameter specifies the maximum size, in lines, the digest is allowed to reach. Once a digest reaches that size, it will be sent out even if it is before the specified time, and another digest will be started. 4.5.9 Stats= Normal|None, ACCESS-LEVEL Indicates what statistics are to be maintained for the list, and who is able to retrieve the statistics reports. The default value is "Normal,Private". Normal statistics include number of mailings and other information for each user who has sent mail or files to the list. 4.5.10 Mail-Via= Distribute|Direct|Dist2 Determines how the list messages should be distributed. Default is "Distribute". "Direct" specifies that all recipients will be handled directly from this Listserv. "Distribute" and "Dist2" are now equivalent. 4.5.11 Internet-Via= DOMAIN-NAME Defines which Internet gateway address should be used when delivering the messages to Internet users. If omitted, the path used is the one calculated by the server to be the "best" for each Internet recipient. 4.5.12 NJE-Via= NJE-NODE Defines the NJE node to be used as a gateway for the list messages. This and the "Internet-Via=" keyword are relevant only for the NJE version of Listserv. 4.6 List management keywords 4.6.1 Owner= INTERNET-ADDRESS|ACCESS-LEVEL,... Defines the person or list of people who "own" the list. List owners control access to the list and define the list control keywords. This keyword should always appear in the list header. The default value is a list of the userids of the maintainers. Most combinations of explicit network addresses and complex access-levels are acceptable, but some access-level keywords such as "Public" are not meaningful. For example: Owner= Big@Blue,(Staff-L),Owner(Main-L). An interesting application of this keyword is to create a STAFF-L list containing the userids of all the local Listserv staff members, and set the "Owner=" keyword of all local lists to "Owner= (STAFF-L)". Thereafter, when there is a change in the local LISTSERV management it is not necessary to modify the headers of all the local lists - just modify the Staff-L list. 4.6.2 Editor= INTERNET-ADDRESS, INTERNET-ADDRESS,... Defines the list editor or editors. The "Send= Editor" option will cause all mail sent to the list to be automatically forwarded to the first person listed in the "Editor=" keyword, who will then decide whether to send it back to the list. Only the editors and list owners will be allowed to mail directly to the list. Any editor will be able to send mail to the list, but only the first one will receive copies of mail sent to the list. The file will be forwarded to the editor "as is", without being included in a mail envelope. This ensures that the "To:" keyword and any fields such as "Resent-From:", "Resent-To:" or "Resent- Date:" are preserved. The editor must be a human person, not a file server, list server, mailer, or the like. Specifying a program's mailbox as "Editor=" could result in a mailing loop. 4.6.3 Errors-To= INTERNET-ADDRESS|ACCESS-LEVEL,... Defines the person or list of people who will receive rejection mail for the list. The default value is "Owners". It may be desirable for the owners to change this to "Owners,Maintainer". Most combinations of explicit network addresses and complex access-levels are acceptable, but some access-level keywords such as "Public" are not meaningful. 4.6.4 Loopcheck= None|Full|Noorigin|Nobody|Nocrc Defines the behaviour of the loop checking mechanism of LISTSERV. None disables loop checking. Full enables complete loop checking. Noorigin disables checking on the "known mailer origins" such as MAILER, POSTMASTER, etc. Nobody disables checking for blank messages. Nocrc disables cyclic redundancy check. The default is Full. Changes to this default may make the list vulnerable to mailing loops with remote mailers. 4.6.5 Peers= PEER, PEER,... Specifies a global list of the node-id or network addresses of all the servers in the world which are peer-linked 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, it will automatically be forwarded to the nearest server holding a peer list, even if this is not the Listserv which was specified by the user. If the name of the peer list is the same as the name of the local list (which is usually the case), only the node name is needed. If the list names are different, the full list network address is needed, e.g. "REXX-L@UIUCVMD". 4.6.6 Service= AREA, AREA,... Defines the "service area" beyond which subscription requests must not be accepted. When a Subscribe command is received, the "Peers=" keyword is checked to see if there is a nearer peer list in the network (the "best placement" check). If so, the command is forwarded to that server. If not, the service area is checked and if the recipient is not within it, the subscription request is denied. When the Subscribe command is forwarded, the destination server could itself deny access to the list if the subscriber is outside its service area. The result of this is that users may sometimes be unable to join a list, if they are outside the designated geographical area of all the peers. The service area check is made after the "best placement" check, to allow several servers in the same country to share an identical service area, e.g. "Service= Germany", within which users will be subscribed to the nearest server. AREA can be a node or list of nodes; possible values are: - a network, e.g. EARN, Bitnet - a country, e.g. Germany, Canada - "Local", in which case it takes the value of the "Local=" keyword - a node, e.g. EARNCC - a simple wildcard nodename pattern such as FR*, *.AC.AT, *ESA*, etc. 4.6.7 Local= NODE, NODE,... Defines the "local nodes" for both service area checking and mail header grouping. The "real" local node is automatically considered as a "local node" and does not have to appear in the list. Non-local list members receive "grouped" mail if there is more than one member in their node, but local members receive separate pieces of mail with a single recipient in the "To:" field. NODE means "anything after the "at" sign (@) in the network address". For instance, "GUMNCC" and "gumncc.earn.net" are both valid node names. This keyword is now used only for service area checking. 4.6.8 Auto-Delete= No|Yes, Semi-Auto|Full-Auto Defines whether Listserv will attempt to remove users by analysing rejection messages from mailers. Rejection messages from LMAIL, MX and PMDF are currently supported. Default is "Yes". 4.6.9 Notify= Yes|No Defines whether the list owner will receive notification of new subscriptions, deletions and any option changes made by list members. The default is "Yes". 4.6.10 Validate= No|Yes, Confirm, NoPW Allows security verification to be performed on "sensitive" commands. When set to "No", all commands except Put are accepted with no validation, which leaves the list unprotected against hackers. For compatibility reasons, this is the default. When set to "Yes", sensitive commands such as Delete or Add require password validation. Both personal and list passwords are accepted for list owner commands, some user commands may accept a personal password, but other user commands will be forwarded to the list owners for verification. When "Yes,Confirm" is specified, sensitive commands are by default validated by sending a message to the user requesting confirmation before the command is carried out (the "OK" mechanism). Passwords are also accepted where appropriate. When "Yes,Confirm,NoPW" is specified, protected commands must be validated using the "OK" confirmation mechanism, and passwords are not accepted. This is the recommended setting for secure lists. 4.6.11 PW= PASSWORD Defines a password which the list owner will need to give before using sensitive commands. This parameter is optional, but its usage is strongly recommended as a means of improving list security. The line containing this keyword is removed from the copy of the list generated by the Get command, so as not to reveal the password. A new password can be created by including it in a new version of this line, adding it back to the file before using the Put command. The old password will be retained if this line is omitted. See the Validate= keyword (4.6.10) for more information. 4.6.12 Default-Options= OPTION, OPTION,... Defines the Set command options which will be used as defaults for new members to the list. For example, "Default-Options=FullHDR" will cause all new members to receive list messages with full headers. The Set command is described in the Listserv Users Guide. 4.6.13 Filter= Also|Only|Safe, INTERNET-ADDRESS, INTERNET-ADDRESS,... Any postings, including subscription requests, will be rejected if the From: field matches any of the patterns in the Filter= keyword. Wildcards are allowed, for example X400MAIL@* or *@*.XYZ.EDU. The default value is no filter. If "Also" is specified, the filter is used in addition to the standard Listserv filter as specified in the LOCAL SYSVARS file of the site. The Listserv filter is contained in the code and updated regularly. If "Only" is used, the addresses you specify are the only ones tested by Listserv. Lists with the keyword value "Safe= Yes" (4.7.4) normally require only minimal filtering. If "Safe" is used, then these safe lists will also use strict filtering. 4.7 List mail headers and body keywords 4.7.1 Reply-to= DESTINATION, Respect|Ignore Indicates whether the sender's "Reply-to:" tag file is to be preserved or discarded, and gives the content of a new "Reply-to:" field if this is needed. The default value is "List,Respect". DESTINATION Destination of a mail message or reply. Possible destination values are given below: List the list Sender the sender of the original mail message Both both the list and the original sender None no reply message is sent at all "INTERNET-ADDRESS" a network address, enclosed in double quotes. Some mailing systems cannot process a "Reply-To:" field which contains multiple addresses, and may therefore treat the "Reply-to= Both" option as "Reply-to= List". Respect the original "Reply-to:" tag, if any, is kept. Ignore the original "Reply-to:" tag is ignored and discarded. 4.7.2 Sender= INTERNET-ADDRESS1, INTERNET-ADDRESS2 Specifies the address to be used for the Sender: field of outgoing messages. The first address given is used for most messages, and ADDRESS2 is used for the headers of IETF messages. Addresses must be enclosed within double-quotes. 4.7.3 X-Tags= Yes|No|Comment The X-Tags option specifies how Listserv should treat the "X-" fields of mail messages which it receives for distribution. The options are: Yes Leave "X-" fields as RFC822 header fields in the outgoing message. This is the default. Comment Prepend the header field "Comment:" to "X-" fields in the outgoing message. No Remove "X-" fields from the outgoing message. 4.7.4 Safe= Yes|No This keyword is mainly used with VM systems. It specifies whether the BSMTP header of the mail distributed from this list will include "owner-listname". Default is Yes for Netdata- capable mailers. If a site is running XMAILER, this will cause the spool filename to be set to "OWNER-xx MAIL". 4.7.5 Editor-Header= Yes|No Enables/Disables an explanatory mail header which is added to list messages forwarded to the editor, for lists configured with an editor. Default is Yes for lists with an editor. 4.7.6 Sizelim= NUMBER Defines the maximum size (in lines) of postings which will be accepted for processing. Default is the value specified by the "mailmaxl" variable in LOCAL SYSVARS, which has a default of 5000 lines. This and other defaults will be increased in future versions of Listserv. 4.7.7 Translate= Yes|No Listserv normally removes control characters from files which it distributes, but will retain them if this keyword is set to No. The default is Yes. 4.8 Other keywords 4.8.1 Notebook= No|Yes, FM, INTERVAL|Separate, ACCESS-LEVEL Indicates whether an automatic log or "notebook" is to be kept of all mail sent to the list, defines at which interval of time the log file's name must be changed, and specifies who is allowed to retrieve the log file from the server. The default value is "No". If the value is "Yes", then the default filemode (FM) is "A", the default interval is "Single", and the default access-level is "Private". FM This parameter is used in VM only. It specifies the filemode of the disk on which the notebook is to be kept. INTERVAL Possible "Interval" values are given below. The filetype of the "notebook" file for the list is determined by this value; the notebook's filename will always be the same as the list name. Single a single file of filetype "NOTEBOOK" is created. Yearly filetype is "LOGyy" Monthly filetype is "LOGyymm" Weekly filetype is "LOGyymmw" (w in "A"-"E") Separate a separate file is kept for each mail message (e.g. digests). the filetype is "yy-nnnnn" (sequential counter). Notebooks can be retrieved using the GET command, which is described in the Listserv Users Guide. A list of all available notebooks can be obtained using the command: Get Notebook Filelist 4.8.2 Newsgroups= NEWSGROUP|None Defines the RFC822 Newsgroup: header for this list. "None" will remove the header completely. 4.8.3 Language= LANGUAGE Defines the language in which information mail and messages are to be sent to subscribers of the list. The maintainer must first have provided the server with a data file containing messages in a different language. The default language is "English". Information mail is currently available in several languages. 4.8.4 Exit= FILENAME Defines the list exit to be used with this list. The exit name must be defined in the LOCAL SYSVARS file via the variable LIST_EXITS, and the filename must exist on disk. A list exit allows the list owner to customise Listserv's treatment of subscriptions, postings, removals and most other tasks related to this list. 4.8.5 Long-Lines= Yes|No Determines if long lines support is to be enabled or not. This keyword was used for compatibility with Listearn and the intention is to remove it in the near future. Chapter 5 - Annotated examples of list headers This chapter consists of the header files of five lists, with discussions of the keywords and values used in them. The lists were chosen as examples of different list types, and the header files can be used as guidelines for settings that might be used with different kinds of lists. However, the examples should not be copied blindly and used unchanged: every keyword value should be checked to make sure it is appropriate for any new list you may create. 5.1 Open international list Here is an example of a totally open list: anyone anywhere may join and anyone, whether a list member or not, may write to the group. Keywords for CW-EMAIL@GUMNCC.BITNET: * * Campus-Wide Electronic Mail Systems discussion list * * Newsgroups= bit.listserv.cw-email * Ack= Yes * Review= Public * Notebook= Yes,E1/194,Monthly,Private * Send= Public * Reply-to= List,Respect * Subscription= Open,Confirm * Stats= Extended,Private * Formcheck= No * Files= Yes * Validate= Store only * Errors-To= Owners * Confidential= No * Notify= No * X-tags = Yes Mail-Via= DIST2 * Renewal= Yearly Auto-Delete= Yes,Full-Auto * * Owner= TURGUT@TREARN * * The recent developments in computer networking have created the need * for unified E-Mail systems, capable of handling mail-type * communications among users on many different kinds of computers * (mainframes,superminis, personal computers), working for the * same organization. * This communication can be within the organization or directed to * other users on the different networks (BITNET, ARPA Internet, etc.) * * This list strives to provide a forum for developers of such systems. * Topics to be discussed are how to carry out such an effort, * experiences in the implementation, recommended policies, * hardware issues, etc. It is aimed primarily (but not limited * to) developers of university campus-wide e-mail systems, hence * its name. * Comments: There can be more than one keyword per line, and several spaces are allowed between a keyword name and its value. Since this list is open to all, various keyword values are used to reduce the number of bad addresses in the list. First of all, the use of "Subscription= Open,Confirm" ensures that there is two-way communication between Listserv and the user before adding the user to the list. "Renewal= Yearly" will require list members to confirm their list membership at least once a year. "Auto-Delete= Yes,Full-Auto" means that Listserv will automatically delete from the list any address for which it receives an error message with an error code indicating an irreparable problem such as unknown user or unknown host computer name. "Formcheck= " is now obsolete, but it is still found in many old lists like this one. It is ignored by Listserv. "Validate= Store only" is the old form of the current "Validate= No" and has the same effect. 5.2 International peered list Here is one of the peers of a large open international list. Keywords for BITNEWS@DEARN.BITNET: * BITNET News List * * Newsgroups= Bit.Listserv.BitNews * OWNER= QUIET:,RUSHING@BITNIC,CONKLIN@BITNIC,SNODGRAS@BITNIC * OWNER= BITNET@BITNIC * Peers= BITNIC,DEARN,HEARN,MARIST,UGA * X-Tags= Comment Confidential= No * Subscription= Open Send= Owner * Validate= Store Only Notify= No * Ack= No Files= No Stats= Normal,Public * Errors-To= Postmaster Review= Public * Notebook= Yes,B,Monthly,Public * * Owner= LISTMGR@BITNIC,NCC@DEARN,LISTMGT@HEARN,LSVMAINT@UGA * Owner= HARRY@MARIST,QUIET:,HAROLD@UGA * * * BITNEWS is the official medium of the BITNET Network Information * Center for distributing BITNET news and administrative * developments. * * List topology: * * MARIST <----+----> BITNIC <----> DEARN <----> HEARN * UGA <----+ * Comments: In a peered list, all peers must be listed in the "Peers= " keyword, even if they are not directly peered to this server. The list topology diagram of the peers is not used by Listserv, but is very helpful for human readers. The diagram shows us that BITNEWS@DEARN.BITNET is directly peered to BITNEWS@BITNIC.BITNET and BITNEWS@HEARN.BITNET, and so we find the following among the list members: BITNEWS@BITNIC Peer Distribution List BITNEWS@HEARN Peer Distribution List You will notice that there are several owners, at least one from each of the peer server sites. Thus, any owner can make changes in all the peers, if necessary. The use of a list password is highly recommended for peered lists (the listing above was produced with the REView command, and thus the password keyword does not appear.) 5.3 International professional list In many lists an attempt is made to ensure that the list audience and discussion are professional and focused. Keywords for HUMANIST@BROWNVM.BITNET: * * HUMANIST: Humanities Computing * * owner= EDITORS@BROWNVM (Elaine Brennan & Allen Renear) * owner= elaine@netcom.com (Elaine Brennan) * * editor= EDITORS@BROWNVM (Elaine Brennan & Allen Renear) * editor= ALLEN@BROWNVM (Allen Renear) * editor= ELAINE@BROWNVM (Elaine Brennan) * * notebook= yes,k,weekly,public * review= private * send= editor * subscription= by_owner * * ack= no * autodelete= no * confidential= no * editor-header= no * errors-to= owner * files= yes * formcheck= yes * mail-via= dist2 notify= yes * reply-to= sender,respect * renewal= Yearly,Delay(30) * stats= normal,private validate= store only * x-tags= comment * * HUMANIST: Humanities Computing list - created 07 MAY 87 * Comments: All requests for subscription are forwarded automatically to the list owners ("subscription= by_owner"). The owners can then request information about the potential list member before adding that person to the list. Since the editors organise submissions into digests, they have set "editor-header= no". The editor header is helpful for editors who simply want to check submissions and then forward them back to the list for distribution. 5.4 Private organisation's list The following is typical of a well-defined, relatively static group. Keywords for TAU-LAW@TAUNIVM.BITNET: * Tel Aviv University Law Faculty List * * Review= Private Subscription= By_owner * Send= Private Notify= Yes * Reply-to= Sender, Respect Files= Yes * Validate= Store only Confidential= Yes * X-Tags= Comment Ack= Msg * Stats= Normal,Private * Newsgroups= None Notebook= No * Errors-To= Owner * Owner= ZIMMER@TAUNIVM (Zehava Zimmer) Comments: Because this list is only for faculty members of Tel Aviv University, "Confidential= Yes" is used so that TAU-LAW will not appear in the global list of lists. It is mostly used for announcements of lectures and other events, so it was decided that no logs need be kept ("Notebook= No"). Since it is used for announcements and not for discussion, there is "Reply-to= Sender, Respect" so that queries will go to the person making the announcement and not to the whole group. Note the use of "Newsgroups= None" so that n line will appear in mail from the list. 5.5 List on non-VM, non-NJE server Keywords for EXCEL-L@PEACH.EASE.LSOFT.COM: * * Microsoft Excel Developers List * * Subscription= Open,Confirm * Review= Private * Send= Editor * Editor= nathan@ubvm.cc.buffalo.edu,nathan@lsoft.com * Editor= (EXCEL-L) * Reply-to= List,Respect * Files= No * Confidential= Yes * Notebook= Yes,F:\LISTSERV\ARCHIVES\EXCEL-L,Monthly,Private * Default-options= NoRepro,NoFiles * Ack= Msg * Notify= No * Validate= No * Errors-To= nathan@linus.dc.lsoft.com * Auto-Delete= Yes,Full-Auto * Filter= ALSO,*@*LIBHITECH.COM * Owner= nathan@ubvm.cc.buffalo.edu (Nathan Brindle - Admin only) * Owner= Quiet: * Owner= nathan@lsoft.com (Nathan Brindle:) * Owner= nathan@linus.dc.lsoft.com (yup, Nathan Brindle:) * * Users should send list requests to the * address(es) listed before "Owner= Quiet:". * * This list installed on 95/01/27, running under L-Soft's * LISTSERV-TCP/IP for Windows NT version 1.8b. * Comments: The same keywords are used on all platforms and for both the NJE and the TCP/IP versions of Listserv. The "Filter= " keyword is used to prevent users from a particular site from joining the list or sending messages. The use of "ALSO" means that this filter is in addition to the default filter for all lists maintained by this server. Chapter 6 - Other sources of information 6.1 Listserv lists LSTOWN-L@SEARN.BITNET Listserv list owners' forum This is THE list for list owners and moderators. This is the place for discussing problems regarding Listserv which you have been unable to solve through the normal support channels. LSTSRV-L@SEARN.BITNET Listserv give-and-take forum (peered) LSTSRV-L@UGA.BITNET Listserv give-and-take forum (peered) This list is mainly for Listserv server maintainers, but owners who are interested in the workings of the Listserv software also participate. NEW-LIST@NDSUVM1.BITNET New list announcements The NEW-LIST list is primarily for initial announcements of new mailing lists, but it may also be used to find out if a list on a particular subject already exists, after you have checked in the lists of lists. LDBASE-L@UKANVM.BITNET Listserv database search capability list This list is for discussion of the uses of the Listserv database facilities. These facilites are of potential interest to list owners. 6.2 Basic Listserv documentation set The documents which are relevant to list owners are: LISTOWNR REFCARD LISTOWNR MEMO LISTKEYW MEMO These documents are available from any Listserv server. They are listed in INFO FILELIST. The first two will only be sent to you if you make your request from an address which is listed as a list owner at that server. 6.3 Listserv Release Notes The Release Notes are detailed technical descriptions of the changes in each new release of the Listserv software. The Release Notes are available from listserv@searn.sunet.se in filelist LINFO as: Vnna RELNOTES where 'nna' indicates the release. For example, the Release Notes for 1.8a are available as V18A RELNOTES. 6.4 Listserv documentation from the EARN Association The following documents were written by the staff of EARN (now TERENA). They are available from listserv@gumncc.bitnet in the DOC filelist LSVGUIDE MEMO - Listserv User Guide, plain text LSVGUIDE PS - Listserv User Guide, Postscript LISTSERV FILEDOC - Documentation for Listserv files, plain text LISTSERV FILE-PS - Documentation for Listserv files, Postscript LSVQUICK MEMO - Listserv quick reference, plain text LSVQUICK PS - Listserv quick reference, Postscript LSVSTART MEMO - Listserv starter guide, plain text LSVSTART PS - Listserv starter guide, Postscript LISTKEYW TXT - List header file keywords document, plain text The last document, LISTKEYW TXT, is an update of the document LISTKEYW MEMO from the basic Listserv documentation set, and thus is of particular interest to list owners. 6.5 Other documentation files Jim Gerland has written a set of short documents for list owners. They can be obtained from listserv@ubvm.cc.buffalo.edu using the command: get lsvowner package The files in this package are: LSVOWNER READY - 'Your List is Ready' information LSVOWNER WELCOME - 'Welcome to this list' information LSVOWNER TXT - Generic List Owner Instructions LSVOWNER NEW-LIST - New List Announcement information LSVOWNER GATEWAY - USENET News Gateway information LSVOWNER HEADERS - List header instructions LSVOWNER FIL-LIST - FILELIST instructions Various documents are available from listserv@searn.sunet.se in the LINFO FILELIST, including the following: LISTSERV TIPS, written in 1991 by Lisa Covi while working for CREN. This document is still valuable, but it must be used with caution because many changes have been made to Listserv since it was written. FSV GUIDE, written by Ben Chi. This guide explains how to make files available using Listserv's file server capabilities. It is also available from: listserv@albany.edu MLM-SOFT FAQ, written by Norm Aleks. This is a guide to mailing list management software and covers many different software packages in addition to Listserv. This document is updated and posted monthly to several Usenet newsgroups including comp.mail.list- admin.software and news.answers. 6.6 Usenet newsgroups Two Usenet newsgroups are devoted to mailing list management issues: comp.mail.list-admin.policy comp.mail.list-admin.software