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.

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.

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.

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.

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.

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.

-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:

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.

.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 listnameCHANGELG 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.

.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.

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).

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.

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.

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.

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.

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:

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, 'chmod4755wa'). 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.

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.

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:

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.

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).

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.

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, http://www.yourhost.com/archives/yourlist.html

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 "joe@unix1.host.com" and tries to log in as "joe@host.com", 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.

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.

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.)

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.

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.

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.

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:

(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.)

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.

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.

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.

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.

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.

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.

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.

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:

(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.

Sites which are willing to become part of the LISTSERV backbone should indicate it in the :backbone tag of the registration form returned to support@lsoft.com. 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.

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.

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.

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

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.

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.

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) "joe@isp.net", which is what Joe wanted, to "joe@alpha.isp.net", "joe@beta.isp.net", "joe@gamma.isp.net" 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 joe@alpha.isp.net with his actual subscribed address of joe@isp.net or any of the other cluster hosts in his domain.

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.

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).

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.

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.

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.

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.