In article <[log in to unmask]>, "Noel P. Hart"
<[log in to unmask]> says:
>
>Does anyone know where I can get documentation, explanation and syntax,
>on *all* the keywords LISTSERV recognizes in a list header ?
>
>At the moment I need to find out about the 'Filter=' keyword.
>If anyone can help I would appreciate it.
Instead of asking multiple times, why not review the logs of LSTSRV-L
and search for Filter= ? In any case, here's my 'patched' version of
LISTKEYW MEMO. When I needed to know what a keyword did which wasn't in
the MEMO, I searched through Eric's announcements and appended to our
MEMO file.
Bob Jackiewicz [\] UIC Computer Center E-mail: [log in to unmask]
University of Illinois at Chicago Network Services
Speed Kills - Use Windows!
Revised List Processor (LISTSERV@FRECP11), Release 1.5d
----------------------------------------------------
(c) Eric Thomas 1986 Ecole Centrale de Paris
*******************************************
* *
* A description of list header keywords *
* *
*******************************************
19931107 BobJ Added 'Renewal' keyword info. Removed 'Extended' option
for 'Stats' keyword.
19931214 BobJ Removed 'Formcheck' keyword info. Removed in 1.7d.
19940105 BobJ Added "Default-option" keyword information
19940314 BobJ Added Filter=, Topics=, Default-Topics= keywords
19940701 BobJ Added Digest= keyword description
This document is a description of the list control keywords that appear
in the header of each list. Whenever default values are supplied for the
keywords, they are listed first in the description. Words enclosed in
parenthesis are "generic parameters" which define a set of possible
values for a keyword operand, as described below:
Generic parameters
------------------
(net-address): Describes a RFC822-compatible network address,
usually of the "[log in to unmask]" form.
(access-level): Controls which category of users has access to
the information or service to which this para-
meter applies. (access-level) can be either:
Public Everybody has access to the information.
Postmaster Only the postmaster (ie LISTSERV operations
staff) has access to the information.
A1,A2,... with Ai being either:
Private Only users subscribed to the list
have access to the information.
(listname) Only the members of the specified
list have access to the info.
Owner Only the list owner can access
the information.
Owner(list) Only the owner of the indicated
list can access the information.
Service Only people in the service area
of the list can see the info.
Service(list)
(destination): Indicates the destination of a piece of mail,
message or reply. Depending on the type of
reply, all the options listed below might not
be effective. For example, "Reply-to= None" is
functionally identical to "Sender", whereas
"// JOB Reply-to=None" (in a batch command
file) would actually suppress all replies.
List The reply message is sent to the list.
Sender The reply message is sent to the sender of
the original piece of mail.
! Both The reply message is sent both to the list
and to the original sender.
None No reply message is sent at all.
"address" The reply message is sent to the specified
network address if enclosed in double quotes
(interval): Is a time interval that indicates how frequent
ly an operation is to be renewed. Note that
depending on the operation being performed,
some of the options may not be available. For
example, "Notebook= Yes,A,Daily" is not avai-
lable.
Yearly
Monthly
Weekly Self-explanatory
Daily
Hourly
Single The operation is to be done only a single
time.
|(peer): Is the node-id or network address of a peer
| list server. If the name of the peer list is
| the same as the name of the local list (which
| will usually be the case), only the node name
| needs be given. If the list names are diffe-
| rent, the full list network address must be
| given, eg "REXX-L@UIUCVMD".
|
|
|(area): Is a means whereby a node or list of nodes can
| be identified. An area can be either:
|
| - The name of a network, eg EARN, BITNET
| - The name of a country, eg Germany, Canada
| - 'Local', in which case it is equated to the
| value of the "Local=" keyword (qqv).
| - A node name, eg FRECP11
| - A simple wildcard nodename pattern such as
| FR*, *11, *ESA*, D*ESA*, etc
|
|
|(mon-address): Is a means whereby 'list monitors' can be iden
| tified (the term 'list monitor' refers to a
| human person who monitors the activity of a
| list). A 'mon-address' can be:
|
| - A single network address, eg INFO@TCSVM
| - 'Postmaster', which indicates the "main"
| postmaster
| - 'Postmasters', which indicates ALL the post-
| masters, main and alternate
| - 'Owner', which indicates the "main" list
| owner (the first to be listed in the
| "Owner=" keyword)
| - 'Owners', which indicates ALL list owners
! Whenever several keywords or operands are accepted, they will be
! separated by a logical OR sign (|). Unless specified otherwise, commas
! have "higher priority" than OR signs, that is to say, "Public|Private,
! Open|Closed" means "(Public|Private),(Open|Closed)", not "Public|
! (Private,Open)|Closed".
List control keywords
---------------------
**************************
* Review= (access-level) *
**************************
This keyword defines the category of users who are allowed to review
the network addresses and names of the persons subscribed to a list.
The default value is "Public".
******************************************
* Subscription= By_owner | Open | Closed *
******************************************
This keyword defines whether or not new users are allowed to subcribe
to the list, and if not, whether their subscription requests are to be
forwarded to the list owner or not.
Open: The users are allowed to subscribe to the list.
By_owner: The users are not allowed to subscribe, but their requests
will be forwarded to the list owner. This is the default.
Closed: The users are not allowed to subscribe, and their requests
are not to be forwarded to the list owner.
*********************************
* Send= (access-level) | Editor *
*********************************
Defines the category of users who can mail or send files to the list.
Possibly puts the list under control of an editor. The default value is
"Public". When the list is controlled by an editor, any file or piece
of mail sent to the list is forwarded to the editor, who is the only
person (with the list owner) to be able to actually mail or send files
to the list. The network address of the editor is defined by the
"Editor=" keyword (see below).
********************
* Notify= Yes | No *
********************
Defines whether the list owner is to receive notification of new
subscriptions and deletions, etc. The default is "Yes".
********************************************
* Reply-to= (destination),Respect | Ignore *
********************************************
Indicates whether the "Reply-to:" tag supplied by the sender of the
mail file is to be preserved or discarded (if present), and, if discar-
ded or omitted, what should be placed in the new "Reply-to:" generated
! by the server. The default value is "List,Respect". Note that some
! mailing systems are unable to process a "Reply-To:" field with multiple
! addresses correctly and may therefore disregard the "Reply-to= Both"
! option and treat it as "Reply-to= List".
Respect: The original "Reply-to:" tag, if any, is kept.
Ignore: The original "Reply-to:" tag is ignored and discarded.
*******************
* Files= Yes | No *
*******************
Indicates whether files can be sent to the list or not. The default
value is "Yes".
************************************
* Confidential= No | Yes | Service *
************************************
! Indicates whether the list should be hidden from users or not. A con-
! fidential list will not appear on the "List" command output. "No" is
! the default value and indicates that the list is not confidential.
! "Service" indicates that the list is to be hidden from users who are
! not in the list's service area (see "Service=" keyword) but not from
! other users. "Yes" means that the list is unconditionally confidential.
***************************************
* Validate= Store only | All commands *
***************************************
Under Revised LISTSERV, lists are protected by a password which must
be specified by the list owner when he sends an updated version of the
list back to the server. When "Validate= All commands", password valida
tion applies to ALL the commands that modify the contents of the list,
eg SIGNOFF, SET, etc. This implies that users cannot use these commands
since they do not know the list password. A notable exception is the
SUBscribe command, which can still be used (if enabled) to get on the
list; however, sending a second SUBscribe command for the same list (to
correct a spelling error in your name) would result in the command
being forwarded to the list owner and not immediately executed. This is
to protect you from UREP hackers who might issue a command "from" your
userid@node to change the name under which you appear on the list to
! something impolite. The default is "Store only", but it is recommended
! that "serious" or "important" lists be changed to "Validate= All
! commands".
******************************
* X-Tags= Yes | No | Comment *
******************************
Indicates whether "X-To:" and "X-cc:" tags are to be included in the
output mail files to list recipients of the original mail file (other
than the list userid) or not, and how they should appear in the RFC822
header.
Yes: This information must be provided in the form of "X-To:"
and "X-cc:" tags in the RFC822 header (similar to the
"To:" and "cc:" tags). This is the default.
Comment: This information must be provided in the form of "Comment:"
tags, ie "Comment: X-To:" and "Comment: X-cc:".
No: This information must not appear at all in the mail haeder.
***************************************
* Stats= Normal | None,(access-level) *
***************************************
Indicates whether or not statistics are to be maintained for the list
and if yes, which level of statistics is desired and who is able to
retrieve the statistics reports. The default value is "Normal,Private".
Normal statistics include number of mailings, number of outbound mail
files, and total number of outbound 80-character records, for each user
on the list, and a similar information for file distribution.
***********************
* Ack= Yes | Msg | No *
***********************
Defines the default value of the "ACK/NOACK" distribution option for
the corresponding list, ie the value assigned to new users when they
subscribe to the list. This value can be altered by subscribers ("SET"
command), but not by users who are not signed on to the list. This
means that this option will always be in effect when distributing mail
from people who are not on the distribution list.
Yes Messages will be sent when your mail file is being proces-
sed. Additionally, a short acknowledgment with statistical
information on the mailing will be sent back to you, in
case a link failure prevented you from receiving the messa
ges. This is the default.
Msg Messages will be sent when your mail file is being proces-
sed. Statistical information will be sent via messages,
but no acknowledgment mail will be sent.
No A single message, but no acknowledgment mail nor statistics
will be sent when your mail file is being processed.
****************************************************************
* Notebook= No | (Yes,(fm),(interval)|Separate,(access-level)) *
****************************************************************
Indicates whether or not an automatic log of every piece of mail sent
to the list is to be kept, and defines at which interval of time its
file name must be changed and who is allowed to retrieve it from the
server. The default values are "Notebook= No,A,Single,Private".
(fm) Is the filemode of the disk on which the notebook is to be
kept. This information is of little importance to users,
except perhaps to the users of the server's host computer
who might, in certain circumstances, be allowed to LINK to
one of the server's disks (containing public information).
Contact the local LISTSERV operation staff for more infor-
mation.
(interval) Defines the filetype of the "notebook" file for the list,
as indicated below (the filename will always be the same
as the list name):
Single: A single file of filetype "NOTEBOOK" is created.
Yearly: A new file is started each yearly, filetype is "LOGyy"
Monthly: The filetype is "LOGyymm"
Weekly: The filetype is "LOGyymmw" (w in "A"-"E")
Separate: A separate file is kept for each mailing (eg digests).
The filetype is "yy-nnnnn" (sequential counter).
!
! Note: notebooks can now be retrieved by means of the GET command. A
! list of all available notebooks can be obtained with a GET
! NOTEBOOK FILELIST command.
*********************************************
* Owner= (net-address1)|(access-level1),... *
*********************************************
Defines the person or list of persons who "own" the list. They are
responsible for controlling access to the list and defining the list
control keywords which are best suited to the purpose of the list. The
! default value for this keyword which should ALWAYS appear in the list
! header is the list of the userids of the postmasters. Any combination
! of explicit network addresses and complex access-levels is acceptable,
! for example: Owner= BIG@BLUE,(STAFF-L),Owner(MAIN-L)
!
! An interesting application is to create a STAFF-L list containing the
! userids of all the local LISTSERV staff members and set the "Owner="
! keyword of all local lists to "Owner= (STAFF-L)". This way when there
! is a change in the local LISTSERV management it is not necessary to
! modify the headers of all the lists -- just modify the STAFF-L list.
*********************************************
* Editor= (net-address1),(net-address2),... *
*********************************************
Defines the list editor(s). When used in conjunction with the "Send=
Editor" option, it causes all mail sent to the list to be automatically
forwarded to the first person listed in the "Editor=" keyword, who will
then send it back to the list at his discretion. The editors are the
only persons (with the list owners) who are allowed to mail directly to
the list. Note that ANY editor can send mail to the list while only the
FIRST one will receive copies of mail sent to the list.
!
! The file will be forwarded to the editor 'as is', without being inclu
! ded in a mail envelope. This method makes sure that the original
! "Resent-" tags (if any) and "To:" keyword are preserved. BITNET editors
! will receive the forwarded mailfile in their mailbox in Netdata format
! (or whatever is the default format for their operating system), while
! non-BITNET editors will receive it via their mailing system with an
! extra mail envelope being generated to enclose the original (unaltered)
! mailfile.
!
! IMPORTANT NOTE: The editor MUST be a human person, not a file server,
! list server, mailer, or suchlike. Specifying a program's mailbox as
! "Editor=" could result in a mailing loop for which the author could not
! be held responsible.
*******************
* Language= idiom *
*******************
| Defines the language in which information mail and messages are to be
| sent to subscribers of the list. The postmaster must have provided the
| required data file to the server, of course. The default language is
! "English", of course.
> Currently only information mail is available in several languages. A
> further release might incorporate customized messages by using the
> :country tag in BITEARN NODES to determine the idiom to be used.
******************************
* Peers= (peer1),(peer2),... *
******************************
| Defines the (global) list of all the servers in the world that are
| peer-linked to the list, either directly or via one or more other peer
| servers. This information is used by the various list management com-
| mands to determine the "nearest" peer list to a given user. For exam-
| ple, when a SUBSCRIBE command is received from a user and it is deter-
| mined that there is a better (nearer) peer list for him, the subscrip-
| tion request is automatically forwarded to the appropriate LISTSERV.
********************************
* Service= (area1),(area2),... *
********************************
| Defines the 'service area' outside of which subcription requests
| must not be accepted. When a SUBSCRIBE command is received, the
| "Peers=" keyword is checked first to see if there is a nearer peer
| list in the network. If it is the case, the command is forwarded to
| this nearer server. If not, the service area is checked to ensure that
| the recipient is acceptable; if it is not, the subscription request is
| denied. When the command is forwarded, the destination server might
| still deny access to the list if the subscriber is outside its own
| service area, if any.
|
| It is important to note that the service area check is made only
| after the "best placement" check. This allows several servers in the
| same country to share an identical service area, eg "Service= Germany",
| and still have users subscribed to the best possible server.
**************************
* Local= node1,node2,... *
**************************
| Defines the nodes which are to be considered as 'local nodes' for
| both service area checking and mail header grouping. The local node is
| automatically considered as a 'local node' and does not have to appear
| in the list. Subscribers from any of the local nodes will receive
| separate pieces of mail with a single recipient in the "To:" field --
| in other words, they will never receive a grouped piece of mail as
| non-local recipients would if there are more than one recipient in
| their node. Note that 'node' is a generic term that means "anything
| after the '@' sign in the network address". For instance, "FRECP11"
| and "VAX2.LAB1.LAN" are both valid node names.
************************************************
* Errors-To= (mon-address1),(mon-address2),... *
************************************************
| Defines the person or list of persons that are to receive rejection
| mail for the list. The default value is 'Postmaster', and it is recom-
| mended that the owners change it to 'Owners' or 'Owners,Postmaster' as
| soon as they become familiar with Revised LISTSERV.
************************************************
* Renewal= None | item1<,item2<,...>>,Delay(n) *
************************************************
The list owner can place a list in automatic expiration mode by providing a
"Renewal=" keyword in the list header. The default is NOT to require
subscription renewal (this can also be specified by means of "Renewal= None").
Each 'item' can take any of the following forms:
- An 'interval' specification, of the form:
<factor->period
Where 'period' can be either 'Monthly', 'Yearly' or 'Weekly' and the
optional factor is a number by which the period will be multiplied. The
special factor 'Bi-' indicates that the period is to be halved. Thus,
'6-Monthly' and 'Bi-Yearly' both indicate an interval of 6 months. Note that
the dash is mandatory.
Whenever more than one interval is specified, the most restrictive (ie
smaller) one will be retained. It may sound stupid to specify "Renewal=
Yearly, Bi-yearly, Monthly", but this allows a postmaster to enforce a
stronger renewal period in the local header portion of (future) peered lists
if he so desires.
- An absolute date, of the form yy/mm/dd, mm/dd or just dd. The first one is
just what it is, the second one means "every year on the mm/dd", and the
last one means "every month on day dd". This is useful if you know when your
students' accounts are going to expire. Whenever more than one expiration
date is specified, the most restrictive one (ie 'most recent') is retained.
This allows each postmaster to add the expiration dates of his own students'
accounts to his local copy of the list.
- "Delay(n)", which defines the minimum delay in days between the time the
user is asked to confirm his subscription and the time he is automatically
removed from the list. The actual kickoff delay might be more than this
number (see below), but not less. The default is one week (ie 7 days). The
most restrictive value takes precedence whenever more than one occurence of
the keyword is found.
For each user and each list, the date of the last subscription/change in the
subscription (SET) is kept. A new procedure, LSVEXPIR, must be added to the
WAKEPARM FILE to check all these values against the "Renewal=" keyword in the
list headers. Since this procedure eats a lot of CPU time (each user on each
list must be checked), I don't recommend running it more than once or twice a
week. It should, however, be invoked at least twice a month. If your CPU is
idle at night, then you can probably run it every day without problem. You can
also activate it manually ("CMS LSVEXPIR") without problem.
**************************************************
* Default-Options= (option1),(option2),... etc.. *
**************************************************
The list owner can set up default settings for various list options for users.
The option can be any of the valid options a user may set him/herself, such as
NOACK and REPRO. The user can change their option at a later time with the
SET command
*****************************************
* Filter= (Only | Also | Safe) patterns *
*****************************************
Gives the list owners better control over troublesome users or
gateways, and removes the generic ban on some traditionally reserved
usernames such as 'root' or 'postmaster', and
supplement the SERVE OFF mechanism (which is restricted to the
LISTSERV maintainer and affects all lists on the server).
It 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
(similar to the one used by 1.7e) 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' or 'postmaster' 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; 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. In fact, 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. This may cause some extra traffic while LISTSERV and various
gateways engage in ping-pong wars, but after 10 iterations the gateways
will be served off and this will stop.
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 [log in to unmask], LISTSERV
will check [log in to unmask], [log in to unmask] and
'mailer@searn' (via the 'internet.' tag). Generally speaking, userids
intercepted by the 1.7e filter will not pass the safe 1.7f filter.
************************
* Default-Topics= list *
************************
See Topics= keyword.
**************************
* Topics= topic_list,... *
**************************
List topics provide a way to run a mailing list (preferrably 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:
- A list of all the topics the user wishes to receive. In that case these
topics replace any other topics the user may have subscribed to before.
For instance, after 'SET XYZ-L TOPICS: NEWS BENCH', the user will
receive news and benchmarks, and nothing else.
- Updates to the list of topics the user currently receives. A plus sign
indicates a topic that should be added, a minus sign requests the
removal of a topic. For instance, 'SET XYZ-L TOPICS: +NEWS -BENCH' adds
news and removes benchmarks. If a topic name is given without a + or -
sign, + is assumed: 'SET XYZ-L TOPICS: +NEWS BENCH' adds news and
benchmarks. The first topic name must have the plus sign to show that
this is an addition, and not a replacement.
- A combination of the above, mostly useful to enable all but a few
topics: 'SET XYZ-L TOPICS: ALL -MEETINGS'.
The colon after the keyword TOPICS: is optional, and TOPICS= is also
accepted. Do not forget to include the special OTHER topic if you want to
receive general discussions which were not labelled properly. On the
other hand, if you only want to receive properly labelled messages you
should not include it. ALL does include OTHER.
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.
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. Depending on the success of topics support, this
restriction might be lifted in a future release.
*******************************************************
* Digest= No | (Yes,(where),(frequency),(when),(max)) *
*******************************************************
indicates that digests of the mailing list should be kept or not, and
when they should be sent out. The defaults for a digest are to send
it out once daily, at midnight. The default for archived lists is
Digest= Yes,Same,Daily and Digest= No for non-archived lists.
(where) Is the filemode of the disk on which the digest is to be
kept. This information is of little importance to users,
except perhaps to the users of the server's host computer
who might, in certain circumstances, be allowed to LINK to
one of the server's disks (containing public information).
Contact the local LISTSERV operation staff for more infor-
mation. This information is the same as the "Notebook="
keyword, or "Same" which means that the digest must be
stored on the same disk as the list archives.
(frequency) Is either "Daily" (the default), "Weekly" or "Monthly".
(when) 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
not get a digest every month.
(max) Is optional and takes the form "Size(nnnn)" and specifies
the maximum size the digest is allowed to reach before a
"special issue" is cut. Bear in mind 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 will 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.
|
