Site Configuration Keyword Reference

for LISTSERV® version 17.0

 

Last updated 26 Jul 2019

To access this file for older versions of LISTSERV, please see the Documentation for Older Versions page on L-Soft's website.

 

Site configuration files

Defining site configuration keyword values

After making changes, restart the server

Alphabetical keyword reference

 

Site configuration files

 

These files have different names depending on the platform. They are located in the same directory with the executable binaries.

 

Platform

Site Configuration File

z/VM

LOCAL SYSVARS

Unix (all supported variants)

go.user

Windows

SITE.CFG

 

For a list of L-Soft-supported operating systems for use with LISTSERV, please visit:

 

http://lsoft.com/products/listserv_os.asp .

 

The above listed files are the only configuration files that should be changed manually on any LISTSERV installation, unless otherwise directed by L-Soft Support. Software upgrades may overwrite any other configuration files located in LISTSERV’s home directory (except as noted below). 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 is also never overwritten in an upgrade.

 

WARNING:  DO NOT edit SITECFG.FILE by hand unless specifically directed to do so by L-Soft support.  This file is not intended to be human-editable.

 

At startup, LISTSERV will first read the original site configuration file, and then will read the SITECFG.FILE for any changes to the original configuration.  Settings in SITECFG.FILE will override settings in SITE.CFG.

 

* Defined as $LSVROOT/home under unix, installation_drive:\LISTSERV\MAIN under Windows.

 

Defining site configuration keyword values

 

The syntax used to define these values differs from platform to platform. For each site configuration keyword we have provided examples for all systems affected by the keyword. A general syntax guide follows:

 

z/VM

 

The configuration file is located on LISTSERV's 191 minidisk and is called LOCAL SYSVARS.

 

KEYWORD = 'somevalue'

 

Note that for z/VM the space on either side of the "=" sign is required. For substitutions, follow the REXX language syntax. For instance,

 

MAILER = 'mailer@'NODE

MYDOMAIN = NODE 'some.host.com'

 

Unix (all)

 

Unix users may prefer to use the Site Configuration Wizard in the web interface to modify the site configuration, rather than editing go.user by hand. However, as in earlier versions, it remains possible to edit the file by hand if necessary, using a plain-text editor such as vi, emacs, nano, or similar.

 

Keywords requiring text values:

 

KEYWORD="somevalue"

 

Keywords requiring numeric values (ie, Boolean settings):

 

KEYWORD=number

 

eg, NODE="listserv.mynode.com", but DBRINDEX=0 .

 

For substitutions, follow this example:

 

MYDOMAIN="$NODE some.host.com"

 

Note that under unix, all site configuration variables must be exported if defined in go.user. The commonly-used variables are exported for you in the go script. Anything else must be exported at the end of go.user.

 

Windows (all)

 

The old, separately-maintained SITE.EXE application used to edit the configuration file (site.cfg) is obsolete and its use deprecated.  If you still have this application and the associated SITE.HLP and SITEDATA.FILE in the \LISTSERV\MAIN directory, they can be safely deleted.

 

Please note that current LISTSERV installation kits will delete these three files if found, since they should NOT be used with modern versions of LISTSERV.

 

Windows users may prefer to use the Site Configuration Wizard in the web interface to modify the site configuration, rather than editing site.cfg by hand. However, as in earlier versions, it remains possible to edit the file by hand if necessary.  Be sure to use a PLAIN TEXT editor and save as ASCII text.  The file MUST NOT be saved in Unicode format.

 

KEYWORD=somevalue

 

Note that both text and numerics, unless specifically noted in the keyword documentation, do not require (and should not use) double quotes.  There are a few exceptions to this general rule, and they are documented where appropriate.

 

For substitutions, follow this example:

 

MYDOMAIN=%NODE% some.host.com

 

Note for Unix and Windows

 

As explained above, changes made to the site configuration via the web administration interface are stored in a "site override" file called sitecfg.file, which is located in LSVROOT/home under unix and in \LISTSERV\MAIN under Windows.  This file is maintained automatically by LISTSERV and SHOULD NOT be edited by the site administrator unless specifically directed by L-Soft Support, for instance, in order to clear a setting that for some reason cannot be cleared from the web interface.

 

When providing your site configuration to L-Soft Support, please be sure to supply BOTH your regular site configuration file (go.user or site.cfg, as the case may be) AND the site override file (sitecfg.file), as both will be necessary to help diagnose whatever problem you are reporting.

 

Restart the Server (in some cases)

 

When the site configuration file is modified by hand, a manual restart of LISTSERV is always required.

 

Any configuration change made via the web interface that requires a manual server restart will cause a message to that effect to be displayed, and a restart button will be provided for that purpose.

 

Windows sites using the SMTPL.EXE "listener" should also ALWAYS stop and restart the LISTSERV-SMTP service, as some changes will affect it as well.  The SMTPL.EXE "listener" cannot be stopped and restarted from the web interface; this must be done via the Windows Services applet or at a Windows Command Prompt using the "NET STOP" and "NET START" commands.

 


Alphabetical Keyword Reference

 

Please see the full documentation of each keyword for platform availability.

 

Keywords not hyperlinked are obscure, undocumented z/VM-only settings.  If you are a z/VM site and need help with these settings, please contact L-Soft customer support.

 

If the "Introduced" column is blank, the keyword existed prior to LISTSERV 1.8d (13).

 

Keyword

Introduced

Abstract

ALL_REQUEST_ALLOWED_USERS

14.0

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

ANTI_VIRUS

14.0

Turns LISTSERV's real-time anti-virus scanning on or off.

AVS_DROP_SPAM

14.4

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.

AVS_DROP_VIRUS

14.4

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.

BITNET_ROUTE

 

Defines the hostname of a machine that knows how to route mail to BITNET addresses

BOUNCES_TO

1.8d (13)

Tells LISTSERV where to send bounces not related to any particular list

CHANGELOG_DBMS

14.0

Tells LISTSERV to mirror a copy of all or selected changelogs to DBMS.

CHANGELOG_DBMS_CONNECTION

14.0

Used in conjunction with CHANGELOG_DBMS. Sets the DBMS connection characteristics for mirroring changelog data to DBMS.

CHANGELOG_DBMS_TABLE

14.0

Used in conjunction with CHANGELOG_DBMS. Sets the DBMS table characteristics for mirroring changelog data to DBMS.

CHECKMDISK

 

List of library minidisks to be checked at startup

CLI_*

14.0

Three configuration variables under the CLI_* rubric are available for use with DBMS/Mail Merge.

CMDPIPE_HOSTNAME

1.8c (12)

Defines the hostname used by the LCMD utility

CMSNAME

 

The name of the CMS system to be used on IPL commands

CRASH_MONITOR

1.8c (12)

Where to send Windows crash reports

CREATEPW

 

The password required to create new lists

DATABASE

 

Indicates whether the (old) z/VM database functions are enabled or not

DBMS_*

1.8d (13)

Several configuration variables under the DBMS_* rubric are available for use with the DBMS/Mail Merge.

DBRINDEX

1.8c (12)

Determines whether or not the new LISTSERV database functions use reverse indexing

DEBUG_LOG_PW

14.3

Debug setting to display passwords in LISTSERV's log file

DEBUG_LOG_TCPGUI

14.3

Show fully-logged TCPGUI commands for debugging purposes.

DEFAULT_CHANGELOG_PERIOD

14.0

Sets a default period for rotating change-logs.

DEFAULT_DIST_BACKGROUND

15.0

Boolean value that sets the server default for background DISTRIBUTE

DEFAULT_LANGUAGE

1.8d (13)

Sets the default national language template for use by all lists on the server

DEFAULT_LOOPCHECK

14.5

Sets the server default for the list-level Loopcheck keyword

DEFAULT_MAIL_MERGE

16.0

Sets the default for the Mail-Merge= keyword for all lists on the server.

DEFAULT_MISC_OPTIONS

14.5

Sets the server default for the list-level Misc-Options keyword

DEFAULT_PROBE

1.8d (13)

Sets defaults for passive probing

DEFAULT_SPLIT

1.8b (11)

Provides a default value for the "SPLIT=" command line keyword

DELAY

 

The delay between  two reader-scan operations

DIAGD4

 

Indicates whether LISTSERV should use diagnose X'D4' to mimic the RSCS origin on files it DISTRIBUTEs

DIST_ALLOWED_USERS

1.8d (13)

Space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE

DIST_BACKGROUND_CHUNKSIZE

15.0

Tuning parameter for background DISTRIBUTE.

DIST_BACKGROUND_JOBSIZE

15.0

Tuning parameter for background DISTRIBUTE.

DIST_FORWARD

14.4

Enables and tunes DISTRIBUTE "workers".  This is a tuning feature for embedded mail merge.

DIST_FORWARD_MINSIZE

15.0

The minimum message size, in kilobytes, to make use of DISTRIBUTE workers

DIST_FORWARD_THRESHOLD

14.4

Enables and tunes DISTRIBUTE "workers".  This is a tuning feature for embedded mail merge.

DIST_OWNER_MAIL_MERGE

1.8d-2000b (13.2)

Determines whether or not list owners may use the mail-merge feature for their lists.

DIST_SECURITY

1.8d (13)

Boolean value which controls security validation feature for the DISTRIBUTE command. WARNING: See the full documentation before changing this value.

DKIM_SIGN

14.5

Specifies DomainKeys domains for which you are able and willing to sign

DKIM_SIGN_ALL

14.5

Boolean value which directs LISTSERV to sign all messages for which it has a suitable DomainKeys private key.

DMARC_NO_REWRITE

16.5-2018a

List of domains and subdomains which should never be rewritten by the DMARC address rewriting function.

DYN_QUERY_CACHE_LIMIT          

16.5

(HPO) Sets the maximum DQL query size that will be cached, in KB.

DYN_QUERY_CACHE_TTL

16.5

(HPO) Sets the TTL of DQL cache entries, in seconds.

EMBEDDED_MAIL_MERGE

14.4

Boolean value which determines whether or not LISTSERV may use a standard SMTP mailer to send mail-merge messages.

FILEDISK

 

The filemode of  the DEFAULT disk  to be used  for storing files via a PUT command

FILEMAXL

 

The maximum number of  lines for any incoming non-mail file to be accepted

FILTER_ALLOW

1.8d (13)

Defines users or classes of users who should be exempt from LISTSERV's standard filter

FILTER_ALSO

1.8b (12)

Defines users or classes of users who should not be allowed to post to any list on the server.

FIOC_INUSE_RETRY

 

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

FIOC_TARGET

 

Defines (in kilobytes) the "target size" for LISTSERV's file cache.

FIOC_TRIM

 

Defines (in kilobytes) the threshold at which point LISTSERV should start aggressively trimming the cache.

FIOC_WARNING

 

Defines (in kilobytes) the cache size at which LISTSERV should write a warning to the console log.

FOREIGN_ANTI_VIRUS

14.4

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.

GETQWAIVE

 

Internet addresses of  persons to  be granted  an "infinite" GET quota

HIDE_TRACEBACK

14.3

Determines whether or not error tracebacks are shown to non-postmasters.

IGNORE

 

(z/VM only) A list of userid@nodes whose messages and files are to be ignored

IGNORE_EMAIL_CASE

14.1

Provided for DBMS lists with UEMAIL fields to work around RFC821 requirement that an email address local-part must be evaluated case-sensitively.

IGNORE_EXTERNAL_PRIME

1.8d (13)

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

INDEX_VIA_GETPOST

1.8c (12)

On z/VM, determines whether INDEX subscriptions use GETPOST or old-style database jobs by default.

INSTPW

 

The  optional local  "installation password"  associated with the INSTALL command

JOB_STAT_DEFAULT

1.8d (13)

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

LDAP_*

15.5

Seven configuration variables under the LDAP_* rubric for configuring LDAP support.

LICENSE_WARNING

 

Toggles license warnings on and off. WARNING: See the full documentation before changing this value.

LIST_ADDRESS

 

Default value for the "List-Address=" keyword

LIST_EXITS

1.8a (10)

Filenames of executable files that can be defined as exits by an "Exit=" list header keyword

LMCPUT

 

Boolean variable indicating how PUT commands for datafiles associated  with the LMC FAC are handled

LOCAL

 

a list  of nodes to be associated with  the hardcoded LCL FAC.  Also used as the default for the "Local=" list keyword

MAILER

 

Internet address of the local mailer

MAILMAXL

 

the maximum number of  lines for an incoming  MAIL file to be accepted

MAXBSMTP

 

Maximum number  of 'RCPT TO:'  lines per BSMTP file  sent to the mailer

MAX_CONSECUTIVE_SUBS

14.3

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

MAXDISTL

 

(HPO only) The maximum number of recipients to be listed in the LISTSERV console log as recipients of an SMTP job

MAXDISTN

 

Maximum number of recipients in forwarded DISTRIBUTE jobs

MAXGET

 

Maximum number of GET requests a user can make per day

MAXGETK

 

Maximum number of kilobytes of data a user may obtain a day via GET requests.

MDISK.cuu

 

Information about library minidisks

MSGD

 

Userid  of the virtual machine running a  RFC1312/MSP server, if "Internet TELL" support is desired

MYDOMAIN

 

The list of domain names  which are equivalent to NODE--e.g., MX addresses, CNAMEs, etc.

MYORG

 

Short organization name that appears in the RFC-822 "Sender:" line.

NDMAIL

 

Whether to send mail to the local MAILER in Netdata format

NODE

 

Internet address of this LISTSERV host

OCI_*

1.8d (13)

Three configuration variables under the OCI_* rubric are available for use with the DBMS/Mail Merge.

ODBC_*

1.8d (13)

Three configuration variables under the ODBC_* rubric are available for use with the DBMS/Mail Merge.

OFFLINETHR

 

Defines   the  system   and   RSCS  spool   thresholds  for   automatic offline/online control

OLD_WEB_INDEXES

17.0

Determines at what level LISTSERV indexes lists

PLAIN_FROMLINE

14.3

Controls the "verboseness" of LISTSERV's administrative From: line.

POSTMASTER

 

A list of  userid@nodes, of which  the first one  is the "main" postmaster (to receive transferred files).

PRIMETIME

 

Defines  the  "prime  time"  for your  node

QUALIFY_DOMAIN

1.8b (11)

Defines domain to be appended to all non-qualified addresses

RESMODES

 

Defines a list of filemodes which are to be considered as "reserved" and  never available for  dynamic ACCESS

RSCS

 

A list of local userids which must be treated as RSCS virtual machines

RSS_ABSTRACT_WORDS

15.5

Sets site-level default of maximum and (optionally) minimum number of words for implicitly-generated RSS abstracts.

RUNMODE

 

The mode (NETWORKED, STANDALONE, or TABLELESS) that LISTSERV runs in.

SEARCH_DISABLED

1.8d (13)

Determines whether or not the non-z/VM SEARCH command is enabled.

SEARCH_PRELOAD

16.5

(HPO) Space-separated list of list names for which search-related files should be preloaded

SIGNUP_ENCRYPT_PASSWORDS

15.5

Boolean value determining whether or not personal LISTSERV passwords are encrypted in the SIGNUP files.  Turned ON by default starting with 15.5.

SMTP_FORWARD

1.8b (11)

The Internet hostname of the server to which all outgoing SMTP mail should be forwarded for delivery

SMTP_FORWARD_n

1.8b (11)

Defines n number of "SMTP workers" used to split up the SMTP forwarding load

