L-Soft international, Inc.
Site Manager's Operations Manual
for
LISTSERV®, version 14.5
23 February 2006
Initial Release
The reference
number of this document is 0603-MD-01.
Information in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. L-Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document.
Permission is granted to copy this document, at no charge and in its entirety, provided that the copies are not used for commercial advantage, that the source is cited and that the present copyright notice is included in all copies, so that the recipients of such copies are equally bound to abide by the present conditions. Prior written permission is required for any commercial use of this document, in whole or in part, and for any partial reproduction of the contents of this document exceeding 50 lines of up to 80 characters, or equivalent. The title page, table of contents and index, if any, are not considered to be part of the document for the purposes of this copyright notice, and can be freely removed if present.
The purpose of this copyright is to protect your right to make free copies of this manual for your friends and colleagues, to prevent publishers from using it for commercial advantage, and to prevent ill-meaning people from altering the meaning of the document by changing or removing a few paragraphs.
Copyright © 1996-2006 L-Soft international, Inc.
All Rights Reserved Worldwide.
L-SOFT, LISTSERV and LSMTP are registered trademarks of L-Soft international, Inc.
LMail is a trademark of L-Soft international.
EASE and CataList are service marks of L-Soft international, Inc.
UNIX is a registered trademark of X/Open Company Limited.
AIX and IBM are registered trademarks of International Business Machines Corporation.
Alpha AXP, Ultrix, OpenVMS and VMS are trademarks of Digital Equipment Corporation.
OSF/1 is a registered trademark of Open Software Foundation, Inc.
Microsoft is a registered trademark and Windows, Windows NT and Windows 95 are trademarks of Microsoft Corporation.
HP is a registered trademark of Hewlett-Packard Company.
Sun is a registered trademark of Sun Microsystems, Inc.
IRIX is a trademark of Silicon Graphics, Inc.
PMDF is a registered trademark of Innosoft International.
Pentium and Pentium Pro are registered trademarks of Intel Corporation.
All other trademarks, both marked and not marked, are the property of their respective owners.
All of L-Soft's manuals for LISTSERV are available in ascii-text format via LISTSERV and in popular word-processing formats via ftp.lsoft.com. They are also available on the World Wide Web at the following URL:
http://www.lsoft.com/manuals/index.html
L-Soft invites comment on its manuals. Please feel free to send your comments via e-mail to MANUALS@LSOFT.COM, and mention which manual you are commenting on. (However, please do not send support questions to this address. See chapter 19 of this manual for appropriate support addresses.)
"Hot fix" revisions to this and other L-Soft manuals are posted as they are made to the master document, on the announcement-only mailing list:
LSOFT-DOC-UPDATES@PEACH.EASE.LSOFT.COM
A word about formatting: This manual was written in Microsoft Word 2000, and originally formatted to be printed on 8-1/2"x11" paper on an HP LaserJet 1000 series printer. When printing the manual on a different type of printer, or converting to a different word-processing program, it is highly likely that the formatting and pagination will change and it will be necessary to update the tables of contents and figures as well as the index prior to printing. The author has taken great pains to ensure that the pagination and formatting works properly with the particular printer mentioned above, and cannot be held responsible for what is, in the end, a limitation of the software used to produce the manual.
Reference Number 0603-MD-01
Preface: LISTSERV Command Syntax and Other Conventions
Editorial Note – New Version Numbering
LISTSERV Command Syntax Conventions
1.1. Changes and updates to the manual
1.2. New documentation is coming!
2. Differences Between Architectures and Implementations
2.1. Differences between architectures
2.2. Differences between LISTSERV and LISTSERV Lite
2.3. Operating Systems and Architectures Supported
4. A LISTSERV How-To for Site Managers
4.1. Installation/Startup Questions
Why do I need a DNS A record and a static IP number for my LISTSERV machine?
Can LISTSERV read mail from POP mailboxes?
How do I install the web archive/administration interface?
How do I add, change, and delete LISTSERV Maintainers (aka postmasters)?
How do I create passwords for postmasters, and what are they used for?
Does LISTSERV have a GUI interface?
5. Configuring your LISTSERV® site.
5.4. Installing and configuring LISTSERV's WWW Archive and Administration Interface
5.4.1. The WWW Archive Interface described
5.4.2. The WWW Administration Interface described
5.4.3. Installing a web server
5.4.4. Installing the web archive interface script
5.4.5. Creating a subdirectory for the archive interface
5.4.6. Configuring LISTSERV to activate the web archive interface
5.4.7. Customizing the web pages LISTSERV creates
5.4.8. Enabling individual lists
5.4.9. Enabling web-based bulk operations
5.5. The "spam" detector and anti-subscription-"spoofing" feature
5.5.2. "Anonymous" spam alerts
5.5.3. Subscription anti-spoofing feature
5.6.1. Registering LISTSERV Classic Servers
5.6.3. Automatic Registration for LISTSERV Lite Servers
5.8. Setting up archive and notebook directories for use with LISTSERV
5.9. DBMS and Mail Merge Functions
5.10. Synonymous host name registration via ALIASES NAMES
5.11. Real-Time Anti-Virus Scanning
6.1.1. List subscription commands (from most to least important)
6.1.2. Other list-related commands
6.1.4. Commands related to file server and web functions
6.1.5. Other (advanced) commands
6.2. List Owner and File Owner Commands
6.2.1. File management commands (for file owners only)
6.2.2. List management functions
6.3. LISTSERV Maintainer Commands
6.4. Sending commands to LISTSERV
6.5. Defining Personal Passwords
7. Creating and Maintaining Lists
7.2. Architecture-Specific Steps for List Creation
7.2.1. Unix: Creating required Sendmail aliases
7.2.2. OpenVMS: Creating required PMDF aliases
7.3. A sample checklist for creating lists
7.5. List Header Keywords and what they do
7.6. Retrieving and editing the list – some considerations
7.7. Adding a list password (obsolete since 1.8c)
7.8. Storing a modified list on the host machine
7.10. A sample list header file
7.12. Adding HTML to a list header for the CataList
7.12.2. Inserting a pointer to another list
7.12.3. Restrictions on the placement of equal signs
7.13. How to set up lists for specific purposes
7.13.1. Public discussion lists
7.13.2. Private discussion lists
7.13.7. Private edited/moderated lists
7.13.10. Restricted subscription lists with automatically-generated questionnaire
7.13.12. "Super-lists" and "sub-lists"
7.14. Merging existing LISTSERV lists
7.14.1. Merging list A into list B; list A user options not preserved
7.14.2. Merging list A into list B; list A user options preserved
7.14.3. Merging list A and list B into list C
7.15. Migrating lists from one site to another
7.15.1. Migrating lists from one LISTSERV site to another LISTSERV site
7.15.2. Migrating lists from non-LISTSERV sites
7.15.3. Migrating lists from Sendmail alias files, databases, etc.
7.16. Changing the name of an existing list
7.17. Bulk operations (ADD and DELETE)
7.17.2. Bulk DELETE operations
7.19. DomainKeys Message Signing (14.5)
8.1. What is the file archive?
8.2. Starting a file archive for your list
8.3. Filelist maintenance (VM systems only)
8.3.1. VM only: Creating a filelist
8.3.2. VM only: Adding FAC codes
8.3.3. VM only: Retrieving the filelist
8.3.4. VM only: Adding file descriptors to the filelist
8.3.5. VM only: File Access Codes (FAC) for user access
8.3.6. VM only: Deleting file descriptors from the filelist
8.3.7. VM only: Storing the filelist
8.4. The listname.CATALOG system on non-VM systems
8.4.1. Adding files to the SITE.CATALOG
8.4.2. Delegating file management authority
8.4.4. Updating the sub-catalog
8.4.5. Indexing the sub-catalog
8.5. Storing files on the host machine
8.6. Deleting files from the host machine
8.7. Automatic File Distribution (AFD) and File Update Information (FUI)
8.9. Where to find more information on File Archives
8.10.1. Setting up notebook archives for a list
8.10.2. Migrating old notebook archives to a new site (LISTSERV to LISTSERV)
8.10.3. Migrating old notebook archives (non-LISTSERV to LISTSERV)
8.10.4. Deleting old notebook archives
8.10.5. Indexing existing notebook archives
9. Creating and Editing LISTSERV's Mail and Web Templates
9.1. What LISTSERV uses templates for
9.2. The default template files and how to get copies
9.3. Mail template format and embedded formatting commands
9.3.1. 8-bit characters in templates
9.4. Creating and editing a <listname>.MAILTPL file for a list
9.4.2. Other available template forms
9.4.3. Tips for using templates
9.5. Storing the <listname>.MAILTPL file on the host machine
9.6. Other template files: DIGEST-H and INDEX-H
9.7. Templates and template forms for the WWW interface
9.7.1. Forms contained in DEFAULT MAILTPL
9.7.2. The www_archive.mailtpl file (optional)
9.7.3. The default.wwwtpl file
9.7.4. The site.wwwtpl file (optional)
9.7.5. National language template files (idiom.mailtpl) (optional)
9.8. Using the DAYSEQ(n) function
9.8.2. Rotating FAQ via the PROBE1 template and "Renewal= xx-Daily"
9.8.3. Calculating the value for DAYSEQ()
9.9. Serving up custom web pages for your list
9.9.1. A practical example: ADMIN_POST
9.10. Modifying the output of LISTSERV's HELP command (non-VM)
10. Interpreting and Managing LISTSERV's log files
10.3. Interpreting the LISTSERV log
10.3.2. Releasing and reallocating a disk slot
10.3.5. Daily error monitoring reports
10.3.6. Processing mail for local lists
10.3.7. Administrative mail (X-ADMMAIL)
10.3.8. DISTRIBUTE jobs from remote hosts
10.3.9. Requesting "OK" confirmation for commands
10.3.10. Subscription summary updates (SUPD jobs)
10.3.11. Global list of lists updates (LUPD jobs)
10.3.12. Valid "OK" confirmation received
10.3.13. Invalid "OK" confirmation received
10.3.14. User is already subscribed to a given list
10.3.15. User has included non-command text (e.g., a .sig file) in his mail to LISTSERV
10.3.16. Response to list owner or LISTSERV maintainer commands
10.3.18. Command forwarded via GLX from another host
10.3.19. Netwide DELETE (X-DEL jobs)
10.3.20. FIOC cache notifications
10.3.21. Web archive/administration interface logging (starting with 1.8d)
10.3.24. Responses to LVMON@VM.SE.LSOFT.COM
10.3.25. MIME parser messages (1.8e)
10.3.26. Content filter rejection message (1.8e)
10.4. Interpreting the SMTP logs (Windows servers only)
10.5. Interpreting the SMTP "worker" log entries (non-VM only)
10.7. Using LISTSERV logs and SHOW CTR to extract server statistics
10.7.1. Sample log-processing scripts
10.7.2. Interpreting the output of SHOW CTR
10.8. Using the system changelog to track distributions
10.9. Logging changelog information to a DBMS
11. Using the Web Adminstration Interface
11.1. Default LISTSERV Home Page
11.3. Setting a LISTSERV password
11.4. The List Management main page
11.5. Maintaining subcriptions via the web
11.5.1. Examine or delete a subscription
11.5.2. Add a new user to the list
11.6. Maintaining the list header via the web
11.7. Customizing how a list's pages look
11.8. Maintaining mail and WWW templates via the web
11.9. Bulk operations via the web
11.10. Sending interactive commands via the web
11.12. Server administration interface
12. Distribution Features and Functions
12.1. Controlling the default level of acknowledgement to user postings
12.2. Controlling the maximum number of postings per day
12.2.1. Controlling total postings to the list per day
12.2.2. Controlling the number of postings per day from individual users
12.3. Controlling "prime" time
12.4. "Holding" and "freeing" a list
12.5. Controlling the list digest feature
12.7. Allowing/Blocking MIME Attachments
13. Error Handling Features and Functions.
13.1. Defining list-level error handling addresses
13.2. The auto-deletion feature
13.3. LISTSERV's loop detection feature
13.3.1. The anti-spamming filter
13.4. RFC822 mail header parsing
13.5.1. Active address probing
13.5.2. Passive address probing
13.5.3. OS-specific issues with probing
13.6. Defining server-level error handling addresses
13.6.2. Crash reports and CRASH_MONITOR=
14. List Maintenance and Moderation Features and Functions
14.1. Setting up edited/moderated mailing lists
14.2. Restricting the size of messages posted to the list
14.3. Restricting the number of posts per user per day
14.4. Moving a list to a new location: the New-List= keyword
15. Security Features and Functions
15.1. First line of defense: The VALIDATE= keyword
15.2. Controlling subscription requests
15.3. Controlling the service area of the list
15.4. Controlling who may review the list of subscribers
15.5. Controlling who may access the notebook files
15.6. Controlling who may post mail to the list
15.7. The "OK" confirmation mechanism
15.7.1. Explicitly cancelling "OK" cookies (1.8e)
15.8. Denying Service to Problem Users
15.8.1. The "Filter=" list header keyword
15.8.2. The "FILTER_ALSO" configuration file variable
15.8.4. The POST_FILTER list exit point
15.9. Hiding selected header lines
15.10. Tracking subscription changes with the Change-Log keyword
16. Subscription Features and Functions
16.1. Setting up subscription confirmation
16.2. Defining default options for subscribers at subscription time
16.3. Setting up subscription renewal
17. Other Features and Functions
17.1. Setting up national language mail templates
17.2. Translating control characters included in list mail
17.3. Communicating with list owners
17.3.1. The listname-REQUEST alias
17.3.3. Configuration required for unix servers and VMS servers running PMDF
17.3.4. Other aliases used by LISTSERV
18. Special Functionality for ISP's
18.1. Directory quotas for individual lists
18.1.2. Displaying quota information
18.1.3. Reloading quota information after making changes
18.2. Limiting the number of subscribers to a list
Appendix A: Command Reference Card for LISTSERV® version 14.5
Appendix B: List Keyword Reference for LISTSERV® version 14.5
Appendix C: Site Configuration Keyword Reference for LISTSERV® 14.5
Appendix D: Sample Boilerplate Files
Appendix E: Related Documentation and Support
List of Tables and Figures
Table 5.1. LISTSERV site configuration variables
Figure 6.1. Sample output of an INDEX listname command.
Figure 7.1. A sample list header.
Figure 7.2. A sample list header file for a list called MYLIST.
Figure 7.3. The edited list header file ready to be sent back to the server.
Figure 8.1. Sample filelist retrieved with (CTL option.
Figure 8.2. Adding a file descriptor to the filelist
Figure 9.1. The default contents of the INFO template form of DEFAULT.MAILTPL.
Figure 9.2. Sample edited INFO template form.
Figure 9.3. Typical contents of a DIGEST-H or INDEX-H file.
Figure 10.2. Typical SMTP log for the SMTPL.EXE "listener"
Figure 10.3. Typical SMTPS log for the SMTPW.EXE SMTP "workers"
Figure 13.1. A typical daily error monitoring report.
Figure 13.2. Sample RFC822 parser error.
Figure 15.1. The editor-header for a list set to Send= Editor,Hold
Figure 15.2. A typical command confirmation request.
Figure 16.1. Typical daily subscription renewal monitoring report.
Figure 18.1. Typical output of a SHOW QUOTA command issued by privileged user
Table B.1. LISTSERV list-level commands and how they are affected by Validate=.
Preface: LISTSERV Command Syntax and Other Conventions
Editorial Note – New Version Numbering
With this release, L-Soft is aligning LISTSERV’s version numbering with the rest of the e-mail industry. There have been 50 released versions of LISTSERV since 1986 – 14 major upgrades and 36 minor releases. Version 1.8e in the “traditional” numbering system corresponds to 14.0, and the present update to 14.5.
Because the old nomenclature is more familiar to our users, in this version of the documentation we will continue to refer to versions of LISTSERV inferior to version 14.4 by the old versioning system.
LISTSERV Command Syntax Conventions
Generally, parameters used in this document can consist of 1 to 8 characters from the following set:
A-Z 0-9 $#@+-_:
Deviations from this include:
|
fformat |
Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail |
|
full_name |
first_name [middle_initial] surname (not your e-mail address). Must consist of at least two space-separated words, for example, "John Doe". |
|
listname |
name of an existing list |
|
node |
Either: the fully-qualified domain name (FQDN) of an Internet host; or the BITNET nodeid or Internet hostname of a BITNET machine which has taken care of supplying an ':internet' tag in its BITEARN NODES entry; |
|
host |
Generally the same as node, but normally refers specificallly to the fully-qualified domain name (FQDN) of an Internet host rather than to a BITNET nodeid. |
|
pw |
a password containing characters from the set: A-Z 0-9 $#@_-?!|% |
|
userid |
Any valid RFC822 network address not longer than 80 characters; if omitted, the 'hostname' part defaults to that of the command originator |
|
internet_address |
Similar to userid, but specifically refers to a complete RFC822 network address in userid@fqdn format. When we use this nomenclature a fully-qualified hostname is required. |
Other deviations from the standard set will be noted along with the affected commands.
Also please note the following conventions for representing variable or optional parameters:
|
italic type |
always indicates required parameter names that must be replaced by appropriate data when sending commands to LISTSERV |
|
< > |
Angle brackets may sometimes enclose required parameter names that must be replaced by appropriate data when sending commands to LISTSERV. Sometimes used for clarity when italic type is inappropriate |
|
[ ] |
Square brackets enclose optional parameters which, if used, must be replaced by appropriate data when sending commands to LISTSERV |
This manual makes the following assumptions:
· You are a system administrator of a VM, VMS, unix, Windows NT/2000/XP/2003 or Windows 95/98/Me system (or in any case, a person with root- or system-level administrative privileges) whose assignment it is to be the LISTSERV maintainer;
· You have already installed the current version of L-Soft’s LISTSERV on your system in accordance with the installation instructions that come with the package, and have it running;
· You have sufficient knowledge (or know where to find it) of your system mailer to fine-tune it without needing instructions from this manual.
In other words, we expect you already to be knowledgeable about the system on which you plan to install and run LISTSERV. This manual does not contain installation instructions; individual installation guides for the four general types of operating systems supported by L-Soft can be found at http://www.lsoft.com/manuals .
L-Soft international’s LISTSERV software is designed to run on various platforms that have widely-differing configurations. Therefore it is not within the scope of this manual to describe in detail (for instance) how you can tune sendmail 8.7.3 under Linux for optimum performance with LISTSERV. However, general tips that could work on all systems will be offered within these pages.
Overall you will find that LISTSERV works much the same way on a unix workstation or a VMS minicomputer or an Intel Pentium machine running Windows 2000 as it has since 1986 on VM mainframes. Where LISTSERV procedures do differ between platforms, we will detail those differences in order to minimize confusion.
1.1. Changes and updates to the manual
When we find a mistake in the manual, or when between-release features are added, we normally report changes to the manual to the announce-only mailing list LISTSERV-DEVELOPERS@PEACH.EASE.LSOFT.COM , provided as a free service for our customers.
Other changes are documented in the Revision History, found in Appendix F.
1.2. New documentation is coming!
L-Soft has committed to the production of completely new documentation for the LISTSERV product. The new documentation is targeted to become available with LISTSERV 15 (no release date has been set).
2. Differences Between Architectures and Implementations
This chapter outlines differences between how LISTSERV is implemented on VM and non-VM machines, and the differences between LISTSERV and LISTSERV Lite.
2.1. Differences between architectures
In version 14, LISTSERV running under VM continues to differ in some regards from its counterparts on the other architectures. Here is a short list of these differences:
· VM: The web interface is not available.
· VM: Rotating change-logs are not available.
· Non-VM: Only a subset of the VM file server functions are available
· Non-VM: Certain rarely-used commands (e.g., STATS listname) are not available
· Non-VM: FUI (File Update Information) and AFD (Automatic File Distribution) are not available
Note that LISTSERV 14 running on non-VM systems actually has about 98% of the functionality of the VM version, and nearly 100% of the functionality that people actually use day-to-day.
There are actually two different file server systems in operation across the LISTSERV network. One is the original version running on VM, which includes the ability to create "filelists" (indexes) which point in turn to more files which can be stored on the server, and the AFD and FUI functions mentioned above. This file server system, while still quite powerful and easy to use, is unfortunately written in a non-portable language, making a complete rewrite from the beginning a necessity. There has been no change in the VM file server from 1.8b through 1.8e (and subsequently 14.x).
The second file server system currently in operation runs on the VMS, unix, and Windows ports of LISTSERV. This is in essence still a subset of the old system in which the LISTSERV maintainer creates entries in a SITE.CATALOG file for each file that will be made available to users. With the release of 1.8c, it became possible for the LISTSERV maintainer to create sub-catalogs, which can be maintained by list owners or other responsible people. 1.8d added the GIVE command and the ability to create file "packages" to the non-VM versions. For more information, please see chapter 8 of this manual.
L-Soft is still developing LISTSERV's file server, which will eventually include a super-set of the original VM file server command set. Complete details are not available as of this writing, but pains are being taken to ensure that the most common commands will not change along the development path. This will help to keep a great deal of existing documentation that has been passed along the Internet from becoming obsolete overnight. The fully-developed file server is scheduled to include AFD (Automatic File Distribution) and FUI (File Update Information) in addition to other new functionality.
The WWW List Archive and List Management Interface
In Version 1.8c, a web-enabled List Archive Interface was introduced. In 1.8d, the interface was expanded to include list and site management features. The interface as been significantly rewritten for version 1.8e and is fully documented in chapter 11 of this manual. The web interface continues to be unavailable on VM but is available on all other platforms on which the software runs.
Year 2000 Compliance
Year 2000 compliance is addressed in L-Soft's Year 2000 Compliance FAQ, which can be viewed at http://www.lsoft.com/corporate/default.asp?item=y2k .
2.2. Differences between LISTSERV and LISTSERV Lite
LISTSERV Lite is LISTSERV running with a special license activation key (LAK) which limits what you can do with the software. With the Free Edition of LISTSERV Lite (activated by a LAK which is both free and perpetual), you can run up to 10 mailing lists as long as you do not derive a profit from this activity. You can also purchase LISTSERV Lite LAKs that allow more (or unlimited) lists.
However, note carefully that LISTSERV Lite does not have all of the functionality of the full, Classic version--a list of the keywords and functions disabled in LISTSERV Lite follows this paragraph. For more information on the exact terms and conditions under which you may run LISTSERV Lite, please see L-Soft's World Wide Web site or contact L-Soft's sales department.
LISTSERV Classic Keywords disabled in LISTSERV Lite
|
Change-Log |
Confirm-Delay |
DBMS |
Default-Topics |
|
Editor-Header |
Exit |
Files |
Indent |
|
Internet-Via |
Language |
List-Address |
List-ID |
|
Local |
Long-Lines |
Loopcheck |
Mail-Merge |
|
Mail-Via |
Misc-Options |
Moderator |
New-List |
|
Newsgroups |
NJE-Via |
Peers |
Prime |
|
Renewal |
Sender |
Service |
Sizelim |
|
Stats |
Sub-Lists |
Topics |
X-Tags |
Note: the fact that the keyword is disabled only means that the default value cannot be changed. For instance, loop checking is still present, you just cannot control the details of its operation. On the other hand, if the default value is that the function in question is disabled (as is the case with "Peers="), then the function is actually gone. See Appendix B for more information on keyword defaults.
A feature comparison chart follows on the next page.
|
Comparison chart: LISTSERV Lite vs. LISTSERV Classic
(Version numbers in parenthesis indicate version in which the feature first became available, starting with LISTSERV 1.8d)
(*) The probe feature does not work with all MTAs (mail servers), or may only work with recent enough versions.
(**) Networked and Standalone RUNMODEs are not available in the Free Edition of LISTSERV Lite, but are available in the commercial version of LISTSERV Lite. |
2.3. Operating Systems and Architectures Supported
LISTSERV 1.8e (14) is the last version for several operating systems which have become obsolescent over the life of this product cycle. The operating systems which will no longer be supported after this version are:
Windows NT 4.0 SP6/6a (see note!)
Windows 95/98/Me
BSDi (Intel)
IRIX (MIPS)
Solaris-x86 (Intel)
(Note: Windows NT 4.0 is no longer supported as of LISTSERV 14.3)
Sites running these operating systems should start planning now for a migration to a different operating system. Please contact your sales representative for further information.
Sites running the Windows 95 shareware should note that their licenses will not activate the product under Windows XP. Please contact your sales representative for alternatives if you are planning to upgrade to Windows XP (optionally you may migrate to the LISTSERV Lite Free Edition). Sites running the Windows 95 Lite Free Edition can simply upgrade to the Windows NT/2000/XP LISTSERV Lite Free Edition. (Naturally you may also elect to continue running LISTSERV under Windows 95/98/Me, but there will be no further new versions or fixes for that platform.)
It should be noted that L-Soft dropped support for the following operating systems with the original release of LISTSERV 1.8e (14) (in other words, LISTSERV 13 or 1.8d was the last version for these platforms):
Windows NT 3.5, 3.51, 4.0 pre-SP6 (Intel)
Windows NT (Alpha AXP)
SunOS 4.x (SPARC)
Ultrix (MIPS)
OpenVMS (VAX)
VM/SP, VM/HPO
On the plus side, L-Soft now formally supports FreeBSD (Intel) and Linux (S/390) in LISTSERV 1.8e (14).
A comprehensive list of operating systems (and versions) under which LISTSERV is supported can be found at
http://www.lsoft.com/products/default.asp?item=listserv-ossupport
LISTSERV® is software that allows you to create, manage and control electronic "mailing lists" on a corporate network or on the Internet. Since its inception in 1986 for IBM mainframes on the BITNET academic network, LISTSERV has been continually improved and expanded to become the predominant system in use today. LISTSERV is now available for VM, OpenVMS, unixand the Windows NT "family" (including NT 4.0 SP6 and later, and Windows 2000).
Consider for a moment what the users of your electronic mail system actually use electronic mail for. Do they discuss problems and issues that face your organization, down to the departmental level? In an academic setting, do your faculty and students communicate via electronic mail? As with "real world" distribution lists, electronic mailing lists can make it possible for people to confer in a painless manner via the written word. The electronic mail software simply replaces the copying machine, with its associated costs, delays and frustrations. In fact, electronic mail lists are easier to use than most modern copiers, and a lot less likely to jam at just the worst possible moment.
Because electronic mail is delivered in a matter of seconds, or occasionally minutes, electronic mailing lists can do a lot more than supplement the traditional paper distribution lists. In some cases, an electronic mailing list can replace a conference call. Even when a conference call is more suitable, the electronic mailing list can prove a powerful tool for the distribution of papers, figures and other material needed in preparation for the conference call. And, when the call is over, it can be used to distribute a summary of the discussion and the decisions that were made. What before might have been an exchange of views between two or three people can now become an ongoing conference on the issue or problem at hand. Announcement lists and even refereed electronic journals can be made available to your audience, which can be as small as a few people or as large as the entire Internet community.
LISTSERV accomplishes its design goals very efficiently and very quickly. This is due primarily to its use of the proprietary DISTRIBUTE algorithm (described in RFC1429, and in the Developer's Guide for LISTSERV, available separately) and to the large (and growing) network of LISTSERV servers.
The LISTSERV network of servers helps to enhance LISTSERV's performance by providing a "backbone" through which large quantities of mail can be quickly distributed. The backbone also allows LISTSERV servers to "talk" to each other and exchange information. Among other things, this exchange of information between servers allows your own local server to participate in the global List of Lists service and L-Soft's CataList service on the World Wide Web (just point a web browser at http://www.lsoft.com/catalist.htmlto use the CataList service).
LISTSERV's nature as a distributed network of interconnected servers also makes it possible to identify and eliminate unsolicited advertisements sent to multiple lists (known colloquially as "spams") before they do much harm. While it is virtually impossible for a small isolated server to detect a spam (unless the sender listed the thousands of lists he was targeting in the "To:" field), for the simple reason that it will only ever receive a few copies for its own public lists, the LISTSERV network as a whole receives thousands of copies of the spam. By comparing notes with each other, the servers can quickly determine that a spam is occurring and raise a network-wide "spamming alert", stopping the message before it does much damage at all. Since the introduction of LISTSERV's anti-spam technology in version 1.8b, the growing number of sites that are participating in the anti-spamming warnings have virtually stopped the distribution of such messages in their tracks. L-Soft's developers are constantly upgrading and refining the anti-spam algorithms, to the effect that LISTSERV version 1.8e has an even better anti-spam filter than before.
In addition to the anti-spamming filter, LISTSERV also incorporates an anti-spoofing filter, to keep mischevious (and often malicious) users from subscribing other users to mailing lists in order to "mailbomb" them.
LISTSERV makes it possible for you to offer the same mailing list in four different formats:
· Individual mail messages sent out as they are processed
· Digest mode, where a compendium of messages processed by the list is sent at specified intervals
· Indexed mode, where an index consisting of the message number, sender, and the subject line of each message is sent each day, along with instructions on how to retrieve postings from the server
· Users can read, search, and respond to postings via LISTSERV's Web Archive Interface.
These modes are set by sending SET commands to LISTSERV. Unlike some other mailing list management systems, LISTSERV does not require the user to unsubscribe from one version of the list and resubscribe to another just to change delivery modes.
LISTSERV includes database search capability for list archive notebooks. A fast reverse indexing feature is available for servers running lists with large archives. Users can use a simple search syntax to comb list archives for specific terms of interest. And L-Soft provides a World Wide Web archive interface (not currently available on VM for technical reasons unrelated to LISTSERV itself) with which the notebook archives for all public lists can be viewed and searched from a web browser. The new WWW interface differs from (and has advantages over) "hypermail" style web archiving in that new postings are shown as soon as they are received; postings can be organized in a manner that best suits the reader; there is no duplication of effort, as the LISTSERV WWW interface works from the list’s notebook archives rather than creating a separate HTML file for each posting; and the list owner can customize the main page for their list by simply modifying their mail template file.
LISTSERV also includes a number of list and server management functions in its WWW interface, including the ability to edit list headers and associated mail and WWW templates, and to manage subscribers via the Web. These features have been substantially rewritten in LISTSERV 1.8e. See chapter 11 of this manual for details.
Since Version 1.8d LISTSERV has also contained DBMS and mail-merge support. These features are documented in the Developer's Guide for LISTSERV, available separately.
New in LISTSERV 1.8e is an Anti-Virus Scanning feature for messages passing through the server. This is a value-added enhancement which requires a special LAK and a special version of F-Secure Anti-Virus. At this writing the feature is only available for Windows NT/2000 and Linux servers running LISTSERV Classic or LISTSERV Classic HPO. (Other OS platforms may be supported in the future; there is no intent to make this functionality available in the Lite version of the product.)
Many other enhancements have been introduced in 1.8e. Please see the release notes for complete details at http://www.lsoft.com/manuals/index.html.
4. A LISTSERV How-To for Site Managers
This how-to section is not intended to replace the LISTSERV FAQs available from L-Soft's documentation web site (http://www.lsoft.com/manuals). It is an attempt to bring together certain basic operations and how to accomplish them in one place. However, note that some of these how-to answers will redirect you to existing external documentation or to other sections of this manual in order to avoid duplication of effort.
4.1. Installation/Startup Questions
Installation guides are available on the web and are also shipped in the version-specific installation kits. You can read the guides on the web at
http://www.lsoft.com/manuals/index.html
Why do I need a DNS A record and a static IP number for my LISTSERV machine?
The best analogy is to consider why you need to put a return address on a piece of postal mail that you expect someone to respond to (or to be returned to you if the person you are trying to reach no longer lives at the address you have for him). In order for people to be able to send mail to your server, it must have a "street address" so that the "postman" can deliver mail to it, and that "street address" must be known to the "post office" so that mail can be properly routed. The DNS A record tells the world where your LISTSERV machine is located by both its name (eg LISTSERV.EXAMPLE.COM) and its IP address, so that other mail machines on the Internet can correctly route mail to it. If the IP address is not static, in other words if it changes every time you dial up, or whenever you disconnect and reconnect your DSL service, it is not possible to add an A record for it to DNS. This is why both a static IP address and a DNS A record are required in order for LISTSERV to work properly.
Can LISTSERV read mail from POP mailboxes?
No. LISTSERV is designed to work with SMTP mail servers and is not able to read POP mailboxes.
How do I install the web archive/administration interface?
Please see either your version-specific installation guide or chapter 5.4, below.
This is version specific and documented in the version-specific installation guides.
The supported method is to send e-mail from your POSTMASTER= address to LISTSERV@your server with the command
STOP PW=createpw
in the body of the message, where "createpw" is the CREATEPW= value from your site configuration file.
Under Windows NT and later, assuming that LISTSERV is running as a system service (which is the recommended method), you can also stop LISTSERV from the Control Panel/Services applet, or by issuing a NET STOP LISTSERV command from a DOS prompt (both of these assume that you are logged into the machine with administrative privileges).
Under unix, it is possible to stop LISTSERV by issuing a 'kill -TERM' command on the PID found in $LSVSPOOL/listserv.PID . However, this is not 100% guaranteed to kill all of the existing 'lsv' processes which may be running at the time (for instance you may end up with zombie processes left over from web interface queries), so L-Soft recommends that the e-mail method using the STOP command as documented above be used in preference to the 'kill -TERM' method from a shell prompt. It is vital that all 'lsv' processes be stopped before restarting LISTSERV, as the web interface may not properly re-initialize if this is not done.
LISTSERV also stops automatically when the system is rebooted.
How do I add, change, and delete LISTSERV Maintainers (aka postmasters)?
LISTSERV Maintainers are defined by their e-mail addresses in the site configuration file, by setting the site configuration variable POSTMASTER=. This is normally done by opening the site configuration file in a text editor (never in a word processor or other non-flat-ASCII editor) and changing the value in the variable, then saving the file and stopping and restarting LISTSERV.
Windows sites can alternatively use the SITE.EXE configuration GUI to make these changes, but must also stop and restart LISTSERV after making the change.
Note carefully that the syntax for the POSTMASTER= variable (like all other site configuration variables) differs from one OS platform to another. See Appendix C of this manual for OS-specific syntax examples.
How do I create passwords for postmasters, and what are they used for?
LISTSERV Maintainers use two different passwords, depending on the particular commands they are attempting to authenticate.
When creating a list by the e-mail method, or when using the PWC privileged password-management command, a LISTSERV maintainer must use the password set in the CREATEPW= site configuration variable.
All other commands (as well as list PUT operations performed on a list after the list is created, for example, to modify the list header) are authenticated by the personal password associated with the LISTSERV maintainer's e-mail address. This password can be created in one of two ways:
· Via the web interface, where a clickable password creation link will appear when you try to log in for the first time; or
· Via mail, by using the PW ADD command documented elsewhere in this manual.
Note that some mailing list commands do not always require password authentication, depending on the setting of the Validate= list header keyword for the list in question. See Appendix B for more information on how the various Validate= settings affect command authentication.
Please see chapter 7.1, below.
There is no LISTSERV command to delete a list. This was a design decision taken very early on in LISTSERV's history, for both security reasons and to avoid accidental deletion of lists. Please see chapter 7.11, below for a procedure for deleting lists.
Does LISTSERV have a GUI interface?
LISTSERV's GUI interface is its web administration/archive interface. Many site-level and most list-level functions can be accessed via the web interface.
5. Configuring your LISTSERV® site
Please note that this manual is not intended to replace the individual installation manuals for LISTSERV on the various platforms supported by L-Soft. This is because the installation procedures vary radically from platform to platform and this manual is intended to assist LISTSERV maintainers on operational LISTSERV sites. The installation guides for all platforms are included in the software distributions, and are also available on L-Soft's World Wide Web and FTP sites.
For the purposes of this chapter, therefore, it is assumed that you have already installed LISTSERV on your host computer and have been able to start it in successfully in interactive mode. If you have not reached this point, this chapter will be of little use to you.
These files have different names depending on the platform. They are located in the same directory with the executable binaries.
|
Platform |
Site configuration file |
|
|
|
|
VM |
LOCAL SYSVARS |
|
OpenVMS |
SITE_CONFIG.DAT |
|
Unix (all) |
go.user |
|
Windows NT/2000 |
SITE.CFG |
|
Windows 95/98/Me |
SITE.CFG |
These are the only configuration files that should be changed on any LISTSERV installation. Software upgrades may overwrite any other configuration files located in LISTSERV’s home directory. They will never overwrite the files listed above. The intent is to help preserve your system settings from one version to the next so that you do not experience the inconvenience of having to reconfigure LISTSERV after an upgrade.
L-Soft international, Inc., is not responsible for system downtime or misoperation occassioned by the loss of any changes that you make to configuration files other than the ones listed above.
Depending on the platform, a large number of control variables are available to "fine tune" the performance and behavior of LISTSERV. The following table indicates the variables, under which platforms they are supported, and briefly what they control. Please see Appendix C of this manual for details before setting any control variable. Some variables shown in the table are VM legacy settings and are not otherwise discussed in this manual.
Table 5.1. LISTSERV site configuration variables
|
Variable |
Short Description |
VM |
VMS |
Unix |
Win |
|
|
ALL_REQUEST_ALLOWED_USERS |
Specifies non-POSTMASTER users who are allowed to post to the ALL-REQUEST alias (1.8e) |
yes |
yes |
yes |
yes |
|
|
ANTI_VIRUS |
Boolean value determining whether or not LISTSERV's anti-virus scanning is enabled (1.8e) |
yes |
yes |
yes |
yes |
|
|
BITNET_ROUTE |
Defines the hostname of a machine that knows how to route mail to BITNET addresses |
yes |
yes |
yes |
yes |
|
|
BOUNCES_TO |
Tells LISTSERV where to send bounces not related to any particular list |
yes |
yes |
yes |
yes |
|
|
CHECKMDISK |
List of library minidisks to be checked at startup |
yes |
no |
no |
no |
|
|
CLI_* |
Three configuration variables under the CLI_* rubric are available for use with DBMS/Mail Merge. Please see the Developer's Guide for LISTSERV (available separately) for documentation. (1.8e) |
no |
no |
yes (AIX only) |
no |
|
|
CMDPIPE_HOSTNAME |
Defines the hostname used by the LCMD utility |
no |
no |
no |
yes |
|
|
CMSNAME |
The name of the CMS system to be used on IPL commands |
yes |
no |
no |
no |
|
|
CRASH_MONITOR |
Where to send VMS or NT crash reports |
no |
yes |
no |
yes |
|
|
CREATEPW |
The password required to create new lists |
yes |
yes |
yes |
yes |
|
|
DATABASE |
Indicates whether the (old) VM database functions are enabled or not |
yes |
no |
no |
no |
|
|
DBRINDEX |
Determines whether or not the new LISTSERV database functions use reverse indexing |
yes |
yes |
yes |
yes |
|
|
DEFAULT_CHANGELOG_PERIOD |
Sets a default period for rotating change-logs. (1.8e) |
no |
yes |
yes |
yes |
|
|
DEFAULT_LANGUAGE |
Sets the default national language template for use by all lists on the server |
yes |
yes |
yes |
yes |
|
|
DEFAULT_PROBE |
Sets defaults for passive probing |
yes |
yes |
yes |
yes |
|
|
DEFAULT_SPLIT |
Provides a default value for the "SPLIT=" command line keyword |
yes |
yes |
yes |
yes |
|
|
DELAY |
The delay between two reader-scan operations |
yes |
no |
no |
no |
|
|
DIAGD4 |
Indicates whether LISTSERV should use diagnose X'D4' to mimic the RSCS origin on files it DISTRIBUTEs |
yes |
no |
no |
no |
|
|
DIST_ALLOWED_USERS |
In 1.8d and following, space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE |
yes |
yes |
yes |
yes |
|
|
DIST_SECURITY |
In 1.8d and following, Boolean value which controls security validation feature for the DISTRIBUTE command. WARNING: See Appendix C before changing this value. |
yes |
yes |
yes |
yes |
|
|
FILEDISK |
The filemode of the DEFAULT disk to be used for storing files via a PUT command |
yes |
no |
no |
no |
|
|
FILEMAXL |
The maximum number of lines for any incoming non-mail file to be accepted |
yes |
yes |
yes |
yes |
|
|
FILTER_ALLOW |
Defines users or classes of users who should be exempt from LISTSERV's standard filter |
yes |
yes |
yes |
yes |
|
|
FILTER_ALSO |
Defines users or classes of users who should not be allowed to post to any list on the server. |
yes |
yes |
yes |
yes |
|
|
FIOC_INUSE_RETRY |
Defines the number of seconds LISTSERV will try to open a file locked by an external process |
yes |
yes |
no |
yes |
|
|
FIOC_TARGET |
Defines (in kilobytes) the "target size" for LISTSERV's file cache. |
yes |
yes |
yes |
yes |
|
|
FIOC_TRIM |
Defines (in kilobytes) the threshold at which point LISTSERV should start aggressively trimming the cache. |
yes |
yes |
yes |
yes |
|
|
FIOC_WARNING |
Defines (in kilobytes) the cache size at which LISTSERV should write a warning to the console log. |
yes |
yes |
yes |
yes |
|
|
GETQWAIVE |
Internet addresses of persons to be granted an "infinite" GET quota |
yes |
no |
no |
no |
|
|
IGNORE |
A list of userid@nodes whose messages and files are to be ignored |
yes |
no |
no |
no |
|
|
IGNORE_EXTERNAL_PRIME |
Boolean value determining whether or not LISTSERV will ignore the PRIME setting on incoming DISTRIBUTE jobs. |
yes |
yes |
yes |
yes |
|
|
INDEX_VIA_GETPOST |
On VM, determines whether INDEX subscriptions use GETPOST or old-style database jobs by default. |
yes |
no |
no |
no |
|
|
INSTPW |
The optional local "installation password" associated with the INSTALL command |
yes |
no |
no |
no |
|
|
JOB_STAT_DEFAULT |
Boolean value determining whether or not the "Summary of resource utilization" is generated or suppressed in a CJLI JOB command response. |
yes |
yes |
yes |
yes |
|
LICENSE_WARNING |
Toggles license warnings on and off. WARNING: See Appendix C before changing this value. |
yes |
yes |
yes |
yes |
|
LIST_ADDRESS |
Default value for the "List-Address=" keyword |
yes |
yes |
yes |
yes |
|
LIST_EXITS |
Filenames of executable files that can be defined as exits by an "Exit=" list header keyword |
yes |
yes |
yes |
yes |
|
LMCPUT |
a boolean variable indicating how PUT commands for datafiles associated with the LMC FAC are handled |
yes |
no |
no |
no |
|
LOCAL |
a list of nodes to be associated with the hardcoded LCL FAC. Also used as the default for the "Local=" list keyword |
yes |
yes |
yes |
yes |
|
MAILER |
Internet address of the local mailer |
yes |
no |
no |
no |
|
MAILMAXL |
the maximum number of lines for an incoming MAIL file to be accepted |
yes |
yes |
yes |
yes |
|
MAXBSMTP |
Maximum number of 'RCPT TO:' lines per BSMTP file sent to the mailer |
yes |
yes |
yes |
yes |
|
MAXDISTL |
(HPO only) The maximum number of recipients to be listed in the LISTSERV console log as recipients of an SMTP job |
yes |
yes |
yes |
yes (NT) |
|
MAXDISTN |
Maximum number of recipients in forwarded DISTRIBUTE jobs |
yes |
yes |
yes |
yes |
|
MAXGET |
Maximum number of GET requests a user can make per day |
yes |
no |
no |
no |
|
MAXGETK |
Maximum number of kilobytes of data a user may obtain a day via GET requests. |
yes |
no |
no |
no |
|
MDISK.cuu |
Information about library minidisks |
yes |
no |
no |
no |
|
MSGD |
Userid of the virtual machine running a RFC1312/MSP server, if "Internet TELL" support is desired |
yes |
no |
no |
no |
|
MYDOMAIN |
The list of domain names which are equivalent to NODE--e.g., MX addresses, CNAMEs, etc. |
yes |
yes |
yes |
yes |
|
MYORG |
Short organization name that appears in the RFC-822 "Sender:" line. |
yes |
yes |
yes |
yes |
|
NDMAIL |
Whether to send mail to the local MAILER in Netdata format |
yes |
no |
no |
no |
|
NODE |
Internet address of this LISTSERV host |
yes |
yes |
yes |
yes |
|
NO_NJE_JOBS |
Directs a VMS™ server running in NJE mode to send all outgoing server-to-server requests via the Internet |
no |
yes |
no |
No |
|
OCI_* |
Three configuration variables under the OCI_* rubric are available for use with the DBMS/Mail Merge functionality introduced in LISTSERV 1.8d. Please see the Developer's Guide for LISTSERV (available separately) for documentation. |
no |
yes |
yes
|
yes** (NT, 1.8d only) |
|
ODBC_* |
Three configuration variables under the ODBC_* rubric are available for use with the DBMS/Mail Merge functionality introduced in LISTSERV 1.8d. Please see the Developer's Guide for LISTSERV (available separately) for documentation. |
no |
no |
no |
yes (NT) |
|
OFFLINETHR |
Defines the system and RSCS spool thresholds for automatic offline/online control |
yes |
yes |
no |
no |
|
POSTMASTER |
A list of userid@nodes, of which the first one is the "main" postmaster (to receive transferred files). |
yes |
yes |
yes |
yes |
|
PRIMETIME |
Defines the "prime time" for your node |
yes |
yes |
yes |
yes |
|
QUALIFY_DOMAIN |
Defines domain to be appended to all non-qualified addresses |
yes |
yes |
yes |
yes |
|
RESMODES |
Defines a list of filemodes which are to be considered as "reserved" and never available for dynamic ACCESS |
yes |
no |
no |
no |
|
RSCS |
A list of local userids which must be treated as RSCS virtual machines |
yes |
yes |
no |
no |
|
RUNMODE |
The mode (NETWORKED, STANDALONE, or TABLELESS) that LISTSERV runs in. |
yes |
yes |
yes |
yes |
|
SEARCH_DISABLED |
Determines whether or not the (new) SEARCH command is enabled. |
yes |
yes |
yes |
yes |
|
SMTP_FORWARD |
The Internet hostname of the server to which all outgoing SMTP mail should be forwarded for delivery |
no |
yes |
yes |
yes |
|
SMTP_FORWARD_n |
Defines n number of "SMTP workers" used to split up the SMTP forwarding load |
no |
yes |
yes |
yes |
|
SMTP_LISTENER_IP |
Dotted-decimal IP address which sets the IP address to which the SMTPL.EXE "listener" will bind at boot time. |
no |
no |
no |
yes |
|
SMTP_LISTENER_PORT |
Integer value which sets the port number to which the SMTPL.EXE "listener" will bind at boot time |
no |
no |
no |
yes |
|
SMTP_RESET_EVERY |
Directs LISTSERV to reset open SMTP connections every n minutes |
no |
yes |
yes |
yes |
|
SORT_RECIPIENTS |
Determines whether or not to sort recipients in the RFC821 mail envelope |
yes |
yes |
yes |
yes |
|
SPAM_DELAY |
Sets the server-wide value (in minutes) for the anti-spam quarantine period |
yes |
yes |
yes |
yes |
|
SSI |
Flag telling LISTSERV that it runs in a SSI system |
yes |
no |
no |
no |
|
STARTMSG |
Recipients of start and stop messages |
yes |
yes |
yes |
yes |
|
STOREPW |
The password to be used by postmasters when executing CP/CMS commands and when storing files in the server by means of the PUTC command |
yes |
yes* |
yes* |
yes* |
|
SYSTEM_CHANGELOG |
Enables a system-level changelog |
yes |
yes |
yes |
yes |
|
TCPGUI_IPADDR |
Defines the IP address used by the TCPGUI interface |
no |
yes |
yes |
yes |
|
TCPGUI_PORT |
Defines the port number used by the TCPGUI interface |
no |
yes |
yes |
yes |
|
TRAPIN |
List of userid@node templates from whom LISTSERV should never accept mail |
yes |
yes |
yes |
yes |
|
TRAPOUT |
List of userid@node templates to whom LISTSERV should never send mail |
yes |
yes |
yes |
yes |
|
VM30091 |
Indicates whether or not the VM30091 message suppression functions are available |
yes |
no |
no |
no |
|
WEB_BROWSER_CONFIRM |
Indicates whether or not LISTSERV should require "OK" confirmation for commands sent from WWW browsers. |
yes |
yes |
yes |
yes |
|
WWW_ARCHIVE_CGI |
The (preferably) relative URL that leads to the WWW archive CGI script. (This is a URL, not an OS path name.) |
no |
yes |
yes |
yes |
|
WWW_ARCHIVE_DIR |
The full OS path name to the WWW archive directory |
no |
yes |
yes |
yes |
|
WWW_AUTHINFO_DISABLE |
Disable/enable the web archive interface's IP address verification function |
no |
yes |
yes |
yes |
|
XFERTO |
Userid of the virtual machine to which files found in the lists readers should be transferred |
yes |
no |
no |
no |
There are also a number of configuration variables pertaining to the DBMS/Mail Merge functions. These variables are documented in the Developer's Guide for LISTSERV, available separately.
Notes:
* For non-VM systems, STOREPW is a secondary password that is functionally identical to CREATEPW. You should use the same value for both passwords, i.e., set STOREPW= %CREATEPW% (for Windows NT/2000 and 95/98), etc.
** The native OCI interface was available for Windows servers only in version 1.8d. It was removed in LISTSERV 1.8e. See Appendix C, OCI_* for details.
The proper operation of LISTSERV is dependent on LISTSERV’s ability to find a number of files that belong to it. The following list of files are required to operate the product, and in most cases must be located in the same directory with the LISTSERV executables. (The notable exception is under unix, where all of the data files other than the 'go*' files are required to be placed one directory below the executables, typically in ~listserv/home .)
(Note that under certain conditions, some required files aren’t necessary; these will be noted where applicable. Note also that some files are not shipped with the distribution, but are generated automatically the first time you run LISTSERV.)
Program Executables
Dependent on the platform, the required executables are:
|
VM: |
LSV EXEC |
|
OpenVMS: |
LSV.EXE |
|
unix: |
lsv* |
|
Windows (all): |
LSV.EXE |
For OpenVMS and Windows systems, the executable SMTPW.EXE is also required.
For Windows NT/2000 systems not running LSMTP and for all Windows 9x/ME systems, the executable SMTPL.EXE is also required.
The executables listed above belong in the following places (depending on the platform):
|
VM: |
on LISTSERV's A disk |
|
OpenVMS: |
in LISTSERV's "A" directory, normally LISTSERV_ROOT:[MAIN] |
|
unix: |
in the LSVROOT directory, i.e., ~listserv/ |
|
Windows (all): |
in LISTSERV's "A" directory, normally drive:\LISTSERV\MAIN |
Finally, the Web Archive ('wa') interface CGI script is shipped in the A directory of the non-VM servers. This script must be copied into the appropriate script directory for your Web server (per chapter 5.4, below) if you plan to use the Web Archive interface. On OpenVMS and Windows servers, this file is WA.EXE, while on unix machines it is wa* .
BITNET Network Table files
These files are not required when running LISTSERV with RUNMODE=TABLELESS, and are not shipped with evaluation copies for Windows 9x/ME or with LISTSERV Lite. Network table files include:
|
bitearn.nodes |
bitearn.dbindex |
bitearn.distsum2 |
bitearn.linkdef2 |
|
bitearn.linksum2 |
bitearn.nodesum3 |
|
|
With the exception of BITEARN NODES, all files are regenerated whenever BITEARN NODES is updated or when an explicit NODESGEN command is issued. For pre-1.8c servers (or non-registered 1.8c or later servers), BITEARN NODES must be downloaded on an approximately monthly basis from
ftp://ftp.lsoft.com/listserv-data/bitearn.nodes
or from the European mirror at
ftp://segate.sunet.se/listserv-data/bitearn.nodes
Beginning with 1.8c, BITEARN NODES on registered networked servers is updated using the same mechanism as PEERS NAMES and other LISTSERV tables. Note that this requires that your mail server support incoming files of at least 1.5M. VM sites have not been included as they typically maintain this file using the UPNODES procedure and store it on a public disk, applying change control procedures in the process.
Internet and Peer Networking Table files
|
aliases.names |
intlinks.file |
intpeers.names |
linkswt2.file |
|
peers.dbindex |
peers.dbnames |
peers.distsum2 |
peers.names |
|
peers.namesum |
service.names |
|
|
These files are used by LISTSERV to define its "backbone" and other peer servers, as well as to help determine the best routes for mail sent via the DISTRIBUTE algorithm.
For registered sites they are updated periodically by mail from other servers. The update process is automatic and does not require LISTSERV maintainer intervention unless a problem is noted.
For non-registered sites the files must be updated manually. See http://www.lsoft.com/table-updates.html for information on how to accomplish this.
Sites running in TABLELESS or STANDALONE mode do not require these files. This includes all LISTSERV Lite and LISTSERV Shareware sites.
LISTSERV's external data files
LISTSERV uses these files for a number of purposes. The fact that they are external to the executables makes it easy to update them when needed. These files include:
|
country.file |
default.mailtpl |
default.wwwtpl |
errfac.file |
|
listkwd.file |
lsvhelp.file |
lsvinfo.file |
permvars.file |
|
signup.filex |
stdcmd.file |
sysff.file |
site.catalog |
|
system.catalog |
|
|
|
PERMVARS.FILE is LISTSERV's main "permanent variables" file; among other things, this is where LISTSERV registers spammers and users that have been served off. NOTE VERY CAREFULLY that this file should NEVER be modified manually. It is in a binary format and, if corrupted, LISTSERV will not start.
The SIGNUP.FILEx files (initially there are 9 [or 31 if you are licensed for HPO], for example, SIGNUP.FILE1, SIGNUP.FILE2, etc.) are used to register users and their real name fields.
SYSTEM.CATALOG is used by LISTSERV to register system files; it should not be modified, as it is always shipped with new versions and will thus overwrite itself. Instead, SITE.CATALOG should be used to register files and list file archive catalogs (listname.CATALOG) for users to retrieve. (SITE.CATALOG is not shipped with LISTSERV; please see the chapter on Notebook and File Archives for details.)
DEFAULT.MAILTPL and DEFAULT.WWWTPL are the files from which LISTSERV gets its default mail templates and default web templates for responses to user input. See Chapter 9, Creating and Editing LISTSERV's Default Mail Templates, for details.
User reference material
The following files are LISTSERV's online documentation.
|
listdb.memo |
listfile.memo |
listkeyw.memo |
listmast.memo |
|
listpres.memo |
listjob.memo |
listlpun.memo |
listownr.memo |
|
listserv.memo |
listall.refcard |
|
|
LISTALL.REFCARD is broken into three parts internally. Part 1 is the response to the INFO REFCARD command; Parts 1 and 2 are the response to a GET LISTOWNR REFCARD command; and the whole document is sent in response to a GET LISTMAST REFCARD command.
Command line utilities (non-VM)
Depending on your platform, the following executables may have been shipped (under unix they must all be complied from the corresponding *.c files):
LCMD.EXE (or lcmd*)
LCMD is a command-line named-pipes interface to LISTSERV. You can use it to send commands directly to LISTSERV from the console and receive information in return, either on the console itself (Windows and OpenVMS) or via mail (unix). The syntax is:
Windows: lcmd [\\computer[\serverid]] command
OpenVMS and unix: lcmd command
The user running LCMD must have appropriate permission (e.g., must be a list owner or LISTSERV maintainer) in order to issue the various protected commands.
LISTVIEW.EXE (or listview*)
LISTVIEW is a utility that allows you to type the binary-format .LIST files to standard output so that they can be viewed and/or redirected to text files. The syntax is:
listview [-a] [-e[h]] [-h] [-r nnnn] [-s] file1 file2...
You can choose only one of the command line options at a time, except that you can specify one of the other options along with the -r option if needed. The options are:
|
-h |
Show the header only |
|
-s |
Show the header + the subscribers (without the option string in columns 81-100) |
|
-e |
Show the list of subscribers only (without the option string) |
|
-eh |
Similar to -e, but show only the hostnames without userid@ |
|
-a |
Show the entire list file |
|
-r nnnn |
Generate two files (listname.view1 and listname.view2) for each list file viewed with this option. The view1 file contains nnnn subscriber addresses chosen at random from the list, where nnnn is an integer value between 1 and the number of users on the list. The view2 file contains the rest of the subscriber addresses from the list, randomly sorted. (The view2 file is useful in cases where you wish to pull x names at random from your mailing list, and then pull x more names at random without duplication. Note however that you would have to add the subscribers in the view2 file to a regular LISTSERV list in order to be able to run listview against those subscribers.)
While you can specify one other option with -r to manipulate the output, the following caveats should be noted:
· listview -h -r results in a blank file · listview -s -r does not output the list header · listview -eh -r outputs a list of random hostnames, but they are not unique. · listview -a -r is the same as listview -r
|
Note carefully that running listview -r against a mailing list with a value of nnnn greater than the actual number of subscribers in the list will result in duplicates being written to the view1 file and the generation of a view2 file of length 0.
LISTVIEW executed with no option is the same as 'listview -a'.
You can redirect the output of LISTVIEW with standard OS-dependent redirection symbols. For instance,
listview -h mylist > mylist.file
redirects the output to the ASCII file 'mylist.file'.
JOBVIEW.EXE (or jobview*)
JOBVIEW allows you to read the Base64-encoded spool files created by LISTSERV (see below for the types of files created in the spool directory that may be read with this utility). The syntax is simply
jobview file1 file2...
GUI site configuration utility (Windows NT and Windows 95 only)
SITE.EXE and SITE.HLP
The Site Configuration Utility for LISTSERV allows you to easily configure LISTSERV's operation. While this can also be done by manually editing LISTSERV's SITE.CFG file, the GUI gives you an easier way to take care of this task. Online help for the various configuration variables is provided, and new LAKs can be entered. Basic optimization for various pre-calculated loads can also be performed.
Line-mode site configuration utility (OpenVMS only)
LISTSERV_CONFIGURE.COM
A very basic line-mode utility that allows you to modify the OpenVMS version of the site configuration file. Useful for initial configuration. Most OpenVMS sysadmins will probably prefer to edit the SITE_CONFIG.DAT file by hand with a text editor.
Other files that will appear during use
While in use, LISTSERV creates various files for itself. On the A disk or in the MAIN or HOME directory, these are typically:
|
.AUTODEL files |
Maintain data for LISTSERV's autodeletion functions; one for each list that has Auto-Delete enabled. If no auto-deletion reports are pending, this file will not exist. |
|
|
|
|
.CHANGELOG files |
Contain data regarding subscription changes for a given list if that list has the "Change-Log= Yes" list header keyword setting. These files are called listname CHANGELG on VM. |
|
|
|
|
.DIGEST files |
These files are the (volatile) digest files for each list that has digests enabled. They are deleted and restarted when the digest is cut. Note that if the location parameter of the Digest= keyword is not set to something that points to the MAIN or HOME directory, .DIGEST files will not appear in the MAIN or HOME directory, but rather in the directory specified. |
|
|
|
|
.LIST files |
Mailing list files, including the header and subscriber information. Do not attempt to edit these files with a text editor; use the GET and PUT commands instead. |
|
|
|
|
.OKxxxxxx files |
Usually found for edited lists, but can also appear for non-edited lists if users are set to REVIEW. These are mail messages that are awaiting "OK" confirmation. If they are not confirmed, they are automatically deleted after about a week. |
|
|
|
|
.OLDLIST files |
These files contain the last saved version of the list file. If you PUT a header and find that you've made a fatal mistake (like adding users "on the fly" and deleting everyone else on the list, or editing the list file by hand and corrupting the record structure) you can send the command GET listname (OLD to have the listname.OLDLIST file sent to you. |
|
|
|
|
.SUBJECT files |
Maintain the list of subjects for the digest. Again, if digests are not enabled for a specific list, this file does not exist for that list. Also, the same note for the location of these files as for .DIGEST files applies. .SUBJECT files are deleted and restarted when the digest is cut. |
In the SPOOL directory, the following file types will be found:
|
.ERROR |
LISTSERV generates an .ERROR file in the spool when it encounters an error in a JOB file. These can be viewed with the jobview utility and are important for tracing certain errors back. |
|
|
|
|
.JOB |
Files that have been received by LISTSERV and are queued for processing. These files are in Base64 format and can be viewed with the jobview utility. |
|
|
|
|
.JOBH |
Held .JOB files. Such files are either being processed by LISTSERV (and are thus locked) or have generated an error message. These can also be viewed with the jobview utility. |
|
|
|
|
|
Files that have been processed through LISTSERV and are queued for delivery to the outgoing SMTP mail agent. These are plain-text files. |
|
|
|
|
.MAIL-ERR |
Files that have been processed through LISTSERV and for which delivery has been attempted, but for which a "permanent" SMTP error has resulted. If you have reason to believe that the error was not actually "permanent", simply rename the file with the .MAIL extension and LISTSERV will pick it up for another try. |
JOBH files containing the string $NOJOB$ in the filename are typically waiting to be processed because the list they are going to has an explicit Prime= variable set and the non-prime time has not yet arrived.
5.4. Installing and configuring LISTSERV's WWW Archive and Administration Interface
LISTSERV 1.8d and later includes an optional WWW archive and administration interface (not enabled by default). This interface is used to allow users to browse and search notebook archives for lists with the feature explicitly enabled, as well as to allow list owners to manage almost every aspect of their lists and to allow LISTSERV maintainers to perform a number of common site management tasks. The interface is secured by the use of LISTSERV personal passwords. List owners have administrative access only to their own lists; general users have access only to the archives of public lists or to private lists to which they are subscribed (in other words, there is no difference between the access one receives via the web interface and the access one receives via the mail interface).
LISTSERV 1.8c also included an optional WWW archive interface which did not have any of the administrative functions described in this chapter.
5.4.1. The WWW Archive Interface described
Postings can be organized by date, by topic or by author, and a search function with online help is provided. LISTSERV's WWW interface has the following advantages over "hypermail" style web archiving:
· The information on the web is always up to date. New postings are shown as soon as they are received.
· The postings can be organized in the manner that best suits the reader: by date, by author, by topic, with or without table of contents, with or without showing the author, etc.
· Only one copy of the information is kept, and in particular there is no need to create an individual HTML file for each posting. This design allows the interface to scale up gracefully to lists with hundreds of thousands of archived postings, which would otherwise require hundreds of thousands of individual HTML files, wasting disk space (each file takes up at least one disk block) and stressing the file system past reasonable limits.
· The search forms can be used to create search requests matching (for instance) all postings in the last X days. The resulting URL can then be bookmarked and reloaded on a regular basis.
· List owners can customize the main page for their lists without any intervention by the LISTSERV maintainer, by updating one of the mail template forms for their list (WWW_INDEX). The LISTSERV maintainer can customize common pages and header/trailer HTML statements by updating system templates.
To take advantage of this new interface, you must first ensure that the "Notebook=" options for your list are compatible with the WWW interface. In most cases, you will not have to do anything, but certain options are incompatible with the use of the WWW interface and may need to be changed:
· The archive frequency MUST be WEEKLY, MONTHLY or YEARLY. SEPARATE and SINGLE notebooks are not supported. L-Soft generally recommends converting lists with SINGLE notebooks to YEARLY unless there is a compelling reason to have all the messages in exactly one file.
· For optimal performance, the archive frequency may need to be adjusted to produce an "adequate" number of topics and messages in each archival period. The definition of "adequate" depends on your users, the kind of equipment they have, and how they connect to the Internet. As a rule, home users will prefer a larger number of smaller archives whereas office users with large screens and T1 or better connectivity will tolerate a larger table of contents.
· Under the 1.8c version of the interface, the archives must be public as there is no userid/password control in the web archive interface. Under 1.8d this restriction has been removed.
· Under 1.8c, on most systems, the directory in which your list archives are kept must be specified in absolute rather than symbolic form, or the WWW interface will not be able to access it. Symbolic form is when the directory name is a single letter, for instance "Notebook= Yes,A,Monthly,Public" ("A" being a logical filemode defined in LISTSERV's site configuration which points to the directory where LISTSERV keeps its internal files). In most cases, your list header will probably read something like "Notebook=Yes,E:\LISTS\XYZ-L,Monthly,Public" and you will not have to worry about this.
Under 1.8d this restriction has been removed (LISTSERV will translate the logical filemode into a full path), but L-Soft still strongly discourages the use of logical filemodes for the "where" parameter of the Notebook= keyword, primarily for security reasons but also to keep things orderly. A full path is always preferred, and each list should imperatively have its own subdirectory. See 5.8, below, and chapter 8 for details.
The LISTSERV maintainer must then enable the list for the WWW interface. This may require the installation of a web server and of the WWW interface code itself. You can then modify the WWW_INDEX mail template form to customize the main archive page for your list. See chapter 9 of this manual for more information on customizing mail templates.
5.4.2. The WWW Administration Interface described
In 1.8d and later, assuming that the WWW interface has been installed per the instructions below, the WWW administration interface is enabled automatically for all lists on the server that are not coded "Validate= Yes,Confirm,NoPW" or "Validate= All,Confirm,NoPW". The basic URL for the list owner section of the interface is
http://hostname/script-directory/wa[.exe]?LMGT1
where hostname is the name of the LISTSERV host, and script-directory is the name of the directory where "wa" is installed. For unix you specify "wa?LMGT1" and for Windows and VMS you specify "wa.exe?LMGT1". With some non-unix web servers you may have to type "WA.EXE?LMGT1" (that is, all in upper case) in order for this to work.
Site managers have a different entry point at
http://hostname/script-directory/wa[.exe]?ADMIN
which allows them to create lists, customize site-wide WWW templates, and manage DBMS and mail-merge operations. This entry point also has a link to the list owner section, so site managers may wish to bookmark this entry rather than the LMGT1 entry.
See chapter 11 for detailed information on the web administration interface.
5.4.3. Installing a web server
Please note that L-Soft cannot help you with the installation or configuration of your web server itself. L-Soft does not recommend or endorse specific web servers, nor does L-Soft have development machines with every possible web server installed. You should ensure that the web server software you choose is installed and operating properly before attempting to install the LISTSERV WWW interface script.
If you do not already have a World Wide Web server installed and operating on your LISTSERV machine, you will need to obtain and install one. There are quite a few free web servers available for downloading on the Internet for most systems; you may want to start your search for server software at the W3 Consortium's web site at http://www.w3.org/. Naturally, commercial web servers can also be used.
Please note that for security purposes you should always disable directory browsing if it is not disabled by default by your web server.
5.4.4. Installing the web archive interface script
The CGI script for the web archive interface must be installed in the directory where your web server normally keeps CGI scripts and from which they are authorized to run. If in doubt, please read the manuals that came with your web server and/or contact the web server manufacturer's support group; L-Soft cannot help you with this. LISTSERV cannot install the script for you because installation depends on which server you use, which operating system you are running, how the server has been configured, etc.
Please note carefully that the web interface is not designed to be run on a machine separate from the LISTSERV server. It MUST run on the same machine. This means that a web server MUST be installed on the LISTSERV machine or you will not be able to use the web interface.
System specific instructions:
· Windows: Copy WA.EXE to the appropriate directory. For Microsoft's Internet Information Server (IIS), this is normally C:\INETPUB\SCRIPTS (not C:\INETPUB\WWWROOT\SCRIPTS).[1]
· Windows NT/2000: WA.EXE builds shipped with LISTSERV 1.8d and later communicate with LISTSERV via TCP/IP rather than via named pipes. If your %SystemRoot% directory (e.g., C:\WINNT) is on an NTFS partition, in order for this to work properly you must grant the "Everyone" user (or at least the user that invokes WA.EXE, for example, IUSR_xxx under IIS) R/X permissions on the following files in the %SystemRoot%\system32 directory:
|
MSAFD.DLL |
WS2_32.DLL |
WS2HELP.DLL |
WSHTCPIP.DLL |
|
WSOCK32.DLL |
|
|
|
Under IIS the invoker is normally the IUSR_xxx user created when you install IIS. Other web servers are probably different and you may have to check the logs to see what user is invoking WA.EXE.
This instruction can be ignored if your %SystemRoot% directory is on a FAT or FAT32 partition.
The Windows NT/2000 1.8d installation kits offer to grant world-read permissions to the above files at install time for your convenience if %SystemRoot% is on an NTFS partition.
· unix: copy 'wa' to the appropriate cgi-bin directory, change its owner to 'listserv' and set the suid bit (typically, 'chmod 4755 wa'). This authorizes the interface to read archive files. Please note that one of the most common problems with 'wa' under unix is that the installer has not followed this instruction.
· OpenVMS: you will have to link WA.OLB with the CGI library provided with your web server, then copy it to the appropriate directory. Make sure to arrange for the program to have read access to the archive files for the lists you want to serve on the web. This may vary from one web server to another.
While the script can be renamed, a short name will help keep the HTML documents small and speed up the site.
5.4.5. Creating a subdirectory for the archive interface
Create a subdirectory on your web server to contain the various files LISTSERV will be creating for the web archive interface. The suggested name (and the name LISTSERV will expect by default) for the subdirectory you will create in this step is 'archives'. Under IIS, you would typically make the directory C:\INETPUB\WWWROOT\ARCHIVES for this purpose. For a unix server running Apache it might be /usr/local/etc/httpd/htdocs/archives . Please note the following IMPORTANT restrictions carefully:
· Do not simply use your main HTML documents directory as LISTSERV will create quite a few files. It is much more orderly to keep the web archive interface's files and subdirectories in their own place in any case.
· Do not use the directory you keep the list's notebook archives in for this purpose. Notebook archives should always be kept separate from the web interface, preferably in a completely separate directory hierarchy.
· Corollary to the above: Do not set the Notebook= keyword for any list so that the list's notebook archives are kept in the subdirectory used by the web archive interface for the list.
For specifics on what should be kept in what directories, see section 5.8, below.
System specific steps:
· OpenVMS: define the systemwide logical LISTSERV_WWW_ARCHIVE_PATH to point to the directory you just created, and LISTSERV_WWW_ARCHIVE_URL with the URL to the directory in question (preferably relative).
· unix: create a world-readable file called /etc/lsv-wa.config with the following two statements:
PATH xxx
URL yyy
Where 'xxx' is the absolute path to the directory you've just created and 'yyy' is the URL to this directory (preferably relative). For instance:
PATH /usr/local/etc/httpd/htdocs/archives
URL /archives
· Windows NT/2000: if necessary (and it shouldn't be), you can update the registry key HKEY_LOCAL_MACHINE\SOFTWARE\L-Soft\LISTSERV\WWW_ARCHIVE_URL to override the default URL to the directory you have just created. Again, this is not normally necessary and is only provided for weird web servers, etc. Don't do it unless it didn't work without it.
5.4.6. Configuring LISTSERV to activate the web archive interface
This is done by modifying LISTSERV's site configuration file (see Appendix C) to add two variables:
· WWW_ARCHIVE_CGI is the (preferably) relative URL that leads to the CGI script you have just installed. Typically this will be something like '/cgi-bin/wa' or '/scripts/wa.exe'. This is a URL, not an OS path name.
· WWW_ARCHIVE_DIR is the full OS path name to the directory you created in the previous step (C:\INETPUB\WWWROOT\ARCHIVES or whatever).
Under unix, you may have to export these variables (you can check the 'go' script to see if they are already exported for you; in early versions of the interface they were not) by adding the lines
export WWW_ARCHIVE_CGI
export WWW_ARCHIVE_DIR
at the end of go.user. Again, if these variables are already exported in the 'go' script, there is no need to do this.
LISTSERV will then create and maintain a file called http://localhost/archives/index.html from which you can access all the postings. (This is made from the template WWW_ARCHIVE_INDEX--see below.)
Note that proper operation of the interface under LISTSERV 1.8d requires that the 'wa' script be able to talk to LISTSERV via TCP/IP to port 2306 (LISTSERV's TCPGUI port).
5.4.7. Customizing the web pages LISTSERV creates
Under LISTSERV 1.8d, the simplest (and recommended) way to make changes to the templates which contain the information for these pages is to use the tools provided in the WWW administration interface for changing the "look" of your site.
The LISTSERV maintainer can create a file called www_archive.mailtpl in the main LISTSERV directory to override the web archive template forms found in default.mailtpl. (See chapter 9 for more information on LISTSERV's mail templates.) There are 3 templates you typically might want to override:
· $WWW_ARCHIVE_HEADER: this is added at the top of every HTML file generated by the interface. This can be used to set the background color and insert a logo. Usage should be kept to a minimum since it appears on every page and gets in the way of the information people want to see.
· $WWW_ARCHIVE_TRAILER: same but added at the bottom of every HTML files. Can contain legal disclaimers, copyright information, and useful links.
· WWW_ARCHIVE_INDEX: this is the main page for the web archive interface. The default works fine but is a bit bland.
The list owner can also control the main page for his own lists by creating the usual listname.MAILTPL file with a WWW_INDEX template. (Again, the recommended way of doing this is to use the template editing tools in the web administration interface.)
There are more templates for other parts of the web interface which are found in the file default.wwwtpl. These templates can be overridden by placing the edited template forms in a file called site.wwwtpl (or by using the template editing tools as already mentioned).
In any case you should not make changes to either default.mailtpl or default.wwwtpl themselves as any changes you make to these files will be overwritten during an upgrade of the software.
5.4.8. Enabling individual lists
Once the interface is installed, LISTSERV will automatically make any mailing list with public archives available through it, provided that a subdirectory has been created for them in the 'archives' subdirectory created above, and provided that LISTSERV has read/write access to the subdirectory.
WARNING:
CONFIDENTIAL= YES DOES NOT LIMIT ACCESS TO ARCHIVES!
Note that public notebooks for any list coded "Confidential= Yes" will be available via the interface if a subdirectory under 'archives' is created for that list. However, unlike the behavior in 1.8c, the list will not appear on the main archive index page if you have coded "Confidential= Yes". In this case there are two avenues for users who know the list exists and want to access the web archives:
· Users can bookmark or manually enter the link to the list's archives, for example,
http://www.yourhost.com/archives/yourlist.html
· Users can click on the link at the bottom of the main index page that pulls up an "unlisted archive" form, into which they can type the name of the list.
On the other hand, if you code "Confidential= Service", your list will show up on the main archive index page for your server but will not show up in the CataList or global list of lists.
Under 1.8d and later, "Private" notebooks can be viewed via the WWW interface by following the same instructions as for "Public" notebooks. However, in order to view the notebooks, subscribers must log in with their subscribed userid@host and their LISTSERV password (set with the PW ADD command or via the WWW interface). Please note carefully that if the user is subscribed as "joe@unix1.host.com" and tries to log in as "joe@host.com", he will be refused access. Also note that unless the list is coded "Confidential= Yes", there will be a link to its archives in the main archive index page.
If you do not want the confidential and/or "Private" list's notebooks available via the WWW interface at all, simply do not make a subdirectory for it under 'archives'.
Please note that when removing a list from the WWW archive interface, you MUST delete the list's directory under 'archives'. Otherwise someone with a bookmarked URL may still be able to access some of the archives via the web.
Also note that under unix, if the 'wa' script does not have the suid bit set, the interface will appear to work normally until you try to read a message. If the suid bit is not set, you will receive a message to the effect that the archives are not available and to try again in 30 seconds.
As an example, let's assume that you have a list called XYZ-L that you want to make available through the Web interface, and that so far you have used the defaults for the installation of the interface.
First, under the 'archives' directory you created above, you must create a directory with the same name as your list. Thus, in order to make the XYZ-L list accessible through the interface, you must create the directory 'archives/xyz-l'
Next, you would edit the XYZ-L header to indicate how you want the list to appear to the interface. If you want the archives to be wide open, you must code
* Confidential= No
* Notebook= Yes,where,interval,Public
If you want the archives to be "wide open" but don't want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Public
If you want the archives to be accessible only by subscribers (with a password) and to have a link on the main archives page, you would code
* Confidential= No
* Notebook= Yes,where,interval,Private
And if you want the archives to be accessible only by subscribers (with a password) but you do not want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Private
Finally, if you want the archives to be available via the interface (either with or without a password), and you want a link on the main archives page, but you do not want your list to appear in the CataList or global list of lists, you would need to code
* Confidential= Service
and "Notebook=" would be either Public or Private depending on your preference, as above.
Please note carefully that coding the Confidential= keyword has other implications. For instance, if you want your list to show up in the CataList or be available via the Global List Exchange (GLX), you must set "Confidential= No". Thus advertising your list globally is not compatible with having your archives available via the web but not having a link on the server's main archives index page.
Finally, you would simply perform a GET and PUT of the XYZ-L header. When you PUT the header, LISTSERV will create the XYZ-L.HTML file in the ‘archives‘ directory and build indexes for the list in the ‘archives/xyz-l’ directory.
Note: If you do not execute a list PUT operation after creating the directory for the list under ‘archives’ (for instance, if the list already had public archives and it was not necessary to edit the header), LISTSERV will wait until midnight to create the web archive files for the list rather than creating them immediately. (Naturally, stopping and restarting LISTSERV will also force a rebuild of all of the web interface files but is not recommended as the normal way to accomplish this.)
At this point you will be able to access XYZ-L's archives from the URL http://www.yourhost.com/archives/xyz-l.html.
5.4.9. Enabling web-based bulk operations
Bulk operations (part of the list owner administration section of the interface) are not enabled by default when the interface is installed. As the site manager, you must create a directory called "upload" under the directory specified in the WWW_ARCHIVE_DIR= site configuration variable, and give the userid under which the "wa" CGI program is run write permission in that directory. This is the only directory in which "wa" needs write authority, and only for this functionality. If you do not want the functionality, do not create the "upload" directory.
Please note carefully that your browser MUST support the RFC1867 file upload extension or you will not be able to use the bulk operations page. Most current browsers do support this extension, including but not limited to Netscape 3.x and later, and Internet Explorer 4.x and later.
(If you get an error 2 when you click on the "Import" button, this means that the "upload" directory has not been created. If you get an error 13 when you click on the "Import" button, this means that the "upload" directory has been created but the CGI program user does not have write permission in that directory.)
5.5. The "spam" detector and anti-subscription-"spoofing" feature
L-Soft acknowledges that these features have been continually upgraded and enhanced throughout the 1.8e development process, but in keeping with previously-announced policy, specifics are proprietary and will not be documented.
One of the most arduous problems the spam detector has to face is the accurate detection of the first few copies of the spam. When the first copy reaches the first LISTSERV server worldwide, it is just a posting like any other. It will take repeated occurrences of this same posting for LISTSERV to realize that it is in fact a spam. However, it is desirable to block this very first copy as well, and this can only be accomplished by introducing a delay in the processing of "suspicious" messages. This "quarantine" gives the spam detector some time to gather the necessary evidence to determine if the message is a spam or not. The default value is 10 minutes, and can be changed by adding:
* Loopcheck= Spam-Delay(xxx)
in the list header (the value is in minutes). The LISTSERV maintainer can also change the system default by adding a SPAM_DELAY variable to the LISTSERV configuration with the desired value (also in minutes). A value of zero disables this part of the spam filter.
(It should be carefully noted that setting SPAM_DELAY=0 does not turn off LISTSERV's spam filter. It turns off only the spam quarantine part of the overall filter. There is no setting to disable the spam filter server-wide; it can be turned off only at the list level, with "Loopcheck= NoSPAM" in the list header.)
The default value of 10 minutes is adequate in most cases; it can be lowered on fast, large, active servers and may need to be increased on servers with chronical backlogs. Currently, LISTSERV determines whether a message is suspicious or not based on the sender's posting history. This however may be changed in future versions to further improve the efficiency of the spam detector.
5.5.2. "Anonymous" spam alerts
On occasion, you may receive a spam alert from LISTSERV where the offender's e-mail address is replaced with the word "anonymous". These alerts are generated by new detection algorithms where, for various reasons, it may sometimes be desirable to hide the identity of the potential offender, usually because there is a fair chance that the posting is in fact legitimate for the particular lists to which it was posted (for instance because these lists were configured to tolerate a high degree of cross-posting). In this case, information about the text of the message may be released and ultimately lead to a spamming alert that will block further copies of this same message, while the identity of the poster remains hidden.
5.5.3. Subscription anti-spoofing feature
Not long before the release of LISTSERV 1.8c (January 1997), a number of point and click utilities began to appear on anonymous FTP servers, allowing mischevious users to forge Internet mail on an industrial scale and subscribe an unfortunate victim to thousands of mailing lists. The resulting mail onslaught fills the victim's mailbox in minutes, rendering the account forever unusable. It also brings the mail server on which the account is hosted to its knees, causing, in some cases, tens of thousands of dollars in consequential damages as other users of the same system also lose precious e-mail.
In most cases, the account ends up being closed. Unfortunately, this usually doubles the load on the recipient's mail server, as a delivery error needs to be generated for every message received from the mailing list servers. Thus, it is not uncommon for the service provider to leave the account open and simply reconfigure it in such a way that incoming mail continues to be accepted, but is summarily discarded without generating a costly delivery error notification. While it is difficult to blame the service provider for wanting to minimize impact to their customers, the drawback is that the list owners may never be notified of the fact that the account was closed. On any large LISTSERV system, there are likely to be dozens of these addresses, each being sent hundreds or possibly thousands of messages a day which are simply discarded and waste resources.
Until now, the only defense against this attack was to configure mailing lists to require subscription confirmation:
* Subscription= Open,Confirm
LISTSERV will then send a confirmation request to the victim, who does not reply and thus is not added to the list. While this line of defense is 100% effective, it may not always be practical or desirable to configure the list to require confirmation.
LISTSERV version 1.8c and later is able to detect these "spoofed" subscription attacks automatically. When more than 50 subscription requests are received from the same account in a short time frame, LISTSERV automatically undoes all the subscription requests and rejects any further subscription attempt for a certain period of time. This applies even to requests that LISTSERV forwarded to other servers; LISTSERV will then send a SIGNOFF request to the remote server for the address in question. Note that, in some cases, the subscription may not be undone, either because of a temporary condition (locked list, etc.) preventing LISTSERV from deleting the user, or because the list was configured with "Subscription= By_Owner" and the owner manually added the victim after the arrival of the undo request.
This mechanism offers a very good degree of protection against the adverse effects that dead "spoofed accounts" can have on the performance of the LISTSERV host system. It does not, unfortunately, mean that people no longer have to fear subscription spoofing, as only LISTSERV lists are monitored and protected by the "spoof detector". Requests to subscribe to lists hosted by other mailing list managers are sent directly to the list managers in question, and LISTSERV can only act on the requests that it does receive.
5.6.1. Registering LISTSERV Classic Servers
NOTE: This section and 5.6.2, following, do not apply to evaluation kits or to LISTSERV Lite kits. Evaluation copies of LISTSERV should not be registered because they are (presumably) temporary servers running test lists, whose existence should not be broadcast. LISTSERV Lite copies run only in TABLELESS mode and therefore cannot be registered in the same manner as LISTSERV Classic, nor may they participate in the LISTSERV backbone. Further, Windows 9x/ME Classic servers may not participate in the backbone as typically they do not have the capacity or stability to qualify for backbone status. For information about how LISTSERV Lite servers are registered, please see 5.6.3.
Also note that only those LISTSERV Classic servers running in NETWORKED mode may be registered.
Once the server is ready for production use (that is, once you have installed a permanent License Activation Key, and once you have arranged for LISTSERV to be started automatically when the system boots), you should register it with L-Soft by filling in a server registration form, and returning it to SUPPORT@LSOFT.COM. Registering the server is necessary to broadcast its existence to the other LISTSERV servers. Once you have registered, your server will be sent periodic updates about the lists hosted by other LISTSERV sites and updates to the files whose versions are shown in the output of the RELEASE command, among other things, and, similarly, other LISTSERV sites will receive information about the public lists you are hosting.
The LISTSERV site registration request form is found at the URL
http://www.lsoft.com/regform.html
along with the requirements that must be met for registration.
The last question on the registration form is whether or not you wish for your site to participate in the LISTSERV backbone.
The LISTSERV backbone is a collection of servers which are operating 24 hours and maintained on a regular basis by their respective operation staffs. This backbone is used to support the DISTRIBUTE command and to host heavy-traffic network-wide peered lists.
LISTSERV servers can fall into one of two categories:
· Local server: A local server has by definition no obligation towards the rest of the network. It can run any release of the code, with or without local modifications. Its operation staff can update it at irregular intervals, place it offline 14 hours a day, or do just anything they might see fit to do. The server will appear in the network routing files but it will be flagged as being a local server.
The only two restrictions placed on local servers are:
1. If the server's operation staff encounter a problem with the software and the latest available release of the code has not yet been installed on the server, in general L-Soft support will recommend upgrading to the latest release before trying to diagnose a problem which may have been fixed between releases.
2. Local servers are not allowed to create peer lists. Note that the term "peer list" should be interpreted as meaning "network-wide public peer list". A closed peer list local to the various nodes of an institution does not fall into that category.
A local server can create a network-wide list by means of the Mail-Via= DISTRIBUTE feature. Local servers can submit DISTRIBUTE jobs to the backbone, but will not receive any. If a peer sub-backbone is required for the list (e.g. if large archive files are to be made available), the local LISTSERV operations staff should try to find hosts in the backbone or should join the backbone.
· Backbone server: A backbone server can do all of the above, can create peer lists and is supposed to receive DISTRIBUTE jobs. The restrictions placed on the backbone sites are the following:
1. A backbone server should always be at the latest available level. This means that the operations staff must take whatever steps are necessary to update it in a timely basis. The average delay should not exceed one week, with the deadline being two weeks.
2. A backbone server cannot be placed offline on a regular basis. It must operate 24 hours/7 days. It can of course be placed offline manually under particular conditions, lists can be held by their respective owners, etc.
3. (VM) A backbone server must be AUTOLOG-ed when the system is IPL-ed, and ought to be automatically restarted at regular intervals in case it logs off due to some hardware failure (e.g. paging error). This applies only if such a restart facility is already available at the site hosting the server. In any case, local operators should be able to restart it if they are also able to restart RSCS and other service machines. That is, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
4. (Non-VM) A backbone server must start automatically whenever the system is rebooted, and should have some facility to restart if it crashes during operation. As with VM servers, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
5. A backbone server should have the latest version of BITEARN NODES, or in the worst case, the version from the previous month. This applies only if the NODUPD files are received in due time of course. In 1.8c and following releases, BITEARN NODES can be updated automatically--see the 1.8c release notes for details.
Sites which are willing to become part of the LISTSERV backbone should indicate it in the :backbone tag of the registration form returned to support@lsoft.com. However, please note that unless you have a large number of lists, or a number of very large lists, it is probably not necessary for you to join the backbone. Sites running a few small support or hobby lists, for instance, don't need to be on the backbone; sites running hundreds of lists both large and small do need to be on the backbone. Also, sites running one or two huge lists (greater than, say, 50K subscribers each) probably should be on the backbone; such sites should contact L-Soft for more information.
5.6.3. Automatic Registration for LISTSERV Lite Servers
LISTSERV Lite servers are registered automatically when you start the software for the first time. This auto-registration is not optional for Free Edition servers, and can only be disabled for non-Free Edition Lite servers by specifying STANDALONE runmode (see "RUNMODE=" in Appendix C).
The auto-registration allows you to take part in the global List of Lists and CataList services maintained by L-Soft. Registrations are verified on a regular basis by a central L-Soft server, which sends out several informational commands that return non-privileged information about your server (anyone can issue these commands). Since these registrations are maintained by regular communication with your server, please note that, should you decommission the server, registration verifications will continue to be mailed to your server for several days until the central server decides that your server is actually gone, and not simply unable to receive mail for some reason. Please note carefully that it is not possible for L-Soft to stop these registration queries manually even if you write to us and tell us that the server has been shut down permanently. They will stop after several days without a response.
Because networked LISTSERV servers operate as part of a distributed system, they do a certain amount of inter-server "chatting". This "chatting" takes the form of DISTRIBUTE jobs, X-LUPD jobs, X-SPAM jobs, and so forth. Some of the jobs are requests for statistics for the LISTSERV network; other jobs are updates to the list of lists; still other jobs are spam alerts. None of these jobs contain privileged or private information; L-Soft does not query your server for licensing information or any non-LISTSERV-related data, and in fact, all data sent out regarding your server can be retrieved by any user with documented LISTSERV commands.
If you are running LISTSERV Classic, and you do not want to participate in the full-fledged LISTSERV network for whatever reason, you can make a change in your site configuration file to run your server in "standalone" rather than "networked" mode. Simply set the RUNMODE= variable to the value "STANDALONE" and stop and restart your server (see Appendix C for the syntax applicable to your OS). Note that this will remove your server and all otherwise-public lists running on it from the CataList and the global List of Lists.
LISTSERV Lite (Free Edition) sites are not allowed to change their runmode. If this is a security issue for your site, L-Soft suggests purchasing either the commercial edition of LISTSERV Lite or LISTSERV Classic and running in "standalone" mode.
5.8. Setting up archive and notebook directories for use with LISTSERV
We have found that often people get confused about the difference between the directories where the mailing list's notebook archives are kept and the directories where the mailing list's web archive interface files are kept. Here are a few guidelines:
L-Soft's STRONG RECOMMENDATION is that each list be given a separate directory in which its notebook archives and any files available via LISTSERV's file server are kept. On VM this is not always practical, but the security concerns are different and (to date) the 'wa' interface is not available in any case. For OpenVMS, unix, and Windows systems, our STRONG RECOMMENDATION is that a separate directory tree be established for the purpose of storing list notebook archives and other related files. For instance, you might create
|
On OpenVMS: |
Where LISTSERV's base directory is |
LISTSERV_ROOT:[MAIN] |
|
|
Create the directory |
LISTSERV_ROOT:[LISTS] |
|
|
|
|
|
On unix: |
Where the LSVROOT directory is |
/home/listserv |
|
|
Create the directory |
/home/listserv/lists |
|
|
|
|
|
In Windows: |
Where LISTSERV's base directory is |
C:\LISTSERV |
|
|
Create the directory |
C:\LISTSERV\LISTS |
Then, under the main "lists" directory, you would create further subdirectories, one for each list that has archives.
For OpenVMS this would be something like LISTSERV_ROOT:[LISTS.MYLIST-L]
for unix something like /home/listserv/lists/mylist-l
and for Windows something like C:\LISTSERV\LISTS\MYLIST-L
Please note carefully that under unix, the directory path specification for notebook archives MUST IMPERATIVELY be in lower case. LISTSERV will not write notebooks to directory paths specified in upper- or mixed-case.
Where you locate list archives is particularly important with regard to LISTSERV's file server functions. You MUST NOT set up a file server sub-catalog entry in site.catalog that points to LISTSERV's A directory! The catalog owner will be given FULL ACCESS to all the files in the directory you specify in the sub-catalog entry. Therefore in order to maintain security you MUST make a separate directory for each list catalog you define in site.catalog. For simplicity's sake, it is generally best to use this directory for the list's notebooks as well as any files the list owners may want to store except for the web archive interface files.
Files generated by LISTSERV for the web archive interface MUST NOT be stored in the notebook directories (or vice versa). You MUST make a separate directory tree where the HTML files and index files for the 'wa' interface are kept. Our best recommendation is to place this directory tree under your web server's document root directory, so that the HTML files for the web archive interface are reached by using a URL such as http://yourserver/archives/ . The location of this directory naturally varies from platform to platform and web server to web server; the guidelines in 5.4.5, above, will give you a start on finding this location.
5.9. DBMS and Mail Merge Functions
For information on installing and using these functions, please refer to the Developer's Guide for LISTSERV, available separately.
5.10. Synonymous host name registration via ALIASES NAMES
LISTSERV has supported hostname aliases since BITNET added support for this function in 1990. You could define that BITNET node (say) VTVM1 was the same as VPIVM1 and VPIVM2 (old names) and was also known as VTVM1.CC.VT.EDU. Since this was designed into the first major rewrite of LISTSERV, it is very efficient and there is almost no performance penalty. It also works globally, i.e., once the equivalence is defined, it works for all lists and all users.
However, the Internet did not have a similar mechanism for registering aliases, so this function was only useful to BITNET sites, although the underlying code would also have worked with Internet aliases if there had been a way to register them.
LISTSERV 1.8d and later supports a centralized list (called ALIASES NAMES) of synonymous Internet hostnames. The main purpose is to address problems with ISPs where the "From:" line is rewritten from (say) "joe@isp.net", which is what Joe wanted, to "joe@alpha.isp.net", "joe@beta.isp.net", "joe@gamma.isp.net" and so forth, where "alpha", "beta" and so on are known machine names (with the understanding that they may add machines from time to time) and "joe" is the same in all cases. In this way it is possible for LISTSERV to match joe@alpha.isp.net with his actual subscribed address of joe@isp.net or any of the other cluster hosts in his domain.
This can also handle a situation where an ISP changed name and for instance "joe@oldname.net" is rewritten to "joe@newname.net". However this does not handle "joe@isp.net" -> "J.Doe@isp.net" and the like.
Requests for additions to ALIASES NAMES are handled by a web form:
http://www.lsoft.com/regaliases.html
Note that while it is possible to add entries to your local copy for your local host, you should NOT do this as they will not be propagated through the network and will simply be overwritten by the next update.
5.11. Real-Time Anti-Virus Scanning
This feature is not available in LISTSERV Lite.
LISTSERV Classic or LISTSERV Classic HPO running on Windows NT/2000 or Linux with current maintenance is required. Other OS platforms may be supported in the future.
LISTSERV 1.8e introduces a long-awaited new feature: real-time, on-the-fly anti-virus scanning of all messages sent to LISTSERV mailing lists. All parts of such messages, including inline uuencoded binaries and MIME attachments in those messages, are scanned and bounced back to the sender if viruses are present. Messages sent to the *-request and owner-* pseudo-mailbox addresses used by LISTSERV (see 17.3.4, below) are also scanned and discarded if they contain viruses. This includes mail sent to the listserv-request and owner-listserv pseudo-mailboxes.
This is a value-added feature which, in addition to a regularly-licensed LISTSERV Classic or LISTSERV Classic-HPO installation, requires the following:
1. A "maintenance" LAK in addition to your regular 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; and
2. A special LISTSERV-specific version of F-Secure Anti-Virus, which is available for download from L-Soft's web site. (The standard version of F-Secure Anti-Virus is not supported.)
The anti-virus scanning feature includes:
· A 45-day warning when maintenance/AV support is about to expire.
· A 5-day warning when virus databases have not been updated.
The above warnings are controlled by the site configuration variable LICENSE_WARNING= as usual. And, as usual, it is not recommended to disable the license warnings as you may miss an expiration date without any warning and/or your anti-virus signature databases may not be kept up to date without your knowledge.
There is a new site configuration variable, ANTI_VIRUS= , which defaults to 1 (enabled) if the supported AV system is detected and 0 (disabled) if it is not. Manually enabling the variable is ignored if the supported AV system is not detected.
The virus checking capability is enabled if (1) the supported AV system is present, (2) a maintenance LAK is loaded and not expired, and (3) ANTI_VIRUS=0 is not specified in the site configuration file. List owners may not turn off AV checking (design decision -- security). Messages containing viruses are always returned to the sender (design decision -- the sender ought to be warned) even if filtering is otherwise enabled. However, attachments which have been filtered are not scanned for viruses (they are simply discarded).
(For a quick reference card of LISTSERV commands, see Appendix A of this document.)
This chapter is divided into five parts. The first three correspond to those commands available for use by the general user, list owners and file owners, and the LISTSERV maintainer. The last two describe how to send commands to LISTSERV and how to register LISTSERV passwords. Non-privileged users can send commands by mail or by interactive commands. (Note that interactive commands can only be sent if a two-way NJE or MSGD connection exists.) Privileged users can send commands by mail, interactive commands (subject to the same restriction previously noted) or via the console (VM) or the LCMD utility (non-VM).
Unless otherwise noted, commands are listed in alphabetical order, with the minimum acceptable abbreviation in capital letters. Angle brackets are used to indicate optional parameters. All commands which return a file accept an optional 'F=fformat' keyword (without the quotes) that lets you select the format in which you want the file sent; the default format is normally appropriate in all cases. Some esoteric, historical or seldom-used commands and options have been omitted.
Note that some commands are not available on all platforms; these commands are marked appropriately.
Continuation cards (see Chapter 2 in the Developer's Guide for LISTSERV regarding LISTSERV’s Command Jobs Language) can be used to split long commands (for instance, ADD commands for users with long X.500 addresses) into two or more 80-character cards. In that case you must insert "// " (two slashes followed by a space) before the command text and a comma at the end of each line of the command so that CJLI considers it as a control card and performs the required concatenation. For instance,
// QUIET ADD MYLIST someone.with.a.real.long.userid.that.wraps@hishost.com ,
His Name
or, for instance, for a large GETPOST job,
// GETPOST MYLIST 10769-10770 10772 11079 11086 11095 11099-11100 11104 ,
11111 11115 11118 11121 11124 11131 11144 11147 11153 11158 11166 11168
Be sure to put a space before the comma at the end of the first line, as LISTSERV will not add the space for you.
6.1.1. List subscription commands (from most to least important)
SUBscribe listname [full_name | ANONYMOUS] [WITH options]
The SUBscribe command is LISTSERV's basic command, issued by users to join mailing lists. This command can also be used to change one's "full_name" field in LISTSERV's SIGNUP database (simply reissue the command with the changed name). Note that the full_name is not required if the user has previously signed up to lists on the same LISTSERV server, or if the user has previously registered in LISTSERV's SIGNUP database by using the REGISTER (q.q.v.) command.
LISTSERV 1.8c and later supports the following syntax:
SUBSCRIBE listname ANONYMOUS
This indicates that the user wishes to join the list anonymously, that is, without specifying a name. The CONCEAL subscription option is automatically set, granting the subscriber the maximal level of protection available.
LISTSERV 1.8d and later supports the following additional syntax:
SUBSCRIBE listname full_name WITH option1 option2 ...
This syntax allows you to "preset" subscription options at subscribe time. For instance, you might want to subscribe to MYLIST-L in order to be able to search its archives, but don't want to receive postings. You would use the command
SUBSCRIBE MYLIST-L Joe User WITH NOMAIL
Or you might want to receive individual postings with the SUBJecthdr option and receive copies of your own postings instead of the standard acknowledgement that your message was distributed to the list:
SUBSCRIBE MYLIST-L Joe User WITH SUBJecthdr REPRO NOACK
LISTSERV 1.8e and later supports the following additional syntax:
QUIET SUBSCRIBE listname full_name WITH option1 option2 ...
This syntax suppresses the command response normally sent by LISTSERV that looks like this:
Confirming:
> SUBSCRIBE MYLIST-L Joe User
You have been added to the MYLIST-L list.
JOIN listname [full_name | ANONYMOUS]
JOIN is a synonym for SUBscribe.
SIGNOFF listname|*|* [(NETWIDE]
The SIGNOFF command allows the user to cancel his or her subscription to lists. SIGNOFF requires a qualifying parameter, as follows:
listname Sign off of the specified list
* Sign off of all lists on that server
* (NETWIDE Sign off of all lists in the LISTSERV network
The "* (NETWIDE" parameter causes the LISTSERV server to forward a copy of the signoff request to all other registered LISTSERV servers. This is a good option for a user who is changing service providers or otherwise losing a specific address that will not be forwarded. Please note that this parameter will not remove the user from non-LISTSERV lists or from LISTSERV lists running on non-registered sites.
LISTSERV will attempt to sign off the address it finds in the RFC822 "From:" line and will not "fuzzy match" for "similar" addresses.
UNSUBscribe listname|*|* [(NETWIDE]
UNSUBscribe is a synonym for SIGNOFF.
CHANGE listname|* newaddr
This form of the CHANGE command can be used by any subscriber. It must be sent from the currently-subscribed address and results in an OK confirmation request being sent back to that address. This cookie then MUST be confirmed by the currently-subscribed address, exactly as it was entered, or the command will fail. This is the only case where a 1.8d cookie must be confirmed by a specific address. Note that this assumes that the user still has login access to both addresses, or at least the ability to send mail from the old address.
SET listname option1 [option2 ...]
Allows the user to change his or her subscription options without administrative intervention. The options available to be changed are as follows:
|
ACK |
A mail message acknowledging the receipt and distribution of the user's posting is sent back to the user. |
|
|
|
|
|
|
NOACK |
No posting acknowledgement is sent. In general, this setting should only be used if the user has also set himself to REPRO, as it is desirable in most cases that some indication of whether or not the posting was received by LISTSERV be sent. |
|
|
|
|
|
|
MSGack |
An interactive message is sent to acknowledge receipt and distribution. Note that this works only if both the machine running LISTSERV and the user's machine have NJE connectivity (e.g., BITNET). If NJE connectivity is not available on both ends, this option is effectively the same as NOACK. |
|
|
|
|
|
|
CONCEAL |
Allows the user to be concealed from the REVIEW command. Note that the list owner or LISTSERV maintainer can always get the complete list of subscribers, regardless of this setting. |
|
|
|
|
|
|
NOCONCEAL |
"Unhides" the user |
|
|
|
|
|
|
Files/NOFiles |
These options toggle the receipt of non-mail files from the list. Note that this is NJE-specific, and thus obsolete for systems without NJE connectivity, but retained for compatibility. |
|
|
|
|
|
|
Mail/NOMail |
These options toggle the receipt of mail from the list. Users who will be away from their mail for an extended period of time may prefer to simply turn the mail off rather than to unsubscribe, particularly if subscription to the list is restricted in some way.
Note that for backward compatibility, the command SET listname MAIL sent by a user who is set to DIGEST but not also set to NOMAIL will cause the user to be set to NODIGEST (the behaviour is identical for users set to INDEX but not to NOMAIL). SET listname MAIL sent by users set to DIGEST/NOMAIL or INDEX/NOMAIL will simply remove the NOMAIL setting and leave the user set to DIGEST or INDEX as the case may be. |
|
|
|
|
|
|
DIGests/INDex/NODIGests/NOINDex |
|
|
|
|
These options change the format in which list mail is received by the subscriber. DIGEST turns on digest mode, in which the subscriber receives a digest of postings at set times dependent on how the "Digest=" keyword of the list is set. INDEX turns on index mode, in which the subscriber receives a daily listing of subjects posted to the list, from which he or she may order postings of interest. NODIGEST and NOINDEX toggle the mode back to individual postings sent as received by LISTSERV. Note that these options are interrelated; setting one will negate another. |
|
|
|
|
|
|
REPro/NOREPro |
Causes LISTSERV to send you a copy of your own postings as they are distributed. Some users may prefer this behavior to the ACK option (see above). |
|
|
|
|
|
|
MIME/NOMIME |
Toggles MIME options on and off. Currently only digests are available in MIME format. If DIGEST mode is set, the user will receive a MIME digest instead of the regular plain-text digest. Note that you must have a mail client that supports MIME digests (Pegasus is one that does) or this setting will do you little good. This option is automatically set at subscribe time for users who send their subscription command using a MIME-compliant agent, unless "Default-Options= NOMIME" is specified for the list. |
|
|
|
|
|
|
HTML/NOHTML |
Toggle the HTML function for digests and indexes on and off. New in 1.8d. |
|
|
|
|
|
|
TOPICS: ALL | [+/-]topicname |
|
|
|
|
For lists with topics enabled (see the Topics= list header keyword), subscribe or unsubscribe to topics. For instance, if a list has topics SUPPORT and CHAT, a user could subscribe to CHAT by sending SET TOPICS +CHAT . Or the user could unsubscribe to SUPPORT by sending SET TOPICS -SUPPORT . Finally, the user can subscribe to all available topics by sending SET TOPICS ALL . |
|
Options for mail headers of incoming postings (choose one):
|
FULLhdr |
"Full" mail headers, (default) containing all of the routing information. |
|
IETFhdr |
Internet-style headers. |
|
SHORThdr |
Short headers (no routing information). |
|
DUALhdr |
Dual headers, useful with PC or Mac mail programs which do not preserve the RFC822 return email address. |
|
SUBJecthdr |
"Full" mail headers (like the default) except that setting this option tells LISTSERV to add the list's default subject tag to the subject line of mail coming from the list. (See the listing in Appendix B for "Subject-Tag=" for more information.) Note that if the user is set to SHORThdr (or any other header option other than FULLhdr), LISTSERV will automatically switch the user to FULLhdr, as subject tags require full headers. Under 1.8c subject tags are not generated for messages sent without an RFC822 "Subject:" header; starting with 1.8d a subject tag is generated (for subscribers with the SUBJecthdr option set) even if the original message had no "Subject:" header. To turn the subject tagging off, the user simply sends a new SET command with any of the other header options (e.g., SET listname FULLhdr) and the SUBJecthdr option is reset. |
|
FULL822 |
Essentially the same as "full" mail headers, but with the important difference that the recipient's email address is specified in the "To:" line rather than the address of the list. "FULL822" headers should be used with extreme caution, as they cause LISTSERV to create a separate mail envelope with a single RFC821 RCPT TO: for each address so set. This behavior can significantly affect the performance of both LISTSERV and of your |