Copyright: Copyright © 1995-2005 L-Soft international, Inc.
Citation: Copyright © 1995-2005 L-Soft international, Inc.


Contents

LISTSERV Version 14.4 Site Configuration Variables

Variable Syntax

ALL_REQUEST_ALLOWED_USERS

ANTI_VIRUS

AVS_DROP_SPAM

AVS_DROP_VIRUS

BITNET_ROUTE

BOUNCES_TO

CHANGELOG_DBMS

CHANGELOG_DBMS_CONNECTION

CHANGELOG_DBMS_TABLE

CMDPIPE_HOSTNAME

CRASH_MONITOR

CREATEPW

DBMS_DEFAULT_EMAIL

DBMS_DEFAULT_NAME

DBMS_DEFAULT_OPTIONS

DBMS_DEFAULT_TABLE

DBMS_DEFAULT_UEMAIL

DBMS_NO_HOSTNAME_ALIASING

DBRINDEX

DEFAULT_CHANGELOG_PERIOD

DEFAULT_LANGUAGE

DEFAULT_PROBE

DEFAULT_SPLIT

DIST_ALLOWED_USERS

DIST_FORWARD

DIST_FORWARD_THRESHOLD

DIST_OWNER_MAIL_MERGE

DIST_SECURITY

EMBEDDED_MAIL_MERGE

FILEMAXL

FILTER_ALLOW

FILTER_ALSO

FIOC_INUSE_RETRY

FIOC_TARGET

FIOC_TRIM

FIOC_WARNING

FOREIGN_ANTI_VIRUS

HIDE_TRACEBACK

IGNORE_EXTERNAL_PRIME

JOB_STAT_DEFAULT

LICENSE_WARNING

LIST_ADDRESS

LIST_EXITS

LOCAL

MAILMAXL

MAX_CONSECUTIVE_SUBS

MAXBSMTP

MAXDISTL

MAXDISTN

MYDOMAIN

MYORG

NODE

ODBC_AUTH

ODBC_DSN

ODBC_UID

PLAIN_FROMLINE

POSTMASTER

PRIMETIME

QUALIFY_DOMAIN

RUNMODE

SEARCH_DISABLED

Setting non-default directory paths with .SD

SMTP_FORWARD

SMTP_FORWARD_n

SMTP_LISTENER_IP

SMTP_LISTENER_PORT

SMTP_RESET_EVERY

SMTP_STRICTLY_ROUND_ROBIN

SORT_RECIPIENTS

SPAM_ALERT

Spam Blacklists and Whitelists

SPAM_DELAY

SPAM_EXIT

SYSTEM_CHANGELOG

TCPGUI_IPADDR

TCPGUI_PORT

TRAPIN

TRAPOUT

TUNE_MANY_LISTS

USE_LSMTP_MAIL_MERGE

WEB_BROWSER_CONFIRM

WWW_ARCHIVE_CGI

WWW_ARCHIVE_DIR

WWW_AUTHINFO_DISABLE

Version 14.4

Information in this document is subject to change without notice.  Companies, names and data used in examples herein are fictitious unless otherwise noted. L-Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of L-Soft international, Inc.

Copyright © 1995-2005, L-Soft international, Inc.

All Rights Reserved Worldwide.

L-SOFT®, LISTSERV® and LSMTP® are registered trademarks of L-Soft international, Inc.

Microsoft®, Windows®, and Windows NT® are registered trademarks of Microsoft Corporation.

All other trademarks, both marked and not marked, are the property of their respective owners.


ALL_REQUEST_ALLOWED_USERS

Abstract

Specifies non-POSTMASTER users who are allowed to post to the ALL-REQUEST alias.

Example

ALL_REQUEST_ALLOWED_USERS=joe@example.com pete@abc.unix.example.org

Details

In LISTSERV 1.8e and following, the ability to post to the ALL-REQUEST alias, which expands to all non-quiet list owners, has been restricted as follows:

1.	The site configuration variable, ALL_REQUEST_ALLOWED_USERS, can be used to specify who can mail to ALL-REQUEST. This variable uses the same syntax as POSTMASTER=, ie, a space-separated list of userid@host specifications.

2.	Postmasters are always allowed to mail to ALL-REQUEST, even when not listed in ALL_REQUEST_ALLOWED_USERS.

3.	The determination is made conclusively on the RFC821 MAIL FROM because:

a. This avoids dealing with header errors. Header error = don't know who sent this = discard silently = unhappy admin who had to send an urgent notice to all his owners.

b. The main point of this change is to block spammers, and spammers typically have non-working or null MAIL FROM: addresses. Needless to say, null doesn't pass the test.

4.	When the MAIL FROM is not null, the REQNAK1 mail template form is sent when the message is rejected.

Default Value

Null string.

Wildcards

Not allowed.


ANTI_VIRUS

Abstract

Turns LISTSERV's real-time anti-virus scanning on or off. Anti-virus scanning of all messages passing through LISTSERV mailing lists was introduced in version 1.8e. See the relevant section in the Site Manager's Manual for LISTSERV for further details.

Example

ANTI_VIRUS=0

Default Value

If the supported anti-virus system is detected, defaults to 1 (enabled), otherwise to 0 (disabled).

Wildcards

Not allowed.


AVS_DROP_SPAM
AVS_DROP_VIRUS

Platforms

All version 14.4 and later using the LISTSERV AVS to scan mail for spam or viruses

Abstract

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.

Example (using AVS_DROP_SPAM)

AVS_DROP_SPAM=1

Details

Two AVS-specific options, AVS_DROP_SPAM and AVS_DROP_VIRUS, are available to deal with mail flooding that may result from a mail-bombing attack on a LISTSERV site protected by an external LISTSERV Anti-Virus Station (AVS).

Both options, which default to 0, can be set to 1 to tell an AVS server to drop messages on the floor if they turn out to be spam or infected with a virus. The normal behavior is to return the message to the primary LISTSERV instance, which can then log it and decide what to do with it. In the case where the primary instance is configured to drop the message, it may be more efficient to drop it at the AVS.

Please note carefully that this works only with mail submitted to an AVS server.  It does not have any effect on mail scanned locally.

Default Value

0 (that is, disabled)


BITNET_ROUTE

Abstract

Defines the Internet hostname of a machine that will be used to route mail to BITNET addresses. If your organization is connected to BITNET, you may want to use the hostname of your main BITNET system for best turnaround time. Otherwise the default value is suitable.

Example

BITNET_ROUTE=INTERBIT.CREN.NET

Default Value

If not explicitly defined, this keyword defaults to BITMAIL.LSOFT.COM.

Wildcards

Not allowed.


BOUNCES_TO

Abstract

Tells LISTSERV where to send bounces that are not related to any specific list (i.e., bounces that should never have been sent to LISTSERV to begin with). This includes almost every situation in which LISTSERV thinks it has detected a bounce and cannot determine which list it is for, along with messages about served-out users. It does not include mail sent to the owner-listserv mailbox, which will still go to the LISTSERV maintainer(s).

Example

BOUNCES_TO=FOO@VM.EXAMPLE.EDU

Default Value

Defaults to the value of the POSTMASTER= variable.

Wildcards

Not allowed.


CHANGELOG_DBMS

Abstract

In LISTSERV 1.8e and later, tells LISTSERV to mirror a copy of all or selected changelogs to DBMS.

Examples

CHANGELOG_DBMS=ALL

CHANGELOG_DBMS=SYSTEM BIGLIST-L

Details

