[LISTSERV logo] [Online documentation]

L-Soft international, Inc.
List Owner's Manual
for
LISTSERV®, version 1.8c
August 18, 1997
Revision 2
r970818-001

The reference number of this document is 9708-UD-02.

[next chapter] [previous chapter] [table of contents]

Appendix B: List Keyword Alphabetical Reference

for LISTSERV version 1.8c

Reference Number 9708-UD-01

This document is available separately. It can be retrieved in plain text from any server running L-Soft's LISTSERV with the command INFO KEYwords.

The List Header

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, version 1.8c (L-Soft document reference number 9708-UD-02).

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:

Generic parameters

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 } Self-explanatory

Monthly } Self-explanatory

Weekly } Self-explanatory

Daily } Self-explanatory

Hourly } Self-explanatory

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, e.g. "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, e.g. EARN, BITNET

The name of a country, e.g. Germany, Canada

'Local', in which case it is equated to the value of the "Local=" keyword (q.q.v.).

A node name, e.g. SEARN

A simple wildcard nodename pattern such as FR*, *11, *ESA*, D*ESA*, etc.

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, e.g. INFO@TCSVM

'Postmaster', which indicates the "main" postmaster

'Postmasters', which indicates ALL the postmasters, main and alternate

'Owner', which indicates the "main" list owner (the first to be listed in the "Owner=" keyword)

'Owners', which indicates ALL list owners

Some keywords can take more than one parameter. Where multiple parameters are accepted, they will be separated by a logical OR sign (|). Unless specified otherwise, commas have "higher priority" than OR signs, that is to say, "Public|Private, Open|Closed" means "(Public|Private), (Open|Closed)", not "Public|(Private,Open)|Closed".

Keywords fit into several different classifications. These classifications, and the associated keywords, are as follows:
Access Control Keywords

Files= Determines whether non-mail files may be distributed by the list

Filter= Gives list owners control over problem users and/or gateways

Review= Restricts who may review the list of subscribers

Send= Restricts who may send postings to the list

Stats= Determines whether or not list statistics are available, and to whom

Distribution Keywords

Ack= Controls the level of acknowledgement messages to those posting messages

Daily-Threshold= Limits the total number of messages that will be processed by the list per day before the list is held

Digest= Controls the automatic digestification option

Internet-Via= Determines through which gateway Internet mail will be sent

Mail-Via= Determines how LISTSERV distributes list mail

Newsgroups= Defines USENET newsgroups linked to the list

NJE-Via= Determines through which gateway NJE mail will be sent

Prime= Controls whether or not mail will be processed during "prime time"

Reply-To= Sets a default for the "Reply-To:" field in the header of list mail

Sender= Defines the value LISTSERV places in the "Sender:" header field of list mail

Sub-Lists= Defines sub-lists of a "container" or "super-" list

Topics= Defines up to 11 sub-topics for a list

Error Handling Keywords

Auto-Delete= Sets parameters for the auto-deletion feature

Errors-to= Determines the network address to whom mail delivery errors are directed

Loopcheck= Defines the type of mailing loop checking performed by LISTSERV

Safe= Determines which built-in address filter is used by LISTSERV

List Maintenance and Moderation Keywords

Editor= Defines an editor or editors for moderated list

