5 May 2000

Revision 2

The reference number of this document is 0005-MD-01 .

Table of Contents

List of Tables and Figures

Preface: 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)
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

1. Who should read this book

This manual makes the following assumptions:

• You are a system administrator of a VM, VMS, unix, Windows NT or Windows 95 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.

1.1. Changes in this edition of the manual

Due to the fact that the manual was getting quite hefty, it was decided to move certain parts of the book into a separate Developer's Guide for LISTSERV, which will be available as a companion volume to the Site Manager's Operations Manual. Information about the database functions, CJLI "Commands-Jobs", DISTRIBUTE, and list exits which was formerly part of this manual is now contained in the Developers Guide.

Other changes are documented in the Revision History, found at the end of the book.

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 1.8d, LISTSERV running under VM differs in some regards from its counterparts on the other architectures. Here is a short list of these differences:

• Non-VM: Only a subset of the 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

The File Server

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.8d.

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 adds 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 will also include AFD (Automatic File Distribution) and FUI (File Update Information) in addition to other new functionality.

The WWW List Archive Search Interface

Prior to Version 1.8d, the lack of named pipes in Windows 95 kept the web-based Search function from working. L-Soft has found a satisfactory workaround for this and the web-based search functionality is now available in LISTSERV Classic Version 1.8d for Windows 95 along with all of the other ports of LISTSERV Classic. (The Search function is not available in any port of LISTSERV Lite.)

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 is both free and perpetual, but is limited in its scope. With the Free Edition of LISTSERV Lite, you can run up to 10 mailing lists as long as you do not derive a profit from this activity. Note also that LISTSERV Lite does not have all of the functionality of a full 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	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.

3. Principles of Operation

LISTSERV® is a system 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, VMS™, unix® and Windows NT™, and has been released as shareware for Windows 95™.

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.html to 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.8d 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.

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.

L-Soft has added a number of list and server management functions to the WWW interface for 1.8d, including the ability to edit list headers and associated mail and WWW templates, and to manage subscribers via the Web. See chapter 11 of this manual for details.

Two of the most significant enhancements in version 1.8d of LISTSERV are DBMS and mail-merge support. These new features are documented in the Developer's Guide for LISTSERV, available separately.

Many other enhancements have been introduced in 1.8d. Please see the release notes for complete details at http://www.lsoft.com/manuals/index.html.

4. How your organization can use LISTSERV® to its benefit

Universities that have used LISTSERV for many years can attest to the value of LISTSERV as both an educational and administrative tool. Lately, more and more commercial enterprises have come to realize that LISTSERV can work for them, too.

4.1. A practical example: Mike’s Bikes

How can LISTSERV improve your business? Although hundreds of businesses have used LISTSERV for years, we are ever impressed by the number of creative and new ways that businesses use LISTSERV. Let's follow the fictitious "Mike's Bikes" bicycle company, and see how using LISTSERV increases sales and product visibility, reduces costs and makes a business more efficient.

When Mike first got LISTSERV, his main goal was to increase name recognition for Mike's Bikes, so he set up a few mailing lists that bicycle enthusiasts would want to subscribe to: the Bicycle Travel list, the Bicycle Maintenance list, and the Bicycle Safety list. News of the lists was sent to various bicycle and sports magazines, and before long hundreds of subscribers were exchanging their views and experiences on the three lists. Thousands of letters were distributed by LISTSERV every week, and, best of all, by using LISTSERV's Banner feature, each letter carried the message:

Announcement and Product Support Lists

Mike started selling so many bicycles that his customer service telephone line was busy constantly. People wanted catalogs; they wanted information on how to attach the new "Nite-Lite Reflectors" that Mike had mentioned on the Bicycle Safety list (sales were great, but the manufacturer's instructions were lacking); they wanted to know when the next sale was (those reflectors were pricey). The phone bill for all of those 800 number calls was getting out of hand! Mike responded by setting up a Product Announcement List, a New Catalog list, and a Product Support list. Mike made both the Product Announcement list and the New Catalog list "announce only" lists: information could be distributed to these lists only by Mike and his sales team.

The Product Announcement list was for customers who wanted to know immediately about new products and services from Mike's Bikes. People who visited the Mike's Bikes home page on the World Wide Web could ask to be added to the list from the web site. When Mike announced a sale, his customers got the word in minutes, and consequently placed their orders sooner.

The New Catalog list was set up for customers who wanted to have Mike's Bikes catalogs sent to them as soon as they were published. Because the catalogs came by email, customers received them within minutes. In addition, customers could save the catalogs instantly on their computers, and didn't have to be concerned about storing or losing a paper copy. Mike was happy because it reduced the number of his paper catalogs, which meant reduced printing and postage costs for the business. Mike's customers were happier because they could search for specific items with their word processor and find them instantly. The reputation Mike's Bikes got for being an environmentally friendly company didn't hurt, either.

Mike also announced to his Catalog list that a deluxe, full color version of the new catalog, including graphics and hypertext, was now on the Mike's Bikes home page on the World Wide Web, and that anyone who wanted the deluxe version of the catalog on their own PC could retrieve specific chapters by using LISTSERV's file retrieval function.

The Product Support list was set up as a moderated "discussion" list. It worked somewhat like a "Letters to the Editor" page in a magazine: any subscriber could submit mail to the list, but Mike filtered the mail, posting only the letters which best articulated a problem, then answering the letters. Sometimes he sent a copy of the letter to the Bicycle Maintenance list, or included it in the "Letters" section of "In Gear". This way, Mike was able to be proactive about addressing issues he knew would be important to his customers.

File Serving

Mike also wrote his own installation instructions for that problem reflector. He made the file available to anyone who needed it using LISTSERV's file server function, as he had done for his deluxe version of the Mike's Bikes catalog. He posted the simple directions on how to get the file to the Bicycle Maintenance list, the Bicycle Safety list, the Announcement list, and the Product Support list. He also mentioned it in the "In Gear" newsletter and on the web site. When word of this got to a major bicycle magazine, instructions for getting the file and visiting the Mike's Bikes homepage were mentioned in the next issue. Mike's use of LISTSERV in handling the reflector dilemma turned apotential problem into an opportunity to attract new customers and improve public relations.

Internal Lists

Mike's Bikes eventually opened manufacturing plants, branch offices and retail stores all over the world. In order to keep his company connected, Mike set up internal mailing lists. Although these lists sent mail through the Internet, they were concealed lists that only people within the company were aware of. Mike could also set up lists on his Wide Area Network. LISTSERV even worked through his firewall.

Mike set up lists for the sales and marketing divisions, branch managers, the import/export teams, and the regional vice-presidents. The US West Coast division had its own list, as did the South America and Tokyo/Far East divisions. There was even a general staff list that included everyone in the world who was employed by Mike's Bikes.

Product Development Lists

Mike's dream was to develop a "carcycle"--a car/bicycle hybrid which would keep 2-4 peddling passengers protected from rain and cold. A market study had shown that people in Japan and the Netherlands were particularly interested in the carcycle, and Mike was confident that once he built a stronghold in these markets, interest would spread worldwide.

The project had been stalled, however, because the development teams in Chicago, Amsterdam, New Delhi, Singapore and Aqaba had such a hard time coordinating international conference calls and scheduling local meetings. Mike started a "carcycle" list for the team. Each time one of them had an idea for the carcycle, they would send it to the list, knowing that LISTSERV would automatically copy and send the information to the others on the team within minutes. The team became a virtual community, without having to schedule conference calls or meetings, and without geographical restrictions.

File Serving Functions

The plans for the carcycle were in a series of computer files. Everyone on the carcycle list had "read" access to the files and could retrieve them. The head engineers also had "write access" to the files which corresponded to their part of the project, meaning they could make changes to those files. Whenever someone updated a file, they sent a message to the list, so everyone on the carcycle development team would be informed of the change and could get the latest version of the file. Because of the international nature of the teams, development was going on 'round the clock, which sped up the development process considerably. The team was able to concentrate on developing the carcycle instead of faxing photocopies of plans and scheduling meetings.

Although Mike's Bikes is a fictional company, these examples are taken from actual LISTSERV use. LISTSERV helps medical research teams coordinate their work worldwide; software developers use it to develop, beta test and support their products. Promotional and Public Service lists give companies elevated profile and "reach" they strive so hard to maintain. Lobbying lists allow organizations to email form letters to their members, who in turn forward the letters to members of Congress.

Copyright © 1995 by L-Soft international, Inc. Comments and questions may be sent to marketing@lsoft.com.

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.

5.1. Site configuration files

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	SITE.CFG
Windows 95	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.

5.2. What can be configured?

Table 5.1. LISTSERV site configuration variables

Variable	Short Description	VM	VMS	Unix	Win
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
CMDPIPE_HOSTNAME	Defines the hostname used by the LCMD utility	no	yes	yes	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_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	yes	yes	yes
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_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
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 EXEC 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
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
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	yes	yes	yes	yes
SMTP_FORWARD_n	Defines n number of "SMTP workers" used to split up the SMTP forwarding load	no	yes	no	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*
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 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 introduced in LISTSERV 1.8d. 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 and 95), etc.

