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.
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.
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.
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
purposes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
The mode (NETWORKED, STANDALONE, or TABLELESS) that LISTSERV runs in.
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
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.
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*.
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
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.
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.
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.
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.)
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.
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.
Windows: lcmd [\\computer[\serverid]] command
|
•
|
-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 -s -r does not output the list header
|
|
•
|
listview -eh -r outputs a list of random hostnames; they are not unique.
|
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.
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.
|
•
|
.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.
|
|
•
|
.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).
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:
|
•
|
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.
|
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:
|
•
|
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.
|
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.
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".
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.
See Section 6 Introduction to the Web Interface for more details on the Web Administration Interface.
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.
|
•
|
Windows: It is strongly recommended that the web interface be installed when LISTSERV is installed (the installation program prompts you to do so).
|
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.
|
•
|
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.
|
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 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.
|
|
•
|
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:
|
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:
|
•
|
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).
|
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:
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.
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.
You should never make changes to default.wwwtpl itself as it is always overwritten when LISTSERV is upgraded.
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.
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.
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'
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
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.)
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.
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 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:
|
•
|
VMS: DEFAULT_DIST_BACKGROUND "500 250"
|
|
•
|
unix: RSS_ABSTRACT_WORDS="500 250"
|
|
•
|
Win: RSS_ABSTRACT_WORDS=500 250
|
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".
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.
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.
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:
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.
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.
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.
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:
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.
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.
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
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.
|
•
|
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.
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.
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.
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
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.
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) "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.
This can also handle a situation where an ISP changed name and for instance "joe@oldname.net" is rewritten to "joe@newname.net". However this does not handle "joe@isp.net" -> "J.Doe@isp.net" and the like.
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.
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.
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).
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.
-----BEGIN RSA PRIVATE KEY-----
MIIBywIBAAJhAM5MtvnHlLhPzQjitdBctkJTRbJ/YkbGzcxHP701mHrlMdVeTI3M
(...)
QJEE65afJ4PS8yqM10hZ0p2euKrVZGgUDDdLzgPo2w==
-----END RSA PRIVATE KEY-----
brisbane._domainkey.example.com IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
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.
|
•
|
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.
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
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.
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.
