Configuration-Owner= conf_owner[, conf_owner2][,...]
This feature and keyword are not available in LISTSERV Lite, and can only be set by the LISTSERV maintainer.
This new (optional) keyword defines which of the list owners, defined in the Owner= keyword setting, are authorized to change the list configuration. It is a LISTSERV ACL, much like "Review=", or "Send=" (if you disregard the special options that are specific to "Send="). The default value is "Configuration-Owner= Owner", which allows all addresses and access-levels listed in Owner= to modify the list header.
Note carefully that list owners who are not Configuration-Owners retain the right to change templates, add and delete users, change user options, GET and PUT archive files, and so forth. The setting of Configuration-Owner for a given list restricts only the ability of non-Configuration-Owners to change the list header.
The definition of a conf_owner is a sub-set of access_level. Valid conf_owners are
Owner
Postmaster
net-address (for instance, user@host.com)
Owner(listname)
(listname)
Examples:
Configuration-Owner= Postmaster,(configownerlist)
Configuration-Owner= Owner,Owner(otherlist),joe@example.com
Configuration-Owner= (configownerlist)
Configuration-Owner= sarah@example.com,joe@example.com
The purpose of this keyword is to make it easier for LISTSERV administrators to manage non-technical list owners. It allows the LISTSERV maintainer to create a list where the owner can manage subscriptions normally, but cannot make changes to the list configuration.
It is also possible with this keyword to create a separate mailing list of LISTSERV users who do not have full LISTSERV maintainer privileges, but can manage lists other than those they might own explicitly on the same server.
Please note carefully that any addresses specified in Configuration-Owner= must also be specified (either explicitly or as part of an access-level definition) in the Owner= setting for the list.
Editor= net-address1,net-address2|access-level1,...
Defines the list editor(s). When used in conjunction with the "Send=Editor" option, it causes all mail sent to the list to be automatically forwarded to the first person listed in the "Editor=" keyword, who will then send it back to the list at his discretion. The editors are the only persons (with the list owners) who are allowed to mail directly to the list. Note that ANY editor can send mail to the list while only the FIRST one will receive copies of mail sent to the list (but see also Moderator=).
The file will be forwarded to the editor 'as is', without being included in a mail envelope. This method makes sure that the original "Resent-" tags (if any) and "To:" keywords are preserved.
Note that the first editor MUST be a network address (e.g., someuser@foo.bar.com) and not an access-level. Subsequent editors may be access-levels. For instance, you can code
* Editor= joe@baz.net,(MYLIST-L)
which allows all subscribers from the MYLIST-L list to post without going through the editor, and diverts all non-subscriber mail to joe@baz.net for approval.
IMPORTANT NOTE: The first editor SHOULD be a human person, not a file server, list server, mailer, or suchlike. Specifying a program's mailbox as the primary editor could result in a mailing loop for which L-Soft international, Inc., could not be held responsible.
ALSO PLEASE NOTE: In many support cases it has been noted that lists are often coded with "Editor= Owner" or "Editor= Owners". Prior to LISTSERV 14.3, this would have caused LISTSERV to generate approval request messages to an address such as OWNER@.BITNET, which of course would not be deliverable. LISTSERV 14.3 and later will now avoid this problem and when encountering either of these cases will default to sending the approval request to the first listed non-quiet list owner. L-Soft continues to recommend NOT using either "Owner" or "Owners" as the primary editor of the list, as it is not always the case that the list owner should be the primary (or only) editor.
Finally, please note that the NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
Editor-Header= Yes | No
This keyword is not available in LISTSERV Lite.
If an editor is defined (see Editor=), this keyword determines whether or not special header information is prepended to list messages forwarded to the editor. The default (for lists configured with an Editor) is "Editor-Header= Yes".
Note that Editor-Header= No is ignored if you have Send= Editor,Hold or Send= Editor,Hold,Confirm . In these cases the editor-header information is required so as to provide the confirmation code for the OK command.
List-Address= name_info[@host_info]
This keyword is not available in LISTSERV Lite.
This keyword determines how LISTSERV announces its list address in the header of messages delivered to the list: NJE vs. Internet address, short vs. long list name, etc. The default options (when neither "List-Address=" or LIST_ADDRESS are defined) are long list name and Internet address. A corresponding LIST_ADDRESS configuration option must be added to the LISTSERV site configuration file.
It is important to note that the only effect of the "List-Address=" keyword is to change the way the list identifies itself in list postings, command replies, etc. It does not instruct the mail system to create forwarding entries to support the new name, nor does it establish the specified name as an alias for the list (use "List-ID=" for this purpose). In general list owners should not use this keyword without first consulting with the LISTSERV maintainer.
In 1.8b and earlier versions, the first token (name_info) may be either LISTNAME or LIST-ID. Do not attempt to specify the actual list name. Use LISTNAME if you want LISTSERV to use the "short" list name (always available), and LIST-ID if you would rather see the "long" list name ("List-ID=" keyword). If there is no "long" name, the short name is substituted.
Version 1.8c introduced the ability to specify the name of the list in the first token (i.e., you may now specify something like "List-Address= XYZ-L@XYZ.EDU").
The second token (host_info) can be either NJE, FQDN, or the fully qualified domain name of your choice. That is, you may type the actual hostname that you want LISTSERV to use, which may be useful if the machine on which LISTSERV is running is known under several hostnames.
If you only want to override one of the two parts of the list address, you do not need to specify the other. For instance, if you only want to change the hostname, you can enter "List-Address= XYZ.EDU" in the list header and let the left-hand part default from the value of the system default in the LISTSERV configuation file. Similarly, "List-Address= List-ID" takes the right-hand part from the system default. To avoid bad surprises, LISTSERV will also accept a comma in lieu of @-sign in the list header, or a blank in the LISTSERV configuration file. Here are a few examples:
"List-Address= FQDN" announces the list under the Internet address for the LISTSERV host, if one is available (for BITNET-only sites this setting has no effect).
"List-Address= List-ID@FQDN" uses the long list name and the Internet hostname.
"List-Address= Listname@XYZ.EDU" uses the short list name and the hostname XYZ.EDU.
Starting with version 1.8c, "List-Address= XYZ-L@XYZ.EDU" is also valid. You no longer are restricted to specifying LISTNAME or LIST-ID for the left-hand (username) part.
List-ID= longlistname
This keyword is not available in LISTSERV Lite, and is technically obsolete on all ports of the software except for VM.
On VM systems, this keyword allows the list owner to specify a long list ID in addition to the normal 8-character list name. This is particularly useful for peered or gatewayed lists that have names longer than 8 characters. On non-VM systems, if the normal list name is longer than 8 characters and the list is being migrated from a VM system, it may be a good idea to specify the first 8 characters of the list name in this keyword, at least temporarily. This way, subscribers who were used to the old 8-character name can continue to use it on the new system.
Non-VM systems may use this keyword for aliasing. However, today there is really no good reason to use this keyword on non-VM systems, as it is possible to define lists on such systems with native file system names longer than 8 characters. L-Soft's recommendation is that this keyword be used only if you are migrating a list from VM that was known by both its "short" name and its "long" List-ID= name. (On unix you can avoid this by simply specifying an extra set of aliases in /etc/aliases for the "long" name that point to the same places as do the ones for the "short" name.)
In any case a list owner should not set a value for List-ID= without first consulting with the LISTSERV maintainer, since it will be necessary to add appropriate system mailer aliases before the name specified in List-ID= will work.
List-ID= will not work properly on Windows 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 Windows and VMS systems running L-Soft's legacy mailer LSMTP, but you must first configure a route in LSMTP for the List-ID= name so that LSMTP will know to deliver mail addressed to the List-ID= address to LISTSERV (as opposed to POP or SMTP, etc.).
Under OpenVMS and unix, it is necessary to add the appropriate aliases to the mailer's aliases file in order for List-ID= to work, since mailers such as sendmail and PMDF otherwise have no way to know that the name specified in List-ID= is a valid address. This means that lists that have the List-ID= keyword specified need two complete sets of aliases defined (unless List-ID= is identical to the list name, in which case it should not be implemented to begin with).
Starting with LISTSERV 1.8d, if you do use List-ID= to specify a "long" name for a list with web archives, LISTSERV will create an HTML page for both the long and short names. Here again, however, on non-VM systems L-Soft does not recommend the use of List-ID= .
Moderator= [All,]netaddress1[,netaddress2]...
This keyword is not available in LISTSERV Lite.
This keyword defines which editors of a moderated list receive postings for forwarding to the list. The default is the first editor as defined by the "Editor=" keyword. If multiple moderators are defined, the load is spread across them.
Note that all editors may still post directly to the list, but only those editors defined by "Moderator=" will have messages from non-editors forwarded to them.
Beginning with 1.8c, if the parameter "All" is coded before the list of moderator addresses, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be
* Moderator= All,joe@somehost.com,jill@someplace.net
Note that this could also be coded as:
* Moderator= All,joe@somehost.com
* Moderator= jill@someplace.net
Assuming "Send= Editor,Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that an identical message has already been posted to the list.
If "Send= Editor" (i.e., without "Hold"), please note that if a note is appended or prepended to the edited post, or if the body of the post itself is edited (that is to say, if the body of the approved message is changed), duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator.
Finally, please note that the NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
New-List= net-address
This keyword is not available in LISTSERV Lite.
When a list is moved to a different LISTSERV host, this keyword can be added to the list header left on the original host. This facilitates forwarding of administrative commands and postings from the original host to the new host. Users posting to the old address will also receive a short note in return listing the new address.
Note that you need Postmaster rights to enable this keyword.
Note that success in setting the "New-List=" keyword is dependent on whether or not you have deleted practically every other keyword other than "Owner=" from the list header. Since the use of "New-List=" is intended to be an automatic pointer to the new host and/or new list name, no other keywords should be defined. Therefore, keywords that would normally cause a problem will generate fatal errors on a list PUT operation, and the list header will not be updated.
Further note that the old listsubscriber 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[,access-level,...]
Indicates whether or not an automatic log of every piece of mail sent to the list is to be kept, and defines at which interval of time its file name must be changed and who is allowed to retrieve it from the server. The default values are "Notebook= No,A,Single,Private".
where is the filemode of the minidisk (VM) or the disk and directory (non-VM) on which the notebook is to be kept. The default value of "A" is equivalent to LISTSERV's main working directory. On VM servers, this is LISTSERV's A disk; on VMS and Windows servers, this is LISTSERV's MAIN directory, and on Unix servers it is ~listserv/home (or whatever value has been used in the Makefile for $LSVROOT/home). Naturally, you may change this value to any directory you wish, provided that a) the directory exists (for security reasons, LISTSERV will not make it for you) and b) LISTSERV has read-write access to that directory. Rather than use the "A" directory, L-Soft strongly recommends that you create a separate directory structure with subdirectories for each list and use a full path spec for this parameter. This is important for security purposes related to the file server functions (see the Site Manager's Manual for details).
Note that under unix this parameter MUST IMPERATIVELY point to a directory specification that is all lower-case. LISTSERV for unix cannot write archives to directories named in upper- or mixed-case.
If your server is running the Web Archive Interface, L-Soft does not recommend that this parameter be pointed to the web archive index directory.
interval Defines the filetype or extension of the "notebook" file for the list, as indicated below (the filename will always be the same as the list name):
Single: A single file with the extension "NOTEBOOK" is created.
Yearly: A new file is started each yearly, extension is "LOGyy"
Monthly: The extension is "LOGyymm"
Weekly: The extension is "LOGyymmw" (w in "A"-"E")
Separate: A separate file is kept for each mailing (e.g. announcements, newsletters). The extension is "yy-nnnnn" (sequential counter).
While you may change the notebook interval at any time, LISTSERV will not convert existing notebooks into the new interval format. For instance, if you convert from Monthly to Weekly notebooks, LISTSERV will continue to maintain your original notebooks in their monthly format, while writing any new postings into weekly notebooks. This is perfectly normal and does not affect the proper operation of your list (in particular it does not cause any breakage to the archive search feature).
For servers with the WWW archive interface interface installed, please note that in order for archives to appear in the interface, the following requirements must be met:
1. Notebooks can be "Public" or "Private" (or any other access-level)
2. The notebook interval must be "Monthly", "Weekly", or "Yearly" ("Yearly" is not recommended).
3. The "Confidential=" keyword must be set either to "No" or "Service"
4. The LISTSERV maintainer must create an index directory for your list per the instructions in the Site ManagerOperations Manual.
See the Site ManagerOperations Manual for further details.
Note: Notebooks may be retrieved by means of the GET command. On VM only, a list of all available notebooks can be obtained with a GET NOTEBOOK FILELIST command.
The first two parameters of the "Notebook=" keyword may only be changed by the LISTSERV postmaster.
If necessary, you may break the "Notebook=" keyword into multiple lines in order to avoid running up against the 100-character header line limit. For instance
* Notebook= Yes,/home/listserv/lists/mylist-l,Monthly,Private
is strictly equivalent to
* Notebook= Yes
* Notebook= /home/listserv/lists/mylist-l
* Notebook= Monthly,Private
This can be particularly important if it is necessary to specify multiple access-levels for the notebooks (for instance if you have many sub-lists and want the subscribers to the sub-lists to be able to access the super-list's notebooks), for example,
* Notebook= Yes,C:\LISTS\SUPER,Monthly,Private,(SUB-A),(SUB-B)
* Notebook= (SUB-C),(SUB-D),(SUB-E),(SUB-F)
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 "Notify= Yes", meaning that non-quiet list owners will be notified.
Owner= net-address1 | mon-address1,[Quiet:,]net-address2 | mon-address2,...
Defines the person or list of persons who "own" the list. They are responsible for controlling access to the list and defining the list control keywords which are best suited to the purpose of the list. The default value for this keyword which should ALWAYS appear in the list header is the list of the userids of the postmasters. Any combination of explicit network addresses and complex access-levels is acceptable, for example: Owner= BIG@BLUE,(STAFF-L),Owner(MAIN-L)
An interesting application is to create a STAFF-L list containing the userids of all the local LISTSERV staff members and set the "Owner=" keyword of all local lists to "Owner= (STAFF-L)". This way when there is a change in the local LISTSERV management it is not necessary to modify the headers of all the lists – just modify the STAFF-L list.
The use of the "Quiet:" parameter causes all subsequently-defined list owners to be excluded from receiving any delivery error messages or other administrative mail from LISTSERV.
List owners may be defined on a single line or on multiple lines. See the List OwnerManual for details.
Peers= peer1,peer2,...
This keyword is not available in LISTSERV Lite.
Defines the (global) list of all the servers in the world that are peer-linked to the list, either directly or via one or more other peer servers. This information is used by the various list management commands to determine the "nearest" peer list to a given user. For example, when 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. Note that peers must have the same PW= keyword setting.
Renewal= interval1,interval2...,intervalx,Delay(number)[,Probe]
This keyword is not available in LISTSERV Lite.
This keyword controls whether or not subscribers are required to renew their subscriptions on a regular basis, and what the subscription period is. Multiple intervals can be set, each interval being one of several things:
Monthly, Yearly, Weekly, or a numeric variation such as 3-Monthly (meaning, quarterly). Note also that 1.8c introduces the ability to code "Renewal= xx-Daily", for instance, "Renewal= 15-Daily". While the use of intervals of less than a week is and remains inadvisable, FAQ templates with rotating topics may require the selection of a very precise renewal interval (for congruence purposes), which was not possible with "xx-Weekly" granularity. Please refer to either the List OwnerManual or the Site ManagerManual for a discussion of rotating FAQ support.
An absolute date in the format yyyy/mm/dd (once on this specific day), or the format mm/dd (once yearly on this month/day).
The confirmation delay, in the format Delay(n), where (n)=the number of days between the time the subscriber is asked to confirm the subscription and the day the user is removed from the list. This default is Delay(7), or seven days.
A typical Renewal= configuration might be:
* Renewal= 6-Monthly,Delay(14)
Conceivably Renewal= could also be set to something like:
* Renewal= 6-Monthly,1998/07/04,12/25,Delay(14)
which would cause LISTSERV to send renewal requests once every six months on the anniversary date of the user's original subscription, a specific request on 4 July 1998, and a request every year on Christmas Day. Note that this is provided ONLY as an example. L-Soft does not recommend using a renewal scheme of this sort.
Note: When setting up Renewal= for the first time on an older, established list, you may find that a substantial number of subscribers are prompted for confirmation immediately even though you may have set Renewal= to a value that might not be expected to cause such behavior. This is because LISTSERV uses the last activity date (which may or may not be the same as the subscription anniversary date) for the purpose of subscription renewal. The last activity date may be one of the following: The subscription anniversary date; the last date the subscriber posted to the list; or the last date the subscriber changed personal options.
Note also that if you code a specific date without specifying a year field (e.g., Renewal= 6/1), LISTSERV will immediately request a renewal from any subscriber whose last activity date is prior to that date in the current year.
The "Probe" parameter, introduced in Version 1.8c (but disabled in LISTSERV Lite) activates LISTSERV's "active probing" bounce processing feature, whereby the users are "probed" regularly using the PROBE1 mail template. The desired response from the user is to discard the message and do nothing. If the probe bounces, LISTSERV first sends the PROBE2 template with a copy of the bounce (assuming that the address actually works regardless of the bounce), and then schedules a new probe for the next day or deletes the user immediately, depending on the list's "Auto-Delete=" policy. For more information, see the List Owner's Manual.
Subscription renewal is disabled by default. To turn it off for a specific list, simply remove the "Renewal=" keyword from the list header.
See also Auto-Delete=.
Sizelim= number | numberK | numberM
This keyword is not available in LISTSERV Lite.
If set, causes LISTSERV to reject all messages to the list which exceed the number of lines (including all Internet header lines) indicated. This can be helpful in discouraging subscribers from posting long screeds or uuencoded files to your lists. It can also be set higher than the LISTSERV default if desired; check with your LISTSERV maintainer before changing this upward. (Generally "Sizelim= 250" is large enough for long posts but short enough to discourage postings of uuencoded binaries, but of course, your mileage may vary.)
List owners alternately may specify a maximum message size in either kilobytes or megabytes, rather than in lines, if preferred. For instance:
Sizelim= 100K Reject messages over 100Kbytes
Sizelim= 1M Reject messages over 1Mbyte
As before, the limit operates against the entire message file, including all Internet header lines.
The LISTSERV default for Sizelim= is determined by the value of the site configuration variable FILEMAXL, which in turn defaults to 500K lines.
Subject-Tag= text
LISTSERV 1.8c and higher supports "subject tags", i.e., the ability to insert a predefined text tag into the subject line of mail coming from a list. For instance, your subscribers might want the subject lines of mail coming from your list to contain the name of your mailing list. Whereas the RFC822 subject line of a typical list posting without a "subject tag" would look like this:
Subject: I think ID4 is a great movie, don't you?
if you were to define
* Subject-Tag= SCI-FI
the subject would look like this for all users who are set to the new "SUBJheader" personal option:
Subject: [SCI-FI] I think ID4 is a great movie, don't you?
Note that this option may be toggled on and off by the user by use of the new "SET listname SUBJecthdr" option. It is turned off by default.
The normal default for "Subject-Tag=" is the name of the list, for example, SCIFI-L. If "List-Address=" is defined for your list, the default is either the name of the list or the list ID, whichever is listed in "List-Address=". A subject tag can be only a single word; in other words, you cannot define a sentence to be used as a subject tag.
Starting with LISTSERV 1.8d, if a user sends a message with a blank RFC822 "Subject:" header, LISTSERV will create a "Subject:" header and place the subject tag into it (but only for subscribers with the SUBJecthdr option set.) Under 1.8c, subject tags worked only when posters defined a subject for their message.
Setting this keyword does not automatically reset users to the SUBJecthdr option. This must be done manually for existing users and may be specified by default for new subscribers by use of the Default-Options= keyword.
X-Tags= Comment | Yes | No
This keyword is not available in LISTSERV Lite.
Indicates whether "X-To:" and "X-cc:" tags are to be included in the output mail files to list recipients of the original mail file (other than the list userid) or not, and how they should appear in the RFC822 header.
Yes: This information must be provided in the form of "X-To:" and "X-cc:" tags in the RFC822 header (similar to the "To:" and "cc:" tags). This is the default.
Comment: This information must be provided in the form of "Comment:" tags, for example, "Comment: X-To:" and "Comment: X-cc:".
No: This information must not appear at all in the mail header.