SMTP_LISTENER_IP

 

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

SMTP_LISTENER_PORT

 

(Windows) Integer value which sets the port number to which the SMTPL.EXE "listener" will bind at boot time

SMTP_RATE_LIMIT

15.0

(HPO non-z/VM only) Defines bandwidth limits for the server.  Typically used with delivery pools, but can be used to set a server-wide bandwidth limit.

SMTP_RESET_EVERY

1.8b (11)

Directs LISTSERV to reset open SMTP connections every n minutes

SMTP_SPAM_CHECK

16.0

Configuration variable for SMTPL-level spam checking.

SMTP_SPAM_EXIT

16.0

Configuration variable for SMTPL-level spam checking.

SMTP_SPAM_THREADS

16.0

Configuration variable for SMTPL-level spam checking.

SORT_RECIPIENTS

1.8c (12)

Determines whether or not to sort recipients in the RFC821 mail envelope

SPAM_ALERT

14.2

Determines whether or not spam reports are sent to the postmaster

SPAM_DELAY

1.8c (12)

Sets the server-wide value (in minutes) for the anti-spam quarantine period

SPAM_EXIT

14.3

Sets the name of the user-provided exit program used to call a third-party spam scanner.

SPAM_FEEDBACK_ACTION

16.0

Determines the action(s) to take when LISTSERV receives spam complaints via AOL feedback loops

SPAM_FEEDBACK_PROBE

15.5

Determines whether to enable AOL Feedback Loop Auto-Processing.

SPAM_MAXSIZE

14.3

Sets the maximum size, in kilobytes, of any message to be handled by the spam scanner.  Messages over the specified size are not scanned.

Spam Blackists and Whitelists

14.3

How to set up spam blacklists and whitelists (14.3)

SSI

 

Flag telling LISTSERV that it runs in a SSI system

STARTMSG

 

Recipients of start and stop messages

SPOOL_CLEANUP

16.0-2017a

Determines how often (in days) LISTSERV runs its spool cleanup routine

STOREPW

 

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

SYSTEM_CHANGELOG

1.8d-2000b (13.2)

Enables a system-level changelog

TCPGUI_IPADDR

 

Defines the IP address used by the TCPGUI interface

TCPGUI_PORT

 

Defines the port number used by the TCPGUI interface

TRAPIN

 

List  of userid@node  templates  from whom  LISTSERV should  never accept mail

TRAPOUT

 

List of userid@node  templates to whom LISTSERV should never send mail

TUNE_MANY_LISTS

14.3

(HPO only) Enables a suite of HPO functions that can markedly speed up operations on servers with many lists (>100).

UODBC_*

14.5

Three configuration variables under the UODBC_* rubric are available for use with DBMS/Mail Merge.

USE_LSMTP_MAIL_MERGE

 

Determines whether or not LISTSERV will use LSMTP's mail-merge functions for enhanced performance (requires LSMTP Classic version 1.1b or higher). OBSOLETE as of 14.5, see EMBEDDED_MAIL_MERGE instead.

VM30091

 

Indicates whether or not the VM30091 message suppression functions are available

VM_STYLE_INDEX

15.0

Boolean value determining the format of the response to the QUERY FILE command.

WA_USE_INSECURE_COOKIE

16.5

Boolean value determining whether LISTSERV favors login cookies containing plain-text passwords or not.  (Default is 0, i.e., "not").

WEB_BROWSER_CONFIRM

1.8c (12)

Indicates whether or not LISTSERV should require "OK" confirmation for commands sent from WWW browsers.

WWW_ALLOW_LEGACY_INTERFACE

17.0

Determines whether the site, and by extension, individual lists, may continue to operate in legacy 16.5 "compatibility  mode"

WWW_ARCHIVE_CGI

1.8c (12)

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

WWW_ARCHIVE_DIR

1.8c (12)

The full OS path name to the WWW archive directory

WWW_AUTHINFO_DISABLE

1.8d (13)

Disable/enable the web archive interface's IP address verification function

WWW_HSTS_MAX_AGE

16.5

Long integer value telling WA whether or not to output the "Strict-Transport-Security: max-age" http header.

WWW_ONETIME_PW_ROAMING

16.5

Boolean value which, when enabled, allows creation of "roaming" one-time passwords for the web interface which are not tied to IP addresses.

WWW_SHOW_SUBSCRIBER_COUNT

15.5

Disable/enable subscriber counts in the main web archive index page of the server.

XFERTO

 

Userid of the virtual machine to which files found in the lists readers should be transferred


ALL_REQUEST_ALLOWED_USERS

 

Platforms

All.

 

Abstract

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

 

Example

z/VM:  ALL_REQUEST_ALLOWED_USERS = 'joe@example.com pete@abc.unix.example.org'

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

       Export ALL_REQUEST_ALLOWED_USERS

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

 

Details

The ability to post to the ALL-REQUEST alias, which expands to all non-quiet list owners, is 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=, in other words, 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

Platforms

LISTSERV Classic/Classic HPO and later running under Windows or Linux (Intel).

 

Abstract

Turns LISTSERV's real-time anti-virus scanning on or off. Please see the relevant section in the Site Manager's Manual for LISTSERV for further details.

 

Example

z/VM: ANTI_VIRUS = 0

Unix: ANTI_VIRUS=0

Win:  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 which have been configured to use the LISTSERV Anti-Virus Server feature to scan mail for spam or viruses

 

Abstract

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

 

Examples (using AVS_DROP_SPAM)

z/VM: AVS_DROP_SPAM = 1

Unix: AVS_DROP_SPAM=1

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

Platforms

All

 

Abstract

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

z/VM: BITNET_ROUTE = 'BITMAIL.LSOFT.COM'

Unix: BITNET_ROUTE="BITMAIL.LSOFT.COM"

Win:  BITNET_ROUTE=BITMAIL.LSOFT.COM

 

Default Value

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

 

Wildcards

Not allowed.

 

BOUNCES_TO

Platforms

All

 

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

z/VM: BOUNCES_TO = 'FOO@VM.EXAMPLE.EDU'

Unix: BOUNCES_TO=FOO@VM.EXAMPLE.EDU

      export BOUNCES_TO

Win:  BOUNCES_TO=FOO@VM.EXAMPLE.EDU

 

Default Value

Defaults to the value of the POSTMASTER variable.

 

Wildcards

Not allowed.

 


CHANGELOG_DBMS

Platforms

All platforms under which LISTSERV's DBMS features are supported.

 

Abstract

Tells LISTSERV to mirror a copy of all or selected changelogs to DBMS.

 

Examples

Unix: CHANGELOG_DBMS="ALL"

      CHANGELOG_DBMS="SYSTEM BIGLIST-L"

      export CHANGELOG_DBMS

Win:  CHANGELOG_DBMS=ALL

      CHANGELOG_DBMS=SYSTEM BIGLIST-L

 

Details

LISTSERV allows a copy of change logs to be stored in a DBMS. This requires a pre-existing DBMS connection (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

Platforms

All platforms under which LISTSERV's DBMS features are supported.

 

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

 

Unix: CHANGELOG_DBMS_CONNECTION="ODBC MYSERVER"

      export CHANGELOG_DBMS_CONNECTION

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

Platforms

All platforms under which LISTSERV's DBMS features are supported.

 

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

Unix:  CHANGELOG_DBMS_TABLE="CHANGELOG TIMESTAMP LISTNAME RECORDTYPE PARAMETERS"

       export CHANGELOG_DBMS_TABLE

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

CHECKMDISK

Platforms

z/VM only

 

Abstract

Defines the list of library minidisks to be checked at startup.

 

Example

CHECKMDISK = '191 192'

 

Details

This parameter defines the LISTSERV "library" minidisks, i.e., minidisks on which LISTSERV might have to read or write list archives or library files (as opposed to "system" files like PROFILE EXEC or DATABASE FILE which are manipulated by LISTSERV but are not apparent to the users).

 

Default Value

None. This parameter must be set explicitly.

 

Wildcards

Not allowed.

 

See also

MDISK.cuu

 

CLI_*

Platforms

Unix only. LISTSERV Classic/Classic HPO only.

 

Details

Three configuration variables under the CLI_* rubric are available for use with the DBMS/Mail Merge feature. Please see the Developer's Guide for LISTSERV (available separately) for documentation.

 


CMDPIPE_HOSTNAME

 

Platforms

Windows only

 

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

 

 


CMSNAME

Platforms

z/VM only

 

Abstract

The name of the CMS system to be used on IPL commands.

 

Example

CMSNAME = 'CMS'

 

Details

This parameter defines the LISTSERV "library" minidisks, i.e., minidisks on which LISTSERV might have to read or write list archives or library files (as opposed to "system" files like PROFILE EXEC or DATABASE FILE which are manipulated by LISTSERV but are not apparent to the users).

 

Default Value

The standard value for your system.

 

Wildcards

Not allowed.

 


CRASH_MONITOR

Platforms

Windows

 

Abstract

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

 

Example

Win:  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 Windows) 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

Platforms

All

 

Abstract

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

 

Example

z/VM: CREATEPW = 'SECRET'

Unix: CREATEPW="SECRET"

Win:  CREATEPW=SECRET

 

Details

This setting is obsolete and deprecated, as all POSTMASTER-restricted commands may be validated with the postmaster's personal password.  Setting CREATEPW to the special value *NOPW* tells LISTSERV to disable CREATEPW entirely; this is the recommended setting.

 

Default Value

None. This parameter must be set explicitly.

 

Wildcards

Not allowed.

 

DATABASE

Platforms

z/VM only

 

Abstract

Boolean value that determines whether or not the database (archive search) functions are enabled. 0= no, 1= yes.

 

Example

DATABASE = 0

 

Default Value

DATABASE = 1

 

DBMS_*

Platforms

Non-z/VM only. LISTSERV Classic only.

 

Details

Several configuration variables under the DBMS_* rubric are available for use with the DBMS/Mail Merge feature. Please see the Developer's Guide for LISTSERV (available separately) for documentation.

 


DBRINDEX

Platforms

All

 

Abstract

Determines whether or not LISTSERV’s database functions use reverse indexing. The use of reverse indexing is strongly recommended with modern server equipment and operating systems, but can be disabled if performance issues are noted.

 

Example

z/VM: DBRINDEX = 0

Unix: DBRINDEX=0

Win:  DBRINDEX=0

 

Default Value

For z/VM: DBRINDEX=0

For unix and Windows: DBRINDEX=1

 

DEBUG_LOG_PW

Platforms

All

 

Abstract

Debug setting to display passwords in LISTSERV's log file

 

Example

z/VM: DEBUG_LOG_PW = 1

unix: DEBUG_LOG_PW=1

      export DEBUG_LOG_PW

Win:  DEBUG_LOG_PW=1

 

Details

To prevent unintentional password disclosure when e-mailing logs for troubleshooting purposes, LISTSERV suppresses all passwords in its logs.  Passwords are replaced with the text "[redacted]". This applies not only to the PW= keyword, but to the PW and PWC commands, and the internal X-PWADD command used by the web interface.

 

As it is recognized that sometimes passwords need to be seen for debugging purposes, especially on development servers, this debugging option has been added to override the new behavior.

 

Default Value

The default is 0, that is, obfuscate passwords in the log.

 


 

DEBUG_LOG_TCPGUI

Platforms

All non-z/VM, starting with LISTSERV 14.3

 

Abstract

Show fully-logged TCPGUI commands for debugging purposes.

 

Example

unix: DEBUG_LOG_TCPGUI=1

      export DEBUG_LOG_TCPGUI

Win:  DEBUG_LOG_TCPGUI=1

 

Details

By default, LISTSERV truncates overly long TCPGUI command lines to make logs less cumbersome.  A site configuration file variable called DEBUG_LOG_TCPGUI is available, defaulting to 0.

 

When set to 1, all commands starting with 'X-' are logged with no size limit.

 

Enabling TCPGUI debugging makes logs very large. Therefore L-Soft does not recommend leaving this option enabled for long periods.  It should be used for debugging only and disabled after troubleshooting has been completed.

 

Default Value

The default is 0, that is, do not log the full TCPGUI command line.

 


DEFAULT_CHANGELOG_PERIOD

Platforms

Non-z/VM

 

Abstract

Sets the default change-log rotation period.

 

Example

Unix: DEFAULT_CHANGELOG_PERIOD="MONTHLY"

      Export DEFAULT_CHANGELOG_PERIOD

Win:  DEFAULT_CHANGELOG_PERIOD=MONTHLY

 

Details

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, YEARLY, MONTHLY, DAILY, or WEEKLY.

 

Default Value

For backward compatibility with older versions of LISTSERV, the default is SINGLE.

 


DEFAULT_DIST_BACKGROUND

DIST_BACKGROUND_CHUNKSIZE

DIST_BACKGROUND_JOBSIZE

 

Platforms

All HPO

 

Abstract

Values controlling the defaults for background DISTRIBUTE.  DEFAULT_DIST_BACKGROUND is Boolean, DIST_BACKGROUND_CHUNKSIZE and DIST_BACKGROUND_JOBSIZE are integers.

 

Examples

z/VM: DEFAULT_DIST_BACKGROUND = 0

      DIST_BACKGROUND_CHUNKSIZE = 7500

      DIST_BACKGROUND_JOBSIZE = 100

Unix:  DEFAULT_DIST_BACKGROUND=0

export DEFAULT_DIST_BACKGROUND

DEFAULT_BACKGROUND_CHUNKSIZE = 7500

export DIST_BACKGROUND_CHUNKSIZE

DIST_BACKGROUND_JOBSIZE=100

export DIST_BACKGROUND_JOBSIZE

Win:  DEFAULT_DIST_BACKGROUND=0

      DEFAULT_BACKGROUND_CHUNKSIZE=7500

      DIST_BACKGROUND_JOBSIZE=100

 

Details

A background DISTRIBUTE delivery feature is available for high-volume LISTSERV HPO sites. This feature is meant especially for sites signing messages with DKIM, but also for sites using Embedded Mail Merge (EMM) that regularly send jobs larger than 10K recipients. Such sites may require faster processing in order to accommodate other jobs and interactive requests in a timely manner, but by the same token may not need the power of LISTSERV's dedicated DISTRIBUTE workers.

 

Background DISTRIBUTE is enabled by default for all LISTSERV Classic HPO sites.  It can be disabled if necessary by setting DEFAULT_DIST_BACKGROUND to 0 in the site configuration file and restarting LISTSERV.

 

If the default is changed, background DISTRIBUTE can be activated per DISTRIBUTE job with the DISTRIBUTE keyword BACKGROUND=YES.

 

Conversely, if the default is retained, you can specify BACKGROUND=NO explicitly in a DISTRIBUTE job to override the default. This is particularly recommended for test jobs.

 

Instead of creating the outbound messages immediately, LISTSERV saves the relevant data in a background queue. Each data file in the queue contains information for a certain number of recipients. The default is 10,000 and can be tuned with the DIST_BACKGROUND_JOBSIZE site configuration variable if requred.  However, the default value should be a good balance between not creating too many files, and not creating any huge files that take a long time to open. With this setting, a job with 1M recipients will create only 100 files. Each file is somewhere between 1M and 5M depending on the job.

 

The DISTRIBUTE command completes as soon as the last data file is written (in much the same way as when using DISTRIBUTE workers). In one test on a desktop PC, 10k recipients took 0.3 sec elapsed time.

 

