Description of the changes for the 2002a "level set" release

                        Version 1.8e of LISTSERV(R)


                 Copyright 2002 L-Soft international, Inc.


                              23 December 2002


THE 2002a LEVEL SET                                                     



The 2002a level set includes all known fixes and patches and between-release enhancements up to 18 December 2002, as follows:


- Fix for Hotmail bounce-processing bug


- Virus scan now allowed on public archives


- Fix for bug that disallowed word searches with certain delimiters (dot, underscore)


- Fix for address case conflicts in DBMS lists


- .FO RAGGed option for mail template forms


- More detail in change-log BOUNCE records for MM processing


- Setting non-default options in bulk ADD jobs


- Miscellaneous performance improvements for LISTSERV HPO.


- Miscellaneous fixes for the 1.8e web interface


- Other miscellaneous fixes and improvements


Also please note:


- OS support information (important)



* Fix for Hotmail bounce-processing bug *



Hotmail bounces saying that the original e-mail address (before address rewrite) was '' caused problems for LISTSERV.  This Hotmail bug has been addressed in the level-set release.



* Virus scan now allowed on public archives *



In the original 1.8e release, viewing public archives via the web interface required a login, which usually failed.  This was due to the way virus-scanning was implemented for archive viewing.  This problem has been fixed in the level-set release and public archives can now be viewed without a login, as expected.



* Word search delimiter bug fix *



A fix has been introduced for list archive searches that solves the problem of certain word searches failing because they contained certain delimiters, such as underscore (_) or dot (.).  Such searches would succeed via the e-mail SEARCH command but fail when made via the web search interface.  They now succeed in both modes.



* Fix for address case conflicts in DBMS lists *



When running a bulk ADD job on a DBMS list with a UEMAIL column in the table, a primary key violation is thrown when an attempt is made to add an address that already exists in the table but has a differently-cased local part.  The primary key violation terminated the bulk-add job at that point.  The only work-around for the problem was to use separate tables for DBMS lists.


The 1.8e-2002a level set has a fix for this problem, and provides new functionality to help work e-mail address case issues.  Although the standard calls for the local part of an e-mail address to be treated case-sensitively, in practice few if any sites actually treat local parts in such a manner.  L-Soft has provided the option of treating local-parts in a case-insensitive manner in response to customer requests.


There is a site configuration variable that sets a sitewide default for address case handling, IGNORE_EMAIL_CASE.  The default is IGNORE_EMAIL_CASE=0, which treats email address local-parts case-sensitively, as in the past, and as per RFC821.


Additionally, a new list header keyword, "Misc-Options=", has been provided.  At present, the only options available are IGNORE_EMAIL_CASE and RESPECT_EMAIL_CASE, which are mutually-exclusive, and provide a list-level override for the site-wide address-case handling default.


Documentation for both of the new options is provided below:


New site configuration variable IGNORE_EMAIL_CASE



Platforms:  Non-VM


Examples:   VMS:  IGNORE_EMAIL_CASE "0"


            Win:  IGNORE_EMAIL_CASE=0


