LISTSERV historical documentation, release 1.5d ----------------------------------------------- Copyright Eric Thomas 1986 ******************************************* * * * A description of list header keywords * * * ******************************************* 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 enclosed in parenthesis are "generic parameters" which define a set of possible values for a keyword operand, as described below: Generic parameters ------------------ (net-address): Describes a RFC822-compatible network address, usually of the "userid@node.domain" form. (access-level): Controls which category of users has access to the information or service to which this para- meter applies. (access-level) can be either: Public Everybody has access to the information. Postmaster Only the postmaster (ie LISTSERV operations staff) has access to the information. A1,A2,... with Ai being either: Private Only users subscribed to the list have access to the information. (listname) Only the members of the specified list have access to the info. Owner Only the list owner can access the information. Owner(list) Only the owner of the indicated list can access the information. Service Only people in the service area of the list can see the info. Service(list) (destination): Indicates the destination of a piece of mail, message or reply. Depending on the type of reply, all the options listed below might not be effective. For example, "Reply-to= None" is functionally identical to "Sender", whereas "// JOB Reply-to=None" (in a batch command file) would actually suppress all replies. 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 (interval): Is a time interval that indicates how frequent ly 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 avai- lable. Yearly Monthly Weekly Self-explanatory Daily Hourly Single The operation is to be done only a single time. |(peer): Is the node-id or network address of a peer | list server. 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 diffe- | rent, the full list network address must be | given, eg "REXX-L@UIUCVMD". | | |(area): Is a means whereby a node or list of nodes can | be identified. An area can be either: | | - The name of a network, eg EARN, BITNET | - The name of a country, eg Germany, Canada | - 'Local', in which case it is equated to the | value of the "Local=" keyword (qqv). | - A node name, eg FRECP11 | - A simple wildcard nodename pattern such as | FR*, *11, *ESA*, D*ESA*, etc | | |(mon-address): Is a means whereby 'list monitors' can be iden | tified (the term 'list monitor' refers to a | human person who monitors the activity of a | list). A 'mon-address' can be: | | - A single network address, eg INFO@TCSVM | - 'Postmaster', which indicates the "main" | postmaster | - 'Postmasters', which indicates ALL the post- | masters, 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 ! Whenever several keywords or operands 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". List control keywords --------------------- ************************** * Review= (access-level) * ************************** This keyword defines the category of users who are allowed to review the network addresses and names of the persons subscribed to a list. The default value is "Public". ****************************************** * Subscription= By_owner | Open | Closed * ****************************************** This keyword defines whether or not new users are allowed to subcribe to the list, and if not, whether their subscription requests are to be forwarded to the list owner or not. 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. ********************************* * Send= (access-level) | Editor * ********************************* Defines the category 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). ******************** * Notify= Yes | No * ******************** Defines whether the list owner is to receive notification of new subscriptions and deletions, etc. The default is "Yes". ******************************************** * Reply-to= (destination),Respect | Ignore * ******************************************** Indicates whether the "Reply-to:" tag supplied by the sender of the mail file is to be preserved or discarded (if present), and, if discar- ded or omitted, what should be placed in the new "Reply-to:" generated ! by the server. The default value is "List,Respect". Note that some ! mailing systems are unable to process a "Reply-To:" field with multiple ! addresses correctly and may therefore disregard the "Reply-to= Both" ! option and treat it as "Reply-to= List". Respect: The original "Reply-to:" tag, if any, is kept. Ignore: The original "Reply-to:" tag is ignored and discarded. ******************* * Files= Yes | No * ******************* Indicates whether files can be sent to the list or not. The default value is "Yes". ************************************ * Confidential= No | Yes | Service * ************************************ ! Indicates whether the list should be hidden from users or not. A con- ! fidential 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. *************************************** * Validate= Store only | All commands * *************************************** Under Revised 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= All commands", password valida tion applies to ALL the commands that modify the contents of the list, eg 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 UREP hackers who might issue a command "from" your userid@node to change the name under which you appear on the list to ! something impolite. The default is "Store only", but it is recommended ! that "serious" or "important" lists be changed to "Validate= All ! commands". ****************************** * X-Tags= Yes | No | Comment * ****************************** Indicates whether "X-To:" and "X-cc:" 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. Yes: This information must be provided in the form of "X-To:" and "X-cc:" 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, ie "Comment: X-To:" and "Comment: X-cc:". No: This information must not appear at all in the mail haeder. ************************************************** * Stats= Normal | Extended | None,(access-level) * ************************************************** 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, number of outbound mail files, and total number of outbound 80-character records, for each user on the list, and a similar information for file distribution. Extended statistics include all of the above plus actual network load indication in "link.kbytes" units. *********************** * Ack= Yes | Msg | No * *********************** Defines the default value of the "ACK/NOACK" distribution option for the corresponding list, ie 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. Yes Messages will be sent when your mail file is being proces- sed. Additionally, a short acknowledgment with statistical information on the mailing will be sent back to you, in case a link failure prevented you from receiving the messa ges. This is the default. Msg Messages will be sent when your mail file is being proces- sed. Statistical information will be sent via messages, but no acknowledgment mail will be sent. No A single message, but no acknowledgment mail nor statistics will be sent when your mail file is being processed. *********************** * Formcheck= No | Yes * *********************** Indicates whether files to be redistributed to the list must have a FORM of REDIST to be accepted or not. The default value is "No", but can be changed to "Yes" if for some reason it is suspected that files can be accidentally sent to the list userid without being intended for redistribution. Note that on some systems the FORM field is imposed by the networking software and cannot be changed by the user. **************************************************************** * Notebook= No | (Yes,(fm),(interval)|Separate,(access-level)) * **************************************************************** 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". (fm) Is the filemode of the disk on which the notebook is to be kept. This information is of little importance to users, except perhaps to the users of the server's host computer who might, in certain circumstances, be allowed to LINK to one of the server's disks (containing public information). Contact the local LISTSERV operation staff for more infor- mation. (interval) Defines the filetype of the "notebook" file for the list, as indicated below (the filename will always be the same as the list name): Single: A single file of filetype "NOTEBOOK" is created. Yearly: A new file is started each yearly, filetype is "LOGyy" Monthly: The filetype is "LOGyymm" Weekly: The filetype is "LOGyymmw" (w in "A"-"E") Separate: A separate file is kept for each mailing (eg digests). The filetype is "yy-nnnnn" (sequential counter). ! ! Note: notebooks can now be retrieved by means of the GET command. A ! list of all available notebooks can be obtained with a GET ! NOTEBOOK FILELIST command. ********************************************* * Owner= (net-address1)|(access-level1),... * ********************************************* 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 access-levels is acceptable, ! for example: Owner= BIG@BLUE,(STAFF-L),Owner(MAIN-L) ! ! An interesting application 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)". 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 STAFF-L list. ********************************************* * Editor= (net-address1),(net-address2),... * ********************************************* 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. ! ! The file will be forwarded to the editor 'as is', without being inclu ! ded in a mail envelope. This method makes sure that the original ! "Resent-" tags (if any) and "To:" keyword are preserved. BITNET editors ! will receive the forwarded mailfile in their mailbox in Netdata format ! (or whatever is the default format for their operating system), while ! non-BITNET editors will receive it via their mailing system with an ! extra mail envelope being generated to enclose the original (unaltered) ! mailfile. ! ! IMPORTANT NOTE: The editor MUST be a human person, not a file server, ! list server, mailer, or suchlike. Specifying a program's mailbox as ! "Editor=" could result in a mailing loop for which the author could not ! be held responsible. ******************* * Language= idiom * ******************* | 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. A > further release might incorporate customized messages by using the > :country tag in BITEARN NODES to determine the idiom to be used. ****************************** * Peers= (peer1),(peer2),... * ****************************** | Defines the (global) list of all the servers in the world that 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 com- | mands to determine the "nearest" peer list to a given user. For exam- | ple, when a SUBSCRIBE command is received from a user and it is deter- | mined that there is a better (nearer) peer list for him, the subscrip- | tion request is automatically forwarded to the appropriate LISTSERV. ******************************** * Service= (area1),(area2),... * ******************************** | Defines the 'service area' outside of which subcription 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, eg "Service= Germany", | and still have users subscribed to the best possible server. ************************** * Local= node1,node2,... * ************************** | Defines the nodes which are to be considered as 'local nodes' for | both service area checking and mail header grouping. 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 | non-local 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, "FRECP11" | and "VAX2.LAB1.LAN" are both valid node names. ************************************************ * Errors-To= (mon-address1),(mon-address2),... * ************************************************ | Defines the person or list of persons that are to receive rejection | mail for the list. The default value is 'Postmaster', and it is recom- | mended that the owners change it to 'Owners' or 'Owners,Postmaster' as | soon as they become familiar with Revised LISTSERV.