Table of Contents Previous Next Index

Section 5 Configuring Your LISTSERV Site

Section 5 Configuring Your LISTSERV Site
For the purposes of this section, it is assumed that you have already installed LISTSERV on your host computer and have been able to start it in successfully in interactive mode.
Note: This manual is not intended to replace the individual installation manuals for LISTSERV on the various platforms supported by L-Soft. This is because the installation procedures vary radically from platform to platform and this manual is intended to assist LISTSERV maintainers on operational LISTSERV sites. The installation guides for all platforms are included in the software distributions, and are also available on L-Soft's World Wide Web and FTP sites.
5.1 Site Configuration Files
These files have different names depending on the platform. They are located in the same directory with the executable binaries.
Table 5-1 Site Configuration Files
These are the only configuration files that should be changed on any LISTSERV installation. Software upgrades may overwrite any other configuration files located in LISTSERV’s home directory. They will never overwrite the files listed above. The intent is to help preserve your system settings from one version to the next so that you do not experience the inconvenience of having to reconfigure LISTSERV after an upgrade.
L-Soft international, Inc., is not responsible for system downtime or mis-operation occasioned by the loss of any changes that you make to configuration files other than the ones listed above.
All LISTSERV sites that use the web administration interface to modify the system configuration in real-time will also have a file called SITECFG.FILE (sitecfg.file under unix) in LISTSERV's A directory. This is where LISTSERV stores changes to the default or initial configuration when made via the web interface. This file SHOULD NOT be modified by hand.
At startup, LISTSERV will first read the original site configuration file, and then will read the SITECFG.FILE for any changes to the original configuration.
L-Soft strongly recommends that, for support purposes, it is best to use the technical support "lifebuoy" link from the Server Administration Dashboard to initiate a support ticket. This will help you create an email message to the support group that contains all the necessary information about the site configuration without having to go to the trouble to find and attach both configuration files.
If LISTSERV is not running, of course, this will not be possible, and you should provide both the original configuration file and SITECFG.FILE to support when writing.
5.2 What can be configured?
Depending on the platform, a large number of control variables are available to "fine tune" the performance and behavior of LISTSERV. The following table indicates the variables, under which platforms they are supported, and briefly what they control. Please see the Site Configuration Keyword Reference document for details before setting any control variable. Some variables shown in the table are VM legacy settings and are not otherwise discussed in this manual.
Table 5-2 LISTSERV Site Configuration Variables
Specifies non-POSTMASTER users who are allowed to post to the ALL-REQUEST alias.
Boolean value determining whether or not LISTSERV's
anti-virus scanning is enabled.
One of two variables that may be set on servers that submit mail to the external LISTSERV AVS for virus and spam scanning, which can help deal with DoS mail-bombing attacks.
One of two variables that may be set on servers that submit mail to the external LISTSERV AVS for virus and spam scanning, which can help deal with DoS mail-bombing attacks.
Defines the hostname of a machine that knows how to route mail to BITNET addresses.
Tells LISTSERV where to send bounces not related to any particular list.
Tells LISTSERV to mirror a copy of all or selected changelogs to DBMS.
Used in conjunction with CHANGELOG_DBMS. Sets the DBMS connection characteristics for mirroring changelog data to DBMS.
Used in conjunction with CHANGELOG_DBMS. Sets the DBMS table characteristics for mirroring changelog data to DBMS.
Three configuration variables under the CLI_* rubric are available for use with DBMS/Mail Merge. Please see the Advanced Topics Guide for LISTSERV for more information.
(AIX only)
The name of the CMS system to be used on IPL commands.
Indicates whether the (old) VM database functions are enabled or not.
Several configuration variables under the DBMS_* rubric are available for use with the DBMS/Mail Merge.
Determines whether or not the new LISTSERV database
functions use reverse indexing.
Debug setting to display passwords in LISTSERV's log file.
Show fully-logged TCPGUI
commands for debugging
Boolean value that sets the server default for background DISTRIBUTE (requires HPO).
Sets the default national
language template for use by all lists on the server.
Sets the server default for the list-level Loopcheck keyword.
Sets whether or not to enable mail-merge for the list. If you enable mail-merge, the default bottom banner will include an automatically generated one-click unsubscribe link for each subscriber. Without mail-merge, the link will instead lead to the generic subscription management page of the list.
Sets the server default for the list-level Misc-Options keyword.
Provides a default value for the SPLIT= command line keyword.
Indicates whether LISTSERV should use diagnose X'D4' to mimic the RSCS origin on files it DISTRIBUTEs.
Space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE.
Tuning parameter for background DISTRIBUTE. (requires HPO)
Tuning parameter for background DISTRIBUTE. (requires HPO)
Enables and tunes DISTRIBUTE "workers". This is a tuning feature for embedded mail merge. (requires HPO)
The minimum message size, in kilobytes, to make use of
DISTRIBUTE workers (requires HPO)
Enables and tunes DISTRIBUTE "workers". This is a tuning feature for embedded mail merge. (requires HPO)
Determines whether or not list owners may use the mail-merge feature for their lists.
Boolean value which controls security validation feature for the DISTRIBUTE command. WARNING: See the Site Configuration Keyword Reference document before changing this value.
Specifies DomainKeys domains for which you are able and
willing to sign
Boolean value which directs LISTSERV to sign all messages for which it has a suitable DomainKeys private key.
Boolean value which determines whether or not LISTSERV may use an SMTP mailer other than LSMTP to send mail-merge messages. The default is 1, which means LSMTP is not required.
The filemode of the DEFAULT disk to be used for storing files via a PUT command.
The maximum number of lines for any incoming non-mail file to be accepted.
Defines users or classes of users who should be exempt from LISTSERV's standard filter.
Defines users or classes of users who should not be allowed to post to any list on the server.
Defines the number of seconds LISTSERV will try to open a file locked by an external process.
Defines (in kilobytes) the "target size" for LISTSERV's file cache.
Defines the threshold (in kilobytes) at which point LISTSERV should start trimming the cache.
Defines (in kilobytes) the cache size at which LISTSERV should write a warning to the console log.
(Boolean) Add anti-virus protection for those Windows sites that for policy or other reasons must run anti-virus systems other than F-Secure on their servers.
Internet addresses of persons to be granted an “infinite” GET quota.
(Boolean) Determines whether or not error trace backs are shown to non-postmasters.
A list of userid@nodes whose messages and files are to be ignored.
Provided for DBMS lists with UEMAIL fields to work around RFC821 requirement that an email address local-part must be evaluated case-sensitively.
Boolean value determining whether or not LISTSERV will ignore the PRIME setting on incoming DISTRIBUTE jobs.
On VM, determines whether INDEX subscriptions use GETPOST or old-style database jobs by default.
The optional local "installation password" associated with the INSTALL command.
Boolean value determining whether or not the "Summary of resource utilization" is generated or suppressed in a CJLI JOB command response.
Three configuration variables under the LDAP_* rubric are available for use to control the LDAP extensibility introduced in LISTSERV 15.5. Please see the LISTSERV LDAP Overview for information.
Toggles license warnings on and off. Warning: See the Site Configuration Keyword Reference document before changing this value.
Default value for the List-Address= keyword.
Filenames of executable files that can be defined as exits by an Exit= list header keyword.
A boolean variable indicating how PUT commands for
datafiles associated with the LMC FAC are handled
A list of nodes to be associated with the hardcoded LCL FAC. Also used as the default for the Local= list keyword.
The maximum number of lines for an incoming MAIL file to be accepted.
Maximum number of 'RCPT TO:' lines per BSMTP file sent to the mailer.
The maximum number of lists to which consecutive subscription attempts will be accepted from a given subscriber, to prevent "spoofing" attacks.
(HPO only) The maximum number of recipients to be listed in the LISTSERV console log as recipients of an SMTP job.
Yes (NT)
Maximum number of recipients in forwarded DISTRIBUTE jobs.
Maximum number of GET requests a user can make per day.
Maximum number of kilobytes of data a user may obtain a day via GET requests.
Userid of the virtual machine running a RFC1312/MSP server, if "Internet TELL" support is desired.
The list of domain names that are equivalent to NODE – e.g., MX addresses, CNAMEs, etc.
Short organization name that appears in the RFC-822 "Sender:" line.
Whether to send mail to the local MAILER in Netdata format.
Directs a VMS™ server running in NJE mode to send all outgoing server-to-server requests via the Internet.
Three configuration variables under the OCI_* rubric are available for use with LISTSERV's DBMS/Mail Merge functionality. Please see the Advanced Topics Guide for LISTSERV for more information.
Three configuration variables under the ODBC_* rubric are available for use with
LISTSERV's DBMS/Mail Merge functionality. Please see the Advanced Topics Guide for LISTSERV for more information.
Defines the system and RSCS spool thresholds for automatic offline/online control.
Controls the "verboseness" of LISTSERV's administrative From: line.
A list of userid@nodes, of which the first one is the "main" postmaster (to receive transferred files).
Defines the domain to be appended to all non-qualified addresses.
Defines a list of filemodes which are to be considered as "reserved" and never available for dynamic ACCESS.
A list of local userids which must be treated as RSCS virtual machines.
Sets the site-level default for the maximum and minimum number of words in implicitly-generated RSS abstracts
Determines whether or not the (new) SEARCH command is enabled.
Boolean value determining whether or not personal LISTSERV passwords are encrypted in the SIGNUP files. It is turned ON by default.
The Internet hostname of the server to which all outgoing SMTP mail should be forwarded for delivery.
Defines “n” number of "SMTP workers" used to split up the SMTP forwarding load.
Dotted-decimal IP address that sets the IP address to which the SMTPL.EXE "listener" will bind at boot time.
Integer value that sets the port number to which the SMTPL.EXE "listener" will bind at boot time.
Defines bandwidth limits for the server. Typically used with
delivery pools, but can be used to set a server-wide bandwidth limit. (Classic HPO Non-VM)
Directs LISTSERV to reset open SMTP connections every “n” minutes.
Determines whether or not to sort recipients in the RFC821 mail envelope.
Determines whether or not
spam reports are sent to the postmaster.
Sets the server-wide value
(in minutes) for the anti-spam quarantine period.
provided” exit program used to call a third-party spam scanner. (VM/VMS require AVS)
Determines the action(s) to take when LISTSERV receives spam complaints via AOL feedback loops
Determines whether to enable AOL Feedback Loop Auto-Processing.
Sets the maximum size, in
kilobytes, of any message to be handled by the spam scanner. Messages over the specified size are not scanned. (VM/VMS require AVS)
Flag telling LISTSERV that it runs in a SSI system.
The password to be used by postmasters when executing CP/CMS commands and when storing files in the server by means of the PUTC command.3
Defines the IP address used by the TCPGUI interface.
List of userid@node templates from whom LISTSERV should never accept mail.
List of userid@node templates to whom LISTSERV should never send mail.
(HPO only) Enables a suite of HPO functions that can speed up operations on servers with many lists (>100).
Three configuration variables under the UODBC_* rubric are available for use with DBMS/Mail Merge.
OBSOLETE as of 14.5, see EMBEDDED_MAIL_MERGE instead.
Indicates whether or not the VM30091 message suppression functions are available.
Boolean value determining the format of the response to the QUERY FILE command.
Indicates whether or not
LISTSERV should require "OK" confirmation for commands sent from WWW browsers.
The (preferably) relative URL that leads to the WWW archive CGI script. (This is a URL, not an OS path name.)
The full OS path name to the WWW archive directory.
Disable or enable the web archive interface's IP address verification function.
Userid of the virtual machine to which files found in the lists readers should be transferred.