5.3. Files used by LISTSERV

Program Executables

Dependent on the platform, the required executables are:

VM:	LSV EXEC
OpenVMS:	LSV.EXE
unix:	lsv*
Windows NT, 95:	LSV.EXE

For OpenVMS and Windows systems, the executable SMTPW.EXE is also required.

For Windows NT systems not running LSMTP and for all Windows 95 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 NT, 95:	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 95 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. 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.

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. The SIGNUP.FILEx files (initially there are 9, e.g., 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

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):

LISTSERV_CONFIGURE.COM

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.
.MAIL	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 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.

• 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.

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.

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.

System specific instructions:

• NT/Win95: 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 ).¹

• NT: WA.EXE builds since January 1998 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) 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 partition.

  1.8d installation kits created after 30 June 1998 will offer to grant world-read permissions to the above files 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.

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.

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

• NT: 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.

This is done by modifying LISTSERV's site configuration file (see Appendix C) to add two variables:

• WWW_ARCHIVE_CGI is the 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).

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.

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.

• $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.

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

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, e.g.,

• 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.

Under 1.8d, "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

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.

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.8d development process, but in keeping with previously-announced policy, specifics are proprietary and will not be documented.

The spam detector was improved in version 1.8c, as follows:

• The spam detector is now able to catch the first few copies of a new spam (in most cases). Previously, dozens of copies (out of the thousands sent by the spammer) could be let through before enough data was collected to identify the posting as a spam.

• The number of spam alert messages sent to the LISTSERV maintainer has been reduced to one per offender.

• The spam database is trimmed more aggressively, saving storage and processing time for sites with lots of mailing lists.

• The algorithms have been generally refined and improved, making the spam detector react more promptly and more accurately. New detection techniques have been introduced.

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 new feature.

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.

Starting with version 1.8c, LISTSERV has been 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. Server Registration

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 95 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.

A platform-specific registration form can be found in the installation guide that came with the software, or in the on-line installation guides which can be found on L-Soft's WWW site at http://www.lsoft.com/manuals/index.html.

5.6.2. The LISTSERV backbone

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.

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.

5.7. Inter-server Updates

Because LISTSERV operates as a distributed system, LISTSERV servers 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 directories for use with LISTSERV

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 VMS, 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.

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 (which were introduced in LISTSERV 1.8d), 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 introduces support for 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.

Eventually registrations for ALIASES NAMES will be handled by a web form (and please check the L-Soft site before just sending them along), but for the time being requests by ISPs to be added to the master list should be sent to support@lsoft.com . 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.

6. LISTSERV Commands

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 a "// " string 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. General Commands

6.1.1. List subscription commands (from most to least important)