Background jobs are processed in sequence, in the order in which they were created, with only one job active at a time. Background delivery pauses immediately if LISTSERV has any other work to do or any other mail to send, although it should be noted that any mail already spooled will continue to be sent. For efficiency, background delivery will not pause until at least x number of messages have been sent. (The number x is set by the site configuration variable DIST_BACKGROUND_CHUNKSIZE, which defaults to 50.)  Progress messages are printed in the LISTSERV log whenever a data file is finished and LISTSERV switches to the next one.

 

Background distribution is compatible with delivery pools, and with the SMTP rate limiting feature discussed below.

 

Default Values

DEFAULT_DIST_BACKGROUND=1

DEFAULT_BACKGROUND_CHUNKSIZE=100

DIST_BACKGROUND_JOBSIZE=1500

 


DEFAULT_LANGUAGE

Platforms

All

 

Abstract

This variable sets the defaults for the Language= keyword for all lists on the server.

 

Examples

z/VM: DEFAULT_LANGUAGE = 'ESPANOL'

      DEFAULT_LANGUAGE = 'NOHTML'

      DEFAULT_LANGUAGE = 'FRANCAIS EXCHANGE'

unix: DEFAULT_LANGUAGE="ESPANOL"

      export DEFAULT_LANGUAGE

Win:  DEFAULT_LANGUAGE=ESPANOL

 

Details

As with other site-level configuration variables, this is a space-separated list of parameters. DEFAULT_LANGUAGE is particularly useful for servers running in non-English-speaking countries and/or with few lists in English. 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).

 

You can also change the list-level defaults for the NOHTML, HTML, and EXCHANGE options if desired.

 

Default Value

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

 

 


DEFAULT_LOOPCHECK

Platforms

All

 

Abstract

This variable sets the default for the Loopcheck= keyword for all lists on the server.

 

Examples

z/VM:  DEFAULT_LOOPCHECK = 'FULL'

unix:  DEFAULT_LOOPCHECK="FULL"

export DEFAULT_LOOPCHECK

Win:   DEFAULT_LOOPCHECK=FULL

 

Details

LISTSERV's loopcheck heuristic defaults to "Loopcheck= Normal" if there is no explicit "Loopcheck=" setting in the list header.

 

Background:  This is a backward-compatible change that eliminated from the default test suite the test that results in the error "Sender:", "From:" or "Reply-To:" field pointing to the list.

 

This test was eliminated because the kinds of loops it was designed to prevent no longer occur on a typical discussion list; most MTAs that were responsible for them have long since been fixed. On the other hand, there are still exceptions, and this test remains the only reliable way to catch these kinds of loops. To put things in perspective, whenever you post something to a discussion list and you, the poster, receive a notice that the mailbox does not exist, it is a signal that the list may be at risk for this type of loop. Nowadays, this almost never happens, but there are still lists where it does. In addition, the larger the list, the higher the risk.

 

To revert to the older  behavior at the server level, set DEFAULT_LOOPCHECK=FULL as shown in the examples above.  This setting may then be overridden at the list level if desired.

 

In the future, it is anticipated that other tests found to be obsolete will be moved from the "Normal" suite to the "Full" suite, for the same backward compatibility.

 

Default Value

NORMAL

 


DEFAULT_MAIL_MERGE

Platforms

All

 

Abstract

This variable sets the default for the Mail-Merge= keyword for all lists on the server.

 

Examples

z/VM:  DEFAULT_MAIL_MERGE = 'YES'

unix:  DEFAULT_MAIL_MERGE="YES"

export DEFAULT_MAIL_MERGE

Win:   DEFAULT_MAIL_MERGE=YES

 

Details

This variable sets the default for list-based mail-merge.  Set to NO to turn off list-based mail-merge, set to YES to turn it on.  Can be overridden at the list level by setting the Mail-Merge= list header keyword.

 

Default Value

Empty string (equivalent to "NO").


DEFAULT_MISC_OPTIONS

Platforms

All

 

Abstract

This variable sets the default for the Misc-Options= keyword for all lists on the server.

 

Examples

z/VM:  DEFAULT_MISC_OPTIONS = '+IGNORE_EMAIL_CASE SUPPRESS_APPROVED_BY'

unix:  DEFAULT_MISC_OPTIONS="+IGNORE_EMAIL_CASE SUPPRESS_APPROVED_BY"

export DEFAULT_MISC_OPTIONS

Win:   DEFAULT_MISC_OPTIONS=+IGNORE_EMAIL_CASE SUPPRESS_APPROVED_BY

 

Details

A DEFAULT_MISC_OPTIONS variable available for use in the site configuration file.  When populated with one or more of the available values for the Misc-Options= list header keyword, it sets a default for all lists that do not already have a Misc-Options= setting.  If a list has a Misc-Options= keyword, the site-level setting is normally overridden.  For instance, if you have (using Windows site.cfg for an example)

 

DEFAULT_MISC_OPTIONS=IGNORE_EMAIL_CASE

 

and a given list has

 

* Misc-Options= RESPECT_EMAIL_CASE

 

then the list-level option overrides the site-level option.

 

You may also prefix options in DEFAULT_MISC_OPTIONS with either  a plus  or minus sign (no  space between  the +/-  sign and  the name  of the  option). As before, an unprefixed option is active  if the list owner did not specify any "Misc-Options=" keyword, and is otherwise ignored.

 

An option prefixed with a plus sign is always active,  for every list. There is  no way for the list owner to turn it off.  Therefore, if we modified our example above to read

 

DEFAULT_MISC_OPTIONS=+IGNORE_EMAIL_CASE

 

then that would always override any list-level setting.

 

Likewise, an option prefixed with a minus signed is prohibited and will be ignored if specified in the list header.  Therefore something like

 

DEFAULT_MISC_OPTIONS=-NO_SPAM_CHECK

 

would disallow list owners from disabling the spam check for their list by setting "Misc-Options= NO_SPAM_CHECK".

 

DOCUMENTED RESTRICTION:  Using the plus and minus prefixes together for the same option (for instance, "DEFAULT_MISC_OPTIONS=+-NO_SPAM_CHECK") will produce unpredictable results and is not supported or recommended.  In the example case, there is no good reason to both (a) force no spam check for all lists and also (b) ignore it if specified in a given list header; all that's needed in that case is the plus prefix.

 

Multiple options for DEFAULT_MISC_OPTIONS are specified in the usual space-separated manner.

 

Default Value

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

 

 

 

DEFAULT_PROBE

Platforms

All

 

Abstract

This variable sets defaults for passive probing.

 

Examples

z/VM: DEFAULT_PROBE = '10 500'

      DEFAULT_PROBE = 21

unix: DEFAULT_PROBE="10 500"

      DEFAULT_PROBE=21

Win:  DEFAULT_PROBE=10 500

      DEFAULT_PROBE=21

 

Details

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 unix-based mail programs without reconfiguration (or, specifically for sendmail, recompilation) to accept the LISTSERV address probe format, 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

Platforms

All

 

Abstract

Provides a default value for the "SPLIT=" command line keyword, causing files ordered through 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

z/VM: DEFAULT_SPLIT = 250

unix: DEFAULT_SPLIT=250

      export DEFAULT_SPLIT

Win:  DEFAULT_SPLIT=250

 

Default Value

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

 

DELAY

Platforms

z/VM only

 

Abstract

The delay between two reader-scan operations. Increasing it will reduce CPU time consumption but will increase response time.

 

Example

DELAY = 250

 

Default Value

Standard value.

 

DIAGD4

Platforms

z/VM only

 

Abstract

Indicates whether LISTSERV should use diagnose X’D4’ to mimic the RSCS origin on files it DISTRIBUTEs. Boolean value. Requires VM/SP release 5 and privilege class B.

 

Example

DIAGD4 = 1

 

Default Value

DIAGD4 = 0

 


DIST_ALLOWED_USERS

Platforms

All

 

Abstract

A space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE. SEE DETAILS.

 

Example

z/VM: DIST_ALLOWED_USERS = 'joe@unix.host.com alma@univ.edu'

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

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

 

Details

A security validation feature exists to secure the DISTRIBUTE command from use by spammers. 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_MINSIZE

DIST_FORWARD_THRESHOLD

 

Platforms

             See details.  Requires Classic HPO.

 

Abstract

Enables and tunes DISTRIBUTE "workers".  This is a tuning feature for embedded mail merge.

 

Examples

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

DIST_FORWARD_THRESHOLD=200

 

or

 

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

DIST_FORWARD_MINSIZE=250

DIST_FORWARD_THRESHOLD=2

 

Platform specific:

 

z/VM:   DIST_FORWARD = DIST1.EXAMPLE.COM 2*DIST2.EXAMPLE.COM

            DIST_FORWARD_MINSIZE=250

            DIST_FORWARD_THRESHOLD = 100

unix:     DIST_FORWARD="0*SELF DIST1.EXAMPLE.COM DIST2.EXAMPLE.COM"

            DIST_FORWARD_MINSIZE=250

            DIST_FORWARD_THRESHOLD=100

            export DIST_FORWARD DIST_FORWARD_THRESHOLD DIST_FORWARD_MINSIZE

Win:     DIST_FORWARD=DIST1.EXAMPLE.COM DIST2.EXAMPLE.COM

            DIST_FORWARD_MINSIZE=250

            DIST_FORWARD_THRESHOLD = 100

 

Details

Configuring many SMTP workers through the SMTP_FORWARD_nSMTP_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 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 either two (14.4) or three (15.0 and later) 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.

 

However, when used in conjunction with DIST_FORWARD_MINSIZE, it may be more efficient to set DIST_FORWARD_THRESHOLD to a low value, e.g., 2, which would allow single-recipient test messages to be processed locally (faster).

 

2. DIST_FORWARD_MINSIZE=nnn

(15.0 or later) This setting is also optional, and defaults to 0, or no limit. It defines the minimum message size, in kilobytes, to make use of the DISTRIBUTE workers. Jobs below that size are processed locally. The message size is defined as the size, counting CRLF terminators, of the contents of the DATA portion of the job.

 

The purpose of DIST_FORWARD_MINSIZE is to better control bandwidth. All jobs above a certain size can be routed to a separate DISTRIBUTE worker, which in turn might be configured to use a separate mail server with a bandwidth cap. The DISTRIBUTE worker in question can run on older hardware as long as it has plenty of disk space. It is expected to build a large queue when oversize jobs are processed.

 

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

 

Historical note:  DIST_FORWARD and DIST_FORWARD_THRESHOLD date from 14.4; DIST_FORWARD_MINSIZE, from 15.0.

 

See also

EMBEDDED_MAIL_MERGE

 

 


DIST_OWNER_MAIL_MERGE

Platforms

Non-z/VM; also, z/VM with Embedded Mail Merge (EMM) enabled

 

Abstract

A Boolean value that determines whether or not list owners may use the mail-merge feature for their lists. BE SURE TO READ DETAILS BELOW!

 

As long as Embedded Mail Merge (EMM) is enabled, this feature is also available on z/VM.

 

Example

z/VM: DIST_OWNER_MAIL_MERGE = 1

unix: DIST_OWNER_MAIL_MERGE=1

Win:  DIST_OWNER_MAIL_MERGE=1

 

Details

DO NOT ENABLE THIS FEATURE UNLESS YOU HAVE ENABLED

EMBEDDED MAIL MERGE!!!!

 

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 LISTSERV's embedded mail merge feature is available and enabled, whereas individual list owners may not have this information.

 

NOTE CAREFULLY that mail-merge operations will fail if EMM is not enabled.*

 

Default Value

0

 

Wildcards

Not allowed.

 

 

_________________

* Note that if embedded mail merge is not available (LISTSERV 14.3 and earlier), the SMTP_FORWARD* variables MUST IMPERATIVELY be pointed to a host which is running LSMTP Classic version 1.1b or higher, or mail-merge operations WILL FAIL. 

 

As LSMTP was withdrawn by L-Soft many years ago and is no longer supported or maintained, it is strongly recommended that sites running LISTSERV 14.3 or earlier and using the mail-merge functions should upgrade to the current supported version of LISTSERV and use EMBEDDED_MAIL_MERGE instead.


DIST_SECURITY

Platforms

All

 

Abstract

A Boolean value which turns off security validation feature for the DISTRIBUTE command. SEE DETAILS.

 

Example

z/VM: DIST_SECURITY = 0

unix: DIST_SECURITY=0

Win:  DIST_SECURITY=0

 

Details

A security validation feature exists to secure the DISTRIBUTE command from use by spammers. 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 disable this behavior, simply set this variable to zero and restart the server. However this is NOT RECOMMENDED as disabling this feature would 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

1

 

See also

DIST_ALLOWED_USERS

 


DKIM_SIGN

Platforms

All

 

Abstract

Specifies DKIM (DomainKeys Identified Mail) domains for which you are able and willing to sign. SEE DETAILS.

 

Example

z/VM:  DKIM_SIGN = 'EXAMPLE.COM *.EXAMPLE.COM EXAMPLE.CA(CA) *.EXAMPLE.CA(CA)'

unix:  DKIM_SIGN="EXAMPLE.COM *.EXAMPLE.COM EXAMPLE.CA(CA) *.EXAMPLE.CA(CA)"

       export DKIM_SIGN

Win:   DKIM_SIGN=EXAMPLE.COM *.EXAMPLE.COM EXAMPLE.CA(CA) *.EXAMPLE.CA(CA)

 

Details

LISTSERV previously supported Yahoo!'s DomainKeys email authentication system.  DomainKeys is now deprecated in favor of DKIM (DomainKeys Identified Mail) (see http://www.dkim.org/ for details).  L-Soft began supporting DKIM in the version 16.0-2017a "level set" release in February, 2017.  The switch is a transparent change for pre-16.0-2017a LISTSERV sites that were already running with DomainKeys enabled.

 

Please note, however, that sites that have used the LISTSERV DomainKeys feature since it was originally released should take this opportunity to review their key pair, as key lengths which were sufficient for DomainKeys may be too short for DKIM.  Per RFC 6376 "DomainKeys Identified Mail (DKIM) Signatures", Section 3.3.3, "Signers MUST use RSA keys of at least 1024 bits for long-lived keys", whereas many DomainKeys sites may be using keys of 512 or 768 bits.

 

Your LISTSERV Classic or Classic HPO installation must have current maintenance in order to enable this support.

 

In order to enable DKIM signing, the LISTSERV site administrator must provide private keys in a standard format for each domain LISTSERV is expected to sign for.  These keys are placed into text files in LISTSERV's A directory and are specified to LISTSERV using the DKIM_SIGN site configuration variable.

 

Because DKIM configuration is complicated, L-Soft has created a separate explanatory document called Using LISTSERV with DomainKeys. Please review Using LISTSERV with DomainKeys before enabling this feature.

 

Default Value

Not set (feature is disabled).

 

See also

Using LISTSERV with DomainKeys


DKIM_SIGN_ALL

Platforms

All

 

Abstract

A Boolean value which tells LISTSERV whether or not to sign all messages for which it has a suitable DKIM private key. SEE DETAILS.

 

Example

z/VM: DKIM_SIGN_ALL = 1

unix: DKIM_SIGN_ALL=1

      export DKIM_SIGN_ALL

Win:  DKIM_SIGN_ALL=1

 

Details