Depending on platform support for DBMS. See the full documentation for details.

The native OCI interface was available for Windows servers only in version 1.8d. It was removed in LISTSERV 1.8e. See the Site Configuration Keyword Reference document.

For non-VM systems, STOREPW is a secondary password that is functionally identical to CREATEPW. You should use the same value for both passwords, i.e., set STOREPW=%CREATEPW% (for Windows NT/2000 and 95/98), etc.

Dependent on unix platform support for unixODBC.

There are also a number of configuration variables pertaining to the DBMS/Mail Merge functions. These variables are documented in the Advanced Topics Manual for LISTSERV.
5.3 Files Used by LISTSERV
The proper operation of LISTSERV is dependent on LISTSERV’s ability to find a number of files that belong to it. The following list of files are required to operate the product, and in most cases, it must be located in the same directory with the LISTSERV executables.
Notes: The exception is under unix, where all of the data files other than the 'go*' files MUST be placed one directory below the executables, typically in ~listserv/home.
Under certain conditions, some required files aren’t necessary; these will be noted where applicable. In addition, some files are not shipped with the distribution, but are generated automatically the first time you run LISTSERV.
5.3.1 Program Executables
Depending on the platform, the required executables are:
For OpenVMS and Windows systems, the executable SMTPW.EXE is also required.
For Windows systems, the executable SMTPL.EXE is also required.
The executables listed above belong in the following places (depending on the platform):
Finally, the Web Archive ('wa') Interface CGI script is shipped in the “A” directory of the non-VM servers. This script must be copied into the appropriate script directory for your Web server (see Section 5.4 Installing & Configuring LISTSERV’s WWW Archive & Administration Interface) if you plan to use the Web Archive interface. For OpenVMS and Windows servers, this file is WA.EXE, while on unix machines it is wa*.
5.3.2 BITNET Network Table Files
These files are not required when running LISTSERV with RUNMODE=TABLELESS, and are not shipped with LISTSERV Lite. Network table files include:
With the exception of BITEARN NODES, all files are regenerated whenever BITEARN NODES is updated or when an explicit NODESGEN command is issued. For pre-1.8c servers (or non-registered 1.8c or later servers), BITEARN NODES must be downloaded on an approximately monthly basis from
or from the European mirror at
BITEARN NODES on registered networked servers are updated using the same mechanism as PEERS NAMES and other LISTSERV tables. Note that this requires that your mail server support incoming files of at least 1.5M. VM sites have not been included as they typically maintain this file using the UPNODES procedure and store it on a public disk, applying change control procedures in the process.
5.3.3 Internet and Peer Networking Table Files
These files are used by LISTSERV to define its "backbone" and other peer servers, as well as to help determine the best routes for mail sent via the DISTRIBUTE algorithm.
For registered sites they are updated periodically by mail from other servers. The update process is automatic and does not require LISTSERV maintainer intervention unless a problem is noted.
For non-registered sites the files must be updated manually. See for information on how to accomplish this.
Sites running in TABLELESS or STANDALONE mode do not require these files. This includes all LISTSERV Lite and LISTSERV Shareware sites.
5.3.4 LISTSERV’s External Data Files
LISTSERV uses these files for a number of purposes. The fact that they are external to the executables makes it easy to update them when needed. These files include:
Important: PERMVARS.FILE is LISTSERV's main "permanent variables" file; among other things, this is where LISTSERV registers spammers and users that have been served off. This file should NEVER be modified manually. It is in a binary format and, if corrupted, LISTSERV will not start.
Important: SITECFG.FILE is where LISTSERV stores changes made to the main site configuration file via the web administration interface. This file should NEVER be modified manually.
The SIGNUP.FILEx files (initially there are 9 [or 31 if you are licensed for HPO], for example, SIGNUP.FILE1, SIGNUP.FILE2, etc.) are used to register users, their "real name" fields, and their personal passwords (if they have one).
Notes: LISTSERV 16.0 supports (and has enabled by default) password encryption for its SIGNUP files. This means that installing LISTSERV 16.0 will encrypt the passwords in your SIGNUP files, which is not backwardly-compatible with earlier versions of LISTSERV. The encrypted passwords are not recoverable, and the PWC QUERY command run against an address with an encrypted password will simply return the information that the address in question has a password set. The only method of "recovering" a lost encrypted password is for either the user to issue a PW REP command or the site maintainer to issue a PWC REP command to change the existing password.
Password encryption can be disabled by setting the site configuration variable SIGNUP_ENCRYPT_PASSWORDS (Boolean) to 0. This can be done prior to upgrading. See the information for SIGNUP_ENCRYPT_PASSWORDS in the Site Configuration Keyword Reference document.
SYSTEM.CATALOG is used by LISTSERV to register system files; it should not be modified, as it is always shipped with new versions and will thus overwrite itself. Instead, SITE.CATALOG should be used to register files and list file archive catalogs (listname.CATALOG) for users to retrieve. (SITE.CATALOG is not shipped with LISTSERV; please Section 15 File and Notebook Archives for details.)
DEFAULT.MAILTPL and DEFAULT.WWWTPL are the files from which LISTSERV gets its default mail templates and default web templates for responses to user input. See Section 14 Creating and Editing Templates Manually for details.
SYSCFG.FILE tells LISTSERV what site-level variables can be configured (and how) from the web administration interface. It should NEVER be altered. It will be overwritten in an upgrade.
5.3.5 User Reference Material
The following files are LISTSERV's online documentation.
LISTALL.REFCARD is broken into three parts internally. Part 1 is the response to the INFO REFCARD command; Parts 1 and 2 are the response to a GET LISTOWNR REFCARD command; and the whole document is sent in response to a GET LISTMAST REFCARD command.
5.3.6 Command Line Utilities (Non-VM)
Depending on your platform, the following executables may have been shipped (under unix they must all be complied from the corresponding *.c files):
LCMD.EXE (or lcmd*)
LCMD is a command-line named-pipes interface to LISTSERV. You can use it to send commands directly to LISTSERV from the console and receive information in return, either on the console itself (Windows and OpenVMS) or via mail (unix). The syntax is:
Windows: lcmd [\\computer[\serverid]] command
OpenVMS and unix: lcmd command
The user running LCMD must have appropriate permission (e.g., must be a list owner or LISTSERV maintainer) in order to issue the various protected commands.
LISTVIEW.EXE (or listview*)
LISTVIEW is a utility that allows you to type the binary-format .LIST files to standard output so that they can be viewed and/or redirected to text files. The syntax is:
listview [-a] [-e[h]] [-h] [-r nnnn] [-s] file1 file2...
You can choose only one of the command line options at a time, except that you can specify one of the other options along with the -r option if needed. The options are:
-h shows the header only.
-s shows the header + the subscribers (without the option string in columns 81-100).
-e shows the list of subscribers only (without the option string).
-eh similar to -e, but show only the hostnames without userid@.
-a shows the entire list file.
-r nnnn generates two files (listname.view1 and listname.view2) for each list file viewed with this option. The view1 file contains nnnn subscriber addresses chosen at random from the list, where nnnn is an integer value between 1 and the number of users on the list. The view2 file contains the rest of the subscriber addresses from the list, randomly sorted. (The view2 file is useful in cases where you wish to pull x names at random from your mailing list, and then pull x more names at random without duplication. Note however that you would have to add the subscribers in the view2 file to a regular LISTSERV list in order to be able to run listview against those subscribers.)