Stats listname [(options]

Help

GET fn ft [filelist] [(options] [F=fformat] [SPLIT=integer]

6.2. List Owner and File Owner Commands

WARNING: new  subscriber data was found  in the replacement list  you sent,
possibly due to the use of a signature file with an unusual separator line.
If  you really  meant to  update the  subscriber data,  please resend  your
request with the word "PUT" replaced  with "PUTALL". For now, only the list
header will be updated.

6.3. LISTSERV Maintainer Commands

6.4. Sending commands to LISTSERV

You will see numerous references to "sending commands to LISTSERV" in this and other L-Soft manuals. All LISTSERV commands are sent to the server either by email or (in LISTSERV 1.8d and following) via the web administration interface described in Chapter 11. For mailed commands, this means that you must create a new mail message using whatever command this requires for your mail client (click on "New message" or its equivalent for most mail clients) addressed to the LISTSERV address. Let’s say for the sake of argument that the list you are managing is running on a server called LISTSERV.MYCORP.COM In order to send a command to that server, you would create a new message and address it to LISTSERV@LISTSERV.MYCORP.COM, and place the command(s) in the body (not the subject) of the message.

Depending on how you have security set up for your lists, some or all commands may require that you validate them with a personal LISTSERV password.

6.5. Defining Personal Passwords

The passwords recognized by LISTSERV for various operations (assuming that the NOPW parameter is not used with the "Validate=" keyword) are of two distinct types:

• Personal Passwords. LISTSERV can store a personal password in its signup files corresponding to your userid. This password not only can be used for list maintenance operations, but also protects your FUI (file update information) and AFD (automatic file distribution) subscriptions (if available on your server) and must be used to store your archive files, if any, on the server.

• List Passwords. Beginning with 1.8c, list passwords are obsolete (we are mentioning them here only because users upgrading from earlier versions will be aware of their existence). You should define and use a personal password for all protected operations.

in the body of the message. LISTSERV will request a confirmation via the "OK" mechanism (see above) before it adds the password.

If you want to remove your password altogether, send the command

This command will also require confirmation.

And finally, if you simply want to change your personal password, send the command

If you do not include the old password in the command (e.g., you’ve forgotten it), LISTSERV will request an "OK" confirmation. Otherwise, it will act on the command without need for further confirmation (unless, of course, the oldpassword provided is incorrect).

Personal passwords may also be defined via the web administration interface at login time.

7. Creating and Maintaining Lists

You can create and maintain lists from any userid listed in the POSTMASTER keyword of LISTSERV’s site configuration file. Note that a LISTSERV maintainer has the authority to GET and PUT any list, filelist, catalog, or archive file on the server (although for any list not set to "Send= Public", the LISTSERV maintainer must be subscribed to the list in order to post to it, and must additionally be a list Editor if the list is set to "Send= Editor...").

7.1. Basic list creation

1. All header lines (including those inserted for "white space") must begin with the character "*" (ASCII 0x2A).

2. Header lines can be up to 100 characters long (including the initial "*" character). However in practice you will probably want to limit them to no more than 80.

3. All words ending with the character "=" (ASCII 0x3D) are evaluated as keywords.

4. The first non-"white space" line of the header file is evaluated as the descriptive name of the mailing list, and will be displayed as such by the LIST command.

PUT listname.LIST PW=password

PUT SAMPLE LIST PW=CCCCCCCC
*
* Title of sample LISTSERV list
*
* Review= Public      Subscription= Open           Send= Public
* Notify= Yes         Reply-to= List,Respect       Validate= No
* Notebook= Yes,A,Monthly,Public
*
* Owner= someone@somewhere.com
*

7.2. Architecture-Specific Steps for List Creation

NAME: "|/BBB/lsv_amin /SSS NAME"
owner-NAME: "|/BBB/lsv_amin /SSS owner-NAME"
NAME-request: "|/BBB/lsv_amin /SSS NAME-request"
NAME-search-request: "|/BBB/lsv_amin /SSS NAME-search-request"
NAME-server: "|/BBB/lsv_amin /SSS NAME-server"
NAME-signoff-request: "|/BBB/lsv_amin /SSS NAME-signoff-request"
NAME-subscribe-request: "|/BBB/lsv_amin /SSS NAME-subscribe-request"
NAME-unsubscribe-request: "|/BBB/lsv_amin /SSS NAME-unsubscribe-request"

• An explicit directory definition, e.g., /var/spool/listserv ; or

• The switch -t , which is equivalent to the value in LSVSPOOL. (Note that the "make list" command makes aliases using -t.)

mylist: "|/usr/local/bin/lsv_amin -t mylist"
owner-mylist: "|/usr/local/bin/lsv_amin -t owner-mylist"
mylist-request: "|/usr/local/bin/lsv_amin -t mylist-request"
mylist-search-request: "|/usr/local/bin/lsv_amin -t mylist-search-request"
mylist-server: "|/usr/local/bin/lsv_amin -t mylist-server"
mylist-signoff-request: "|/usr/local/bin/lsv_amin -t mylist-signoff-request"
mylist-subscribe-request: "|/usr/local/bin/lsv_amin -t mylist-subscribe-request"
mylist-unsubscribe-request: "|/usr/local/bin/lsv_amin -t mylist-unsubscribe-request"

listname:                      listname@LISTSERV
owner-listname:                owner-listname@LISTSERV
listname-request:              listname-request@LISTSERV
listname-search-request:       listname-search-request@LISTSERV
listname-server:               listname-server@LISTSERV
listname-signoff-request:      listname-signoff-request@LISTSERV
listname-subscribe-request:    listname-subscribe-request@LISTSERV
listname-unsubscribe-request:  listname-unsubscribe-request@LISTSERV

7.3. A sample checklist for creating lists

1. Check to see that the list name is legal and not duplicated elsewhere. You can use the CataList (http://www.lsoft.com/catalist.html) as one resource for the latter.

2. If Notebook= Yes, then make the appropriate directory and make sure that LISTSERV has appropriate r/w permissions in it.

3. If Notebook= No but Digest= Yes, then make the appropriate directory and make sure that LISTSERV has appropriate r/w permissions in it.

4. Optionally, add the list to the quota file (ISP scope licenses only; see chapter 19 for details)

5. VM: Optionally, make a listname.FILELIST for this list (see chapter 8 for details)
   Non-VM: Optionally, make an entry in SITE.CATALOG for a sub-catalog belonging to this list (see chapter 8 for details) and create a dummy listname.CATALOG in the specified directory.

6. Non-VM: Optionally, assuming that Notebook= Yes and you have installed the web archive interface as described in chapter 5, create the listname directory under the base 'archives' directory. If you do this now, you won't have to GET/PUT the list header later to initialize things.

7. Create and store the list header with the list owner and you as the only subscribers.

8. Architecture-specific steps:
   • Unix, running Sendmail: Create the required Sendmail aliases for the list, either by hand or by using 'make list name=listname'. Note that this is a required step for unix servers; if you don't make the Sendmail aliases, the list won't work. See section 7.2.1 for details.

   • VMS, running PMDF®: Create the required PMDF aliases for the list in PMDF_ROOT:[TABLE]ALIASES. Note that this is a required step for VMS servers running PMDF; if you don't make the aliases, the list won't work. See section 7.2.2 for details.

9. Send a boilerplate "your list has been created" message to the list as the final test that the list works--if it doesn't, go back and find out why, then return here. See Appendix D for a sample boilerplate message for this step, or use your own.

10. Delete yourself from the list (assuming you don't want to be subscribed)

7.4. Naming Conventions

7.5. List Header Keywords and what they do

7.6. Retrieving and editing the list - some considerations

GET listname (HEADER

• Issue the UNLOCK listname command (if you decide no changes are needed)

• Send the list back to the server with the PUT command.

• Don't use the (NOLOCK switch if you are not the sole owner of the list. This prevents conflicting GETs and PUTs by different list owners. For instance, Owner(A) GETs the list without locking it. Owner(B) then also GETs the list. The owners make differing changes to the list header. Owner(B) PUTs his changes back first. Owner(A) then PUTs his changes back, erasing every change Owner(B) made. If Owner(A) had not used the (NOLOCK switch, Owner(B) would not have been able to GET a copy of the list until Owner(A) either unlocked the list or PUT his copy back. (Owner(B) could also unlock the list himself, but it would be advisable to ask Owner(A) if he was finished editing the list header before doing so.)

• Don't use the (NOLOCK switch if you get the entire list rather than just the header. You will erase all subscriptions for users who subscribed between the time you GET the list and PUT the list back. It is easier to deal with questions as to why they got the "listname has been locked since time by list-owner" message than to explain why they got a subscription confirmation and now aren't getting list mail.

7.7. Adding a list password (obsolete since 1.8c)

* PW=MYPASSWD

7.8. Storing a modified list on the host machine

7.9. Fixing mistakes

7.10. A sample list header file

PUT MYLIST.LIST PW=CREATEPW
* The Descriptive Title of My List
*
* Owner= NATHAN@LSOFT.COM (Nathan Brindle)
* Notebook= Yes,E:\LISTS\MYLIST,Monthly,Public
* Errors-To= Owner
* Subscription= Open,Confirm
* Ack= Yes                 Confidential= No
* Validate= No
* Reply-to= List,Respect   Review= Public
* Send= Public
* Default-Options= NoRepro,NoMIME
*                                                                                                  

* This list installed on 96/06/02, running under L-Soft's LISTSERV-TCP/IP
* for Windows NT.
*
* Comment lines...
*

PUT MYLIST.LIST PW=MYPASSWD
* The Descriptive Title of My List
*
* Owner= NATHAN@LSOFT.COM (Nathan Brindle)
* Owner= Quiet:
* Owner= nathan@linus.dc.lsoft.com
* Owner= ncbnet@linus.dc.lsoft.com
* Notebook= Yes,E:\LISTS\MYLIST,Monthly,Public
* AutoDelete= Yes,Full-Auto
* Errors-To= ncbnet@linus.dc.lsoft.com
* Subscription= Open,Confirm
* Ack= Yes                 Confidential= No              Notify= No
* Mail-Via= Distribute     Validate= No                  Send= Public
* Reply-to= List,Respect   Review= Public                X-Tags= Yes
* Default-Options= NoRepro,NoMIME
*                                                                                                  

* This list installed on 96/06/02, running under L-Soft's LISTSERV-TCP/IP 
* for Windows NT.
*
* Comment lines...
*

7.11. Deleting a list

1. Back up any files you wish to keep, such as notebook archives

2. For a digested list, you may want to send a QUIET SET listname NODIGEST FOR *@* command. This will cause LISTSERV to send out its accumulated digest to those who were set to DIGEST mode. If the list hasn't been active or if it's not digestified, you don't need to take this step.

3. Delete the listname.LIST file with the appropriate file system command.

4. If the list has web archives, delete the /archives/listname.html file and the /archives/listname/listname.ind* files. You can also remove the /archives/listname directory at this time.

5. Although it is not absolutely necessary, stopping and restarting LISTSERV will complete the procedure. If you do not stop and restart LISTSERV, LISTSERV will fairly quickly notice that the list is gone, and will take care of this on its own.

7.12. Adding HTML to a list header for the CataList

* The coffee lovers' list
*
* Review= Public    Subscription= Open         Send= Public
* Notify= Yes       Reply-to= List,Respect
* Notebook= Yes,L,Monthly,Public
*
* Owner=  claudia@espresso.xyz.it (Claudia Serafino)
*
* <HTML>
* COFFEE-LOVERS is an open list for, well, coffee lovers! Our
* motto is: <cite>"Instant -- just say no!"</cite>
* That's pretty much our whole charter, although there are a
* few other <a href="http://www.coffee.org/charter.html">
* rules</a> that you may want to read before joining. For
* instance, we don't allow flame wars about decaf: if you like it,
* well, it's your body after all.
*
* <p>The list is maintained by
* <a href="http://www.coffee.org/claudia.html">Claudia
* Serafino</a> (that's me!) and you will find all sorts of
* useful info about coffee on my home page.
* </HTML>
*

1. The <HTML> and </HTML> tags must appear on a separate line, as shown in the example above. You cannot have anything else on that line and, in particular, you cannot mix keyword definitions with HTML data.

2. The HTML data you are providing is embedded into the document shown by the web interface when users query your list. Because you are given some space between two horizontal rules on an existing page, rather than a whole new page. you should not include tags that affect the whole document, like for instance <TITLE>.

3. While this procedure is compatible with all versions of LISTSERV, there are a few restrictions on the placement of equal signs within your HTML text with versions that do not have any specific support for the <HTML> and </HTML> markers. In practice, you can ignore this rule unless you get an error message while storing your list.

<!--#listref listname@hostname-->

*
* Sample list with problem pattern
*
* <HTML>
* For more information on the list, just check <a
* href="http://www.xyz.edu/mypage.html">my home page.</a>
* </HTML>
*

7.13. How to set up lists for specific purposes

* My public discussion list (MYLIST-L)
* Subscription= Open,Confirm
* Ack= Yes
* Confidential= No
* Validate= No
* Reply-to= List,Respect
* Review= Owners        Send= Public      Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\MYLIST-L,Weekly,Public

* My private discussion list (PRIVATE-L)
* Subscription= By Owner
* Ack= Yes
* Confidential= Service
* Validate= No
* Reply-to= List,Respect
* Review= Owners
* Send= Private
* Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\PRIVATE-L,Weekly,Public

* Send= Editor
* Editor= someuser@somehost.com

* Editor= someuser@somehost.com,anotheruser@anotherhost.com
* Editor= yetanotheruser@his.host.com

* Send= Editor,Hold

* Send= Editor,Confirm

* Send= Editor,Hold,Confirm

* Send= Editor,Confirm
* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= yetanotheruser@his.host.com

* Send= Editor,Confirm
* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= someuser@somehost.com,yetanotheruser@his.host.com

* Send= Editor,Confirm
* Editor= someone@someplace.com,(listname)

* Auto-responder for service messages
* Owner= someone@someplace.com
* Send= Public     Notebook= No     Subscription= Closed

>>> POSTACK1 Service Message for &MYNAMES
&MYNAMES will be down Sunday from 0200 EST until 0500 EST for backups 
and upgrades. For more information contact LSTMAINT@&MYHOST.

* The FOO Product Announcment List
* Owner= foo@myhost.com
* Owner= Quiet:
* Owner= anotheruser@myhost.com
* Owner= yetanotheruser@myhost.com
* Editor= foo@myhost.com
* Editor= anotheruser@myhost.com
* Editor= yetanotheruser@myhost.com
* Notebook= No
* Errors-To= Owner
* Subscription= Open,Confirm
* Validate= No
* Review= Owners
* Send= Editor,Confirm
* Reply-To= foo@myhost.com,Ignore
* Sender= None

1. Security. This setting tells LISTSERV to request confirmation from the Editor for all postings it receives that purport to be from that Editor. This prevents hackers from forging mail under an Editor's address, because any forgeries will require that the Editor in question approve them before they go to the list.

2. Loop protection. Certain broken mailers can and will bounce mail back to your list in a "reflected" manner, that is, the bounce will appear to be a legitimate posting from the Editor to the list instead of looking like an error. This is different from a forgery attempt because (it is assumed) the mailer on the other end is not doing this with malicious intent. Requiring the editor confirmation will stop these potential loop-generating messages from getting through to the list.

>>> SUB_OWNER &LISTNAME: &WHOM requested to join
.TO &WHOM
A copy of the &LISTNAME membership questionnaire has been sent
to you.  Please read it carefully and follow the instructions
to complete it and return it to the list owners.

>>> ADDREQ1 &LISTNAME Membership Survey
.RE OWNERS
.TO &WHOM
.CE &LISTNAME Membership Survey
NOTE:  Please make sure when you send this back that it goes to
the address &LISTNAME-Request@&MYHOST.  Thanks.

This is a standard questionnaire required for all prospective
subscribers to &LISTNAME. Blah blah blah...

.fo off
----------------------------------------------------------------
For List Owner's Use Only --  Be sure to include with your Reply
----------------------------------------------------------------
// JOB
  ADD &LISTNAME &WHOM &USERNAME
// EOJ
----------------------------------------------------------------
.fo on

The approval request code received together  with your posting for the MYLIST-L
list is  incorrect. For  a peered  list, this  may be  a normal  condition. The
approval protocol  is not  guaranteed to  work among  peer chains with pre-1.8b
servers, and  will also  fail if  the peers  have a  different password.  For a
non-peered list, the only likely explanation is a failure in the mail system or
a recent change in mail  system version or  configuration. At any  rate, please
resubmit your message and go through  the approval procedure a second time, and
contact the LISTSERV administrator if the problem persists.

------------------------ Rejected message (73 lines) --------------------------

• Query listname FOR userid@host (old server), write down the options.

• QUIET ADD listname userid@host full_name

• QUIET SET listname options FOR userid@host

• Wait until you get confirmation for the two previous commands

• QUIET DELete listname userid@host (old server)

• GET listname (old server)

• GET listname (new server)

• If you are using VM XEDIT: Receive both files and use the XEDIT "PUT" and "GET" commands to move users from one list to the other. You must preserve the contents of columns 81-100 across the move.

• If you are using another text editor: Make sure that the editor you are using does not "imbed" control codes such as line breaks, tabs or word-wrapping characters into the text when you edit it. Use the cut and paste controls to copy lines in their entirety. You must preserve the contents of columns 81-100 across the move. Imbedded control codes and/or word wrap will generate errors when the list is stored back on the server.

• Store the two lists back on their respective servers.

1. NOMAIL subscriptions are ignored. You will get the super-message if you have an active (not NOMAIL) subscription to at least one sub-list. The idea is that the super-message must be equivalent to posting to all the sub-lists, without the duplicates. Since all it takes to get a message posted to all the sub-lists is a single non-NOMAIL subscription, this is how the super-list works. The only way not to get the super-messages is to subscribe to the super-list directly and set yourself to NOMAIL.

2. The DIGEST and INDEX options are ignored and internally converted to MAIL. The first reason is that, since in most cases the user will be on multiple sub-lists (otherwise you don't need a super-list in the first place), the only safe method to set subscription options for super-messages is by subscribing to the super-list so that there is no ambiguity. The second reason is that, in most cases, super-lists will be used for out of band administrative messages rather than for large volume discussions, so it is actually preferable to have the message sent directly. The third reason is that the super-list and sub-lists may not necessarily offer the same options (DIGEST and INDEX). In particular it is expected that many super-lists will not have archives. If you want a DIGEST or INDEX for the super-messages, you must subscribe to the super-list directly.

PUT M101 KEYWORDS PW=createpw
* Owner= mathwhiz@someuni.edu (Professor J. Random User)
* Owner= Quiet:
* Owner= gradasst@someuni.edu (Joe Doakes, Graduate Assistant)
* Notebook= Yes,/home/listserv/archives/m101,Monthly,Private
* Auto-Delete= No
* Errors-To= gradasst@someuni.edu
* Subscription= Closed
* Notify= Yes               Confidential= Yes        Validate= Yes,Confirm,NoPW
* Reply-to= List,Ignore     Review= Owners           Send= Private
* Default-Options= Repro

Next, the LISTSERV maintainer stores this file in the usual way, by first making a filelist or catalog entry for it (as outlined in chapter 8) and then storing it with a PUT operation. Generally the GET and PUT FACs for this file should specify that the list owner(s) should be able to retrieve and store it. The file must be stored in LISTSERV’s A directory (the same directory that contains the *.LIST files).

7.14. Merging existing LISTSERV lists

* My test list
* (remaining header lines removed for clarity)
*
xxxxx@APK.NET Pxxxx Axxxxx
2AAARAA4HAAA
xxxxxxxxxx@AOL.COM Rxxxxx Axxxx
2AAARAA2bAAA
xxxxxx@LSOFT.COM Nxxxxx Bxxxxxx
2AAARAA2bAAA
xxxxxxxx@CS.ROSE-HULMAN.EDU Mxxx Dxxxxxx
2AAARAA3nAAA

1. Kept as one single long line in which the option string starts in column 81 of the line; or

2. Split into two separate lines, the subscriber address and real name on one line followed by the option string on the next line.

• Reformat the lines so that the option strings start in column 81 rather than being on separate lines; or

• If your mail program supports MIME, re-order the file as a MIME/TEXT attachment by adding F=MIME/TEXT to your GET command (e.g., GET MYLIST-L F=MIME/TEXT). This should preserve the long lines without inserting end-of-line characters.

nxxxxx@LSOFT.COM Nxxxxx Bxxxxxx                                                 2AAARAA2bAAA

7.15. Migrating lists from one site to another

1. You are migrating lists from an existing LISTSERV site (e.g., moving from VM to unix)

2. You are migrating lists from a non-LISTSERV site to LISTSERV

3. You are creating a LISTSERV list from a Sendmail alias or other database of e-mail addresses

• You can migrate only from VM to non-VM, or from non-VM to non-VM. You cannot migrate using the FTP method from non-VM back to VM (unless you are prepared to reconstruct your list files and so forth from scratch). Naturally a GET and PUT will work if you need to move from non-VM to VM.

• If migrating from VM to non-VM: Be sure to FTP the list files, archives, and so forth in ASCII mode. If you use binary mode, the files will be unreadable on your new system.

• If migrating from non-VM to non-VM, please note that if moving the files by FTP does not work, you will have to migrate the list using the preferred method outlined above. You could also create a new list header on the new server and add the users with an ADD IMPORT job as detailed in the next section.

• Once you have FTP'd the files to the new server, decide where you want things to go. The list file itself should go into LISTSERV's A directory (typically ~listserv/home on unix systems, LISTSERV\MAIN on Windows systems, and LISTSERV_ROOT:[MAIN] on VMS systems). You may want to make a separate directory on your new server for archives, then subdirectories of that directory for each list (see chapter 5.8, above). If so, make the appropriate directories and move the archive files there. (This is particularly important if you intend to use the ISP options such as the file quota subsystem.) If you are copying non-notebook archives, you should read the chapter on Notebook and File Archives, below, in order to set up a filelist or catalog file for these files.

• Next, you should restart LISTSERV. This is particularly important when moving lists from VM to other platforms, as LISTSERV will need to reformat the file into the binary format used on non-VM machines. If this is successful, you will see two messages in the console log:

  6 May 1996 12:50:14 Invalid record format for list XXXXX-L.
  6 May 1996 12:50:14 -> List reformatted successfully.

  If this is not successful, you will need to open the list file in a text editor and look for anything that might have caused a problem. Note that list header lines have a limit of 100 characters in length.

• Before releasing the list to the general public, be sure to GET the list header and make any changes that need to be made. Typically, changes will need to be made to the location parameters of the Notebook= and/or Digest= keywords, particularly if you are moving from one platform to another.

• Create a list header for your list as noted above and store it on the LISTSERV server. If you plan to set "Validate=" to any value but "No", set it to "No" until the following steps are completed.

• Create a LISTSERV command language job as follows:

  QUIET ADD listname DD=X IMPORT
  //X DD *
  internet-address1
  internet-address2
  /*

  where "listname" is the name of the new list, and "internet-address1", "internet-address2" and other users are the internet addresses from the original list that you want to add to the new list. Optionally, you can add the user's "real name" field, e.g.,

  QUIET ADD listname DD=X IMPORT
  //X DD *
  internet-address1 full_name
  internet-address2 full_name
  /*

  You should remove any lines from the original list that do not actually identify subscriber addresses. If you are converting to LISTSERV from ListProc, note that LISTSERV will not convert ListProc user options to their LISTSERV equivalents; you must take a line like
  user1@somehost.com POSTPONE NEWLIST NO user's name
  and reduce it at least to
  user1@somehost.com user's name
  Otherwise, the ListProc options will become part of the full_name field.

• Send the command language job to LISTSERV.

• You will receive in return a confirmation that the job executed and whether or not it was successful, e.g.:

  > QUIET ADD XXXXX-L DD=X IMPORT
  ADD: no error, 2 recipients added, no entry changed, none forwarded.

7.16. Changing the name of an existing list

* New-List= JOESLIST-L@LISTSERV.MYHOST.COM
* Confidential= Yes

7.17. Bulk operations (ADD and DELETE)

[QUIET] ADD listname DD=ddname [IMPORT] PW=yourpassword
//ddname DD *
userid1@host1.com [full name]
userid2@host2.com [full name]
...
useridn@hostn.com [full name]
/*

[QUIET] DELete listname DD=ddname PW=yourpassword
//ddname DD *
userid1@host1.com
userid2@host2.com
...
useridn@hostn.com
/*

8. File and Notebook Archives

• The VM (mainframe) version of LISTSERV continues to support the "traditional" file server system. While it is very powerful, this file server system dates back to 1986 and suffers from a few annoying limitations. In addition, it is written in a non portable language. This will be replaced eventually with the "new" file server system, currently under development.

• The non-VM versions of LISTSERV 1.8d enhance further the new file server system introduced in non-VM 1.8c, which includes most of the functionality of the "traditional" file system. Notably, GIVE and file "packages" are now available. Most end user commands will continue to work as before. However, there is no guarantee that the internal data files manipulated by the file server functions will remain as before. Note that SITE.CATALOG files from versions 1.8a through 1.8c are still supported and will not need to be changed in order to work with 1.8d.

• The non-VM versions of LISTSERV 1.8a and 1.8b supported a "temporary" file server system, to provide an interim solution while the new system was being developed. This temporary system supports only a subset of the functions of the traditional system. This system is no longer supported by L-Soft as it has been superseded by the new non-VM file server referenced above.

8.1. What is the file archive?

The file archive consists of all files other than notebook logs that have been stored on the LISTSERV host for your list. Users can find out what files are available for a specific list by sending the command INDex listname to the appropriate LISTSERV host.

8.2. Starting a file archive for your list

On VM Systems ONLY

8.3. Filelist maintenance (VM systems only)

If you are running LISTSERV under unix, Windows, or VMS, please skip this section as it does not pertain in any way to your implementation of LISTSERV.

GET listname FILELIST PW=XXXXXXXX (CTL

*  Files associated with MYLIST and available to subscribers:
*                             rec               last - change
* filename filetype   GET PUT -fm lrecl nrecs   date     time   Remarks
* -------- --------   --- --- --- ----- ----- -------- -------- --------
  MYLIST   POLICY     ALL OWN V      79    45 94/03/16 12:04:23 Mission Statement
  MYLIST   BOOKLIST   ALL OWN V      79   177 94/04/19 16:24:57 Books of interest
  MYLIST   QUARTER    ALL OWN V      73   113 95/03/11 08:57:04 Quarterly posting

*  Listowner's files (not public)
  MYLIST   FAREWELL   OWN OWN V      78     9 95/03/11 08:53:41 Goodbye memo
  MYLIST   WELCOME    OWN OWN V      73   105 95/03/11 09:14:38 Hello memo

 MYLIST FAQ ALL OWN . . . . . Frequently-Asked Questions for MYLIST

*  Files associated with MYLIST and available to subscribers:
*                             rec               last - change
* filename filetype   GET PUT -fm lrecl nrecs   date     time   Remarks
* -------- --------   --- --- --- ----- ----- -------- -------- --------
  MYLIST   POLICY     ALL OWN V      79    45 94/03/16 12:04:23 Mission Statement
  MYLIST   BOOKLIST   ALL OWN V      79   177 94/04/19 16:24:57 Books of interest
  MYLIST   QUARTER    ALL OWN V      73   113 95/03/11 08:57:04 Quarterly posting
 MYLIST FAQ ALL OWN . . . . . Frequently-Asked Questions for MYLIST

*  Listowner's files (not public)
  MYLIST   FAREWELL   OWN OWN V      78     9 95/03/11 08:53:41 Goodbye memo
  MYLIST   WELCOME    OWN OWN V      73   105 95/03/11 09:14:38 Hello memo

PUT filename FILELIST PW=XXXXXXXX

8.4. The listname.CATALOG system on non-VM systems

MY.FILE        my.file./home/lists/xyz      ALL JOE@XYZ.COM

MY.FILE     C:\FILES\XYZ\MY.FILE  XXX YYY

MY.FILE     /files/xyz/my.file    XXX YYY

MY.FILE     XYZ:[FILES]MY.FILE   XXX YYY

MY.FILE C:\FILES\XYZ\MY.FILE JOE@XYZ.EDU,JACK@XYZ.EDU,PRIVATE(XYZ-L) CTL

1. The LISTSERV administrator creates the sub-catalog and identifies the directory where the files will be stored, and the person(s) who will be in charge of managing it ("catalog owners").

2. The catalog owners use the GET and PUT commands to update their catalog and register new files in their directory. Each file has the usual GET and PUT file access codes, allowing the catalog owners to further delegate the management of individual files to third parties ("file owners").

3. The file owners manage the files in question using the GET and PUT commands. Authorized users can retrieve the files using the GET command.

1. As the result of an INDEX command without qualifier: simply define the file in SITE.CATALOG.

2. As the result of an INDEX listname command: simply define the file in the listname.CATALOG.

MY.CATALOG     /home/lists/xyz/my.catalog   ALL JOE@XYZ.COM

(1)            (2)             (3)          (4) (5)                       

MY.FILE        my.file                      ALL JOE@XYZ.COM
(1)            (2)                          (3) (4)

*
* Files for the XYZ sub-project
*
XYZ.AGENDA
XYZ.BUDGET
XYZ.PROPOSAL-1
XYZ.PROPOSAL-2

If MY.CATALOG is defined as:

MY.CATALOG     /home/lists/xyz/my.catalog   xxx JOE@XYZ.COM

8.5. Storing files on the host machine

1. Edit your file and save it. Add a single line at the top of the file as follows (square brackets indicate optional parameters):

   PUT filename extension [filelist|catalogname] PW=XXXXXXXX

   (This line will not appear to people who GET the file from LISTSERV.) Replace XXXXXXXX with your personal password. If you specify the filelist or catalog name, do not put the square brackets around the name.
   There are a couple of issues that need to be noted here:
   • If the file you are going to store is registered in the sitewide catalog or filelist, do not specify the name of the catalog or filelist.

   • If the file you are going to store is registered in a sub-catalog or filelist other than the sitewide one, you may have to specify the name of the sub-catalog or filelist in order to be able to store the file. This is because it is entirely possible that two lower-level filelists or catalogs may have files registered with the same name (for instance, README TXT). If LISTSERV has two sub-catalogs registered (for instance, MYLIST CATALOG and HISLIST CATALOG) that both have a file called README TXT registered, then a PUT README TXT command will tell LISTSERV to try and store the file in the first catalog it comes to in the hierarchy. If MYLIST CATALOG is registered before HISLIST CATALOG in SITE CATALOG, LISTSERV will try to store the file as if it belonged to MYLIST (which we assume is what you want). However, if HISLIST CATALOG is registered before MYLIST CATALOG (and many sites like to keep things in alphabetical order, so this is a most likely scenario), LISTSERV will try to store the file as if it belonged to HISLIST, and you will get an error stating that you aren't allowed to store the file.

2. Be sure that the file has been registered with an entry in a filelist or the site catalog.

3. Be sure that you have defined a "personal password" to LISTSERV with the PW ADD command before you PUT the new or edited file. If you have done this but can't remember the password, send a PW RESET command to LISTSERV, then a new PW ADD command.

4. Send the mail message to LISTSERV.

8.6. Deleting files from the host machine

1. Create a new mail message addressed to LISTSERV. Add a single line at the top of the message as follows:

   PUT filename extension [filelist|catalogname] PW=XXXXXXXX

   (Replace XXXXXXXX with your personal password.) The same issues noted in 8.5 regarding the filelist/catalog name are operative here.

2. Be sure that you have defined a "personal password" to LISTSERV with the PW ADD command before you PUT the delete job. If you have done this but can't remember the password, send a PW RESET command to LISTSERV, then a new PW ADD command.

3. Send the mail message to LISTSERV.

4. LISTSERV will tell you that the file has been successfully deleted.

5. For VM Systems ONLY: GET the listname FILELIST for your list and delete the line for the file you’ve just deleted. PUT the listname FILELIST back on the server.

6. For Workstation and PC Systems ONLY: Get the listname.CATALOG for your list and delete the line for the file you've just deleted. PUT the listname.CATALOG back on the server. Note that this is not necessarily required since under non-VM, if the physical file does not exist, LISTSERV will not include it in the output of an INDEX command. This is primarily a housekeeping measure.

8.7. Automatic File Distribution (AFD) and File Update Information (FUI)

8.8. File "Packages"

* MYLIST $PACKAGE
* Packing list for MYLIST PACKAGE
*
* You can make other comments here, such as
* the contact email address.
*
* filename filetype filelist

*==========================

• A "compatibility" mode that works on all platforms, and which is identical to the original method used on VM (and which VM servers still must use). In the compatibility mode the basic format for the entries is

  filename filetype filelist <optional_comments>

  for example,

  MYLIST   $PACKAGE MYLIST The packing list
  INTEREST FILE     MYLIST Interest groups
  NETIQUET FILE     MYLIST How to behave
  ANOTHER  FILE     MYLIST No comment

• In the second (new) mode for non-VM servers only, the entries are formatted like this:

  filename.extension <optional_comments>

  for example,

  MYLIST.$PACKAGE The packing list
  INTEREST.FILE   Interest groups
  NETIQUET.FILE   How to behave
  ANOTHER.FILE    No comment

1. They may get the entire package of files sent to them by sending LISTSERV the command GET filename PACKAGE (without the $ sign); or

2. They may request that LISTSERV send only the package file itself by sending LISTSERV the command GET filename $PACKAGE (with the $ sign).

8.9. Where to find more information on File Archives

8.10. Notebook Archives

1. Make sure that you have disk space for the notebook archives and that the directory in which they will reside has been created with appropriate security privileges. LISTSERV needs read and write access to any directory it uses for notebooks. Note that, for security reasons, LISTSERV will not create the directory if it does not exist.

2. Add the Notebook= keyword to the list header with appropriate settings. (If you are not the LISTSERV maintainer, you will have to ask the LISTSERV maintainer to do this for you.)

3. Store the list header back on the server.

* Notebook= Yes,/usr/listserv/home/mylist-archive,Monthly,Public

The following problems have been detected in the list header:

* Notebook= ...
Error: The first two parameters of the "Notebook=" keyword may only be updated
       by the LISTSERV administrator.

Please refer to the list keyword documentation (available via the "INFO
KEYWORDS" command) for more information about keyword syntax.

PUT operation rejected, old list remains unchanged.

=========================================================================
Date:         Fri, 6 Mar 1998 17:05:01 -0500
Sender:       Test list <TEST@XXXXXX.NET>
From:         Nathan Brindle <nathan@XXXXXX.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is a test.
=========================================================================
Date:         Thu, 12 Mar 1998 13:23:07 -0500
Sender:       Test list <TEST@XXXXXX.NET>
From:         Nathan Brindle <nathan@XXXXXX.NET>
Subject:      Test

This is another test
=========================================================================
Date:         Thu, 12 Mar 1998 13:24:58 -0500
Sender:       Test list <TEST@XXXXXX.NET>
From:         Nathan Brindle <nathan@XXXXXX.NET>
Subject:      Test 3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Yet another test.

From userid@host.com Thu Feb 2 15:27:02 1995

• Use standard file system commands from the console prompt to delete the files. On VM, use CMS ERASE; on Unix, rm; on VMS, DEL; on Windows systems, DEL or ERASE.

• Send a PUT command by itself (in essence, you are storing a zero-length file) via mail to LISTSERV. For instance:

  PUT MYFILE.TEXT PW=XXXXXXXX

  by itself would delete the file MYFILE.TEXT.

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

>>> EXAMPLE1 This is the subject line

• The template form starts with the line containing the form name and subject, and ends with the next line starting with '>>>', or at the end of the file.

• The subject line may contain substitutions (such as "&LISTNAME: &WHOM requested to join").

• Ensure that there is a blank space (ASCII 0x20) between ‘>>>‘ and the name of the form, or LISTSERV will not recognize the form.

• Also note that the names of the template forms must be typed in UPPER CASE.

.ASIS Click <a href="http://some.host.com/some-doc.html">here</a>.

9.4. Creating and editing a <listname>.MAILTPL file for a list

>>> INFO Information about the &LISTNAME list
There is no information file for the &LISTNAME list. Here is a copy of
the list "header", which usually contains a short description of the
purpose of the list, although its main purpose is to define various
list configuration options, also called
"keywords". If you have any question about the &LISTNAME list, write to
the list owners at the generic address:

.ce &LISTNAME-Request@&MYHOST

.dd &LISTHDR

>>> INFO Information about the &LISTNAME list
&LISTNAME is an open, unmoderated discussion list featuring
monkeys.  Things such as how to care for a pet monkey, monkey
diseases, monkey lore, endangered species of monkeys, and
monkey psychology are likely to be discussed.  The list is
NOT intended for discussion of Darwinism and/or theories of
evolution.

If you have any question about the &LISTNAME list, write to
the list owners at the generic address:

.ce &LISTNAME-Request@&MYHOST

Figure 9.2. Sample edited INFO template form.

>>> AUTODEL1 This message is not wanted for our list
.QQ

>>> REQACK1 This message is not wanted for our list
.QQ 

9.5. Storing the <listname>.MAILTPL file on the host machine

1. Get a copy of DEFAULT.MAILTPL and edit it.

2. Be sure that you have defined a "personal password" to LISTSERV with the PW ADD command before you PUT the template file. If you have done this but can't remember the password, send a PW RESET command to LISTSERV, then a new PW ADD command.

3. Send the file to LISTSERV with a PUT listname MAILTPL PW=XXXXXXXX command at the top of the file, just as if you were storing the list itself. Replace XXXXXXXX with your personal password.

9.6. Other template files: DIGEST-H and INDEX-H

The MYLIST list is sponsored by ABig Corporation.

See http://www.abig.com for information on ABig Corporation's products.

Date: Tue, 11 Jun 1996 11:52:41 -0500
From: Automatic digest processor <LISTSERV@MYHOST.COM>
Reply-To: My test list <MYLIST@MYHOST.COM>
To: Recipients of MYLIST digests <MYLIST@MYHOST.COM>
Subject: MYLIST Digest - 10 Jun 1996 to 11 Jun 1996

There is one message totalling 10 lines in this issue.

Topics in this issue:

  1. Testing 125...3 sir!

The MYLIST list is sponsored by ABig Corporation.

See http://www.abig.com for information on ABig Corporation's products.

Figure 9.4. Sample DIGEST output for a list with a DIGEST-H file. The INDEX-H output would be similar, following the list of postings.

9.7. Templates and template forms for the WWW interface

1. Any substitution variable that you use (for instance, &LISTNAME) must be escaped with a "+" symbol between the ampersand and the name of the variable, thus: &+LISTNAME . (Note that, as with the regular mail template forms, not all substitution variables are available in every HTML template form.)

2. Any dot-formatting command you use (for instance, .CC , .BB , etc.) must have a "+" symbol rather than the dot, thus: +CC +BB