The LISTSERV® Maintainer's Support FAQ
Last updated 4 May 2009
Note: List owners now have their own FAQ.
If you are running a non-VM release build of 1.8d or earlier (ie the build date shown in the "SHOW LICENSE" output is earlier than 16 July 2000) please see the security advisory found here.
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
or in chapter 2 of the Site Manager’s Operations Manual for LISTSERV.
Note carefully that if you are 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 running 1.8c or earlier, the solution is to upgrade to the current supported version. There are no Y2K patches for earlier versions.
L-Soft's official Y2K statement is linked here.
Question about recent changes to DST start/end dates? See here.
2. Windows-specific (NT/2000/XP and 9x)
Please note that 1.8e is the last version of LISTSERV to support Windows 95/98/ME.
At the present time there are no VMS-specific FAQ issues.
5. All platforms
6. Problems specific to previous releases
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.
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 ".
You need to execute "dbx lsv core" (or "gdb lsv core") and then type "where" (or "bt"). Then send this information to email@example.com. 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.
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 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.
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.
Note: This answer is unix-specific. Windows sites with a similar problem should see this FAQ, below.
The problem is that your outbound mailer does not support LISTSERV mail-merge. Mail-merge requires that LSMTP Classic be used as your outbound mailer because it employs a proprietary extension to the BSMTP command set that only LSMTP Classic implements. The error shown above is typical of sites that are using sendmail as the outbound mailer.
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, ie, 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.
Note carefully: If you're not running LSMTP to handle your outbound mail, LEAVE THIS VARIABLE SET TO ITS 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.
As a result, L-Soft developers have written a perl script called lsv-logger.pl which can be downloaded here, and which can be used as a filter to redirect LISTSERV's standard output into daily files, without the need to stop and restart LISTSERV.
Perl 5.6.1 or later is recommended. The script may work with earlier versions of Perl but we have not tested it with earlier versions.
Please note that there is no facility for compressing and deleting logs that are n days old. This must be scripted locally.
Sites running LISTSERV 1.8e-2002a or later use the following instructions. (If you are running an earlier version of LISTSERV, see below.)
0. Back up the 'go' script just in case.
1. Open the 'go' script in a text editor. Find the line
lsvlog="2>&1 >>$LOG_PATH/listserv-`date +%Y%m%d`.log"
2. Replace that line with
lsvlog="2>&1 | ./lsv-logger.pl $LOG_PATH"
3. Save the 'go' script.
4. If you have not configured a value for LOG_PATH in go.user, you should do so at this time. If LOG_PATH is null, the log gets written to "listserv.log" as before and lsv-logger.pl is ignored. Note that the "listserv" UID must own the directory specified in LOG_PATH, and must have RW permissions on it.
5. Copy the lsv-logger.pl script into the LSVROOT directory (same directory where the 'go' script lives).
6. Ensure that lsv-logger.pl is owned by 'listserv' and has permissions 700.
7. Stop and restart LISTSERV. Note that as always, LISTSERV must be started in the background, with 'go bg', in order for a log to be written.
At this point daily logs named listserv-yyyymmdd.log should start appearing in the directory pointed to by the LOG_PATH variable in go.user. These logs will autorotate at midnight without any need to stop and restart LISTSERV. Again, if LOG_PATH is left null, lsv-logger.pl will be bypassed and listserv.log will be written in the LSVROOT directory.
Sites running LISTSERV prior to the 2002a level-set release may be able to use the above instructions, with the following caveats:
1. There is no LOG_PATH variable pre-defined in 'go.user', nor is LOG_PATH exported in 'go'. It would therefore be necessary to add
to go.user in order to make this work. ("/path/to/logs" is typically something like "/var/log/listserv". Remember that the "listserv" UID must own that directory and must have RW permissions on it.)
2. Additionally, sites running LISTSERV prior to the 2002a level-set release must replace the following lines in 'go':
if [ -s listserv.log ]
mv listserv.log listserv.log.OLD
echo "> Starting LISTSERV as a background process"
with this block:
echo "> Starting LISTSERV as a background process"
if [ "$LOG_PATH" ]
lsvlog="2>&1 |./lsv-logger.pl $LOG_PATH"
if [ -s listserv.log ]
mv listserv.log listserv.log.OLD
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 15.5, LISTSERV will not run because it expects LDAP 2.3, and we have LDAP 2.2 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 default to 2.2. This is easy to fix; simply rename 'lsv' to 'lsv-precompiled' or similar, and relink lsv.o as follows:
Linux and Linux-2.6:
gcc -O -o lsv lsv.o nocli.o nooci.o -lldap
gcc -O -o lsv lsv.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.
On Windows NT/2000/XP, 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".
This can be narrowed to one of two things:
1. A glitch in the NT TCP/IP stack which occurs irregularly. This can normally be fixed by rebooting the machine. Note that this condition appears to have been fixed by one of the NT Service Packs for NT 3.51; if you are running NT 3.51 without a service pack or with a service pack earlier than SP5, we recommend applying at least SP5. We have not seen this problem in the TCP/IP stack under NT 4.0 (although for other reasons we strongly recommend that you apply at least SP3 for NT 4.0 if you are running LISTSERV) and it has not manifested itself in later versions of Windows so far as we are aware. Please note that L-Soft no longer supports LISTSERV under either Windows NT 3.51 or Windows NT 4.0.
2. 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 set to start up at boot time. Check your Control Panel/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.
I'm running Windows NT/2000/XP (or 9x/ME) and want to know if I can run a POP mail server (or other SMTP server) on the same machine as LISTSERV.
For Windows 9x/ME, the answer is no. For Windows NT/2000/XP, the answer is that the only SMTP servers currently available that will not conflict with LISTSERV are LSMTP and Software.Com's Post.Office version 3.1.x and later. The reason for this is that, due to the lack of a true Internet mail API for Windows systems, the SMTPL.EXE "listener" requires exclusive access to the SMTP port for incoming mail. Windows NT LISTSERV machines can use LSMTP in place of SMTPL.EXE because LSMTP has a built-in interface to process mail bound to LISTSERV and lists running on LISTSERV. And LSMTP for Windows NT has a built-in POP3 server.
For details on how to setup LISTSERV on Windows NT with Software.Com's Post.Office, please see the Windows NT installation guide that comes with your installation kit. You can also view the installation guide at the URL
or download a copy in rich text format at
L-Soft is currently reviewing other SMTP products for Windows machines to determine if they can be used with LISTSERV. Please note specifically that you cannot currently operate LISTSERV on the same machine with Microsoft Exchange Server, Novell GroupWise, Lotus Notes, or the IIS SMTP service (these being the ones we get the most questions about).
Please note that this restriction does not prevent you from running a Web server or FTP server on the same machine with LISTSERV. Web and FTP servers don't use the SMTP port, so there is no conflict.
Under 1.8d and 1.8e "wa" works fine under NT 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 the 1.8d release builds (late February 1998 and following), "wa" was rewritten to take advantage of LISTSERV's TCPGUI interface, which operates over TCP/IP instead of using named pipes. In order to make this work under NT, you must grant permission to use the Winsock TCP/IP subsystem to the user who is invoking "wa". Under IIS this is the IUSR_xxxx user; under other web servers this will be different. In any case this error can be remedied by using the File Manager or Windows NT Explorer to grant RX permissions (Read and Execute) for the "wa" invoker to the following files, which are found in %SystemRoot%\system32:
Once you have granted the permission, reloading the page should be all you need to do.
Additionally, a bug in 1.8d and 1.8e prior to the 1.8e-2003a level set release caused this to happen if DEFAULT_SPLIT was explicitly defined in SITE.CFG. If you are running an earlier version and have DEFAULT_SPLIT defined, you can work around this by removing DEFAULT_SPLIT from the configuration, then stopping and restarting LISTSERV. Or you can upgrade to the current version.
I have both LISTSERV and LSMTP installed at my site, and get this error when I try to send email to LISTSERV.
An error was detected while processing the enclosed message. A list of
the affected recipients follows. This list is in a special format that
allows software like LISTSERV to automatically take action on incorrect
addresses; you can safely ignore the numeric codes.
--> Error description:
Error-Text: Mailer example.org said: "554 Message looping (received 6
Error-End: One error reported.
------------------------------ Original message ------------------------------
Received: from mail.example.org (xxx.xxx.xxx.xxx) by mail.example.org (LSMTP
for Windows NT v1.1a) with SMTP id <0.5CCB7DC0@mail.example.org>; Thu, 12
Mar 1998 16:24:42 -0600
(repeats five times for a total of six)
You need to define "example.org" as a "local domain" in the LSMTP configuration. LSMTP must know about all its domains, otherwise it assumes they are remote and attempts to deliver via SMTP, thus causing the loop. It stops after six iterations because of the default configuration setting under "SMTP & Reports" that causes LSMTP to reject messages received more than 5 times.
Are there any known Windows service pack issues with LISTSERV and/or LSMTP?
We are not aware of any issues with the current Windows service packs.
For older versions of Windows (no longer supported by L-Soft), it is our recommendation that you apply at least SP6 for Windows NT 4.0 as it contains fixes to things like Year 2000 issues and the TCP/IP stack which have the potential to affect the operation of our products if you do not apply them. You may also want to apply certain of the available "hot fixes", for instance the one that prevents SYN attacks, at your discretion. We also recommend applying Service Pack 4 for Windows 2000. However, please note that L-Soft no longer supports LISTSERV under Windows NT 4.0 or earlier.
After applying a new LAK, eg, 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 NT 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--eg, 19990825 for 25 Aug 1999) 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. Also ensure that WA.EXE has the correct NTFS execute permission.
My LISTSERV (or - more usually - SMTPS) log is filling up with the following messages every second. What can I do about this?
29 Mar 2001 00:00:00 *** LSMTP extensions activated ***
29 Mar 2001 00:00:00 -> XMRG FROM: VERSION=1
29 Mar 2001 00:00:00 502 Sorry, mailmerge not allowed.
[or, if LSMTP isn't being used as your SMTP_FORWARD mailer, you may be
seeing something like this:]
29 Mar 2001 00:00:00 -> XMRG FROM: VERSION=1
29 Mar 2001 00:00:00 500 Command unrecognized: "XMRG FROM: VERSION=1"
Note: This answer is Windows-specific. Unix sites with a similar problem should see this FAQ, above.
In both of these cases the problem is that your outbound mailer does not support LISTSERV mail-merge. Mail-merge requires that LSMTP Classic be used as your outbound mailer because it employs a proprietary extension to the BSMTP command set that only LSMTP Classic implements.
The first error example shows what you get either when LSMTP Lite is being used as the outbound mailer, or when you have mail-merge explicitly disabled in LSMTP Classic. (LSMTP Lite does not have mail-merge support at all.)
The second error example is typical of sites that are using a remote sendmail machine as the outbound mailer.
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 DOS box, then CD into \LISTSERV\SPOOL and do
find /i "XMRG FROM" *.MAIL
from the DOS 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, ie, via the "Mail-Merge" command button in the web administration interface. If you are running LSMTP Classic to handle your outbound mail, you can allow list owners to perform mail-merge operations by setting
in site.cfg. Then stop and restart LISTSERV to pick up the change.
Note carefully: If you're not running LSMTP to handle your outbound mail, LEAVE THIS VARIABLE SET TO ITS DEFAULT!
The following appears in my SMTPS#x log file. What does it mean?
30 Aug 2004 10:57:51 Receive error: Unknown error 
30 Aug 2004 10:57:51 *** LSMTP extensions activated ***
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.
2.11. Error "rename() failed: Permission denied" appears at the bottom of web interface pages after upgrade to 15.5
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 earlier 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:
15 Oct 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).
First, it must be remembered that current versions of LISTSERV for Windows are 32-bit and, as such, are not able to access 64-bit 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 (for example, LISTSERV) 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.
At the present time there are no VMS-specific FAQ issues.
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.
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 = ''
5. All platforms
Please see the L-Soft international, Inc. Year 2000 Compliance FAQ for Year 2000 issues.
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 Jan 1997 13:06:59 >>> Error X'00C80025' loading license data <<<
3 Jan 1997 13:06:59 -> Severity: Severe error
3 Jan 1997 13:06:59 -> Facility: License control
3 Jan 1997 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 Jan 1997 13:08:26 >>> Error X'00C80015' loading license data <<<
3 Jan 1997 13:08:26 -> Severity: Severe error
3 Jan 1997 13:08:26 -> Facility: License control
3 Jan 1997 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 NT 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 NT 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.
(Windows 95 evaluation kit users should note that they actually download a file called license.win95, and that this file must be renamed license.merge before restarting LISTSERV. If you do not rename the file, LISTSERV will not find a license and will not start [as in the first example, above].)
Under Windows 95 and Windows NT 4.x, 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:
· Occasionally there is confusion between Solaris and SunOS. If you requested a SunOS LAK but are actually running Solaris, the SunOS LAK will be read in by the license manager but will not be accepted at run time.
· 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 on the workstation systems 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 NT or Windows 95.
· 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 NT or Windows 95 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 firstname.lastname@example.org... 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.
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 this workaround.
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) 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.
· Recently a duplication problem has cropped up with firewalls that have SMTP proxies which are not 100% compliant with standards. Until such time as the proxy can be fixed to work per the standard, the only solution is to contact the administrators at the receiving site and urge them to allow their firewalls to pass SMTP traffic through untouched by the proxy.
Recent versions of the Cisco PIX firewall prior to 5.2(4) (see below) exhibit this behaviour when its MailGuard feature is turned on. You can determine whether or not a given problem site is running the Cisco PIX firewall by telnetting to port 25 of its MX host and looking for a response that looks like this:
If you have LSMTP, the simplest way to check for this is to issue the command
lscp resolve /connect hostname
where hostname is the fully-qualified name of the host you want to check. The LSCP output will look something like this (all names and IPs changed or x'd out to protect the innocent):
E:\LSMTP>lscp resolve /connect EXAMPLE.COM
13:53:56 MX query for EXAMPLE.COM
13:53:56 trying (via UDP) DNS server xxx.xxx.xxx.x
status = %LSMTP-S-OK, Ok
cname = EXAMPLE.COM
firewall.EXAMPLE.COM 5 xx.xx.xxx.xxx
fw2.EXAMPLE.COM 15 xxx.xxx.x.xxx
13:53:56 connecting to firewall.EXAMPLE.COM
13:53:56 firewall.EXAMPLE.COM( 0) >>> 220 ***********************2*************
13:53:56 firewall.EXAMPLE.COM( 0) <<< QUIT
13:53:57 firewall.EXAMPLE.COM( 0) >>> 221 firewall closing connection.
(You can also do this via the WinLSCP GUI's "Resolve" window, but it is easier to cut and paste the data from the DOS box if you need to send it to a site administrator.)
Once you've determined whether or not a site is behind a Cisco PIX server, the solution which you can share with the site adminstrators is as follows:
It appears that the mail server for [insert host] is running behind
Cisco PIX firewall with the "Mailguard" feature turned on. Cisco has
confirmed that there is a known problem with this configuration that will
occasionally cause mail loops on selected e-mail messages. Please
contact the firewall administrators and ask them to remove this line:
default fixup smtp 25
from the configuration or enter the command:
no fixup protocol smtp 25
on the PIX server. This action should stop the looping e-mail messages.
In addition, assuming you are running LSMTP, you can cancel the mail it is attempting to send to the affected recipient(s).
First, from a command line in the \LSMTP directory, issue:
x:\LSMTP>LSCP SHOW QUEUE /DEST=example.com
which will list the entries in the queue for that destination. The one(s) that is/are looping is/are the one(s) that have a non-zero "Rtr" value. For example:
x:\LSMTP>LSCP SHOW QUEUE /DEST=example.com
Entry-.Message---- Size---- Rcp Rtr Since------- R Destination-----------------
000160.02.FF950995 4640 001 040 2 20:16:04 S EXAMPLE.COM
000194.04.FF26FA6E 27063 001 000 0 00:00:47 S EXAMPLE.COM
In the above, if example.com mail is looping, then you can see that entry #160 is the one that is looping because the Rtr is 40. By contrast, entry #194 may well be delivered without incident in the next few minutes, so you don't want to arbitrarily remove all of the queued entries for EXAMPLE.COM.
To remove entry #160 from LSMTP's queue, you would then issue:
x:\LSMTP>LSCP REMOVE ENTRY 160
LSMTP will respond:
Are you sure (yes/no) [YES]
enter YES or just hit enter (default response is YES), after which LSMTP will respond:
1 entry removed
Cisco Resolution: Cisco have confirmed that this behaviour is due to a bug in the PIX firewall product prior to release 5.2(4), and they recommend that sites running earlier versions of the Cisco Secure PIX Firewall upgrade to version 5.2(4) or later. They further have confirmed that this problem is not limited to mail received from sites running LSMTP. (A quick Google search indicates at least two other SMTP server vendors reporting the same problem.)
This issue is assigned Cisco bug ID CSCds90792 and is considered resolved by Cisco in Release 5.2(4) of the PIX Firewall product, per the Release Notes document at:
You'll need to page down a bit to find "CSCds90792" in the listing of "Resolved Caveats - Release 5.2(4)". (We found it at the fifth bullet point.)
Once you get there, it reads:
The fixup smtp command no longer blocks email separated by a packet
when the "." and "" are the termination sequence and are
split across multiple TCP frames.
Unfortunately the original bug report does not appear to be available on the Cisco web site. For additional information about the problem, sites involved will need to contact Cisco with the bug ID given above.
Turnaround time on mail sent to LISTSERV or to lists on my server is poor.
On unix machines, check the version of Sendmail you are using. Some commercial unixes ship with Sendmail version 5 or earlier, which can handle at most a few thousand deliveries/day. L-Soft recommends that any unix site running LISTSERV upgrade to the standard UCB Sendmail version 8.7.x or higher. (Note: It is very unlikely that anyone is still running Sendmail 5, but we will leave this here just in case.)
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 LSMTP 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.
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.
Starting with 1.8c, 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.
Our LISTSERV is running on LISTSERV.MYCORP.COM, but the "From:" field reads WWW.MYCORP.COM.
This is due to using a sendmail that rewrites the address and having LISTSERV.MYCORP.COM as a CNAME in your DNS. You can fix it by telling sendmail not to rewrite addresses (but be aware that this will work only until the mail reaches another sendmail 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. If you decide to change your sendmail.cf to remove the rewrite rule, be aware that this is a long change that is only short in the 'meta' config files for V8. Previous versions will require that you change a substantial number of lines.
(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 restriction has been removed in 1.8d but L-Soft still does not recommend using logical filemodes for this purpose.)
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 (NT/Win95) and then making a separate sub-directory under that for each list you have. As an example, under NT 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
Note that 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 NT, you must ensure that the IUSR_xxx user 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?
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 NT 4.0 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. For 1.8d and later, the code has been changed to simply ignore files with spaces in the filename so this error should not occur unless you are running an older build of the software.
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 1.8e 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 (RFC 821 [STD 0010] as updated by RFC 1123 [STD 0003]) 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.
The specific sections of the standards that apply are:
Excerpted from RFC821 (STD 0010) Sect 3.6:
Of course, server-SMTPs should not send notification messages about problems with 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 relayed it is permissible to leave the reverse-path null. A MAIL command with a null reverse-path appears as follows:
Excerpted from RFC1123 (STD 0003) Sect 5.2.9:
Command Syntax: RFC-821 Section 4.1.2
The syntax shown in RFC-821 for the MAIL FROM: command omits the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page 15). An empty reverse path MUST be supported.
Can the text "L-Soft list server at [...] ([version number])" be removed from mail coming from LISTSERV?
From LISTSERV 14.3, the PLAIN_FROMLINE site configuration variable allows you to do this. For versions prior to 14.3, it is not possible.
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, eg, setting this variable to "1" would result in
From: "Example Company LISTSERV Server (14.3)" <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 email@example.com subscribed to the list mentioned, you should be able to issue a "DELETE XYZ firstname.lastname@example.org" command to (for instance) LISTSERV@LISTSERV.EXAMPLE.COM as long as the command comes from email@example.com (or firstname.lastname@example.org). 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; email@example.com can't issue commands on behalf of firstname.lastname@example.org.
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 email@example.com, 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.
Note however that all other commands (except for the "OK" command, which is a separate issue) are NOT case-sensitive. For instance, if you send a DELETE command for firstname.lastname@example.org, it will delete not only email@example.com, 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.
Note also that 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?
LISTSERV 1.8e: Yes. From the release notes:
LISTSERV Version 1.8e supports real-time anti-virus scanning of all messages sent to mailing lists that run under LISTSERV Classic or LISTSERV Classic HPO on Windows NT/2000/XP 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 in 1.8e is available only for Windows NT/2000/XP 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.
LISTSERV 1.8d and earlier: No. There are no "hooks" in LISTSERV that would lend themselves to easy scanning for malignant attachments in mail sent to lists. L-Soft's position on virii and worms in mail sent to LISTSERV lists is that the best place to handle such things is at the campus or enterprise gateway, with existing products that are specifically written to perform this task.
From a user standpoint the usual education is indicated--never execute a file sent you by a non-trusted source; scan all .ZIP 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.
If you have upgraded to the 1.8d 2000a "level set" release of LISTSERV (announced on 5 May 2000) or later, your 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.
Starting with the version 1.8d 2000a "level set" release of LISTSERV, announced and made available on 5 May 2000, 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 level set release notes for information on how to configure Attachments=.
Note carefully that Attachments= works only for properly-configured MIME attachments. It will not strip or filter (for instance) uuencoded files that are simply cut and pasted into the body of a posting. The only way to reject such postings would be to use the pre-2000a workaround of setting the Sizelim= list header keyword to reject mail more than a specified number of lines in length, which can have the side effect of rejecting mail containing binary attachments (assuming the attachments push the length of the mail over the number of lines you specify; it won't catch all attachments). To limit the number of lines you code
* Sizelim= xxx
in the list header (where "xxx" is the number of lines). This has to be done on a list-by-list basis; there is no global setting. Generally a setting of 200-250 lines is sufficient to allow legitimate mail through but reject most large attachments. Note carefully that setting Sizelim= for a given list is not a guarantee that your list will remain virus-free, since it is entirely possible that a virus propagated by a non-MIME method (and thus being able to slip through regardless of any Attachments= setting you might have) might be smaller than your Sizelim= setting. Sizelim= is just one more tool that you can use to help keep the larger virii off your lists.
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).
A list of registered MIME media types for attachments is kept by IANA and can be found at
After upgrading from 1.8c to 1.8d or 1.8e, the web archive interface still works fine, but I can't access the list and server management features. When I try to do so I get
Error - invalid parameter
An invalid parameter was passed to the CGI function. Please
report this error to the webmaster and make sure to specify
the full URL that led to this message.
It is most likely that you did not copy the new 'wa' script that was shipped with your kit into the CGI directory pointed to by the WWW_ARCHIVE_CGI variable in your site configuration file. Version 1.8c 'wa' does not know anything about the web management commands introduced in version 1.8d, and thus considers your access attempt to be using invalid parameters. Please revisit the upgrade instructions in the installation guide and ensure that you have copied the 'wa' script per the instructions.
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 7.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. 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 in Appendix C of the Site Manager's Operations Manual 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 (ie, 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:
firstname.lastname@example.org 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 email@example.com 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 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 NT and IIS for instance this would be the IUSR_xxx user created when IIS was installed.
I added a list to my server, and after adding that list, my Web interface changed from having the pull-down box to select my list, to a blank text box to enter the list name into. How do I make it go back to using the pull-down list box?
Normally this is limited to the pre-1.8e web interface. As documented in 11.4 of the manuals, list owners who have only one or just a few lists running on the server will be presented with a drop-down list box from which they can choose the list they want to work on (only their own lists will be displayed). Site maintainers will either see the drop-down list box (on servers with up to 50 lists) or a plain text box (on servers with 51 or more lists). The limit is not configurable, so if you have more than 50 lists on the server, as a LISTSERV maintainer you will always get the text box.
In LISTSERV 1.8e, lists are displayed in groups of 50, which are selected by clicking on the links displayed beneath the drop-down text box. For instance you should see something like the following:
If you are running 1.8e with more than 50 lists and still observe the 1.8d behaviour, it is likely that you have made substantial modifications to the web interface templates that will need to be redone from scratch for 1.8e, or you have not completely installed your 1.8e upgrade (the latter is typically seen under unix when LISTSERV Classic sites do not apply the common.tar.Z archive along with the `uname`.tar.Z archive at upgrade time).
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
In 1.8d and later, 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.)
Sites running 1.8c or earlier cannot suppress the information.
When attempting to start LISTSERV, the following error is thrown and LISTSERV terminates.
5 Feb 2001 11:00:37 LISTSERV(R) for Windows version 1.8d starting...
5 Feb 2001 11:00:37 Copyright L-Soft international 1986-2000
5 Feb 2001 11:00:37 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 is still connected to BITNET (and there are fewer and fewer every day), 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 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 the report section I see only 2003 at the end of the report. How about 2004?
This is a known issue that will be addressed in a forthcoming update. In the meantime you can update this yourself by applying the following fix:
You can add entries for 2004 by editing the Site-Wide Dynamic Template LOG-MAIN. Simply go to the server management section in the web
interface, choose "Customize site-wide dynamic web templates", then choose LOG-MAIN from the dropdown list. You'll see an area that looks like this:
<option value="1997" &+SEL_a1997;>1997
<option value="1998" &+SEL_a1998;>1998
<option value="1999" &+SEL_a1999;>1999
<option value="2000" &+SEL_a2000;>2000
<option value="2001" &+SEL_a2001;>2001
<option value="2002" &+SEL_a2002;>2002
<option value="2003" &+SEL_a2003;>2003
Add one line at the bottom like this:
<option value="2002" &+SEL_a2002;>2002
<option value="2003" &+SEL_a2003;>2003
<option value="2004" &+SEL_a2004;>2004 <-added new line
and later on,
<option value="1997" &+SEL_A1997;>1997
<option value="1998" &+SEL_A1998;>1998
<option value="1999" &+SEL_A1999;>1999
<option value="2000" &+SEL_A2000;>2000
<option value="2001" &+SEL_A2001;>2001
<option value="2002" &+SEL_A2002;>2002
<option value="2003" &+SEL_A2003;>2003
Again, add one line at the bottom (observe that the case is different, so don't simply paste the same line twice):
<option value="2001" &+SEL_A2001;>2001
<option value="2002" &+SEL_A2002;>2002
<option value="2003" &+SEL_A2003;>2003
<option value="2004" &+SEL_A2003;>2004 <-added new line
In sum: Just add the appropriate option tag for 2004 in each spot (note: the above sections are case-sensitive!) and click Update.
That will give you a 2004 option where required.
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, with the following prerequisite depending on what version of LISTSERV you are running:
· LISTSERV 14.4 or later: LISTSERV's Embedded Mail Merge feature must be enabled.
· LISTSERV prior to version 14.4: LISTSERV's legacy SMTP mail product LSMTP Classic must be handling LISTSERV's outgoing mail. LSMTP Lite does not support mail-merge and cannot be used for this purpose.
One of the above requirements being satisfied, there are three options.
1. Send a list-based mail merge job. This essentially gives you complete control over what appears in the headers of the messages that are distributed.
the FULL822 subscription option. This option was originally devised to deal
with certain types of non-standards-compliant mail servers which no longer are
in wide use and so its use is deprecated, but it will do what you want.
Before using this option, make sure that USE_LSMTP_MAIL_MERGE is set to 1 in LISTSERV's site configuration file, as otherwise it will use up an inordinate amount of system resources.
To make it so that your subscribers are set to the FULL822 option, add the following line to the mailing list's configuration:
and issue the following command in the body of a message to listserv@...:
QUIET SET listname FULL822 FOR *@*
list-based mail-merge via the web interface. Add to List Header:
Add to the site configuration file:
Then send the message via the WWW Interface (this generates an internal list-based MM job, which ends up making this option similar to #1, but does not require the user to create a mail-merge job by hand).
LISTSERV itself doesn't know anything about SPF/DomainKeys, which are handled at the SMTP server level. It will, however, pass mail signed with these systems without altering the signature.
LSMTP does not support SPF/DomainKeys, and L-Soft recognizes that this may cause a problem for people using LISTSERV's mail-merge feature. Therefore, starting with LISTSERV 14.4, LSMTP is no longer required for mail-merge operations. LISTSERV's Embedded Mail Merge feature means that you can now send all your mail-merge traffic through an SMTP server that supports SPF/DomainKeys signing.
Unfortunately the 14.3 release notes left out a very important step for enabling this new feature.
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
The IETFHDR subscriber option was added in LISTSERV 1.7b (November 1991). 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.
If IETFHDR is specified, these rules prevent LISTSERV from appending subject-tags and/or making other modifications to the email headers.
Those interested in the history of the IETFHDR option may wish to review the following LSTSRV-L postings:
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 14 Feb 2007 this was 3.0).
5.42. What is the difference between "mail delivered"
and "mail posted" in the LISTSERV log?
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.
5.43. "Error X'0000006B' looking up LDAP account" thrown after first configuring LDAP via the web interface (15.5)
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:
Because this is easily worked around in the field, the
issue will be fixed in the next version of LISTSERV.
6. Problems specific to previous releases
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 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 running 1.8c or earlier, the solution is to upgrade to 1.8d. Again, there are no Y2K patches for earlier versions.
If you are running a non-VM release build of 1.8d or earlier (ie the build date shown in the "SHOW LICENSE" output is earlier than 16 July 2000) please see the security advisory found here.
The bottom line is that if you are still running LISTSERV 1.8c or earlier, 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.
At this point, it means that you are running a Linux ELF kernel and that you have a very old copy of the Linux evaluation kit, which contains an lsv.o file that was compiled in a.out format under a Linux 1.x kernel. You should discard this kit and get a new one. The Linux kits currently on our server are supported under Linux 1.2.13 and later kernels running with ELF support. Download the following files:
L-Soft no longer supports LISTSERV under Linux kernels earlier than 1.2.13.
I'm running LISTSERV on OSF/1 (Digital Unix), and on the ‘listserv’ account I get many messages like this:
>Unaligned access pid=3804 va=141c62f4 pc=12071954 ra=12071928 type=ldq
The kernel fixes unaligned accesses, so this only affects performance. We fix them when reported, but most people ignore them because they don't have much of an impact. That is, when people migrate their applications to OSF/1, they find that many produce these errors, so they end up just disabling them for the entire system. Note that unaligned accesses are specific to OSF/1 (or Digital Unix).
When reporting an unaligned access problem, first please do SHOW LICENSE and let us know the build date. Then use the uac command to request a core dump on the unaligned access, then do 'dbx lsv core' and 'where' and send us the traceback.
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
This is a bug in the code for LISTSERV 1.8b that supports "tableless" operation. It has been fixed in LISTSERV 1.8c and later. If you need to run in "tableless" mode, please upgrade to the current version (contact your sales representative if you need a new LAK).
Note that all Windows 95 shareware servers run in "tableless" mode regardless of the setting of the "RUNMODE=" configuration file variable.
This problem should not be an issue with early LISTSERV Lite servers as LISTSERV Lite was originally launched at the 1.8c code revision level.
After upgrading from IRIX 5.x to IRIX 6.x, LISTSERV refused to accept my valid LAK.
This happens only if you are running LISTSERV version 1.8c or older. LISTSERV 1.8d has a fix for the problem, which happens because SGI changed the output of 'uname' from "IRIX" to "IRIX64" between versions. There is no fix for this problem other than to upgrade to LISTSERV 1.8d. Note that this upgrade requires a 1.8d LAK, which must be requested from your sales representative if you do not already have one, and installed before you perform the upgrade.
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.
This is because you are using the precompiled lsv* binary shipped with the kit. If you have a compiler, you can eliminate this error by deleting the precompiled lsv* binary and recompiling it with the 'make server' command.
Note that if you do not have a compiler, you will not be able to do anything about this error.
When installing the LISTSERV evaluation kit for Windows NT, the setup program shows an hourglass but then terminates without doing anything.
This should not be happening with current Windows kits.
With very old Windows kits (1.8c and early 1.8d), this is a very strange problem that only seems to occur when the Netscape WWW server is running on the LISTSERV machine. The only solution is to stop Netscape Server until after the LISTSERV setup program completes. The problem appears to be related to Netscape and certain Windows setup engines and does not affect the operation of LISTSERV itself.
I have installed the "wa" (Web Archive) interface that came with 1.8c or later on my NT 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.
Generally this will occur if you are running the EMWAC, Netscape, or O'Reilly Website servers (it does not happen with IIS 3.0 or earlier), and is the result of a Microsoft documented restriction on the use of named pipes by the SYSTEM account. The solution is to do one of two things:
· In Control Panel/Services, set the web server service startup to log in as a privileged user other than the SYSTEM account (for instance, Administrator).
· Switch to IIS or another server product that does not require a privileged user to run scripts. (We’re not endorsing IIS specifically, it is simply one server that we know has the dual advantages of not having this problem and of being free.)
Note that if you have recently upgraded to IIS 4.0 (by installing the Windows NT 4.0 Option Pack from Microsoft) from IIS 3.0, you may find that you get this error from 'wa' when trying to do things like search, post to the list, or anything else that requires 'wa' to pipe a command to LISTSERV. We believe this to be due to a bug in IIS 4.0, specifically in the code that enables automatic password synchronization for the anonymous user stage. The only fix we are aware of is to open the Internet Service Manager, find the "wa.exe" executable in the tree, and then do the following:
1. Open the property sheet for "wa.exe" by double-clicking it
2. Click on the "File Security" tab
3. Under "Anonymous Access and Authentication Control", click on the "Edit..." button, which pulls up a dialog box entitled "Authentication Methods"
4. Click the "Edit..." button next to "Account used for Anonymous Access:" which brings up a dialog entitled "Anonymous User Account"
5. UNCHECK the box for "Enable Automatic Password Synchronization"
6. Click "OK"
At this point 'wa' should resume working again. You might need to type the password for the IUSR_xxxx account but our experience was that you needed only to uncheck the box and click OK".
This is a documented restriction (see the Site Manager’s Operations Manual) 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 Windows NT and LISTSERV Classic (Lite does not support the SEARCH command or web searches).
Please note that sending "SEARCH" commands via mail works fine on LISTSERV Classic for Windows 95.
(This restriction was removed in LISTSERV 1.8d.)
Comments on this FAQ should be sent to firstname.lastname@example.org. 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 Contacting L-Soft. Thank you!