LISTSERV supports DKIM (DomainKeys Identified Mail) (see http://www.dkim.org/ for details).

 

Your LISTSERV Classic or Classic HPO installation must have current maintenance in order to enable this support.

 

Additionally, LISTSERV HPO for Windows, Linux, and FreeBSD incorporates a DKIM Accelerator for faster signing of messages.  The accelerator is part of HPO and cannot be disabled without disabling HPO.

 

By default (DKIM_SIGN_ALL=0), LISTSERV does not sign any messages using DKIM other than those for which DKIM signing is expicitly requested by the caller, for instance, DISTRIBUTE jobs with an explicit "DKIM=YES" parameter in the JOB card.  List mail and non-list administrative messages will not be signed when DKIM_SIGN_ALL is left at the default value.

 

However, because of its relationship to the DMARC protocol, you will probably 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.

 

IMPORTANT:  Please review Using LISTSERV with DomainKeys before enabling this feature. DKIM support MUST be configured in LISTSERV before setting DKIM_SIGN_ALL=1 or message signing will fail.

 

Default Value

0

 

See also

DKIM_SIGN

Using LISTSERV with DomainKeys

 


 

DMARC_NO_REWRITE

Platforms

All 16.5-2018a and following

 

Abstract

A list of domains and subdomains which should never be rewritten by the DMARC address rewriting function.

 

Example

z/VM: DMARC_NO_REWRITE = 'EXAMPLE.COM *.EXAMPLE.COM'

unix: DMARC_NO_REWRITE="EXAMPLE.COM *.EXAMPLE.COM"

      export DMARC_NO_REWRITE

Win:  DMARC_NO_REWRITE=EXAMPLE.COM *.EXAMPLE.COM

 

Details

Under normal circumstances, when receiving mail for a list from a user in a domain that has a DMARC record containing "p=reject" or "p=quarantine", LISTSERV will by default rewrite From: line addresses into a format that will appear to be coming from the LISTSERV server's own NODE= address.  For instance, for a LISTSERV node known as LISTSERV.EXAMPLE.COM, mail coming from a user at yahoo.com (which has a restrictive DMARC policy) will be rewritten as something like

 

00000003f16b4808-dmarc-request@LISTSERV.EXAMPLE.COM

 

when their posting is sent out to the list. LISTSERV will keep a permanent record of that equivalency, so that future mail from that user will always be rewritten to that address, and so that replies to that address will always be forwarded to the user in question at yahoo.com. (Note however that the user's real address is always preserved in the list archives.)

 

Organizations which use DMARC "p=reject" or "p=quarantine" for their own domain, and where the outbound MTA used by LISTSERV (i.e., in its SMTP_FORWARD_n= settings) is authorized to send from the organization's domain, may use the DMARC_NO_REWRITE configuration variable to prevent posters' addresses in their own domain from being rewritten, as may be desirable for policy or branding reasons.

 

Please note carefully that this feature should not be used to simply disable DMARC rewriting altogether.  To do so will likely result in a great deal of LISTSERV mail not being delivered to domains that have "p=reject" or "p=quarantine" set in their DMARC record.  L-Soft will not be responsible for loss of mail due to the misuse of this feature.

 

Default Value

Set to null string, that is, LISTSERV will perform a DMARC rewrite for any domain configured with "p=reject" or "p=quarantine" in its DMARC DNS record.

 

See also

Find Out How LISTSERV Can Help You Comply With DMARC Requirements


 

DYN_QUERY_CACHE_LIMIT

Platforms

All 16.5 (and later), with HPO

 

Abstract

Maximum dynamic query size to cache, in kilobytes.

 

Example

z/VM: DYN_QUERY_CACHE_LIMIT = 10

unix: DYN_QUERY_CACHE_LIMIT=10

      export DYN_QUERY_CACHE_LIMIT

Win:  DYN_QUERY_CACHE_LIMIT=10

 

Details

Beginning with LISTSERV 16.5, dynamic query performance under HPO has been improved by caching queries run for authentication purposes.  The intent is to speed up response time for queries run from WA against lists which use DQL queries for the purpose of defining owners, moderators, etc.  LISTSERV will now cache the information after the first run against the directory server and use the cache for subsequent queries (e.g., "LISTS MODERATED BY" and "LISTS OWNED BY") for the same list.  The cache is also available for any DQL back-end, including exits.

 

The cache is enabled by setting the DYN_QUERY_CACHE_LIMIT keyword to a non-zero value, where the value is in kilobytes, representing the maximum dynamic query size that will be cached.

 

The dynamic query cache is disabled by default and must be enabled to take advantage of the performance improvement it offers.

 

Default Value

0 (cache is disabled)

 

See also

DYN_QUERY_CACHE_TTL

 


 

DYN_QUERY_CACHE_TTL

Platforms

All 16.5 (and later), with HPO

 

Abstract

Sets the TTL (Time To Live) of DQL cache entries.

 

Example

z/VM: DYN_QUERY_CACHE_TTL = 60

unix: DYN_QUERY_CACHE_TTL=60

      export DYN_QUERY_CACHE_LIMIT

Win:  DYN_QUERY_CACHE_TTL=60

 

Details

Sets the TTL (Time To Live), in seconds, of dynamic query cache entries.  The default is 15 minutes (900 seconds).  Shorter values can be used for testing, if desired, but shorter values may not alleviate bottlenecking in production.

 

It may be helpful to determine the propagation time of directory service changes within your network and organization before reducing or increasing the default value.

 

Default Value

900

 

See also

DYN_QUERY_CACHE_LIMIT

 

 


EMBEDDED_MAIL_MERGE

Platforms

All

 

Abstract

A Boolean value determining whether LISTSERV writes individual mail-merge messages to its spool, or uses BSMTP to offload the creation of the individual messages to an external server.  With this value set to 1, any high-capacity SMTP server can be used to deliver LISTSERV e-mail that uses mail-merge.

 

Embedded Mail Merge is enabled by default.

 

Example

z/VM: EMBEDDED_MAIL_MERGE = 1

unix: EMBEDDED_MAIL_MERGE=1

      export EMBEDDED_MAIL_MERGE

Win:  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, DISTRIBUTE "workers" can be used in very high volume situations to move mail smoothly.

 

History:  Embedded mail-merge was introduced to end dependence on L-Soft's discontinued and no longer supported LSMTP product.  Please, if you are still using LSMTP, find another SMTP product.

 

Default Value

1 (that is, enabled)

 

See also

DIST_FORWARD


FILEDISK

Platforms

z/VM only

 

Abstract

The filemode of the DEFAULT disk to be used for storing files with a PUT command.

 

Example

FILEDISK = 'L5'

 

Default Value

FILEDISK = 'A5'

 

Wildcards

Not allowed.

 

FILEMAXL

Platforms

All

 

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

z/VM: FILEMAXL = 25000

unix: FILEMAXL=25000

Win:  FILEMAXL=25000

 

Default Value

500000

 

See also

MAILMAXL


FILTER_ALLOW

Platforms

All

 

Abstract

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

 

Example

z/VM: FILTER_ALLOW = '*@GOODNODE.COM POSTMASTER@SOMEHOST.NET'

unix: FILTER_ALLOW="*@GOODNODE.COM POSTMASTER@SOMEHOST.NET"

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

Platforms

All

 

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 guide for more information.

 

Example

z/VM: FILTER_ALSO = '*@BADNODE.COM OBNOXUSR@SOMEHOST.NET'

unix: FILTER_ALSO="*@BADNODE.COM OBNOXUSR@SOMEHOST.NET"

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

Platforms

z/VM, Windows

 

Abstract

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

 

Example

z/VM: FIOC_INUSE_RETRY = 15

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

10


FIOC_TARGET

Platforms

All, but see note in details re non-HPO.

 

Abstract

Defines the "target size" for LISTSERV's file cache (in kilobytes). See the LISTSERV Tuning Guide (available from L-Soft at no extra charge) for more information.

 

Example

z/VM: FIOC_TARGET = 15000

unix: FIOC_TARGET=15000

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

 

If you are not running LISTSERV HPO, note that FIOC_TARGET is capped at 4096.

 

Default Value

System dependent.

 


FIOC_TRIM

Platforms

All, but see note in details re non-HPO.

 

Abstract

Defines the threshold (in kilobytes) where LISTSERV should start aggressively trimming the cache. See the LISTSERV Tuning Guide (available from L-Soft at no extra charge) for more information.

 

Example

z/VM: FIOC_TRIM = 17000

unix: FIOC_TRIM=17000

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

 

If you are not running LISTSERV HPO, note that FIOC_TRIM is capped at 4915 (120% of the FIOC_TARGET cap of 4096).

 

Default Value

System dependent.

 

 


FIOC_WARNING

Platforms

All

 

Abstract

Defines the cache size (in kilobytes) at which LISTSERV should write a warning to the console log. See the LISTSERV Tuning Guide (available from L‑Soft at no extra charge) for more information.

 

Example

z/VM: FIOC_WARNING = 20000

unix: FIOC_WARNING=20000

Win:  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).  However, the default minimum is 50000.

 

Default Value

FIOC_WARNING=50000

 


FOREIGN_ANTI_VIRUS

Platforms

Windows only, AVS systems excluded.

 

Abstract

Adds 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

This feature 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)


GETQWAIVE

Platforms

z/VM only; there is no GET quota on any other platform.

 

Abstract

Internet addresses (space-delimited) of persons to be granted an "infinite" GET quota.

 

Example

GETQWAIVE = 'nathan@example.com holly@example.edu lowell@example.bitnet'

 

Default Value

Empty string.

 

Wildcards

Not allowed.

 


HIDE_TRACEBACK

Platforms

All

 

Abstract

Boolean value determining whether or not error tracebacks are shown to non-postmasters.

 

Examples

z/VM: HIDE_TRACEBACK = 1

unix: HIDE_TRACEBACK=1

Win:  HIDE_TRACEBACK=1

 

Details

Tracebacks in LISTSERV error messages may be suppressed by setting the Boolean site configuration variable HIDE_TRACEBACK. When set, 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

Platforms

z/VM only

 

Abstract

A list of Internet addresses (space-delimited) whose messages and files are to be ignored. Usually these are addresses that generate auto-responses that should simply be discarded.

 

Example

IGNORE = 'response@* dirmaint@'node 'reslim@'node

 

Default Value

Empty string.

 

Wildcards

Allowed.

 


IGNORE_EMAIL_CASE

 

Platforms      

Non-z/VM

 

Abstract

Provided for DBMS lists with UEMAIL fields to work around RFC821 requirement that an email address local-part must be evaluated case-sensitively.

 

Examples

unix: IGNORE_EMAIL_CASE=0

      export IGNORE_EMAIL_CASE

Win:  IGNORE_EMAIL_CASE=0

 

Details

IGNORE_EMAIL_CASE=0 (the default) tells LISTSERV to operate per RFC821 and treat address fields with differently-cased local parts as different addresses. 

 

IGNORE_EMAIL_CASE=1 causes the ADD command to ignore the case of the "local part" of list subscriber entries (that is, the part of the address that is to the left of the "@" sign). Although most modern mail clients are configured to ignore the case of the local-part, this behavior technically violates RFC821 which states that local-parts are considered case-sensitive.

 

If an entry whose "local part" differs only in case is found in the list during an ADD operation (for instance, JOE@EXAMPLE.COM vs. joe@EXAMPLE.COM), that entry will be assumed to be the entry that was sought, and the address field will be updated to the new case (that is, "JOE@" will be changed to "joe@").  No other change will be made to the entry unless there is a change in the name field, in which case the name field will also be updated.

 

If there is no change in the address field associated with the entry, no change will be made to the entry (again, unless the name field changes, in which case the entry will be updated). 

 

In either case, when this option is set, a new entry with a different case will NOT be added.

 

Note the following caveats:

 

1.     Pre-existing duplicates are not automatically removed from lists when this option is set.

2.     Because ADD updates the case of entries, it is possible to end up with multiple entries that have exactly the same case.

3.     The only real way to de-dupe a given address is to DELETE and then re-ADD it.

 

Other than this, existing duplicate entries work exactly as they did before the option was enabled.  Commands that do not add new entries ignore the option.

 

And finally, it should be carefully noted that the PUT command also ignores the option.

 


IGNORE_EXTERNAL_PRIME

Platforms

All

 

Abstract

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

 

Example

z/VM: IGNORE_EXTERNAL_PRIME = 1

unix: IGNORE_EXTERNAL_PRIME=1

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

0

 

 


INDEX_VIA_GETPOST

Platforms

z/VM only

 

Abstract

The INDEX subscription option uses the GETPOST command rather than a database job by default. INDEX_VIA_GETPOST can be used to control this default.

 

Example

INDEX_VIA_GETPOST = 0

 

Details

The GETPOST command requires fewer resources and is easier to use for non-technical users. The old database job format is still supported.  The old behavior can be restored by adding 'INDEX_VIA_GETPOST = 0' to LOCAL SYSVARS, but this is not recommended.

 

Default Value

1

 


INSTPW

Platforms

z/VM-NJE only

 

Abstract

The optional local "installation password" associated with the INSTALL command.

 

Example

INSTPW = 'fixmelater'

 

Details

When INSTPW is set to '', it indicates that there is no local password and that only the global password is required to install automatic shipments. The server can then be updated by the LISTSERV Master Coordinator without requiring any intervention by the local operation staff (provided that this has not been disabled from the LSV$INST EXEC user exit). A non-null value indicates that the installation of each shipment must be confirmed by means of an "INSTALL PASSWORD instpw" command from either the LMC or the local operation staff.

 

Default Value

Empty string.

 

Wildcards

Not allowed.

 


JOB_STAT_DEFAULT

Platforms

All Classic/Classic HPO (no effect under Lite)

 

Abstract

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

 

Example

z/VM: JOB_STAT_DEFAULT = 0

unix: JOB_STAT_DEFAULT=0

Win:  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. (In LISTSERV Lite the summary is suppressed and this variable setting has no effect.)

 

Default Value

1

 

Wildcards

Not allowed.


LDAP_*

Platforms

All Classic and Classic HPO

 

Details

Several configuration variables under the LDAP_* rubric are available for use to control LISTSERV's LDAP directory extensibility feature. Please see the LISTSERV LDAP Overview  (available separately) for documentation.

 

LICENSE_WARNING

Platforms

All

 

Abstract

Disable LISTSERV's automatic license warnings. WARNING: SEE DETAILS AND DISCLAIMER BELOW. IT IS NOT RECOMMENDED TO DISABLE LICENSE WARNINGS.

 

Example

z/VM: LICENSE_WARNING = 0

unix: LICENSE_WARNING=0

Win:  LICENSE_WARNING=0

 

Details

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, and issues a similar warning every day for 45 days prior to the license expiration date. Warnings are automatically disabled for small licenses (9 points or less). Warnings can be turned off for higher license point values by using this Boolean variable.

 

DISCLAIMER: Setting this variable to 0 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

1

 


LIST_ADDRESS

Platforms

All (obsolete)

 

Abstract

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

 

Example

z/VM: LIST_ADDRESS = 'LIST-ID@NJE'

unix: LIST_ADDRESS="LIST-ID@FQDN"

Win:  LIST_ADDRESS=LIST-ID@FQDN

 

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-z/VM systems, other than as a migration aid for mainframe BITNET sites moving off of z/VM.

 

Default Value

LIST-ID@FQDN

 

Wildcards

Not allowed.


LIST_EXITS

Platforms

All

 

Abstract

A list of filenames of files that can be activated as list exits through the "Exit=" list header keyword. Any suffixes (CMD or BAT for Windows for example) should not be included.

 

Example

z/VM: LIST_EXITS = 'EXIT1 EXIT2'

