Description of the changes for release 1.8c of LISTSERV(R)
----------------------------------------------------------
Copyright 1996,1997 L-Soft international, Inc.
January 20th, 1997
*************************************************************************
********************** LISTSERV maintainer's notes **********************
*************************************************************************
The release notes for version 1.8c of LISTSERV(R) have been split into
two documents: list owner's notes and LISTSERV maintainer's notes. The
present LISTSERV maintainer's notes describe changes that are specific to
server or host machine configuration, or too technical to be included in
the list owner's notes. LISTSERV maintainers should also read the owners'
notes.
**************
* Highlights *
**************
- A new, 265-page site maintainer's guide is now available.
- (non-VM) Hierarchical file server functions are now available for the
NT, unix and VMS versions of LISTSERV. While remaining compatible with
the 1.8b file server functions, this new system makes it possible for
the LISTSERV maintainer to create individual sub-catalogs which list
owners can then manage without assistance. Refer to the site
maintainer's guide for more information.
- (non-VM) Web archive interface allowing users to browse list archives
interactively. This includes a WWW interface to the new database
functions with online help.
- Automatic detection of "spoofed subscription" to lessen impact on both
victims and LISTSERV host system. Subscriptions accepted during the
detection phase are automatically undone once an alert is raised,
without affecting unrelated mailing lists to which the victim was
already subscribed.
- New table-less and standalone modes of operation for non-backbone
Internet sites and for "Intranet" sites.
- (non-VM) BITEARN NODES now maintained via the PUT mechanism, without
maintainer intervention.
**********************************************
* Documentation: New site maintainer's guide *
**********************************************
A comprehensive, 265-page site maintainer's guide is now available
online. A plain text version is included with the 1.8c update, replacing
the old "INFO POSTMASTER" document. You can also FTP a copy of the new
manual from FTP.LSOFT.COM, CD DOCUMENTS. The file is available in a
variety of word processing formats - check the FTP server for more
information.
***********************************
* Operating system specific notes *
***********************************
- VM: version 1.8c introduces support for CMS release 12.
- VMS (VAX): to reduce development costs in light of the dwindling number
of VAX customers, L-Soft is switching from VAX C to DEC C with version
1.8c. Thus, the DEC C RTL is now a pre-requisite for the VAX version of
LISTSERV. This RTL is included with VMS 6.0 or higher, and can also be
installed as a no-charge component on top of VMS 5.5-2 or higher.
Please refer to the DEC C installation guide for more information.
- NT: customers running version 4.0 are strongly urged to install Service
Pack 1, which contains fixes for problems that can seriously impact
LISTSERV.
- unix (Linux): version 1.8c ships with ELF binaries, as most current
Linux distributions ship with a.out support disabled by default. You
may need to upgrade your kernel to a a version supporting ELF before
you can install 1.8c.
- unix (all systems): the kits for version 1.8c now include both object
files (xxx.o) and precompiled executables, for the benefit of unix
customers who do not have a C compiler. By default, the makefile will
assume that a C compiler is available. Please refer to the installation
guide for more information on how to select the pre-compiled
version.
**************************
* External compatibility *
**************************
Release 1.8c is generally compatible with 1.8b, from the perspective of
the end-user (including list managers and maintainers), and with the
exception of the changes listed below. Release 1.8c also introduces
changes to LISTSERV internals, making compatibility with locally
developed extensions or local modifications problematic. These changes
are briefly described in the next section, and only affect sites which
made alterations or additions to the LISTSERV code. Changes which affect
all LISTSERV sites are highlighted below; note that more details are
available, when appropriate, from the longer descriptive section of these
release notes.
1. A number of changes to list keyword defaults and to the LIST and
SUBSCRIBE commands were made in order to fight "spamming" and
"spoofing". These changes are described in the list owner's release
notes.
2. The addition of MIME digest support and automatic detection of MIME
user agents at SUBSCRIBE time introduces a change to the format of
digests sent to MIME-enabled users. Users can revert to the old
digest format with the (new) 'SET xxx NOMIME' command. See the list
owner's notes for more information.
3. LISTSERV now decodes MIME messages sent to the LISTSERV address (but
not those sent to the list addresses) before processing them. In most
cases, this will allow correct processing of LISTSERV requests which
used to be rejected by 1.8b, for instance because they were base64
encoded. In some cases, however, it can lead to LISTSERV rejecting
MIME messages with proprietary text-like formats when the requests
previously happened to work. LISTSERV requests should be sent in
plain text format whenever possible.
4. LISTSERV now requires 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 change was made both to avoid abuse and because
many occasional WWW users do not know their e-mail address or enter
it incorrectly, whereas people who use e-mail regularly do of course
have a working e-mail address in their configuration. This change can
be disabled by setting the WEB_BROWSER_CONFIRM option to 0 in your
server configuration.
5. The posting acknowledgement message ("Your message dated ... has been
successfully distributed to the ... list") has been modified to
include DIGEST and INDEX recipients in the recipient count. Even
though the message was not actually distributed to the recipients in
question, users found the discrepancy between the recipient count and
the number of actual subscribers confusing. Note that NOMAIL
subscribers are still not counted as they have not been sent a copy
of the message in any form.
6. The restriction about the use of the "OK" confirmation mechanism with
commands such as ADD IMPORT has been lifted in version 1.8c. Users
may now confirm these commands normally, and there is no longer any
need to temporarily change the list configuration to allow their
execution. However, the so-called "OK kludge" which some list owners
used to bypass the 1.8b restriction will no longer work.
7. The "TO" command prefix has been renamed to "MAILTO" as it would tend
to generate unwanted bounces to the maintainer when processing
certain vacation messages.
8. The 'To:' field in LISTSERV-style headers has been modified to remove
the historical "Multiple recipients of list" message. The field now
reads 'To: [log in to unmask]
9. (VM) The INDEX subscription option now uses the new GETPOST command,
rather than a database job. The GETPOST command requires less
resources and is easier to use for non-technical users. Users may of
course continue to use their own database jobs to access the list
archives. The old behaviour can be restored by adding
'INDEX_VIA_GETPOST = 0' to LOCAL SYSVARS.
Release 1.8c is to be installed directly on top of the base 1.8b code,
and includes all known fixes as of the build date.
IMPORTANT: unix(R) customers should retrieve BOTH common.tar.Z and
`uname`.tar.Z, and use the 'make update' stage to update their system.
**************************
* Internal compatibility *
**************************
A number of changes have been made to LISTSERV internals. The most
important ones are briefly described below; refer to the LSTSRV-L
archives for more information.
1. The format of columns 81-100 of the LIST file had to be changed to
permit the introduction of new options. The old format is still
accepted as input and entries are not converted to the new format
until they are modified, to minimize disruption in case you should be
forced to fall back to 1.8b.
2. (unix) The main 'lsv' process may occasionally fork a second 'lsv'.
This is a normal condition; do not kill the child process.
**************************
* Compatibility warnings *
**************************
This section describes planned changes which may affect compatibility
(both external and internal). The release in which the change is planned
to be introduced is indicated, with the letter 'x' denoting an unknown
release of the specified major version (not necessarily posterior to the
last release explicitly mentioned). Note that conversion of REXX files to
PREXX is assumed to take place with each new release and is not indicated
here.
- (1.8x) The data currently in AFDLIST and FUILIST FILE will be moved to
the signup files.
- (1.8x/VM) The FILELIST/FILEID files will be replaced with new CATALOG
files. Applications which alter them directly will no longer work.
- (1.8x) The internal format of LIST and STATS files will change
dramatically. Applications which alter them directly will no longer
work.
- (1.8x/VM) LSVFRD1 and LSVFWR1 will be removed eventually. You should
avoid using these utilities.
*************************************************
* (non-VM) Usability: New web archive interface *
*************************************************
Version 1.8c introduces a WWW archive interface that allows users to
browse and search list archives (the LISTSERV maintainer controls which
lists are or are not visible through this interface). Postings can be
organized by date, by topic or by author, and a search function with
online help is provided. LISTSERV's WWW interface has the following
advantages over "hypermail" style web archiving:
- The information on the web is always up to date. New postings are shown
as soon as they are received.
- The postings can be organized in the manner that best suits the reader:
by date, by author, by topic, with or without table of contents, with
or without showing the author, etc.
- Only one copy of the information is kept, and in particular there is no
need to create an individual HTML file for each posting. This design
allows the interface to scale up gracefully to lists with hundreds of
thousands of archived postings, which would otherwise require hundreds
of thousands of individual HTML files, wasting disk space (each file
takes up at least one disk block) and stressing the file system past
reasonable limits.
- The search forms can be used to create search requests matching all
postings in the last X days. The resulting URL can then be bookmarked
and reloaded on a regular basis.
- List owners can customize the main page for their lists without any
intervention by the LISTSERV maintainer, by updating one of the mail
templates for their list. The LISTSERV maintainer can customize common
pages and header/trailer HTML statements by updating system mail
templates.
Please refer to the new site administrator's guide for information on how
to install and configure this interface.
(VM) The WWW interface is not currently available for VM because L-Soft
does not want to invest in a solution for the currently available
(single-connection) web servers. L-Soft believes that these servers will
become obsolete as soon as web servers supporting multiple connections
become available for VM, and that it is not a good use of L-Soft
resources to invest in the development of a single-threaded REXX CGI
stage at this point. However, the VM version of LISTSERV does have the
necessary programming to support the web archive interface; the missing
component is the CGI stage. Please contact L-Soft if your organization
would be interested in developing this function through a joint study.
*******************************************************************
* Usability/Security: Automatic password generation for new lists *
*******************************************************************
To simplify the creation of new lists, LISTSERV now generates a random
16-character list password when a list is created without a "PW=" keyword
being specified in the list header. This randomly generated password is
not disclosed to the maintainer or list owner and acts as a placeholder,
providing a seed (together with other list attributes) for various
internal cryptographic functions used to protect mechanisms such as
"Send= Editor,Hold". L-Soft recommends that list creation procedures be
updated to omit the "PW=" keyword and let LISTSERV generate a random
password.
Historically, list passwords have been used by list owners to confirm
privileged commands. This practice was made obsolete in December 1986
with the introduction of personal passwords, which allowed list owners to
manage all their lists with a single, personal password. The list owners,
however, had grown used to list passwords and continued to use them. They
taught new list owners to use list passwords and, 10 years later, there
are still a lot of list owners using list passwords rather than personal
passwords (and this will of course remain possible with version 1.8c).
However, with the exception of peered lists (which must share a common
list password to synchronize peering operations), list passwords no
longer serve any useful purpose. They complicate list creation because
someone must choose and assign a password for the list and, since this
password allows list management operations to be carried out, it must be
kept confidential and must be communicated to the list owner using
reasonably safe channels. The personal password, on the other hand, is
chosen by the list owner (through the PW ADD command) and must undergo
the 2-way "OK" confirmation procedure before it is enabled. Random,
unguessable list passwords make list creation simpler and safer.
Again, customers who prefer to use list passwords can continue to do so.
The random password change is compatible in that it only takes effect if
no password was provided when creating the list, which previously was an
error condition.
**********************************************************
* (non-VM) Serviceability: BITEARN NODES updated via PUT *
**********************************************************
Starting with version 1.8c, the BITEARN NODES file used by registered
networked servers will be updated using the same mechanism as PEERS NAMES
and other LISTSERV tables. This however requires that your mail server
support incoming files of at least 1.5M. VM sites have not been included
as they typically maintain this file using the UPDNODES procedure and
store it on a public disk, applying change control procedures in the
process.
****************************************************
* (VMS/NT) Serviceability: Crash/exception reports *
****************************************************
Following a severe system crash, LISTSERV will now generate a "crash
report" containing:
- System-specific information about the immediate cause of the crash
(access violation, division by zero, etc).
- A traceback showing what LISTSERV was doing at the time of the crash.
- The last 100 lines in the LISTSERV log.
By default, this report is mailed to the LISTSERV maintainer. You can
change the destination of these reports by adding a CRASH_MONITOR
variable to your configuration file (SITE.CFG for NT, SITE_CONFIG.DAT for
VMS) with the e-mail addresses to which the report should be mailed. Note
that CRASH_MONITOR replaces the entire recipient list, so make sure that
all the necessary addresses are listed. This configuration variable
follows the same syntax rules as POSTMASTER. Please do not add L-Soft
mailboxes to CRASH_MONITOR without checking with our support group first.
While we will be happy to receive these reports, we want to make sure
that they are sent to the addresses where we can process them most
efficiently. In particular, these reports should never be mailed to a
support engineer's personal mailbox. Instead, we use special addresses
where these reports are logged for future reference.
IMPORTANT: Crash reports may contain company confidential information!
Before forwarding a crash report to L-Soft, make sure that it does not
contain any confidential information. L-Soft will not sign non-disclosure
agreements related to crash reports. If you include an L-Soft address in
your CRASH_MONITOR configuration variable, you are implicitly stating
that none of the activity taking place on your server is confidential.
When reporting a crash to L-Soft, please forward a copy of the crash
report why any confidential information removed or XXX-ed out. Note that
the crash report is not actually mailed until LISTSERV is restarted.
Crashes are usually caused by conditions which prevent LISTSERV from
operating normally; furthermore, image termination may be necessary to
cause the operating system to generate the traceback included in the
report.
(NT) IMPORTANT: In order for the crash report to be useful, the files
LSV.EXE and LSV.SYM must be updated at the same time. This is done
automatically if you install/update LISTSERV using the graphical
installation procedure, however if you install patches manually you must
ensure that both LSV.EXE and LSV.SYM are updated.
This feature was not provided for VM because all the information that is
available is already gathered at the bottom of the console log, which is
normally spooled to a maintenance userid and not accessible to LISTSERV.
Under unix, there is no portable way for an exception handler to obtain a
call traceback; a system-specific debugger (which must be installed
separately and often requires a separate license) must be run on the core
file, which is not available until the process has aborted. Version 1.8c
does flush buffered log output to ensure that the listserv.log fail
contains all the relevant log information following a core dump.
*****************************************************************
* Performance: Enabling reverse indexing for database functions *
*****************************************************************
(VM) Note: the guidelines in this section only apply to the new database
functions. The original VM database functions are not currently affected
by the DBRINDEX configuration variable.
The new 1.8c database functions can be configured to work in one of two
modes: with forward indexing only, and with both forward and reverse
indexing. The forward index is the file called xxx.DBINDEX. With list
archive files and other plain-text based databases, this file tells the
LISTSERV database functions where a particular database entry begins and
ends. Thus, entry #17283 in the XYZ-L list might begin at line 281 of
XYZ-L.LOG9609 and extend until line 312. The forward index also contains
frequently accessed information, such as the subject of a message or the
date at which it was posted. However, it does not contain any information
that would help in locating all the entries that contain the word 'TEST'.
The reverse index (xxx.DBRINDEX), when enabled by setting the
configuration variable DBRINDEX to 1 (or letting it default to this
value), provides this functionality. A reverse index will dramatically
speed up searches on large databases. However, it will not have much
effect on smaller databases. Without reverse index, you can still expect
a search rate on the order of 1-3M per second (elapsed) on a typical PC
server. Many lists have archives in the 1-5M range, and would not really
benefit from reverse indexing. The drawbacks of reverse indexing are:
1. The reverse index file uses up (typically) a few megabytes of disk
space, even if the archives are relatively small. This is because,
even with a small list, tens of thousands of different words are
likely to be in use. This could be an issue for sites with thousands
of small lists.
2. Building and maintaining the reverse index uses up some amount of CPU
time. This could be a problem on time-sharing systems where CPU cycles
are billed by the hour, and I/O accesses are comparatively cheap.
3. The current implementation of the reverse indexing code may require
significant amounts of virtual memory for large databases. On a system
with virtual memory quotas, this would require increasing the quotas
for the LISTSERV process. On a dedicated system, it could, in some
extreme cases, require a hardware upgrade.
None of these problems are likely to be an issue with a typical dedicated
configuration. However, we have customers running over 6,000 lists on the
same machine, paying an outsourcing company for every hour of CPU time
used, or running LISTSERV on machines with 8M of RAM, and this is the
context in which we are mentioning these issues. An operating system
specific discussion follows:
- NT (default = 1): L-Soft recommends leaving reverse indexing enabled
unless your system has less than 32-64M of RAM (depending on RISC/CISC
architecture and on the size of your largest archives) or is already
paging. Most dedicated PC servers have enough resources to enable this
option without impacting overall system performance, although in some
cases a RAM upgrade could be necessary.
- unix (default = 1): L-Soft recommends leaving reverse indexing enabled
unless your system has less than 32-64M of RAM (depending on RISC/CISC
architecture, presence or absence of X-Windows and size of your largest
archive) or is already swapping heavily. Most dedicated unix servers
have enough storage to enable this option without impacting overall
system performance.
- VM (default = 0): L-Soft recommends enabling reverse indexing on VM/XA
and VM/ESA unless all your lists have small archives. On S/370 systems,
only about 10-12M of virtual storage can be made available to LISTSERV,
which is sometimes insufficient even without reverse indexing. This
option can only be enabled safely on an XA/ESA system, after switching
the LISTSERV userid to an ESA/XA or XC machine and increasing its
VMSIZE to the recommended value of 64M (sites which already need more
than 32M due to the number of lists they are hosting should add another
32M). While this may seem excessive, LISTSERV is unlikely to actually
use all that storage. Database accesses last a few seconds at most, and
any peak in storage usage would be temporary.
- VMS (default = 0): L-Soft recommends enabling reverse indexing on
systems which have 64M of memory or more (possibly less for VAX systems
or systems without DECwindows), and which are not page-bound. On the
other hand, you will need to increase the PGFLQUO quota for the
LISTSERV process before enabling this option. Depending on the number
of lists on your system and on the size of the archives for your
largest list, you will want to increase PGFLQUO by 16-64M. VAX users
should note that the default PGFLQUO set by the 1.8b installation
procedure was found to be much too conservative (regardless of the
reverse indexing issue) and has been doubled for version 1.8c. Reverse
indexing is disabled by default on VMS as it is likely to lead to
virtual storage exhaustion unless the quotas are increased.
- Windows 95 (default = 1): since Windows 95 uses the same executable as
Windows NT, reverse indexing is enabled by default. However, a typical
Windows 95 system with 8-16M of RAM cannot support reverse indexing and
this option should be disabled. When installing with the graphical
installation program, your SITE.CFG file will be automatically modified
to disable reverse indexing. If you install the new version manually,
you will need to make this change yourself.
*******************************************************
* Usability: Tableless and standalone operation modes *
*******************************************************
From its very first version in 1986, LISTSERV was designed as a
distributed service where peer servers would cooperate to provide various
value-added services to the end user, without any "master node" or other
single point of failure. These services include:
- The automatically maintained list of lists (see the LIST GLOBAL command
and L-Soft's CataList(SM) at http://www.lsoft.com/lists/listref.html).
- DISTRIBUTE, a mail delivery algorithm that saves bandwidth and computer
resources while decreasing delivery times.
- The ability to subscribe to any (non-confidential) LISTSERV list
without knowing where it is located - any backbone LISTSERV site can
transparently locate the list for you and forward your request. This
feature actually works with most LISTSERV commands, including SIGNOFF,
QUERY, SET, REVIEW, etc.
- The ability to sign off all LISTSERV lists with a single command,
regardless of where they are located.
All these functions have been introduced between 1986 and 1988 and have
stood to the test of time (and orders of magnitude of traffic increase).
They are the foundation on which some of the newer and most popular
LISTSERV features were built; the spam detector and the newly introduced
"spoof detector", for instance, would not have been possible without
LISTSERV's peer architecture.
The drawback, however, is that the servers need to exchange information
with their peers on a regular basis, and need to maintain certain data
tables to ensure a smooth operation of this "LISTSERV backbone" (although
the algorithms are very resistant to the use of outdated tables). In some
cases, this may not be practical. For instance, users running LISTSERV on
their home PC over a 14.4k dial-up connection may find the constant
bursts of server-to-server traffic irritating (while the overall volume
is low, background transfers have a severe impact on interactive
performance with dial-up connections). Similarly, it does not make sense
to attempt to activate the distributed functions on a corporate
"Intranet" server located behind a firewall, with no access to the rest
of the Internet; the server-to-server traffic would only generate
annoying security alerts on the firewall.
L-Soft remains totally committed to the continued improvement of
LISTSERV's distributed, cooperative peer design. It is this design which
made it possible for L-Soft to introduce the very popular LISTSERV "spam
detector" in May 1995. Eighteen months later, none of the competing
products feature a spam detector, for the simple reason that it is next
to impossible to implement one with an isolated, single-system view. Some
products have introduced rule-based filters where you can register
certain "taboo" words, such as "FREE", which of course will erroneously
match "FREE SPEECH" and any number of other legitimate derivatives, while
LISTSERV's spam detector accurately pinpoints messages submitted to large
numbers of lists in a short time frame, regardless of their contents.
At the same time, L-Soft recognizes that some of its customers have
different needs, and has developed two new server operation modes (called
"run modes") to address their needs:
- STANDALONE run mode: suitable for "Intranet" use, this mode disables
any and all cooperative server interaction. LISTSERV acts as an
isolated server with no knowledge of other LISTSERV sites. In this
mode, none of the value-added distributed functions is available.
- TABLELESS run mode: designed primarily for smaller sites that want to
receive as many of the benefits of the distributed model as possible,
but with a minimal level of server-to-server interaction, this mode
configures the server as a "satellite" of a backbone server host, which
acts as a "controller" for the satellite. In this mode, the table-less
server registers its lists in the list of lists and in the CataList
through its controller, receives spam alerts from the controller site,
and is able to forward SUBSCRIBE requests for non-local lists.
DISTRIBUTE, however, is disabled.
The default configuration mode, NETWORKED, corresponds to the traditional
LISTSERV behaviour. To switch to another mode, add a variable called
RUNMODE to your LISTSERV configuration file, with the value STANDALONE
for standalone mode and TABLELESS for table-less mode. For table-less
operation, you can also specify the host name of the controller site (the
default being a host provided by L-Soft for this purpose). There is no
charge for using the L-Soft provided controller, but other LISTSERV sites
may have different policies.
IMPORTANT: In order to effectively support satellite table-less sites, a
backbone LISTSERV site must be running the release build of version 1.8c
and must have been specifically configured to act as a controller (which
adds some overhead). Do not select an arbitrary LISTSERV host without
first checking with its administrator!
**********************************************************
* Security: Automatic detection of spoofed subscriptions *
**********************************************************
In the last few months, a number of point and click utilities have begun
to appear on anonymous FTP servers, allowing mischevious users to forge
Internet mail on an industrial scale and subscribe an unfortunate victim
to thousands of mailing lists. The resulting mail onslaught fills the
victim's mailbox in minutes, rendering the account forever unusable. It
also brings the mail server on which the account is hosted to its knees,
causing, in some cases, tens of thousands of dollars in consequential
damages as other users of the same system also lose precious e-mail.
In most cases, the account ends up being closed. Unfortunately, this
usually doubles the load on the recipient's mail server, as a delivery
error needs to be generated for every message received from the mailing
list servers. Thus, it is not uncommon for the service provider to leave
the account open and simply reconfigure it in such a way that incoming
mail continues to be accepted, but is summarily discarded without
generating a costly delivery error notification. While it is difficult to
blame the service provider for wanting to minimize impact to their
customers, the drawback is that the list owners may never be notified of
the fact that the account was closed. On any large LISTSERV system, there
are likely to be dozens of these addresses, each being sent hundreds or
possibly thousands of messages a day which are simply discarded and waste
resources.
Until now, the only defence against this attack was to configure mailing
lists to require subscription confirmation:
* Subscription= Open,Confirm
LISTSERV will then send a confirmation request to the victim, who does
not reply and thus is not added to the list. While this line of defence
is 100% effective, it may not always be practical or desirable to
configure the list to require confirmation.
Starting with version 1.8c, LISTSERV is now able to detect these
"spoofed" subscription attacks automatically. When more than 50
subscription requests are received from the same account in a short time
frame, LISTSERV automatically undoes all the subscription requests and
rejects any further subscription attempt for a certain period of time.
This applies even to requests that LISTSERV forwarded to other servers;
LISTSERV will then send a SIGNOFF request to the remote server for the
address in question. Note that, in some cases, the subscription may not
be undone, either because of a temporary condition (locked list, etc)
preventing LISTSERV from deleting the user, or because the list was
configured with "Subscription= By owner" and the owner manually added the
victim after the arrival of the undo request.
This mechanism offers a very good degree of protection against the
adverse effects that dead "spoofed accounts" can have on the performance
of the LISTSERV host system. It does not, unfortunately, mean that people
no longer have to fear subscription spoofing, as only LISTSERV lists are
monitored and protected by the "spoof detector". Requests to subscribe to
lists hosted by other mailing list managers are sent directly to the list
managers in question, and LISTSERV can only act on the requests that it
does receive.
******************************************************
* (non-VM) Usability: Easier file catalog management *
******************************************************
File names may now be specified in native (operating system specific)
format in the catalogs. Thus, you can now write (under unix):
MY.FILE /home/lists/xyz/my.file ALL [log in to unmask]
instead of:
MY.FILE my.file./home/lists/xyz ALL [log in to unmask]
The old format remains supported for compatibility. You MUST use the old
format if any of the directories in the path contains a period; otherwise
LISTSERV may use the wrong parser.
The new syntax does not remove the restriction that all files manipulated
by LISTSERV must be accessible through LISTSERV's OS-independent file
access methods. This means that files whose name contains spaces or
control characters (or, under unix, mixed case characters) cannot be
accessed. Similarly, files whose name does not contain a period cannot be
manipulated by LISTSERV. There is no limit on the length of the file
name, only on the characters that comprise it. Note that these "system
filenames" are not visible to the end users, who refer to the file in the
above example as MY.FILE (or my.file - LISTSERV is not case sensitive).
***********************************************
* Reliability: Miscellaneous noteworthy fixes *
***********************************************
- Digest processing has been overhauled with version 1.8c to solve the
various problems reported with 1.8b. LISTSERV can now recover from
severe system errors, including the loss of DIGESTS FILE in a UFS
crash.
- When migrating lists with "Notebook= ...,Separate" from another system,
LISTSERV will now initialize the counter used to number subsequent
issues based on the existing archive files.
- LISTSERV now strips trailing periods from e-mail addresses. Some
misconfigured sendmail systems generate these addresses.
- The HOLD and FREE commands now perform as expected on lists with the
"New-List=" keyword, ie they are executed locally and not forwarded to
the new address.
- (non-VM) LISTSERV will now detect and handle time zone changes even if
not restarted together with the time change.
- (VM) LISTSERV now supports the time zone change notification interrupt
(X'2004') and will automatically reboot upon a time zone change.
Rebooting is the only way to make sure that customer-provided
initialization code is re-executed. For instance, some customers use
one time zone for normal VM operations and another one for LMail,
usually because the former is not RFC822 compliant. PROFILE EXEC will
then contain customer-provided code to update LOCAL SYSVARS based on
the value returned by CP QUERY TIME.
*****************************************
* Usability: Miscellaneous enhancements *
*****************************************
- LISTSERV will now detect most signature files and skip them when
processing messages sent to the LISTSERV address, without denying
service to EMC users (whose messages start with a signature-like file)
in the process. Similarly, LISTSERV will interpret a QUIT or END
command as an indication that the remainder of the message should be
ignored.
- Commands starting with a greater-than character ('>') are now silently
ignored and no longer count towards the SERVE OFF threshold.
- Reduced "junk mail" to LISTSERV maintainer: replies to administrative
requests are now sent with MAIL FROM:<>, avoiding repeated bounces to
the LISTSERV maintainer when users with invalid e-mail addresses
attempt to use the service. Requests from MS Mail users are
automatically detected and continue to receive a reply with a return
path pointing to the LISTSERV mailbox, allowing the users to use their
reply function to send another request.
- Reduced number of "xxx.error" files in the spool directory (spool files
transferred to maintainer on VM): the number of conditions that cause
jobs to be saved as an error file has been reduced to exclude most
user-generated errors.
- The maximum length of a list name has been increased from 32 characters
to as many as your virtual storage capacity will allow. However, L-Soft
recommends using names of 32 characters or less whenever possible as
they provide for correct alignment of the results returned by certain
commands. Very long (program generated) list names are likely to
conflict with mail system limits and L-Soft recommends other solutions
to the problem of dynamically generated lists. As a rule, list names in
excess of 70 characters are likely to result in mail delivery problems.
- The DEL_FILTER list exit point has been enhanced with the addition of
exit code 2. This code causes the request to be rejected (like exit
code 1) and aborts processing with no further message being sent to the
command originator. In contrast, exit code 1 continues processing,
searching the list for additional alias matches and ultimately
resulting in a message being sent to the originator. Please refer to
the site maintainer's guide for more information on list exit points.
- The serve off threshold has been raised from 20 to 50 invalid commands.
***********************************************************
* Performance: Miscellaneous system-specific enhancements *
***********************************************************
- A new configuration option, SORT_RECIPIENTS, controls whether list
recipients are sorted by host name before the message is passed on to
the mail system for delivery. This option defaults to 1 under unix and
0 on other systems. It should be set to 1 when using sendmail as a mail
delivery agent. For LSMTP and LMail/FAL, it is usually best to leave
this option set to 0. Note that this feature was provided as a
between-release enhancement and may already be in effect on your
server.
- (VMS/NT) With large (VMS) or very large (NT) workloads requiring 5-10
SMTP workers or more, accesses to the LISTSERV spool directory can
become so frequent that they can impact performance when recovering
from a network or system outage. This problem can be alleviated by
allocating separate spool directories for incoming (xxx.JOB) and
outgoing (xxx.MAIL) files, as follows:
1. Create a new directory for the outgoing files. This could be a
subdirectory of the existing spool directory, or it could be on
another disk volume. Make sure LISTSERV has R/W access to the new
directory. In this example we will assume that the directory is
called C:\LISTSERV\SPOOL\OUTGOING.
2. Stop LISTSERV, wait until it has exited, then move any leftover
xxx.MAIL files to the new directory.
3. If migrating from VM, allocate an unused minidisk emulation slot for
step 4. If not migrating from VM, use the letter "T" in step 4.
4. Assuming you selected "T" in step 3, add the following two variables
to SITE.CFG (see below for VMS example):
.SD T C:\LISTSERV\SPOOL\OUTGOING
MAIL_SPOOL_DIR=T
Under VMS, you could edit SITE_CONFIG.DAT to add (for instance):
T "LISTSERV_ROOT:[SPOOL-OUT]"
MAIL_SPOOL_DIR "T"
Or you could otherwise define these logicals in the procedure that
initializes LISTSERV on your system.
This change is only required for very large workloads, or to remedy
chronical spool directory backlogs. Note that it is normal to have a
MAIL file backlog if your mail server is unable to accept the messages
at the speed at which they arrive. What would not be normal, however,
is to have a JOB file backlog with the LISTSERV process in contention
wait, and half of the workers waiting for new work (this is just one of
the possible situations that this problem remedies). While there is no
performance drawback in splitting the directories, it is easier to
monitor a single spool directory, especially when troubleshooting
delivery problems. This is why L-Soft does not recommend this
configurations for small workloads where the performance gains are
insignificant.
IMPORTANT: this procedure will not work with the unix version. As there
is only one process accessing the directory (other than short-lived
lsv_amin processes started by sendmail as new mail arrives), there is
little or no contention.
-------------------------------------------------------------------------
CataList is a service mark of L-Soft international, Inc.
LISTSERV is a registered trademark licensed to L-Soft international, Inc.
LSMTP is a trademark of L-Soft international, Inc.
LMAIL and L-SOFT are trademarks of L-Soft international.
Unix is a registered trademark of X/Open Company Limited.
System/370 and VM/XA are trademarks of International Business Machines
Corporation.
VM/ESA is a registered trademark of International Business Machines
Corporation.
DEC, VAX and VMS are trademarks of Digital Equipment Corporation.
Windows and Windows NT are trademarks of Microsoft corporation.
All other trademarks, both marked and not marked, are the property of
their respective owners.
-------------------------------------------------------------------------
|
