List Keyword Reference for LISTSERV® version 15.0
Last updated 20 Nov 2006
Format of List Header Keyword Settings
List Maintenance and Moderation Keywords
Default Values for All Keywords
The list header contains configuration information for the list. To edit it, use the GET listname (HEADER command, edit the header, and send it back to LISTSERV with the PUT listname PW=XXXXXXXX command. For more details on this procedure, consult the List Owner's Manual for LISTSERV. If you have the web archive and administration interface installed, you can also do this via the web (see chapter 11 of this manual).
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 40-50 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:
Format of List Header Keyword Settings
List header keyword settings can be defined in any of the following formats (we are using three parameters for our examples; note that some keyword settings have more then three parameters and adjust accordingly):
* Keyword= parameter1,parameter2,parameter3
* Keyword=parameter1,parameter2,parameter3
* Keyword= parameter1, parameter2, parameter3
* Keyword = parameter1,parameter2,parameter3
* Keyword= parameter1
* Keyword= parameter2
* Keyword= parameter3
The last example above is useful when defining a keyword setting (for instance, Notebook=) which may contain a long directory path. When using this format, note carefully that the last parameter on the line MUST NOT be followed by a comma. LISTSERV will properly concatentate the parameters internally as if they had commas. For instance,
* Keyword= parameter1,parameter2
* Keyword= parameter3
and variations are also supported; for instance,
* Notebook= Yes
* Notebook= /home/listserv/archives/english101-fall2002
* Notebook= Weekly,Private
is perfectly legal.
LISTSERV reads list headers one line at a time, assuming that any word followed by an equal sign is a keyword, and then, starting at the equal sign, reads keyword parameter settings either until it encounters a space that is not preceded by a comma (the first parameter excepted), or until it reaches the next word in the line which it evaluates as being a keyword. Thus LISTSERV will completely ignore a keyword setting coded as follows:
* Keyword parameter1, parameter2, parameter3
because there is no equal sign following the keyword. (This is one way to comment out a keyword setting if you do not want to completely remove it from the list header.) Likewise, while LISTSERV will recognize the following as a keyword setting:
* Keyword= parameter1, parameter2 parameter3
it will read only to the second parameter because the second parameter is not followed by a comma.
It is also possible to define multiple keywords on a single line, so long as the line does not wrap and does not exceed 100 characters. For instance,
* Send= Private Confidential= Yes Review= Owners
is a legal LISTSERV header line containing settings for the Send=, Confidential=, and Review= list header keywords.
Keyword settings are always evaluated in a case-insensitive manner. Under unix, where case sensitivity is an important issue, file and directory paths defined in the list header are always converted to lower-case for LISTSERV's use. Thus all data files written to or read from by LISTSERV under unix must be named in lower case, regardless of the case used in the list header keyword setting.
Starting with LISTSERV 1.8d, it is possible to hide part or all of a list header (except for the list title) from users who send the REVIEW command or who try to view the list's configuration via the CataList. The following syntax is used:
* My very own list
*
* blah blah blah
*.HH ON
* This line is hidden
* This line is also hidden
*.HH OFF
* This line is not hidden
The sequence can be repeated as many times as required. GET will return the unedited header with the .HH sequences, REVIEW will replace hidden lines with a note saying that lines were hidden. You can't hide the fact that some lines were hidden because it would lead to people spending hours trying to figure out problems which only appear to be problems because some of the keywords are not visible. Please note that L-Soft will not field support inquiries with hidden headers; you must send the entire raw header (including the .HH lines) when requesting support.
In LISTSERV 14.2 (1.8e-2003a) and later,
· .HH commands can be nested.
· The .HH ON and .HH OFF dot commands are respected in KEYWORDS files called from list headers with the .IK dot command. Previous versions ignored .HH commands in KEYWORDS files.
The following should be noted:
· In a KEYWORDS file, .HH OFF found in excess of .HH ON will be ignored. This ensures that a KEYWORDS file called from inside of an .HH ON block will not expose the remainder of that block upon return from the call.
· Similarly, LISTSERV will internally generate as many .HH OFF tags as necessary before exiting the KEYWORDS file and returning to the list, if more .HH OFF tags than .HH ON tags exist in the KEYWORDS file.
Both of these precautions ensure that .HH coding errors in a KEYWORDS file will not result in exposure of keyword settings that it is desired to keep hidden.
Note: Special parameters used by only one or two keywords are defined along with the keyword and do not appear in this listing.
net-address Describes an Internet address, such as JACK@XYZ.COM.
access-level Controls which category of users has access to the information or service to which this parameter applies. access-level can be either:
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:
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.
destination Indicates the destination of a piece of mail, message or reply.
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 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.
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. 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, for example "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, for example EARN, BITNET
The name of a country, for example Germany, Canada
'Local', in which case it is equated to the value of the "Local=" keyword (q.q.v.).
A node name, for example SEARN
A simple wildcard nodename pattern such as FR*, *11, *ESA*, D*ESA*, etc.
mon-address Is 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 'mon-address' can be:
A single network address, for example 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
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".
Optional parameters are indicated by enclosure in square brackets ([ ]); for instance, in the case of
Send= Editor[,Hold][,Confirm[,Non-Member | All]][,Semi-Moderated][,NoMIME]
the only required parameter is the first one ("Editor"), and each of the following five parameters is optional. In this case, note carefully the nested brackets signifying that one parameter ("Non-Member | All") is available only if another parameter ("Confirm") is also specified in the keyword setting. Further, because the logical OR symbol is used, the two options "Non-Member" and "All" are mutually exclusive, thus only one of them may be specified.
Do not type the brackets when using the optional parameters! Where the use of square brackets and logical OR signs together could be confusing, we have shown each of the alternate configurations on separate lines.
Keywords fit into several different classifications. These classifications, and the associated keywords, are as follows:
Access Control Keywords (page 8)
|
Determines whether MIME attachments may be distributed to the list |
|
|
Determines whether non-mail (NJE) files may be distributed by the list |
|
|
Gives list owners control over problem users and/or gateways |
|
|
Restricts who may review the list of subscribers |
|
|
Restricts who may send postings to the list |
|
|
Determines whether or not list statistics are available, and to whom |
Distribution Keywords (page 16)
|
Controls the level of acknowledgement messages to those posting messages |
|
|
Limits the total number of messages that will be processed by the list per day before the list is held |
|
|
Controls the automatic digestification option |
|
|
Determines through which gateway Internet mail will be sent |
|
|
Determines how LISTSERV distributes list mail |
|
|
Defines USENET newsgroups linked to the list |
|
|
Determines through which gateway NJE mail will be sent |
|
|
Controls whether or not mail will be processed during "prime time" |
|
|
Sets a default for the "Reply-To:" field in the header of list mail |
|
|
Defines the value LISTSERV places in the "Sender:" header field of list mail |
|
|
Defines sub-lists of a "container" or "super-" list. |
|
|
Defines up to 23 sub-topics for a list |
Error Handling Keywords (page 26)
|
Sets parameters for the auto-deletion feature |
|
|
Determines the network address to whom mail delivery errors are directed |
|
|
Defines the type of mailing loop checking performed by LISTSERV |
|
|
Determines which built-in address filter is used by LISTSERV |
List Maintenance and Moderation Keywords (page 31)
|
Determines who may update the list's configuration (header) |
|
|
Defines an editor or editors for moderated lists |
|
|
Controls if an explanatory mail header is added to list messages forwarded to the list editor (if one is defined) |
|
|
Determines how the list address is announced in message headers |
|
|
Defines a long listname alias for the list |
|
|
Defines the editors on moderated lists who will receive postings for approval. |
|
|
Sets forwarding when a list is moved to a different LISTSERV host |
|
|
Controls the notebook archive for a list |
|
|
Determines the type of header information included in the notebook archive |
|
|
Defines whether or not (or to whom) subscription notification is sent |
|
|
Defines the owner (or owners) of the list |
|
|
Defines peers for the list |
|
|
Controls whether or not subscription renewal is implemented, and how |
|
|
Controls the maximum size of any single message posted to the list |
|
|
Controls the "subject tag" text for messages coming from the list |
|
|
Controls whether "X-to:" and "X-cc:" tags are included in list mail headers |
Security Keywords (page 42)
|
Enable logging (in listname.CHANGELOG) of all subscription changes |
|
|
Determines whether or not an entry for the list appears in the List of Lists |
|
|
Defines a list "exit" which modifies the default behavior of LISTSERV |
|
|
Defines which nodes are considered "local" for this list |
|
|
Sets a password used for validation of list maintenance commands |
|
|
Defines an area or areas outside which subscription requests are not accepted |
|
|
Determines whether or not list commands must be validated with a password or the "OK" mechanism |
Subscription Keywords (page 50)
|
Defines a default number of hours LISTSERV holds jobs requiring confirmation |
|
|
Defines what options should be set by default for new subscribers |
|
|
Defines what topics should be set by default for new subscribers |
|
|
Defines how new subscriptions are handled, and if confirmation is required |
Other Keywords (page 54)
|
Defines search categories for the CataList service |
|
|
Controls DBMS features |
|
|
Defines the minimum number of columns allowed for list addresses in a REVIEW |
|
|
Defines the language in which information mail and messages are sent |
|
|
Defines certain limits (no. of subscribers, etc.) for a list (ISP scope option only) |
|
|
Controls whether long-lines support is enabled |
|
|
Controls whether or not list postings are treated as mail-merge jobs |
|
|
Controls certain miscellaneous options which don't fit other places |
|
|
Controls how LISTSERV handles control characters in list mail |
Default Values for All Keywords (page 62)
Attachments= Yes[,allowed_content_types[,Filter]]
Attachments= All[,allowed_content_types[,Filter]]
LISTSERV 1.8d 2000b "level set" and LISTSERV 1.8e and later include a list-owner-configurable message attachment filter. This feature allows you to control the posting of various types of MIME attachments (images, audio, etc.) to your lists. LISTSERV 1.8e adds the ability to control the posting of inline uuencoded files to your lists on an on/off basis (off being the default if attachment control is enabled).
NOTE: The ability of LISTSERV to filter or reject messages that contain MIME attachments is completely dependent on the ability of the poster's mail client to properly identify the MIME attachment when the mail is originally sent. Filtering/rejection is done based on the Content-Type headers found in the message--NOT by evaluation of the actual contents of the attachment. If for instance an executable binary (normally Content-Type: application/octet-stream) is sent by the client with a Content-Type of "text/plain", it will not be filtered or rejected by LISTSERV since (as noted below) text attachments are not covered by this keyword setting.
A registry of allowable MIME types for attachments, maintained by the Internet Assigned Numbers Authority (IANA) per RFC2048, can be found at
http://www.iana.org/assignments/media-types/index.html
The options are:
Attachments= Yes All types of attachments are allowed to be posted to the list (the default). Note however that other configuration options may still disallow the posting of certain attachments, and that "Attachments= Yes" does not override them. For instance, if you have "Language= NoHTML", setting "Attachments= Yes" does not override the Language= setting. Or if you have "Sizelim=" set to a value that precludes a file of x number of lines from being posted to the list, setting "Attachments= Yes" will not override the Sizelim= setting if the message with its attachment exceeds the number of lines specified by Sizelim=.
Attachments= No All types of attachments are disallowed, other than plain text (always allowed) and HTML text (which is controlled exculsively by the "Language= NoHTML" keyword setting). With "Attachments= No", LISTSERV rejects messages containing attachments and bounces them back to the poster.
Attachments= No,Filter Same as "Attachments= No", except that LISTSERV simply removes the unwanted material from the message and processes it instead of rejecting it out of hand. The removal of material is a silent operation and the poster is not notified that the attachment was discarded.
In LISTSERV 1.8e and later, note that in all three of the above cases, when a message containing one or more uuencoded files is posted to the list, the encoded file(s) is/are stripped from the body of the message and the remainder of the message is passed through to the list. LISTSERV 1.8d was unable to recognize or strip inline uuencoded files.
Attachments= All (Requires 1.8e or later) This setting tells LISTSERV to allow inline, uuencoded files, such as are generated by Microsoft Outlook, overriding the default.
One important restriction: UUencode filtering is strictly on/off. There is no attempt on the part of LISTSERV to guess file types when filtering is enabled (the default). This would be hazardous to begin with as support for these attachments is usually provided on a legacy basis in mail clients; that is, client A and client B could have a very different opinion on the type of the attachment.
It is also possible to allow certain MIME types to be passed through to the list while rejecting or filtering all others. For instance,
Attachments= Yes,image,application/*msword
allows only the specified attachment types and rejects everything else. If you don't want to reject messages that contain other types of attachments, but just want to remove all other types of attachments, you add the ",Filter" parameter at the end of the line--ie,
Attachments= Yes,image,application/*msword,Filter
This means, "Allow all image and application/*msword attachments, and strip all other attachments". Again, note that plain text ("Content-Type: text/plain") is always allowed and does not need to be included in the list of allowed attachment types. Likewise, HTML text is controlled exclusively by the "Language= NoHTML" keyword setting. Other text subtypes are, however, controlled by "Attachments=", so they need to be listed if you intend to allow them.
Additionally, should it be desired to allow all inline uuencoded files but restrict the list to certain MIME types, you can specify, similar to the above, something like
Attachments= All,image,application/*msword
or
Attachments= All,image,application/*msword,Filter
(In the preceding examples note carefully that "image" by itself is equivalent to "image/*"--in other words, when you code "Attachments= image", you are saying that all MIME image sub-types, for example, "image/jpeg", "image/gif", and so forth, are to be accepted. If only certain sub-types are acceptable, for instance if you want to accept only JPEG graphics and ensure that others don't go through, you must specify the types explicitly--eg "Attachments= image/jpeg".)
Note carefully that simply coding something like "Attachments= image" will not necessarily allow all image files through. This is highly dependent on the client being used by the poster. For instance, if your client attaches all binary files as "Content-Type= application/octet-stream", regardless of whether a given binary is (for instance) an executable image, a Word file, or a compressed archive, and you send a JPEG to a list with "Attachments= image" set in the header, it will be rejected since the image does not have a "Content-Type: image" tag. Specifically this appears to be the case with Eudora 3.x but may not be limited to that particular client.
In the 1.8d version of the attachment filter, attachments sent by Microsoft Outlook cannot be blocked by LISTSERV as they do not follow MIME standards (at least not up to and including Outlook 97; this writer has not installed Outlook 2000). Outlook sends attachments as imbedded uuencoded files and does not use the MIME Content-Type: header. LISTSERV 1.8e is able to recognize and filter inline uuencoded "attachments" as noted above.
The rejection message sent by LISTSERV when ",Filter" is not specified is found in the BAD_ATTACHMENT mail template form (see chapter 9 for information on LISTSERV's mail templates). Note that the BAD_ATTACHMENT template form is a linear template and as such does not allow text formatting commands to be used.
The reason HTML text is not subject to "Attachments=" filtering is to allow you to reject (bounce) messages with attachments, while silently suppressing HTML text in multi-part messages which also contain a plain-text alternative. Some mail programs send both HTML and plain-text versions of messages, and, even if you do not want HTML text on your list, there is little point in keeping out people who use it (who are often new to the Internet and aren't aware that their mail programs are sending HTML text) when you can simply remove the HTML part. At the same time, you may want to reject postings containing images out of hand, rather than removing the images and continuing. The same applies to Exchange attachments, which are filtered by default (see "Language= Exchange").
This keyword is not available in LISTSERV Lite.
(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 non-RFC822 mailer users from posting to lists.
Files= has absolutely no effect under the non-NJE versions of LISTSERV. Specifically it will not prevent users from sending "attached" (MIME-encoded) files to lists. It is provided under all versions for backwards compatibility only (i.e., for lists being migrated from NJE servers). See the Attachments= keyword for attachment blocking.
Filter= Only,net-address1,net-address2,...[Allow],net-addressn,... |
Filter= Also,net-address1,net-address2,...[Allow],net-addressn,... |
Filter= Safe,net-address1,net-address2,...[Allow],net-addressn,... |
"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 parameter 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 "Filter= 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.
· If "Filter= Only..." is specified, 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.
· If "Filter= Safe" is specified, LISTSERV uses the "more safe" of its two built-in filters. These built-in filters are (1) a "minimal" one, which is used for safe lists; and (2) 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.
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.
In all cases, LISTSERV extracts as many e-mail 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 in BITEARN NODES).
Version 1.8d adds the ability to "exempt" certain addresses (or wildcards) from the default filters. You can combine "Filter= ...,Allow,..." with the forms documented above as long as you put the "allow" information last. That is, the first word must be ONLY, SAFE or ALSO as before, and you can then have ALLOW anywhere (including as the second word) followed by a list of addresses that should be allowed even if present in the filter. The default for ALLOW is the empty string. Examples of ALLOW usage follow:
Filter= Also,userid@host1.com,*@host2.edu
Filter= Allow,niceguy@host2.edu
The first example stops everyone from host2.edu from posting to the list, but since we've determined that niceguy@host2.edu is a considerate human being and should be allowed to post, we've defined him as an exception to the general rule by including him in the "Allow" part of the filter.
Filter= Safe,Allow,root@host1.edu
The second example would invoke the "safe" filter mentioned above, but would allow root@host1.edu to subscribe to and post to the list, instead of bouncing his mail because it matches one of the entries in the "safe" filter. All other "root" users' mail will be caught by the "safe" filter and transferred to the list owner as an error.
See also Safe= and Loopcheck=.
This keyword defines the categories of users who are allowed to review the (non-concealed) Internet addresses and names of the persons subscribed to a list. Beginning with version 1.8c, the default value is "Review= Private".
Send= Public[,Confirm][,Non-Member]
Send= Private[,Confirm]
Send= Editor[,Hold][,Confirm[,Non-Member | All]][,Semi-Moderated][,NoMIME]
Send= other-access-level[,Confirm]
(Note: The "Non-Member" option is available only in LISTSERV 14.3 and later, and only with "Send= Public,Confirm" or "Send= Editor,Confirm...". Similarly, the "All" option is available only in LISTSERV 14.3 and later, and only with "Send= Editor,Confirm...". Please see below for full details.)
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". Other access-levels for use with Send= would include "Private", "Editor", "Owner", etc. (see the beginning of this document for the definition of an access-level). A literal Internet e-mail address may also be used in place of the access-level, for example, Send=joe@foo.bar.com. Using a literal address is one way to ensure that only an authorized person can post to the list, for instance, if the list is an "announce-only" list rather than a discussion list.
Requiring confirmation: When the "Confirm" option is enabled, the sender is required to confirm the posting. When LISTSERV receives mail for the list, it sends an e-mail to the sender requesting a confirmation. The confirmation can be accomplished by replying to the confirmation with another e-mail containing the text "OK" (the subject of the confirmation e-mail contains a validation "cookie") or by clicking on the confirmation URL provided in the e-mail.
List owners can require that non-subscribers actively confirm their messages to the list, while allowing subscribers to post without confirmation. This can dramatically cut down on spam for lists accepting postings from non-subscribers. When "Send=Public,Confirm" is used, the "Non-Member" setting can be specified to limit the confirmation requirements to non-members. When "Send=Editor,Confirm" is used, the "Non-Member" setting can be specified to limit the confirmations to non-members and to require editors to confirm their own posts (see below).
Moderated/Edited lists: When the list is controlled by an editor (Send= 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").
When the "Hold" option is enabled (Send= Editor,Hold), 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".
When the "Confirm" option is enabled on a moderated list (for instance, Send=Editor,Confirm), mail sent by any editor or moderator requires confirmation by that editor or moderator. This is to prevent a user from forging mail to the list under an editor's or moderator's return address. The confirmation request is validated with the "OK" mechanism. Please note that this does not mean that a double validation is required when an editor approves other peoples' postings, but only that the editor's own postings to the list and any reposts he does on others' behalf require a confirmation from him that he actually submitted them. In other words if the editor simply "OK"s a posting, he doesn't have to "OK" his own "OK".
It is also possible to set a list to
* Send= Editor,Hold,Confirm
This allows you to "OK" both subscriber submissions and editor/moderator approvals, as described above.
"Non-Member" and "All" options with "Confirm" (14.3 and later): List owners can require that non-subscribers actively confirm their messages to the list, while allowing subscribers to post without confirmation. This can dramatically cut down on spam for lists that accept postings from non-subscribers. To activate this feature, you would set:
* Send= Public,Confirm,Non-Member
or either
* Send= Editor,Confirm,Non-Member
or
* Send= Editor,Hold,Confirm,Non-Member
in the list header.
It should be noted that, although LISTSERV will accept “Send= Private,Confirm,Non-Member” when the header is stored, that setting is equivalent to just “Send= Private,Confirm” since by definition only subscribers are allowed to post to a list coded "Send= Private".
The intent is to help list owners cut down spam on public discussion lists, without inconveniencing normal list subscribers. For public lists, it works like "Send= Public,Confirm" if you are not a member of the list, otherwise it works as "Send= Public" (no confirmation required from subscribed users). List owners and editors are considered to be members of the list even if they are not subscribed to it, and are thus not subjected to the confirmation requirement.
For edited lists, the behavior is similar -- non-members must confirm their own postings before they are submitted to the editor for approval, whereas members' postings go directly to the editor for approval without the intermediary step. It should be noted that ",Confirm" still activates the anti-spoofing feature that already existed, which requires that the editor must approve his own postings.
Please note carefully: On an edited list, if it is desired for all posters to confirm their own postings regardless of their subscription status, substitute "All" for "Non-Member", that is
* Send= Editor,Hold,Confirm,All
forces all posters to validate their own postings before they are submitted to the editor for final approval.
IMPORTANT: "Non-Member" or "All" must always be specified in conjunction with "Confirm". For instance, setting "Send= Public,Non-Member" or "Send= Editor,All" will not activate the feature.
Semi-Moderated option for Send= Editor: When the "Semi-Moderated" option is enabled (Send= Editor,Semi-Moderated), mail sent to the list will be treated in one of two different ways, depending on the contents of its "Subject:" field. If the subject starts with "Urgent:" (case-independent), the list is treated as a non-moderated one, which means that the message will be immediately distributed provided that the sender matches the access-level description. If the subject does not start with "Urgent:", the message is forwarded to the primary list editor (unless it came from someone defined as an editor). A "Subject:" field beginning with "Re: Urgent:" is treated identically, so that replies to urgent messages are by default considered urgent.
Note that
* Send= Public,Semi-Moderated
is a contradiction. If Send= Public, no Editor is involved and anyone can post to the list, so Semi-Moderated is ignored.
"Send= Private,Semi-Moderated" was supported in Revised LISTSERV prior to approximately 1994, and, while previously documented in this space, was never actually available in L-Soft LISTSERV (that is, from version 1.8a and following).
A usage example:
* Send= Editor,Semi-Moderated
* Editor=NATHAN@EXAMPLE.COM,ERIC@EXAMPLE.COM
In this example, a message sent to the list would be:
· Processed, if the sender used the "Urgent:" subject
· Forwarded to the moderator if the sender didn’t use the "Urgent:" subject.
Note that in the above example, messages don’t get discarded if the sender isn’t subscribed.
Moderation "OK" requests and MIME attachment display: In versions previous to LISTSERV 1.8e, an OK confirmation request for a message coming to a moderated list displayed the message to be approved in its "raw" format, i.e., there was no attempt made to display/decode MIME attachments that might be present in the message to be approved. LISTSERV 1.8e addresses the problem by including a copy of the first text/plain part (if one exists in the message) for the purpose of quick screening. The following restrictions apply:
1. This is only done for MIME messages (even simple single-part ones, but they must have MIME headers).
2. The text part in question is sent pretty much 'as is', that is, as an extra text/plain part in the message, with all the options and encoding and what not supplied in the original message. The reason is quite simply that it would be a lot of work and, in some extreme cases (incompatible code page, etc), completely impossible, to embed it into the first text/plain part with the LISTSERV message. The drawback is that some mail agents might conceivably only show the first part until you take some kind of clicking action.
It is important to understand that only the first text/plain part is extracted in this fashion. The goal was to make it easier to approve or reject simple text messages, not to build a factory around a simple problem. The ENTIRE message is available at an extra click.
Where security is a concern, it is important to review the ENTIRE original message and not just the plain text part. There could be an obscene GIF or another text part or a text/html part not matching the contents of the text/plain part or whatever. This is why, again, you are given the ENTIRE original message.
List owners using certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" in the Send= list header keyword; for instance,
* Send= Editor,Hold,NoMIME
"Hold" now forced for multi-part moderated messages: LISTSERV 14.3 and following will force ",Hold" if it is not specified with "Send= Editor" for multi-part messages, in order to generate an approval request that can display the multi-part message correctly.
Stats= Normal | None,access-level
This keyword is not available in LISTSERV Lite.
This keyword is obsolete and has absolutely no effect on all ports of the software except for VM. On non-VM servers it is provided for backwards compatibility only (i.e., for lists being migrated from VM) in order that any existing "Stats=" keyword setting in a migrated list header does not trigger a command parser error.
UNDER VM ONLY, 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.
Defines the default value of the "ACK/NOACK" distribution option for the corresponding list, that is, 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. The default is "Ack= No".
Yes A short acknowledgment with statistical information on the mailing will be sent back to you.
Msg Messages 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]
No For Internet users, no acknowledgement will be sent. For BITNET users, a single interactive message will be sent as the message is processed. This is the default value.
None No messages of any kind are sent when your mail file is processed. [same as No for non-BITNET]
This keyword limits the number of postings that may be processed by the list in a calendar day (midnight to midnight, server time), and, with the addition of a (new) optional second parameter, limits the number of postings that may be accepted from any individual user per calendar day (midnight to midnight in the server's local time zone).
The default is Daily-Threshold= 50. When the value of the first parameter 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 higher-volume lists – individual list owners should study the issue carefully before increasing the daily threshold of their high-volume lists.
When the value of the optional second parameter is reached by an individual user, the user is told that their posting will not be processed and that they should resend it later if they still want it to be posted. The list itself is not held in this situation. The default is to have no such limit, in which case the second parameter is not defined. Note that list owners and list editors are exempt from the individual daily limit. There is no command to reset the limit for an individual user, although the list owner may update the header to increase the value.
Digest= Yes,where | Same[,frequency][,when][,Size(maxsize)][,BOTTOM_BANNER]
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.[1]
Digests are larger messages containing all the postings made by list subscribers over a certain period of time. Unlike real-world 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 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):
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. (Note that any mail already "in the pipeline" to the subscriber will still be delivered.)
When switching from any option to DIGEST 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 DIGEST/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.
When switching from DIGEST or INDEX to NODIGEST or NOINDEX, 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 NODIGEST and then back to DIGEST. You can send both commands in the same mail message to make sure they are executed together.
The list owner controls the availability and frequency of digests through the "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 fourth parameter is optional and specifies when the digest is to be actually distributed. For daily digests, specify 'hh:mm' or just 'hh' in the usual 00-23 scale (24 is also accepted for midnight). Note that daily digests are cut on the hour, regardless of whether or not you have provided ":mm" in your setting. 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 mid-month rather than on the first of the month - if you code a number larger than 28, you may not get a digest every month.
The fifth parameter is also optional. It takes the form "Size(number)" and specifies the maximum number of lines the digest is allowed to reach before a "special issue" is cut. (Note that your digests may run over the limit set in "Size(number)". This is because LISTSERV will never truncate a message in order to meet the digest size limit. Thus, if you've reached 950 lines of your 1000 line setting and the next message is 100 lines long, your digest will cut at 1050 lines.) 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.
In LISTSERV 14.3 and following, you may code a Size() parameter in kilobytes or megabytes rather than in lines. For instance,
|
* Digest= Yes,Same,Daily,Size(100K) |
Cut the digest at 100Kbytes |
|
* Digest= Yes,Same,Daily,Size(1M) |
Cut the digest at 1Mbyte |
As before, the digest will be cut whenever the pending digest grows over the size limit setting.
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.
(1.8c and 1.8d only) The default behavior of a list with a BOTTOM_BANNER template defined in listname.MAILTPL is to suppress the banner throughout the digest and print it only once at the beginning, between the list of topics and the first message in the digest. This behavior can be disabled so that the banner is printed in its normal position at the end of each message in the digest by adding the BOTTOM_BANNER parameter to the Digest= keyword. Evaluators should note that this behavior is also standard on evaluation copies, with the difference that the evaluation kit banner cannot be turned off. L-Soft does not expect that this parameter will be much used, but it is included for the sake of completeness.
(1.8e and following) Bottom banners are no longer suppressed in individual messages when BOTTOM_BANNER is specified. The only use of the BOTTOM_BANNER parameter in 1.8e and following is to force a copy of the banner to be printed at the top of the digest as in previous versions.
Note that TOP_BANNERs are always included at the top of each message in the digest. Generally, TOP_BANNER contains copyright or other important information that should be included with each message, and therefore it is not suppressed.
The second parameter of the "Digest=" keyword ("where") may only be changed by the LISTSERV maintainer. A list owner is allowed to change "Digest= No" to "Digest= Yes,Same....", but any other specification for the digest file location will cause an error. A list owner is also allowed to change "Digest= Yes..." to "Digest= No" without the intervention of the LISTSERV maintainer. Note that if the list is not archived ("Notebook= No"), changing "Digest= No" to "Digest= Yes,Same" will cause the digest files to be written to LISTSERV’s A disk (or equivalent specification on the workstation systems). Since the overhead for a typical digest is small, it is not expected that this will cause any problem for the LISTSERV maintainer.
Internet-Via= internet-hostname
This keyword is not available in LISTSERV Lite.
There is no default value. This parameter determines whether or not mail bound for Internet addresses is routed through a specific Internet gateway. In principle this keyword should never need to be set on non-BITNET hosts.
Mail-Via= DISTRIBUTE | DIST2 | Direct
This keyword is not available in LISTSERV Lite.
The default value is Mail-Via= DISTRIBUTE. DIST2 is functionally equivalent to DISTRIBUTE, and is included for historical reasons.
The Mail-Via keyword should generally not be set, except by the site administrator for troubleshooting mail delivery problems.
On "Networked" and "Tableless" LISTSERV sites, Mail-Via= DISTRIBUTE causes mail to go out over the DISTRIBUTE backbone to spread the delivery load over the LISTSERV Network. Mail-Via= Direct causes LISTSERV to send all mail through the local SMTP server.
On "Standalone" LISTSERV sites, it has no practical use.
Newsgroups= None | usenet_newsgroup1,usenet_newsgroup2...
This keyword is not available in LISTSERV Lite.
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:
* Newsgroups= bit.listserv.lstown-l
This keyword is not available in LISTSERV Lite.
There is no default value. This parameter determines whether or not mail bound for NJE addresses is routed through a specific gateway. In principle this keyword should never need to be set on non-BITNET hosts.
This keyword is not available in LISTSERV Lite.
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", which means that LISTSERV will allow postings to be processed during prime time. You can also explicitly code "Prime= No", which means that LISTSERV will use the value in its PRIMETIME site configuration variable to determine "prime time" for the list.
This keyword can be most useful in controlling the load on the machine running LISTSERV. "Prime=" may also be set to an explicit time specification, for example,
Prime= "MON-FRI: 09:00-17:00; SAT-SUN: -"
or (for a once-weekly newsletter issued on Wednesday, perhaps)
Prime= "MON-TUE: 00:00-23:59; WED: -; THU-SUN: 00:00-23:59"
Note that the time specification for Prime= must always be surrounded by double quotes (""). Otherwise LISTSERV will stop reading the specification at the first space (ASCII 32) it encounters. For example, the above example coded without quotes would be interpreted as Prime= MON-FRI: with the balance of the string ignored. LISTSERV will not issue an error if you omit the quotes.
Note also that when you are coding a prime time specification that LISTSERV's week starts on Monday and runs through Sunday. Thus something like the following examples:
Prime= "MON-TUE: 00:00-23:59; WED: -; THU-SUN: 00:00-23:59"
Prime= "TUE: 01:00-4:59; THU-SUN: 00:00-23:59"
are correct syntax, whereas
Prime= "WED: -; THU-SUN: 00:00-23:59; MON-TUE: 00:00-23:59"
is not. Furthermore note carefully the weekdays must be specified in their correct order, that is,
Prime= "THU-FRI: 00:00-23:59; SAT-MON: 21:00-23:59"
is not correct because it starts on Thursday and ends on Monday The correct specification in this case would be
Prime= "MON: 21:00-23:59; THU-FRI: 00:00-23:59; SAT-SUN: 21:00-23:59"
IMPORTANT: When you set a "prime time" either for a list or globally for the entire server ("PRIMETIME=" in the site configuration file), you are setting the time during which LISTSERV does not process postings. It is "prime time" for the machine when it should be doing other things, for example, number crunching, daily backups, or any other function during which LISTSERV should not be using cycles.
Note also that the minutes specification is cosmetic only. LISTSERV checks on jobs held awaiting non-prime time only once each hour, on the hour. Thus if you have
* Prime= "MON-SUN: 06:00-21:00"
then jobs awaiting non-prime time will be executed at 22:00, not 21:00 as you might otherwise expect. On the other hand, if you code
* Prime= "MON-SUN: 06:00-20:xx"
where "xx" is any two-digit integer between 01 and 59, then jobs awaiting non-prime time will be executed when LISTSERV runs its hourly check of PRIME jobs at 21:00.
If you need to open only one short window during one or more days, you can do this by coding something like:
* Prime= "MON-FRI: 00:00-02:59 04:00-23:59; SAT-SUN: -"
This example allows LISTSERV to process mail for the list only between 2 AM and 4 AM Monday through Friday, and at any time on Saturday and Sunday. Note that there is no punctuation--just a space--between the time settings for a given day or day sequence.
Reply-To= List|Sender|Both|None|net-address,[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 discarded or omitted, what should be placed in the new "Reply-to:" generated by the server. The default value is "Reply-To= 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.
PLEASE NOTE CAREFULLY: Setting this parameter guarantees only one thing -- that LISTSERV will generate an appropriate RFC822 Reply-To: header in the mail it distributes to subscribers. THERE IS UNFORTUNATELY NO GUARANTEE THAT THE MAIL TRANSFER AGENT (MTA) OR MAIL CLIENT ON THE RECEIVING END WILL HONOR THE Reply-To: HEADER. This is because some mail clients, out-of-office robots, and Internet MTAs either simply do not recognize the existence of Reply-To: or do not implement it properly. Specifically RFC2076 "Common Internet Message Headers" reports that the use of Reply-To: is "controversial", that is, "The meaning and usage of this header is controversial, meaning that different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations." (RFC2076, page 4). While L-Soft recognizes that it is sometimes important to provide an explicit Reply-To: header to indicate a response path, L-Soft cannot be held responsible for problems arising from the inability of a remote server to properly process Reply-To: headers.
The two parameters are specified as follows:
First parameter:
|
List |
Replies are directed to the list address. |
|
Sender |
Replies are directed to the original sender. |
|
Both |
Reply to both the original sender and to the list (see note regarding this above) |
|
None |
No Reply-to: header is generated unless ",Respect" is specified and a Reply-to: header is present in the original posting, in which case replies are directed to wherever the Reply-To: tag points. |
|
net-address |
Replies are directed to the specified internet address |
Second parameter:
|
Respect |
The original "Reply to:" tag on the posting, if any, is kept. If no valid Reply To: tag exists in the posting, the value defined in the first parameter of this keyword is used. |
|
Ignore |
The original "Reply to:" tag on the posting, if any, is ignored and discarded, and the value defined in the first parameter of this keyword is used instead. If Reply To= None,Ignore, then a Reply to: tag will never be generated by LISTSERV. |
Sender= "list title <net-address>",ietf-address
This keyword is not available in LISTSERV Lite.
NOTE CAREFULLY: Setting this value DOES NOT change the RFC822 "From:" header. Per standard, LISTSERV is not allowed to change the From: header, but must pass it through unchanged.
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 non-IETF 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 "owner-listname" mailbox is substituted. Example:
* Sender= "Test List <TEST@LISTSERV.X.EDU>",owner-test@listserv.x.edu
Note that the first address must be contained in quotes.
Sub-lists= sublist1,sublist2...sublistn
This feature and keyword are not available in LISTSERV Lite.
This keyword first appeared in 1.8c and makes it possible to define a "super-list" (as in opposite of sub-list), that is, a "container" list that includes all the subscribers in a predefined set of sub-lists. This can be done recursively to any depth. Only the maintainer can create a super-list, for security reasons. Concretely, the "Sub-lists=" keyword is protected from owner tampering in the same fashion as "Notebook=". The value is a comma separated list of all the sub-lists, which must all be on the same (local) machine. For instance:
* Sub-lists= MYLIST-L,MYOTHERLIST-L
or (if you want to put each sublist on a separate line):
* Sub-lists= MYLIST-L
* Sub-lists= MYOTHERLIST-L
The default value for this keyword is null, that is, to have no sublists. Please note that the super-list and all of its sublists must reside on the same LISTSERV server.
The only difference between a normal list and a super-list is what happens when you post to it. With the super-list, the membership of all the sub-lists is added (recursively) and duplicates are suppressed. Other than that, the super-list is a normal list with its own archives, access control, etc. You can even subscribe to it, and this is actually an important aspect of the operation of super-lists. If you are subscribed to the super-list itself, the subscription options used to deliver super-messages to you are taken from your subscription to the super-list, just like with any other list. All combinations are allowed, and in particular NOMAIL is allowed, meaning you don't want to get messages posted to the super-list. When you are subscribed to multiple sub-lists, on the other hand, things work differently:
1. NOMAIL subscriptions are ignored. You will get the super-message if you have an active (not NOMAIL) subscription to at least one sub-list. The idea is that the super-message must be equivalent to posting to all the sub-lists, without the duplicates. Since all it takes to get a message posted to all the sub-lists is a single non-NOMAIL subscription, this is how the super-list works. The only way not to get the super-messages is to subscribe to the super-list directly and set yourself to NOMAIL.
2. The DIGEST and INDEX options are ignored and internally converted to MAIL. The first reason is that, since in most cases the user will be on multiple sub-lists (otherwise you don't need a super-list in the first place), the only safe method to set subscription options for super-messages is by subscribing to the super-list so that there is no ambiguity. The second reason is that, in most cases, super-lists will be used for out of band administrative messages rather than for large volume discussions, so it is actually preferable to have the message sent directly. The third reason is that the super-list and sub-lists may not necessarily offer the same options (DIGEST and INDEX). In particular it is expected that many super-lists will not have archives. If you want a DIGEST or INDEX for the super-messages, you must subscribe to the super-list directly.
3. In LISTSERV 1.8c and 1.8d, the REPRO option is NOT inherited by sub-lists. That is to say, even if the sub-list subscriber is set to REPRO on the sub-list AND the super-list is set up such that sub-list subscribers may post directly to it, he will NOT receive a copy of his own posting. REPRO is effective only for users who are directly subscribed to the super-list. This restriction has been removed in LISTSERV 1.8e.
Topics, if defined, are evaluated on a per-list basis. That is, for every sub-list (and for the super-list), LISTSERV determines whether the topic of the message is one that you want to see. If not, it acts as if you were not subscribed to this particular list. Roughly speaking, this works very well if all the sub-lists have the same set of topics (or a well-defined set of common topics), and doesn't work well at all if every list has its own set of topics.
Topics= topic1,topic2,...topic23
This feature and keyword are not available in LISTSERV Lite.
List topics provide a way to run a mailing list (preferably moderated) where several sub-topics 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 23 topics for the list (note that 1.8c and earlier are limited to 11 topics). For instance, the list owner could code:
* Topics= News,Benchmarks,Meetings,Beta-tests
If necessary, you may use multiple Topics= lines in your header in order to fit all of your topics in.
WARNING - YOU MUST NEVER REORDER THE TOPICS= KEYWORD(S)
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 "Beta-tests" 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:
* Topics= News,Benchmarks,,Beta-tests
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 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 "Beta-tests" 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:
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 XYZ-L TOPICS: NEWS BENCH', the user will receive news and benchmarks, and nothing else.
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 XYZ-L TOPICS: +NEWS -BENCH' adds news and removes benchmarks. If a topic name is given without a + or - sign, + is assumed: 'SET XYZ-L 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 XYZ-L TOPICS: ALL -MEETINGS'.
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 Default-Topics.)
Yes,Semi-Auto[,Delay(number)][,Max(number)][,Probe(number)]
Yes,Full-Auto[,Delay(number)][,Max(number)][,Probe(number)]
Yes,Manual[,Delay(number)][,Max(number)][,Probe(number)]
This keyword is available in LISTSERV Lite, but is not full-featured. The behavior in LISTSERV Lite with Auto-Delete= Yes is Auto-Delete= Yes,Semi-Auto,Delay(0),Max(1). Any other settings are ignored. Specifically the passive probing option available in Classic is disabled in Lite.
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 "Auto-Delete=" list header keyword. The unix versions of LISTSERV also support sendmail’s delivery error format. The auto-deletion code is also fully compatible with RFC1893 "Notary" format error codes
If the list has been coded "Auto-Delete= 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 whenever the auto-deletion feature is enabled:
When auto-deletion is set to "Full-Auto" or "Semi-Auto":
· LISTSERV 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.
· If 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 passes the actual error message to the list owner for further disposition if running in semi-auto mode. If running in full-auto mode, the error messages themselves are discarded and the errors only show up as entries in the daily auto-deletion monitoring report.
· When running in full-auto 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). Full-auto mode should be used only when the list owner positively does not have the time to handle the delivery errors LISTSERV sends every day.
When auto-deletion is set to "Manual":
· When running in manual mode, the auto-delete monitor informs the list owner of the error(s) and takes no further action on delivery errors.
Some considerations for configuring the auto-delete monitor parameters:
· Setting 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, but will delete on the first bounce.
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 2-3 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.
· Setting the Max(number) option. To prevent auto-deletion monitoring from getting out of hand, subscribers are deleted after a specified number of 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. Note that if Delay(0), the setting for Max() is ignored (in effect it is set to Max(1)).
· Setting the Probe(number) option. This parameter tunes the "passive probing" option (beginning with 1.8d). Passive probing operates by turning a certain percentage of your regular list messages into transparent probes that look like a normal message but also double as a probe, rather than sending out the explicit PROBE1 template as in active probing. You enable (or tune) passive probing by adding a ",Probe(xx)" parameter to the Auto-Delete= keyword setting. For instance,
Auto-Delete= Yes,Full-Auto,Probe(30)
where "30" is the number of days to wait between probes for any given user. Subscribers with working mail systems will not see any difference, subscribers with flaky mail systems will occasionally receive a message showing that their mail bounced and saying that they should report the problem to their ISP, and of course plain bad addresses will go away.
In order to disable passive probing you set the probe parameter to 0, i.e.,
Auto-Delete= Yes,Full-Auto,Probe(0)
If you have users who for whatever reason should not be probed, you can deactivate passive probing (and any other renewal you have set for the list) with the SET userid@host NORENEW command. The default for this parameter is Probe(30) for lists up to ~2K subscribers, and Probe(0) for larger lists (because by its nature, probing can be a non-inconsiderable performance hit).
For more information on passive probes, see chapter 13.5.2 of the Site Manager's Operations Manual.
· When you take a vacation, note that it is best to switch auto-delete 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 Full-Auto or Semi-Auto, 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.
The default value is "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)" for lists coded "Validate= No" and "Auto-Delete= No" for all other lists.
Note that if you have coded "Delay(0)" and/or "Max(0)", LISTSERV simply deletes any error-generating subscriber it can (generally 95-98%), discards any further errors it does not understand, and does not generate daily monitoring reports. If you want the daily monitoring reports you must code at least "Delay(1),Max(1)".
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 'Owners'.
In LISTSERV 1.8e and following, the internet address of the list is explicitly disallowed as an error-receiving address, and attempting to set Errors-To= to the internet address of the list will raise an error. The list should never be configuired to receive its own errors as this is guaranteed to cause looping.
It should be carefully noted that there is no way to automatically discard errors without sending them to some address. "Errors-To= No" and "Errors-To= None" are both invalid settings and will cause LISTSERV to revert to the default.
Loopcheck= Normal
Loopcheck= None[,Allow-Bounces]
Loopcheck= option1[,option2][,optionn]
This keyword is not available in LISTSERV Lite.
Determines the type of loop checking performed by LISTSERV to avoid perpetuating mail loops. The default is "Loopcheck= Full" prior to LISTSERV 14.5, and "Loopcheck= Normal" starting with LISTSERV 14.5. Loop checking is configured on a list by list basis only.
ALWAYS USE THIS KEYWORD WITH CAUTION!
Misuse of this keyword can and will allow mailing loops onto your list!
The various Loopcheck= parameters are defined as follows. "Normal", "Full" and "None" must be specified alone (except in the special "None,Allow-Bounces" case, and except for "Spam-Delay(n)"), whereas the other options may be specified together as required.
|
Normal |
LISTSERV uses its "normal" suite of loop checking heuristics. Tests considered to be obsolete are not conducted. This is the default for Loopcheck= beginning with LISTSERV 14.5. See the LISTSERV 14.5 release notes for more details. |
|
Full |
LISTSERV uses its full suite of loop checking heuristics to check incoming mail for loops. This includes tests considered to be obsolete. |
|
None |
All LISTSERV loop checking and "command to list" checking is disabled for this list. WARNING: "None" tells LISTSERV that, by definition, anything that reaches its reader is NOT a delivery error. It is never a good idea to use this parameter except in special cases where a bug is suspected in the loop checking heuristics. Generally this parameter should not be used without checking with L-Soft first, and only for the diagnosis of an existing problem. |
|
None,Allow-Bounces |
From LISTSERV 14.2 (1.8e-2003a), allows the list to accept error messages that would normally be bounced to the list owner. This makes it possible to direct the Errors-To= keyword setting to a LISTSERV list rather than to a specific person. "Allow-Bounces" MUST be specified in conjunction with "None". Specifying just "Loopcheck= Allow-Bounces" will result in a syntax error when the list header is stored. |
|
Noorigin |
Allows the list owner to disable the check for "known mailer origins" such as MAILER, POSTMASTER, ROOT, UUCP, et al. Mail whose 'From:' field is the address of the local mailer is still trapped, but wildcard checks on the mail origin are disabled. |
|
Nobody |
Allows the list owner to disable the check for identical text in the body of incoming mail only. LISTSERV relies only on the Subject: field of the mail message to determine whether or not mail is looping. This is a very dangerous option: it means that any mailer not using one of the "standard" subjects known to LISTSERV will cause a loop. |
|
NoCRC |
Allows the list owner to disable CRC (cyclical redundancy check) check of incoming mail. CRC loop checking calculates a "checksum" based on the contents of the mail message and compares it to other incoming mail to spot duplicates. |
|
NoSpam |
Allows the list owner to disable the anti-spamming filters to incoming mail. |
|
Spam-Delay(n) |
Allows the list owner to modify the number of minutes LISTSERV holds mail from non-subscribers before releasing it to the list. The assumption is that, within n minutes, a spam alert may or may not arrive regarding non-subscriber mail. The list owner can disable this function for his list by coding "Loopcheck= Spam-Delay(0)", or can tune it to his preference by simply specifying the number of minutes for LISTSERV to hold the mail. The default is 10 minutes, or "Spam-Delay(10)". |
Please note carefully that L-Soft does not recommend changing Loopcheck= from the default value unless you are prepared to accept the very likely possibility of a mail loop occuring on your list; a situation for which L-Soft would not and could not be held responsible for. The only exception would be the "Loopcheck= NoSpam" (which might be necessary to keep adminstrative mail to multiple lists on a single host from triggering the anti-spamming filter) or "Loopcheck= Spam-Delay(n)" options, neither of which stops canonical mail loops per se.
The list header keyword, "Safe=", controls the e-mail address LISTSERV places in the SMTP MAIL FROM: field, which is where well-behaved 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 'owner-listname', 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 'owner-listname' mailbox. Unfortunately, there are many non-compliant mailers which will continue to send the error back to the list (usually because it is listed in the 'Reply-To:' or 'Sender:' field). Using "Safe= Yes" 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.
See also Filter= and Loopcheck=.
List Maintenance and Moderation Keywords
Configuration-Owner= conf_owner[, conf_owner2][,...]
This feature and keyword are not available in LISTSERV Lite, and can only be set by the LISTSERV maintainer.
This new (optional) keyword defines which of the list owners defined in the Owner= keyword setting are authorized to change the list configuration. It is a LISTSERV ACL, much like "Review=", or "Send=" (if you disregard the special options that are specific to "Send="). The default value is "Configuration-Owner= Owner", which allows all addresses and access-levels listed in Owner= to modify the list header.
Note carefully that list owners who are not Configuration-Owners retain the right to change templates, add and delete users, change user options, GET and PUT archive files, and so forth. The setting of Configuration-Owner for a given list restricts only the ability of non-Configuration-Owners to change the list header.
The definition of a conf_owner is a sub-set of access_level. Valid conf_owners are
Owner
Postmaster
net-address (for instance, user@host.com)
Owner(listname)
(listname)
Examples:
Configuration-Owner= Postmaster,(configownerlist)
Configuration-Owner= Owner,Owner(otherlist),joe@example.com
Configuration-Owner= (configownerlist)
Configuration-Owner= sarah@example.com,joe@example.com
The purpose of this keyword is to make it easier for LISTSERV administrators to manage non-technical list owners. It allows the LISTSERV maintainer to create a list where the owner can manage subscriptions normally, but cannot make changes to the list configuration.
It is also possible with this keyword to create a separate mailing list of LISTSERV users who do not have full LISTSERV maintainer privileges, but can manage lists other than those they might own explicitly on the same server.
Please note carefully that any addresses specified in Configuration-Owner= must also be specified (either explicitly or as part of an access-level definition) in the Owner= setting for the list.
Editor= net-address1,net-address2|access-level1,...
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., someuser@foo.bar.com) and not an access-level. Subsequent editors may be access-levels. For instance, you can code
* Editor= joe@baz.net,(MYLIST-L)
which allows all subscribers from the MYLIST-L list to post without going through the editor, and diverts all non-subscriber mail to joe@baz.net for approval.
IMPORTANT NOTE: The first editor SHOULD 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 L-Soft international, Inc., could not be held responsible.
ALSO PLEASE NOTE: In many support cases it has been noted that lists are often coded with "Editor= Owner" or "Editor= Owners". Prior to LISTSERV 14.3, this would have caused LISTSERV to generate approval request messages to an address such as OWNER@.BITNET, which of course would not be deliverable. LISTSERV 14.3 and later will now avoid this problem and when encountering either of these cases will default to sending the approval request to the first listed non-quiet list owner. L-Soft continues to recommend NOT using either "Owner" or "Owners" as the primary editor of the list, as it is not always the case that the list owner should be the primary (or only) editor.
Finally, please note that the NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
This keyword is not available in LISTSERV Lite.
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 "Editor-Header= Yes".
Note that Editor-Header= No is ignored if you have Send= Editor,Hold or Send= Editor,Hold,Confirm . In these cases the editor-header information is required so as to provide the confirmation code for the OK command.
List-Address= name_info[@host_info]
This keyword is not available in LISTSERV Lite.
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 "List-Address=" or LIST_ADDRESS are defined) are long list name and Internet address. A corresponding LIST_ADDRESS configuration option must be added to the LISTSERV site configuration file.
It is important to note that the only effect of the "List-Address=" keyword is to change the way the list identifies itself in list postings, command replies, etc. It does not instruct the mail system to create forwarding entries to support the new name, nor does it establish the specified name as an alias for the list (use "List-ID=" for this purpose). In general list owners should not use this keyword without first consulting with the LISTSERV maintainer.
In 1.8b and earlier versions, the first token (name_info) can be either LISTNAME or LIST-ID. Do not attempt to specify the actual list name. Use LISTNAME if you want LISTSERV to use the "short" list name (always available), and LIST-ID if you would rather see the "long" list name ("List-ID=" keyword). If there is no "long" name, the short name is substituted.
Version 1.8c introduced the ability to specify the name of the list in the first token (i.e., you may now specify something like "List-Address= XYZ-L@XYZ.EDU").
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 "List-Address= XYZ.EDU" in the list header and let the left-hand part default from the value of the system default in the LISTSERV configuation file. Similarly, "List-Address= List-ID" takes the right-hand 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:
"List-Address= FQDN" announces the list under the Internet address for the LISTSERV host, if one is available (for BITNET-only sites this setting has no effect).
"List-Address= List-ID@FQDN" uses the long list name and the Internet hostname.
"List-Address= Listname@XYZ.EDU" uses the short list name and the hostname XYZ.EDU.
Starting with version 1.8c, "List-Address= XYZ-L@XYZ.EDU" is also valid. You no longer are restricted to specifying LISTNAME or LIST-ID for the left-hand (username) part.
This keyword is not available in LISTSERV Lite, and is technically obsolete on all ports of the software except for VM.
On VM systems, this keyword allows the list owner to specify a long list ID in addition to the normal 8-character list name. This is particularly useful for peered or gatewayed lists that have names longer than 8 characters. On non-VM 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 8-character name can continue to use it on the new system.
Non-VM systems may use this keyword for aliasing. However, today there is really no good reason to use this keyword on non-VM systems, as it is possible to define lists on such systems with native file system names longer than 8 characters. L-Soft's recommendation is that this keyword be used only if you are migrating a list from VM that was known by both its "short" name and its "long" List-ID= name. (On unix you can avoid this by simply specifying an extra set of aliases in /etc/aliases for the "long" name that point to the same places as do the ones for the "short" name.)
In any case a list owner should not set a value for List-ID= without first consulting with the LISTSERV maintainer, since it will be necessary to add appropriate system mailer aliases before the name specified in List-ID= will work.
List-ID= will not work properly on NT systems running with the SMTPL "listener" because the "listener" has no way to know that the list ID specified in this parameter is a valid local address.
List-ID= will work on NT and VMS systems running LSMTP, but you must first configure a route in LSMTP for the List-ID= name so that LSMTP will know to deliver mail addressed to the List-ID= address to LISTSERV (as opposed to POP or SMTP, etc.).
Under VMS and unix, it is necessary to add the appropriate aliases to the mailer's aliases file in order for List-ID= to work, since mailers such as sendmail and PMDF otherwise have no way to know that the name specified in List-ID= is a valid address. This means that lists that have the List-ID= keyword specified need two complete sets of aliases defined (unless List-ID= is identical to the list name, in which case it should not be implemented to begin with).
Starting with LISTSERV 1.8d, if you do use List-ID= to specify a "long" name for a list with web archives, LISTSERV will create an HTML page for both the long and short names. Here again, however, on non-VM systems L-Soft does not recommend the use of List-ID= .
Moderator= [All,]netaddress1[,netaddress2]...
This keyword is not available in LISTSERV Lite.
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 non-editors forwarded to them.
Beginning with 1.8c, if the parameter "All" is coded before the list of moderator addresses, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be
* Moderator= All,joe@somehost.com,jill@someplace.net
Note that this could also be coded as:
* Moderator= All,joe@somehost.com
* Moderator= jill@someplace.net
Assuming "Send= Editor,Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that an identical message has already been posted to the list.
If "Send= Editor" (i.e., without "Hold"), please note that if a note is appended or prepended to the edited post, or if the body of the post itself is edited (that is to say, if the body of the approved message is changed), duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator.
Finally, please note that the NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
This keyword is not available in LISTSERV Lite.
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.
Note that success in setting the "New-List=" keyword is dependent on whether or not you have deleted practically every other keyword other than "Owner=" from the list header. Since the use of "New-List=" is intended to be an automatic pointer to the new host and/or new list name, no other keywords should be defined. Keywords that would cause a problem will therefore generate fatal errors on a list PUT operation and the list header will not be updated.
Further note that the old list’s subscriber list cannot be modified once the "New-List=" parameter is defined. The appropriate sequence of operations is:
1. Create the new list
2. Move the subscribers to it
3. DELETE oldlistname *@*
4. Modify the header of the old list by deleting unneeded keywords and adding the "New-List=" keyword with its pointer to the new list.
Should this sequence not be followed, note that by removing the "New-List=" keyword, the old list will be unlocked and the subscriber list can then be deleted if desired.
Notebook= Yes,where,interval|Separate,access-level[,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".
where is the filemode of the minidisk (VM) or the disk and directory (non-VM) on which the notebook is to be kept. The default value of "A" is equivalent to LISTSERV's main working directory. On VM servers, this is LISTSERV's A disk; on VMS and Windows servers, this is LISTSERV's MAIN directory, and on Unix servers it is ~listserv/home (or whatever value has been used in the Makefile for $LSVROOT/home). Naturally, you may change this value to any directory you wish, provided that a) the directory exists (for security reasons, LISTSERV will not make it for you) and b) LISTSERV has read-write access to that directory. Rather than use the "A" directory, L-Soft strongly recommends that you create a separate directory structure with subdirectories for each list and use a full path spec for this parameter. This is important for security purposes related to the file server functions (see chapter 8 for details).
Note that under unix this parameter MUST IMPERATIVELY point to a directory specification that is all lower-case. LISTSERV for unix cannot write archives to directories named in upper- or mixed-case.
If your server is running the Web Archive Interface, L-Soft does not recommend that this parameter be pointed to the web archive index directory.
interval Defines 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):
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 "yy-nnnnn" (sequential counter).
While you may change the notebook interval at any time, LISTSERV will not convert existing notebooks into the new interval format. For instance, if you convert from Monthly to Weekly notebooks, LISTSERV will continue to maintain your original notebooks in their monthly format, while writing any new postings into weekly notebooks. This is perfectly normal and does not affect the proper operation of your list (in particular it does not cause any breakage to the archive search feature).
For servers with the WWW archive interface interface installed, please note that in order for archives to appear in the interface, the following requirements must be met:
1. Notebooks can be "Public" or "Private" (or any other access-level)
2. The notebook interval must be "Monthly", "Weekly", or "Yearly" ("Yearly" is not recommended).
3. The "Confidential=" keyword must be set either to "No" or "Service"
4. The LISTSERV maintainer must create an index directory for your list per the instructions in the Site Manager’s Operations Manual.
See chapter 5.4.6 of the Site Manager’s Operations Manual for further details.
Note: Notebooks may be retrieved by means of the GET command. On VM only, a list of all available notebooks can be obtained with a GET NOTEBOOK FILELIST command.
The first two parameters of the "Notebook=" keyword may only be changed by the LISTSERV postmaster.
If necessary, you may break the "Notebook=" keyword into multiple lines in order to avoid running up against the 100-character header line limit. For instance
* Notebook= Yes,/home/listserv/lists/mylist-l,Monthly,Private
is strictly equivalent to
* Notebook= Yes
* Notebook= /home/listserv/lists/mylist-l
* Notebook= Monthly,Private
This can be particularly important if it is necessary to specify multiple access-levels for the notebooks (for instance if you have many sub-lists and want the subscribers to the sub-lists to be able to access the super-list's notebooks), for example,
* Notebook= Yes,C:\LISTS\SUPER,Monthly,Private,(SUB-A),(SUB-B)
* Notebook= (SUB-C),(SUB-D),(SUB-E),(SUB-F)
Determines whether or not individual message in notebook archives are stored with full Internet header information or with "short" headers. The default is "Notebook-Header= Short".
Notify= Yes | No | mon-address
Defines whether the list owner (or the person indicated by "Notify= mon-address") is to receive notification of new subscriptions and deletions, etc. The default is "Notify= Yes", meaning that non-quiet list owners will be notified.
Owner= net-address1 | mon-address1,[Quiet:,]net-address2 | mon-address2,...
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.
The use of the "Quiet:" parameter causes all subsequently-defined list owners to be excluded from receiving any delivery error messages or other administrative mail from LISTSERV.
List owners may be defined on a single line or on multiple lines. See Chapter 2.7 of the List Owner’s Manual for details.
This keyword is not available in LISTSERV Lite.
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 commands to determine the "nearest" peer list to a given user. For example, when aSUBSCRIBEcommand 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. Note that peers must have the same PW= keyword setting.
Renewal= interval1,interval2...,intervalx,Delay(number)[,Probe]
This keyword is not available in LISTSERV Lite.
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:
Monthly, Yearly, Weekly, or a numeric variation such as 3-Monthly (meaning, quarterly). Note also that 1.8c introduces the ability to code "Renewal= xx-Daily", for instance, "Renewal= 15-Daily". While the use of intervals of less than a week is and remains inadvisable, FAQ templates with rotating topics may require the selection of a very precise renewal interval (for congruence purposes), which was not possible with "xx-Weekly" granularity. Please refer to chapter 9.9 of either the list owner’s manual or the site manager’s manual for a discussion of rotating FAQ support.
An absolute date in the format yyyy/mm/dd (once on this specific day), or the format mm/dd (once yearly on this month/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.
A typical Renewal= configuration might be:
* Renewal= 6-Monthly,Delay(14)
Conceivably Renewal= could also be set to something like:
* Renewal= 6-Monthly,1998/07/04,12/25,Delay(14)
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 1998, and a request every year on Christmas Day. Note that this is provided ONLY as an example. L-Soft does not recommend using a renewal scheme of this sort.
Note: When setting up Renewal= for the first time on an older, established list, you may find that a substantial number of subscribers are prompted for confirmation immediately even though you may have set Renewal= to a value that might not be expected to cause such behavior. This is because LISTSERV uses the last activity date (which may or may not be the same as the subscription anniversary date) for the purpose of subscription renewal. The last activity date may be one of the following: The subscription anniversary date; the last date the subscriber posted to the list; or the last date the subscriber changed personal options.
Note also that if you code a specific date without specifying a year field (e.g., Renewal= 6/1), LISTSERV will immediately request a renewal from any subscriber whose last activity date is prior to that date in the current year.
The "Probe" parameter, introduced in Version 1.8c (but disabled in LISTSERV Lite) activates LISTSERV's "active probing" bounce processing feature, whereby the users are "probed" regularly using the PROBE1 mail template. The desired response from the user is to discard the message and do nothing. If the probe bounces, LISTSERV first sends the PROBE2 template with a copy of the bounce (assuming that the address actually works regardless of the bounce), and then schedules a new probe for the next day or deletes the user immediately, depending on the list's "Auto-Delete=" policy. For more information see chapter 4.6 of the list owner's manual.
Subscription renewal is disabled by default. To turn it off for a specific list, simply remove the "Renewal=" keyword from the list header.
See also Auto-Delete=.
Sizelim= number | numberK | numberM
This keyword is not available in LISTSERV Lite.
If set, causes LISTSERV to reject all messages to the list which exceed the number of lines (including all Internet header 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.)
List owners alternately may specify a maximum message size in either kilobytes or megabytes, rather than in lines, if preferred. For instance:
Sizelim= 100K Reject messages over 100Kbytes
Sizelim= 1M Reject messages over 1Mbyte
As before, the limit operates against the entire message file, including all Internet header lines.
LISTSERV 1.8c and higher supports "subject tags", i.e., the ability to insert a predefined text tag into the subject line of mail coming from a list. For instance, your subscribers might want the subject lines of mail coming from your list to contain the name of your mailing list. Whereas the RFC822 subject line of a typical list posting without a "subject tag" would look like this:
Subject: I think ID4 is a great movie, don't you?
if you were to define
* Subject-Tag= SCI-FI
the subject would look like this for all users who are set to the new "SUBJheader" personal option:
Subject: [SCI-FI] I think ID4 is a great movie, don't you?
Note that this option may be toggled on and off by the user by use of the new "SET listname SUBJecthdr" option. It is turned off by default.
The normal default for "Subject-Tag=" is the name of the list, for example, SCIFI-L. If "List-Address=" is defined for your list, the default is either the name of the list or the list ID, whichever is listed in "List-Address=". A subject tag can be only a single word; in other words, you cannot define a sentence to be used as a subject tag.
Starting with LISTSERV 1.8d, if a user sends a message with a blank RFC822 "Subject:" header, LISTSERV will create a "Subject:" header and place the subject tag into it (but only for subscribers with the SUBJecthdr option set.) Under 1.8c, subject tags worked only when posters defined a subject for their message.
Setting this keyword does not automatically reset users to the SUBJecthdr option. This must be done manually for existing users and may be specified by default for new subscribers by use of the Default-Options= keyword.
This keyword is not available in LISTSERV Lite.
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, for example, "Comment: X-To:" and "Comment: X-cc:".
No: This information must not appear at all in the mail header.
Change-Log= No |Yes[,Yearly|Monthly|Weekly|Daily|Single]
This keyword is not available in LISTSERV Lite.
When set to YES, causes LISTSERV to write a listname.CHANGELOG file (listname CHANGLG on VM) in the "A" disk or directory which contains information about all changes made to individual subscriptions. Commands tracked include SUBscribe/JOIN, SIGNOFF/UNSUBscribe, auto-deletions, and all changes to users' personal options. A CHANGELOG file can be retrieved by list owners and site maintainers with the GET command and deleted with the PUT command like any other file (it is not necessary to make catalog entries for CHANGELOG files).
In 1.8d, change-logs could be only enabled or disabled. There was no facility to rotate change-logs at all, so once enabled, a change-log simply kept growing until it was deleted. Since it can grow quite large, it was recommended that this option be enabled under 1.8d only if the list owner(s) kept it pruned on a regular basis. Alternately the option could be enabled for problem resolution, and disabled after debugging.
Non-VM LISTSERV 1.8e and later has an enhanced Change-Log= list header keyword that allows list owners to rotate change-logs along the same lines as they rotate list notebook logs.
Rotated logs are renamed to listname.CHANGELOG-yyyy[mm[dd|w]] and can be retrieved as usual with the GET command, which was changed to recognize these as change-logs.
When the feature is introduced (ie when upgrading to 1.8e or later), old logs will be renamed based on the date in the last entry. If the last entry is compatible with the newly introduced period (eg logs are YEARLY and the last entry is 2001), the log will continue, even if there were also entries for 2000. The definition of the 2001 log is that it contains all the entries for 2001, not that it is the first log started in 2001. Logs are not split as the feature is introduced.
If the rename fails (eg because you keep changing the period back and forth), the current log continues.
While LISTSERV on VM will accept all of the above settings without complaint, everything will behave as if you had specified SINGLE. This is because filetypes are limited to 8 characters on VM and it would be difficult to support a different naming convention just for VM.
The default is "Change-Log= No". For backward compatibility, "Change-Log= Yes" is equivalent to "Change-Log= Yes,Single".
Confidential= No | Yes | Service
Indicates whether the list should be hidden from users or not. A confidential list will not appear on the "Lists" command output. "Confidential= No" is the default value and indicates that the list is not confidential. "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. "Confidential= Yes" means that the list is unconditionally confidential.
Please note that in LISTSERV 1.8c and following, the local list of (public) lists can be retrieved only by those users who are considered local, per the setting of the server-wide LOCAL= variable in LISTSERV's site configuration file. All other users will be told that none of the lists on the server are visible via the LISTS command, and will be referred to the use of the LISTS GLOBAL search-text command or to the CataList. This is regardless of the setting of Confidential= as outlined below.
This feature and keyword are not available in LISTSERV Lite.
Background for non-technical 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 ABC-L 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.
LISTSERV version 1.8a and higher support list "exits". List "exits" allow you 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 site 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.
This keyword is not available in LISTSERV Lite.
Defines the nodes which are to be considered as 'local nodes' for service area checking. The LISTSERV machine 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, "SEARN" and "SEARN.SUNET.SE" are both valid node names.
By default, this keyword takes its value from the LOCAL variable in LISTSERV's site configuration file.
(Obsolete since version 1.8c [except for peered lists]; included for backwards compatibility)
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.
LISTSERV version 1.8c and higher generate a 16-character random password for lists at list creation time if this keyword is not explicitly defined, making such lists more secure from random hackers. List owners are now encouraged to use personal passwords (defined with the PW ADD command, q.q.v.) in preference to list passwords for this reason.
The one exception to this keyword's obsolescence is when you are creating peer lists. Peers must have the same PW= setting, so you cannot use the LISTSERV-generated random password when creating peers.
This keyword is not available in LISTSERV Lite.
Defines the 'service area' outside of which subscription requests must not be accepted. When a SUBSCRIBE command is received, the "Peers=" keyword (if set) is checked first to see if there is a nearer peer list in the network. If this is the case, the command is forwarded to this nearer peer 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 to a peer, the destination peer 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, for example "Service= Germany", and still have users subscribed to the best possible server.
For lists running the web archive interface: Starting with LISTSERV 1.8d it is possible to define "Service=" in terms of IP address blocks in order to limit access to list archive notebooks via the web archive interface. This is implemented as follows:
1. Notebook= ...,Service
2. "Service=" can contain entries of the form:
[^]IP(a.b.c.d[/e])
3. For any other keyword (call it "xxx") in "Service=" which contains neither period, wildcard nor parentheses, if a site configuration variable called IP_xxx is defined, it is processed using the syntax in #2, except that the IP() is implicit, i.e., the syntax would be (for unix; no quotes for NT as usual):
IP_MYNETWORK="192.36.125.0/24 ^192.36.125.199"
The corresponding setting in "Service=" would then be something like
Service= example.com,*.example.com,MYNETWORK
("IP_" must not be specified in "Service=". LISTSERV understands that when you specify "Service= MYNETWORK", you mean for it to look at the value set in the IP_MYNETWORK site configuration variable.)
If both #2 and #3 are present, they are combined. Likewise, you can have multiple occurrences of #2 or #3 and they will just be combined.
Access will be granted if the IP address matches at least one of the entries that do not begin with a ^ (you can also use a minus sign if you prefer) AND the IP address does not match any of the negative entries. Otherwise you get a normal login request without any further comment.
Note carefully that LISTSERV does not do a reverse lookup on the IP addresses you code into the Service= keyword! When coding IPs into Service= you must also code in FQDN values for allowed hostnames. Thus if you have a list that should be restricted to the 192.36.0.0/16 subnet, which belongs to a domain called FOO.COM, you really have to code something like
* Service= FOO.COM,*.FOO.COM,IP(192.36.0.0/16)
in order for everyone in the FOO.COM domain who needs access to be able to have it.
The default value is "Service= *" (e.g., any host).
Validate= No | Yes[,Confirm[,NoPW]] | All,Confirm[,NoPW]]
The Validate= keyword determines what level of validation (if any) is performed for various LISTSERV commands that apply to individual lists. There are six different settings ranging from very basic to very strict. The two most common settings are (arguably) "Validate= No" and "Validate= Yes".
Lists are protected from hackers at the most basic level by the fact that a list PUT operation always requires validation, regardless of the setting of the Validate= keyword. In other words, the list owner or LISTSERV postmaster must always use a personal password (set with the PW ADD command, q.q.v.) when he sends an updated version either of the list header or of the entire list back to the server, even if "Validate= No". This is to protect you from network hackers who might issue a command "from" your userid@host address to change list settings, such as who has the ability to GET and PUT the list, review concealed subscribers, etc. The default for this keyword is "Validate= No", but it is recommended that "serious" or "important" lists be changed to at least "Validate= Yes".
When "Validate= Yes", password validation applies to so-called "protected" commands (all of the commands that modify the contents of the list, for example ADD, DELETE, SIGNOFF, etc.--but not SUBscribe or SET). This implies that hackers cannot use these "protected" commands since they do not know the list owner's or LISTSERV postmaster's personal password. While at first glance this would also seem to mean that legitimate subscribers cannot use the SIGNOFF command, that is not the case, because for lists operating with "Validate= Yes" (i.e., 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 from legitimate subscribers and DELETE requests from registered node administrators (NADs) 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.
A notable exception to the list of "protected" commands is the SUBscribe command, which can still be used (if enabled, for example, if "Subscription= Open") to get on the list; however, when "Validate= Yes", sending a second SUBscribe command for the same list (for instance, to correct a spelling error in your name) would result in the command being forwarded to the list owner and not immediately executed. Also note that the SET command used to set various personal subscription options is not a "protected" command and may be issued without need for validation even when "Validate= Yes".
A rundown of the six different settings and what they mean follows:
"Validate= No": all commands except PUT are taken at face value with no validation. While users are not bothered with validation requests, the list is almost totally unprotected from attacks by hackers. For compatibility reasons, this is the default setting.
"Validate= Yes": "protected" commands, such as DELETE or ADD, require password validation. For list owner commands, personal passwords set with the PW ADD command 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. Other "protected" commands include GET, but do not include SUB or SET.
"Validate= Yes,Confirm": protected commands are validated using the "OK" mechanism by default, although personal passwords are also accepted where appropriate. This is a good compromise between list security and list owner convenience.
"Validate= Yes,Confirm,NoPW": protected commands are always 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. Note that lists with this setting cannot be managed via the Web Management Interface.
"Validate= All,Confirm": all commands causing a change in state, except the PUT command (which is always password-validated), are validated using the "OK" mechanism by default, although personal passwords are also accepted where appropriate. "Protected" commands (see above) are included in the class of commands that cause a change of state. Non-"protected" commands that cause a change in state include SUB and SET.
· "Validate= All,Confirm,NoPW": all commands causing a change in state (except PUT, as noted above) are always validated using the "OK" mechanism; passwords are not accepted, as with "Validate= Yes,Confirm,NoPW". Note that lists with this setting cannot be managed via the Web Management Interface.
Warning regarding obsolete values: Under Revised LISTSERV (that is, LISTSERV for VM prior to version 1.8a), "Validate= All commands" (or "Validate= All") and "Validate= Store only" (or "Validate= Store") were the only acceptable values for this keyword. These old values are still accepted for compatibility reasons, but generate a warning with an explanatory message when you update the list header. Since these values are obsolete and may not be supported in the future, you should change any instance of these settings in your lists to the current equivalent values (or to other currently-acceptable values as you see fit):
"Validate= Store only" is now "Validate= No"
"Validate= All commands" is now "Validate= Yes"
Informational commands such as QUERY, SHOW, INDEX and REVIEW do not require any validation, regardless of the setting of Validate=.
Requests originating on the local machine via CP MSG or CP SMSG (on VM systems) or originating on the local machine via LCMD (on VMS, Unix, and Windows 95/NT systems) never require validation, as they cannot be forged.
In all cases save one, the PUT command must always be validated with the personal password of the list owner or LISTSERV postmaster who is executing the PUT operation. This is because LISTSERV is not currently able to (1) suspend the execution of your PUT command, (2) store your list header or other file in a temporary file, and (3) wait for your "OK" before executing the PUT. If your password is used only for the purpose of validating PUT commands, any password exposure is minimal as PUT operations are not part of everyday list management routine. VM users should note that PUT requests require no validation when submitted via CMS SENDFILE from the machine on which LISTSERV is running, as the operating system itself guarantees the authenticity of the transaction (and thus there is no need to store the file you are PUTting and wait for an "OK"). This is the only case in which a PUT operation does not require a password.
Table B.1 shows how LISTSERV commands are influenced by the Validate= keyword under different settings. Some redundant commands (e.g., JOIN, LEAVE, and UNSUBscribe) are not documented in the table, but behave exactly as do their "official" counterparts (e.g., JOIN behaves exactly as does SUBSCRIBE). Some commands never require validation but are included for completeness because they are specifically "list-level" commands. If a command is not otherwise listed below, it is not influenced in any way by the Validate= keyword.
NONE = does not require any validation
PW = requires password validation
OK = requires OK validation, will not accept PW validation
OK/PW = requires OK validation by default but will also accept PW validation
|
|
Validate= setting is: |
|||||
|
Command |
No |
Yes |
Yes, Confirm |
Yes, Confirm, NoPW |
All, Confirm |
All, Confirm, NoPW |
|
ADD(*) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
CHANGE(**) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
CONFIRM |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
DELETE(*) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
FREE(*) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
GET(***) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
GETPOST |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
HOLD(*) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
INFO |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
PUT(*) |
PW |
PW |
PW |
PW |
PW |
PW |
|
QUERY |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
REVIEW |
NONE |
NONE |
NONE |
NONE |
OK/PW |
OK |
|
SCAN |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
SEARCH |
NONE |
NONE |
NONE |
NONE |
NONE |
NONE |
|
SET |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
|
SIGNOFF |
NONE |
NONE |
NONE |
NONE |
OK/PW |
OK |
|
SUBSCRIBE |
NONE |
NONE |
NONE |
NONE |
OK/PW |
OK |
|
UNLOCK(*) |
NONE |
PW |
OK/PW |
OK |
OK/PW |
OK |
Table B.1. LISTSERV list-level commands and how they are affected by Validate=.
(*) All commands so marked may be issued only by a list owner or LISTSERV postmaster.
(**) The CHANGE command has two syntaxes, one for general users, one for list owners/postmasters. General users will always be required to use "OK" confirmation, regardless of the Validate= setting. The values in the table above are for the syntax issued by list owners or the LISTSERV postmaster(s).
(***) 'GET listname' may be issued only by a list owner or LISTSERV postmaster. General users may issue GET commands for notebook archives and/or files listed in the list's file catalog and with appropriate GET FACs only.
Please note carefully that Table B.1 assumes that you have defined default values for most keywords. For instance, the SUBSCRIBE command will require an "OK" confirmation if you have "Subscription= Open,Confirm" and "Validate= No"; REVIEW will only be available depending on how you have the "Review=" keyword set; GETPOST and SEARCH may require passwords depending on the "Notebook=" setting; etc. However none of these conditions are influenced directly by "Validate=" except as noted in the table.
In some cases, "Validate= Yes" will cause an "OK" request to go out instead of requiring a password (i.e., if no password was included with the command). This is to avoid confusion on the part of a subscriber who may or may not have a LISTSERV password and who may not understand why he is being asked to provide a password before a given command will work.
Note also that even with "Validate= No" some users may be required to confirm commands with the "OK" method if they are sending commands via a web browser and WEB_BROWSER_CONFIRM= is set to 1 (the 1.8c default; under 1.8d the default is 0, or disabled) in the site configuration file.
History: 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.8b and following, this procedure is also used for authentication purposes. Since the confirmation codes are valid only for a single command, this actually provides better security than personal passwords, while simplifying book-keeping.
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).
This keyword is not available in LISTSERV Lite.
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 Confirm-Delay= 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).
In LISTSERV 1.8b and later, this keyword can also extend the period of time during which postings to a list coded "Send= Editor,Hold" are held before they are flushed. The default (and minimum) for holding such postings is 7 days (168 hours). Note that you can only increase this period with "Confirm-Delay=", not decrease it. Thus for a list with "Send= Editor,Hold" and "Confirm-Delay=48", the holding period would still be 7 days. But for a list coded "Send= Editor,Hold" and "Confirm-Delay=240", the holding period would be 10 days (240 hours).
Please inform the LISTSERV maintainer before any significant increase to the value of "Confirm-Delay=", particularly if your list is coded "Send= Editor,Hold" or "Send= Editor,Hold,Confirm", as the increased delay could cause a problem with disk space availability.
Note that if you increase "Confirm-Delay=" to extend the holding period for postings, you also are increasing the period during which LISTSERV will hold subscription jobs requiring confirmation.
See also Subscription=.
Default-Options= option1,option2,...
A "Default-Options" 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. Setting Default-Options= does not affect existing subscribers. If you want existing subscribers to have these settings, you must update them manually with a SET listname options FOR *@* command.
A typical Default-Options= setting might be:
* Default-Options=Nofiles,Norepro,Msg
Note that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
Starting with LISTSERV 1.8d, all default options are applied to non-subscribers, so it is possible to force even non-subscribers to post through a moderator by simply setting "Default-Options= REVIEW", or lock them out altogether by setting "Default-Options= NOPOST". This works even if your list is set "Send= Public", in which case there is a side benefit: the setting will stop people whom you have set to REVIEW or NOPOST from signing off the list and being able to post.
Two caveats regarding the use of this keyword under 1.8d:
Default-Options= REVIEW is overridden for addresses defined in Editor= or Moderator=.
Default-Options= NOPOST in conjunction with Send= Editor causes mail from non-subscribers to be forwarded to the appropriate Editor for approval rather than simply rejecting it with a "you are not allowed to post" message.
Default-Topics= topic1,topic2,...
This keyword is not available in LISTSERV Lite.
A "Default-Topics=" list header keyword is available to define the initial topics for new subscribers. The syntax is the same as for the SET TOPICS 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 "Default-Options=" 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.
As with Default-Options=, setting this keyword affects only subscribers who sign up after you set it. If you want existing subscribers to be set to these topics, you must update them manually with a SET listname TOPICS: topics FOR *@* command.
Subscription= By_Owner[,Confirm]
Subscription= Closed
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.
Open: New users are allowed to subscribe to the list.
Open,Confirm: Before new users are allowed to subscribe to the list they must confirm their address with an "OK" response. No list owner intervention is required.
By_Owner: New users are not allowed to subscribe, but their requests will be forwarded to the list owner. This is the default.
By_Owner,Confirm: (1.8e) Similar to "By_Owner", but before the request is forwarded to the list owner, the would-be subscriber must first respond to an "OK" confirmation request. NOTE CAREFULLY that you MUST specify "By_Owner" rather than "By Owner" -- the underscore is required for this syntax.
Closed: New users are not allowed to subscribe, and their requests are not to be forwarded to the list owner.
Note that "Subscription= By Owner" is still supported but is deprecated, and as noted, the underscore must be supplied if ",Confirm" is used.
(The ",Confirm" option is used in conjunction with "Subscription= Open" and "Subscription= By_Owner" only. It has no effect with "Subscription= Closed".)
One problem plaguing some mailing lists is one-way or non-repliable 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 "Confirm-Delay=" keyword (the default is 48h).
Similarly, starting with LISTSERV 1.8e, it is possible to code "Subscription= By_Owner,Confirm". This adds an address probe into the usual procedure for subscriptions that must be approved by the list owner. The behaviour with "Subscription= By_Owner" is
1. User sends SUBSCRIBE command.
2. LISTSERV forwards to list owner.
and no check is done to verify that the user's address is viable. Adding the ",Confirm" parameter changes the behaviour to
1. User sends SUBSCRIBE command.
2. LISTSERV asks for OK confirmation (new).
3. User confirms.
4. LISTSERV forwards to list owner.
With this setting in place, list owners who run restricted-subscription lists will no longer have to discover for themselves whether or not a potential subscriber's address has been spoofed or is otherwise non-viable, since they will never see subscription requests that have not been confirmed by the subscriber.
Categories= category1,category2,...categoryn
Sets search categories for this list (by default, none are defined) for the CataList service (see Chapter 3.3 of the List Owner's Manual for details). For instance, you might have a list on the topic of great opera tenors of the 20th century, and want anyone searching the CataList based on certain topics to find your list. You might therefore code:
* Categories= Arts:Music:Opera,Arts:Music:Opera:Singers
* Categories= Arts:Music:Opera:Pavarotti
and so forth.
DBMS=Yes[,Table(xxx)][,Email(xxx)][,Name(xxx)][,Uemail(xxx)][,Options(xxx)] [,Server(server_alias)]
This keyword is not available in LISTSERV Lite.
This functionality is not available under VM. Under non-VM it requires an appropriate DBMS application (not provided by L-Soft) be installed on the LISTSERV machine.
"DBMS=" (introduced in 1.8d) is used to tell LISTSERV that the list of subscribers is kept in an ODBC or OCI database rather than in the traditional *.LIST file. In order to set this keyword to anything but the default, DBMS support must be installed on the LISTSERV server. Please see the Developer's Guide for LISTSERV (available separately) for more information on installing support for and using the DBMS and Mail Merge functions.
Warning: List owners should NOT add this keyword to their list header as the use of the DBMS= keyword presupposes existing DBMS support that has been configured to work with LISTSERV. Further, list owners should NOT change the value of this keyword if it exists in their list header, as changing any of the parameters could lead to unexpected results.
Windows OCI Support Withdrawn: In LISTSERV 1.8e, it is possible to define multiple simultaneous connections to DBMS tables, and as a result, previous OCI support for Windows NT/2000 (which was provided to work around the earlier limitation of only a single ODBC connection at a time) has been withdrawn. OCI databases may still be accessed via ODBC.
When migrating an existing list to use a DBMS, you are responsible for migrating the subscriber data to the DBMS, if necessary (in many cases, the subscriber data will already be in the DBMS, possibly in a slightly different format). Once you add the "DBMS= Yes" keyword, LISTSERV stops accessing subscriber data from the xxx.LIST file and uses the DBMS instead.
The default is "DBMS= No", i.e., keep subscriber information in a traditional *.LIST file.
This keyword is not available in LISTSERV Lite.
Determines the minimum number of columns allowed for list addresses in response to the REVIEW command. The default is Indent= 40.
Language= idiom|option[,option]
This keyword is not available in LISTSERV Lite, except that it can be set to "Language= Exchange" to avoid suppression of application/ms-tnef attachments as noted below.
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 (called idiom.MAILTPL, where idiom is the name of the language specified by this keyword) to the server. The default is "Language= English", which uses DEFAULT.MAILTPL.
L-Soft does not provide non-English templates.
Available options are as follows:
Language= HTML: This setting allows you to specify that LISTSERV's administrative messages (i.e., those specified in the MAILTPL) be sent out in HTML format. You specify either Language= HTML or Language= idiom,HTML to enable this feature. Note carefully that this setting does not affect the WELCOME or FAREWELL files.
Language= NOHTML: This setting allows you to specify that LISTSERV strip any HTML attachments from postings (while retaining HTML tags sent in the
body of plain text messages). You specify either Language= NOHTML or Language= idiom,NOHTML to enable this feature.
The actual function of this setting is to remove the attachment that contains the HTML mail from the message. It does not remove HTML tags from plain text messages. This means that setting this option will not suppress HTML in messages sent from (for instance) Eudora Pro 3.x (since Eudora Pro 3.x does not send the HTML message as a MIME attachment with a plain text alternative).
If an HTML message does not contain a plain text alternative, and Language= NoHTML is set, the message will be rejected. LISTSERV 1.8d and earlier would allow such messages through.
Language= EXCHANGE: This setting allows you to specify that LISTSERV keep Microsoft Exchange attachments in postings (the default is to remove them). You specify either Language= EXCHANGE or Language= idiom,EXCHANGE to enable this feature. Note that this affects "application/ms-tnef" attachments only-- LISTSERV does not currently strip WINMAIL.DAT attachments.
These three formatting options are not mutually exclusive and may be defined in any grouping (in other words, Language= HTML,NOHTML,EXCHANGE is legal although it is unlikely anyone would want to use it).
This keyword is not available in LISTSERV Lite.
This keyword is available only with the ISP add-on, and may only be added or changed by the LISTSERV Maintainer. Defines specific limits for a list. Currently only the number of subscribers can be limited, for example,
* Limits= Sub(100)
This keyword may only be added or changed by the LISTSERV postmaster, and the list creation password is required for the list PUT operation when the keyword is added or changed. The list owner may execute a PUT operation with this keyword defined in the header as long as the values for the keyword are not changed.
This keyword is not available in LISTSERV Lite.
Enables or disables "long-lines" support. This keyword was added to maintain compatibility with LISTEARN and will be removed in a future version of LISTSERV. The default is "Long-Lines= Yes". It is unlikely that this keyword will need to be set for any list.
This keyword is not available in LISTSERV Lite.
Documented Restriction: LISTSERV's mail merge functionality REQUIRES EITHER: a) the use of LSMTP Classic as the outgoing MTA, or b) the use of Embedded Mail Merge (EMM), introduced in LISTSERV 14.4. Without EMM, mail merge works ONLY with L-Soft's LSMTP Classic mailer. EMM is enabled by default in LISTSERV 14.5 and later.
Under unixes not supported by LSMTP Classic, not using EMM may require that you set SMTP_FORWARD= accordingly in go.user, to point to a separate machine running LSMTP (for instance, a dedicated Windows NT LSMTP machine). Under OpenVMS or Windows NT can run LSMTP Classic either on the same machine (the preferred method), or on a separate machine if desired. The main point is that the outgoing mail-merge postings MUST be handled by LSMTP Classic. (LSMTP Lite does not support mail-merge.)
Mail merge functions are documented fully in the Developer's Guide for LISTSERV, available separately.
Mail-Merge= Yesmakes every posting to the list a mail-merge operation (see the Developer's Guide to LISTSERV for more information about formatting mail merge jobs). Digests and indexes also become mail-merge jobs. Header modifications are done in the same way as with a normal list, you confirm with OK as usual, etc. The text will then follow the same rules as when entered in a mail-merge job using the web interface--ASSUMING that your mail program did not do anything fancy to the text, such as replace all ampersands with =xx or rewrite everything in rich-text format. It is fundamentally difficult and unreliable to use a mail program as the client for mail-merge since mail programs are engineered to encode information in fancy and unpredictable ways that were not used in the previous version, whereas mail servers are engineered to only look at the information they positively need to look at to get the job done, so that they do not inadvertently get in the way of new, fancier encoding methods. Therefore it is important when using a mail program to send mail-merge jobs that you ensure that the mail program sends plain text rather than any kind of encoded text.
This keyword should be used only on lists that are set up as announce-only mailing lists (that is to say, posting should be restricted to the list owner(s) only for security purposes). Because this keyword alone does not restrict the ability to post, the list owner(s) should ensure that the "Send=" keyword is set appropriately. Note that if you do not restrict the ability to post, anyone who is otherwise permitted to post to the list will also be able to send mail-merge jobs to it.
This method can be used to attach files unconditionally. It cannot be used to send file 1 to some people and file 2 to others because the mail program knows nothing about mail-merge and, as such, does not mark them as conditional blocks. Any markings you provide are part of the text attachment you are working in.
The default is to send mail normally, in other words, Mail-Merge= No . As noted above, if your LISTSERV installation is not configured properly for mail-merge operations, you should never change this setting from the default.
Misc-Options= option1,option2...optionn
This keyword is not available in LISTSERV Lite.
This keyword is available in non-Lite 1.8e versions and later with build dates of September 2002 forward (issue the command SHOW LICENSE to LISTSERV to determine build date). It is not available in original release 1.8e.
This keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings. Currently the only options available are as follows:
IETFHDR_SUBJECT_TAG (14.5)
Add subject tags to IETF headers (that is, for users who are set to the IETFHDR personal option). However, as this can be considered a violation of the standard for IETF-style headers, it can be prevented site-wide by the site administrator if desired.
Adding "Misc-Options= IETFHDR_SUBJECT_TAG" to the list header causes the IETFHDR option to always include subject tags. This is a per-list setting; in other words, either all subscribers to a list who are set to the IETFHDR option get the subject-tag, or no. The design consideration is that, at present, it is prohibitively expensive to switch the existing header types into flags as the number of combinations grows significantly.
IGNORE_EMAIL_CASE | RESPECT_EMAIL_CASE
These options are mutually-exclusive; only one can be defined at a time per list.
When set in a list header, "Misc-Options= IGNORE_EMAIL_CASE" causes the ADD command to ignore the case of the "local part" of list subscriber entries (that is, the part of the address that is to the left of the "@" sign). Although most modern mail clients are configured to ignore the case of the local-part, this behavior technically violates RFC821 which states that local-parts are considered case-sensitive.
If an entry whose "local part" differs only in case is found in the list during an ADD operation (for instance, JOE@EXAMPLE.COM vs. joe@EXAMPLE.COM), that entry will be assumed to be the entry that was sought, and the address field will be updated to the new case (that is, "JOE@" will be changed to "joe@"). No other change will be made to the entry unless there is a change in the name field, in which case the name field will also be updated.
If there is no change in the address field associated with the entry, no change will be made to the entry (again, unless the name field changes, in which case the entry will be updated).
In either case, when this option is set, a new entry with a different case will NOT be added.
Note the following caveats:
1. Pre-existing duplicates are not automatically removed from lists when this option is set.
2. Because ADD updates the case of entries, it is possible to end up with multiple entries that have exactly the same case.
3. The only real way to de-dupe a given address is to DELETE and then re-ADD it.
Other than this, existing duplicate entries work exactly as they did before the option was enabled. Commands that do not add new entries ignore the option.
And finally, it should be carefully noted that the PUT command also ignores the option.
When a list is set to "Misc-Options= RESPECT_EMAIL_CASE", this tells LISTSERV to operate per RFC821 and treat address fields with differently-cased local parts as different addresses. The option is provided as an override to the site-level IGNORE_EMAIL_CASE configuration variable and does not need to be set to preserve the default unless the site setting has been changed to make IGNORE_EMAIL_CASE the default.
KEEP_DKIM_SIGNATURE (14.5)
Incoming DomainKeys signatures in messages submitted
to a mailing list will be suppressed unless "Misc-Options= KEEP_DKIM_SIGNATURE" is set in the
list configuration.
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general
use. As DomainKeys is specified today,
signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so
LISTSERV removes them by default to avoid triggering alerts for subscribers on
systems that have implemented the client side of DomainKeys.
NO_DKIM_SIGNATURE (14.5)
"Misc-Options= NO_DKIM_SIGNATURE" is available at the list level to override LISTSERV's default DomainKeys message signing if desired.
NO_RFC2369 (14.5)
In LISTSERV 14.5, support has been added for RFC2369, which calls for the use of message headers such as "List-Help", "List-Subscribe", and "List-Unsubscribe". A list posting using these headers will look like this:
Date:
Fri, 21 Oct 2005 14:21:03 -0500
Reply-To: Test list <TEST@LISTSERV.EXAMPLE.COM>
Sender: Test list <TEST@LISTSERV.EXAMPLE.COM>
From:
Some User <someuser@EXAMPLE.COM>
Subject: What's all this RFC2369 stuff?
To:
TEST@LISTSERV.EXAMPLE.COM
Precedence: list
List-Help: <http://listserv.example.com/scripts/wa.exe?LIST=TEST>,
<mailto:LISTSERV.EXAMPLE.COM?body=INFO+TEST>
List-Unsubscribe: <mailto:TEST-unsubscribe-request@LISTSERV.EXAMPLE.COM>
List-Subscribe: <mailto:TEST-subscribe-request@LISTSERV.EXAMPLE.COM>
List-Owner: <mailto:TEST-request@LISTSERV.EXAMPLE.COM>
List-Archive:
<http://listserv.example.com/scripts/wa.exe?LIST=TEST>
I was curious about these new headers, can someone enlighten me?
RFC2369 support is activated by default and supplies all of the headers specified in the standard except "List-Post:", which L-Soft considers to be redundant.
In compliance with RFC2369, LISTSERV discards any pre-existing List-xxx tags.
RFC2369 compliance can be disabled using:
* Misc-Options= NO_RFC2369
and this can also be specified in the site-wide DEFAULT_MISC_OPTIONS variable. When RFC2369 support is disabled, you get the old behavior; that is, the tags are neither added nor removed.
NO_SPAM_CHECK (14.3)
Use this option to disable spam scans for a particular list and its associated xxx-request address. (This is only useful if the LISTSERV maintainer has enabled spam-scanning via the SPAM_EXIT feature.)
RESPECT_EMAIL_CASE
See above at IGNORE_EMAIL_CASE.
SUBJECTHDR_SEQUENCE (14.5)
For LISTSERV 14.5, it is possible for each list posting to have a sequence number attributed to it, which can be seen by subscribers who are set to the SUBJECTHDR personal option. This new feature is enabled by adding "Misc-Options= SUBJECTHDR_SEQUENCE" to the list header. Site administrators can enable it server-wide by adding the value SUBJECTHDR_SEQUENCE to DEFAULT_MISC_OPTIONS in the site configuration. The format of the new subject tag is
[listname - number]
For example:
Subject: [TEST - 256] Test of SUBJECTHDR_SEQUENCE
where 'number' is a sequence number, starting from 1 and increasing indefinitely for all practical purposes (the counter will accommodate over 2 billion postings per list).
"Subject-Tag=" is still used to change the first item. In order to allow server administrators to set a server-wide default for the new feature, it was not possible to implement the sequence number feature as an extension to "Subject-Tag=".
Note: Both the new [listname - number] and the traditional [listname] tags are removed from the subject on incoming messages. This happens whether or not the option is set, because people might be replying to old messages before the option was changed.
LISTSERV tries very hard never to skip a sequence number. The only plausible scenario in which this could ever happen would be when the MTA (not LISTSERV) fails to deliver the message. However, there are several cases where a sequence number will be reused:
· If the site administrator deletes or temporarily renames PERMVARS.FILE in an attempt to solve an unrelated problem. Deleting PERMVARS.FILE is not supported as a troubleshooting method.
· If the list is migrated to a new host.
· If there is a crash, disk full error, etc., when updating the counter.
SUPPRESS_APPROVED_BY (14.3)
Use this option to suppress RFC822 "Approved-By:" headers that would normally be generated by LISTSERV in messages posted through moderated lists.
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".
Setting "Translate= No" may be required for accurately passing messages written using double-byte character systems such as those available for the Japanese language.
Default Values for all keywords
|
Ack= No |
Attachments= Yes |
||||
|
Auto-Delete= No if "Validate= Yes", Yes,Semi-Auto,Delay(4),Max(100) otherwise |
|
|
|||
|
Categories= <none> |
Change-Log= No |
||||
|
Confidential= No Configuration-Owner= Owner |
Confirm-Delay= 48 |
||||
|
Daily-Threshold= 50 |
DBMS= No |
||||
|
Default-Options= <none> |
Default-Topics= <none> |
||||
|
Digest= Yes,Same,Daily if "Notebook= Yes", No otherwise |
|
|
|||
|
Editor= <none> |
Editor-Header= Yes |
||||
|
Errors-To= Owners |
Exit= <none> |
||||
|
Files= No |
Filter= <built-in> |
||||
|
Indent= 40 |
Internet-Via= <none> |
||||
|
Language= English |
Limits= <not set, ISP option only> |
||||
|
List-Address= <none> (per LIST_ADDRESS system default) |
|
|
|||
|
List-ID= <none> |
Local= <none> (per LOCAL system default) |
||||
|
Long-Lines= Yes |
Loopcheck= Normal |
||||
|
Mail-Merge= No |
Mail-Via= DISTRIBUTE |
||||
|
Misc-Options= <none> |
|
|
|||
|
Moderator= <none> (defaults to first Editor if "Editor=" is defined)) |
|
|
|||
|
New-List= <none> |
Newsgroups= <none> |
||||
|
NJE-Via= <none> |
Notebook= No,A,Single,Private |
||||
|
Notebook-Header= Short |
Notify= Yes |
||||
|
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) |
||||
|
Peers= <none> |
Prime= Yes |
||||
|
PW= |
(randomly generated at list creation time if not specifically defined) |
||||
|
Renewal= <none, disabled> |
Reply-To= List,Respect |
||||
|
Review= Private |
Safe= Yes |
||||
|
Send= Public |
Sender= List |
||||
|
Service= * |
Sizelim= <none> |
||||
|
Stats= Normal,Private |
Sub-lists= <none> |
||||
|
Subject-Tag= short name of the list, for example, MYLIST-L |
|
|
|||
|
Subscription= By_Owner |
Topics= <none> |
||||
|
Translate= Yes |
Validate= No |
||||
|
X-Tags= Yes |
|
||||
[1]The plaintext digests conform to RFC1153 with an acceptable deviation from the recommended subject line (verified with the RFC author).