Editor-Header= Controls if an explanatory mail header is added to list messages forwarded to the list editor (if one is defined

List-Address= Determines how the list address is announced in message header

List-ID= Defines a long listname alias for the lis

Moderator= Defines the editors on moderated lists who will receive postings for approval

New-List= Sets forwarding when a list is moved to a different LISTSERV host

Notebook= Controls the notebook archive for a list

Notebook-Header= Determines the type of header information included in the notebook archive

Notify= Defines whether or not (or to whom) subscription notification is sent

Owner= Defines the owner (or owners) of the list

Peers= Defines peers for the list

Renewal= Controls whether or not subscription renewal is implemented, and how

Sizelim= Controls the maximum size of any single message posted to the list

Subject-Tag= Controls the "subject tag" text field for messages coming from the list

X-Tags= Controls whether "X-to:" and "X-cc:" tags are included in list mail headers

Security Keywords

Confidential= Determines whether or not an entry for the list appears in the List of Lists

Exit= Defines a list "exit" which modifies the default behavior of LISTSERV

Local= Defines which nodes are considered "local" for this list

PW= Sets a password used for validation of list maintenance commands

Service= Defines an area or areas outside which subscription requests are not accepted

Validate= Determines whether or not list commands must be validated with a password or the "OK" mechanism

Subscription Keywords

Confirm-Delay= Defines a default number of hours LISTSERV holds jobs requiring confirmation

Default-Options= Defines what options should be set by default for new subscribers

Default-Topics= Defines what topics should be set by default for new subscribers

Subscription= Defines how new subscriptions are handled, and if confirmation is required

Other Keywords

Categories= Defines search categories for the CataList service

Indent= Defines the minimum number of columns allowed for list addresses in a REVIEW

Language= Defines the language in which information mail and messages are sent

Limits= Defines certain limits (no. of subscribers, etc.) for a lists (ISP scope option only)

Long-Lines= Controls whether long-lines support is enabled

Translate= Controls how LISTSERV handles control characters in list mail

Default Values for All Keywords

Keywords Disabled in LISTSERV Lite

LISTSERV Lite is LISTSERV running with a special license activation key (LAK) which is both free and perpetual, but is limited in its scope. With LISTSERV Lite, you can run up to 10 mailing lists as long as you do not derive a profit from this activity. Note also that LISTSERV Lite does not have all of the functionality of a full version--a list of the keywords and functions disabled in LISTSERV Lite follows this paragraph. For more information on the exact terms and conditions under which you may run LISTSERV Lite, please see L-Soft's World Wide Web site or contact L-Soft's sales department.

LISTSERV Classic Keywords disabled in LISTSERV Lite

Confirm-Delay   Default-Topics  Editor-Header   Exit
Files           Indent          Internet-Via    Language
List-Address    List-ID         Local           Long-Lines
Loopcheck       Mail-Via        Moderator       New-List
Newsgroups      NJE-Via         Peers           Prime
Renewal         Sender          Service         Sizelim
Stats           Sub-Lists       Topics          X-Tags

Note: the fact that the keyword is disabled only means that the default value cannot be changed. For instance, loop checking is still present, you just cannot control the details of its operation. On the other hand, if the default value is that the function in question is disabled (as is the case with "Peers="), then the function is actually gone. See the entry for the keyword in question for more information on keyword defaults.

For a full discussion of the differences between LISTSERV Classic and LISTSERV Lite, please see the Site Manager's Operations Manual or the LISTSERV Lite web page.

Access Control Keywords

Files=Yes | No

(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.
Filter= Only | Also | Safe,net-address1,net-address2,....
"Filter=" is checked when a user attempts to post or subscribe to a list (but not when the list owner issues an ADD command). The first word of this keyword is either "Only", "Also" or "Safe", and it is followed by a list of patterns such as 'X400MAIL@*' or '*@*.XYZ.EDU' (without the quotes). If "Also" is specified, your filter is used in addition to the standard LISTSERV filter; this is useful to register additional looping mailers, to prevent users behind broken gateways from subscribing until the problem is addressed, or to ban anonymous posters. LISTSERV has two built-in filters: a "minimal" one, which is used for safe lists, and a "safe" one which is used for lists running with "Safe= No". That is, the unsafe lists need a safe filter to avoid mailing loops; safe lists only need the minimal filter, but can be made even safer by selecting "Filter= Safe". This, however, prevents usernames such as 'root' from posting to the list, because they are included in the safe filter.

If "Filter= Only" is used, the addresses you specify are the only ones which LISTSERV prevents from posting to the list. CAUTION: You should not use this option unless you also code "Safe= Yes", and even then you will want to ask your LISTSERV maintainer for permission. This option has been added mostly for LISTSERV maintainers with very specific problems to solve. The minimal filter is very small and you should never need to override it.

Messages sent to the LISTSERV userid for execution are always checked with the minimal filter, as people with userids such as 'root' would otherwise not be allowed to subscribe to lists which were set up to allow them.

Note that LISTSERV extracts as many 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).

Review= access-level

This keyword defines the categories of users who are allowed to review the Internet addresses and names of the persons subscribed to a list. Beginning with version 1.8c, the default value is "Review= Private".
Send= access-level [,Semi-Moderated][,Hold][,Confirm]

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, e.g., 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.

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 "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.

An example:

* Send= Private,Semi-Moderated
* Editor=NATHAN@LSOFT.COM ERIC@LSOFT.COM

In this example, a message sent to the list would be:

Another example:

* Send= Editor,Semi-Moderated
* Editor=NATHAN@LSOFT.COM ERIC@LSOFT.COM

In this example, a message sent to the list would be:

Note that in the above example, messages don’t get discarded if the sender isn’t subscribed.

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 (e.g., Send=Editor,Confirm), all mail sent to the list, including mail sent by any editor/moderator, requires confirmation by the primary editor or a moderator (if "Moderator=" is defined). 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.

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.

Note that you may only specify one access-level in the "Send=" keyword. If you need to diversify the group of people who may send mail to the list, you should use "Send= Editor" (at minimum) and define the authorized sender(s) in one or more "Editor=" keywords.

Stats= Normal | None,access-level [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.

Distribution Keywords

Ack= Yes | Msg | No | None

Defines the default value of the "ACK/NOACK" distribution option for the corresponding list, i.e. the value assigned to new users when they subscribe to the list. This value can be altered by subscribers ("SET" command), but not by users who are not signed on to the list. This means that this option will always be in effect when distributing mail from people who are not on the distribution list.

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]

Daily-Threshold= nnn1[,nnn2]
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.

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= No

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. [7]

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 new options are alternatives to MAIL and NOMAIL. When switching around between these delivery options, users will observe the following behavior (digests will be assumed to be daily for the sake of clarity):

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:ss' or just 'hh' in the usual 00-23 scale (24 is also accepted for midnight). For weekly digests, specify a weekday such as "Tuesday". For monthly digests, you may specify a number from 1 to 31 corresponding to the day of the month when the digest will be distributed, although this is not recommended. The purpose here is to make it possible for digests to be issued at 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.

Finally, the last 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.

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.

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.

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, and the list creation password is required for the list PUT operation if this parameter is changed. 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= net-address
There is no default value. This parameter determines whether or not mail bound for Internet addresses is routed through a specific Internet gateway.
Mail-Via= Direct | DISTRIBUTE | DIST2
The default value is Mail-Via= DISTRIBUTE. DIST2 is functionally equivalent to DISTRIBUTE, and is included for historical reasons. Mail-Via= Direct causes LISTSERV to ignore the DISTRIBUTE algorithm for subscribers on the local system, but mail to non-local subscribers will still go out on the DISTRIBUTE backbone.
Newsgroups= None | usenet_newsgroup1,usenet_newsgroup2...
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

NJE-Via= net-address
There is no default value. This parameter determines whether or not mail bound for NJE addresses is routed through a specific gateway.
Prime= Yes | No | when
Determines whether or not mail for the list is processed during "prime time", a value that is determined by the LISTSERV maintainer and is kept in the system configuration file. The default is "Prime= Yes". This can be most useful in controlling the load on the machine running LISTSERV. "Prime=" may also be set to an explicit time specification, e.g.,

Prime= "MON-FRI: 09:00-17:00; SAT-SUN: -" 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.

Please note that 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, e.g., number crunching, daily backups, or any other function during which LISTSERV should not be using cycles.

Reply-To= List | Sender | Both | netaddress [,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 "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.

The parameters operate as follows:

1st position:

2nd position:
Sender= LIST | NONE | "list title <net-address>",ietf-address
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>...
This keyword is new 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

The default value for this keyword is null, e.g., 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.
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,...topic11
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 11 topics for the list. For instance, the list owner could code:

Topics= News,Benchmarks,Meetings,Beta-tests

WARNING - YOU MUST NEVER REORDER THE TOPICS= KEYWORD
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, 12th topic, "Other". If some of the topics are valid but others are undefined, the invalid ones are ignored. At any rate the subject field is left unchanged. Here is an example:

Subject: Benchmarks,News: Benchmarks for XYZ now available!

Messages which should be read by everyone can be posted to the special topic "All". Topic names can be shortened to any unambiguous abbreviation. In our example, "Be" is ambiguous because it could be either "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:

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.)

Error Handling Keywords

Auto-Delete= No

Yes,Semi-Auto | Full-Auto | Manual,Delay(number),Max(number)

LISTSERV includes support for automatic deletion of users whose account has expired or whose system has permanently disconnected. When the delivery error is generated by LMail (any version), MX V3.2 or higher, PMDF V4.2 or higher, or LSMTP(TM) , which all implement the same delivery error format, LISTSERV may be able to automatically process the delivery error and take action based on the value of the "Auto-Delete=" list header keyword. The unix versions of LISTSERV also support sendmail's delivery error format.

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:

When auto-delete is set to "Manual":

Some considerations for configuring the auto-delete monitor parameters:

The default value is "Auto-Delete= No" for lists with "Validate= All" and "Auto-Delete= Yes,Semi-Auto,Delay(4),Max(100)" for other lists.

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'.
Loopcheck= Full | None | Noorigin | Nobody | NoCRC | NoSpam | Spam-Delay(n)
Determines the type of loop checking performed by LISTSERV to avoid perpetuating mail loops. The default is "Loopcheck= Full". 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: Please note carefully that L-Soft does not recommend changing Loopcheck= from its default of "Full" 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.

Safe= Yes | No
The list header keyword, "Safe= Yes/No", 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). The use of the "Safe= Yes" option significantly decreases the potential for mailing loops, but not enough to actually code "Loopcheck= No", unless you are sure that all your subscribers have compliant mailers.