unix: LIST_EXITS="EXIT1 EXIT2"

Win:  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 Deveoper's Guide to LISTSERV for more information on list exits.

 

Default Value

Empty string (no exits enabled).

 

Wildcards

Not allowed.

 


LMCPUT

Platforms

z/VM only

 

Abstract

A boolean variable indicating how PUT commands for datafiles associated with the LMC FAC are handled.

 

Example

LMCPUT = 0

 

Details

This variable indicates whether PUT commands for datafiles associated with the LMC FAC must be honored immediately (1) or transferred to the postmaster (0). Note that in the latter case, the postmaster is responsible for updating the file.

 

Default Value

LMCPUT = 1

LOCAL

Platforms

All

 

Abstract

A space-separated 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).

 

Examples

z/VM: LOCAL = 'PDQ.COM *.PDQ.COM PDQ.NET *.DARNQUICK.ORG'

unix: LOCAL="PDQ.COM *.PDQ.COM PDQ.NET *.DARNQUICK.ORG"

Win:  LOCAL=PDQ.COM *.PDQ.COM PDQ.NET *.DARNQUICK.ORG

 

Details

Note carefully that LISTSERV evaluates the values associated with LOCAL literally. If you code "LOCAL = 'XYZ.EDU'", then users on (for instance) UNIX.XYZ.EDU will not be treated as local users. Likewise, if you code "LOCAL = '*.XYZ.EDU'", then users who are addressed as userid@XYZ.EDU will not be considered local users. In order for all users in a given domain to be considered "local" by LISTSERV, you must imperatively code a value for LOCAL that covers all bases--ie, "LOCAL = 'XYZ.EDU *.XYZ.EDU'".

 

Default Value

None. This parameter must be set explicitly.

 

Wildcards

Allowed.

 


MAILER

Platforms

z/VM only

 

Abstract

RFC822 address of the local mailer.

 

Example

MAILER = 'MAILERT@'node

 

Default Value

'MAILER@'node

 

Wildcards

Not allowed.

 


MAILMAXL

Platforms

All (obsolete except for z/VM BITNET servers)

 

Abstract

The maximum acceptable size, in lines, of an incoming mail message. Obsolete; see Details.

 

Example

z/VM: MAILMAXL = 15000

unix: MAILMAXL=15000

Win:  MAILMAXL=15000

 

Details

Messages larger than MAILMAXL lines are not accepted for processing. For all practical purposes this option is obsolete (it was intended to solve a problem specific to z/VM BITNET servers) and you should not set it (i.e., you should accept the default) unless you are experiencing this kind of problem. In other words, if you aren't running z/VM on BITNET, don't set this! It is preferable to set a Sizelim= keyword in individual list headers if you must restrict postings on the basis of size. Do not use MAILMAXL as a server-level global replacement for Sizelim=.

 

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.

 

Note that if MAILMAXL is set, messages coming in that exceed MAILMAXL will be discarded without any notification to the sender. This is not the same as the list header keyword setting Sizelim=, which when exceeded will cause LISTSERV to send a notification. However note carefully that since MAILMAXL is evaluated before the message is actually processed, that is, before Sizelim= can be evaluated, a message that exceeds MAILMAXL (but which may or may not exceed Sizelim= for the list it is being posted to) will be discarded without warning to the sender. This is why it is preferable to restrict postings based on size at the list level rather than at the server level.

 

Default Value

MAILMAXL defaults to the value of FILEMAXL. Note that under z/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. It is not recommended to set MAILMAXL to a value less than 10000, and LISTSERV will issue a warning at startup if MAILMAXL is set lower than that.

 


MAXBSMTP

Platforms

All

 

Abstract

The maximum number of recipients in each message forwarded to the mail delivery system.

 

Example

z/VM: MAXBSMTP = 50

unix: MAXBSMTP=50

Win:  MAXBSMTP=50

 

Details

If your mail delivery system runs on 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.

 

This is an optimization parameter that you would normally set through the Optimization Settings tab in the web administration interface.

 

Default Value

100

 

See also

SMTP_FORWARD

 


MAX_CONSECUTIVE_SUBS

Platforms

All LISTSERV 14.3 and later

 

Abstract

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

 

Example

z/VM: MAX_CONSECUTIVE_SUBS = 50

unix: MAX_CONSECUTIVE_SUBS=50

Win:  MAX_CONSECUTIVE_SUBS=50

 

Details

As a preventative against spoofers adding third parties to hundreds of lists without their knowledge, this variable sets the number of local lists to which a user may subscribe at any one given time. The default is 50 lists, after which LISTSERV assumes that the subscription requests are coming from a spoofer, and cancels the last 50 subscription requests for the user in question. (To clarify, a user may be subscribed to more than 50 lists on the server, but may not issue more than 50 subscription requests in a row.)

 

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

 

In LISTSERV 16.0-2017a and following, MAX_CONSECUTIVE_SUBS is also applied to the X-CONFIRM command, to prevent an exploit which targeted the X-CONFIRM command via signup pages in the LISTSERV web interface.  This exploit flooded target email addresses with bogus subscription confirmation requests from multiple lists on the server. This could happen either accidentally (broken external script) or by malicious intent.  The original exploit would result in a further flooding several days later when the bogus subscription requests expired.  Because X-CONFIRM is not a SUBSCRIBE command, it was not limited by the MAX_CONSECUTIVE_SUBS setting.

 

To mitigate this problem, LISTSERV's internal X-CONFIRM function was modified to honor MAX_CONSECUTIVE_SUBS, and will reject consecutive X-CONFIRM commands from the same user once that limit is reached.  The rejection message is displayed in the web interface and is not sent to the targeted address

 

Default Value

50

 


MAXDISTL

Platforms

All; HPO only

 

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

z/VM: MAXDISTL = 100

unix: MAXDISTL=100

Win:  MAXDISTL=100

 

Default Value

1000

 

MAXDISTN

Platforms

All

 

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

z/VM: MAXDISTN = 100

unix: MAXDISTN=100

Win:  MAXDISTN=100

 

Default Value

1000

 


MDISK.cuu

Platforms

z/VM only

 

Abstract

Information about library minidisks

 

Example

MDISK.191 = 'A- N L L 85 95 //A(191) is the LISTSERV system minidisk.' 

MDISK.192 = 'D- N L L 100 100 //D(192) is LISTSERV''s scratch work disk.'

 

Details

The 'MDISK.' stem defines various parameters associated with LISTSERV "library" minidisks, that is, minidisks on which LISTSERV might have to read or write list archives or library files (as opposed to "system" files like PROFILE EXEC or DATABASE FILE which are manipulated by LISTSERV but are not apparent to the users). The syntax of the assignment is the following:

 

MDISK.cuu = 'acc rw ro nl th1 th2 / wlist / wmsg'

 

The slash signs are used as separators. They allow for more parameters to be specified in future releases while ensuring compatibility.

 

·         CUU is the minidisk address (*three* hexadecimal digits), or the FULL name of the SFS directory (filepool:dirid), as returned by a QUERY ACCESSED command.

 

·         ACC indicates how the minidisk should be accessed. If it should be accessed permanently at a fixed filemode, just specify its filemode letter (eg 'F') and LISTSERV will access it during startup. If the disk has already been accessed by the PROFILE, append a dash to the filemode letter (as in 'A-') to bypass the ACCESS command. If the disk should be accessed dynamically (ie as the needs arise), specify '*' to let LISTSERV choose the filemode, '*S' to force the filemode to be in the T-Y range (for security reasons) or '*fm' to force a given filemode to be used for the disk (note that A,D and Z are reserved and cannot be specified in this fashion).

 

·         RW indicates what LISTSERV should do if the minidisk is found to be accessed in R/W status. 'N' means that this is a normal condition, 'W' means that a warning message should be issued (see below) and 'L' means that this is a fatal error and LISTSERV should log off.

 

·         RO is similar to RW and describes what happens if the minidisk is R/O; NL specifies what should be done if the minidisk is not linked.

 

·         TH1 is the %utilization threshold above which a warning message will be generated during startup. Specify 100 to bypass the test.

 

·         TH2 is the %utilization threshold above which LISTSERV will log off. Specify 100 to bypass the test.

 

·         WLIST is a blank-separated list of RFC822 addresses to be notified if something is wrong with the minidisk. Note that the postmasters are always notified, so that the default setting of WLIST (null string) actually means that the notification will be sent only to the postmasters.

 

·         MSG is an optional message to be appended to the standard error or warning messages generated by LISTSERV. This could, for example, contain some description of the contents of the minidisk.

 

Please note that only those CUUs listed in the CHECKMDISK variable will be verified at startup time. However, some of the information in the MDISK stem will be used when dynamically accessing libraries. The default settings for library minidisks which have not been described here is shown below.

 

Default Value

MDISK.cuu = '*S N N N 100 100//'

 

Wildcards

Not allowed.

 

See also

CHECKMDISK

 


MSGD

Platforms

z/VM only

 

Abstract

Userid of the virtual machine running a RFC1312/MSP server, if "Internet TELL" support is desired. Leave this field blank if you are not running a MSGD virtual machine.

 

Example

MSGD = 'MSGD'

 

Default Value

Emtpy string.

 

Wildcards

Not allowed.

 


MYDOMAIN

Platforms

All

 

Abstract

The list of all the possible Internet host names and aliases for the machine on which LISTSERV is running.

 

Examples

z/VM: MYDOMAIN = 'LISTSERV.XYZ.COM WWW.XYZ.COM VM.IGATE.XYZ.COM'

      MYDOMAIN = NODE 'WWW.XYZ.COM VM.IGATE.XYZ.COM'

unix: MYDOMAIN="LISTSERV.XYZ.COM WWW.XYZ.COM UNIX.IGATE.XYZ.COM"

      MYDOMAIN="$NODE WWW.XYZ.COM UNIX.IGATE.XYZ.COM"

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

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

 

Details

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.

 

Default Value

None. This parameter must be set explicitly.

 

Wildcards

Not allowed.


MYORG

Platforms

All

 

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

z/VM: MYORG = 'XYZ, Inc.'

unix: MYORG="XYZ, Inc."

Win:  MYORG=XYZ, Inc.

 

Default Value

Not set. Generates the standard "L-Soft list server at host" organization name.

 

Wildcards

Not allowed.

 

NODE

Platforms

All

 

Abstract

Defines the Internet hostname of this LISTSERV host.

 

Example

z/VM: NODE = 'LISTSERV.MYHOST.NET'

unix: NODE="LISTSERV.MYHOST.NET"

Win:  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, for example, 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.


OCI_*

Platforms

AIX, Linux, Solaris. LISTSERV Classic/Classic HPO only.

 

Details

Three configuration variables under the OCI_* rubric are available for use with LISTSERV's DBMS/Mail Merge feature. Please see the Developer's Guide for LISTSERV (available separately) for documentation.

 

Windows servers may access Oracle databases via ODBC.

 

ODBC_*

Platforms

Windows, LISTSERV Classic only.

 

Details

Three configuration variables under the ODBC_* rubric are available for use with LISTSERV's DBMS/Mail Merge feature. Please see the Developer's Guide for LISTSERV (available separately) for documentation.

 


 

OLD_WEB_INDEXES

Platforms

Non-VM 17.0 and later

 

Abstract

Numeric value determining at what level LISTSERV indexes lists for the web interface.

 

Example

Unix: OLD_WEB_INDEXES=0

Win:  OLD_WEB_INDEXES=0

 

Note for Unix:  OLD_WEB_INDEXES has been pre-exported in the "go" script which ships with LISTSERV 17.0 and does not need to be exported separately in go.user.

Details

The setting of OLD_WEB_INDEXES determines at what level LISTSERV indexes lists. The options are as listed in the following table (the default value is in bold):

 

OLD_WEB_INDEXES=0

LISTSERV will create and maintain only new-style single indexes after a list has been indexed from scratch. Old-style indexes are used until the list is re-indexed and are then removed permanently.

 

This is the "normal" setting for 17.0 and the default.

OLD_WEB_INDEXES=1

Both types of indexes are created when indexing the list from scratch and are maintained in parallel. In other words, re-indexing a list adds a new-style index without losing the old-style index.

 

This is a hybrid mode for testing only.

OLD_WEB_INDEXES=2

A new-style single index is never created. This setting is supported only with WWW_ALLOW_LEGACY_INTERFACE=2.

 

This is a compatibility mode only.

 

OLD_WEB_INDEXES is closely related to the WWW_ALLOW_LEGACY_INTERFACE site configuration variable, and the values of both variables should be considered carefully if there is any reason to change them from the default.  Please see the documentation below for WWW_ALLOW_LEGACY_INTERFACE for more information.

 

Default Value

0

 

See also

WWW_ALLOW_LEGACY_INTERFACE

 

 


PLAIN_FROMLINE

Platforms

All

 

Abstract

Boolean value controlling the "verboseness" of LISTSERV's administrative From: line.

 

Example

z/VM: PLAIN_FROMLINE = 1

Unix: PLAIN_FROMLINE=1

Win:  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: "LISTSERV.EXAMPLE.COM LISTSERV Server (16.0)" <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

Platforms

All

 

Abstract

The space-delimited list of Internet addresses of the "LISTSERV maintainers", that is, 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

z/VM:  POSTMASTER = 'NATHAN@EXAMPLE.COM Hide: LIAM@EXAMPLE.COM Quiet: ERIC@EXAMPLE.COM'

unix:  POSTMASTER="NATHAN@EXAMPLE.COM Hide: LIAM@EXAMPLE.COM Quiet: ERIC@EXAMPLE.COM"

Win:   POSTMASTER=NATHAN@EXAMPLE.COM Hide: LIAM@EXAMPLE.COM Quiet: ERIC@EXAMPLE.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

Platforms

All

 

Abstract

Defines the "prime time" for your node, during which mail to lists configured as "Prime= Yes" should not be processed. This option is mostly for small machines that are very busy during business hours. See Appendix B under the list header keyword "Prime=" for more information. Note that the value for PRIMETIME must always be enclosed in quotes, EXCEPT on Windows machines.

 

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, for example, it is the "prime time" of day on your machine during which other operations must take precedence.

 

Example

z/VM: PRIMETIME = 'MON-FRI: 0800-1700; SAT-SUN: -'

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

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

 

NOTE CAREFULLY that under Windows, the PRIMETIME= value IS NOT QUOTED. For all other OS ports, the variable setting must be quoted as shown.

 

Default Value

MON-SUN: -

 

Wildcards

Not allowed.

 


QUALIFY_DOMAIN

Platforms

All

 

Abstract

Defines the Internet domain to be appended to all non-qualified Internet addresses in incoming mail.

 

Example

z/VM: QUALIFY_DOMAIN = '.DC.LSOFT.COM'

unix: QUALIFY_DOMAIN=".DC.LSOFT.COM"

Win:  QUALIFY_DOMAIN=.DC.LSOFT.COM

 

 

Details

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. Note that this option applies only to unqualified addresses in the mail header, for example, with SUBSCRIBE. It will not qualify hostnames used with ADD or other third-party (list owner) commands.

 

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.

 


RESMODES

Platforms

z/VM

 

Abstract

Defines a list of filemodes which are to be considered as "reserved" and never available for dynamic ACCESS

 

Details

