Table of Contents Previous Next Index

Section 15 Security Features and Functions

Section 15 Security Features and Functions
LISTSERV’s security options are wide ranging, from almost no protection (easiest to administer a list, but also most open to hacker attacks) to total protection requiring validation of each and every command sent to LISTSERV for the list. It is also possible to limit access to various aspects of the list, such as who can subscribe, who can review the list of subscribers, and who can access the list archives. The list can be hidden from the LIST command, either at the global level or from all requests, including those from users on LISTSERV’s local machine, or from a definable range in between.
Note: LISTSERV does not set any file system permissions for any files. LISTSERV's security features are meant to allow and deny access to LISTSERV's various files depending on how various keywords are set, but in order to make your system completely safe, you must ensure that you have also set file and directory permissions appropriately for your operating system. For instance, LISTSERV may deny GET access to certain list archive files to non-subscribers, but if you have not set the appropriate file system permissions at the operating system level, you may have left open a window for someone to reach these files via anonymous ftp.
15.1 The VALIDATE= Keyword
The VALIDATE= keyword controls the level of command validation desired for the list. The default, VALIDATE= NO, requires password validation only for storing the list on the server. This is often sufficient for general needs. However, when a list is set this way, LISTSERV only compares the RFC822 "Sender:"/"From:" headers against the Owner= keyword(s) in the list header to determine whether or not the person ostensibly sending the commands has authority to do so. Otherwise at this level LISTSERV does not validate commands it receives for the list, under the assumption that the mail it receives is genuinely coming from a list owner. This level of validation does not protect the list from commands issued by hackers who have forged mail in the name of the list owner. If you run a list on a controversial topic or just don't feel comfortable without at least some security, VALIDATE= NO is probably not for you.
The next level is VALIDATE= YES. At this level, LISTSERV requires a password for all of its "protected" commands. This password is the sender’s personal LISTSERV password as defined by the PW ADD command. The commands protected by this level are those that affect subscriptions or the operation of the list, for example, DELETE or ADD. Users will also have to validate most commands that affect their subscriptions, but generally can do so using the "OK" mechanism rather than defining a personal password. Note that some user commands will be forwarded to the list owner for validation rather than accepting password validation from the user.
The next level is VALIDATE= YES,CONFIRM. At this level, LISTSERV will require validation with the "OK" mechanism (see below) by default, but will still accept passwords where appropriate. While the less-secure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience.
The next level is VALIDATE= YES,CONFIRM,NOPW. At this level, LISTSERV will no longer accept passwords as validation for protected commands. The logic is that because of the way the "OK" mechanism is implemented, passwords are not as safe as "magic cookies". This is the recommended setting for lists that must be kept secure.
Two other levels are VALIDATE= ALL,CONFIRM and VALIDATE= ALL,CONFIRM,NOPW. These levels require "OK" validation for all commands that cause a change in state except for the PUT command. If NOPW is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (e.g., QUERY and other strictly-informational commands) do not require validation.
Note: LISTSERV 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.
Lists which are set to either Validate= Yes,Confirm,NoPW or Validate= All,Confirm,NoPW may not be managed via the web administration interface, which is password-driven.
See the List Keyword Reference document for complete information on the VALIDATE= keyword.
15.2 Controlling Subscription Requests
Subscription requests are controlled by use of the SUBSCRIPTION= keyword. By default, this keyword is set to SUBSCRIPTION= BY_OWNER, meaning that all subscription requests will be forwarded to the list owner for disposition. Subscription requests can be refused completely by setting SUBSCRIPTION= CLOSED.
To code a list for open subscriptions without list owner intervention, set SUBSCRIPTION= OPEN. If it is desired to add protection against forged subscription requests or bad return mailing paths, code SUBSCRIPTION= OPEN,CONFIRM. The latter will cause a subscription confirmation request to be sent to the prospective subscriber, which he or she must respond to using the "OK" confirmation mechanism.
In order to restrict subscriptions to persons in a specific service area, see the next section.
15.3 Controlling the Service Area of the List
The Service= keyword is not available in LISTSERV Lite.
It may be desirable to restrict access to a list to people in a small area. For instance, you probably would not want a list for students in a class section at a university to be advertised or accessible by people all over the world. However, without setting certain keywords appropriately, such a list will be visible to a LISTS GLOBAL command.
The local list of (public) lists can be retrieved only by those users who are considered local, per the setting of the server-wide LOCAL= variable in LISTSERV's site configuration file. All other users will be told that none of the lists on the server are visible via the LISTS command, and will be referred to the use of the LISTS GLOBAL search-text command or to the CataList. This is regardless of the setting of Confidential= as outlined below.
To simply hide a list from a LISTS command, but still allow people to subscribe to it if they know it is there, use the keyword Confidential= YES. Note that users subscribed to the list as well as the list owner(s) will be able to see the list if they issue a LISTS command. In addition, all other non-subscribers, including users on the local machine, will not be able to determine that the list exists via a LISTS command.
To hide a list from and refuse subscription requests from users outside the local area, you define two keywords:
* Service= bitnode1,bitnode2,some.host.edu
* Confidential= SERVICE
Service= can also be set to Service= LOCAL, meaning it will use either LISTSERV’s global definition of which machines are LOCAL, or the machines defined by the list keyword Local=. The LISTSERV maintainer should define hosts and nodes that are considered local with the server-wide LOCAL= variable in the site configuration file. If the global definition is not suitable, it can be overriden by defining the Local= list header keyword:
* LOCAL= bitnode1,bitnode2,some.host.edu,another.host.co
m* SERVICE= LOCAL
* CONFIDENTIAL= SERVICE
If there are many subdomains within your primary domain, it may be preferable to use the wildcard when defining the LOCAL or SERVICE list header keywords. For instance:
* SERVICE= *.HOST.COM
defines the service area for a specific list as "all subdomains ending in .HOST.COM".
Note: Defining a service area for a list controls only from which domains subscription requests may be accepted. It does not control who may post to the list. Depending on local circumstances, it may be desirable to set lists with controlled service areas to Confidential= Service.
15.4 Controlling Who Reviews the List of Subscribers
For whatever reason, it may be desirable to restrict the ability to review the subscriber list either to subscribers or to list owners. This is done by setting the REVIEW= keyword appropriately.
To allow anyone, including non-subscribers, to review the list, set REVIEW= PUBLIC.
To restrict reviews of the list to subscribers only, set REVIEW= PRIVATE. This is the default.
To restrict reviews of the list to list owners only, set REVIEW= OWNERS.
Reviews can also be restricted to users within the list’s service area by setting REVIEW= SERVICE, and defining the SERVICE= keyword appropriately (see the preceding section).
Note: Unless the list is set to "Confidential= Yes" or "Confidential= Service", a request to REVIEW a list by someone who is not allowed to do so will result in the header of the list being sent to the user along with a note to the effect that the REVIEW command is restricted for this list. See Section 15.9 Hiding Selected Header Lines regarding hiding header lines if you want to hide parts of the header but do not want to use the "Confidential=" keyword.
15.5 Controlling Access to the Notebook Files
Restricting access to the list’s notebook archive files is similar to controlling who may review the list. It is accomplished by setting the fourth parameter of the NOTEBOOK= keyword to an appropriate value. For instance,
* NOTEBOOK= Yes,A,Monthly,Public
defines a monthly notebook on LISTSERV’s A disk that is accessible by anyone. Change Public to Private if you wish only subscribers to be able to access the notebooks. The same access-levels are available for this keyword as for REVIEW=. (See the List Keyword Reference document for a discussion of access-levels.)
It is possible to define "Service=" in terms of IP address blocks in order to limit access to list archive notebooks. See "Service=" in the List Keyword Reference document for details.
If enabled, notebook archives are private by default.
15.6 Controlling Who Can Post Mail to a List
The Send= list header keyword is the basic control for who may post mail to the list. If the list allows non-subscribers to post, set Send= Public. (This is the default.)
For a list that does not allow non-subscribers to post, set Send= Private.
For a list where all posts should be forwarded to a moderator/editor, there are two settings:
Send= Editor forwards all postings to the list editor (see the Editor= and Moderator= keywords). This setting allows the editor to make changes before forwarding the message back to the list. Note that your mail program must be capable of inserting "Resent-" header lines in your forwarded mail—if it is not capable of this, all such posts forwarded to the list will appear to be coming from the editor. Check with your system administrator if you are not sure whether or not your mail program inserts the "Resent-" headers.
Send= Editor,Hold forwards a copy of the posting to the editor but differs from Send= Editor in that LISTSERV holds the posting for a period of time (usually 7 days) until the editor confirms the message with the "OK" mechanism (see below). Unconfirmed messages simply expire and are flushed by LISTSERV, so there is no need to formally disapprove a posting. This method of message confirmation is well-suited to lists where it is not often necessary to modify the text of a posting, and also is an excellent workaround if the editor’s mail program does not generate "Resent-" headers in forwarded mail.
Below is a sample of the editor-header for a list set to Send= Editor,Hold:
Figure 15-1 The Editor-Header for a List Set to Send= Editor,Hold
Date: Tue, 4 Aug 1998 10:47:21 -0500
From: "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8d)"
<LISTSERV@PEACH.EASE.LSOFT.COM>
Subject: B5-L: approval required (9723A0DD)
To: Joe ListOwner <joe@PRUNE.EXAMPLE.COM>
This message was originally submitted by jack@UNIX.FOO.COM to the B5-L list at PEACH.EASE.LSOFT.COM. You can approve it using the "OK" mechanism, ignore it, or repost an edited copy. The message will expire automatically and you do not need to do anything if you just want to discard it. Please refer to the list owner's guide if you are not familiar with the "OK" mechanism; these instructions are being kept purposefully short for your convenience in processing large numbers of messages.
A final method (called "self-moderation") exists for lists where subscribers should be allowed to post freely, but non-subscriber posts should always be sent to an editor for approval. To enable self-moderation, set
Send= Editor (or Send= Editor,Hold)
Editor= userid@host,(listname)
Ensure that "listname" is in parenthesis. Note that self-moderation will catch all posts from non-subscribers—including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as joe@foo.com but is posting from joe@unix1.foo.com, LISTSERV will treat his mail as non-subscriber mail. Self-moderation may require some slight changes in individual user subscriptions in order for it to work seamlessly. See also the Default-Options= list header keyword description.
15.7 The "OK" Confirmation Mechanism
Depending on the setting of the Validate= list header keyword, certain LISTSERV commands have always required a password for execution. However, with a recognition that mail can be forged ("spoofed") by just about anyone on the Internet today, L-Soft introduced a "magic cookie" method of command validation that is considered much more secure than passwords.
In essence, the "magic cookie" method requires that the sender of the command must confirm his command via a reply containing only the text "OK". (This is actually simplistic; see below.) If mail is spoofed from the list owner’s user id, the command confirmation request will always be sent to the list owner’s user id, thus preventing the spoofer from confirming the command. Moreover, the "cookie" itself (an eight-digit hexidecimal number) is registered to the "From:" user id of the original command. A typical command confirmation request looks like this:
Figure 15-2 A Typical Command Confirmation Request
Date: Wed, 5 Aug 1998 09:50:06 -0400
From: "L-Soft list server at LISTSERV.EXAMPLE.COM (1.8d)"
<LISTSERV@LISTSERV.EXAMPLE.COM>
Subject: Command confirmation request (5C019D91)
To: joe_user@EXAMPLE.COM
Your command:
PW REP XXXXXXXX
requires confirmation. To confirm the execution of your command, simply point your browser to the following URL:
http://listserv.example.com/scripts/wa.exe?OK=5C019D91
Alternatively, if you have no WWW access, you can reply to the present message and type "ok" (without the quotes) as the text of your message. Just the word "ok" - do not retype the command. This procedure will work with any mail program that fully conforms to the Internet standards for electronic mail. If you receive an error message, try sending a new message to LISTSERV@LISTSERV.EXAMPLE.COM (without using the "reply" function - this is very important) and type "ok 5C019D91" as the text of
Finally, your command will be cancelled automatically if LISTSERV does not receive your confirmation within 48h. After that time, you must start over and resend the command to get a new confirmation code. If you change your mind and decide that you do NOT want to confirm the command, simply discard the present message and let the request expire on its own.
The general method of replying to a command confirmation request is to use the web browser confirmation method outlined in the confirmation request.
If you prefer, you can use the old method of responding by mail:
REPLY to the command confirmation request with the text "ok" in the body of the reply. (Non-case-sensitive) LISTSERV reads the "cookie" from the subject line and if it corresponds to a held job, the job is released and processed.
If this does not work, it is possible that the Subject: line was corrupted in transit and you may need to try the following:
SEND a new message to LISTSERV with the text "ok xxxxxxxx" (where xxxxxxxx is the command confirmation number from the original confirmation request) in the body of the reply.
It is also possible to confirm multiple command confirmation requests with a single message (for instance, if you have Send= Editor,Hold and have a number of requests to be responded to). This eliminates multiple "Message approved" mails from LISTSERV. However, make sure that you send the confirmations in a new mail message rather than replying to one of them. (See the "bracketed OK" syntax mentioned below.)
You can send the "OK" from any address, which helps when the address field of your mail gets changed somewhere along the line. For instance if you are logged into the web administration interface as joe@example.com and issue a command that requires mail confirmation, LISTSERV will send the request to joe@example.com (as expected). If your mail system expands joe@example.com to Joe_Doakes@mail.example.com, the "OK" will still succeed and Joe_Doakes@mail.example.com will get a message that says
> ok
Confirming:
> QUIET DELETE * jane@example.com
[reply sent to joe@EXAMPLE.COM]
while as a protection against "spoofed" commands the actual command response will be sent to joe@example.com like this:
jane@EXAMPLE.COM has been removed from the TEST list. No notification has been sent.
Global deletion process complete, one entry removed.
The "OK" confirmation mechanism also has the following features:
An "OK" without an argument (confirmation number) flushes the job stream so any text following an "OK" on a line by itself will not be seen by the LISTSERV command processor.
Bracketed "OK" functionality. This feature allows you to send multiple commands for which LISTSERV will request only a single "OK" (where normally you would expect to have to "OK" each individual command). The syntax is as follows:
OK BEGIN
command1
command2
...
command3
OK END
A command confirmation ("OK") may now be sent by clicking on a web URL provided in the command confirmation request (mailed "OK"s are still perfectly acceptable, of course).
Note: In a "bracketed OK" the aggregate length of the data stream (that is, the total number of characters in the command lines falling between OK BEGIN and OK END) MUST be less than 32K characters. In practice you should use bracketed OKs for limited numbers of commands only, say no more than 10-12 at a time. In particular, if you have many ADD or DELETE commands to send, it is far more efficient (and strongly preferred) to use the bulk ADD and bulk DELETE syntaxes described in Section 7.17 Bulk Operations (ADD and DELETE).
15.7.1 Explicitly Cancelling "OK" Cookies
It is possible to explicitly cancel an OK confirmation cookie if so desired. The command is simply
OK CANCEL xxxxxxxx
(for instance, "OK CANCEL 8F2E8F4B"), and if the cookie is valid, LISTSERV will respond "Confirmation code 8F2E8F4B cancelled." If the cookie is not valid (e.g. has expired, has already been cancelled, or is simply incorrect), LISTSERV will send its standard message telling you in part that "The confirmation code 8F2E8F4B does not correspond to any pending command."
15.8 Denying Service to Problem Users
In addition to methods listed above for restricting service areas and the like, LISTSERV has a varied set of methods whereby "problem users" may be denied service on several levels.
15.8.1 The "Filter=" List Header Keyword
List owners or LISTSERV maintainers may filter specific userids (or users matching a wildcard specification) on a list-by-list basis by using the FILTER= list header keyword. For more information, see the List Keyword Reference document.
15.8.2 The "FILTER_ALSO" Configuration File Variable
LISTSERV maintainers may add specific or wildcarded userids to LISTSERV's built-in filter by using the FILTER_ALSO= configuration file variable. Users matching this specification will be denied service to all LISTSERV services on your server.
15.8.3 The "SERVE" Command
The LISTSERV maintainer may selectively "serve out" specific userids with the SERVE command. This use of the SERVE command creates a "hard" serve-out which only a LISTSERV maintainer may override, as opposed to the "soft" serve-out that occurs when 51 consecutive bad commands are sent to LISTSERV which any user (other than the served-out user) can override. This function is particularly useful for temporary suspensions of service to certain userids, as it does not require modifying the site configuration file, but naturally it may be used to serve users out permanently. The SERVE command does not accept wildcards, so if you need to suspend service to a class of users rather than to a specific user, you should use the FILTER_ALSO configuration file variable as described in Section 15.8.2 The "FILTER_ALSO" Configuration File Variable.
LISTSERV writes an entry for each served-out user to its PERMVARS FILE. (PERMVARS FILE is not a plain-text file; do not edit it by hand.) To serve a user out manually, the LISTSERV maintainer sends the command:
SERVE internet-address OFF PW=password
The password is required. Acceptable passwords are the list creation password (CREATEPW), the system file modification password (STOREPW), or your personal password set with the PW ADD command.
Note: Prepending QUIET to the SERVE command suppresses notification to the user in question. If you are serving out an ID that is causing a mailing loop, you will probably want to use QUIET to avoid sending a fresh message to the looping ID.
Because the postmaster does receive notifications when a served-out user attempts to send mail to the server, the SERVE command also has a DROP sub-command that can be used to tell LISTSERV to "drop on the floor" all mail from that served-out address. For instance,
SERVE internet-address OFF DROP PW=password
To restore service to a user previously served out, the LISTSERV maintainer sends the command:
SERVE internet-address PW=password
Again, the password is required, and the QUIET modifier may be used.
When a user is served out by the LISTSERV maintainer, assuming the QUIET modifier is not prepended to the SERVE command, a message similar to the following is sent:
Date: Thu, 6 Dec 2001 09:45:40 -0500
From: "L-Soft list server at LISTSERV@LISTSERV.EXAMPLE.COM (1.8e)"
<LISTSERV@LISTSERV.EXAMPLE.COM>
Subject: Message ("Your access to LISTSERV has just been suspended...")
To: baduser@somehost.com
Your access to LISTSERV has just been suspended by nathan@example.com. Commands and postings from you will be ignored from now on.
15.8.4 The POST_FILTER List Exit Point
See the Advanced Topics Guide for LISTSERV for information on programming list exits and the POST_FILTER list exit point.
15.9 Hiding Selected Header Lines
It is possible to hide part or all of a list header (except for the list title) from users who send the REVIEW command or who try to view the list's configuration via the CataList. The following syntax is used:
* My very own list
*
* blah blah blah
*.HH ON
* This line is hidden
* This line is also hidden
*.HH OFF
* This line is not hidden
The sequence can be repeated as many times as required. GET will return the unedited header with the .HH sequences, REVIEW will replace hidden lines with a note saying that lines were hidden. You can't hide the fact that some lines were hidden because it would lead to people spending hours trying to figure out problems which only appear to be problems because some of the keywords are not visible. L-Soft will not field support inquiries with hidden headers; you must send the entire raw header (including the .HH lines) when requesting support.
15.10 Tracking Subscription Changes with the Change-Log Keyword
This feature and keyword are not available in LISTSERV Lite.
LISTSERV includes a "Change-Log=" list header keyword which, when set to "Yes", causes the server to log information about changes to individual subscriptions for a given list to a listname.CHANGELOG file (listname CHANGELG on VM). Changelogs also log postings to the list. Please see Section 10.6 Change Logs and the List Keyword Reference document for more information on the "Change-Log=" keyword.