List Maintenance and Moderation Keywords

Editor= net-address1,net-address2,...

Defines the list editor(s). When used in conjunction with the "Send=Editor" option, it causes all mail sent to the list to be automatically forwarded to the first person listed in the "Editor=" keyword, who will then send it back to the list at his discretion. The editors are the only persons (with the list owners) who are allowed to mail directly to the list. Note that ANY editor can send mail to the list while only the FIRST one will receive copies of mail sent to the list (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 MUST be a human person, not a file server, list server, mailer, or suchlike. Specifying a program's mailbox as the primary editor could result in a mailing loop for which L-Soft international, Inc., could not be held responsible.

Editor-Header= Yes | No
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".
List-Address= name_info@host_info
This keyword determines how LISTSERV announces its list address in the header of messages delivered to the list: NJE vs. Internet address, short vs. long list name, etc. The default options (when neither "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 configuration file.

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.

1.8c introduces 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:

It is important to note that the only affect 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, you should not use this keyword without first consulting with the LISTSERV maintainer.

List-ID= name
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. Note however that 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 systems running LSMTP.

Moderator= <netaddress1>,<netaddress2>....
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" (e.g., 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.

New-List= netaddress
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 generally 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= No
Notebook= Yes,where,interval|Separate,access-level
Indicates whether or not an automatic log of every piece of mail sent to the list is to be kept, and defines at which interval of time its file name must be changed and who is allowed to retrieve it from the server. The default values are "Notebook= No,A,Single,Private".
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.

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).

Note: Notebooks may be retrieved by means of the GET command. A list of all available notebooks can be obtained with a GET NOTEBOOK FILELIST command.

If your 1.8c server has 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 must be "Public"
  2. The notebook interval cannot be "Single" or "Separate"
  3. The LISTSERV maintainer must create an index directory for your list per the instructions in the Site Manager's Operations Manual.
Note further that lists that meet the above three requirements will show up in the WWW archive interface even if the list is set "Confidential= Yes". See chapter 5.4.6 of the Site Manager's Operations Manual for details.

The first two parameters of the "Notebook=" keyword may only be changed by the LISTSERV postmaster, and the list creation password is required for the list PUT operation if one or both of these parameters is changed.

Notebook-Header= Short | Full
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 "Yes".
Owner= net-address1 | mon-address1,...
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.

Peers= peer1,peer2,...
Defines the (global) list of all the servers in the world that are peer-linked to the list, either directly or via one or more other peer servers. This information is used by the various list management commands to determine the "nearest" peer list to a given user. For example, when a SUBSCRIBE command is received from a user and it is determined that there is a better (nearer) peer list for him, the subscription request is automatically forwarded to the appropriate LISTSERV.

Be sure to read the appropriate sections of the LISTSERV List Owner's Manual before peering any list.

Renewal= interval1,interval2...,intervalx,Delay(number)

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:

A typical Renewal= configuration might be:

* Renewal= 6-Monthly,Delay(14)

Conceivably Renewal= could also be set to something like:

* Renewal= 6-Monthly,95/07/04,12/25,15,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 1995, a request every year on Christmas Day, and a request every month on the 15th day of the month. Note that this is provided ONLY as an example. 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 a new 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.

Sizelim= number
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.)
Subject-Tag= text
(New for 1.8c)