LISTSERV 1.8e allows a copy of change logs to be stored in a DBMS. This requires a pre-existing DBMS connection configured in the usual way (see the Developer's Guide for LISTSERV, chapter 4, if you need guidance), and is controlled by three new site configuration parameters, and a table that must be created manually. The parameters, which are defined in LISTSERV's site configuration file, are CHANGELOG_DBMS, CHANGELOG_DBMS_TABLE, and CHANGELOG_DBMS_CONNECTION .  The first two are mandatory while the third is optional.

Note:  It is not possible for LISTSERV to write the changelog in multiple different tables based on various combinations of parameters. This can be accomplished on the DBMS side with a stored procedure if required.

Important: The DBMS copy is just that, a copy. The disk files are still generated. Naturally if they are not needed they may periodically be erased with a script.

CHANGELOG_DBMS controls which entries are to be copied to the DBMS. Note that only entries that are actually generated can be copied. If a given change-log is disabled, it will not go to the DBMS even if you request it in this variable.

The value can be ALL or a space-separated combination of SYSTEM, NOLIST (matches any NOLIST-xxx), LISTS (matches any list) or the names of individual lists.

Default Value

Not set (null string).

Wildcards

Not allowed.

See also

CHANGELOG_DBMS_TABLE, CHANGELOG_DBMS_CONNECTION


CHANGELOG_DBMS_CONNECTION

Abstract

Used in conjunction with CHANGELOG_DBMS. Sets the DBMS connection characteristics for mirroring changelog data to DBMS. This parameter is optional if CHANGELOG_DBMS is used and does not normally need to be set.

Example

CHANGELOG_DBMS_CONNECTION=ODBC MYSERVER

Details

This contains two optional space separated words:

1.	The type of driver to be used (CLI, OCI, ODBC). This defaults to your system default driver type.

2.	The server to connect to (similar to SERVER=). This defaults to the empty string ie the default server.

Default Value

Not set (the defaults are as noted in the details).

See also

CHANGELOG_DBMS


CHANGELOG_DBMS_TABLE

Abstract

Used in conjunction with CHANGELOG_DBMS. Sets the DBMS table characteristics for mirroring changelog data to DBMS. This parameter is required to be set if CHANGELOG_DBMS is used.

Example

CHANGELOG_DBMS_TABLE=CHANGELOG TIMESTAMP LISTNAME RECORDTYPE PARAMETERS

Details

This contains five space-separated names:

1.	The name of the table in which to store changelog entries.

2.	The name of a time-stamp column in which to write the current date and time. This must be a DATE (Oracle), TIMESTAMP (DB2), DATETIME (SQL Server), or whatever else can store both date and time. This cannot be a character string.

3.	The name of a VARCHAR or equivalent column storing the name of the list. The maximum size depends on the list names you choose, but it should be at least 40.

4.	The name of a VARCHAR column storing the record type (BOUNCE, etc). This should probably be around 40.

5.	The name of a VARCHAR column storing the parameters. This ought to be 256 or so.

If any of these parameters is missing, the setting is ignored.

Default Value

Not set (null string).

See also

CHANGELOG_DBMS


CMDPIPE_HOSTNAME

Abstract

Defines the default hostname used by the LCMD interface

Example

CMDPIPE_HOSTNAME=EXAMPLE.COM

Details

This variable allows you to specify the hostname used when you communicate with LISTSERV via the LCMD interface. For instance your LISTSERV host may be named LISTSERV.MYCORP.COM, in which case LCMD will identify you to LISTSERV as userid@LISTSERV.MYCORP.COM. This is fine as long as you have added this address to the POSTMASTER= variable, but privileged commands will probably fail if you haven't (for instance you may be listed as userid@MYCORP.COM instead, which works fine via mail).

In order to simplify the issue and not have to code extra userids into the POSTMASTER= variable just to be able to use LCMD, you can simply set CMDPIPE_HOSTNAME=MYCORP.COM and LCMD will issue commands from userid@MYCORP.COM insead of the default.

This setting is particularly useful for large list providers such as L-Soft itself, where there are many different nodes all operated by the same small group of people, and it would otherwise be difficult to keep track of personnel changes across the "farm" of machines.

Default Value

Defaults to the DNS A name of the LISTSERV host.

Wildcards

Not allowed.


CRASH_MONITOR

Abstract

Defines the address to which LISTSERV will send crash reports upon restart.

Example

CRASH_MONITOR='CRASHLST@LISTSERV.EXAMPLE.COM'

Default Value

Defaults to all non-quiet POSTMASTERs.

Details

By default, LISTSERV crash reports are mailed to the LISTSERV maintainer(s). You can change the destination of these reports by adding a CRASH_MONITOR variable to your site configuration file (SITE.CFG for NT, SITE_CONFIG.DAT for VMS) with the e-mail addresses to which the report should be mailed. Note that CRASH_MONITOR replaces the entire recipient list, so make sure that all the necessary addresses are listed. This configuration variable follows the same syntax rules as POSTMASTER.

Please do not add L-Soft mailboxes to CRASH_MONITOR without checking with our support group first. While we will be happy to receive these reports, we want to make sure that they are sent to the addresses where we can process them most efficiently. In particular, these reports should never be mailed to a support engineer's personal mailbox. Instead, we use special addresses where these reports are logged for future reference.

Wildcards

Not allowed.


CREATEPW

Abstract

Defines the password used to validate the creation of new lists.

Example

CREATEPW=SECRET

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.


DBMS_DEFAULT_EMAIL

Abstract

Default value for the name of the column containing the subscriber's e-mail address. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_DEFAULT_EMAIL=EMAIL

Wildcards

Not allowed.


DBMS_DEFAULT_INTERFACE

Abstract

Default value for the type of DBMS interface LISTSERV will use by default for DBMS lists. The acceptable values are "ODBC" (the default, for Microsoft ODBC databases) or "OCI" (for Oracle). For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_DEFAULT_INTERFACE=ODBC

Example

DBMS_DEFAULT_INTERFACE=OCI

Wildcards

Not allowed.


DBMS_DEFAULT_NAME

Abstract

Default value for the name of the column containing the subscriber's name. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_DEFAULT_NAME=NAME

Wildcards

Not allowed.


DBMS_DEFAULT_OPTIONS

Abstract

Default value for the name of the column containing the subscriber's LISTSERV subscription options. An asterisk indicates that the column should be named after the list. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_DEFAULT_OPTIONS=*

Wildcards

Not allowed (the asterisk in this case is not technically a wildcard).


DBMS_DEFAULT_TABLE

Abstract

Default value for the name of the table in which DBMS lists are stored. Specify either a valid table name, or an asterisk to name the table after the list. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_DEFAULT_TABLE=LISTSERV

Wildcards

Not allowed.


DBMS_DEFAULT_UEMAIL

Abstract

Default value for the name of the optional column containing an upper-case copy of the subscriber's e-mail address. If set to the empty string, no such column is created or used. See below for more information on this performance option. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

Empty string.

Wildcards

Not allowed.


DBMS_NO_HOSTNAME_ALIASING

Abstract

When set to 1, disables hostname aliasing for increased performance with some DBMS products. L-Soft recommends using the default value of 0. For details please consult "DBMS and mail-merge support" in the LISTSERV Developers Guide. Not supported under LISTSERV Lite.

Default Value

DBMS_NO_HOSTNAME_ALIASING=0

Wildcards

Not allowed.


DBRINDEX

Abstract

Determines whether or not LISTSERV’s database functions use reverse indexing. Please see the 1.8c release notes for a full discussion of whether or not you should use reverse indexing. Windows 95 sites should probably turn this off (DBRINDEX=0). Not supported under LISTSERV Lite.

Example

DBRINDEX=0

Default Value

For VM and VMS: DBRINDEX=0

For unix and Windows: DBRINDEX=1

Wildcards

Not allowed.


DEFAULT_CHANGELOG_PERIOD

Abstract

Sets the default change-log rotation period in LISTSERV 1.8e and later.

Example

DEFAULT_CHANGELOG_PERIOD=MONTHLY

Details

In LISTSERV 1.8e and following it is possible to automatically rotate list and system change-log files on a periodic basis. This site configuration variable allows site administrators to set a server-default rotation period, which can be one of the following: SINGLE (the 1.8d behavior), YEARLY, MONTHLY, DAILY, or WEEKLY.

Default Value

For backward compatibility, the default is SINGLE.


DEFAULT_LANGUAGE

Abstract

This variable sets the default national language template to use for all lists on the server.

Examples

DEFAULT_LANGUAGE='ESPANOL'

Details

Particularly useful for servers running in non-English-speaking countries and/or with few lists in English. In 1.8d and following, this variable allows you to define a default national language mail template file for all lists (thereby eliminating the need to code "Language=" in all lists in order to make them use the national language template). Setting this variable to any value other than "ENGLISH" assumes that you have provided a national language mail template file (see the entry for "Language=" in Appendix B for details). If this variable is left unset or is set to "ENGLISH", LISTSERV uses the DEFAULT MAILTPL file (in other words there is no ENGLISH MAILTPL).

Default Value

Not set (the default settings for the Language= list header keyword are in force).


DEFAULT_PROBE

Abstract

This variable sets defaults for passive probing.

Examples

DEFAULT_PROBE=10 500

DEFAULT_PROBE=21

Details

In 1.8d and following, a feature called "passive probing" is enabled by default for lists under a certain size. This variable controls two aspects of passive probing. The first parameter to this variable is the length of the default passive probing cycle in days.

Because passive probing is very resource-intensive, above a certain list size it is disabled by default. The second (and optional) parameter to this variable is the list size beyond which passive probing is disabled unless you explicitly enable it in the Auto-Delete= list header keyword.

Since probes do not work with sendmail, the default under unix is to disable passive probing altogether.

Default Value

All platforms except unix: 	DEFAULT_PROBE=30 1000

Unix only:	DEFAULT_PROBE=0


DEFAULT_SPLIT

Abstract

Provides a default value for the "SPLIT=" modifier of the GET command, causing files ordered with the GET command to be automatically split into smaller "chunks". This option can be useful if LISTSERV is behind a firewall or other central mail gateway with an unusually low maximum message size limit. Unit: kilobytes.

Example

DEFAULT_SPLIT=250

Default Value

Not set - messages are not split unless specifically requested by the user.

Wildcards

Not allowed.


DIST_ALLOWED_USERS

Abstract

In 1.8d and following, space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE. SEE DETAILS.

Example

DIST_ALLOWED_USERS=joe@unix.host.com alma@univ.edu

Details

In 1.8d, to secure the DISTRIBUTE command from use by spammers, a security validation feature was added. Only a user defined in POSTMASTER= or in DIST_ALLOWED_USERS= may issue the DISTRIBUTE command, and the DISTRIBUTE command must be validated with that user's personal LISTSERV password.

Default Value

Not set (null value).

Wildcards

Not allowed.

See also

DIST_SECURITY


DIST_FORWARD
DIST_FORWARD_THRESHOLD

Abstract

In 14.4 and following, enables and tunes DISTRIBUTE "workers".  This is a tuning feature for embedded mail merge, also introduced in 14.4.

Example

DIST_FORWARD=smtp.example.com 2*smtp2.example.com

DIST_FORWARD_THRESHOLD=200

Details

Configuring many SMTP workers through the SMTP_FORWARD_n site configuration parameter will help speed up the delivery of the many individual mail files generated with the embedded mail-merge feature. However, in very high volume situations, it may also be desirable to off-load the work of generating the many individual mail files to one or more separate servers.

This can be done in LISTSERV 14.4 by configuring additional LISTSERV instances to be “DISTRIBUTE workers”. The primary LISTSERV instance can quickly divide and delegate the mail-merge responsibility among its workers and get on with its own work while the “workers” take care of the brute-force generation of the individual mail messages, which are then delivered by the workers’ SMTP workers. By using several DISTRIBUTE workers, not only does the primary instance’s availability increase, but the deliveries can be forwarded to the SMTP server(s) much faster because multiple messages are being generated in parallel, instead of one at time.

In most cases, each instance will run on a separate, dedicated server, but this is not a requirement. On a very large server with many CPUs and as many independent disk drives, it could make sense to run multiple instances on the same server.

Each instance requires a separate license. Since this feature is intended for processing large volumes, the primary instance must be running with an HPO license. The “worker” instances must have either HPO licenses (in which case they can also act as standalone LISTSERV hosts), or special SCOPE=DISTWORKER licenses (in which case they are dedicated DISTRIBUTE workers).

DISTRIBUTE workers are enabled with two options set in the primary instance’s site configuration:

1. DIST_FORWARD_THRESHOLD=nnn

This setting is optional, and defaults to 100. It defines the minimum number of total recipients to make use of the workers. It would be inefficient to forward a message with one recipient to a worker so that it could deliver it for you.

2. DIST_FORWARD=[[n*]hostname [[n*]hostname [...]]

This is a space-separated list of all your DISTRIBUTE workers.

For "hostname", you can specify just the hostname if the userid is LISTSERV. If the userid is not LISTSERV, then you must specify a full RFC822 e-mail address pointing to the USERID= address for that server.

Optionally, you can specify a weight (the "n" parameter), which defaults to 1. The number of recipients sent to a particular server is proportional to its weight. The weight must be greater than zero. If a particular server is specified multiple times, the weights are added.

By default, the primary server also takes one share of recipients. In other words, it has a weight of 1. You can change that using the special hostname “SELF”. So, if you want a double share for your primary LISTSERV because it runs on a bigger server, just add 2*SELF to the list. SELF is the only worker allowed to have a weight of zero. In this case, nothing is processed locally (except for jobs that are below the threshold). For very large mail-merge volumes, 0*SELF is recommended.

A worker cannot delegate jobs to sub-workers, but the primary instance can drive any number of workers.

See also

EMBEDDED_MAIL_MERGE


DIST_OWNER_MAIL_MERGE

Abstract

In 1.8d and following, Boolean value which determines whether or not list owners may perform mail merge operations using their lists. BE SURE TO READ DETAILS BELOW!

Example

DIST_OWNER_MAIL_MERGE=1

Details

DO NOT ENABLE THIS FEATURE UNLESS YOU ARE USING LSMTP AS YOUR OUTBOUND MTA!!!!

By default, list owners who are not LISTSERV postmasters may not use the mail-merge features against their own lists (ie, via the "Mail-Merge" button in the web administration interface). Setting this variable to 1 enables this feature for all list owners on the server.

LISTSERV postmasters may always use mail-merge features regardless of the setting of this variable, as it is assumed that they know whether or not LSMTP Classic 1.1b or higher is installed, whereas individual list owners may not have this information.

Note that the SMTP_FORWARD* variables MUST IMPERATIVELY be pointed to a host which is running L-Soft's LSMTP Classic version 1.1b or higher, since LISTSERV's mail-merge features require LSMTP Classic version 1.1b or higher.

NOTE CAREFULLY that this feature should NEVER be enabled unless you are using LSMTP Classic 1.1b or later as your outbound mail server! Mail-merge operations will fail on all other MTAs as mail-merge operations use L-Soft proprietary extensions to the BSMTP protocol that are implemented only by LSMTP.

Default Value

DIST_OWNER_MAIL_MERGE=0

See also

SMTP_FORWARD, SMTP_FORWARD_n


DIST_SECURITY

Abstract

In 1.8d and following, Boolean value which turns off new security validation feature for the DISTRIBUTE command. SEE DETAILS.

Example

DIST_SECURITY=0

Details

In 1.8d, to secure the DISTRIBUTE command from use by spammers, a security validation feature was added. Only a user defined in POSTMASTER= or in DIST_ALLOWED_USERS= may issue the DISTRIBUTE command, and the DISTRIBUTE command must be validated with that user's personal LISTSERV password. This feature is turned on by default.

If it is deemed necessary to revert to the pre-1.8d behavior, simply set this variable to zero and restart the server. However this is NOT RECOMMENDED as the original behavior would continue to allow the indiscriminate use of DISTRIBUTE by spammers. L-Soft will not be responsible for any consequences deriving from the disabling of this feature.

Default Value

DIST_SECURITY=1

See also

DIST_ALLOWED_USERS


EMBEDDED_MAIL_MERGE

Abstract

Starting with LISTSERV 14.4, any high-capacity SMTP server can be used to deliver e-mail that uses mail-merge. When operating in this mode, the proprietary mail-merge BSMTP features of LSMTP are not required for mail-merge.

Embedded mail-merge is activated in LISTSERV by adding the EMBEDDED_MAIL_MERGE= site configuration variable to the site configuration file and restarting LISTSERV.

Example

EMBEDDED_MAIL_MERGE=1

Details

Embedded mail-merge is a "brute-force" method. In this mode, each individual merged message is written to LISTSERV's spool as a single-recipient MAIL file. In turn, each individual MAIL file is then delivered by SMTP to the outbound SMTP_FORWARD host.

Since Batch SMTP (BSMTP) cannot be used in the embedded mode, sites with very high volumes of mail may wish to split the load across multiple outbound mail servers using SMTP "workers" (defined with SMTP_FORWARD_n= variable settings in the site configuration file). In addition, the new DISTRIBUTE "workers" (detailed in the next section) can be used in very high volume situations to move mail smoothly.

Default Value

EMBEDDED_MAIL_MERGE=0


FILEMAXL

Abstract

The maximum number of lines for any incoming non-mail file to be accepted. A non-mail file is defined as a piece of mail that contains LISTSERV commands (eg, a bulk ADD or DELETE job) as opposed to a piece of mail that contains a message (eg, a list posting).

Example

FILEMAXL=25000

Default Value

FILEMAXL=100000

Wildcards

Not allowed.


FILTER_ALLOW

Abstract

Blank-delimited list of addresses or wildcards which will be exempted from LISTSERV's standard loop-detection filter.

Example

FILTER_ALLOW=*@GOODNODE.COM POSTMASTER@SOMEHOST.NET

Details

This variable determines what, if any, exemptions are made to the standard set of addresses normally bounced by LISTSERV as part of its loop-checking heuristic. For instances, if you want to allow POSTMASTER@SOMEHOST.NET to post to lists like a normal user, you can add that value to this variable.  Or if you should decide that any postmaster account anywhere should be allowed to post to lists, you can add the value POSTMASTER@* (but please note that L-Soft does not recommend this). FILTER_ALLOW works in conjunction with enhancements to the "Filter=" list header keyword; for more information on this interaction please see Appendix B.

Default Value

Not set; adds to LISTSERV's built-in filter.

Wildcards

Allowed.


FILTER_ALSO

Abstract

Blank-delimited list of problem users who should not be allowed to post or subscribe to any list. This is similar to the "Filter=" list header keyword, but applies to all the lists. The FILTER_ALSO option is usually used to filter out problematic mail gateways, anonymous remailers (if anonymous postings are not desired), troublesome users, etc. Please refer to the list owner’s manual for more information.

Example

FILTER_ALSO=*@BADNODE.COM OBNOXUSR@SOMEHOST.NET

Details

Sometimes it may be necessary to deny a specific user (or a class of users) access to all the lists hosted by your server. This may be due to policies internal to your organization, technical problems, or simply to lock out an obnoxious user. FILTER_ALSO adds to the standard LISTSERV filter and denies access to all lists on the server.

Default Value

Not set; adds to LISTSERV's built-in filter.

Wildcards

Allowed.


FIOC_INUSE_RETRY

Abstract

Defines the number of seconds LISTSERV will try to open a file which is locked by an external process.

Example

FIOC_INUSE_RETRY=15

Details

Sometimes LISTSERV may try to open a file (such as a list file) while that file is locked by an external process (for instance, a nightly backup program). If the open attempt times out, an error is generated. This functionality is not available on unix because file locking is not implemented.

Default Value

FIOC_INUSE_RETRY=10


FIOC_TARGET

Abstract

Defines the "target size" for LISTSERV's file cache (in kilobytes). (Windows sites can set this option through the various "Optimize for..." buttons in the LISTSERV configuration program.) See the LISTSERV Tuning Guide (available from L-Soft at no extra charge) for more information.

Example

FIOC_TARGET=15000

Details

One of three variables that control how LISTSERV handles its built-in data cache. FIOC_TARGET is the "target size" for the cache. LISTSERV will strive to keep the cache to about that size, but will allow it to grow past this value for short periods of time. LISTSERV expects that it will have fast access (low paging rate) to these FIOC_TARGET kilobytes of cache memory; it does not help to increase this value if your system is memory-constrained.

Default Value

System dependent.

Wildcards

Not allowed.


FIOC_TRIM

Abstract

Defines the threshold (in kilobytes) where LISTSERV should start aggressively trimming the cache. (Windows sites can set this option through the various "Optimize for..." buttons in the LISTSERV configuration program.) See the LISTSERV Tuning Guide (available from L-Soft at no extra charge) for more information.

Example

FIOC_TRIM=17000

Details

One of three variables that control how LISTSERV handles its cache. FIOC_TRIM is the point at which LISTSERV should start aggressively trimming the cache in order to free up virtual storage. Typically this value should be set to FIOC_TARGET plus 20% or 512KB (whichever is larger).

Default Value

System dependent.

Wildcards

Not allowed.


FIOC_WARNING

Abstract

Defines the cache size (in kilobytes) at which LISTSERV should write a warning to the console log. (Windows sites can set this option through the various "Optimize for..." buttons in the LISTSERV configuration program.) See the LISTSERV Tuning Guide (available from L-Soft at no extra charge) for more information.

Example

FIOC_WARNING=20000

Details

One of three variables that control how LISTSERV handles its cache. Under certain circumstances, LISTSERV may not be able to trim the cache right away, either because a cache entry is locked by a routine that maintains pointers to it or because the file is currently open and thus it would be counter-productive to flush the cache entry right away.  In such cases, the cache size can continue to grow past FIOC_TRIM.  When it reaches FIOC_WARNING, a warning is displayed on the LISTSERV log. This probably indicates a programming error, or a value of FIOC_TARGET which is significantly below the "correct" value for your workload. Typically this value should be set to FIOC_TARGET plus 75% or 1MB (whichever is larger).

Default Value

System dependent.

Wildcards

Not allowed.


FOREIGN_ANTI_VIRUS

Abstract

In 14.4 and following, 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.

Example

FOREIGN_ANTI_VIRUS=1

Details

Version 14.4 adds anti-virus protection for those sites that for policy or other reasons must run anti-virus systems other than F-Secure on their servers. This feature is not available on anti-virus stations (AVS). Support for these “foreign” anti-virus systems is not fully integrated with LISTSERV in the same way that FSAV is, but LISTSERV will give the AV system the opportunity to disinfect messages.

To have LISTSERV messages disinfected by an AV system other than FSAV, add the FOREIGN_ANTI_VIRUS parameter to your site configuration as shown in the example.

The anti-virus system must be installed on the LISTSERV server, and must block creation of a .EXE file containing a virus with an error of “access is denied“.

Use of this feature is at your own risk. Because the foreign AV system is not fully integrated with LISTSERV as is FSAV, LISTSERV cannot check that the AV system is up and running and has up-to-date virus definitions. It can only assume that any file that is not denied access does not contain a virus. If you use this feature, it is recommended that you test it thoroughly and set up an external monitoring system to make sure that the anti-virus system is always active when LISTSERV is.

Since the foreign AV system is not integrated with LISTSERV, LISTSERV does not know which viruses have been detected. Anti-virus reports will identify every virus detected as "unknown virus”.

This feature is part of the LISTSERV message scanner, and therefore requires a valid and current maintenance LAK. See http://www.lsoft.com/products/listserv_av.asp for more information.

Default Value

0 (that is, disabled)


HIDE_TRACEBACK

Abstract

Boolean value determining whether or not error tracebacks are shown to non-postmasters. (Added in 14.3)

Example

HIDE_TRACEBACK=1

Details

It is now possible to suppress tracebacks in error messages by setting the Boolean site configuration variable HIDE_TRACEBACK. When set, the tracebacks are no longer included in error messages, except in certain postmaster-only e-mail messages.

This has no impact on what is written to the LISTSERV log. The traceback is always written to the LISTSERV log.

Default Value

0, that is, do not suppress the tracebacks.


IGNORE_EXTERNAL_PRIME

Abstract

A Boolean value which determines whether or not LISTSERV will ignore the PRIME setting on incoming DISTRIBUTE jobs.

Example

IGNORE_EXTERNAL_PRIME=1

Details

This parameter can be used to expedite the delivery of DISTRIBUTE jobs which have an explicit PRIME setting. The point of this is simply to keep the spool clear of DISTRIBUTE jobs that might have a very narrow window (e.g., jobs set for weekend delivery only). Most sites will not need to use this setting, and it is disabled by default.

Default Value

IGNORE_EXTERNAL_PRIME=0


JOB_STAT_DEFAULT

Abstract

Boolean value determining whether or not the "Summary of resource utilization" is generated or suppressed in a CJLI JOB command response.

Example

JOB_STAT_DEFAULT=0

Details

Sets a server-wide default which can be overridden on a single-job basis with the STAT= JOB card option (see the Developer's Guide for LISTSERV for more information on JOB cards). L-Soft does not recommend changing this value from the default but recognizes that some sites do not want this information to be sent out.

Default Value

JOB_STAT_DEFAULT=1

Wildcards

Not allowed.


LICENSE_WARNING

Abstract

LISTSERV issues a warning to the console and to all non-quiet POSTMASTERs when you reach a usage level corresponding to about 80% of your license points. This warning is automatically disabled for small licenses (9 points or less). The warning can be turned off for higher license point values by using this Boolean variable. WARNING: SEE DETAILS BELOW.

Example

LICENSE_WARNING=0

Details

Note that this keyword turns off all license warnings, including expiration warnings. L-Soft does not recommend turning this feature off as it is possible for your license to expire or to be at capacity without any warning. L-Soft is not responsible for delays or other problems arising from the deactivation of license warnings.

Default Value

LICENSE_WARNING=1

Wildcards

Not allowed.


LIST_ADDRESS

Abstract

Default value for the "List-Address=" list header keyword. This keyword does not normally need to be changed on non-VM systems.

Example

LIST_ADDRESS=LIST-ID@NJE

Details

LIST_ADDRESS defines how mailing lists will identify themselves by default. The main purpose of this keyword is to allow BITNET sites to select their NJE address as the primary address, for compatibility. There is no practical application for this keyword under non-VM systems, other than as a migration aid for mainframe BITNET sites moving off of VM.

Default Value

LIST_ADDRESS=LIST-ID@FQDN

Wildcards

Not allowed.


LIST_EXITS

Abstract

A list of filenames of files that can be activated as list exits through the "Exit=" list header keyword. Any suffixes (CMD for Windows NT and BAT for Windows 95, for example) should not be included. List exits are not available under LISTSERV Lite.

Example

LIST_EXITS=EXIT1 EXIT2

Details

An "exit" is a program supplied by the customer to modify the behavior of a product (such as LISTSERV) in ways that the supplier of the product could not anticipate, or could not afford to support via standard commands or options. The product checks for the presence of the "exit" program and calls it on a number of occasions, called "exit points". In some cases, the "exit" program supplies an answer ("return code") to the main program, which adjusts its behavior accordingly. For instance, LISTSERV may ask an exit program "Is it OK to add JOE@XYZ.EDU to the ABC-L list?", and the program will answer yes or no, and possibly send a message to the user explaining why his subscription was accepted or rejected. In other cases, the "exit point" call is purely informative: the exit program gets a chance to do something, such as sending an informational message to a user, but does not return any answer. Because this "exit" is a computer program, it must be prepared by a technical person and installed by the

LISTSERV maintainer.

List "exits" are available to control the major events associated with list maintenance. This makes it easier to tailor the behavior of LISTSERV to local requirements that are too specific to be addressed through standard facilities.

An exit is enabled by adding "Exit= filename" to the list header. For security reasons, all exits must be explicitly declared in the LIST_EXITS configuration variable (in the LISTSERV configuration). This prevents list owners from causing the invocation of arbitrary executable files through the use of the "Exit=" keyword.

See the Developer's Guide to LISTSERV for more information on list exits.

Default Value

Empty string (no exits enabled).

Wildcards

Not allowed.


LOCAL

Abstract

A list of hosts and nodes to be associated with the hard-coded LCL FAC.  Also used as the default for the "Local=" list header keyword. You usually want to set this variable to a wildcard pattern matching all the hosts in your organization (or department for large organizations).

Example

LOCAL=*.XYZ.EDU

Default Value

None. This parameter must be set explicitly.

Wildcards

Allowed.


MAILMAXL

Abstract

The maximum acceptable size, in lines, of an incoming mail message.

Example

MAILMAXL=15000

Details

Messages larger than MAILMAXL lines are not accepted for processing. This option is all but obsolete (it was intended to solve a problem specific to VM BITNET servers) and you should not set it (i.e., you should accept the default) unless you are experiencing this kind of problem.

MAILMAXL is primarily intended for small machines where there are not enough resources to process very large messages. Rather than attempting to process them and then running out of resources anyway, you can use the MAILMAXL option to reject the message right away.

Default Value

MAILMAXL defaults to the value of FILEMAXL. Note that under VM this can be more complicated as there typically is an entry for MAILMAXL in one of the SYSVARS files which overrides the default in the MODULE.

Wildcards

Not allowed.


MAXBSMTP

Abstract

The maximum number of recipients in each message forwarded to the mail delivery system (see SMTP_FORWARD). This is an optimization parameter that you would normally set through the various "Optimize for..." buttons in the configuration program. If your mail delivery system is a unix machine, you should use values in the 50-100 range; smaller values will result in faster delivery, but will use up more system resources. If your mail delivery system runs L-Soft’s LSMTP™ product, you should use a much larger value, such as 1000. With LSMTP™, larger values improve turnaround time and decrease system resource usage. Very large values, however, may exhaust available system storage.

Example

MAXBSMTP=50

Default Value

MAXBSMTP=100

Wildcards

Not allowed.


MAX_CONSECUTIVE_SUBS

Abstract

The maximum number of lists to which consecutive subscription attempts will be accepted from a given subscriber, to prevent "spoofing" attacks.  (Added in 14.3)

Example

MAXBSMTP=50

Details

In previous releases, as a preventative against spoofers adding third parties to hundreds of lists without their knowledge, LISTSERV has had a hard-coded maximum for the number of local lists to which a user could subscribe at any one given time. The limit was set at 50, after which LISTSERV would assume that the subscription requests were coming from a spoofer and would cancel the last 50 subscription requests for the user in question. (To clarify, a user could be subscribed to more than 50 lists on the server, but could not issue more than 50 subscription requests in a row.)

MAX_CONSECUTIVE_SUBS allows site maintainers full control over the limit.  The default remains 50.  A setting of 0 disables the anti-spoofing filter (which is not recommended).

Default Value

50


MAXDISTN

Abstract

The maximum number of recipients in forwarded DISTRIBUTE jobs. You should not modify this value unless instructed to do so by L-Soft.

Example

MAXDISTN=100

Default Value

MAXDISTN=1000

Wildcards

Not allowed.


MAXDISTL

Abstract

The maximum number of recipients to be listed in the LISTSERV console log as recipients of an SMTP job. When the number of recipients is greater than MAXDISTL, a shorter message is printed in the log.

Example

MAXDISTL=100

Default Value

MAXDISTL=1000

Wildcards

Not allowed.


MYDOMAIN

Abstract

The list of all the possible Internet host names and aliases for the machine on which LISTSERV is running. Usually this is the same as NODE, however you can supply additional names if your machine operates several services under different host names. For instance, if your machine operates WWW and FTP servers in addition to LISTSERV, under the hostnames WWW.XYZ.COM and FTP.XYZ.COM, you may want to list these names in MYDOMAIN. Similarly, if you operate the LISTSERV service under a hostname such as LISTSERV.XYZ.COM, while the machine’s real name is NT2.IGATE.XYZ.COM, you will want to list the real name in MYDOMAIN because some unix machines will automatically substitute it for the published name.

Example

MYDOMAIN=LISTSERV.XYZ.COM WWW.XYZ.COM NT2.IGATE.XYZ.COM

or

MYDOMAIN=%NODE% WWW.XYZ.COM NT2.IGATE.XYZ.COM

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.


MYORG

Abstract

Short organization name that appears in the mail header of messages from LISTSERV itself (i.e. not in the header of messages from a mailing list).

Example

MYORG=XYZ, Inc.

Default Value

Not set. Generates the standard "L-Soft list server at host" organization name. Please note that the "L-Soft list server at" part of the string is not configurable, for trademark and copyright reasons.

Wildcards

Not allowed.


NODE

Abstract

Defines the Internet hostname of this LISTSERV host.

Example

NODE=LISTSERV.MYHOST.NET

Details

This must be a fully-qualified address, as noted in the example. It must not be an IP address or a non-qualified address such as ‘LISTSERV’.

For testing/evaluation purposes only you can define the NODE= as a square-bracketed, dotted-IP, e.g., NODE=[aaa.bbb.ccc.ddd], but this is not officially supported and L-Soft will not accept registrations for servers using this nomenclature.

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.


ODBC_AUTH

Abstract

The ODBC "authorization string" (sometimes called the "password" in vendor documentation) for accessing the ODBC database specified by the ODBC_DSN site configuration variable.  Set only in conjunction with ODBC_DSN.

Example

ODBC_AUTH=myodbcpassword

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.

See also

ODBC_DSN


ODBC_DSN

Abstract

The name of the ODBC DSN used to identify the ODBC database used for LISTSERV's DBMS features.

Example

ODBC_DSN=GREEN

Details

When using DBMS lists under Windows NT with ODBC, a System DSN must be created in the ODBC32 interface to identify the ODBC database that will be used by LISTSERV for this purpose. The value of this parameter is identical to the name of the System Data Source that points to that database.

This variable should be set only if DBMS lists are to be used and a System DSN has been set up for that purpose.  Otherwise the variable should not be set (and LISTSERV will not try to initialize any ODBC databases).

Note that the variables ODBC_AUTH and ODBC_UID will also have to be set accordingly if you are connecting to an ODBC data source.

See the Developer's Guide to LISTSERV for specifics on setting up DBMS lists.

Default Value

None; DBMS lists are not used by default.

Wildcards

Not allowed.

See also

ODBC_AUTH and ODBC_UID


ODBC_UID

Abstract

The ODBC userid for accessing the ODBC database specified by the ODBC_DSN site configuration variable. Set only in conjunction with ODBC_DSN.

Example

ODBC_UID=MYODBCID

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.

See also

ODBC_DSN


ODBC_server
ODBC_server-alias

This help section refers to the "Server" entry in the "Define Multiple DBMS Connections" window of SITE.EXE .

When defining multiple simultaneous ODBC connections in LISTSERV 1.8e, you must specify a server name (or data source) for each connection.  This server or data source name is used in the ODBC_DSN_server-alias=, ODBC_UID_server-alias=, and ODBC_AUTH_server-alias= variables, which are used to identify the specific ODBC  connection.  For instance, if you have an ODBC data source for bulk mail merge that you would like to refer to as BULKMAIL, which has the DSN "customers", and which requires a login from 'sa' with the password "luxfiat", you would have to add

ODBC_DSN_BULKMAIL=customers

ODBC_UID_BULKMAIL=sa

ODBC_AUTH_BULKMAIL=luxfiat

to your site configuration.

The server or data source name entered here (in our example above, "BULKMAIL") is whatever name you wish to assign to that particular DSN, but please note that when defining an alternate server, it is recommended that server_alias be defined as an alpha string as opposed to a numeric string, in order to avoid certain problems in some ODBC drivers. There is no character limit for the server_alias string, but for simplicity's sake it should not be overly long.


PLAIN_FROMLINE

Abstract

Boolean value controlling the "verboseness" of LISTSERV's administrative From: line. (Added in 14.3)

Example

PLAIN_FROMLINE=1

Details

PLAIN_FROMLINE controls whether or not LISTSERV generates a “plain” From: line when sending administrative mail, eg, setting this variable to "1" would result in

From: LISTSERV@LISTSERV.EXAMPLE.COM

rather than

From: "Example Company LISTSERV Server (14.3)" <LISTSERV@LISTSERV.EXAMPLE.COM>

Enabling PLAIN_FROMLINE overrides any setting made to MYORG=, MYNAME=, and/or MYNAME_HIDE_RELEASE=, since the organization name setting and release number will no longer be displayed.

Default Value

0 (that is, the original behavior)


POSTMASTER

Abstract

The space-delimited list of Internet addresses of the "LISTSERV maintainers", i.e. the people in charge of operating the LISTSERV service who are to be granted maintainer privileges and notified of problems with the operation of the server.

Example

POSTMASTER=NATHAN@LSOFT.COM Hide: LARRY@LSOFT.COM Quiet: ERIC@LSOFT.COM

Details

Please note that userids such as ‘postmaster@somehost.com’ or ‘listserv-maintainer@somehost.com’ cannot be defined as LISTSERV maintainers because they will be trapped by LISTSERV’s built-in loop-checking heuristics. If it is desired to have an "generic" address listed as the POSTMASTER address (for instance, in the output of the RELEASE or HELP commands), L-Soft suggests using a userid such as ‘lstmaint’.

The SHOW VERSION,  RELEASE and HELP commands report the names and addresses of all the LISTSERV maintainers, allowing users to determine where to report problems. However, you can insert a "Hide:" keyword in the list, causing all the addresses that follow to be hidden from SHOW VERSION, RELEASE or HELP. Similarly, a "Quiet:" keyword indicates that all the addresses that follow should be granted privileges, but should not be notified of problems with the service.

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.


PRIMETIME

Abstract

Defines the "prime time" for your node, during which mail to lists configured as "Prime= No" should not be processed. This option is mostly for small machines that are very busy during business hours. Refer to the list owner’s guide for more information. Note that the value for PRIMETIME must always be enclosed in quotes, including on Windows machines where quotes are not normally required.

Do not confuse "prime time" for time that LISTSERV is allowed to process mail.  "Prime time" is the time during which LISTSERV is not allowed to process mail, e.g., it is the "prime time" of day on your machine during which other operations must take precedence.

Example

PRIMETIME="MON-FRI: 0800-1700; SAT-SUN: -"

Default Value

PRIMETIME="MON-SUN: -"

Wildcards

Not allowed.


QUALIFY_DOMAIN

Abstract

Defines the Internet domain to be appended to all non-qualified Internet addresses in incoming mail. This is mostly useful when dealing with unix systems, which often do use unqualified addresses (in violation of the Internet mail standards). In a typical non-unix-based network, this option does not need to be set.

Example

QUALIFY_DOMAIN=.DC.LSOFT.COM

Default Value

Determined from the Internet hostname; for instance, if your hostname is LISTSERV.XYZ.COM, the value of QUALIFY_DOMAIN will be .XYZ.COM.

Wildcards

Not allowed.


RUNMODE

Abstract

Determines the server’s mode of operation with respect to peer LISTSERV servers running on other Internet hosts.

Details

LISTSERV can operate in one of three modes:

Networked: in this mode, your server will connect to the worldwide LISTSERV backbone operated over the Internet, exchanging information with these other servers on a regular basis. This allows you, for instance, to keep a local database of all the available LISTSERV lists, to act as a redistribution point for all LISTSERV mail directed to users on your campus, to advertise your lists in the worldwide list of lists, etc. Networked mode requires a number of special tables, which must be updated on a regular basis, and 24h uptime. Thus, this mode is not suitable for servers with dial-up connectivity.

Tableless: in this mode, your server accesses the worldwide LISTSERV backbone through another LISTSERV site (which must be running in Networked mode with full backbone status). Your server still has access to the data available to backbone servers, but doesn’t need to maintain any LISTSERV table (hence the name). This is the preferred mode for dial-up servers and for small servers where the overhead of maintaining the server should be kept to a minimum.

Standalone: this mode is for servers that are not connected to the Internet, or that operate in a "closed" environment where outside communication is not desired. The server will not communicate with any of the other LISTSERV servers on the Internet. As such, it will not have access to the list of lists or to other Internet LISTSERV resources.

The traditional academic servers operate in Networked mode. This is the default mode for the non-shareware versions.

Example

RUNMODE=TABLELESS SWGATE.LSOFT.COM

Default Value

Tableless for the Windows 95 version and all Lite versions, networked for all others. The value cannot be changed under the Lite "Free Edition".

Wildcards

Not allowed.


SEARCH_DISABLED

Abstract

A string variable which, if set to anything but the null string, disables the (new) SEARCH command and returns the text in the string to anyone attempting an archive search. Similar in function to the (Boolean) DATABASE variable for VM, but allows you to customize the string returned to the invoker.

Example

SEARCH_DISABLED='The SEARCH command is disabled on this server.'

Details

This variable is provided primarily for servers such as the IBM P/390 which may not have sufficient resources to offer database searching functionality. This variable should not be used unless there is a good reason to disable the SEARCH command altogether.

Default Value

Not set (null string).


Setting non-default directory paths with .SD

Abstract

It is possible (but not recommended) to set non-default directory paths for LISTSERV files by using the .SD parameter.

Example

.SD L E:\FTP\LOGS

Details

L-Soft recommends that the default directory configuration not be changed without good reason. Such reasons might include putting LISTSERV logs on a shared network drive for testing or debugging purposes.

Default Value

Not set.

Wildcards

Not allowed. Note that this parameter must point to a valid, existing directory name.  For security reasons, LISTSERV will not create directories that do not already exist.


SMTP_FORWARD

Abstract

The Internet hostname (not the IP address; this variable must contain a fully-qualified domain name [FQDN]) of the server to which all outgoing SMTP mail should be forwarded for delivery. This can be any machine with SMTP software that will accept mail from your machine. If you are running the MS Mail SMTP gateway product as your SMTP forwarding host, you should point SMTP_FORWARD to the "smart host" defined in the MS Mail configuration, rather than to the MS Mail gateway itself.

Example

SMTP_FORWARD=UNIX.XYZ.COM

Default Value

None. This parameter must be set explicitly.

Wildcards

Not allowed.

See also

SMTP_FORWARD_n


SMTP_FORWARD_n

Abstract

Allows LISTSERV to deliver mail asynchronously via one or more SMTP "worker" processes.

Formal Syntax

There are several different ways to define the value for this variable. Here is the formal syntax (for unix the value must be enclosed in double-quotes, of course):

SMTP_FORWARD_n=[x*]hostname[(prime-setting)][;failoverhostname]

(Advanced tuning parameters typically used only by "huge" sites (millions of recipients/day) have been omitted.)

Examples

SMTP_FORWARD_1=UNIXSERVER.BAR.COM

SMTP_FORWARD_2=SMTP.BAZ.NET

SMTP_FORWARD_3=UNIXSERVER.BAR.COM

SMTP_FORWARD_1=2*UNIXSERVER.BAR.COM

SMTP_FORWARD_2=SMTP.BAZ.NET

SMTP_FORWARD_1=2*UNIXSERVER.BAR.COM;SMTP.BAZ.NET

SMTP_FORWARD_2=SMTP.BAZ.NET

SMTP_FORWARD_1=UNIXSERVER.BAR.COM(00:00-05:00);SMTP.BAZ.NET

SMTP_FORWARD_2=SMTP.BAZ.NET

SMTP_FORWARD_3=SMTP.BAZ.NET(10:00-14:00)

Details

Defines a number of "SMTP workers" (SMTPW.EXE on VMS and Windows; lsv child processes on supported unix platforms) used to spread the mail delivery load across multiple machines (or multiple connections to the same machine). For most normal workloads, the recommendation is to define a single SMTP_FORWARD_n host (ie, SMTP_FORWARD_1=) which points to the same host as is set for the SMTP_FORWARD= synchronous delivery variable.

Multiple SMTP_FORWARD_n host definitions should be made only for large workloads (30,000 daily deliveries or more), or when the mail delivery server being pointed to is very slow. In that case, opening multiple connections to the machine may improve throughput. A general rule is that you define multiple SMTP_FORWARD_n hosts only when xxx.MAIL files are consistently accumulating in the LISTSERV spool directory. Please be sure to read the comments below.

The value of each SMTP_FORWARD_n host must be a fully-qualified domain name (FQDN), not an IP address.

You MUST define an SMTP_FORWARD= parameter in the site configuration file which will tell LISTSERV where to deliver mail synchronously should asynchronous delivery fail for any reason.

The first example is one of the most simple configurations: one SMTP_FORWARD_n variable is defined for each separate worker. In this case two workers are pointed at one host, meaning that that host will be used for two-thirds of the outgoing mail.

The second example is functionally identical to the first example but the syntax is different. SMTP_FORWARD_1=2*UNIXSERVER.BAR.COM says "define two workers pointed at UNIXSERVER.BAR.COM".

The third example is also functionally identical to the first example except that it tells worker #1 to use SMTP.BAZ.NET as a "failover" host if UNIXSERVER.BAR.COM cannot be contacted.  Otherwise SMTP.BAZ.NET will handle only one-third of the outgoing mail as would be expected.

The fourth example tells worker #1 to use UNIXSERVER.BAR.COM only between midnight and 5AM, and use the failover host SMTP.BAZ.NET at all other times. It also tells worker #3 to operate only between the hours of 10AM and 2PM (with no failover). This is handy for (for instance) offloading large queues to other machines during heavy traffic periods when the other machines aren't being used for other things (like number-crunching).

Default Value

Not set (workers are not used and mail is delivered synchronously).

Comments

The more SMTP_FORWARD_n hosts you define, the more SMTP workers will be started. Since each SMTP worker takes up some resources on your machine, you should not define more workers than your workload requires.

Wildcards

Not allowed.


SMTP_LISTENER_IP

Platforms

Windows

Abstract

Dotted-decimal IP address which sets the IP address to which the SMTPL.EXE "listener" will bind at boot time.

Details

Under normal circumstances it is not advisable to set this parameter. It is only for use when it becomes necessary to force SMTPL.EXE to "listen" out on a specific IP address (for instance, on a multi-homed machine you might have another mail server running on one IP address and LISTSERV/SMTPL running on another).  This parameter would normally be set only if another SMTP mail application were running on the same machine as LISTSERV and it were necessary to divide the mail up based on the IP address. However, please note that this assumes that the other SMTP mailer is also able to listen out on a designated IP address, and that separate DNS entries have been established for each of the IP addresses assigned to the machine.

Example

SMTP_LISTENER_IP=1.2.3.4

Default Value

Defaults to all valid IP addresses configured for the machine.

Wildcards

Not allowed.


SMTP_LISTENER_PORT

Abstract

 Integer value. Sets the port number to which the SMTPL.EXE "listener" will bind at boot time.

Details

Under normal circumstances it is not advisable to set this parameter. It is only for use when it becomes necessary to force SMTPL.EXE to "listen" out on a non-standard port (i.e., other than the standard SMTP port, port 25).  This parameter would normally be set only if another SMTP mail application were running on the same machine as LISTSERV and it were necessary to avoid an SMTP port conflict. However, please note that this implies that the other SMTP mailer is able to forward LISTSERV's mail to the non-standard port you define.

Example

SMTP_LISTENER_PORT=10025

Default Value

Normally not set in SITE.CFG but the default would be

SMTP_LISTENER_PORT=25

Wildcards

Not allowed.


SMTP_RESET_EVERY

Abstract

Directs LISTSERV to reset the SMTP connections to the SMTP delivery machines (see SMTP_FORWARD) at regular intervals (units: minutes). This parameter improves turnaround time on busy servers if the mail delivery server is a unix machine. It should not be used with other types of delivery servers. Under Windows this parameter is normally set through one of the "Optimize for..." buttons in the configuration program.

Example

SMTP_RESET_EVERY=60

Default Value

Not set; connections are not reset unless inactive.

Wildcards

Not allowed.


SMTP_STRICTLY_ROUND_ROBIN

Abstract

A Boolean value that directs LISTSERV's SMTP "workers", if plural, to handle outbound MAIL files using strict "round-robin" delivery to the outbound MTA.

Example

SMTP_STRICTLY_ROUND_ROBIN=1

Details

An option for strict "round-robin" delivery to the outbound MTA via LISTSERV's SMTP "worker" processes has been added to the Windows version of LISTSERV.

Activation of this feature tells the SMTP workers, if plural, to only process messages whose spool ID is congruent to their worker ID modulo the total number of workers. In other words, they only process their fair share of messages. Messages without a numeric spool ID, such as those created manually or by debug scripts, are "free for all" and will be processed by the first worker that sees them. The SMTP worker log files (x:\LISTSERV\LOG\SMTPS#n-yyyymmdd.LOG) will have a message at the top confirming that the feature has been activated.

DRAWBACK: if a worker should die, some messages will be left unprocessed. In practice, we have never ever seen a worker die unless there is some kind of global system problem, like a disk crash or out of swap space condition (not counting workers that abort due to a configuration error). But, in theory, it could happen. Another potential drawback is more cycles spent scheduling workers since a short burst of messages will require the participation of each and every worker. L-Soft does not believe that it will be a very significant difference except in low-volume, many-worker scenarios (in a high-volume scenario, workers are not very often in wait state and it does not matter from a resource utilization standpoint which messages they pick and on which criteria).

IMPORTANT: this feature is incompatible with worker pools. Any workers placed in a pool will ignore SMTP_STRICTLY_ROUND_ROBIN=1 and process all messages for the pools they are currently enabled for. Workers not in a pool, if any, will honor the option and this is likely to lead to unprocessed messages. This feature cannot be implemented for pools without major work because the workers do not communicate with each other. This means they cannot maintain a catalogue of all pools currently active and how many workers are currently working on what pools.

It should be made clear that any imbalances in load sharing are outside LISTSERV. By default (that is, without SMTP_STRICTLY_ROUND_ROBIN=1), the various workers are synchronized using a single, shared event flag. LISTSERV sets the event flag when there is a new message to process. Because there is only one event flag, LISTSERV could not possibly be favoring a particular worker, or ignoring a particular one. All the workers wait on this event flag when they run out of work to do, and Windows decides which of the workers to wake up if several are waiting (only one is awakened). Windows does not know that they are numbered #1, #2, etc. They are just different processes as far as Windows is concerned. All tests done so far have shown that Windows seems to use a round-robin algorithm. Simulations have all shown approximately the same number of wakeups for every process.

However, our simulations were based on pseudo-workers that did a variety of things at the same speed. If for any reason a worker is slower (typically because it is talking to a slower MTA), it will tend to be busy when the other workers are waiting for new work. That is, there will tend to be a more-than-fair occurrence of the state where all workers are waiting except for the slow worker, which is still busy finishing its last message. At that point it is guaranteed that the next message will be processed by one of the fast, waiting workers. This dynamic load balancing is by design. MTA speed can vary significantly in the space of a few minutes and the workers adjust their respective shares accordingly and without human intervention. The result is more messages to workers (and thus to MTAs) that have more capacity right now, though this can change in only a few minutes.

Thus a slower target server will normally lead to a less-than-fair  share of messages. The purpose of SMTP_STRICTLY_ROUND_ROBIN=1 is to  enforce a fair share for all workers by earmarking messages for a  particular worker.

Default Value

Not set; effectively, SMTP_STRICTLY_ROUND_ROBIN=0 .

Wildcards

Not allowed.


SORT_RECIPIENTS

Abstract

An integer value (0, 1, or 2) that determines whether or not LISTSERV sorts the recipient list in outgoing SMTP jobs. Under Windows this option is normally set through the "Optimize for..." buttons in the configuration program. It should be set to 1 for best performance if your mail delivery host is a unix machine. Other systems do not normally need a pre-sorted recipient list for optimal performance.

Example

SORT_RECIPIENTS=1

Details

This variable setting has changed for 1.8d. Under 1.8c and earlier the variable was a Boolean value that simply determined whether or not the recipient list was sorted by hostname before being handed off to the outgoing MTA.

Under 1.8d and following, if this variable is set to the value 2, LISTSERV will not sort the recipient list if the number of recipients is less than or equal to your MAXBSMTP setting. Conversely, for jobs where the number of recipients is greater than MAXBSMTP, LISTSERV will sort the recipient list (keeping XYZ.COM together and thereby conserving resources). This enhancement is useful when you are using LSMTP as your outgoing MTA, since LSMTP doesn't care whether or not the recipient list is sorted.

Default Value

All platforms except Windows NT:	SORT_RECIPIENTS= 0

Windows NT:	SORT_RECIPIENTS= 2

Wildcards

Not allowed.


SPAM_ALERT

Abstract

Boolean value determining whether or not spam reports are sent to the postmaster. (Added in 14.3)

Example

SPAM_ALERT=1

Details

SPAM_ALERT defaults to 0, meaning that spam alerts will not be sent to the LISTSERV postmaster (but will still be sent back to the message poster for his/her information).

The previous default behavior, in which the LISTSERV postmaster was cc'd on all spam alerts, can be reverted to by setting SPAM_ALERT=1.

Default Value

0, that is, enabled (postmaster will not receive cc's of spam reports).


SPAM_BLACK_WHITE
Spam Blacklists and Whitelists

Starting with version 14.3, LISTSERV includes a whitelist/blacklist system that can be used either on its own, or in conjunction with the spam exit feature (also new in 14.3; please see the Developers Guide to LISTSERV for more information on the spam exit feature). This built-in whitelist/blacklist system is very efficient, which makes it advantageous to duplicate your spam filter’s whitelist/blacklist rules so that the spam filter is bypassed for messages whose disposition can be determined simply on the basis of the origin or target address.

There are four separate lists (or in reality, site configuration variables that contain the lists), called:

SPAM_BLACKLIST_FROM

SPAM_BLACKLIST_TO

SPAM_WHITELIST_FROM

SPAM_WHITELIST_TO

The lists are defined in the site configuration file in the usual space-separated manner. A restart of LISTSERV is required after updating any of the lists, also as usual.

The FROM lists are applied to all the origin fields in the RFC822 header – From:, Sender:, Resent-From: and Resent-Sender: (note that the SMTP-level MAIL FROM: is not used).

The TO lists are applied to the various recipient fields in the RFC822 header. Please note that LISTSERV does not work at the SMTP transaction level and does not have access to the RCPT TO: field.

The listing system is based on a score that LISTSERV maintains as it goes through the four lists in sequence. If the final score is zero, the message is neither white- nor blacklisted, and processing continues normally (to the external spam filter, if one has been configured). If the final score is positive, the message is whitelisted and accepted, bypassing any additional tests, including the external spam filter. If negative, the message is immediately rejected. A negative final score is a conclusive determination that makes any further tests unnecessary.

Being whitelisted normally gives one point, and being blacklisted costs one point. This can be changed by using the following syntax:

SPAM_WHITELIST_FROM=*@EXAMPLE.COM *@*.EXAMPLE.COM

SPAM_BLACKLIST_FROM=*@PUBLIC.EXAMPLE.COM >JAMES@EXAMPLE.COM

The first entry whitelists all EXAMPLE.COM addresses. The second entry acts as a cancellation of this whitelist for the fictitious machine PUBLIC.EXAMPLE.COM, which is not part of the Intranet. It also blacklists JAMES@EXAMPLE.COM, a notorious source of spam, with a score of 2 (every '>' sign gives another score point). JAMES@EXAMPLE.COM receives 1 point from the whitelist and -2 from the blacklist, so he will be effectively blacklisted. It is possible to load an entry with up to 254 extra score points, although it is not expected that anyone would need to go that far.

Every list gives score points at most once. So if we also had JAMES@EXAMPLE.COM and JAMES@* in the whitelist, he would still get only one point from the whitelist. But, when applicable, you do get the highest possible number of points that you have matched. If we had JAMES@EXAMPLE.COM and >>JAMES@* in the whitelist, he would get 3 points.

Again, all the whitelists and blacklists scores are added. If you use both FROM and TO, you need to use a point system that gives the desired results. It is much easier if you only use FROM or only TO.

What you would put in TO is defunct addresses (former employees, “honeypots”, etc.) that are guaranteed to have come out of spam listings. The message is then bounced for all recipients, not just the defunct address.

In most cases you will not want bounces to be blacklisted, since they are useful to LISTSERV and are processed automatically. So in addition to the new white/blacklists themselves, a new site configuration variable, SPAM_WHITELIST_BOUNCE, has been added. This value is an integer, defaulting to 1, and is the number to be added to the message's whitelist score if it is a bounce. Set to 0 to disable. You can also use a higher value.

Note that bounces may not be run through the spam filter at all. If LISTSERV can immediately determine what the bounce is for and process it, it will not scan it for spam.

SYNTAX:  The syntax for all of the white- and blacklists is identical, so we will use just one of them for the example.

White/Blacklisting example:

SPAM_BLACKLIST_FROM=*@PUBLIC.EXAMPLE.COM >JAMES@EXAMPLE.COM

SPAM_WHITELIST_BOUNCE example:

SPAM_WHITELIST_BOUNCE=1


SPAM_DELAY

Abstract

Sets the server-wide delay period for the spam quarantine feature.

Example

SPAM_DELAY=15

Details

This variable sets the server-wide delay period (in minutes) during which LISTSERV holds certain "suspicious" messages before processing them. This gives LISTSERV’s anti-spamming algorithms time in which to gather the necessary evidence to determine whether or not the message may be a spam. The value can be overridden on a list-by-list basis with the list header keyword setting "Loopcheck= Spam-Delay(xxx)" (the value is in minutes). SPAM_DELAY=0 disables this "spam quarantine" feature for all lists on the server.

Default Value

SPAM_DELAY=10

Wildcards

Not allowed.


SPAM_EXIT

Abstract

Sets the name of the user-provided exit program used to call a third-party spam scanner. (Added in 14.3)

Example

SPAM_EXIT=SAEXIT

Details

Please see the full documentation (or the LISTSERV 14.3 release notes) for information on this feature.  See also the documentation on spam blacklists and whitelists.

Default Value

Not set, ie, disabled.


SYSTEM_CHANGELOG

Abstract

System changelogs are not available in LISTSERV Lite. Enable/disable a system-wide changelog that logs information about DISTRIBUTE/mail-merge jobs and postings to lists.

Example (for 1.8d)

SYSTEM_CHANGELOG=1

Example (for 1.8e non-VM, see changes noted in Details)

1.8d syntax continues to work, enhanced by (for example):

SYSTEM_CHANGELOG=WEEKLY

Details

LISTSERV builds dated 16 July 2000 (the 2000b level set release) or later running with Classic or Classic HPO LAKs include this feature. If enabled, a file called system.changelog is created and written to in LISTSERV's A directory containing data for each DISTRIBUTE, mail-merge, and list posting sent through the server. The syntax of the data line is documented in chapter 10 of the site manager's manual.

Difference between 1.8d and 1.8e versions: In 1.8d, the SYSTEM_CHANGELOG value was a binary "on/off" setting. In non-VM 1.8e, the system change-log can now be rotated on a DAILY, WEEKLY, MONTHLY, YEARLY, or SINGLE basis, or explicitly turned off (the default) by setting the value to 0 as before. For backward compatibility the value 1 is the same as the value SINGLE.

Rotated system change-logs are renamed with the format SYSTEM.CHANGELOG-yyyy[mm[dd|w]] (depending on the rotation period selected)

Default Value

SYSTEM_CHANGELOG=0 (ie, disabled)


TCPGUI_IPADDR

Abstract

Sets the default IP address for use with LISTSERV's TCPGUI interface.

Example

TCPGUI_IPADDR=101.231.8.1

Details

If TCPGUI_IPADDR is not specified on a multi-homed machine, LISTSERV listens to port 2306 (by default) on every IP configured for use by the machine. This is primarily important on multi-homed machines where you want to use port 2306 on another IP for something else. It can be set on single-homed machines but is not necessary since this value will default to the machine's single IP address.

Default Value

Defaults to the primary IP address of the LISTSERV machine.

Wildcards

Not allowed.

See also

TCPGUI_PORT


TCPGUI_PORT

Abstract

Sets the port number for use with LISTSERV's TCPGUI interface.

Example

TCPGUI_PORT=23006

Details

TCPGUI_PORT= can be used to resolve potential port conflicts with other software on the LISTSERV machine by allowing you to change the port number used by the TCPGUI interface. It can also be useful on single-homed machines on which you wish to disable the LISTSERV TCPGUI interface altogether (for instance, to address local security issues). In order to disable the TCPGUI interface, simply set TCPGUI_PORT=0 and restart the server.

Default Value

TCPGUI_PORT=2306

Wildcards

Not allowed.

See also

TCPGUI_IPADDR


TRAPIN

Abstract

A space-separated list of Internet addresses from which LISTSERV should never accept mail.

Example

TRAPIN= OBNOX@SOMENODE.NET *@BADNODE.COM

Details

A space-separated list of Internet addresses from which LISTSERV should never accept mail. Mail and files from users matching these templates will not be processed, but rather simply transferred to the LISTSERV maintainer. This parameter is provided primarily for VM sites, but is available for the convenience of VM customers migrating to other platforms and should not need to be set by typical non-VM installations.

Note:  L-Soft does not recommend using this keyword to filter out problem users, as it does not prevent people at the hosts in question from posting to mailing lists. It controls only how incoming administrative mail (e.g., containing LISTSERV commands) sent to the LISTSERV address is treated. You should use the FILTER_ALSO keyword to filter problem users.

Default Value

Built in.

Wildcards

Allowed.

See also

TRAPOUT


TRAPOUT

Abstract

A space-separated list of Internet addresses to which LISTSERV should never send mail.

Example

TRAPOUT= OBNOX@SOMENODE.NET *@BADNODE.COM

Details

A space-separated list of Internet addresses to which LISTSERV should never send mail. Mail and files to users matching these templates will be sent to the postmaster instead. This parameter is provided primarily for VM sites, but is available for the convenience of VM customers migrating to other platforms and should not need to be set by typical non-VM installations.

Note:  L-Soft does not recommend using this keyword to filter out problem users, as it does not prevent people at the hosts in question from posting to mailing lists. It controls only how outgoing administrative mail (e.g., containing responses to LISTSERV commands) sent to the LISTSERV address is treated. You should use the FILTER_ALSO keyword to filter problem users. If you wish to stop outgoing list mail to specific domains, you should simply do a global delete (QUIET DELETE * *@*badnode.com) and then add the domain to FILTER_ALSO to prevent future subscriptions from that domain.

Default Value

Built in.

Wildcards

Allowed.

See also

TRAPIN


TUNE_MANY_LISTS

Abstract

(HPO only) In  LISTSERV 14.3 and following, enables a suite of HPO functions that can markedly speed up operations on servers with many lists (>100).

Example

TUNE_MANY_LISTS=1

Details

Setting this Boolean value to 1 makes LISTSERV HPO work faster at the expense of memory. For sites of 100 lists or less, enabling TUNE_MANY_LISTS does nothing. Sites between 100 and 1000 lists may note some improvement if enabled. Sites of 1000 lists or more will want to turn this feature on.

Default Value

0 (that is, disabled)


USE_LSMTP_MAIL_MERGE

Abstract

Boolean value which determines whether or not LISTSERV will use LSMTP's mail-merge functions for enhanced performance (requires LSMTP version 1.1b or higher).

Example

USE_LSMTP_MAIL_MERGE=1

Details

If all your SMTP servers (as defined in the SMTP_FORWARD* variables) are, at all times and  including backup and last resort, guaranteed to be LSMTP servers running version 1.1b or higher, you can set USE_LSMTP_MAIL_MERGE=1 to enable a number of delivery optimizations which REQUIRE the LSMTP 1.1b (or higher) mail merge functionality. NOTE CAREFULLY that L-Soft makes absolutely no guarantees as to the efficacy of enabling this feature unless ALL of your SMTP_FORWARD* variables point to LSMTP 1.1b (or higher) servers. L-Soft STRONGLY DISCOURAGES changing this variable from the default unless it can be guaranteed that all of your SMTP_FORWARD* hosts are LSMTP 1.1b (or higher) servers. Since LISTSERV's mail-merge functionality works only in conjunction with LSMTP 1.1b or higher, you run considerable risk of non-delivery of mail if this feature is enabled and any of your SMTP_FORWARD* servers are not running LSMTP 1.1b or higher.

Default Value

USE_LSMTP_MAIL_MERGE=0

See also

SMTP_FORWARD, SMTP_FORWARD_n


WEB_BROWSER_CONFIRM

Abstract

LISTSERV can be configured to require confirmation (through the "OK" mechanism) when commands are sent through a WWW browser, even if they apply to a list whose security level or "Subscription=" keyword does not require confirmation. This variable controls whether or not that functionality is enabled.

Details

This change was made the default for the 1.8c release both to avoid abuse and because many occasional WWW users do not know their e-mail address or enter it incorrectly, whereas people who use e-mail regularly do of course have a working e-mail address in their configuration. To disable this feature, set WEB_BROWSER_CONFIRM=0 in the site configuration file.

In 1.8d and following, this feature is disabled by default.

Example

WEB_BROWSER_CONFIRM=1

Default Value

WEB_BROWSER_CONFIRM=0

Wildcards

Not allowed.


WWW_ARCHIVE_CGI

Abstract

The relative URL that leads to the WWW archive CGI script. (This is a URL, not an OS path name.)

Example

WWW_ARCHIVE_CGI=/SCRIPTS/WA.EXE

Default Value

Null.

Wildcards

Not allowed.

See also

WWW_ARCHIVE_DIR


WWW_ARCHIVE_DIR

Abstract

The full OS path name to the WWW archive directory

Examples

WWW_ARCHIVE_DIR=c:\inetpub\wwwroot\archives

Default Value

Null.

Wildcards

Not allowed.

See also

WWW_ARCHIVE_CGI


WWW_AUTHINFO_DISABLE

Abstract

A Boolean value which can be set to 1 to disable the IP address verification function of the web archive interface ('wa'), or 0 to re-enable the function.

Details

This setting allows you to bypass certain proxy problems that prevent the 'wa' interface from working properly. There is a certain minimum security exposure involved in that someone with a good memory can watch you using 'wa', memorize the URL, and then type it into another browser and use your login ticket. The ticket will still expire but until then the "thief" has full reign on your list. It is therefore not recommended that this value be changed from the default unless you have a problem using the 'wa' interface through your proxy server.

Example

WWW_AUTHINFO_DISABLE=0

Default Value

WWW_AUTHINFO_DISABLE=1

Wildcards

Not allowed.


Server Registration Form
Server Registration

NOTE: This section does not apply to evaluation kits or to LISTSERV Lite kits. Evaluation copies of LISTSERV should not be registered because they are (presumably) temporary servers running test lists, whose existence should not be broadcast. LISTSERV Lite copies run only in TABLELESS mode and therefore cannot be registered in the same manner as LISTSERV Classic, nor may they participate in the LISTSERV backbone.  Further, Windows 9x/ME Classic servers may not participate in the backbone as typically they do not have the capacity or stability to qualify for backbone status. For information about how LISTSERV Lite servers are registered, please see 5.6.3 of the LISTSERV Site Manager's Manual.

Also note that only those LISTSERV Classic servers running in NETWORKED mode may be registered.

Once the server is ready for production use (that is, once you have installed a permanent License Activation Key, and once you have arranged for LISTSERV to be started automatically when the system boots), you should register it with L-Soft by filling in a server registration form, and returning it to SUPPORT@LSOFT.COM. Registering the server is necessary to broadcast its existence to the other LISTSERV servers. Once you have registered, your server will be sent periodic updates about the lists hosted by other LISTSERV sites and updates to the files whose versions are shown in the output of the RELEASE command, among other things, and, similarly, other LISTSERV sites will receive information about the public lists you are hosting.

The LISTSERV site registration request form is found at the URL

http://www.lsoft.com/regform.html

along with the requirements that must be met for registration.


Configuration Syntax Guide
Variable Syntax

Windows users should use the SITE.EXE application, provided with the software, to modify the site configuration file, rather than editing it by hand. However, it is possible to edit the file by hand if necessary.

KEYWORD=somevalue

For substitutions, follow this example:

MYDOMAIN=%NODE% some.host.com