For more information on these features, also see the
List Keyword Reference document.
You can control the default level of acknowledgement sent back to users when they post to the list with the "Ack=" list header keyword (see the
List Keyword Reference document for details). This is particularly important because it also controls the acknowledgement level for users who are not subscribed to the list and cannot, therefore, set personal options. While the value set for "Ack=" can be overridden for subscribers both by the setting of the "Default-Options=" keyword (which sets the default at subscribe time) and by the "SET" command, this option will always be in effect when distributing mail from people who are not subscribed to the distribution list.
You can control the maximum number of postings per day per subscriber on a list-by-list basis by setting the new (optional) second parameter of the "Daily-Threshold=" list header keyword. The default is to have no such limit.
If set, when the per-subscriber threshold is reached, the subscriber is told that his message cannot be processed because he has reached the limit for today, and that he should repost his message at a later time. The counter for this limit resets to zero at midnight for all lists.
This feature reserves certain times and days of the week when you don't want LISTSERV to process postings. Although this is not usually necessary today, there can be certain applications for the use of the "PRIMETIME=" site configuration variable and the "Prime=" list header keyword.
Note: To all intents and purposes, this option is obsolete. It was originally designed for mainframe environments in which job scheduling was critically important, so that LISTSERV could process large jobs during non-"prime" time and not be a load on the processor during "prime" time. Therefore, and perhaps counter-intuitively to some, it defines the time period during which LISTSERV SHOULD NOT process the job. In LISTSERV 1.8e, the AFTER= RFDR job card option was added to LISTSERV to help with scheduling jobs that should be held until a particular time and then released. Therefore, the use of PRIME= is deprecated for that type of job.
"PRIMETIME=" controls the server-wide prime time setting. By default it is set to MON-SUN: -. There should be no need to change this setting under normal circumstances. Please see the entry for PRIMETIME in the
Site Configuration Keyword Reference document
for further details.
The list header keyword "Prime=" controls prime time on a list by list basis. By default it is set to "Prime= Yes", meaning that it does not observe the PRIMETIME= variable. If explicitly set to "Prime= No", the value in the PRIMETIME= variable will be observed. It can be set to an explicit time definition if necessary. For instance, you might have a very large announce-only list (e.g., a newsletter) that should not be posted until after midnight (when network traffic is low and more machine resources are generally available). You might wish to set this list with a "Prime=" setting of
The specification for "Prime=" must be enclosed in double quotes and the format (spaces) should be identical to the examples. In addition, 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
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.
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.
Mail sent to lists during prime time is automatically held until non-prime time and then distributed normally, without requiring further intervention by anyone. This means that the newsletter editor of the example list can post their next issue on Friday afternoon and know that it won't be distributed until Saturday at midnight or shortly thereafter.
One of the most common misconceptions regarding the prime time settings is that prime time is the time during which LISTSERV will process postings for your list (or globally for the server if you change "PRIMETIME="). Please remember that when you set a "prime time" either for a list or globally for the entire server, 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.
Notes: The default value for seconds in a PRIME time specification is zero. Therefore, specifying "00:00-23:59" is equivalent to specifying "00:00:00-23:59:00", not "00:00:00-23:59:59", and, in this example, there is actually a one-minute "window" each night between 23:59 and 00:00 in which an arriving job could be processed. You may code the seconds in the time specification if it is vitally important that no mail be processed during that one-minute "window".
On occasion, LISTSERV will automatically "hold" a list, i.e., postpone processing new mail for the list until either the list owner or the LISTSERV maintainer manually intervenes. There are two circumstances under which a list will be automatically held:
to LISTSERV. However, note that for any hold, it may be wisest to wait until the LISTSERV maintainer has had a chance to check the server for anything untoward that might be causing the error (e.g., a mailing loop) before freeing the list.
Note: An error indicating that the current notebook archive LOG file is open and locked by another process may actually indicate that the archive file is in a directory accessible by anonymous FTP and that someone is in the process of FTPing the current notebook archive, making it impossible for LISTSERV to append the latest posting to the current notebook. This error generally occurs only on systems with FTPable notebook archives; by the time you receive the error, it is usually safe to issue the FREE command to release the list. If, on the other hand, this error persists, you may want to check the server for "zombie" processes that may have the file locked, or set the location parameter of the "Notebook=" keyword to a non-FTPable directory.
List "digests" are provided for those users who prefer to receive (typically) one large, comprehensive posting per digest period that includes all of the list traffic from that period, rather than receiving each post individually as processed by the server.
If "Notebook= Yes...", the digest feature defaults to daily digests cut at midnight with the "work" files kept in the same directory as the list's notebook archives. If "Notebook= No", digests are not enabled by default. However, note that lists without notebook archives can have digests; it is simply necessary to enable digests manually for such lists by using the "Digest=" list header keyword and specifying a valid path for the location of the digest's work files.
Digests can be set up to cut on a Daily, Weekly, or Monthly basis, and can be further configured to cut after a certain number of lines of data have been stored regardless of the digest period setting. This ability to generate "special issues" when the digest reaches a certain size may be necessary if people complain that your 10,000 line daily digest is getting truncated by their mail host to 1500 (or even 1000) lines.
For example, if a high volume list is set for Daily digests, and the "Size(nnn)" parameter of the "Digest=" keyword for the list is set to "Size(1000)", a "special issue" of the digest will be cut and mailed to digest subscribers whenever the listname.DIGEST file reaches 1000 lines of text. Note that LISTSERV will not cut the digest at exactly 1000 lines, thereby truncating the last message; LISTSERV will cut the digest after the end of the message that causes the digest file to go over its limit. Thus, if the digest file is 950 lines long and a 200 line message is received, the "special issue" digest will be 1150 lines long.
List topics provide powerful "sub-list" capabilities to a list. When properly set up and used, topics give subscribers the ability to receive list postings in a selective manner, based on the beginning of the "Subject:" line of the mail header. It is important to note the following points about topics:
|
•
|
Topics are best employed on moderated lists. This makes it possible to review the "Subject:" header line to make sure that it conforms to one or more of the topics defined for the list before you forward the post to the list. Not only does this help catch simple errors (such as misspellings of the topic), but it also allows the moderator to add a topic into the subject line if one is not already there.
|
|
•
|
If you employ topics on unmoderated lists, your subscribers must be well-educated in their use. Otherwise, there is no point in using them. Messages that do not conform to a specified topic are lumped into the reserved topic "Other" and are distributed only to subscribers who have explicitly defined "Other" as a topic they wish to receive. Therefore some subscribers will receive the message and some won't, and it is problematic as to whether the message will actually reach the entire audience for which it is intended.
|
where xxx,
yyy, and
zzz can be:
|
•
|
Updates to the list of topics the subscriber currently receives. A plus sign indicates a topic that should be added, a minus sign requests the removal of a topic. For instance, "SET XYZ-L TOPICS: +NEWS -BENCH" adds news and removes benchmarks. If a topic name is given without a + or - sign, + is assumed: "SET XYZ-L TOPICS: +NEWS BENCH" adds news and benchmarks. The first topic name must have the plus sign to show that this is an addition, and not a replacement.
|
The colon after the keyword TOPICS: is optional, and TOPICS= is also accepted. The subscriber should 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 the subscriber only wants to receive properly labeled messages it should not be included. ALL does include OTHER.
Finally, it is important to note that topics are active only when the subscriber's subscription is set to MAIL. Digests and indexes always contain all the postings that were made, because the same digest is prepared and sent to all the subscribers.
See the List Owner’s Manual and the
List Keyword Reference document for more information on setting up and using list topics.
LISTSERV includes a MIME attachment-filtering feature which is configured by setting the Attachments= list header keyword. The keyword as first introduced allowed three distinct modes:
In addition, you could configure specific MIME types to reject or filter while allowing other types through (for instance, you could block executable files but allow images or word processing files based on their MIME type).
In addition, the Attachments= keyword supports adding a filter for non-MIME, inline uuencoded files such as are sent by mail clients like Microsoft Outlook. The uuencode filter is strictly on/off; no attempt is made to determine the file type of such inline "attachments".