This variable defines a list of filemodes which are to be considered as "reserved" and never available for dynamic ACCESS. That is, LISTSERV will never ACCESS a library minidisk by itself under one of these filesmodes. You may of course use them to ACCESS minidisks from the PROFILE EXEC or from any local command/exec you may have written. Note that A,D,S and Z are always reserved, regardless of what you put in the RESMODES variable. Also, any filemode which happens to be in use at the time LISTSERV is started will be marked as reserved, so that LISTSERV will never release minidisks which were ACCESSed when it was started.

 

Note that the value for RESMODES= must be in UPPER CASE.

 

Example

RESMODES = 'BC'

 

Default Value

None (that is, no RESMODES are reserved by default).

 

Wildcards

Not allowed.

 


RSS_ABSTRACT_WORDS

Platforms

Non-z/VM, with web archive interface enabled.

 

Abstract

Sets site-level maximum and (optionally) minimum number of words for implicitly-generated RSS abstracts.

 

Details

RSS support in LISTSERV's web archive interface includes RSS abstracts, which are available in your RSS feed by default.

 

DOCUMENTED RESTRICTION: If you are upgrading your site from an older version, the 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. The REINDEX command is available for this purpose.

 

An abstract is either generated implicitly from the existing text of the message, or may be specified explicitly. For details regarding the construction of explicit abstracts, which are not controlled by this site configuration variable, please see either the List Owner's Manual or the Site Manager's Manual for LISTSERV.

 

RSS_ABSTRACT_WORDS sets the site default for the size and/or the presence of the abstract in the feed.  It may be overridden at the list level by the RSS-Abstract-Words= list header keyword.

 

When constructing an implicit abstract, 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, the min and max parameters are ignored and the abstract is whatever the user entered. If the stop-on-paragraph-end feature is not desired, simply set "min" to the same value as "max".

 

If RSS abstracts are not desired, setting the maximum to 0 disables the abstract altogether.

 

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 is not automatic, and must be performed manually by the LISTSERV maintainer.

 

Example

     unix: RSS_ABSTRACT_WORDS="500 250"

     Win:  RSS_ABSTRACT_WORDS=500 250

 

Default Value

Maximum 100, minimum 50.

 

 


RUNMODE

Platforms

All

 

Abstract

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

 

Details

LISTSERV Classic or the non-free edition of LISTSERV Lite 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. Unless you know of a specific LISTSERV backbone site that is willing to allow you to do lookups, you should use SWGATE.LSOFT.COM for the lookup site.

·         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

z/VM: RUNMODE = 'TABLELESS SWGATE.LSOFT.COM'

unix: RUNMODE="TABLELESS SWGATE.LSOFT.COM"

Win:  RUNMODE=TABLELESS SWGATE.LSOFT.COM

 

Default Value

Tableless for all Lite versions, networked for all others. The value cannot be changed under the Lite "Free Edition". Note that if a host is not defined when running in TABLELESS mode, LISTSERV defaults to using the host SWGATE.LSOFT.COM for lookups.

 

Wildcards

Not allowed.


SEARCH_DISABLED

Platforms

All

 

Abstract

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

 

Example

z/VM:  SEARCH_DISABLED = 'The SEARCH command is disabled on this server.'

unix:  SEARCH_DISABLED="The SEARCH command is disabled on this server."

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

Platforms

Windows only

 

Abstract

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

 

Example

Win:  .SD L E:\FTP\LOGS

 

Details

L-Soft does not recommend that the default directory configuration 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.


 

SEARCH_PRELOAD

Platforms

All HPO, version 16.5 and following

 

Abstract

Space-separated list of list names for which search-related files should be preloaded

 

Examples

z/VM: SEARCH_PRELOAD = 'BIGLIST HUGELIST ANOTHERLIST'

unix: SEARCH_PRELOAD="BIGLIST HUGELIST ANOTHERLIST"

      export SEARCH_PRELOAD

Win:  SEARCH_PRELOAD=BIGLIST HUGELIST ANOTHERLIST

 

Details

The SEARCH_PRELOAD feature is a space-separated list of list names for which you want to preload all the files that might be necessary for the fastest possible search experience.  It is set in the site configuration file in the usual way (see Examples) or can be set in the site configuration section of the web interface.

 

The enhanced search engine in LISTSERV 16.5 and following is very fast as long as the data is already in memory. Without SEARCH_PRELOAD, if your search encompasses 1,000 text files and a 100MB compressed index, there will be a very noticeable startup time, at least on conventional drives, every time the search is run.  Naturally, running LISTSERV on expensive server-class SSD drives would speed the process up, but by enabling SEARCH_PRELOAD, the average customer gets a $0.00 solution to the problem, and can put all their “free” RAM to good use instead of leaving it unused.

 

Certain customers have one main list for which they may want to provide the best possible search performance, faster than even Google. With SEARCH_PRELOAD, LISTSERV will load all the relevant files at startup (in the background) and keep them loaded for the fastest possible access.

 

Please see also What's New in LISTSERV Version 16.5 or the general LISTSERV documentation for more information regarding the enhanced search engine.

 

Default Value

Not set.

 

Wildcards

Not allowed.  Each list to be preloaded must be explicitly specified.


SIGNUP_ENCRYPT_PASSWORDS

Platforms

All

 

Abstract

Boolean value determining whether or not personal LISTSERV passwords are encrypted in the SIGNUP files. Available in and turned ON by default starting with 15.5. SEE DOCUMENTED RESTRICTION, BELOW.

 

Example

z/VM: SIGNUP_ENCRYPT_PASSWORDS = 0

unix: SIGNUP_ENCRYPT_PASSWORDS=0

Win:  SIGNUP_ENCRYPT_PASSWORDS=0

 

Details

LISTSERV supports (and has enabled by default) password encryption for its SIGNUP files.

 

DOCUMENTED RESTRICTION FOR LISTSERV PRIOR TO VERSION 15.5: The above means that upgrading an older server to the current version of LISTSERV will encrypt the passwords in your SIGNUP files, which is not backward-compatible with earlier versions of LISTSERV. If you are upgrading to the current version from an earlier version, it is STRONGLY RECOMMENDED that you make a full backup of your LISTSERV installation before upgrading, OR that you disable this feature in your site configuration file BEFORE you upgrade to the current version if you believe that you may have to roll back to the earlier version.  (Earlier versions of LISTSERV will simply ignore the setting at start time, so it is safe to do this.) 

 

Password encryption can be disabled by setting the site configuration variable SIGNUP_ENCRYPT_PASSWORDS (Boolean) to 0. This can be done prior to upgrading, if desired.

 

When SIGNUP_ENCRYPT_PASSWORDS is set to 0, everything works as before -
passwords are kept in plain text, they can be queried with PWC QUERY, and so forth.

 

When SIGNUP_ENCRYPT_PASSWORDS is set to 1, all SIGNUP entries with a password will be irreversibly encrypted. Newly created passwords will be encrypted, and PWC QUERY will still work, but it will not tell you what the password is. The initial encryption process happens as part of the regular SIGNUP file compression. If you have a lot of passwords, then the initial compression will take a bit longer to complete.

 

If you then return to SIGNUP_ENCRYPT_PASSWORDS=0, encrypted passwords will continue to work and PWC QUERY will continue to not show them, while passwords created after disabling encryption will be in plain text, and PWC QUERY will show them to you. There is no way to recover the one-way encrypted passwords. Either the user must use PW REP or the LISTSERV administrator must use PWC REP and change the password if it is lost.

 

Default Value

1, that is, enabled.

 


SMTP_FORWARD

Platforms

Windows, unix

 

Abstract

The Internet hostname 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.

 

By preference, this variable should contain a fully-qualified domain name [FQDN]. Alternately it may contain a dotted-decimal IPv4 IP address, but this is not recommended.

 

Unqualified hostnames are not supported and will result in errors.  If you intend to forward mail to the local host, again by preference, we recommend using the FQDN of the local host, rather than "LOCALHOST".

 

IPv6 addresses are not supported.

 

Example

unix: SMTP_FORWARD="UNIX.XYZ.COM"

Win:  SMTP_FORWARD=UNIX.XYZ.COM

 

Default Value

Unix:           The default is to point to the localhost; however, it is strongly recommended that this parameter be set explicitly with the FQDN of the host.

Windows:    None. This parameter must be set explicitly.

 

Wildcards

Not allowed.

 

See also

SMTP_FORWARD_n

 


SMTP_FORWARD_n

Platforms

Windows, unix

 

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[(opentime-setting)][;failoverhostname]

 

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

 

Examples

There are many different ways to set this keyword. A few examples are given below. Note carefully that the settings shown are Windows-specific; in order to set these on unix servers, be sure to place double-quotes around the setting strings.

 

A typical unix example:              SMTP_FORWARD_1="UNIXSERVER.BAR.COM"

 

To save space, the rest of these examples are in Windows format.

 

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 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), or alternately, a dotted-decimal IPv4 address.  IPv6 addresses are not supported.

 

Under unix, this keyword causes LISTSERV to spawn sub-processes of itself rather than requiring a separate executable.

 

Note: Under Windows 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. Under unix this isn't technically required since synchronous delivery always defaults to the local machine, however we recommend that SMTP_FORWARD= always be explicitly set even under unix.

 

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

 

IPv6 addresses are not supported.

 

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

Platforms

Windows

 

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_RATE_LIMIT

Platforms

All non-z/VM Classic HPO.

 

Abstract

Defines bandwidth limits for the server.  Typically used with delivery pools, but can be used to set a server-wide bandwidth limit.

 

Example

See Details.

 

Details

Requires LISTSERV Classic HPO running on a non-z/VM platform.

 

It is possible to "rate-limit" LISTSERV's output to its SMTP_FORWARD host(s) by defining limits for individual delivery pools (or server-wide if you do not choose to implement separate delivery pools).  This is done by setting the site configuration variable SMTP_RATE_LIMIT appropriately.  For example, the following setting rate-limits the entire server to 12Mbps of throughput to the outbound forwarding host.

 

unix:

SMTP_RATE_LIMIT="12Mbps"

export SMTP_RATE_LIMIT

Win:

SMTP_RATE_LIMIT=12Mbps

 

Using the feature with delivery pools allows the server administrator to limit the impact that large lists or large DISTRIBUTE jobs have on total throughput from LISTSERV to its outbound MTA(s), reserving sufficient bandwidth so that administrative mail and smaller lists can get through at the same time. Thus a more complicated rate-limiting scheme might be as follows:

 

unix:

SMTP_RATE_LIMIT="12Mbps AB:1.5Mbps C:150kbps"

export SMTP_RATE_LIMIT

Win:

SMTP_RATE_LIMIT=12Mbps AB:1.5Mbps C:150kbps

 

In this case, the entire server (including existing delivery pools that have not been otherwise specified) is limited to 12Mbps outbound, while pools A and B are limited further to 1.5Mbps and pool C is limited to 150kbps.  Anything not mentioned is unlimited. In the above example, D is technically unlimited, other than for the overall 12Mbps limit for all traffic.

 

Each outbound message belongs to exactly one pool and is subjected to exactly two rate limits (either of which can be unlimited): the pool rate limit and the overall rate limit. Whichever is strictest at this particular moment sets the bar.

The formal syntax of SMTP_RATE_LIMIT is

 

SMTP_RATE_LIMIT=limit1 [limit2 [...]]

 

limit: [pools:]maxbps

 

pools: any  valid pool names  (as usual, the  default pool is  '-'). When
       specified,  each listed  pool receives  the specified  limit. When
       omitted, the overall rate limit is defined.

 

maxbps: a positive number followed by  'kbps', 'Mbps' or 'Gbps' (case not
        material). No space between the number and 'kbps'.

 

Example:

 

SMTP_RATE_LIMIT=12Mbps AB:1.5Mbps C:150kbps

 

Please note carefully the following:

 

·         A LISTSERV HPO LAK is required.

 

·         LISTSERV's rate-limiting imperatively requires that asynchronous SMTP "workers" (SMTP_FORWARD_n) be used. Results will be unpredictable if used with the deprecated ASYNCH_SMTP option. The fallback SMTP_FORWARD (synchronous) delivery mechanism ignores rate limits.

 

·         The rate limit is specific to LISTSERV. It can be used to limit the rate at which LISTSERV feeds your outbound SMTP MTA, but it does NOT limit the rate at which your MTA feeds messages to the outside world. Rate-limiting your MTA on the outbound side is beyond the ability of LISTSERV to control.

 

·         Rate limiting does not split messages. Any given message is either sent immediately as it is, or delayed. If you have large attachments with MAXBSMTP=10000, you will not get a smooth ride. If you want a smooth traffic graph on your network monitor, make sure that MAXBSMTP is low enough. This being said, it will work either way, correctly and accurately.

 

·         The limit is applied to the size of the message body (including RFC822 headers and CRLF, but not including the RFC821 envelope). This may require that the rates be tweaked somewhat to get the actual desired performance.

 

·         To keep synchronization overhead to a reasonable level, the rate limits are split among participating workers, which work independently as they always have. A little report is written at the beginning of the SMTP worker log. This means you will probably see somewhat less usage than you have requested, especially if you have workers servicing multiple pools. When worker #1 is servicing a large distribution for pool B, its rate quota for pool A is not being used. Worker #2 has no idea what worker #1 is doing and cannot "borrow" its pool A quota during this time. There is a simple solution to that problem: one worker, one rate-limited pool.

 

·         For reference, kilo, mega and giga as used by SMTP_RATE_LIMIT are powers of 2, not 10.

 

Default Value

0, that is, rate-limiting is disabled.


SMTP_RESET_EVERY

Platforms

All

 

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.

 

Example

z/VM: SMTP_RESET_EVERY = 60

unix: SMTP_RESET_EVERY=60

      export SMTP_RESET_EVERY

Win:  SMTP_RESET_EVERY=60

 

Default Value

Not set; connections are not reset unless inactive.

 

 

SMTP_SPAM_CHECK

Platforms

Windows running SMTPL.EXE 1.0w or later for inbound mail

 

Abstract

If SMTPL spam control is enabled, contains the space-separated list of target hostnames to check. Normally this is handled by setting the value to %MYDOMAIN%.

 

Example

Win:  SMTP_SPAM_CHECK=%MYDOMAIN%

 

or

 

Win:  SMTP_SPAM_CHECK=EXAMPLE.COM LISTSERV.EXAMPLE.COM

 

Details

For full information on this feature, please see Section 5, SMTPL-Level Spam Control for Windows, in the LISTSERV Advanced Topics Manual.

 

Default Value

Not set; SMTPL spam control disabled.

 

See also

SMTP_SPAM_EXIT, SMTP_SPAM_THREADS

 


SMTP_SPAM_EXIT

Platforms

Windows running SMTPL.EXE 1.0w or later for inbound mail

 

Abstract

If SMTPL spam control is enabled, contains the space-separated list of target hostnames to check.

 

Example

Win: SMTP_SPAM_EXIT =!C:\LISTSERV\MAIN\REXX.EXE C:\LISTSERV\MAIN\SASMTPL.REXX

 

Details

Change the paths in SMTP_SPAM_EXIT to match your local installation. Ensure that the line begins with an exclamation point (!).

 

For full information on this feature, please see Section 5, SMTPL-Level Spam Control for Windows, in the LISTSERV Advanced Topics Manual.

 

Default Value

Not set; SMTPL spam control disabled.

 

See also

SMTP_SPAM_CHECK, SMTP_SPAM_THREADS

 

SMTP_SPAM_THREADS

Platforms

Windows running SMTPL.EXE 1.0w or later for inbound mail

 

Abstract

If SMTPL spam control is enabled, defines the number of concurrent spam scans that can be executed by SMTPL.

 