LISTSERV now 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, e.g., 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.

Note that if a user sends a message with a blank RFC822 "Subject:" header, LISTSERV will not create a "Subject:" header and place the subject tag into it. Subject tags will only work when posters define a subject for their message.

X-Tags= Comment | Yes | No
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, i.e. "Comment: X-To:" and "Comment: X-cc:".

No: This information must not appear at all in the mail header.

Security Keywords

Confidential= No | Yes | Service

Indicates whether the list should be hidden from users or not. A confidential list will not appear on the "List" command output. "No" is the default value and indicates that the list is not confidential. "Service" indicates that the list is to be hidden from users who are not in the list's service area (see "Service=" keyword) but not from other users. "Yes" means that the list is unconditionally confidential.
Exit= filename
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.

Starting with version 1.8a, list "exits" are available to control the major events associated with list maintenance. This makes it easier to tailor the behavior of LISTSERV to local requirements that are too specific to be addressed through standard facilities.

An exit is enabled by adding "Exit= filename" to the list header. For security reasons, all exits must be explicitly declared in the LIST_EXITS configuration variable (in the LISTSERV configuration file). This prevents list owners from causing the invocation of arbitrary executable files through the use of the "Exit=" keyword.

This keyword is not generally usable by list owners without specific intervention by the LISTSERV maintainer, and thus is not otherwise documented here.

