Validate Keyword

Validate= No | Yes[,Confirm[,NoPW]] | All,Confirm[,NoPW]]

The "Validate=" keyword determines what level of validation is performed for various LISTSERV commands that apply to individual lists. There are six different settings ranging from very basic to very strict. The two most common settings are "Validate= No" and "Validate= Yes".

Lists are protected from hackers at the most basic level by the fact that a list PUT operation always requires validation, regardless of the setting of the "Validate=" keyword. In other words, the list owner or LISTSERV postmaster must always use a personal password when an updated version of the list header is sent back to the server, even if "Validate= No". This is to protect you from network hackers who might issue a command "from" your email address to change list settings. The default for this keyword is "Validate= No", but it is recommended that "serious" or "important" lists be changed to at least "Validate= Yes".

When "Validate= Yes", password validation applies to so-called "protected" commands (all of the commands that modify the contents of the list, e.g. ADD, DELETE, SIGNOFF, and so on – but not SUBscribe or SET). This implies that hackers cannot use these "protected" commands since they do not know the list owner's or LISTSERV postmaster's personal password. While at first glance this would also seem to mean that legitimate subscribers cannot use the SIGNOFF command, that is not the case, because for lists operating with "Validate= Yes" (i.e., without the "Confirm" option), LISTSERV may still use the "OK" mechanism in certain cases if it is deemed appropriate. The rationale of LISTSERV is that the "Validate=" keyword describes the desired behavior for interaction with the list owner and people who can be expected to use the list on a regular basis. SIGNOFF requests from legitimate subscribers and DELETE requests from registered node administrators on behalf of a user on their machine, for instance, may be validated using the "OK" mechanism even though that was not requested, because users and node administrators are not generally expected to have a password with which to validate such requests.

A notable exception to the list of "protected" commands is the SUBscribe command, which can still be used (if enabled, e.g., "Subscription= Open") to get on the list. However, when "Validate= Yes", sending a second SUBscribe command for the same list (for instance, to correct a spelling error in your name) would result in the command being forwarded to the list owner and not immediately executed. Also note that the SET command used to set various personal subscription options is not a "protected" command and may be issued without need for validation even when "Validate= Yes".

A rundown of the six different settings and what they mean follows:

• "Validate= No": All commands except PUT are taken at face value with no validation. While users are not bothered with validation requests, the list is almost totally unprotected from attacks by hackers. For compatibility reasons, this is the default setting.


• "Validate= Yes": Protected commands, such as DELETE or ADD, require password validation. For list owner commands, personal passwords set with the PW ADD command are accepted. Some user commands may accept a personal password, while others will cause the request to be forwarded to the list owners for verification. Other "protected" commands include GET, but do not include SUB or SET.


• "Validate= Yes,Confirm": Protected commands are validated using the "OK" mechanism by default, although personal passwords are also accepted where appropriate. This is a good compromise between list security and list owner convenience.


• "Validate= Yes,Confirm,NoPW": Protected commands are always validated using the "OK" mechanism. Passwords are not accepted, as they are not as safe as "cookies". This is the recommended setting for secure lists. Note that lists with this setting cannot be managed via the web interface.


• "Validate= All,Confirm": All commands causing a change in state, except the PUT command (which is always password-validated), are validated using the "OK" mechanism by default, although personal passwords are also accepted where appropriate. "Protected" commands (see above) are included in the class of commands that cause a change of state. Non-"protected" commands that cause a change in state include SUB and SET.


• "Validate= All,Confirm,NoPW": All commands causing a change in state (except PUT, as noted above) are always validated using the "OK" mechanism; passwords are not accepted, as with "Validate= Yes,Confirm,NoPW". Note that lists with this setting cannot be managed via the web interface.

Informational commands such as QUERY, SHOW, INDEX and REVIEW do not require any validation, regardless of the setting of "Validate=".

Requests originating on the local machine via LCMD never require validation, as they cannot be forged.

The PUT command must always be validated with the personal password of the list owner or LISTSERV administrator who is executing the PUT operation.

To see how individual commands are affected by this keyword, see the LISTSERV List Header Keyword Reference for more details.