Example

Win:  SMTP_SPAM_THREADS=75

 

Details

For the 75 concurrent spam scans configured in the example, 750M-1G of memory will be required.  Depending on available resources, you may want to start lower.

 

For full information on this feature, please see Section 5, SMTPL-Level Spam Control for Windows, in the LISTSERV Advanced Topics Manual.

 

Default Value

Not set; SMTPL spam control disabled.

 

See also

SMTP_SPAM_CHECK, SMTP_SPAM_EXIT


SORT_RECIPIENTS

Platforms

All

 

Abstract

An integer value (0, 1, or 2) that determines whether or not LISTSERV sorts the recipient list in outgoing SMTP jobs. 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.

 

This is an optimization parameter that you would normally set through the Optimization Settings tab in the web administration interface (15.0 and following).

 

Example

z/VM: SORT_RECIPIENTS = 1

unix: SORT_RECIPIENTS=1

      export SORT_RECIPIENTS

Win:  SORT_RECIPIENTS=1

 

Details

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.

 

Note:  This variable setting worked differently 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.

 

Default Value

All platforms except Windows NT:          SORT_RECIPIENTS = 0

Windows NT:                                         SORT_RECIPIENTS = 2

 


SPAM_ALERT

Platforms

All

 

Abstract

Boolean value determining whether or not spam reports are sent to the postmaster.

 

Example

z/VM: SPAM_ALERT = 1

unix: SPAM_ALERT=1

      export SPAM_ALERT

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

 

If it is preferred that the LISTSERV postmaster be cc'd on all spam alerts, this behavior can be enabled by setting SPAM_ALERT=1.

 

Default Value

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


SPAM_DELAY

Platforms

All

 

Abstract

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

 

Example

z/VM: SPAM_DELAY = 15

unix: SPAM_DELAY=15

      export SPAM_DELAY

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

 

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.

 

Default Value

SPAM_DELAY = 10


SPAM_EXIT

Platforms

LISTSERV Classic/Classic HPO on Windows and unix; also z/VM when using the LISTSERV Anti-Virus Server option.

 

Abstract

Sets the name of the user-provided exit program used to call a third-party spam scanner.

 

Example

z/VM: (no setting -- spam scanning is handled by the AVS)

unix: SPAM_EXIT="saexit"

      export SPAM_EXIT

Win:  SPAM_EXIT=SAEXIT

 

Details

This feature is not available in LISTSERV Lite.  A current L-Soft maintenance contract is also required for this feature in LISTSERV Classic and LISTSERV Classic HPO.

 

Please see the full documentation for information on this feature.

 

Default Value

Not set, ie, disabled.


SPAM_FEEDBACK_ACTION

Platforms

All 16.0 and following

 

Abstract

Determines what action(s) to take when LISTSERV receives spam complaints through AOL feedback loops.

 

Example

z/VM: SPAM_FEEDBACK_ACTION = 'DELETE SERVEDROP'

unix: SPAM_FEEDBACK_ACTION="DELETE SERVEDROP"

      export SPAM_FEEDBACK_ACTION

Win:  SPAM_FEEDBACK_ACTION=DELETE SERVEDROP

 

Details

SPAM_FEEDBACK_ACTION determines how LISTSERV should handle spam complaints arriving through AOL Feedback Loops. By default, when a spam complaint is received through an AOL Feedback Loop, LISTSERV will:

 

1.     Immediately delete the AOL user from all LISTSERV lists, on the first spam report. This does not include Dynamic Query Lists, which are managed outside LISTSERV.

2.     Not send any notification to the AOL user.

3.     Log a SPAM_COMPLAINT record to the list's change log, if one has been defined. You can use this information to remove the AOL user from Dynamic Query Lists, if you have any such lists that may contain AOL users.

4.     Serve the AOL user off with the DROP option, which prevents the user from accidentally re-subscribing to the list.

 

This default behavior is equivalent to DELETE SERVEDROP.

 

Possible configuration options, include (all space-separated actions are taken in turn):

 

·         DELETE: The AOL user is deleted from all LISTSERV lists.

·         SERVEOFF: The AOL user is served off.

·         SERVEDROP: The AOL user is served off with the DROP option.

·         NONE: No action is taken other than logging an entry to the list's change log (if defined).

·         LOGALL: An advanced option for customers operating multiple LISTSERV instances, which collects a central copy of all spam reports and forces them to be logged on that instance even if the reports are for another instance.

 

Default Value

SPAM_FEEDBACK_ACTION = 'DELETE SERVEDROP'

 

See Also

SPAM_FEEDBACK_PROBE


SPAM_FEEDBACK_PROBE

Platforms

All

 

Abstract

Determines whether to enable AOL Feedback Loop Auto-Processing.

 

Example

z/VM: SPAM_FEEDBACK_PROBE = 'AOL.COM'

unix: SPAM_FEEDBACK_PROBE="AOL.COM"

      export SPAM_FEEDBACK_PROBE

Win:  SPAM_FEEDBACK_PROBE=AOL.COM

 

Details

SPAM_FEEDBACK_PROBE determines whether to enable AOL Feedback Loop Auto-Processing. AOL's Feedback Loop reports are sent automatically by AOL to organizations that are on AOL's whitelist. Once configured, LISTSERV automatically parses the reports and implements the actions required by AOL's whitelist agreement. This helps preserve whitelist status and reduce the number of spam complaints from AOL users.

 

There are two steps in configuring automatic feedback loop processing. The first is to set this configuration variable to AOL.COM (see the examples above). The second step is to create a LISTSERV list dedicated to feedback loop processing. It can be configured as you wish as long as the special AOL address from which the spam reports are coming is authorized to post to the list. Test the list carefully to make sure that archiving is working properly and that the list will not send any replies back to AOL. Then add Misc-Options= PROCESS_SPAM_FEEDBACK to the list configuration to activate automatic report processing.

 

If the message is recognized as an AOL spam report and it refers to a message originated after you set SPAM_FEEDBACK_PROBE=AOL.COM, LISTSERV will:

 

1.     Immediately delete the AOL user from all LISTSERV lists, on the first spam report. This does not include Dynamic Query Lists, which are managed outside LISTSERV.

2.     Not send any notification to the AOL user.

3.     Log a SPAM_COMPLAINT record to the list's change log, if one has been defined. You can use this information to remove the AOL user from Dynamic Query Lists, if you have any such lists that may contain AOL users.

4.     Serve the AOL user off with the DROP option, which prevents the user from accidentally re-subscribing to the list.

 

This ensures that no further mail will be sent to the AOL user and minimizes the risk for further complaints (although experience has shown that AOL users often find old messages in their mailbox days or weeks later, which can lead to a handful of additional spam reports). In the future, other ISPs may be supported, but for now only AOL is supported.

 

In addition, the SPAM_FEEDBACK_ACTION site configuration variable may be used to customize LISTSERV's reaction to an AOL Feedback Loop report.

 

Default Value

Not set, ie, disabled.

 

See Also

SPAM_FEEDBACK_ACTION


SPAM_MAXSIZE

Platforms

All

 

Abstract

Sets the maximum size, in kilobytes, of any message to be handled by the spam scanner.  Messages over the specified size are not scanned.

 

Example

z/VM: SPAM_MAXSIZE = 512

unix: SPAM_MAXSIZE=512

      export SPAM_MAXSIZE

Win:  SPAM_MAXSIZE=512

 

Details

Related to SPAM_EXIT. Please see the full documentation for information on this feature.

 

Default Value

256 (ie, 256KB).

 


Spam Blacklists and Whitelists

 

Platforms

All LISTSERV Classic/Classic HPO.

 

Abstract

Sets up blacklists and whitelists to help combat spam.

 

Examples

See below, in Details.

 

Requirements

This feature is not available in LISTSERV Lite.  A current L-Soft maintenance contract is also required for this feature in LISTSERV Classic and LISTSERV Classic HPO.

 

In order for LISTSERV to use the blacklists and whitelists, SPAM_EXIT must be enabled and pointed to an existing, external exit program. This is necessary because the white- and blacklisting feature is part of LISTSERV's overall anti-spam toolbox, which is only activated if SPAM_EXIT is enabled.

 

While you may of course use the exit program you write to submit inbound mail to an external spam filter for scanning, that is not mandatory. In that case, the exit program does not need to do anything other than exit immediately with a return code of zero.  For example:

 

Windows:

site.cfg setting:

SPAM_EXIT=SAEXIT

 

x:\listserv\main\saexit.cmd :

rem don't do anything, just go back to LISTSERV

exit 0

Unix:

go.user setting:

SPAM_EXIT="SAEXIT"

export SPAM_EXIT

 

~listserv/home/SAEXIT :

# don't do anything, just go back to LISTSERV

exit 0

 

Details

LISTSERV includes a whitelist/blacklist system that can be used either on its own, or in conjunction with the spam exit feature (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. In addition to the white/blacklists themselves, another site configuration variable, SPAM_WHITELIST_BOUNCE, is available. 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:

z/VM:    SPAM_BLACKLIST_FROM = '*@PUBLIC.EXAMPLE.COM >JAMES@EXAMPLE.COM'

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

       export SPAM_BLACKLIST_FROM

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

 

SPAM_WHITELIST_BOUNCE examples:

z/VM:  SPAM_WHITELIST_BOUNCE = 1

unix:  SPAM_WHITELIST_BOUNCE=1

      export SPAM_WHITELIST_BOUNCE

Win:    SPAM_WHITELIST_BOUNCE=1

 

See Also

SPAM_EXIT

 


 

SPOOL_CLEANUP

Platforms

All 16.0-2017a and later

 

Abstract

Specifies how often, in days, LISTSERV will automatically clean old files from its SPOOL directory.

 

Example

z/VM:  SPOOL_CLEANUP = 7

unix:  SPOOL_CLEANUP=7

      export SPOOL_CLEANUP

Win:    SPOOL_CLEANUP=7

 

Details

SPOOL_CLEANUP has been added to help automate clearing old files from the spool that should not be kept indefinitely.  The keyword takes a single integer value denoting the number of days between cleanups, and setting it to 0 disables it.  The default is 30 days.

 

The keyword is not explicitly editable in the web administration interface, but can be added by using the "Find or Add Configuration Variable" search box at the top of the Site Configuration page.  Once added, the keyword becomes available and editable in the My Configuration tab.

 

Alternately, the keyword can be set in LISTSERV's main site configuration file as usual.

 

In LISTSERV 16.0-2017a, enabling the feature targets only .ERROR files found in the spool directory.  In future versions, the feature may target other types of files.

 

Default Value

30 (days)

 


STOREPW

Platforms

z/VM

 

Abstract

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

 

Example

STOREPW= 'almighty'

 

Details

If you do not want to allow remote file storing nor remote CP/CMS command execution, just set this variable to ''. Note that CP/CMS commands typed at the server's console will always be honored.

 

Although this variable is available under non-z/VM versions of LISTSERV, for non-z/VM it is functionally equivalent to CREATEPW and should simply be left unset.

 

This setting is obsolete and deprecated, as all POSTMASTER-restricted commands can now be validated with the postmaster's personal password.  Setting STOREPW to the special value *NOPW* tells LISTSERV to disable STOREPW entirely.

 

See also

CREATEPW

 


SYSTEM_CHANGELOG

Platforms

All Classic and Classic HPO

 

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 (original Boolean syntax, deprecated)

z/VM: SYSTEM_CHANGELOG = 1

Unix: SYSTEM_CHANGELOG=1

      Export SYSTEM_CHANGELOG

Win:  SYSTEM_CHANGELOG=1

 

Example (current syntax)

Unix: SYSTEM_CHANGELOG="YEARLY"

      export SYSTEM_CHANGELOG

Win:  SYSTEM_CHANGELOG=WEEKLY

 

Change-log rotation is not supported under z/VM.

 

Details

LISTSERV Classic or Classic HPO includes this feature. If enabled, a file called system.changelog (SYSTEM CHANGELG on z/VM) is created and written to in LISTSERV's A directory (or on the A disk for z/VM) 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.

 

Originally, the SYSTEM_CHANGELOG value was a binary "on/off" setting. Under non-z/VM ports of LISTSERV, the system changelog can also 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.

 

Changelog rotation is not supported under z/VM due to the filesystem restriction of 8-character file extensions; while the command processor will not complain if you set SYSTEM_CHANGELOG = 'MONTHLY', the behavior will always be as if you had specified 1 or 'SINGLE'.

 

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

 

Default Value

0 (ie, disabled)

 


TCPGUI_IPADDR

Platforms

Non-z/VM

 

Abstract

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

 

Example

unix: TCPGUI_IPADDR="101.231.8.1"

      export TCPGUI_IPADDR

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

 

IPv6 addresses are not supported.

 

Default Value

Defaults to the primary IP address of the LISTSERV machine.

 

Wildcards

Not allowed.

 

See also

TCPGUI_PORT

 


TCPGUI_PORT

Platforms

Non-z/VM

 

Abstract

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

 

Example

unix: TCPGUI_PORT=23006

      export TCPGUI_PORT

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

Platforms

All

 

Abstract

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

 

Example

z/VM: TRAPIN = 'OBNOX@SOMENODE.NET *@BADNODE.COM'

unix: TRAPIN="OBNOX@SOMENODE.NET *@BADNODE.COM"

Win:  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 z/VM sites, but is available for the convenience of z/VM customers migrating to other platforms and should not need to be set by typical non-z/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.

 

Beginning with LISTSERV 16.5, the contents of TRAPIN are evaluated during any call to the X-CONFIRM message generator, as one of two improvements added to help prevent spammers from generating "backscatter" messages by using the anonymous list subscription form in LISTSERV's web interface.

 

(A second, related improvement in 16.5 is to summarily reject any anonymous subscription request where the Name: field contains a URL (or more specifically, the string "://").  We mention this only in passing as it otherwise has nothing to do with the change made in 16.5 to TRAPIN.)

 

Default Value

Built in.

 

Wildcards

Allowed.

 

See also

TRAPOUT

 


TRAPOUT

Platforms

All

 

Abstract

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

 

Example

z/VM: TRAPOUT = 'OBNOX@SOMENODE.NET *@BADNODE.COM'

unix: TRAPOUT="OBNOX@SOMENODE.NET *@BADNODE.COM"

Win:  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 z/VM sites, but is available for the convenience of z/VM customers migrating to other platforms and should not need to be set by typical non-z/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

Platforms

LISTSERV Classic HPO only

 

Abstract

(HPO only) 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)

 

 

 

UODBC_*

Platforms

LISTSERV Classic/Classic HPO under unix only.

 

Details

Three configuration variables under the UODBC_* rubric are available for use with LISTSERV's DBMS/Mail Merge functionality. Please see the Developer's Guide for LISTSERV (available separately) for documentation.

 


USE_LSMTP_MAIL_MERGE

Platforms

Non-z/VM.  Obsolete.

 

Abstract

 

This setting is obsolete as of LISTSERV 14.5.  Sites requiring mail-merge performance improvements should use EMBEDDED_MAIL_MERGE instead.

 

See also

EMBEDDED_MAIL_MERGE, SMTP_FORWARD, SMTP_FORWARD_n

 


VM_STYLE_INDEX

Platforms

All non-z/VM

 

Abstract

Boolean value determining the format of the response to the QUERY FILE command.

 

Example

unix: VM_STYLE_INDEX=1

export VM_STYLE_INDEX

Win:  VM_STYLE_INDEX=1

 