Local= node1,node2,...
Defines the nodes which are to be considered as 'local nodes' for both service area checking. The local node is automatically considered as a 'local node' and does not have to appear in the list. Subscribers from any of the local nodes will receive separate pieces of mail with a single recipient in the "To:" field - in other words, they will never receive a grouped piece of mail as 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.

PW= list-password
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.

Note that, begining with version 1.8c, a random password is generated for the list at list creation time if this keyword is not explicitly defined. List owners are encouraged to use personal passwords (defined with the PW ADD command, q.q.v.) in preference to list passwords for this reason.

Service= area1,area2,...
Defines the 'service area' outside of which subscription requests must not be accepted. When a SUBSCRIBE command is received, the "Peers=" keyword is checked first to see if there is a nearer peer list in the network. If it is the case, the command is forwarded to this nearer server. If not, the service area is checked to ensure that the recipient is acceptable; if it is not, the subscription request is denied. When the command is forwarded, the destination server might still deny access to the list if the subscriber is outside its own service area, if any.

It is important to note that the service area check is made only after the "best placement" check. This allows several servers in the same country to share an identical service area, e.g. "Service= Germany", and still have users subscribed to the best possible server. The default value is "Service= *" (e.g., any host).

Validate= No | Yes[,Confirm[,NoPW]] | All[,Confirm[,NoPW]]
Under L-Soft's LISTSERV, lists are protected by a password which must be specified by the list owner when he sends an updated version of the list back to the server. When "Validate= Yes", password validation applies to ALL the commands that modify the contents of the list, e.g. SIGNOFF, SET, etc. This implies that users cannot use these commands since they do not know the list password. A notable exception is the SUBscribe command, which can still be used (if enabled) to get on the list; however, sending a second SUBscribe command for the same list (to correct a spelling error in your name) would result in the command being forwarded to the list owner and not immediately executed. This is to protect you from network hackers who might issue a command "from" your userid@node to change list settings, such as who has the ability to GET and PUT the list, review concealed subscribers, etc. The default is "No", but it is recommended that "serious" or "important" lists be changed to "Validate= Yes".

