List Keyword Reference for LISTSERV® version 14.5
Last updated 10 Mar 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 239)
|
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 245)
|
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 255)
|
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 260)
|
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 270)
|
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 278)
|
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 281)
|
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 285)
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. |