Details

The sample output of QUERY FILE is normally something like this:


DEFAULT       DKIM            N/A CTL          727 2005-11-25 16:56:25

or:

DEFAULT       DKIM            N/A CTL            . .......... ........

if the file is defined but does not exist.  Note that certain files (including DKIM files) are defined implicitly by LISTSERV and do not necessarily need an explicit entry in a CATALOG or FILELIST file in order for LISTSERV to know about them.

 

That is the default non-z/VM query format, but customers with old z/VM scripts that utilized LISTSERV's file server functions can also choose the old z/VM query format, which results in the following sample output:


SERVICE  NAMES      ALL LMC V      65   248 05/01/13 15:17:55
DOMAIN   NAMES      ALL LMC .       0     0 ........ ........

Choosing the query format is done by setting the Boolean value VM_STYLE_INDEX in the site configuration (note that this setting centrally affects all file server commands, not just QUERY FILE).  To use the z/VM query format, set VM_STYLE_INDEX to 1. To use the default non-z/VM style format, set VM_STYLE_INDEX to 0 (or remove from, or comment out the variable in, the site configuration file).

 

Default Value

VM_STYLE_INDEX=0


 

WA_USE_INSECURE_COOKIE

Platforms

All 16.5 and later

 

Abstract

Boolean value determining whether LISTSERV favors login cookies containing plain-text passwords or not.  (Default is 0, i.e., "not").

 

Example

unix: WA_USE_INSECURE_COOKIE=1

      export WA_USE_INSECURE_COOKIE

Win:  WA_USE_INSECURE_COOKIE=1

 

Details

Prior to LISTSERV 16.5, WA login cookies contained an unencrypted e-mail address; a masked but unencrypted password (which, should the cookie be opened by accident, would appear to be garbage, but still was not encrypted); and an array of flags indicating whether the user is a list owner, admin, moderator, and the RUNMODE of the server.

 

LISTSERV 16.5 introduced a new secure WA login cookie feature.  Going from an insecure to a secure WALOGIN cookie is completely transparent to the user, and should be used by all LISTSERV installations.  As it is the default in 16.5 and later, nothing needs to be done to configure it.

 

The feature is controlled by the WA_USE_INSECURE_COOKIE configuration variable.  The variable is set like any other LISTSERV configuration variable, and LISTSERV publishes it in SYSTEM.WWWTPL for WA to see and act on.

 

With WA_USE_INSECURE_COOKIE=1, WA is instructed to favor cookies containing the plain-text password and, being also aware of that, LISTSERV does not bother to generate secure one-time passwords, and it all basically works as before.

 

With WA_USE_INSECURE_COOKIE=0 (the default), things get more interesting.

 

The first time through, WA will login using its plain-text password cookie. The design decision was not to bother the user with a login prompt when the password is already available and has already been sent over the net. So, as usual WA does:

 

17 Apr 2018 12:59:34 From [ANONYMOUS]: X-LOGIN joe@example.com 10.123.231.30 PW=[redacted]

 

Next, LISTSERV automatically generates a one-time secure password and volunteers it to WA for future use. WA does not have to use it, but it will because WA_USE_INSECURE_COOKIE=0.

 

17 Nov 2013 12:59:34 To   [ANONYMOUS]: ***OK*** PFA2F8FA92A1E2A4810 [redacted]

 

As before, the one-time password is redacted, but it looks something like this if you run in debugging mode:

 

XnkXjHxDmn+bJEYXTTVJBg

 

WA now sees the one-time password and overwrites it into the WALOGIN cookie, still in plain text, but this password has two special properties. First, XnkXjHxDmn+bJEYXTTVJBg is not the user’s online bank password, or any other password the user might be using in an "overloaded" manner.  The second special property of this password is that it can be used only once, and only from the same IP address.

So let’s say that a hacker got his hands on this password via an XSS attack. He can try the password all he wants, but from a different IP address it simply won't work. He has to hack your computer in order to use the password – and (in most cases) he only has 15 minutes at the most. In 15 minutes your ticket will expire and you will use the one-time password to obtain a new ticket, which will invalidate the one-time password forever.

 

The next time WA needs to log in, it will use the one-time password as follows:

 

17 Nov 2013 14:17:57 From [ANONYMOUS]: X-LOGIN joe@example.com ONETIME 212.247.27.231 PW=[redacted]

17 Nov 2013 14:17:57 To   [ANONYMOUS]: ***OK*** OPF36ABF742466929D97 [redacted]

 

The ONETIME option simply states that the supplied password is a one-time password and should not be attempted as a real password (so as not to lock people out if using LDAP for password validation). LISTSERV returns a new one-time password to replace the one that just expired.  The cookie is updated. Note that the ticket starts with O, indicating a ticket obtained from a one-time password.

 

The one-time passwords are stored as a user configuration variable called *ONETIME*. You can query its existence but not see its contents.

 

17 Nov 2013 14:34:11 From LISTSERV@LISTSERV.EXAMPLE.COM: x-logck x getcfg: *

* ***OK***

* *ONETIME*=[redacted]

 

As previously noted, one-time passwords are tied to the IP address they are issued to. A user can have up to 5 active one-time passwords, for either the same or different IP addresses, and they all exist independently of each other. So, if you use both IE and Chrome, they can each have their own one-time password that keeps being replaced. And your laptop or phone can have its own too, up to the maximum of 5.

 

If tying one-time passwords to IP addresses is problematic for you, which it is bound to be if you have a lot of subscribers from every possible type of organization, you can set WWW_ONETIME_PW_ROAMING=1 to create one-time passwords that are not bound to any IP address and are thus less secure, but still not the user’s online banking password. Note that if you later revert to WWW_ONETIME_PW_ROAMING=0, the unbounded passwords will stop working – the configuration option trumps the wildcard in the password record.

 

Finally, LISTSERV login tickets are now generated cryptographically, by the operating system's internal cryptographic functions.

 

Default Value

WA_USE_INSECURE_COOKIE=0

 

See Also

WWW_ONETIME_PW_ROAMING


WEB_BROWSER_CONFIRM

Platforms

All

 

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.

 

Example

z/VM: WEB_BROWSER_CONFIRM = 1

unix: WEB_BROWSER_CONFIRM=1

      export WEB_BROWSER_CONFIRM

Win:  WEB_BROWSER_CONFIRM=1

 

Details

To enable this feature, set WEB_BROWSER_CONFIRM=1 in the site configuration file.

 

This feature is disabled (set to 0) by default.

 

Default Value

WEB_BROWSER_CONFIRM = 0

 


 

WWW_ALLOW_LEGACY_INTERFACE

Platforms

Non-VM 17.0 and later

 

Abstract

Numeric value determining whether the site, and by extension, individual lists, may continue operating in legacy 16.5 "compatibility mode".

 

Example

Unix: WWW_ALLOW_LEGACY_INTERFACE=0

Win:  WWW_ALLOW_LEGACY_INTERFACE=0

 

Note for Unix:  WWW_ALLOW_LEGACY_INTERFACE has been pre-exported in the "go" script which ships with LISTSERV 17.0 and does not need to be exported separately in go.user.

Details

WWW_ALLOW_LEGACY_INTERFACE allows the site administrators to decide whether the site, and by extension, individual lists, may continue operating in legacy 16.5 "compatibility mode". The options are as follows (the default value is in bold):

WWW_ALLOW_LEGACY_INTERFACE=0

The web interface operates in 17.0 "native mode", and the 16.5 legacy interface is not allowed. This should be the standard setting once migration to the new interface is complete.

 

This will be the default in the next version of LISTSERV.

WWW_ALLOW_LEGACY_INTERFACE=1

The web interface operates in 17.0 "native mode", but the 16.5 legacy interface is allowed, either for the whole site or on a list-by-list basis.

 

This is the default for 17.0.

WWW_ALLOW_LEGACY_INTERFACE=2

The web interface operates in 16.5 "compatibility mode". The 17.0 interface is not allowed, and all new 17.0 features in the interface are disabled. This setting is supported only with OLD_WEB_INDEXES=2.

 

This is a compatibility mode only.


While there are three available settings each for the two new variables, it should be noted carefully that not all combinations are supported. Following is a compatibility matrix indicating which combinations are supported (green), supported for special situations (yellow) and unsupported (red):

OLD_WEB_INDEXES=0
(default)

WWW_ALLOW_LEGACY_INTERFACE=0

Supported

 

Standard setting once migration to the new interface is complete. This will be the default in the next version.

WWW_ALLOW_LEGACY_INTERFACE=1

Supported

 

Default setting for 17.0. This setting allows staged migration to the new interface.

WWW_ALLOW_LEGACY_INTERFACE=2

Unsupported

 

Degraded functionality.

OLD_WEB_INDEXES=1

WWW_ALLOW_LEGACY_INTERFACE=0

Unsupported

 

Maintaining both old and new indexes only makes sense if both interfaces are allowed.

WWW_ALLOW_LEGACY_INTERFACE=1

Special Situation

 

This setting can be used if some lists need to use the old interface for a long time. However, rebuilding both sets of list indexes for lists with very large archives can slow down the server.

WWW_ALLOW_LEGACY_INTERFACE=2

Unsupported.


Maintaining both old and new indexes only makes sense if both interfaces are allowed.

OLD_WEB_INDEXES=2

WWW_ALLOW_LEGACY_INTERFACE=0

Unsupported


Degraded functionality.

 

WWW_ALLOW_LEGACY_INTERFACE=1

Unsupported


Degraded functionality when selecting the new interface.

WWW_ALLOW_LEGACY_INTERFACE=2

Level Set Mode


New features are disabled and 17.0 is used as a bug fix update only.


The combinations highlighted in red are not supported and will not be discussed further. The combinations highlighted in yellow are supported but not recommended for general use.

Default Value

1

 

See also

OLD_WEB_INDEXES

List level setting Misc-Options= LEGACY_INTERFACE

What's New in LISTSERV Version 17.0


WWW_ARCHIVE_CGI

Platforms

Unix, Windows

 

Abstract

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

 

Examples

unix: WWW_ARCHIVE_CGI="/cgi-bin/wa"

      WWW_ARCHIVE_CGI="http://listserv.example.com/cgi-bin/wa"

      export WWW_ARCHIVE_CGI

Win:  WWW_ARCHIVE_CGI=/scripts/wa.exe

      WWW_ARCHIVE_CGI=http://listserv.example.com/scripts/wa.exe

 

Details

This value is preferably a relative URL, but in some cases (eg where the LISTSERV host name is an MX but not an A in DNS and thus cannot be resolved by a browser) it may be necessary to define this as an absolute URL including the A record hostname. If using SSL or a non-standard port it is also necessary to use the absolute URL.

 

Default Value

Null.

 

Wildcards

Not allowed.

 

See also

WWW_ARCHIVE_DIR

 


WWW_ARCHIVE_DIR

Platforms

Unix, Windows

 

Abstract

The full OS path name to the WWW archive directory

 

Examples

unix: WWW_ARCHIVE_DIR="/usr/local/etc/httpd/htdocs/archives"

Win:  WWW_ARCHIVE_DIR=c:\inetpub\wwwroot\archives

 

Default Value

Null.

 

Wildcards

Not allowed.

 

See also

WWW_ARCHIVE_CGI

 

WWW_AUTHINFO_DISABLE

Platforms

Unix, Windows

 

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.

 

Example

unix: WWW_AUTHINFO_DISABLE=0

Win:  WWW_AUTHINFO_DISABLE=0

 

Details

The default 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. If the minimum security exposure noted above is unacceptable, this variable can be set to 0 (i.e., enable the authorization).

 

Default Value

WWW_AUTHINFO_DISABLE = 1

 

 


 

WWW_HSTS_MAX_AGE

Platforms

Unix, Windows

 

Abstract

Long integer value which sets the maximum age limit (in seconds) for the HTTPS Strict-Transport-Security header.

 

Example

unix: WWW_HSTS_MAX_AGE=31536000

      export WWW_HSTS_MAX_AGE

Win:  WWW_HSTS_MAX_AGE=31536000

 

Details

When set to a non-zero value, causes WA to output the header "Strict-Transport-Security: max-age=x", where "x" is the non-zero variable setting representing the number of seconds the STS header will persist in a user's cache (unless the user clears their cache before that time).  The value 31536000 shown in the example represents 365 days or one year.

 

This is intended primarily to address DHS directive BOD 18-01, but will enhance security for any LISTSERV site which uses the HTTPS protocol in the LISTSERV web interface.

 

It is important to note that WA functions named DEBUG-* (e.g., DEBUG-SHOW-VERSION) do not load the configuration file, and therefore will not output the Strict-Transport-Security: header.

 

Also note that if you already have the webserver configured for HSTS, the webserver HSTS value will preferentially override the setting provided by WA.  The LISTSERV setting is provided for situations where the entire website is not already configured for HSTS but it is desired to use HSTS with LISTSERV.

 

With HSTS enabled site-wide in IIS, you may find that:

 

- The "archives" directory no longer works correctly if it is implemented as an IIS virtual directory

 

- Some images served by WA.EXE may be broken

 

WWW_HSTS_MAX_AGE can be used to solve this problem rather than enabling site-wide HSTS in IIS.

 

Default Value

WWW_HSTS_MAX_AGE=0 (i.e., disabled)


 

WWW_ONETIME_PW_ROAMING

Platforms

Unix, Windows; 16.5 and later.

 

Abstract

Boolean value which, when enabled, allows creation of "roaming" one-time passwords for the web interface which are not tied to IP addresses.

 

Example

unix: WWW_ONETIME_PW_ROAMING=1

      export WWW_ONETIME_PW_ROAMING

Win:  WWW_ONETIME_PW_ROAMING=1

 

Details

WWW_ONETIME_PW_ROAMING modifies the behavior of one-time password creation when WA_USE_INSECURE_COOKIE is set to its default (0, i.e., disabled).  For details, please see the documentation for WA_USE_INSECURE_COOKIE.

 

Default Value

WWW_ONETIME_PW_ROAMING=0

 

See Also

WA_USE_INSECURE_COOKIE


WWW_SHOW_SUBSCRIBER_COUNT

Platforms

Unix, Windows

 

Abstract

A Boolean value which can be set to 0 to disable the display of subscriber counts for al lists listed on the main web archive index page.  The feature is enabled (set to 1) by default.

 

Example

unix: WWW_SHOW_SUBSCRIBER_COUNT=0

      export WWW_SHOW_SUBSCRIBER_COUNT

Win:  WWW_SHOW_SUBSCRIBER_COUNT=0

 

Details

By default, the LISTSERV web interface displays the number of subscribers as part of the list title on the main archive index page.  For instance, the title may appear like this:

 

Discussion list for Turkish Van Cat Fanciers (2191 Subscribers)

 

If desired, this feature may be disabled site-wide by setting the WWW_SHOW_SUBSCRIBER_COUNT variable to 0.  If this is done then after a reload the index page entry would look like this:

 

Discussion list for Turkish Van Cat Fanciers

 

As noted, this is a site-wide setting and cannot be overridden at the list level.

 

Default Value

WWW_SHOW_SUBSCRIBER_COUNT = 1

 

 

XFERTO

Platforms

z/VM

 

Abstract

Userid of the virtual machine to which files found in the lists readers should be transferred. This is part of the VM/ISF support and should NOT be changed on a regular SP or HPO system.

                             

Example

XFERTO = 'LSTMAINT'

 

Default Value

Standard value.

 

Wildcards

Not allowed.