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: listname@hostname'. 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 JOE@XYZ.COM instead of: MY.FILE my.file./home/lists/xyz ALL JOE@XYZ.COM 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. -------------------------------------------------------------------------