(Under unix, don't forget to export.)


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.


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


New list header keyword Misc-Options=



Syntax:  Misc-Options= option1,option2...optionn


This keyword is not available in LISTSERV Lite.


This keyword is available in non-Lite 1.8e versions and later with build dates of September 2002 forward (issue the command SHOW LICENSE to LISTSERV to determine build date). It is not available in original release 1.8e.


This keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings.  Currently the only option available is as follows:




These options are mutually-exclusive; only one can be defined at a time per list.


The "Misc-Options= IGNORE_EMAIL_CASE" and "Misc-Options= RESPECT_EMAIL_CASE" settings are provided as an override to the site-level IGNORE_EMAIL_CASE= configuration variable. 


See the documentation above for the IGNORE_EMAIL_CASE site configuration for further details on what each setting does.  Other than the fact that they work at the list level rather than at the site level, "Misc-Options= RESPECT_EMAIL_CASE" is identical to the behavior of IGNORE_EMAIL_CASE=0 (the default) and "Misc-Options= IGNORE_EMAIL_CASE" is identical to the behavior of IGNORE_EMAIL_CASE=1.



* .FO RAGGed option for mail template forms *



New in this level-set is a new directive for non-linear mail template forms.  The dot command




(minimum syntax: .FO RAGG) causes text that follows it to be formatted left-justified (that is, "ragged" on the right side).


Please note carefully that .FO RAGGed does not turn formatting off; it simply suppresses the right-justification that is done by default.  If you want full control over the text placement in your non-linear template forms, you must turn formatting off as before, that is, with the .FO OFF directive.


.FO ON causes a reversion to right-justified formatting as in previous releases.



* More detail in change-log BOUNCE records for MM processing *



(Please note that this applies only to mail-merge jobs that use the NOLIST bounce collection mechanism.)


With this level-set release, more detail is available in BOUNCE records collected in NOLIST changelogs.  This feature was added primarily for simplification of LISTSERV Maestro bounce processing.  Previously only the bouncing probed address was collected:




Now LISTSERV also provides information about why the message bounced, with a syntax of


20020329174013 BOUNCE USER@ZYX.COM x.x.x Bounce Message Here


For example:


20021107112809 BOUNCE BOGUSUSER@RERUN.IN.LSOFT.COM 5.1.1 Mailer [] said: "550 5.7.1 <bogususer@RERUN.IN.LSOFT.COM>... Relaying denied"



* Setting non-default options in bulk ADD jobs *



This enhancement is meant primarily for those sites migrating native format LISTSERV lists to DBMS lists.  It allows you to migrate subscriber personal option settings along with their subscriptions.


Normally when preparing a bulk ADD or bulk ADD IMPORT job, the job is formatted like this:


ADD listname DD=myddname PW=mypassword

//myddname DD * His Name

... more users, 1 per line ... Her Name



When this job is submitted to LISTSERV, LISTSERV creates a new options string for each user based on the options already set in the list header, including any options set in Default-Options and any topics set in Default-Topics.  For lists that are simply being migrated from one format to another, this may not be acceptable, as not all users may have the same settings (some may be set to DIGEST, others to NOMAIL, others to REPRO, and so forth).


Subscriber personal options are kept in a Base64-encoded string in columns 81-100 of each subscriber's record in a native format list.  For instance, when doing a GET of a particular list, a particular user's record may look like this in your mailer:





The encoded subscriber options string for JOE@EXAMPLE.COM is thus "3AEAQEBetBev////".  In order to preserve these options across your migration from native format to DBMS format, in your bulk ADD job you would use the syntax





A job using this new syntax would look like this:


ADD listname DD=myddname PW=mypassword

//myddname DD *






Linda.Doe@EXAMPLE.COM Linda Doe


bogususer@RERUN.EXAMPLE.ORG (No Name Available)



Note carefully the following:






* Enhancements for the HPO version *



A number of changes were made to the LISTSERV HPO code in the 1.8e-2000a level set to accelerate web and catalog scan operations and alleviate slowing problems seen by some very large LISTSERV sites.


HPO sites with "many" lists can implement the changes by installing the 1.8e-2002a level set and adding a new site configuration variable, TUNE_MANY_LISTS, to their site configuration.  The new variable is a binary value, and should be set to 1 in order to enable the functionality. 


Note carefully that there is no fixed threshold for the number of lists at which the implementation of these fixes becomes necessary.  This makes LISTSERV work faster at the expense of memory.  If you have 100 lists, you definitely will not need it.  If you have 1000, you probably do. Anything in between would be up to you.



* Miscellaneous fixes for the 1.8e web interface *



Post-release, a number of minor bugs were noticed by customers in the new 1.8e web interface, including problems using Netscape 4.7x.  A number of small fixes have been made to the 1.8e web interface, both in the template forms and in the 'wa' executable itself, to address these problems.



* Other miscellaneous fixes and improvements *



- Bottom banners were not properly inserted into malformed MIME messages.  This problem was manifested by the banner being inserted prior to the last line of the message.  It has been fixed in this level set release.


- Missing keyword files referenced by the .IK list header dot command will now cause an error to be written to the LISTSERV log.


- INDEX.HTML for a given list file was not immediately updated after list creation.  This has also been fixed in this level set.


- (Unix - Classic only) There is a new, simplified installation procedure for LISTSERV for Unix platforms.  A new configuration script ( optionally replaces the need to manually configure LISTSERV's Makefile and go.user site configuration file.  Currently this script is available only for LISTSERV Classic; however it will be slipstreamed into the LISTSERV Lite for Unix kits sometime during 2003Q1.


This new procedure is designed for first-time installers or those who simply wish to install LISTSERV with most of its default settings.  It is thus necessarily limited in its scope and does not provide user control over every aspect of the installation, but rather, allows the installer to set several basic options and relies on Makefile defaults for the rest.  Instructions for use of the script are included in the README.FIRST file found in common.tar.Z.


If it is desired to have complete control over all aspects of the LISTSERV installation, it will still be necessary for installers to revert to the original installation instructions and edit the Makefile by hand, as in the past.


- (Unix - Classic only) Makefile, go, and go.user.sample changes.  Long time users of LISTSERV for Unix should note that there have been a couple of changes to the Makefile in this release.  (Again, these changes are only available in LISTSERV Classic for the time being and will be added to the LISTSERV Lite kits on the same timeframe as the new installation procedure described above.)  These changes include:


  o Makefile:  A new macro, CGIDIR, which can be set to allow 'wa' to be installed to your cgi-bin directory automatically rather than having to copy it manually.  The new Makefile stage added for this purpose also correctly sets ownership and permissions for 'wa' at install time.


  o Makefile:  The default for LSVAMIN_TYPE is now "paths", which causes 'make list name=listname' and 'make aliases' to use the full path to the LSVSPOOL directory rather than "-t".  The "-t" switch, while still supported, is now deprecated.


  o Makefile:  Where applicable, 'nooci.o' and 'nocli.o' have been added to the CFLAGS_`uname` macros, and the CFLAGS section of the Makefile has been moved into the "user customization area".


  o go.user.sample:  This file is used to make 'go.user' in a scratch installation.  A variable called "LOG_PATH" has been added to allow more flexibility in where and how LISTSERV's logs (made by redirection of standard output) are written.  See go.user.sample for more information as to how this works.


  o go: Support was added for the LOG_PATH variable and log rotation/location.



* OS support information (important) *



LISTSERV 1.8e is the last version for several operating systems which have become obsolescent over the life of this product cycle.  The operating systems which will no longer be supported after version 1.8e are:


Windows NT 4.0 SP6

Windows 95/98/Me

BSDi (Intel)


Solaris-x86 (Intel)


Sites running these operating systems should start planning now for a migration to a different operating system.  Please contact your sales representative for further information.


Sites running the Windows 95 shareware should note that their licenses will not activate the product under Windows XP.  Please contact your sales representative for alternatives if you are planning to upgrade to Windows XP (optionally you may migrate to the LISTSERV Lite Free Edition).  Sites running the Windows 95 Lite Free Edition can simply upgrade to the Windows NT/2000/XP LISTSERV Lite Free Edition.  (Naturally you may also elect to continue running LISTSERV under Windows 95/98/Me, but there will be no further new versions or fixes for that platform.)


It should be noted that L-Soft dropped support for the following operating systems with the original release of LISTSERV 1.8e (in other words, LISTSERV 1.8d was the last version for these platforms):


Windows NT 3.5, 3.51, 4.0 pre-SP6 (Intel)

Windows NT (Alpha AXP)

SunOS 4.x (SPARC)

Ultrix (MIPS)




On the plus side, L-Soft now formally supports FreeBSD (Intel) and Linux (S/390) in LISTSERV 1.8e.


A comprehensive list of operating systems (and versions) under which LISTSERV is supported can be found at



* APPLYING THE 2002a LEVEL SET *                                         



Level sets are standard installation kits that replace the previous installation kits on L-Soft's FTP and web servers. They can be used to install a new copy of LISTSERV or upgrade an existing installation. A level set is similar to a Windows NT CD-ROM with the latest service pack pre-applied.


To download the 2002a level set, simply go to L-Soft's web site (or to FTP.LSOFT.COM) and download an evaluation copy of LISTSERV or LISTSERV Lite, then follow the installation instructions for your operating system. The kits can be found at:


LICENSE KEY FOR THE 2002a LEVEL SET                                        



The level set is a no-cost upgrade to customers licensed for version 1.8e and will work with your existing 1.8e license key.


The level set will NOT work with a 1.8d or older license key.  If you are still running a pre-1.8e LISTSERV installation and would like to upgrade to this level-set release, please contact your sales representative to get a 1.8e LAK BEFORE you attempt to upgrade.





1. This document does not include upgrade instructions.  Please see the installation guide specific to your OS platform for upgrade instructions.






VM sites currently at the 1.8e level should download and install it per the "Fixes and Upgrades" section of .  VM sites currently at the 1.8d or earlier level must first upgrade to 1.8e before applying this level set fix.


2. Make sure to update ALL LISTSERV executables, including wa, lsv_amin, lcmd, etc., and associated files, such as the mail and web default templates. Unix Classic sites need to be sure to download both common.tar.Z and the `uname`.tar.Z for their operating system.  For unix we also recommend touching all files in the distribution prior to running 'make update', to ensure that they are "newer" than your existing production files.


3. The 2002a level set is only available for operating systems currently supported by L-Soft. When browsing FTP.LSOFT.COM, you may find installation kits for other operating systems, such as Ultrix or SunOS 4.x, but these kits will be based on older versions and/or code bases.  L-Soft no longer has development systems for unsupported operating systems and is not in a position to compile the 2002a level set for these systems.


*end of file*