While you can specify one other option with -r to manipulate the output, the following caveats should be noted:
listview -h -r results in a blank file
listview -s -r does not output the list header
listview -eh -r outputs a list of random hostnames; they are not unique.
listview -a -r is the same as listview -r
Note carefully that running listview -r against a mailing list with a value of nnnn greater than the actual number of subscribers in the list will result in duplicates being written to the view1 file and the generation of a view2 file of length 0.
LISTVIEW executed with no option is the same as 'listview -a'.
You can redirect the output of LISTVIEW with standard OS-dependent redirection symbols. For instance,
listview -h mylist > mylist.file
redirects the output to the ASCII file 'mylist.file'.
JOBVIEW.EXE (or jobview*)
JOBVIEW allows you to read the Base64-encoded spool files created by LISTSERV (see below for the types of files created in the spool directory that may be read with this utility). The syntax is simply jobview file1 file2...
5.3.7 GUI Site Configuration Utility (Windows Only)
Notes: The SITE.EXE and SITE.HLP files are obsolete as of LISTSERV 15.0 and no longer shipped or maintained. Please use the LISTSERV web administration interface to change the site configuration. Also, the Site Configuration Utility for LISTSERV allows you to easily configure LISTSERV's operation. While this can also be done by manually editing LISTSERV's SITE.CFG file, the GUI gives you an easier way to take care of this task. Online help for the various configuration variables is provided, and new LAKs can be entered. Basic optimization for various pre-calculated loads can also be performed.
5.3.8 Line-mode site configuration utility (OpenVMS only)
LISTSERV_CONFIGURE.COM is a very basic line-mode utility that allows you to modify the OpenVMS version of the site configuration file. It is useful for initial configuration, but most OpenVMS sysadmins will probably prefer to edit the SITE_CONFIG.DAT file by hand with a text editor.
Note: Newer configuration variables are not covered by LISTSERV_CONFIGURE.COM. Please use the LISTSERV web administration interface to change the site configuration.
5.3.9 Other files that will appear during use
While in use, LISTSERV creates various files for itself. On the A disk or in the MAIN or HOME directory, these are typically:
.AUTODEL files – Maintain data for LISTSERV's autodeletion functions; one for each list that has Auto-Delete enabled. If no auto-deletion reports are pending, this file will not exist.
.CHANGELOG files – Contain data regarding subscription changes for a given list if that list has the "Change-Log= Yes" list header keyword setting. These files are called listname CHANGELG on VM.
.DIGEST files – These files are the (volatile) digest files for each list that has digests enabled. They are deleted and restarted when the digest is cut. Note that if the location parameter of the Digest= keyword is not set to something that points to the MAIN or HOME directory, then the .DIGEST files will not appear in the MAIN or HOME directory, but rather in the directory specified.
.LIST files – Mailing list files, including the header and subscriber information. Do not attempt to edit these files with a text editor; use the GET and PUT commands instead.
.OKxxxxxx files – Usually found for edited lists, but can also appear for non-edited lists if users are set to REVIEW. These are mail messages that are awaiting "OK" confirmation. If they are not confirmed, they are automatically deleted after about a week.
.OLDLIST files – These files contain the last saved version of the list file. If you PUT a header and find that you've made a fatal mistake (like adding users "on the fly" and deleting everyone else on the list, or editing the list file by hand and corrupting the record structure) you can send the command GET listname (OLD to have the listname.OLDLIST file sent to you.
.SUBJECT files – Maintain the list of subjects for the digest. Again, if digests are not enabled for a specific list, this file does not exist for that list. Also, the same note for the location of these files as for .DIGEST files applies. .SUBJECT files are deleted and restarted when the digest is cut.
In the SPOOL directory, the following file types will be found:
.DELETED – These are processed JOB files that have been left in the spool when LISTSERV was running under a debugging regime, i.e., to compare JOB file input to LISTSERV output. Normally JOB files are deleted from the spool after processing. These files can be viewed with the jobview utility. Unless you are actively debugging something, files with this extension can be safely deleted.
.ERROR – LISTSERV generates an .ERROR file in the spool when it encounters an error in a JOB file. These can be viewed with the jobview utility and are important for tracing certain errors back.
.JOB – Files that have been received by LISTSERV and are queued for processing. These files are in Base64 format and can be viewed with the jobview utility.
.JOBH – Held .JOB files. Such files are either being processed by LISTSERV (and are thus locked) or have generated an error message. These can also be viewed with the jobview utility.
.MAIL – Files that have been processed through LISTSERV and are queued for delivery to the outgoing SMTP mail agent. These are plain-text files.
.MAIL-ERR – Files that have been processed through LISTSERV and for which delivery has been attempted, but for which a "permanent" SMTP error has resulted. If you have reason to believe that the error was not actually "permanent", simply rename the file with the .MAIL extension and LISTSERV will pick it up for another try.
JOBH files containing the string $NOJOB$ in the filename are typically waiting to be processed because the list they are going to has an explicit Prime= variable set and the non-prime time has not yet arrived.
5.4 Installing & Configuring LISTSERV’s WWW Archive & Administration Interface
LISTSERV includes an optional WWW archive and administration interface (not enabled by default). This interface is used to allow users to browse and search notebook archives for lists with the feature explicitly enabled, as well as to allow list owners to manage almost every aspect of their lists and to allow LISTSERV maintainers to perform a number of common site management tasks. The interface is secured by the use of LISTSERV personal passwords. List owners have administrative access only to their own lists; general users have access only to the archives of public lists or to private lists to which they are subscribed (in other words, there is no difference between the access one receives via the web interface and the access one receives via the mail interface).
5.4.1 The WWW Archive Interface
Postings can be organized by date, by topic or by author, and a search function with online help is provided. LISTSERV's WWW interface has the following advantages over "hypermail" style web archiving:
The postings can be organized in the manner that best suits the reader: by date, by author, topic, with/without table of contents, with/without showing the author, etc.
Only one copy of the information is kept, and in particular there is no need to create an individual HTML file for each posting. This design allows the interface to scale up gracefully to lists with hundreds of thousands of archived postings, which would otherwise require hundreds of thousands of individual HTML files, wasting disk space (each file takes up at least one disk block) and stressing the file system past reasonable limits.
The search forms can be used to create search requests matching (for instance) all postings in the last X days. The resulting URL can then be bookmarked and reloaded on a regular basis.
To take advantage of the interface, you must first ensure that the "Notebook=" options for your list are compatible with the WWW interface. In most cases, you will not have to do anything, but certain options are incompatible with the use of the WWW interface and may need to be changed:
The archive frequency MUST be WEEKLY, MONTHLY or YEARLY. SEPARATE and SINGLE notebooks are not supported. L-Soft generally recommends converting lists with SINGLE notebooks to YEARLY unless there is a compelling reason to have all the messages in exactly one file.
For optimal performance, the archive frequency may need to be adjusted to produce an "adequate" number of topics and messages in each archival period. The definition of "adequate" depends on your users, the kind of equipment they have, and how they connect to the Internet. As a rule, home users will prefer a larger number of smaller archives whereas office users with large screens and T1 or better connectivity will tolerate a larger table of contents.
L-Soft strongly recommends that the directory in which your list archives are kept should be specified in the Notebook= list header keyword in absolute rather than symbolic form. Symbolic form is when the directory name is a single letter, for instance "Notebook= Yes,A,Monthly,Public" ("A" being a logical filemode defined in LISTSERV's site configuration which points to the directory where LISTSERV keeps its internal files). In most cases, your list header will probably read something like "Notebook=Yes,E:\LISTS\XYZ-L,Monthly,Public" and you will not have to worry about this.
If a logical filemode is used, LISTSERV will translate it into a full path, but L-Soft still strongly discourages the use of logical filemodes for the "where" parameter of the Notebook= keyword, primarily for security reasons but also to keep things orderly. A full path is always preferred, and each list should imperatively have its own subdirectory. See Section 5.8 Setting Up Archive and Notebook Directories for Use with LISTSERV and Section 18 File and Notebook Archives for details.
The LISTSERV maintainer must then enable the list for the WWW interface. This may require the installation of a web server and of the WWW interface code itself. You can then modify the WWW_INDEX mail template form to customize the main archive page for your list. See Section 16 Creating and Editing Templates Manually for more information on customizing mail templates.
5.4.2 The WWW Administration Interface
Assuming that the WWW interface has been installed correctly, the WWW administration interface is enabled automatically for all lists on the server that are not coded "Validate= Yes,Confirm,NoPW" or "Validate= All,Confirm,NoPW".
The default entry URL is
By default, this directs all users to the LISTSERV archives page. If the default has been changed by setting personal preferences, the archives page can be reached at
The basic URL for the list owner "dashboard" is
where hostname is the name of the LISTSERV host, and script-directory is the name of the directory where "wa" is installed. For unix you specify "wa?OWNER" and for Windows and VMS you specify "wa.exe?OWNER". With some non-unix web servers you may have to type WA.EXE?OWNER (that is, all in upper case) in order for this to work.
Site managers can reach the server administration dashboard at
From here they may create lists, customize site-wide WWW templates, manage DBMS and mail-merge operations, and so forth.
See Section 6 Introduction to the Web Interface for more details on the Web Administration Interface.
5.4.3 Installing a Web Server
Notes: L-Soft cannot help you with the installation or configuration of your web server itself. L-Soft does not recommend or endorse specific web servers, nor does L-Soft have development machines with every possible web server installed. You should ensure that the web server software you choose is installed and operating properly before attempting to install the LISTSERV WWW interface script.
If you do not already have a World Wide Web server installed and operating on your LISTSERV machine, you will need to obtain and install one. There are quite a few free web servers available for downloading on the Internet for most systems; you may want to start your search for server software at the W3 Consortium's web site at Naturally, commercial web servers can also be used.
For security purposes you should always disable directory browsing if it is not disabled by default by your web server.
5.4.4 Installing the Web Archive Interface Script
The CGI script for the web archive interface must be installed in the directory where your web server normally keeps CGI scripts and from which they are authorized to run. If in doubt, please read the manuals that came with your web server and/or contact the web server manufacturer's support group; L-Soft cannot help you with this. LISTSERV cannot install the script for you because installation depends on which server you use, which operating system you are running, how the server has been configured, etc.
Note: The web interface is not designed to be run on a machine separate from the LISTSERV server. It MUST run on the same machine. This means that a web server MUST be installed on the LISTSERV machine or you will not be able to use the web interface.
System specific instructions:
Windows: It is strongly recommended that the web interface be installed when LISTSERV is installed (the installation program prompts you to do so).
However, if it is necessary to install the web interface manually: Copy WA.EXE to the appropriate directory. For Microsoft's Internet Information Server (IIS), this is normally C:\INETPUB\SCRIPTS (not C:\INETPUB\WWWROOT\SCRIPTS). For Apache for Windows, this is normally C:\apache2\cgi-bin.
WA.EXE builds shipped with LISTSERV 16.0 communicate with LISTSERV via TCP/IP. If your %SystemRoot% directory (e.g., C:\WINNT) is on an NTFS partition, in order for this to work properly it may be necessary to grant the "Everyone" user (or at least the user that invokes WA.EXE, for example, IUSR_xxx under IIS) R/X permissions on the following files in the %SystemRoot%\system32 directory:
Under IIS the invoker is normally the IUSR_xxx user created when you install IIS. Other web servers are probably different and you may have to check the logs to see what user is invoking WA.EXE.
This instruction can be ignored if your %SystemRoot% directory is on a FAT or FAT32 partition. However, using FAT or FAT32 partitions is insecure and is not recommended.
unix: The LISTSERV installation kit will offer to install the web interface, but if it is necessary to do a manual install, you can copy 'wa' to the appropriate cgi-bin directory, change its owner to 'listserv' and set the suid bit (typically, 'chmod 4755 wa'). This authorizes the interface to read archive files. Please note that one of the most common problems with 'wa' under unix is that the installer has not followed this instruction.
OpenVMS: A precompiled WA.EXE is provided. However, for some webservers, you may need to link WA.OLB with the CGI library provided with the web server to make a new WA.EXE. You then copy it to the appropriate cgi-bin directory. Make sure to arrange for the program to have read access to the archive files for the lists you want to serve on the web. Again, this may vary from one web server to another.
While the script can be renamed, a short name will help keep the HTML documents small and speed up the site.
5.4.5 Creating Subdirectories for the Archive Interface
For the Archive Interface, you need to create a subdirectory on your web server to contain the various files LISTSERV will be creating for the web archive interface. The suggested name (and the name LISTSERV will expect by default) for the subdirectory you will create in this step is 'archives'. Under IIS, you would typically make the directory C:\INETPUB\WWWROOT\ARCHIVES for this purpose. For a unix server running Apache, it might be /var/www/html/archives.
You must also add an additional directory under the Archives directory to receive all files and text uploaded via ‘wa’ (including all attachments added to list postings by subscribers). This directory must be named ‘upload’. Assuming the default ‘archives’ path suggested above is being used, then under IIS, you need to make the directory C:\INETPUB\WWWROOT\ARCHIVES\UPLOAD for this purpose. For a unix server running Apache, it would be /var/www/html/archives/upload.
Important: Please note the following restrictions carefully:
Do not simply use your main HTML documents directory as LISTSERV will create quite a few files. It is much more orderly to keep the web archive interface's files and subdirectories in their own place in any case.
Do not use the directory you keep the list's notebook archives in for this purpose. Notebook archives should always be kept separate from the web interface, preferably in a completely separate directory hierarchy.
Do not set the Notebook= keyword for any list so that the list's notebook archives are kept in the subdirectory used by the web archive interface for the list.
For specifics on what should be kept in what directories, see Section 5.8 Setting Up Archive and Notebook Directories for Use with LISTSERV.
System specific steps:
OpenVMS: define the system-wide logical LISTSERV_WWW_ARCHIVE_PATH to point to the directory you just created, and LISTSERV_WWW_ARCHIVE_URL with the URL to the directory in question (preferably relative).
unix: create a world-readable file called /etc/lsv-wa.config with the following two statements:
PATH xxx
URL yyy
where 'xxx' is the absolute path to the directory you've just created and 'yyy' is the URL to this directory (preferably relative). For instance:
PATH /usr/local/etc/httpd/htdocs/archives
URL /archives
Windows: If necessary (and it shouldn't be), you can update the registry key HKEY_LOCAL_MACHINE\SOFTWARE\L-Soft\LISTSERV\WWW_ARCHIVE_URL to override the default URL to the directory you have just created. Again, this is not normally necessary and is only provided for weird web servers, etc. Don't do it unless it didn't work without it.
5.4.6 Configuring LISTSERV to Activate the Web Archive Interface
This is done by modifying LISTSERV's site configuration file (see the Site Configuration Keyword Reference document) to add two variables:
WWW_ARCHIVE_CGI is the (preferably) relative URL that leads to the CGI script you have just installed. Typically this will be something like '/cgi-bin/wa' or '/scripts/wa.exe'. This is a URL, not an OS path name.
WWW_ARCHIVE_DIR is the full OS path name to the directory you created in the previous step (C:\INETPUB\WWWROOT\ARCHIVES or whatever).
Under unix, you may have to export these variables (you can check the 'go' script to see if they are already exported for you; in early versions of the interface they were not) by adding these lines:
at the end of go.user. Again, if these variables are already exported in the 'go' script, there is no need to do this.
LISTSERV will then create and maintain a file called:
from which you can access all the postings. (This is made from the template WWW_ARCHIVE_INDEX – see below.)
Note: Proper operation of the interface requires that the 'wa' script be able to talk to LISTSERV via TCP/IP to the local port 2306 (LISTSERV's TCPGUI port). This may require a local firewall exception, but there is no technical need for the port to be opened to the world at large.
5.4.7 Customizing the Web Pages
The simplest (and recommended) way to make changes to the templates that contain the information for these pages is to use the tools provided in the WWW administration interface for changing the "look" of your site. Because the template system has become quite complicated, we strongly recommend using the web interface tools for this purpose rather than trying to edit the template files by hand.
Most of the templates for the web interface are found in the file default.wwwtpl. Templates that you edit are placed in a file called site.wwwtpl.
You should never make changes to default.wwwtpl itself as it is always overwritten when LISTSERV is upgraded.
5.4.8 Enabling Individual Lists
Once the interface is installed, LISTSERV will automatically make any existing mailing list with public archives available through it, provided that a subdirectory has been created for them in the 'archives' subdirectory created above, and provided that LISTSERV has read/write access to the subdirectory.
In addition, when creating new lists using the web interface, the web archive sub-directory can be automatically created by choosing the appropriate option.
Figure 5-1 Enabling Web Archive Interface and Creating Necessary Directories
Warning: CONFIDENTIAL=YES does not limit access to the Archive. Public notebooks for any list coded "Confidential= Yes" will be available via the interface if a subdirectory under 'archives' is created for that list. However, the list will not appear on the main archive index page if you have coded "Confidential= Yes". In this case there are two avenues for users who know the list exists and want to access the web archives:

1.) Users can bookmark or manually enter the link to the list's archives, for example,

2.) Users can click on the link at the bottom of the main index page that pulls up an "unlisted archive" form, into which they can type the name of the list.

On the other hand, if you code "Confidential= Service", your list will show up on the main archive index page for your server but will not show up in the CataList or global list of lists.

"Private" notebooks can be viewed via the WWW interface by following the same instructions as for "Public" notebooks. However, in order to view the notebooks, subscribers must log in with their subscribed email address and their LISTSERV password (set with the PW ADD command or via the WWW interface).

Please note carefully that if the user is subscribed as "" and tries to log in as "", he will be refused access. Also note that unless the list is coded "Confidential= Yes", there will be a link to its archives in the main archive index page.

If you do not want the confidential and/or "Private" list's notebooks available via the WWW interface at all, simply do not make a subdirectory for it under 'archives'.

Please note that when deleting a list without deleting the list's archive notebooks, you MUST delete the list's index directory under the web interface. Otherwise someone with a bookmarked URL may still be able to access some of the archives via the web.

Also note that under unix, if the 'wa' script does not have the suid bit set, the interface will appear to work normally until you try to read a message. If the suid bit is not set, you will receive a message saying the archives are not available and to try again in 30 seconds.
As an example, let's assume that you have a list called XYZ-L that you want to make available through the Web interface, and that so far you have used the defaults for the installation of the interface.
First, under the 'archives' directory you created above, you must create a directory with the same name as your list. Thus, in order to make the XYZ-L list accessible through the interface, you must create the directory 'archives/xyz-l'
Next, you would edit the XYZ-L header to indicate how you want the list to appear to the interface. If you want the archives to be wide open, you must code
* Confidential= No
* Notebook= Yes,where,interval,Public
If you want the archives to be "wide open" but don't want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Public
If you want the archives to be accessible only by subscribers (with a password) and to have a link on the main archives page, you would code
* Confidential= No
* Notebook= Yes,where,interval,Private
And, if you want the archives to be accessible only by subscribers (with a password) but you do not want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Private
Finally, if you want the archives to be available via the interface (either with or without a password), and you want a link on the main archives page, but you do not want your list to appear in the CataList or global list of lists, you would need to code
* Confidential= Service
and Notebook= would be either Public or Private depending on your preference.
Note: Coding the Confidential= keyword has other implications. For instance, if you want your list to show up in the CataList or be available via the Global List Exchange (GLX), you must set Confidential= No. Thus advertising your list globally is not compatible with having your archives available via the web but not having a link on the server's main archives index page.
Finally, you would simply perform a GET and PUT of the XYZ-L header (or store it from the web interface without making any changes). When you PUT the header, LISTSERV will create the XYZ-L.HTML file in the ‘archives‘ directory and build indexes for the list in the ‘archives/xyz-l’ directory.
Note: If you do not execute a list PUT operation after creating the directory for the list under ‘archives’ (for instance, if the list already had public archives and it was not necessary to edit the header), LISTSERV will wait until midnight to create the web archive files for the list rather than creating them immediately. (Naturally, stopping and restarting LISTSERV will also force a rebuild of all of the web interface files but is not recommended as the normal way to accomplish this.)
At this point you will be able to access XYZ-L's archives from the URL
5.4.9 Enabling Web-Based Bulk Operations
Bulk operations (part of the list owner administration section of the interface) are not enabled by default when the interface is installed. As the site manager, you must create a directory called "upload" under the directory specified in the WWW_ARCHIVE_DIR= site configuration variable, and give the userid under which the "wa" CGI program is run write permission in that directory. This is the only directory in which "wa" needs write authority, and only for this functionality. If you do not want the functionality, do not create the "upload" directory.
Note: Your browser MUST support the RFC1867 file upload extension or you will not be able to use the bulk operations page. Most current browsers support this extension.
If you get "error 2” when clicking on the [Import] button; then the "upload" directory has not been created.
If you get an "error 13" when you click on the [Import] button, then the "upload" directory has been created but the CGI program user does not have write permission.
5.4.10 RSS Support for Web Archives
RSS support for LISTSERV web archives is inherent in the WA CGI and does not need to be turned on to be available.
The existing RSS support in LISTSERV's web archive interface has been improved by the addition of RSS abstracting, which is available in LISTSERV RSS feeds by default.
Note: Existing web indexes must be recreated to add the abstracts. This is a one-time operation that could take a while on a large site and is better left to be scheduled by the administrator. (See the documentation for the REINDEX command in Section 14.2.2 List Management Functions.) The abstract is either generated implicitly from the existing text of the message, or it may be specified explicitly by the use of a tag in the message.
In order to properly specify the explicit abstract, a mail client that supplies a plain-text part that matches the message is REQUIRED. Most if not all modern mail clients fit this specification.
For those using plain text messages: An explicit abstract is specified by using <abstract> and </abstract> tags in the body of the message - typically at the very end, but the explicit abstract may in theory appear anywhere in the message. The closing tag is optional but recommended.
For those using HTML-capable mail clients: If the mail client is unable to provide a user-specified plain-text alternative and instead sends a "canned" message to the effect that mail clients that do not support HTML will not be able to read the message, the "canned" message will be the abstract. If the mail client is not capable of providing a plain-text alternative message part at all, and provides HTML only, no abstract will be available.
For those posting messages using the web interface: A dedicated text box for entering explicit abstracts can also be enabled in the message posting interface. List owners can set the RSSINPUT variable to 1 in the list-specific SKIN template. To enable the dedicated text box for all lists, the server administrator should set the RSSINPUT variable to 1 in the site-wide SKIN template.
There is no word limit when an explicit abstract is specified.
There is a new site configuration variable, RSS_ABSTRACT_WORDS, which controls the size and/or the presence of the abstract in the feed.
There are two parameters: a maximum abstract size and a minimum abstract size. The second parameter is optional, and if left unset, defaults to 50% of the maximum size. The basic syntax is:
unix: RSS_ABSTRACT_WORDS="500 250"
The site-level value may be overridden at the list level with the new list header keyword RSS-Abstract-Words, whose basic syntax is:
RSS-Abstract-Words= max[,min]
For example,
RSS-Abstract-Words= 100
RSS-Abstract-Words= 100,25
LISTSERV stops at the first paragraph boundary after which it has collected at least 'min' words, adding an ellipsis if there is more text (compliant signatures are ignored). If there is an explicit abstract, then the min and max parameters are ignored and the abstract is whatever the user entered. If the stop-on-paragraph-end feature is not desired, simply set "min" to the same value as "max".
If RSS abstracts are not desired, then setting the maximum to 0 disables the abstract.
In all cases, RSS_ABSTRACT_WORDS and/or RSS-Abstract-Words may be changed at will, with the change taking effect "from now on." In order to make the new value take effect retroactively, the indexes must be rebuilt manually. Because of the resource-intensive nature of the REINDEX command, this will NOT happen automatically.
5.5 The Spam Features
L-Soft acknowledges that these features have been continually upgraded and enhanced throughout the development process, but in keeping with previously-announced policy, specifics are proprietary and will not be documented.
5.5.1 Spam Quarantine
One of the most arduous problems the spam detector has to face is the accurate detection of the first few copies of the spam. When the first copy reaches the first LISTSERV server worldwide, it is just a posting like any other. It will take repeated occurrences of this same posting for LISTSERV to realize that it is in fact a spam. However, it is desirable to block this very first copy as well, and this can only be accomplished by introducing a delay in the processing of "suspicious" messages. This "quarantine" gives the spam detector some time to gather the necessary evidence to determine if the message is a spam or not. The default value is 10 minutes, and can be changed by adding:
* Loopcheck= Spam-Delay(xxx)
in the list header (the value is in minutes). The LISTSERV maintainer can also change the system default by adding a SPAM_DELAY variable to the LISTSERV configuration with the desired value (also in minutes). A value of zero disables this part of the spam filter.
(It should be carefully noted that setting SPAM_DELAY=0 does not turn off LISTSERV's spam filter. It turns off only the spam quarantine part of the overall filter. There is no setting to disable the spam filter server-wide; it can be turned off only at the list level, with "Loopcheck= NoSPAM" in the list header.)
The default value of 10 minutes is adequate in most cases; it can be lowered on fast, large, active servers and may need to be increased on servers with backlogs. Currently, LISTSERV determines whether a message is suspicious or not based on the sender's posting history. This however may be changed in future versions to further improve the efficiency of the spam detector.
5.5.2 "Anonymous" Spam Alerts
On occasion, you may receive a spam alert from LISTSERV where the offender's e-mail address is replaced with the word "anonymous". These alerts are generated by new detection algorithms where, for various reasons, it may sometimes be desirable to hide the identity of the potential offender, usually because there is a fair chance that the posting is in fact legitimate for the particular lists to which it was posted (for instance because these lists were configured to tolerate a high degree of cross-posting). In this case, information about the text of the message may be released and ultimately lead to a spamming alert that will block further copies of this same message, while the identity of the poster remains hidden.
5.5.3 Subscription Anti-Spoofing Feature
About a decade ago, a number of point and click utilities began to appear on anonymous FTP servers, allowing mischievous users to forge Internet mail on an industrial scale and subscribe an unfortunate victim to thousands of mailing lists. The resulting mail onslaught fills the victim's mailbox in minutes, rendering the account forever unusable. It also brings the mail server on which the account is hosted to its knees, causing, in some cases, tens of thousands of dollars in consequential damages as other users of the same system also lose precious e-mail.
In most cases, the account ends up being closed. Unfortunately, this usually doubles the load on the recipient's mail server, as a delivery error needs to be generated for every message received from the mailing list servers. Thus, it is not uncommon for the service provider to leave the account open and simply reconfigure it in such a way that incoming mail continues to be accepted, but is summarily discarded without generating a costly delivery error notification. While it is difficult to blame the service provider for wanting to minimize impact to their customers, the drawback is that the list owners may never be notified of the fact that the account was closed. On any large LISTSERV system, there are likely to be dozens of these addresses, each being sent hundreds or possibly thousands of messages a day which are simply discarded and waste resources.
Until now, the only defense against this attack was to configure mailing lists to require subscription confirmation:
* Subscription= Open,Confirm
LISTSERV will then send a confirmation request to the victim, who does not reply and thus is not added to the list. While this line of defense is 100% effective, it may not always be practical or desirable to configure the list to require confirmation.
As a result, L-Soft modified LISTSERV to be able to detect these "spoofed" subscription attacks automatically. When more than the default of 50 subscription requests are received from the same account in a short time frame, LISTSERV automatically undoes all the subscription requests and rejects any further subscription attempt for a certain period of time. This applies even to requests that LISTSERV forwarded to other servers; LISTSERV will then send a SIGNOFF request to the remote server for the address in question. Note that, in some cases, the subscription may not be undone, either because of a temporary condition (locked list, etc.) preventing LISTSERV from deleting the user, or because the list was configured with "Subscription= By_Owner" and the owner manually added the victim after the arrival of the undo request.
This mechanism offers a very good degree of protection against the adverse effects that dead "spoofed accounts" can have on the performance of the LISTSERV host system. It does not, unfortunately, mean that people no longer have to fear subscription spoofing, as only LISTSERV lists are monitored and protected by the "spoof detector". Requests to subscribe to lists hosted by other mailing list managers are sent directly to the list managers in question, and LISTSERV can only act on the requests that it does receive.
If desired, the maximum number of consecutive subscription attempts can be adjusted by setting the LISTSERV site configuration variable MAX_CONSECUTIVE_SUBS.
5.5.4 Hosted Content Analysis
This feature is now available in LISTSERV 16.0 for customers with paid maintenance.
For some time, LISTSERV Maestro has incorporated the ability to perform a deliverability evaluation on messages it is used to compose and send. However, this feature required several prerequisites:
Because the first two prerequisites are difficult to implement, few sites use this feature, even though it can do more for deliverability than L-Soft's HDMail product.
Therefore L-Soft has implement a hosted service that will be available at no charge to customers with maintenance. This feature is enabled when LISTSERV is installed and your current maintenance LAK is applied. Once this is done, there is nothing to configure; it is entirely automatic.
If a SPAM_EXIT is present, by default, both the SPAM_EXIT report and the hosted report are shown. The hosted report can be disabled if it is preferred to show the results of local spam filter instead.
For details on using this feature in the Message Posting Interface, see Section 13 Posting Messages to a List using the Web Interface.
5.5.5 Using the SMTPL-Level Spam Control for Windows
The SMTPL.EXE SMTP "listener" service has the ability to submit inbound mail to a third-party spam scanning product. In LISTSERV 16.0, this feature allows sites with significant inbound spam problems to scan and reject spam before it reaches the main LISTSERV process, thus freeing LISTSERV itself to handle legitimate mail.
For details on configuring this service, see the Advanced Topics Manual for LISTSERV 16.0.
5.6 Server Registration
5.6.1 Registering LISTSERV Classic and Classic HPO Servers
Notes: This section and Section 5.6.2 How do I find out if my server is already registered? do not apply to evaluation kits or to LISTSERV Lite kits. Evaluation copies of LISTSERV should not be registered because they are (presumably) temporary servers running test lists, whose existence should not be broadcast.
LISTSERV Lite Free Edition runs only in TABLELESS mode and therefore cannot be registered in the same manner as LISTSERV Classic. LISTSERV Lite paid sites may run only in TABLELESS or STANDALONE runmode, and as such cannot be registered either. In addition, LISTSERV Lite sites, whether Free Edition or not, may not participate in the LISTSERV backbone. For information about how LISTSERV Lite servers are registered, please see Section 5.6.4 Automatic Registration for LISTSERV Lite Servers.
Also note that only those LISTSERV Classic and Classic HPO servers running in NETWORKED mode may be registered.
Once the server is ready for production use (that is, once you have installed a permanent License Activation Key, and once you have arranged for LISTSERV to be started automatically when the system boots), you should register it with L-Soft by filling in a server registration form, and returning it to SUPPORT@LSOFT.COM. Registering the server is necessary to broadcast its existence to the other LISTSERV servers. Once you have registered, your server will be sent periodic updates about the lists hosted by other LISTSERV sites and updates to the files whose versions are shown in the output of the RELEASE command, among other things, and, similarly, other LISTSERV sites will receive information about the public lists you are hosting.
The LISTSERV site registration request form is found at the URL
along with the requirements that must be met for registration.
5.6.2 How do I find out if my server is already registered?
If your server is already registered, it will have a :node. entry in LISTSERV's INTPEERS.NAMES file. If your node name is LISTSERV.EXAMPLE.COM, you can look for the line
in that file.
If you are still unsure, simply contact L-Soft support and ask.
5.6.3 The LISTSERV Backbone
The last question on the registration form is whether or not you wish for your site to participate in the LISTSERV backbone.
The LISTSERV backbone is a collection of servers that are operated for 24 hours and maintained on a regular basis by their respective staffs. This backbone is used to support the DISTRIBUTE command and to host heavy-traffic network-wide peered lists.
LISTSERV servers can fall into one of two categories:
Local Server – A local server has by definition no obligation towards the rest of the network. It can run any release of the code, with or without local modifications. Its operation staff can update it at irregular intervals, place it offline 14 hours a day, or do just anything they might see fit to do. The server will appear in the network routing files but it will be flagged as being a local server.
The only two restrictions placed on local servers are:
If the server's operation staff encounter a problem with the software and the latest available release of the code has not yet been installed on the server, in general L-Soft support will recommend upgrading to the latest release before trying to diagnose a problem which may have been fixed between releases.
Local servers are not allowed to create peer lists. Note that the term "peer list" should be interpreted as meaning "network-wide public peer list". A closed peer list local to the various nodes of an institution does not fall into that category.
A local server can create a network-wide list by means of the Mail-Via= DISTRIBUTE feature. Local servers can submit DISTRIBUTE jobs to the backbone, but will not receive any. If a peer sub-backbone is required for the list (e.g. if large archive files are to be made available), the local LISTSERV operations staff should try to find hosts in the backbone or should join the backbone.
Backbone Server – A backbone server can do all of the above, can create peer lists and is supposed to receive DISTRIBUTE jobs. The restrictions placed on the backbone sites are the following:
A backbone server should always be at the latest available level. This means that the operations staff must take whatever steps are necessary to update it in a timely basis. The average delay should not exceed one week, with the deadline being two weeks.
A backbone server cannot be placed offline on a regular basis. It must operate 24 hours/7 days. It can of course be placed offline manually under particular conditions, lists can be held by their respective owners, etc.
(VM) A backbone server must be AUTOLOG-ed when the system is IPL-ed, and ought to be automatically restarted at regular intervals in case it logs off due to some hardware failure (e.g. paging error). This applies only if such a restart facility is already available at the site hosting the server. In any case, local operators should be able to restart it if they are also able to restart RSCS and other service machines. That is, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
(Non-VM) A backbone server must start automatically whenever the system is rebooted, and should have some facility to restart if it crashes during operation. As with VM servers, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
A backbone server should have the latest version of BITEARN NODES, or in the worst case, the version from the previous month. This applies only if the NODUPD files are received in due time of course.
Sites which are willing to become part of the LISTSERV backbone should indicate it in the :backbone tag of the registration form returned to However, please note that unless you have a large number of lists, or a number of very large lists, it is probably not necessary for you to join the backbone. Sites running a few small support or hobby lists, for instance, don't need to be on the backbone; sites running hundreds of lists both large and small do need to be on the backbone. Also, sites running one or two huge lists (greater than, say, 50K subscribers each) probably should be on the backbone; such sites should contact L-Soft for more information.
5.6.4 Automatic Registration for LISTSERV Lite Servers
LISTSERV Lite servers are registered automatically when you start the software for the first time. This auto-registration is not optional for Free Edition servers, and can only be disabled for non-Free Edition Lite servers by specifying STANDALONE runmode (see "RUNMODE=" in the Site Configuration Keyword Reference document).
The auto-registration allows you to take part in the global List of Lists and CataList services maintained by L-Soft. Registrations are verified on a regular basis by a central L-Soft server, which sends out several informational commands that return non-privileged information about your server (anyone can issue these commands). Since these registrations are maintained by regular communication with your server, please note that, should you decommission the server, registration verifications will continue to be mailed to your server for several days until the central server decides that your server is actually gone, and not simply unable to receive mail for some reason. Please note carefully that it is not possible for L-Soft to stop these registration queries manually even if you write to us and tell us that the server has been shut down permanently. They will stop after several days without a response.
5.7 Inter-Server Updates
Because networked LISTSERV servers operate as part of a distributed system, they do a certain amount of inter-server "chatting". This "chatting" takes the form of DISTRIBUTE jobs, X-LUPD jobs, X-SPAM jobs, and so forth. Some of the jobs are requests for statistics for the LISTSERV network; other jobs are updates to the list of lists; still other jobs are spam alerts. None of these jobs contain privileged or private information; L-Soft does not query your server for licensing information or any non-LISTSERV-related data, and in fact, all data sent out regarding your server can be retrieved by any user with documented LISTSERV commands.
If you are running LISTSERV Classic, and you do not want to participate in the full-fledged LISTSERV network for whatever reason, you can make a change in your site configuration file to run your server in "standalone" rather than "networked" mode. Simply set the RUNMODE= variable to the value "STANDALONE" and stop and restart your server (see the Site Configuration Keyword Reference document for the syntax applicable to your OS). Note that this will remove your server and all otherwise-public lists running on it from the CataList and the global List of Lists.
LISTSERV Lite (Free Edition) sites are not allowed to change their runmode. If this is a security issue for your site, L-Soft suggests purchasing either the commercial edition of LISTSERV Lite or LISTSERV Classic and running in "standalone" mode.
5.8 Setting Up Archive and Notebook Directories for Use with LISTSERV
We have found that often people get confused about the difference between the directories where the mailing list's notebook archives are kept and the directories where the mailing list's web archive interface files are kept. Here are a few guidelines:
L-Soft's STRONG RECOMMENDATION is that each list be given a separate directory in which its notebook archives and any files available via LISTSERV's file server are kept. On VM this is not always practical, but the security concerns are different and (to date) the 'wa' interface is not available in any case. For OpenVMS, unix, and Windows systems, our STRONG RECOMMENDATION is that a separate directory tree be established for the purpose of storing list notebook archives and other related files. For instance, you might create
Table 5-3 Creating Archive and Notebook Directories
Then, under the main "lists" directory, you would create further subdirectories, one for each list that has archives.
An example for unix is /home/listserv/lists/mylist-l
An example for Windows is C:\LISTSERV\LISTS\MYLIST-L
Note: Under unix, the directory path specification for notebook archives MUST IMPERATIVELY be in lower case. LISTSERV will not write notebooks to directory paths specified in upper- or mixed-case.
Where you locate list archives is particularly important with regard to LISTSERV's file server functions. You MUST NOT set up a file server sub-catalog entry in site.catalog that points to LISTSERV's A directory! The catalog owner will be given FULL ACCESS to all the files in the directory you specify in the sub-catalog entry. Therefore in order to maintain security you MUST make a separate directory for each list catalog you define in site.catalog. For simplicity's sake, it is generally best to use this directory for the list's notebooks as well as any files the list owners may want to store except for the web archive interface files.
Files generated by LISTSERV for the web archive interface MUST NOT be stored in the notebook directories (or vice versa). You MUST make a separate directory tree where the HTML files and index files for the 'wa' interface are kept. Our best recommendation is to place this directory tree under your web server's document root directory, so that the HTML files for the web archive interface are reached by using a URL such as http://yourserver/archives/. The location of this directory naturally varies from platform to platform and web server to web server; the guidelines in Section 5.4.5 Creating Subdirectories for the Archive Interface will give you a start on finding this location.
5.9 DBMS and Mail Merge Functions
For information on installing and using these features, please refer to the Advanced Topics Manual for LISTSERV.
5.10 Synonymous Host Name Registration via ALIASES NAMES
LISTSERV has supported hostname aliases since BITNET added support for this function in 1990. You could define that BITNET node (say) VTVM1 was the same as VPIVM1 and VPIVM2 (old names) and was also known as VTVM1.CC.VT.EDU. Since this was designed into the first major rewrite of LISTSERV, it is very efficient and there is almost no performance penalty. It also works globally, i.e., once the equivalence is defined, it works for all lists and all users.
However, the Internet did not have a similar mechanism for registering aliases, so this function was only useful to BITNET sites, although the underlying code would also have worked with Internet aliases if there had been a way to register them.
LISTSERV supports a centralized list (called ALIASES NAMES) of synonymous Internet hostnames. The main purpose is to address problems with ISPs where the "From:" line is rewritten from (say) "", which is what Joe wanted, to "", "", "" and so forth, where "alpha", "beta" and so on are known machine names (with the understanding that they may add machines from time to time) and "joe" is the same in all cases. In this way it is possible for LISTSERV to match with his actual subscribed address of or any of the other cluster hosts in his domain.
This can also handle a situation where an ISP changed name and for instance "" is rewritten to "". However this does not handle "" -> "" and the like.
Requests for additions to ALIASES NAMES are handled by a web form:
Note: While it is possible to add entries to your local copy for your local host, you should NOT do this as they will not be propagated through the network and will simply be overwritten by the next update.
5.11 Real-Time Anti-Virus Scanning
This feature is not available in LISTSERV Lite.
LISTSERV Classic or LISTSERV Classic HPO running on Windows 2000 or later, or on Linux, is required. In addition, current LISTSERV maintenance is required. Other OS platforms may be supported in the future.
LISTSERV 15 includes optional real-time, on-the-fly anti-virus scanning of all messages sent to LISTSERV mailing lists. All parts of such messages, including inline uuencoded binaries and MIME attachments in those messages, are scanned and bounced back to the sender if viruses are present. Messages sent to the *-request and owner-* pseudo-mailbox addresses used by LISTSERV (see Section 25.3.4 Other Aliases Used by LISTSERV) are also scanned and discarded if they contain viruses. This includes mail sent to the listserv-request and owner-listserv pseudo-mailboxes.
This is a value-added feature which, in addition to a regularly-licensed LISTSERV Classic or LISTSERV Classic-HPO installation, requires the following:
A "maintenance" LAK in addition to your regular LAK, meaning that you must purchase maintenance (which includes automatic anti-virus signature updates for the term of the LAK) for LISTSERV in order to use the feature; and
A copy of F-Secure Anti-Virus, which is available for download from L-Soft's web site. This download is free for licensed LISTSERV sites with annual maintenance.
The anti-virus scanning feature includes:
The above warnings are controlled by the site configuration variable LICENSE_WARNING= as usual. And, as usual, it is not recommended to disable the license warnings as you may miss an expiration date without any warning and/or your anti-virus signature databases may not be kept up to date without your knowledge.
The site configuration variable, ANTI_VIRUS= , defaults to 1 (enabled) if the supported AV system is detected and 0 (disabled) if it is not. Attempts to manually enable antivirus scanning by setting the variable to 1 are ignored if the supported AV system is not detected.
The virus checking capability is enabled if (1) the supported AV system is present, (2) a maintenance LAK is loaded and not expired, and (3) ANTI_VIRUS=0 is not specified in the site configuration file. List owners may not turn off AV checking (design decision -- security). Messages containing viruses are always returned to the sender (design decision – the sender ought to be warned) even if filtering is otherwise enabled. However, attachments which have been filtered are not scanned for viruses (they are discarded).
5.12 LISTSERV DomainKeys Support
In order for DKIM support to work, we assume that DKIM support has already been configured in DNS for the domains you will be signing for, per the DomainKeys documentation. For your convenience, we have excerpted the relevant section from the Internet Draft for DomainKeys below.
DKIM support is available for LISTSERV Classic and HPO, on all operating systems except for VM. It is not available in LISTSERV Lite.
5.12.1 Creating DKIM Keys and Configuring DNS
The following is an excerpt from the controlling Internet Draft for DomainKeys.
For ease of explanation, the openssl command is used throughout this
document to describe the mechanism by which keys and signatures are managed.
There is currently no standard method defined for storing public-keys in the DNS. As an interim measure, the public-key is stored as a TXT record derived from a PEM format [PEM], that is, as a Base64 representation of a DER encoded key. Here is an example of a 768 bit RSA key in PEM form:
To save scarce DNS packet space and aid extensibility, the PEM wrapping MUST be removed and the remaining public-key data along with other attributes
p = public-key data, encoded as a Base64 string. An empty value means
that this public-key has been revoked. This tag MUST be present.
5.12.2 LISTSERV Configuration
LISTSERV's DKIM support is configured by doing two things.
Each private key is stored as a text file in LISTSERV's main or home directory (that is, the directory where the *.list files are) and must be named xxx.dkim, where xxx is the arbitrary name you choose to give the key. If you only use one key, it is recommended to name it default.dkim.
The file is created in the usual openssl/RSA format, with one minor modification. Here is an example:; s=test
The first line in the file must include a specification for the 'd=' and 's=' parameters of the DomainKeys signature (in whatever order, as long as they are both there). Per the controlling Internet Draft for DomainKeys, these variables specify the domain for which you are signing ("d=") and the "selector" that is used to form the query for the public key ("s="). For instance, let’s say that your public key is registered as follows in the DNS: IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
Please see the DomainKeys documentation for more information.
In your site configuration file, add a DKIM_SIGN= variable containing a blank-separated list of domains that you are able and willing to sign for. You can use wildcards, but only of the form '*.EXAMPLE.COM'. You can't use, for instance, 'SALES.EXAMPLE.*'. For each entry in the list, specify the key to be used, as follows:
(Under unix, don't forget to export DKIM_SIGN .)
By default, the key called DEFAULT is used (if one exists). So, in the sample above, the key for EXAMPLE.COM will be fetched from DEFAULT.DKIM whereas the key for EXAMPLE.CA will come out of CA.DKIM.
5.12.3 Starting LISTSERV with DKIM Support
LISTSERV loads the keys at startup and makes simple verifications.
8 Dec 2005 12:07:42 Loading DomainKeys private keys...
8 Dec 2005 12:07:42 -> Loaded DEFAULT (d=EXAMPLE.COM; s=TEST; RSA-768)
8 Dec 2005 12:07:42 -> Loaded CA (d=EXAMPLE.CA; s=TEST; RSA-768)
8 Dec 2005 12:07:42 DomainKeys support enabled
In particular, the 'd=' parameter in the key must match or be a parent of the domain you want to sign for. Thus, the key for EXAMPLE.COM can be used to sign for EXAMPLE.COM and *.EXAMPLE.COM, but not for EXAMPLE.CA. LISTSERV will skip any invalid entries. Keys are kept in memory so you can have as many as you want.
If there is no DKIM_SIGN variable or if you are running a LISTSERV version without DKIM support, LISTSERV does not attempt to load any keys and the DKIM feature is bypassed.
5.12.4 Using DKIM with LISTSERV
With mailing lists:
Incoming DomainKeys signatures submitted to a mailing list will be suppressed unless "Misc-Options= KEEP_DKIM_SIGNATURE" is set in the list configuration.
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DKIM is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for Yahoo subscribers.
For announcement lists, "Misc-Options= ADD_DKIM_SIGNATURE" is available to have LISTSERV sign all messages from the list (including digests and indexes). This option also tells LISTSERV to sign administrative messages, welcome messages, and the like for the list.
If desired, both options can be specified for all lists via the DEFAULT_MISC_OPTIONS= site configuration variable.
A DKIM=NO|YES option is available for the DISTRIBUTE command (default: NO). This will fail if running a LISTSERV version without DKIM support, but otherwise it always succeeds. Messages originating from domains for which LISTSERV has been configured to sign will be signed, while those originating from other domains won't be.
In other types of messages:
Once you have become comfortable with DomainKeys signatures, you may want to have LISTSERV sign every message that it generates, regardless of its source. Setting DKIM_SIGN_ALL=1 in the site configuration file tells LISTSERV to try to sign every message for which it has a suitable private key, as defined in the DKIM_SIGN configuration parameter
(Under unix, don't forget to export DKIM_SIGN_ALL if you use it.)
5.12.5 Restrictions and Implementation Choices
LISTSERV will not sign messages that already have a DomainKeys signature. Double DKIM signatures are disallowed in most cases and, even when allowed, there is a risk that they may not be handled correctly by all implementations. This does not apply if the incoming DomainKeys signature has been discarded (e.g. mailing list without "Misc-Options= KEEP_DKIM_SIGNATURE"). In that case, the message can be signed without risk of false positive.
DKIM can be used to sign mail-merge messages, but in that case LISTSERV's Embedded Mail Merge (EMM) feature MUST be enabled. Using EMM is the only way to guarantee that the signing engine will see the exact text being sent to the recipient, and that the signature will match.
5.13 LISTSERV LDAP and Dynamic Query List (DQL) support
These features are not available in LISTSERV Lite. They require LISTSERV Classic or Classic HPO.
LISTSERV is able to interface to LDAP servers to authenticate user logins and to insert LDAP attributes in mail-merge distributions. For full information on LISTSERV/LDAP integration, please see the Advanced Topics Manual.
In addition, LISTSERV is now able to execute on-demand Dynamic Queries against either LDAP or traditional DBMS servers, and use the results for access control or mail delivery. For instance, an LDAP query against an Active Directory server could be used to grant list owner privileges to all members of a particular Windows Security Group. A DBMS query could be used to combine employee rosters for two departments and send a single copy of an announcement to each unique employee e-mail address. For more information on Dynamic Query Lists (DQL), please see the Advanced Topics Manual.

L-Soft international, Inc.