The LISTSERV® Maintainer's Support FAQ
Last updated 18 April 2017
Note: List owners have their own FAQ.
We've made an attempt here to document a few of the most frequently-asked questions pertaining to running a LISTSERV server. Please take a moment to read through this list and see if your problem is answered here before contacting L-Soft's support hotline.
Note: In general these FAQs apply to both the Classic and Lite versions of LISTSERV. If there is any question, please consult the Classic/Lite feature comparison chart at
We follow the general convention in this document that references to Internet RFCs (Requests For Comment) such as RFC821 and RFC822 mean "the latest revision of the standard", unless otherwise specifically noted. Thus, if we mention RFC821, unless we state that we are talking about RFC821 specifically, we mean that you should reference the latest revision, which is currently RFC5321. Similarly, if we mention RFC822 without saying we mean that specific document, you may reference RFC5322, the current standard.
Unix special note:
As of LISTSERV 16.0-2017a, please note that Linux is supported only in 64-bit distributions.
Windows special note:
As of LISTSERV 16.0-2017a, only 64-bit Windows operating systems are supported. Support has been withdrawn for Microsoft Windows Server 2008 (non-R2) and earlier, and Windows XP and earlier. Currently supported are Windows Server 2008 R2, Windows Server 2012 (both non-R2 and R2), and Windows Server 2016, as well as the 64-bit versions of Windows 7, 8.x, and 10.
OpenVMS special note:
OpenVMS is no longer a supported operating system beginning with LISTSERV 16.0-2017a. Sites still running LISTSERV under OpenVMS should contact the sales department for information on migrating to another operating system platform.
This document concentrates on LISTSERV Version 16.0 and its later "level-set" releases. Older versions are outdated for a number of reasons, including fixed bugs, fixed WA vulnerabilities, and deliverability issues. LISTSERV sites running anything older than the latest Generally Available release (16.0-2017a, released on 28 Feb 2017) should strongly consider upgrading. Release notes for 16.0 and its later "level-set" releases can be viewed at our Documentation and Manuals page.
Any files that you create that you expect LISTSERV to be able to see and take action on MUST be created with lower-case filenames. LISTSERV assumes that all of its files under unix are named in lower-case, in order to avoid case-sensitivity issues inherent in the unix file system. This includes files that you may edit by hand, such as the go.user file, or the license.merge file when you install a new license. It also includes list files and notebook archive files you might migrate from a non-unix host, where those files are usually named in upper case (although under Windows, for instance, files may be named in any combination of case).
If you find exceptions to this rule (for instance, HPO-licensed servers will have an HPO.dat file in the web interface's /archives/upload directory, and LISTSERV writes its parent process ID to spool/listserv.PID), they are LISTSERV-maintained files that LISTSERV knows how to deal with.
I'm attempting to compile LISTSERV on Solaris but whenever I run 'make' I get an error: 'sh:make: not found'.
Sun has placed 'make' in a hidden location, /usr/ccs/bin, which by default is not in your path, so it makes it appear that 'make' isn't available. Therefore you may need to add it to your path to make it work.
You need to execute "dbx lsv core" (or "gdb lsv core") and then type "where" (or "bt"). Then send this information to firstname.lastname@example.org. L-Soft can't debug the problem without this traceback. Don't send the core file itself as it is useless on any machine other than the one it was generated on.
Also, you should check go.user and go.sys for anything unusual that might have caused the dump. It will probably help (and save time) if you send copies of go.user and go.sys along with the dbx or gdb traceback. Be sure to "xxx" out the CREATEPW= setting in go.user before sending it.
Finally, please send the last 100 lines of 'listserv.log' along with your traceback. L-Soft needs this for context. (Please do not send the entire log if it is longer than that! The last 100 lines are usually sufficient.)
If you do not have either 'dbx' or 'gdb' but do have the 'adb' debugger, you need to execute "adb lsv core" followed by "c" in order to generate the traceback.
If a core file is not left after a LISTSERV crash then it is most likely that you need to change some system-wide setting to allow the operating system to write a core file. (See the man page for 'ulimit'.) For instance some unixes have a maxcorefilesize setting (or equivalent -- check the documentation for your particular unix) that defaults to a value that is too small to handle a LISTSERV core dump, which can be quite large. The bottom line is that if a core file is not written after a crash, it's not being written due to an operating system constraint, not because of something LISTSERV is or isn't doing.
I've installed LISTSERV on my unix machine and can't get it to run. When I type "go", I get an error message that says ">>> Cannot create '/listserv.PID' <<<". What do I do?
This is caused by the LISTSERV spool directory being either not defined or set to the empty string. Check go.user and go.sys to see if the spool directory is correctly defined, typically as something like "/home/listserv/spool ".
LISTSERV is running, but mail to LISTSERV is bouncing back with errors like
lsv_amin: Unable to deliver mail to: owner-listserv
lsv_amin: *Error(13)** A call to fopen() failed.
554 "|/usr/local/bin/lsv_amin -t owner-listserv"... unknown mailer error 202
You must ensure that the permissions on the spool directory are set to allow lsv_amin and 'listserv' to create new files. Almost all such errors are a direct result of insufficient permission settings. In particular, Error(13) means insufficient permission on the directory to which lsv_amin is trying to write (the 'listserv' user must have full permissions in that directory). Error(9) is similar, but means that the lsv_amin executable itself has a permissions problem -- usually that it has not been given permissions 4755 (the suid bit MUST be set) and ownership 'listserv'.
Note that some Solaris machines running the OEM sendmail will send back similar errors but complain about Error(11) (which means "Try again" and thus isn't very indicative). We do not currently know what this error means in this context. Our general recommendation for any unix is to use a UCB sendmail rather than the sendmail that ships with the box, but if this is not an option (say, for warranty and support reasons) you will have to ask Sun what Error(11) means in this context.
At least one Linux customer has reported that Error(11) appeared after he moved the LISTSERV directory tree. This was due to the fact that the absolute path to the spool directory is compiled into lsv_amin. If you move the LISTSERV directory tree after installation, you must either use a full path to the spool instead of '-t' in /etc/aliases, or you must edit the LSVSPOOL macro in the Makefile (it would probably be wise to update the LSVROOT macro as well) and re-run the 'make mailer' stage, followed by 'make update'. If you use the 'lcmd' utility you will also want to re-run 'make lcmd' before 'make update', as 'lcmd' also has the LSVSPOOL value compiled into it.
I've successfully created a list on my Unix machine, and it's listed when I send the LISTS command to LISTSERV, but when I try to send mail to it, I get back a "user unknown" error.
You need to create Sendmail aliases (or equivalent, if you're using a mail transport agent other than Sendmail) for the list. This is explained in the LISTSERV for Unix installation guide which comes with the product.
I've installed the 'wa' interface on my unix LISTSERV server. When I try to view the archives for the test lists I've created, I get the following message:
The archive files could not be accessed, probably because they are being updated. Please try again in about 30 seconds, and report the problem if it persists for more than a few minutes. The file that could not be opened is: 'archives/test/test.ind9707' and the error code was 2.
The problem is that the file is really there, and as far as I can tell it has the proper permissions.
Error code 2 under unix usually means "file or directory not found". Thus the most likely explanation for this is that you have not created the file '/etc/lsv-wa.config' as outlined in the Web Archive Interface installation instructions. The clue here is that the error message does not show a full path to the test.ind9707 file, meaning that 'wa' is trying to look for the index file in the relative path 'archives/test' instead of looking for it in the full path, which on some servers might be '/var/www/html/archives/test' . The solution is to create the file /etc/lsv-wa.config per the instructions for installing the 'wa' interface.
After a migration from one unix machine to another, you may navigate to the LISTSERV web interface and receive an error message similar to the following:
Error - template LISTSERV-HOME not found
A configuration error was detected in the CGI script; the LISTSERV-HOME
template could not be found.
This error usually means that you have not migrated the required /etc/lsv-wa.config file from the old machine. It is essentially the same problem described in 1.7.
If this error is received on a machine that hasn't been migrated, check to ensure that /etc/lsv-wa.config exists, is world-readable, and that the PATH and URL parameters it contains are correct.
When we send mail to LISTSERV or to a list, the mail either is never processed or is processed only on the hour.
Normally this is due to not having the permissions and/or ownership set correctly for the lsv_amin program. lsv_amin must run 'suid listserv', which means it must have permissions 4755 and be owned by 'listserv'. If the mail is never processed, lsv_amin is probably not owned by 'listserv', meaning that it is creating .job files in the LSVSPOOL directory that LISTSERV can't read because the 'listserv' user doesn't own them. If the mail is being processed only once each hour, the suid bit is probably not set for lsv_amin, which makes it impossible for lsv_amin to send a "wakeup" call to LISTSERV so that LISTSERV will process the mail in its spool. For what it is worth, this may indicate that lsv_amin was copied by hand into the BINDIR directory rather than being put there by 'make install' or 'make update'. 'make update' or 'make install' should set the ownership and permissions properly, assuming that you are logged in as 'root' when you run them.
Mail being sent to my list (call it MYLIST-L) is being rejected with "unknown mailer error 137", i.e.,
----- The following addresses had permanent fatal errors -----
"|/usr/local/bin/lsv_amin -t MYLIST-L"
(expanded from: )
----- Transcript of session follows -----
554 "|/usr/local/bin/lsv_amin -t MYLIST-L"... unknown mailer error 137
The most likely reason we've found for this so far is that someone may have updated /etc/aliases without following up with 'newaliases'. If you check the syslog you will probably come up with something like this:
Sep 17 03:13:03 listserv sendmail: alias database /etc/aliases.db out of date
If you run 'newaliases' it is probable that the error will disappear. Otherwise a reboot of the machine may be required.
When sending mail to LISTSERV or to a list, I get the error "sh: lsv_amin not available for sendmail programs," ie,
----- The following addresses had permanent fatal errors -----
"|/usr/local/bin/lsv_amin /home/listserv/spool owner-listserv"
(expanded from: owner-listserv)
----- Transcript of session follows -----
sh: lsv_amin not available for sendmail programs
554 "|/usr/local/bin/lsv_amin /home/listserv/spool owner-listserv"... Service
550 MAILER-DAEMON... User unknown
This error indicates that you are running sendmail with a sendmail restricted shell, from which only authorized programs may be run. One such shell is "smrsh", which typically is configured by placing symbolic links from /usr/adm/sm.bin/ to the programs which are authorized. (On some recent Red Hat and possibly other systems the link is made to /etc/smrsh -- just note that this may be system dependent and be sure to read your sendmail restricted shell documentation carefully.)
We restart LISTSERV on a regular basis (to rotate logs, etc). However, when we do the restart we get
>>> Cannot bind to local host, port 2306: error 48.
>>> TCP/IP GUI interface disabled <<<
2 Mar 2000 02:00:05 LISTSERV(R) for unix version 1.8d starting...
2 Mar 2000 02:00:05 Copyright L-Soft international 1986-1999
2 Mar 2000 02:00:05 SIGNUP files are being compressed...
in the log and the web interface does not work.
This is a function of how you are stopping LISTSERV. LISTSERV normally runs in two or more processes under unix, a parent plus one or more children. If you use 'kill -9' to stop LISTSERV, there is a very good chance that you will not kill all of the children. This error normally occurs because one of the unkilled children is bound to port 2306, the port used by 'wa' to communicate with LISTSERV.
The supported method of stopping LISTSERV is to send LISTSERV a "STOP" command (which must be authenticated with the CREATEPW value) from one of the POSTMASTER= accounts. This can be done either by mail or by using the 'lcmd' utility. This is the only method that is guaranteed to stop LISTSERV properly.
You can also try 'kill -TERM' instead of 'kill -9'. 'kill -TERM' produces (on most systems) a more orderly shutdown. (Since it does not work 100% of the time, it is not a supported solution.)
Note carefully that LISTSERV will not stop until it has finished whatever jobs are ahead of the STOP command in its queue.
If you are interested in a better way to rotate LISTSERV's log file, please see this section.
When installing listserv, 'make install' fails with an error like this:
# /usr/ccs/bin/make install
if [ `whoami` = listserv ]; \
then umask 066;mkdir -p /home/listserv; \
else su listserv -c "umask 066;mkdir -p /home/listserv"; \
mkdir: "/home/listserv": Operation not applicable
*** Error code 2
make: Fatal error: Command failed for target `/home/listserv'
It is our understanding that this only happens when attempting to install LISTSERV to a directory on an NFS share. Changing the LSVROOT macro in the Makefile to point to a directory on the local disk should solve the problem. (If you change LSVROOT from the default and are planning to use the precompiled binaries, be sure to read the appropriate sections of the installation guide pertinent to using the precompiled binaries in a non-default environment, particularly with regard to making sendmail aliases for LISTSERV and your lists.)
LISTSERV is a single-threaded process, so when it gets busy distributing mail, it can take a non-trivial amount of time to transfer that mail to the SMTP MTA on your machine for delivery, particularly if the MTA is itself bogged down with traffic. While 'wa' requests do get priority between mail jobs, you are still likely to see a slowdown if you have a lot of mail going through the server at a given time.
The solution as far as LISTSERV is concerned is to take the burden of offloading the mail to the MTA off of its shoulders and instead deliver it in an asynchronous manner to the MTA. This is done by defining SMTP "worker" processes which LISTSERV spawns at run time for this purpose.
In order to define the asynchronous "worker" processes, add the following to your go.user file:
then stop and restart LISTSERV. "nodename" is the same value you have configured for NODE=. For instance, if you have
then you should add
to go.user. The example shown will tell LISTSERV to spawn two (2) asynchronous SMTP worker processes. While you can tweak this number higher, it is best to start with just a couple of workers and then increase the number if necessary. Note that too many workers can lead to diminishing returns, as the more workers you have, the more system resources you will consume.
The difference between synchronous and asynchronous delivery should be considerable and your 'wa' sessions should run much faster even when LISTSERV is under load.
My listserv.log file is filling up with the following messages. What can I do about this?
29 Mar 2001 00:00:00 -> XMRG FROM:<owner-TEST@LISTSERV.EXAMPLE.COM> VERSION=1
29 Mar 2001 00:00:00 500 Command unrecognized: "XMRG FROM:<owner-TEST@LISTSERV.
The problem is that your outbound mailer does not support LISTSERV mail-merge. LISTSERV mail-merge used to require that LSMTP Classic (discontinued for some years) be used as your outbound mailer because mail-merge employed a proprietary extension to the BSMTP command set that only LSMTP Classic implemented. The error shown above is typical of sites that are using sendmail as the outbound mailer and have
set in their go.user file. If this is the case, remove the setting and restart LISTSERV. However, that is not all you need to do.
When you see these errors you must manually remove from LISTSERV's spool directory the *.mail file(s) that correspond to the errors. The easiest way to find the file(s) in question would be to open a shell session, then cd into the LSVSPOOL directory (usually /home/listserv/spool ) and do
grep -H "XMRG FROM" *.mail
from the shell prompt. Then simply move or delete the offending file (or files) from the spool directory. Note that you might have to stop LISTSERV to make it let go of the file before you can move or delete it.
LISTSERV is configured by default to disallow list owners from sending mail-merge jobs, i.e., via the "Mail-Merge" command button in the web administration interface. If you are running LSMTP Classic on a Windows machine to handle your outbound mail from the unix LISTSERV machine, you can allow list owners to perform mail-merge operations by setting
in go.user. Then stop and restart LISTSERV to pick up the change.
It should be noted that LISTSERV has supported mail-merge via a standard SMTP server since version 14.4, by use of the EMBEDDED_MAIL_MERGE site configuration variable. This feature is enabled by default.
LISTSERV's spool directory has some old *.mail files in it that seem to be taking up processing time and are slowing things down. These *.mail files contain lines like
XMRG FROM:<owner-TEST@LISTSERV.EXAMPLE.COM> VERSION=1
XDFN NAME="Jane User"
and sendmail appears to be having a problem with them. What do I do about this? Where are these files coming from?
These are mail-merge jobs. See the previous question for the solution to this problem.
We've installed LISTSERV and started it up but we are getting the following error:
3 Jun 2002 10:59:07 Requeuing 1 mail file for delivery...
3 Jun 2002 10:59:08 >>> Error X'00B0037B' enqueuing mail for delivery <<<
3 Jun 2002 10:59:08 -> Severity: Error
3 Jun 2002 10:59:08 -> Facility: POSIX/unix error codes
3 Jun 2002 10:59:08 -> Abstract: Unspecified error (111) - See errno.h
3 Jun 2002 10:59:08 -> strerror: Connection refused
3 Jun 2002 10:59:08 -> 1 mail file left unprocessed.
There are two ways to look at this -- either sendmail (or whatever you are using as an SMTP MTA) is not running, or sendmail is running but is not configured to accept mail from the network. Obviously the first thing to check is to see if sendmail is running.
If sendmail is running, it is likely configured in a default state which does not allow it to receive mail from the network (this is the default in newer versions of RedHat Linux, for instance, most likely as an anti-spam/anti-relay precaution for sites that install RedHat without doing much local configuration). One way to confirm this is to attempt to telnet to port 25 of the machine from another machine. If the connection is refused and sendmail is running, you've confirmed the problem.
For machines running sendmail, in order to change the default to accept mail from the network, the following checklist is provided. If you are not running sendmail, you will have to refer to the documentation that came with your SMTP MTA for further guidance.
Linux Note: In order to do the following you must have installed the sendmail-cf RPM. That's something that has to be done at the OS level. L-Soft cannot help you with it.
1. cd into /etc/mail and open sendmail.mc in a text editor. Find the following text in that file:
dnl This changes sendmail to only listen on the loopback device 127.0.0.1
dnl and not on any other network devices. Comment this out if you want
dnl to accept email over the network.
2. Make backup copies of /etc/mail/sendmail.mc and /etc/sendmail.cf
3. Change the DAEMON_OPTIONS line to read
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
This comments the line out as noted in the explanatory text.
4. Save the file.
5. Run 'm4 /etc/mail/sendmail.mc > /etc/sendmail.cf' from the shell prompt. This will overwrite your existing sendmail.cf, so be sure you made a backup of it in #1.
6. Do 'ps ax | grep sendmail'. This should give you something like
[rerun]root:/etc/mail# ps ax | grep sendmail
2299 ? S 0:00 sendmail: accepting connections
12423 pts/0 S 0:00 grep sendmail
and will tell you sendmail's current PID (in this case it was 2299).
7. Do 'kill -HUP xxx' where 'xxx' is sendmail's PID. This will force sendmail to re-read sendmail.cf and implement the new configuration.
Please note: If this does not fix the problem, or if sendmail is already accepting mail from the network at large, you will have to refer to the sendmail documentation or ask Sendmail support for assistance. While L-Soft supports LISTSERV running in a sendmail environment, L-Soft does not provide product support for sendmail itself.
Under unix, LISTSERV does not automatically start a new console log file every day. This was originally intended to make it possible for unix sites to redirect standard output from LISTSERV through any specialized scripts that they might decide to write, with the default being simply to redirect standard output to a file called listserv.log in the $LSVROOT directory.
In the event, few sites ever bothered to write custom scripts for log processing, and instead wrote scripts to stop LISTSERV, rename the log file, and restart LISTSERV on a daily basis via cron. This can be quite unsatisfactory, particularly for sites with hundreds or thousands of lists and a great deal of traffic.
To help solve this problem, modern versions of LISTSERV for Unix are shipped with a file called "lsv-logger.pl", which can be configured very easily to both rotate your logs automatically and place them in a "standard" location such as /var/log/listserv . The lsv-logger.pl file should already be present in your LSVROOT directory (if not, it can be downloaded here), and log rotation is enabled by editing the go.user file and uncommenting (and, optionally, editing) the following value:
Before uncommenting the LOG_PATH variable, ensure that the directory where you want the logs to be written has been created (LISTSERV will not create it for you) and that the "listserv" user is able to write there. In general this requires that the directory thus created have the following minimum permissions and ownership:
drwxr-xr-x. 2 listserv root 4096 Apr 18 09:31 listserv
If "listserv" is unable to write in the directory, you will get console errors like this on startup:
print() on closed filehandle LOGFILE at ./lsv-logger.pl line 41, <STDIN> line 26.
When correctly set up, this results in daily logfiles named listserv-yyyymmdd.log being written into the specified directory. The logs will autorotate at midnight without any need to stop and restart LISTSERV.
A few final caveats:
1. Perl 5.6.1 or later is recommended.
2. Be aware that logging occurs ONLY when LISTSERV is running in the background. The logging process under unix is simply redirection of STDOUT to a file. When running in the foreground, it is not possible to divert output in this way. Running in the foreground is a debugging mode only, in any case, and LISTSERV running in production should always be run as a background process.
3. Logs written using lsvlogger.pl will never be deleted by LISTSERV. You may choose to write a separate script called by cron, or use a standard unix utility such as logrotate(8), to handle this housekeeping issue. On a busy server, LISTSERV will write quite of bit of data to its log, so it is important to monitor the amount of disk space being taken up by the logs, and to delete old logs on a regular basis.
4. If the LOG_PATH variable is uncommented but left null, lsv-logger.pl will be bypassed and a single file named listserv.log will be written in the LSVROOT directory.
This error means that sendmail is set to "canonify" outbound addresses on the fly. The problem with this is that LISTSERV, not being an MTA, does not expect errors in the middle of the transmission and thus does not have any way to handle such errors.
The fix for this problem is to disable on-the-fly canonification in sendmail, with FEATURE(nocanonify) in sendmail.mc, recompilation of sendmail.cf, and a restart of sendmail (or at least sending it a SIGHUP) to pick up the configuration change.
After installing and configuring LISTSERV on unix, './go' and './go bg' results in only a return to the shell prompt. No errors are written to the console and (when started in background mode) no log is written.
Typically this means that the 'listserv' user has not been assigned a working login shell. For instance, when creating the 'listserv' user, you may have assigned '/usr/bin/false' or '/sbin/nologin' as its default shell. LISTSERV must have a working login shell in order to work (we generally recommend 'sh' or 'bash').
After upgrading to LISTSERV 16.0, LISTSERV will not run because it expects to find version 2.3 OpenLDAP libraries, and our server has OpenLDAP 2.4 installed.
Generally you will only see this error with the precompiled 'lsv' binary under Linux. Sites that install with DBMS support will generally have to relink by default and the relinking operation will eliminate this issue.
The error is due to the fact that our development environment is set up with LDAP 2.3, whereas it appears that many production systems (specifically CentOS 7 and Red Hat Enterprise Linux 7, but possibly other distributions as well) now ship with OpenLDAP 2.4. This is easy to fix; simply rename 'lsv' to 'lsv-precompiled' or similar, and relink lsv.o as follows:
gcc -O -o lsv lsv.o nocli.o -lldap
gcc -O -o lsv lsv.o nocli.o nooci.o -lldap
gcc -O -o lsv lsv.o nouodbc.o -lldap
This will "realign" lsv with your local LDAP libraries. You can verify this by running 'ldd lsv' from the unix command prompt.
Note: The relinking commands above simply relink lsv without any DBMS support. If you require DBMS support, you will need to exclude the appropriate "no*.o" file from the command when relinking. For more information see the DBMS and Mail-Merge chapter in the Advanced Topics Manual.
Also note: For Linux LISTSERV kits containing both nocli.o and nouodbc.o files (currently only the Linux-RH6x64 kit), it is necessary to specify only one or the other when excluding DBMS support for both DB2 and UnixODBC. Do not specify both when relinking; doing so results in linker errors regarding multiple definitions of DBMS functions within LISTSERV. This is because DB2 and UnixODBC share a significant amount of function namespace. (For the same reason, it is also not possible to relink LISTSERV with both DB2 and UnixODBC support.)
After upgrading to LISTSERV 16.0-2017a, the server dashboard says we are still running the older version we replaced
This is a display issue only, due to old WA cache files still hanging around after the upgrade. It does not affect LISTSERV operation and you can ascertain that you are running 16.0-2017a by issuing a SHOW LICENSE command to the server.
The display issue is, however, easily fixed.
In LISTSERV's site configuration go.user, there should be a setting named WWW_ARCHIVE_DIR that points to a particular location on the LISTSERV server. Inside that location, check to see if it contains a file called system.wwwtpl. If the file exists, delete it. It is not used by current versions of WA, but it will be read in like any other template file when WA executes, if present.
Also in the WWW_ARCHIVE_DIR location, there should be a subdirectory named 'upload'. There may be one or more files in this location whose names begin with 'LICENSE' or 'RELEASE'. If so, delete them. In addition, any file in that directory that has a mixed-case filename may be safely deleted. Such files were written by older versions of WA and because of their mixed-case names, cannot be automatically deleted by LISTSERV's upload directory cleanup process.
After deleting any of the above-referenced files, restart LISTSERV. That should rebuild the web interface files and fix the version display issue; if not, please contact support and we will help you resolve the problem.
On Windows, after I installed the kit, I tried to start LISTSERV in interactive mode in a CMD window, but got "Error 5 Creating synchronization events" and then "Abnormal program termination".
It is most probable that LISTSERV is already running in the background as an service, and you are attempting to run a second instance in a CMD box. Note that the SETUP program installs LISTSERV and SMTPL as services that are configured to start up at boot time. Check your Administrative Tools/Services applet or issue a NET START command to see if LISTSERV is already running. If so, you can simply stop the services from the Control Panel/Services applet and then fire up LISTSERV and SMTPL in CMD windows for interactive mode.
Please note that the interactive mode is not intended for production use; it should be used only for debugging purposes. Running a high-volume LISTSERV service interactively can significantly slow down your throughput.
I'm running Windows and want to know if I can run a POP/IMAP mail server on the same machine as LISTSERV.
LISTSERV's SMTPL.EXE "listener", which passes inbound mail to LISTSERV in a format LISTSERV can understand, requires exclusive access to the SMTP port for incoming mail by default. However, it is possible to run the "listener" service on a non-standard "high" port such as 40025 and use another mail server to accept inbound mail on port 25 and forward the mail intended for LISTSERV to the "listener" service on the non-standard port. L-Soft's support staff will be happy to provide more information regarding the nuts and bolts of how this can be done.
Please note that this restriction does not prevent you from running a Web server or other Internet service on the LISTSERV machine. Only mail services use the SMTP port, so there is no conflict.
WA works fine until I try to enter any data, like a search string or my userid/password for the web management interface. When I do this I get back the message
The specified CGI application misbehaved by not returning a complete set of
HTTP headers. The headers it did return are:
and nothing else.
In general, this error means that WA and the default web interface templates (DEFAULT.WWWTPL) may be out of sync, either because WA.EXE is backleveled, or the templates are backleveled. The support group can help you ascertain which is the case.
Are there any known Windows service pack issues with LISTSERV?
We are not aware of any issues with the current Windows service packs.
After applying a new LAK, e.g., in preparation for an upgrade or to increase LISTSERV's capacity, LISTSERV doesn't start and I get an Windows error:
Could not start the Listserv (Primary Server) service on \\XXXXXX
Error 2140: An internal windows NT error occurred.
Generally, Windows system errors are not helpful in diagnosing LISTSERV problems. You need to look at the LISTSERV console log (typically found in \LISTSERV\LOG, the logs are called LISTSERV-yyyymmdd.LOG where yyyymmdd is the year, month, and day—e.g., 20170825 for 25 Aug 2017) to see what LISTSERV has to say about this problem. However a couple of guesses can be hazarded:
· Is the LAK in LICENSE.MERGE properly formatted? If the LAK contains quoted-printable encoding or any other "garbage" that may have accreted between the sales representative and yourself, or if the LAK was typed in by hand and contains an error, LISTSERV will not start.
· Was LICENSE.MERGE created with Notepad and really named LICENSE.MERGE.TXT ?
You can also take a look at this FAQ, below.
When attempting to start LISTSERV, Windows error 2140 is thrown and LISTSERV does not start.
See above. The error literally means that the service did not start. You should check the LISTSERV log for specifics before contacting support. Typically this happens because you do not have a current license or that your license capacity has been exceeded. Rarely, this error can mean something else is wrong; if you do verify that the problem is not with the LAK, contact the appropriate support address.
When we try to use the web administration interface (or any function using WA.EXE) the browser tries to open the executable WA.EXE instead of the web server executing it.
This means that you do not have the access permissions for WA.EXE set so that it can be executed. You need to open the IIS management console and set the access permissions properly so that the file will be executed rather than read. You may also need to enable the CGI-exe handler mapping for your website in the IIS Manager (it comes disabled by default). Also ensure that WA.EXE has the correct NTFS execute permission.
The following appears in my SMTPS#x log file. What does it mean?
30 Aug 2017 10:57:51 Receive error: Unknown error 
It means that the SMTP_FORWARD host associated with the LISTSERV SMTP "worker" in question has dropped the connection and that the worker has immediately restored it. This is normal if there is limited traffic on the connection; most SMTP servers will drop idle connections after a specified timeout period. LISTSERV always attempts to keep its SMTP_FORWARD connections open because it is inefficient to open a connection, send mail, drop the connection, and repeat if traffic is heavy. If you are not noticing any specific delivery problems at the same time, you can safely ignore it.
This error indicates that the "upload" directory under the web archive interface tree (that is, the "archives\upload" directory) does not have the NTFS file system permission "modify" set. Under very old versions of the web interface, "read/write/execute" was sufficient, but newer versions of WA.EXE also require "modify" (which apparently is not implied by "write"). Setting the permissions accordingly should eliminate this error.
When attempting to use ODBC to connect to a database under Windows x64, the following error appears in the log:
2008 18:18:27 Connecting to ODBC data source MYDBMS...
>>> IM002/0: [Microsoft][ODBC Driver Manager] Data source name not found and
no default driver specified
>>> 08003/0: [Microsoft][ODBC Driver Manager] Connection not open
15 Oct 2008 18:18:27 >>> Error X'0100003B' opening DBMS list <<<
15 Oct 2008 18:18:27 -> Severity: Error
15 Oct 2008 18:18:27 -> Facility: DBMS interface
15 Oct 2008 18:18:27 -> Abstract: SQL error
We are using the same ODBC_* settings that worked on our 32-bit server (or we have otherwise correctly set up LISTSERV to talk to ODBC).
On an x64 system there are two versions of the "ODBC
Datasource Administrator" tool: One version for 64-bit and one version for
32-bit. When creating a datasource you have to take care to use the correct
tool in respect to which client programs will be using the datasource. That is,
if a 32-bit program needs to access the datasource, you have to create this
datasource using the 32-bit version of the tool.
Unfortunately, the shortcut to the tool which you can find at the usual location in "Control Panel" -> "Administrative Tools" points to the 64-bit version of the tool without even a hint that there also is a different version. The 32-bit version is in a special sub-folder of the Windows folder.
So, depending on what sort of datasource you need (for 64-bit or 32-bit access) you have to use either of these two:
(or simply use the shortcut in "Control Panel" -> "Administrative Tools")
(Note that both files have the same name "odbcad32.exe", even the 64-bit version - the difference in the two files is their location, where again it is confusing that the tool for the 32-bit datasources is in a folder that is called "SysWOW64"...)
The solution is to re-create the datasource as a 32-bit datasource using the "hidden" 32-bit ODBC tool.
According to Wikipedia, Windows Server Core is a "minimalistic Microsoft Windows Server installation option, debuted in Windows Server 2008". As such, Server Core does not have the traditional Windows Explorer shell (or "Windows Desktop Experience") and, depending on the version used, may or may not have any Remote Desktop support. Typically Server Core is managed via command-line interface windows, remote Microsoft Management Console connections, various remote server administration tools, and PowerShell. The intent behind Server Core appears to be at least two-fold, viz., 1) eliminate the massive overhead represented by the Desktop Experience GUI, and 2) reduce the "attack surface" of the operating system (again, per Wikipedia, one Microsoft engineer estimates that 70% of the vulnerabilities plaguing the OS over the last five years would not have affected Server Core).
LISTSERV has not been tested in Server Core environments, but given that LISTSERV is not a traditional Windows GUI application, it should not have any problems per se running under Server Core. The difficult part would be installing LISTSERV from the current GUI-based InstallShield installer.
In Windows Server 2016, an even smaller Server Core implementation known as Nano Server is available. Nano Server appears to be designed for Windows Server Containers and Hyper-V Containers. At this time it is unknown whether LISTSERV will run in the Nano Server environment.
However, L-Soft can provide all of the necessary LISTSERV files in a compressed .ZIP archive and LISTSERV can be configured manually; this is, in fact, the way LISTSERV was originally delivered for Microsoft Windows in 1994. If this type of installation is required, please contact the Support department and we will provide the manual installation kit.
We just received our BITEARN NODES update for the current month, and now LISTSERV doesn't accept commands, mail bounces from hosts that didn't bounce before, etc.
This question is only relevant with VM servers running in NJE mode. It is therefore technically obsolete, but there may be z/VM LISTSERV nodes running on internal networks that still use NJE.
Did you add a ':newnode' tag to your BITEARN NODES entry for the current update? The ':newnode' tag internally removes your server from BITNET, and if you are running LISTSERV-NJE, this will cause problems with mail coming in to the server from outside and with commands (e.g., via TELL) coming from local userids. To fix the problem you must edit your copy of BITEARN NODES and remove the ':newnode' tag from your site's entry. The following appendix from LEAVING BITNET (originally at ftp://ftp.cren.net/bitnet/doc/leaving.bitnet, page no longer available) applies:
Use of the :newnode tag for nodes running LISTSERV-NJE
The following is excerpted from e-mail on the LSTSRV-L@UGA.BITNET
list, on 94/11/29-94/12/05 and 96/03/14-96/03/18.
The problems that have been reported to result from setting a
:newnode tag for a node running LISTSERV-NJE include:
a. bounces of regular mailings from external sources that worked fine
b. bounces by local Listserv<->Netnews gateway;
c. Listserv error messages for X-DEL jobs;
d. refusal by LISTSERV to accept mail or TELL commands from
owner/maintainer VM accounts.
e. Users subscribed with FULLHDR lose that option and revert to SHORTHDR
when Listserv 'newnode' processing takes place.
Note that these problems do NOT arise for nodes running LISTSERV-TCP
when the :newnode tag is used for those nodes.
Part of the reason for those problems is that LISTSERV-NJE doesn't
support running from a non-NJE host-name. It is therefore necessary to
edit the node's local copy of BITEARN NODES to remove the :newnode tag,
erase BITEARN LINKSUM2, and restart. This must be done each month the
node remains in BITNET after the :newnode tag is entered.
Another cause for the problems is that the processing of the
:newnode tag does not affect the 'owner' tag in Listserv header, so the
'owner' tag has to be edited by hand for each LISTSERV list whose owner
is affected by the :newnode tag in order for the owner to be recognized
by LISTSERV. LISTSERV will respond to owner comande by mail as it does
for all Internet commands, since all commands will be translated to the
owner's Internet address.
This usually comes from a site exit called LSV$PW EXEC. There is probably some code in there installed at some point which does not work when in TCP/IP mode. For most sites this exit is not really needed and you can just add "Exit 0" at the top.
After upgrade to 1.8d, a call to RXLSVTEL fails at startup and LISTSERV abends, like this:
23 Jul 1999 14:07:06 LISTSERV(R)-TCP/IP version 1.8d starting...
23 Jul 1999 14:07:06 Copyright L-Soft international 1986-1999
23 Jul 1999 14:07:06 PASCAL code loaded at C97000 - size 1199k
DMSITP143T Addressing exception occurred at 80CBA328 in system routine
DMSABE2047I AUTODUMP dump started; please wait
DMSABE1297I Dump has been taken
HCPGIR450W CP entered; disabled wait PSW 000A0000 80E77568
This can be fixed by setting the startmsg variable in LOCAL SYSVARS to the null string, ie,
startmsg = ''
LISTSERV conforms to Section 508 (summary here) of the Rehabilitation Act of 1973, as amended in 2000 (29 U.S.C. 794d). All of its essential functions can be accessed through a plain-text email interface.
I just installed a new LAK (License Activation Key) and now LISTSERV is claiming that I don’t have a valid key, e.g.,
3 Apr 2017 13:06:59 >>> Error X'00C80025' loading license data <<<
3 Apr 2017 13:06:59 -> Severity: Severe error
3 Apr 2017 13:06:59 -> Facility: License control
3 Apr 2017 13:06:59 -> Abstract: No license available, cannot start
>>> Error in license data: option "I S T S E R V - W I N N T - I N T E L
U N I T S" unknown <<<
3 Apr 2017 13:08:26 >>> Error X'00C80015' loading license data <<<
3 Apr 2017 13:08:26 -> Severity: Severe error
3 Apr 2017 13:08:26 -> Facility: License control
3 Apr 2017 13:08:26 -> Abstract: Syntax error in license data
The first error indicates that the license.merge file was not placed in the correct directory. Consult the material at the beginning of the LAK for platform-specific instructions on where this file should go.
The second error indicates a syntax error in the LAK itself. Generally this is caused by mistyping the LAK material by hand, or by attempting to change any aspect of the LAK from its original settings.
As it happens, the second error above was actually generated on Windows by a valid LAK, but the LAK was saved in UNICODE format rather than straight ASCII format. LISTSERV requires that the license.merge file be a straight ASCII file with no imbedded formatting commands, so it is particularly important on Windows machines to ensure that you use Notepad (or some other ASCII text editor) rather than Write or WordPad to edit a LAK file, and that you ensure that you save the file in Text format rather than UNICODE format.
If you have trouble with the evaluation LAK when cutting and pasting it into a text editor and saving it, you should try downloading the license.merge file from ftp.lsoft.com in text mode instead.
Under Windows, if you create license.merge with the Notepad application, it will save the file as license.merge.txt, which LISTSERV will not be able to find. If you do use Notepad to create your license.merge file, please be aware that you will have to rename the file after saving it.
You can avoid this problem by enclosing the name of the file in double quotes, i.e., when you are prompted for the filename in the "Save as" dialog box, enter "license.merge" (you must use the double quote marks!) and press the OK/Save button. Your file will be saved as license.merge and not as license.merge.txt.
Please note that there are other reasons why a LAK may not "take", even when it is installed in the correct directory. Among these are:
· If you are trying to migrate LISTSERV to a different supported operating system (e.g., from unix to Windows or vice versa), your old LAK will not work on the new machine. You must contact the L-Soft sales department to arrange for a LAK that matches your new operating system.
· If you have received a LAK with an expiration date and your system clock is set incorrectly (that is, set so that the date is later than the expiration date in the LAK), the LAK will not be accepted since as far as LISTSERV can tell, it has expired. (This may sound obvious but we have had people write in who were actually not aware that their clocks were set to some date in 2025.)
I've just made a list called TEST.LIST. When I tried to add subscribers, I got the following error:
>>> Error X'0028005B' updating file F:\listserv\main\TEST.LIST <<<
-> Severity: Error
-> Facility: LFxxx routines
-> Abstract: File not opened in update mode
-> I/O mode: Record read + update
This error generally occurs when a list file has been manually inserted into LISTSERV's main directory (e.g., created with vi, etc.) and LISTSERV was not restarted before a command arrived for the list (e.g., an ADD or DELETE command). LISTSERV must be restarted to reformat the plain text file before the list can be used.
I have LISTSERV installed on my machine called WWW.MYCORP.COM, but when I send mail to it, it says something like "...no such user."
There are several possibilities.
· Does WWW.MYCORP.COM get its mail via a mail exchanger? If so, the error may actually be coming from the mail exchanger rather than from the machine LISTSERV is running on. You may be able to fix this problem by having the system administrator change the DNS records for WWW.MYCORP.COM so that mail goes directly to the LISTSERV machine, or by adding a mail alias that redirects mail sent to the non-existent LISTSERV account on the mail exchanger machine to LISTSERV@WWW.MYCORP.COM.
· Is WWW.MYCORP.COM the only name for your machine? Check with your system administrator to see if there are any variant CNAMEs or MX records in the DNS that point to your machine. If so, you just need to add these aliases to the MYDOMAIN variable in LISTSERV's site configuration file. This is particularly important when running under Windows.
· If running under Unix, did you create the Sendmail aliases for listserv and owner-listserv as outlined in the Installation Guide?
· If you are running the Windows version and your bounces look like this:
Connected to listserv.myhost.com:
>>> RCPT To:<listserv@listserv> <== note the unqualified hostname
<<< 550 Recipient not local.
550 email@example.com... User unknown
550 error... User unknown
then the sendmail on your local mail host isn’t fully-qualifying addresses on outgoing mail within the local domain. You may be able to work around this by adding the unqualified name of the host (in this case LISTSERV) to the MYDOMAIN= variable in SITE.CFG. In other words, MYDOMAIN= should look something like this:
MYDOMAIN= LISTSERV.MYHOST.COM LISTSERV
After you make this change, stop and restart both LISTSERV and the SMTPL.EXE "listener".
The Windows versions running with the SMTPL.EXE "listener" are quite picky about their own addresses. Since the listener has no way to resolve the unqualified host name, unless you explicitly specify it in the site configuration file, the listener will reject it as not being local.
For unix hosts, please note that there is no good technical reason to run a mail server with host name qualification disabled, and if it is feasible, you should actually turn this option on in your sendmail configuration rather than apply the MYDOMAIN workaround.
(NOTE: This is probably obsolete, but we are leaving it in for the time being.)
I keep getting error mail that has a bad return path, e.g., "Return-Path: <<@@somehost.com>>". Why is LISTSERV doing this?
The answer is that LISTSERV isn't doing this. You have a bug in sendmail, probably as a result of a bad rewrite rule in sendmail.cf. The Return-Path: line is inserted by sendmail as it delivers the message, not by LISTSERV. (This can also apply to Windows servers that are using a sendmail machine as their SMTP_FORWARD host.)
If you are running a sendmail version prior to version 8.7.x, the simple solution to this problem would be to upgrade your sendmail to the latest UCB version (we do not recommend using OEM versions because our experience with them indicates that the OEM usually introduces some kind of error in sendmail.cf that doesn't play well with LISTSERV). Version 8.7.x (and later; 8.15.2 is the latest available version at this writing) has a much-simplified sendmail.cf that eliminates most of the chance for error on a standard installation.
If you are running a sendmail earlier than 8.7.x, please note that the official sendmail distribution site (ftp://ftp.cs.berkeley.edu/ucb/sendmail/.message) currently notifies users that "8.6 is not supported, not secure, and should not be run on any network-connected machine."
I'm getting complaints on several of our lists that LISTSERV is issuing duplicate copies of list mail (or digests) to the users. What could be causing this?
LISTSERV probably isn't doing this (in fact, it's almost impossible for LISTSERV to be doing this), but to be sure you should check the daily log for any discrepancy. The most likely causes of this problem are:
· A broken unix gateway somewhere between LISTSERV and the recipient that is sending the duplicate mail (this has to do with how unix Sendmail recovers from crashes). Generally this problem will appear and disappear, although it's entirely possible for it to go on for days or weeks, depending on how broken the gateway is.
· The SMTP protocol makes it possible for messages to be duplicated if the remote MTA abruptly drops the connection before it sends your local MTA an acknowledgement that it successfully received the message for delivery (via a 250 reply message). When this happens the protocol dictates that the local MTA try to deliver the message again. There is no way to stop this on the sending end short of removing the message manually from the MTA's queue (by the time this happens, LISTSERV has surrendered control of the message to sendmail or LSMTP or whatever MTA is handling the outgoing mail).
· SMTP synchronization problems as described in RFC1047. RFC1047 describes nearly the same problem described in the preceding paragraph but is related more to connections timing out after the "." signifying the end of the message body arrives but before the 250 reply is sent, rather than being due to the remote host simply cutting the connection before sending it. The former may be indicative of a software or machine resource problem, whereas the latter may be due to extensive "sophisticated processing of the message, in an attempt to confirm that they can deliver the message" (RFC1047, page 2). A solution to the problem as described by RFC1047 may be to raise your MTA's timeout for the site in question, perhaps from 5 to 10 minutes.
In the first three instances, the only way to find the point of duplication is to compare the date stamps on the various "Received:" header lines in the duplicated mail. The point at which they no longer match is where the duplication is taking place.
· Look for users who may have an account on one host .forwarded to a second host but still have subscriptions for both accounts. (This last is extremely common in these days when people jump from ISP to ISP almost on a whim.)
· Finally, duplicates can be generated when the SMTP server on the receiving end does not respond to the end-of-data signal from the sending server and times out the connection. Per standard, when a connection times out, the sending server must assume that the message was not received properly on the remote side. Since the sending server cannot know if the message was actually received in its entirety, the message must be requeued for delivery. If the remote side server continues to exhibit this behavior, the sending server will continue to redeliver the message until it reaches its retry limit.
· [Very old FAQ regarding the Cisco PIX firewall removed as being obsolete.]
Turnaround time on mail sent to LISTSERV or to lists on my server is poor.
On unix machines, it is probable that you will need to tune your MTA for better performance. Please consult the documentation for your MTA for that purpose.
Sites that are forwarding their outgoing mail through another machine (typically Windows sites using the SMTP_FORWARD and SMTP_FORWARD_n site configuration variables) should note that their turnaround time is also a function of how quickly the SMTP forwarding host(s) process the outgoing mail. In other words, LISTSERV may process the mail in seconds, but getting through the SMTP forwarding host's queue could take a lot longer, depending on the mail transfer agent being used by the forwarding host as well as the existing load on that forwarding host. If you are forwarding to a host running a broken or old Sendmail, for instance, you cannot expect lightning-fast delivery.
Please also note that LISTSERV can’t be held responsible for general network problems such as gateway hosts being down, buggy name servers, and the like. If the users who are complaining are generally located in a single domain or in a specific country, the issue is probably connectivity rather than anything LISTSERV itself is doing. For instance, if the main gateway host for a specific domain is turned off every Friday night and isn’t rebooted until Monday morning (and unfortunately this does indeed happen), obviously users behind that gateway aren’t going to get their mail over the weekend.
We've got a postmaster at some site complaining to the effect that, "Your server machine keeps connecting to our GenericWare SMTP server and sending EHLO. Isn't this an error?" (Note: this complaint will generally occur only when you are running the no-longer supported LSMTP mailer with LISTSERV.)
No, it is not. The SMTP protocol (RFC821 et seq) dictates that SMTP servers must answer "500 Unrecognized command" (or similar) when they receive a command they do not understand. The newer ESMTP protocol, introduced in the early 90s, relies on this assumption for proper operation. After receiving a 500 reply to the new EHLO command, the server will send a normal HELO command and the transaction will continue using the original SMTP protocol.
SMTP servers which close the connection when they receive an unknown command are in violation of RFC821 and are unable to communicate with ESMTP servers. Closing the connection looks exactly the same, to the ESMTP server, as a network failure. Since the server thinks the network connection has failed, it enqueues the message for retransmission.
The solution is for the problem site to modify their SMTP server to return a 500 error code and not disconnect when receiving an unknown SMTP command. We understand that in some cases this may not be an option. For instance, they may be using a very old product whose vendor may have gone bankrupt or may have decided not to make the change because they are phasing out the product, or whatever the case might be. However, please understand that the current versions of most SMTP products use ESMTP, and that people want to use ESMTP because of the improvements it offers over the original (1982) SMTP protocol. In other words, this problem is not specific to L-Soft; it is specific to the software the site is using. ESMTP-compatible servers are commonly available, commercially and as freeware, for most operating systems.
If it is absolutely necessary to turn off ESMTP support in LSMTP for a given host, you can create a "mailer" in LSMTP (see Configure/Mailers in the WinLSCP GUI) for the host in question and disable EHLO (and thus ESMTP) in the "Protocol" section for that mailer entry. L-Soft does not recommend turning off ESMTP globally in LSMTP, and would recommend doing so only in cases where the recipient host is adamant that they will not accept your mail with ESMTP.
It is HIGHLY UNLIKELY that this is an issue any longer in the late twenty-teens, but we are leaving this FAQ in place just in case.
I'm suddenly being deluged with tons of "You are not allowed to use inter-server DISTRIBUTE control keywords" errors. What's going on?
When this occurs, it's usually right after you've updated BITEARN NODES, and usually because you ftp'd the file directly into the directory where it belongs while LISTSERV was running. You can fix this by issuing the NODESGEN command, either by mail or from the console, to rebuild the routing files, or simply by stopping and restarting LISTSERV.
Another cause of this problem can be that you've ftp'd BITEARN.NODES in binary rather than ASCII mode. If so, you'll have to ftp the file again.
The proper method for updating BITEARN.NODES is to ftp the file into a scratch directory, stop LISTSERV, move the file into the appropriate directory, then restart LISTSERV. It's never a good idea to overwrite the file when LISTSERV may be accessing it. If you're mirroring BITEARN.NODES, be sure that your mirror is not pointing to the working copy; always mirror to a directory not used by LISTSERV.
BITEARN NODES can be updated automatically for all versions (not just VM as in the past) and it should never be necessary to update by hand as long as you are running with RUNMODE=NETWORKED and your server is registered.
That said, BITEARN NODES has not been updated in quite a few years (because BITNET is no longer in operation) and it is unlikely anyone will see this error again.
Our LISTSERV is running on LISTSERV.MYCORP.COM, but the "From:" field reads WWW.MYCORP.COM.
This is due to using an MTA that routinely "canonicalizes" the hostname of the local machine, and having LISTSERV.MYCORP.COM as a CNAME in your DNS. You can fix it by telling your MTA not to rewrite addresses (but be aware that this will work only until the mail reaches another MTA that isn't so configured), or by using a MX record instead of a CNAME, or by simply adding a second A record for the machine for LISTSERV.MYCORP.COM.
This was primarily a sendmail issue, but might still be a problem depending on the whims of mail transport agent authors and local mail administrators.
(This is similar to but distinct from 1.7.) I've installed the 'wa' interface on my VMS, unix, or NT LISTSERV server. When I try to view the archives for the test lists I've created, I get the following message:
The archive files could not be accessed, probably because they are being updated. Please try again in about 30 seconds, and report the problem if it persists for more than a few minutes. The file that could not be opened is: 'A\mylist-l.log9708' and the error code was 2.
The problem is that the file is really there, and as far as I can tell it has the proper permissions.
This is a documented restriction of the 'wa' interface. Lists that appear in the 'wa' interface must have a full path specified in the "Notebook=" list header keyword. Note that we generally don't recommend putting list archives in the "A" directory for security reasons (and also to keep things from getting cluttered up). We recommend making a directory such as LISTSERV_ROOT:[LISTS] (VMS) or /home/listserv/lists (unix) or C:\LISTSERV\LISTS (Windows) and then making a separate sub-directory under that for each list you have. As an example, under Windows you could have C:\LISTS\MYLIST-L for the list in question and your "Notebook=" setting would be something like
* Notebook= Yes,C:\LISTS\MYLIST-L,Monthly,Public
To fix this, you must not only provide the full path in the "Notebook=" keyword, but you must also go into the directory you created for the list in the web server's /archives hierarchy and delete all of the MYLIST-L.IND* files so that LISTSERV can rebuild them. You should also delete the /archives/MYLIST-L.HTML file so LISTSERV can rebuild that as well. Then either PUT the list header or stop and restart LISTSERV to make it rebuild the 'wa' files.
I've installed the 'wa' interface on my VMS, unix, or NT LISTSERV server. When I try to view the archives for the test lists I've created, I get the following message:
The archive files could not be accessed, probably because they are being updated. Please try again in about 30 seconds, and report the problem if it persists for more than a few minutes. The file that could not be opened is 'C:\LISTSERV\ARCHIVES\MYLIST-L\MYLIST-L.LOG9903' and the error code was 13.
This error indicates that the web server's startup user (ie, the userid under which the web server is running on your machine) does not have read access to the LISTSERV notebook logs for the list in question. Check the file access permissions on the notebook logs. Specifically for IIS under Windows, you must ensure that the IUSR_xxx user (or equivalent in newer versions of IIS) has read access.
I've just deleted a list (we'll call it "deleted") and got the following error:
>Serious error occurred - traceback follows
>>>> Error X'00000011' opening file /users/listserv/home/deleted.list <<<
> -> Severity: Warning
> -> Facility: Generic error codes
> -> Abstract: File/major entity not found
> -> I/O mode: Record read + update
What's going on?
This has not actually been a problem since LISTSERV 1.8d, as the code was been changed to simply ignore files with spaces in the filename. This error should not occur unless you are running an extremely old version of the software.
If you are running with an HPO (High Performance Option) LAK and deleted the list while LISTSERV was running, this error is normal and will only occur once. This is due to an optimization that avoids unnecessary directory accesses, and just means that LISTSERV was surprised that the list was gone, but it recovers after the fact. If you did delete the list, there is nothing to worry about; if you did not, you will want to investigate further, as this error means "file not found".
OK, but I've even rebooted and this is still happening on my Windows machine, and the file it can't find is called "COPY.LIST". There's no such file in \LISTSERV\MAIN.
Look for a file in \LISTSERV\MAIN called "Copy of xxxx.LIST" where xxxx can be anything, but is likely the name of one of your lists. An errant drag-and-drop operation while using Windows Explorer could have created this file. Older versions of LISTSERV will read to the first space and assume that the file is actually called "COPY.LIST", which of course will fail because there is no such file.
Mail going through my list has a From: line that points back to the original poster. I want this line to contain the list address instead.
While it is possible to configure the RFC822 header lines Reply-To: and Sender: via the Reply-To= and Sender= list header keywords, From: is not configurable. This is because, per RFC822, it must contain the address of the originator of the message.
For moderated lists where it is not desirable for the moderator's default e-mail address to show up in the From: line, you can simply use a second POP account and another instance of your POP client to moderate the list.
In any case, due to compliance with RFC822, LISTSERV itself is not allowed to change the value of the From: field except in rare instances where the From: field can't be parsed, and then it says something like '"Undetermined origin c/o LISTSERV Postmaster at node_x" <owner-LISTSERV@node_x>' (but of course, this is not considered a "change" because the original From: line has become garbled or is non-existent).
I get the error "file/major entity not found" when posting to my list, e.g.,
An error occurred while logging mail to the archives of the TESTLIST list.
An incomplete copy of the message might be present in the archive file. The
list is being held to prevent further occurrences of this error. Please take
corrective action and issue a "FREE TESTLIST" command when you want the
message to be reprocessed.
Serious error occurred - traceback follows
>>> Error X'00000011' opening file /home/listserv/lists/testlist/testlist.log9805 <<<
-> Severity: Warning
-> Facility: Generic error codes
-> Abstract: File/major entity not found
-> I/O mode: Record write
This means that the directory you specified in the Notebook= list header keyword does not exist. For security reasons, LISTSERV does not create notebook archive directories for you, you must manually create them using your OS-specific directory creation command. LISTSERV will not complain if the directory does not exist when you initially create the list, but will issue this error the first time you try to post to it.
(Note that LISTSERV will create the Notebook= and web directories for you if you create the list from the web interface and check the appropriate boxes for that purpose.)
LISTSERV uses a null return path (RFC821 MAIL FROM:<>) on its administrative mail, and some of our list owners' and/or subscribers' mail hosts reject this. Can the null return path be changed?
No. The MAIL FROM:<> is per standard for any message generated by an automatic "daemon" process that should imperatively not be responded to by another automatic "daemon" process. This is to prevent a loop from starting if the administrative mail should happen to bounce.
Unfortunately some ISPs have started blocking mail with MAIL FROM:<> as an anti-spamming measure. About all we can say about this is that a) it's against the standard, and b) savvy spammers have already found ways around it. So as it turns out, this is not really a good way to block spam, and our recommendation to any site that rejects such mail is to follow the standard and accept mail with the null return path.
Very little has changed in the standards in this regard since RFC821, regardless of the positions taken by certain large ISPs. The specific sections of the current standards that apply are:
Excerpted from RFC5321 Sect 3.6.3:
Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is transmitted, the reverse-path MUST be set to null (see Section 4.5.5 for additional discussion). A MAIL command with a null reverse-path appears as follows:
Excerpted from RFC5321 Sect 4.5.5:
Implementers of automated email processors should be careful to make sure that the various kinds of messages with a null reverse-path are handled correctly. In particular, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path, or change a null reverse-path to a non-null one, to such messages when forwarding.
Can the text "L-Soft list server at [...] ([version number])" be removed from mail coming from LISTSERV?
Yes, the PLAIN_FROMLINE site configuration variable allows you to do this. (This is not supported prior to LISTSERV 14.3.)
PLAIN_FROMLINE is a Boolean variable (set to 1 or zero) which controls whether or not LISTSERV generates a plain From: line when sending administrative mail, e.g., setting this variable to "1" would result in
From: "Example Company LISTSERV Server (16.0)" <LISTSERV@LISTSERV.EXAMPLE.COM>
PLAIN_FROMLINE = 1
Enabling PLAIN_FROMLINE overrides any setting made to MYORG=, since the organization name setting and release number will no longer be displayed.
I'm the mail admin at my company (we'll call it FOO.COM) and I have users who are subscribed to LISTSERV mailing lists all over the Internet. One user has left the company and still seems to be subscribed to a list called XYZ@LISTSERV.EXAMPLE.COM. How can I issue a DELETE command for my former user?
LISTSERV servers will accept commands on behalf of users in remote domains if they come from the POSTMAST or MAINT address in that domain. In other words if you have a user firstname.lastname@example.org subscribed to the list mentioned, you should be able to issue a "DELETE XYZ email@example.com" command to (for instance) LISTSERV@LISTSERV.EXAMPLE.COM as long as the command comes from firstname.lastname@example.org (or email@example.com). Note that if you use the former, it has to be "postmast", not "postmaster". If it comes from "postmaster", LISTSERV's default filter catches it and it generates an error. Also note that the hostname must be identical; firstname.lastname@example.org can't issue commands on behalf of email@example.com.
If all else fails, you can always write to the generic list owner address for the list (listname-REQUEST@host) or to one of the LISTSERV maintainers, whose address(es) can be found by issuing a RELEASE command to LISTSERV@host, and request that the user be manually removed.
Why does LISTSERV consider case? Shouldn't subscriber addresses be evaluated as case-insensitive? For instance, if I have an address on the list as firstname.lastname@example.org, why does LISTSERV allow the address JOE@example.org to be added?
According to the Internet RFCs for mail (RFC821 and following), the "local part" of any e-mail address--the part to the left of the "@" sign--MUST be considered case-sensitive. This is because long ago, when the mail standards were written, it was thought that it might be useful to allow a mail system to let mail addressed to (for instance) joe and JOE and JoE to be routed to different mailboxes (ie, for different local users who happened to be named "Joe"). Although most modern mail systems do not differentiate between the case of the local part (because most rational people recognized the inherent breakage involved in overloading userids based on case), some still do, and the RFC still requires case-sensitivity. Therefore LISTSERV must treat the local-part of the address with case-sensitivity.
However, please note the following points:
· All other LISTSERV commands (except for the "OK" command, which is a separate issue) are NOT case-sensitive. For instance, if you send a DELETE command for email@example.com, it will delete not only firstname.lastname@example.org, but also JOE@example.com and JoE@example.com in one fell swoop. This is a compromise between adhering to the letter of the RFC and recognizing that very few sites operate with case-sensitivity in this day and age.
· LISTSERV does not consider case in the hostname part of the address (the part to the right of the "@" sign). LISTSERV does upcase hostnames but this is in order to make sorting more efficient, not for any reason of standards compliance. According to the RFCs, hostnames are not allowed to be case-sensitive. Therefore if an MTA is rejecting mail to a user because LISTSERV is upcasing the hostname in the address, the user's MTA is not compliant with the RFCs. Specifically see RFC1035, Section 2.3.1, which states:
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
Can LISTSERV scan incoming mail for viruses or worms (or any kind of malicious attachment) before it processes mail for a list?
Yes. LISTSERV supports real-time anti-virus scanning of all messages sent to mailing lists that run under LISTSERV Classic or LISTSERV Classic HPO on Windows and Linux servers, including inline uuencoded binaries and MIME attachments in those messages. This is a value-added feature which, in addition to a regularly-licensed LISTSERV Classic or LISTSERV Classic-HPO installation, requires the following:
1. For sites with perpetual ("EXP=NEVER") LAKs: An additional "maintenance" LAK, meaning that you must purchase maintenance (which includes automatic anti-virus signature updates for the term of the LAK) for LISTSERV in order to use the feature. This LAK will come from your sales representative automatically when a perpetual LISTSERV LAK is purchased with maintenance and must be renewed yearly.
2. For all sites: A separate F-Secure Anti-Virus key that should be sent to you by your sales representative along with your LISTSERV LAK. F-Secure Anti-Virus must be installed on your LISTSERV machine to enable anti-virus scanning.
Please note carefully that the anti-virus scanning feature is available only for Windows Server and Linux running on Intel platforms at this time. Should F-Secure extend its OS support to other L-Soft supported platforms, the feature will become available on those platforms.
Regardless of LISTSERV's ability to reject mail containing malicious payloads, from a user standpoint the usual education is still always indicated -- never execute a file sent you by a non-trusted source; scan all compressed (.zip, .gz, etc.) archives sent by non-trusted sources before opening them; use automatic virus protection locally; and so forth. It is particularly important to update the virus signature database of your virus protection program early and often so as to offer maximum protection against new worms and viruses.
List owners have the further option of using the "Attachments=" list header keyword to reject or filter MIME attachments. See the next FAQ entry for more information.
LISTSERV contains a configurable MIME attachment filter that will let you bounce or strip MIME attachments. The filter is configured on a list-by-list basis by using the new Attachments= list header keyword. (There is no site-wide override.) See the Site Configuration Keyword Reference for information on how to configure Attachments=.
Note carefully that Attachments= works only for properly-configured MIME attachments.
Also note that the Attachments= setting will not block old-fashioned uuencoded files that are not attached via MIME. Because very few mail clients use uuencoded attachments anymore, LISTSERV simply strips uuencoded files from all messages by default. You can re-enable this if necessary by setting Attachments= All rather than Attachments= Yes (see the documentation for details).
Note that you can also strip HTML attachments from multipart/alternative messages (assuming that there is a plain text alternative in the message) by setting Language= NoHTML in the list header. The Attachments= keyword setting cannot be used for this purpose, nor can it be used to strip or reject messages of MIME type text/plain (which are always accepted since they are plain text).
Finally, LISTSERV also strips by default proprietary Microsoft Exchange attachments which contain information about the mailpiece that is only usable by Microsoft Outlook. The choice to strip these attachments by default was for the convenience of users who do not use Outlook and find the "winmail.dat" and MS-TNEF attachments produced by Exchange to be a nuisance. However, in some cases it may be desirable to allow the Microsoft attachments through (for instance if all of your users are using Outlook and want the full experience), and this can be done by setting
in the list header.
A list of registered MIME media types for attachments is kept by IANA and can be found at
When trying to access an ODBC list (for posting, admin, etc.) I get a message back that says something like
Serious error occurred - traceback follows
>>> Error X'0100003B' opening DBMS list <<<
-> Severity: Error
-> Facility: DBMS interface
-> Abstract: SQL error
Whenever you see the above SQL error you must look in the LISTSERV console log for further information. There are usually 1-3 more lines found there which report the exact nature of the SQL error.
Note that should your ODBC source disconnect for any reason while LISTSERV is running (ie you stop and restart your DBMS), ODBC does not currently have any way to inform LISTSERV of this and LISTSERV may have to be stopped and restarted in order to reconnect.
If there is a question about what SQL commands LISTSERV is sending, you can ask LISTSERV to trace the commands to the log by adding
to the site configuration file and stopping and restarting LISTSERV. It is also a good idea to trace ODBC itself by turning tracing on in the ODBC control panel.
Although this is clearly documented in chapter 15.11 of the Site Manager's Operations Manual for LISTSERV, we reproduce the procedure below.
For security reasons, LISTSERV does not have an explicit command for deleting lists, although lists can be deleted through the web administration interface. If you prefer to delete a list via the web interface, log into the web interface as a LISTSERV administrator and choose "Server Administration", "Mailing Lists", and then "List Deletion" from the menu. You will be prompted to select a list, after which the list header will be displayed and you may delete it by clicking the "Delete" button at the bottom of the page. Please be aware that this operation is final and the list, once deleted, cannot be recovered.
For those who prefer to delete lists the old, manual way, the LISTSERV administrator simply deletes the list file from the system command prompt with the appropriate file system command (CMS ERASE for VM, DEL for VMS, ERASE for Windows, rm for Unix). A suggested procedure for deleting an established list (one with archives and so forth) follows:
1. Back up any files you wish to keep, such as notebook archives.
2. For a digested list, you may want to send a QUIET SET listname NODIGEST FOR *@* command. This will cause LISTSERV to send out its accumulated digest to those who were set to DIGEST mode. If the list hasn't been active or if it's not digestified, you don't need to take this step.
3. Delete the listname.list file with the appropriate file system command.
4. If the list has web archives, delete the /archives/listname.html file and the /archives/listname/listname.ind* files. You can also remove the /archives/listname directory at this time.
5. Although it is not absolutely necessary, stopping and restarting LISTSERV will complete the procedure. If you do not stop and restart LISTSERV, LISTSERV will fairly quickly notice that the list is gone, and will take care of this on its own.
I keep seeing lines like this in the LISTSERV log:
1 Mar 2000 09:31:48 Processing file 3215 from MAILER@LISTSERV.EXAMPLE.ORG
-> New subscriber, will process in 10 minutes.
What in the world is this?
LISTSERV has a feature called "spam quarantine". This feature holds all messages from non-subscribers and the first message from new subscribers for 10 minutes (the default) to help compensate for network latency that could result in a spam alert not reaching your machine until after the spam in question has been distributed to your list(s). You can adjust this (or defeat it completely) either at the server level (with SPAM_DELAY= in the site configuration) or at the list level (see the Spam-Delay(n) parameter of the Loopcheck= list header keyword).
The purpose of holding the first message from a new subscriber to a given list is to help avoid situations where a spammer subscribes to a list, posts, and then unsubscribes in order to get around Send= Private.
If you are running in Networked or Tableless mode you may see these from time to time:
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: RELEASE
13 Mar 2000 16:45:13 To LVMON@VM.SE.LSOFT.COM: LISTSERV(R) High Performance fo
r Windows NT version 1.8d, managed by:
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW WWW_ARCHIVE_URL
13 Mar 2000 16:45:13 To LVMON@VM.SE.LSOFT.COM: WWW_ARCHIVE_URL = http://peach.
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW CTR 200003
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW CTR 200002
13 Mar 2000 16:45:13 Sent information mail to LVMON@VM.SE.LSOFT.COM
VM.SE.LSOFT.COM is a central L-Soft server that collects publicly-available statistics and other information for the CataList service and for L-Soft's use in developing usage metrics. All of the commands sent by LVMON are documented and can be issued by any user. See also 5.7 of the Site Manager's Operations Manual for more information on inter-server information sharing.
If you absolutely, positively cannot approve of the idea of this information being sent out to a central server, then you must set your server to operate in STANDALONE runmode. See the documentation for the RUNMODE= site configuration keyword for more information. (Note: LISTSERV Lite Free Edition sites cannot change their runmode. On the other hand, the paid version of LISTSERV Lite does support the RUNMODE= keyword.)
How do LISTSERV's license points work? For instance, if I have a 10 point LAK (UNITS=10), why can't I make 10 lists? Isn't it one point per list?
This question applies only to sites that have graduated LAKs. If your LAK has "UNITS=0" then it is non-graduated (i.e., unlimited capacity).
The answer to the question is, "it depends". With a 10-point LAK you can make 10 lists as long as they have 150 or fewer subscribers each. But if you have lists larger than 150 subscribers, you start using multiple points per list. The subscribers-to-points scale is as follows:
If you have this many subscribers on a given list:
then you need this many points for the list:
0 - 150
151 - 300
301 - 500
501 - 1000
1001 - unlimited
Thus if you have a list with 141 subscribers, a list with 673 subscribers, and a list with 2530 subscribers, you need a total of 10 points (1 + 4 + 5) to run the lists, and if you have only a 10 point LAK you will not be able to make more lists unless you purchase more capacity.
Note: This scale does not apply to sites that have LAKs with SCOPE=PERLIST, in which case one list == one point regardless of size. Typically L-Soft sells this type of LAK only to ISPs.
If you do not know how many points you currently have in use, you can issue the command SHOW POINTS ALL to get a detailed breakdown.
We run LISTSERV on a machine called LISTSERV.EXAMPLE.COM. But when we send mail to that machine we always get an error back that looks like this:
Your message did not reach some or all of the intended recipients.
Sent: 4/10/2000 4:28 PM
The following recipient(s) could not be reached:
email@example.com on 4/10/2000 4:28 PM
The recipient name is not recognized
The MTS-ID of the original message is: c=US;a= ;p=ExampleCom
MSEXCH:IMS:ExampleCom International:POUGHKEEPSIE:NTSERVER 3550
(000B099C) 550 No such local user
We run Microsoft Exchange as our main mail gateway.
Exchange has an unfortunate habit of assuming that if it is supposed to handle mail for (say) example.com then it is also supposed to handle mail for all subdomains of example.com. Therefore if a piece of mail addressed to firstname.lastname@example.org passes through the Exchange machine, Exchange will attempt to handle that mail itself (presumably by looking for a local 'listserv' account) rather than (correctly) passing it off to listserv.example.com.
Since LISTSERV handles its own incoming mail, this means that mail addressed to the LISTSERV machine which passes through the Exchange server never gets to LISTSERV. Instead it typically gets bounced back to the sender with the error you reported.
The solution is to tell Exchange to hand off any mail sent to the listserv.example.com domain to the LISTSERV machine. We have some instructions provided to us by a customer for dealing with this sort of situation; note that since we don't use Exchange in-house we can't guarantee the accuracy of the instructions and if you have problems with them we will probably not be able to assist you further with your Exchange setup. Here are the instructions--use at your own risk:
| Open Exchange Administrator and navigate to your site's Connections
| container. Open the Internet Mail Service. Click on the Connections tab.
| Click on the E-Mail Domain button. Click on Add. In the EMail Domain box
| enter the FQDN for your LISTSERV computer (e.g. listserv.example.com).
| Check the Forward all messages for this domain to host: button and enter
| the IP address of the machine on which LISTSERV is installed -- this only
| works by IP address. Click on OK. OK. OK. OK. Stop and restart the
| Microsoft Exchange Internet Mail Service. And that should be it.
Again, if this fix does not work for you, you will have to consult the Exchange documentation or contact Microsoft support to resolve the problem. L-Soft does not run Exchange and does not support Exchange.
When using the bulk operations part of the web interface, I get this message and the operation fails:
The CGI script was unable to upload your file to
'e:\inetpub\wwwroot\archives\upload\4792584625258591.tmp'. The error code
was 2. The upload area has probably not been configured by the
As documented, this error means that the "upload" directory has not been created. LISTSERV does not make it for you; it has to be created manually.
If the directory exists and you get an error 13 when you attempt a bulk operation, this means that the CGI program user does not have write permission in that directory. Under Windows and IIS for instance this would be the IUSR_xxx (or equivalent) user created when IIS was installed.
How do I suppress the "summary of resource utilization" messages that appear at the bottom of command responses coming from LISTSERV? For instance,
Summary of resource utilization
CPU time: 0.000 sec
Overhead CPU: 0.000 sec
CPU model: AlphaServer XP1000 6/500 (1024M)
Job origin: J.USER@EXAMPLE.COM
You can suppress this information by setting
in the site configuration file and stopping and restarting LISTSERV. (Unix sites may need to add
on the following line.)
When attempting to start LISTSERV, the following error is thrown and LISTSERV terminates.
6 Apr 2017 16:47:06 LISTSERV(R) for Windows version 16.0 starting...
6 Apr 2017 16:47:06 Copyright Eric Thomas 1986-2017
6 Apr 2017 16:47:06 Build date: 28 Feb 2017
6 Apr 2017 16:47:06
6 Apr 2017 16:47:06 NJE interface failed to initialize - aborting.
What does this mean?
The short answer is that you have set NODE= to a value that isn't recognized by LISTSERV as a fully-qualified domain name (FQDN). Unless you are running an IBM VM mainframe that still uses an NJE connection (highly unlikely), you must imperatively set NODE= to the full DNS FQDN that points to your machine. Using a non-qualified name for NODE= tells LISTSERV to attempt to activate legacy code for its BITNET-NJE interface, which is still available under VM. Since this code is not available at all in the unix and Windows versions, this initialization attempt fails and LISTSERV shuts down.
Can LISTSERV tell me if my mails are being received and opened? (In other words, can LISTSERV do so-called "open-rate" tracking?)
LISTSERV does not do open rate tracking itself. However, since it acts as a direct pass-through of whatever you post to a list, it does not interfere with any open-rate tracking code (usually HTML that executes when the message is opened) that you might acquire elsewhere and post to a list for this purpose.
If you are looking for a product that integrates seamlessly with LISTSERV to do open-rate tracking (or handle other e-mail marketing chores), you might find L-Soft's LISTSERV Maestro package of interest.
Generally, yes. However, when PDF files are sent with quoted-printable encoding, the format of the file may become corrupted, rendering the file unreadable. Using Content-Transfer-Encoding: 7-BIT instead of quoted-printable (or sending the attachment using a Base64 encoding scheme rather than quoted-printable) should solve the problem.
In fairness, this is unlikely to be a problem with modern email clients, unless for some reason they are set to send attachments using uuencode.
Note: Change-logging is not available in LISTSERV Lite.
LISTSERV's reporting interface is based on the existence of changelog data for the time period you have chosen. LISTSERV's change-logging feature is not enabled by default because changelogs take up quite a bit of space, and even when changelogs are enabled, they may be set to automatically rotate after a particular interval.
If changelogs are enabled with rotation, and a changelog or changelogs exist for the time period in question, it is possible to download the changelog(s) and post-process the data in Excel or with a custom script.
For more information on site-level changelogs, see the SYSTEM_CHANGELOG site configuration variable as well as the previously-mentioned section of the Site Manager's Manual.
We would prefer that the mail sent to subscribers should list the subscribers name and email address in the "To:" header rather than seeing the list name on the "To:" header. Is there any way to do this?
Yes. Use LISTSERV Maestro to create personalized mail. Otherwise, no, there is no way to do this with standard LISTSERV lists.
LISTSERV does support SPF, if you have configured SPF support for your domain in DNS. There is no specific LISTSERV setup required for SPF, and if you have configured SPF correctly in DNS, it should work.
Until LISTSERV 16.0-2017a, DomainKeys was supported. However, DomainKeys is obsolete and in LISTSERV 16.0-2017a, DomainKeys support has been replaced with DKIM (DomainKeys Identified Mail) support.
For most LISTSERV sites that were already running with DomainKeys support, the change is transparent and requires no adjustment of your current LISTSERV settings. However, prior to upgrading to LISTSERV 16.0-2017a, sites running with DomainKeys support should take the opportunity to review their key pair, as key lengths which were sufficient for DomainKeys may be too short for DKIM. Per RFC 6376 "DomainKeys Identified Mail (DKIM) Signatures", Section 3.3.3, "Signers MUST use RSA keys of at least 1024 bits for long-lived keys", whereas many DomainKeys sites may be using keys of 512 or 768 bits.
In order for LISTSERV to use the blacklists and whitelists, SPAM_EXIT must also be enabled and pointed to an existing, external exit program. This is necessary because the white- and blacklisting feature is part of LISTSERV's overall anti-spam toolbox, which is only activated if SPAM_EXIT is enabled.
While you may of course use the exit program you write to submit inbound mail to an external spam filter for scanning, that is not mandatory. In that case, the exit program does not need to do anything other than exit immediately with a return code of zero. For example:
rem don't do anything, just go back to LISTSERV
# don't do anything, just go back to LISTSERV
IETFHDR demands strict compatibility with IETF standards for mail, which impose a very strict set of rules on LISTSERV:
· LISTSERV MUST add a "Received:" field to the message as it passes through the server;
· LISTSERV MUST add a "Message-ID:" field if it is missing;
· LISTSERV MAY add a "Sender:" field if desired;
· No other changes of any kind to the email headers are allowed.
Thus, if IETFHDR is specified, strict adherence to these rules prevents LISTSERV from appending subject-tags and/or making other modifications to the email headers. Clearly this causes some head-scratching moments when it comes to implementing features like the list header fields recommended by RFC2369 ("List-Unsubscribe" and so forth), DKIM signatures, etc., not to mention simple things that people actually want, like subject-tags on their mailing list emails to make it easier to sort their mail.
For a long time, LISTSERV hewed to the standard and did not allow IETFHDR violations like subject-tags. However, since LISTSERV 14.3, adding "Misc-Options= IETFHDR_SUBJECT_TAG" to a list header causes the IETFHDR option to always include subject tags for subscribers set to that header option.
Because, as already noted, this can be considered a violation of the practice for IETF-style headers, it can be prevented site-wide by the site administrator if desired, by setting the DEFAULT_MISC_OPTIONS site configuration variable as follows:
DEFAULT_MISC_OPTIONS = '-IETFHDR_SUBJECT_TAG'
LISTSERV uses the operating system clock time and as such does not require patching for the DST change. As long as your operating system has been updated to reflect the change, this will not cause a problem for LISTSERV.
However, Maestro users using versions prior to 3.0 will be affected by the DST date change. The only way to fix this is to upgrade to the current supported version of Maestro (as of 6 Apr 2017 this was 7.3-1). To be honest, anyone running Maestro older than version 7 should upgrade to the current supported version; many bugs have been quashed and there are many, many new features available.
Very little. "Mail delivered" means that LISTSERV created one mail message for a single recipient, and passed it on to the mail system. "Mail posted via SMTP" means that LISTSERV created a bulk SMTP transaction for multiple recipients and passed it on to the mail system. In the earlier days of LISTSERV, it was helpful to see the difference in the logs because "Mail delivered" was much slower. When reading the logs, it was your cue that it was normal to see a slowdown in the time stamps, and that perhaps you should reconfigure your lists to allow the use of bulk SMTP. Today it is unlikely that the difference is that big, especially with embedded mail-merge. But this still corresponds to two different delivery processes in the code that it is sometimes useful to distinguish for troubleshooting purposes. For practical purposes, the result is the same.
Using the LDAP configuration screen in the original release version of LISTSERV 15.5 may cause an error to be thrown when LISTSERV attempts to authenticate via LDAP, e.g.,
24 Apr 2008 13:23:53 >>> Error X'0000006B' looking up
LDAP account <<<
24 Apr 2008 13:23:53 -> Severity: Error
24 Apr 2008 13:23:53 -> Facility: Generic error codes
24 Apr 2008 13:23:53 -> Abstract: Configuration error detected
24 Apr 2008 13:23:53 To [ANONYMOUS]@LISTSERV.EXAMPLE.COM: ***BADPW***
In all cases we have seen, this will be due to a known bug found in the LDAP configuration screen which pre-populates a nickname of 'DEFAULT' for the first LDAP server configuration. When entering a hostname in the LDAP_SERVER box and adding the connection, the following appears in sitecfg.file :
Unfortunately, 'DEFAULT' is never a valid nickname in the LDAP_SERVER line. It should be:
However, should you create an LDAP connection using a nickname other than "DEFAULT", the syntax would be valid:
This issue is fixed in the current version of LISTSERV.
If you have any of the following errors you should upgrade to the current release version. There are no patches for earlier versions.
Note carefully that if you are still running LISTSERV 1.8c or earlier, you are not running a Y2K-compliant version of LISTSERV. If you have any problem that looks like a Y2K issue and you are still running 1.8c or earlier, the solution is to upgrade to 1.8d. Again, there are no Y2K patches for earlier versions, which are badly outdated in any case.
If you are still running a non-VM release build of 1.8d or earlier (i.e., the build date shown in the "SHOW LICENSE" output is earlier than 16 July 2000) please see the security advisory found here.
If you are running any build of LISTSERV prior to the version 16.0-2017a "level set" release, you are missing out on some of the most recent changes affecting deliverability of your email to just about anyone – there have been changes to DMARC and Domain Keys (which was supported previously by LISTSERV) has been obsoleted by DKIM (which is supported by 16.0-2017a). Also, for Windows and Linux users, the latest versions of F-Secure's anti-virus suites for those platforms have been certified as supported with LISTSERV. For complete release notes, please see here.
The bottom line is that if you are still running an old version of LISTSERV, there are some very good reasons for upgrading to the current version.
The LISTSERV kit for Linux compiles fine except for 'make server'. When I run 'make server', I get lots of errors like:
undefined reference to `fread'
cc: Internal compiler error: program ld got fatal signal 11
make: *** [lsv_prog] Error 1
make: Leaving directory `home/listserv/src'
make: *** [lsv] Error 2
It leaves an 'lsv' file in the source directory, but it doesn't have "x" privileges.
Where did you get this kit? Looks like it is a pre-ELF Linux kit that hasn't been available for years. Please download the latest supported version from http://lsoft.com/download/listserv.asp .
I've installed LISTSERV and configured it to operate in TABLELESS mode, and I keep getting errors like this:
Reason: No such list - this temporary interface does not gateway to MAPI.
This bug has been fixed since LISTSERV 1.8c. Please download the latest supported version from http://lsoft.com/download/listserv.asp .
I have installed the (insert name of unix) kit for 1.8c, but I am getting the following error:
ld.so.1: ./lsv; warning: /usr/4lib/libc.so.1.8 has older revision than expected 9.
Please download the latest supported version from http://lsoft.com/download/listserv.asp .
When installing the LISTSERV evaluation kit for Windows, the setup program shows an hourglass but then terminates without doing anything.
You have a very old installation kit. Please download the latest supported version from http://lsoft.com/download/listserv.asp .
I have installed the "wa" (Web Archive) interface that came with 1.8c or later on my Windows machine running LISTSERV, and I can view archives without any problem, but any time I try to search archives via the web page or (1.8d) log into the web administration interface, I get back
Search results LISTNAME
Unable to initiate communication with LISTSERV. Error code was 5
("Access is denied.") The server is probably not started.
I’ve checked and LISTSERV is running.
Again, you have a very old version running. Please download the latest supported version from http://lsoft.com/download/listserv.asp .
This was a documented restriction of the ‘wa’ interface; web-based searches won’t work because the Windows 95 operating system doesn’t implement named pipes. If you need to be able to search archives via the web, we suggest an upgrade to a modern Windows operating system and LISTSERV Classic (Lite does not support the SEARCH command or web searches). L-Soft also has several hosting solutions available, ranging from hosting a single list to a full hosted LISTSERV site branded with your own domain and logos.
Please note that sending "SEARCH" commands via mail works fine on LISTSERV Classic for Windows 95.
(This restriction was removed in LISTSERV 1.8d.)
That said, if you are still running the LISTSERV Shareware on Windows 95 or Windows 98, you are very brave. Again, we recommend either switching to a hosted solution or upgrading to a non-shareware version of LISTSERV that will run on a newer Microsoft OS.
Comments on this FAQ should be sent to email@example.com. Please do not send support or sales inquiries to this address--it is for comments on the manuals only. If you need to ask a question that is not covered by this FAQ, please see our page entitled L-Soft Technical Support. Thank you!