This keyword was revised substantially in versions 1.7f and 1.8a. The "OK" command confirmation mechanism was introduced in version 1.7f, where it was used to implement the "Subscription= Open,Confirm" address verification mechanism. When a user tries to subscribe to a mailing list with that setting, he is mailed a confirmation request with a randomly generated confirmation key, also known as "magic cookie". The user replies to the message, types "OK" in the message body, and the command is confirmed. If for any reason the user's address cannot be replied to, the confirmation request is never received (or the "OK" message never arrives) and the user is not added. In versions 1.8x, this procedure is also used for authentication purposes. Since the confirmation codes are valid only for a single command, this provides better security than personal passwords, while simplifying 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). The following security settings are available:

Informational commands such as QUERY, SHOW, INDEX and REVIEW do not require any validation.

Requests coming from the local system via CP MSG or CP SMSG (on VM systems) or via LCMD (on VMS or Unix systems) never require validation, as they cannot be forged. The PUT command must always be validated with the list password, because there is presently no mechanism to suspend execution of a request to which a file is attached. If the list password is used only for that purpose, the exposure is minimal as PUT operations are not part of everyday list management routine. Note that PUT requests require no validation when submitted via SENDFILE from the machine on which LISTSERV is running, as the operating system then guarantees the authenticity of the transaction.

For lists operating with "Validate= Yes" (without the "Confirm" option), LISTSERV may still use the "OK" mechanism in certain cases if it is deemed appropriate. LISTSERV's rationale is that the "Validate=" keyword describes the desired behavior for interaction with the list owner and people who can be expected to use the list on a regular basis. SIGNOFF requests and DELETE requests from registered node administrators on behalf of a user on their machine, for instance, may be validated using the "OK" mechanism even though that was not requested, because users and node administrators are not generally expected to have a password with which to validate such requests.

Subscription Keywords

Confirm-Delay= number

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 1.8b and following, 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. Default-Options does not affect existing subscribers.

A typical Default-Options setting might be:

* Default-Options=Nofiles,Norepro,Msg

Default-Topics= topic1,topic2,...
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 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.
Subscription= By owner | Closed | Open [,Confirm]
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: The users are allowed to subscribe to the list.

By owner: The users are not allowed to subscribe, but their requests will be forwarded to the list owner. This is the default.

Closed: The users are not allowed to subscribe, and their requests are not to be forwarded to the list owner.

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).

Other Keywords

Categories= <category1>,<category2>,...<categoryn>

Note: the full list of categories may not be available when version 1.8c is released.

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.

Indent= number

Determines the minimum number of columns allowed for list addresses in response to the REVIEW command. The default is Indent= 40.
Language= idiom
Defines the language in which information mail and messages are to be sent to subscribers of the list. The postmaster must have provided the required data file (called idiom.MAILTPL, where idiom is the name of the language specified by this keyword) to the server. The default language is "English", of course.

L-Soft does not provide non-English templates.

Long-Lines= Yes | No
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.
Limits= Sub(number),...
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, e.g.,

* 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.

Translate= Yes | No
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".

Default Values for all keywords

Ack= No
Auto-Delete= No if "Validate= Yes", Yes,Delay(4),Max(100) otherwise
Categories=
Confidential= No
Confirm-Delay= 48
Daily-Threshold= 50
Default-Options= <none>
Default-Topics= <none>
Digest= Yes,Daily,Same 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
List-Address= <none> (per LIST_ADDRESS system default)
List-ID= <none>
Local= <none>
Long-Lines= Yes
Loopcheck= Full
Mail-Via= DISTRIBUTE
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>
Reply-To= List,Respect
Review= Private
Safe= Yes
Send= Public
Sender= List
Service= *
Sizelim= <none>
Stats= Normal,Private
Subject-Tag=
Subscription= By Owner
Topics= <none>
Translate= Yes
Validate= No
X-Tags= Yes

[next chapter] [previous chapter] [table of contents]