L-Soft international, Inc.
Site Manager's Operations Manual
LISTSERV®, version 1.8d
5 May 2000
The reference number of this document is 0005-MD-01 .Information in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. L-Soft international, Inc. does not endorse or approve the use of any of the product names or trademarks appearing in this document. Permission is granted to copy this document, at no charge and in its entirety, provided that the copies are not used for commercial advantage, that the source is cited and that the present copyright notice is included in all copies, so that the recipients of such copies are equally bound to abide by the present conditions. Prior written permission is required for any commercial use of this document, in whole or in part, and for any partial reproduction of the contents of this document exceeding 50 lines of up to 80 characters, or equivalent. The title page, table of contents and index, if any, are not considered to be part of the document for the purposes of this copyright notice, and can be freely removed if present. The purpose of this copyright is to protect your right to make free copies of this manual for your friends and colleagues, to prevent publishers from using it for commercial advantage, and to prevent ill-meaning people from altering the meaning of the document by changing or removing a few paragraphs. Copyright © 1996-2000 L-Soft international, Inc. All Rights Reserved Worldwide. L-SOFT, LISTSERV and LSMTP are a registered trademarks of L-Soft international, Inc.
All of L-Soft's manuals for LISTSERV are available in ascii-text format via LISTSERV and in popular word-processing formats via ftp.lsoft.com. They are also available on the World Wide Web at the following URL:
http://www.lsoft.com/manuals/index.htmlL-Soft invites comment on its manuals. Please feel free to send your comments via e-mail to MANUALS@LSOFT.COM, and mention which manual you are commenting on. (However, please do not send support questions to this address. See chapter 19 of this manual for appropriate support addresses.) "Hot fix" revisions to this and other L-Soft manuals are posted as they are made to the master document, on the announcement-only mailing list:
LSOFT-DOC-UPDATES@PEACH.EASE.LSOFT.COMReference Number 0005-MD-01
Table of Contents
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|
|italic type||always indicates required parameter names that must be replaced by appropriate data when sending commands to LISTSERV|
|< >||Angle brackets may sometimes enclose required parameter names that must be replaced by appropriate data when sending commands to LISTSERV. Sometimes used for clarity when italic type is inappropriate|
|[ ]||Square brackets enclose optional parameters which, if used, must be replaced by appropriate data when sending commands to LISTSERV|
This manual makes the following assumptions:
In other words, we expect you already to be knowledgeable about the system on which you plan to install and run LISTSERV.L-Soft internationalís LISTSERV software is designed to run on various platforms that have widely-differing configurations. Therefore it is not within the scope of this manual to describe in detail (for instance) how you can tune sendmail 8.7.3 under Linux for optimum performance with LISTSERV. However, general tips that could work on all systems will be offered within these pages. Overall you will find that LISTSERV works much the same way on a unix workstation or a VMS minicomputer or an Intel Pentium machine running Windows NT as it has for years on VM mainframes. Where LISTSERV procedures do differ between platforms, we will detail those differences in order to minimize confusion.
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.
This chapter outlines differences between how LISTSERV is implemented on VM and non-VM machines, and the differences between LISTSERV and LISTSERV Lite.
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:
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 .
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
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:
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.
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.
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.Public Relations Lists
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.
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.
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 firstname.lastname@example.org.
Please note that this manual is not intended to replace the individual installation manuals for LISTSERV on the various platforms supported by L-Soft. This is because the installation procedures vary radically from platform to platform and this manual is intended to assist LISTSERV maintainers on operational LISTSERV sites. The installation guides for all platforms are included in the software distributions, and are also available on L-Soft's World Wide Web and FTP sites.
For the purposes of this chapter, therefore, it is assumed that you have already installed LISTSERV on your host computer and have been able to start it in successfully in interactive mode. If you have not reached this point, this chapter will be of little use to you.
These files have different names depending on the platform. They are located in the same directory with the executable binaries.
|Platform||Site configuration file|
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.
Table 5.1. LISTSERV site configuration variables
Defines the hostname of a machine that knows how to route mail to BITNET addresses
Tells LISTSERV where to send bounces not related to any particular list
List of library minidisks to be checked at startup
Defines the hostname used by the LCMD utility
The name of the CMS system to be used on IPL commands
Where to send VMS or NT crash reports
The password required to create new lists
Indicates whether the (old) VM database functions are enabled or not
Determines whether or not the new LISTSERV database functions use reverse indexing
Sets the default national language template for use by all lists on the server
Sets defaults for passive probing
Provides a default value for the "SPLIT=" command line keyword
The delay between two reader-scan operations
Indicates whether LISTSERV should use diagnose X'D4' to mimic the RSCS origin on files it DISTRIBUTEs
In 1.8d and following, space-separated list of non-POSTMASTER users who are to be allowed to use DISTRIBUTE
In 1.8d and following, Boolean value which controls security validation feature for the DISTRIBUTE command. WARNING: See Appendix C before changing this value.
The filemode of the DEFAULT disk to be used for storing files via a PUT command
The maximum number of lines for any incoming non-mail file to be accepted
Defines users or classes of users who should be exempt from LISTSERV's standard filter
Defines users or classes of users who should not be allowed to post to any list on the server.
Defines (in kilobytes) the "target size" for LISTSERV's file cache.
Defines (in kilobytes) the threshold at which point LISTSERV should start aggressively trimming the cache.
Defines (in kilobytes) the cache size at which LISTSERV should write a warning to the console log.
Internet addresses of persons to be granted an "infinite" GET quota
A list of userid@nodes whose messages and files are to be ignored
On VM, determines whether INDEX subscriptions use GETPOST or old-style database jobs by default.
The optional local "installation password" associated with the INSTALL command
Boolean value determining whether or not the "Summary of resource utilization" is generated or suppressed in a CJLI JOB command response.
Toggles license warnings on and off. WARNING: See Appendix C before changing this value.
Default value for the "List-Address=" keyword
Filenames of EXEC files that can be defined as exits by an "Exit=" list header keyword
a boolean variable indicating how PUT commands for datafiles associated with the LMC FAC are handled
a list of nodes to be associated with the hardcoded LCL FAC. Also used as the default for the "Local=" list keyword
Internet address of the local mailer
the maximum number of lines for an incoming MAIL file to be accepted
Maximum number of 'RCPT TO:' lines per BSMTP file sent to the mailer
Maximum number of recipients in forwarded DISTRIBUTE jobs
Maximum number of GET requests a user can make per day
Maximum number of kilobytes of data a user may obtain a day via GET requests.
Information about library minidisks
Userid of the virtual machine running a RFC1312/MSP server, if "Internet TELL" support is desired
The list of domain names which are equivalent to NODE--e.g., MX addresses, CNAMEs, etc.
Short organization name that appears in the RFC-822 "Sender:" line.
Whether to send mail to the local MAILER in Netdata format
Internet address of this LISTSERV host
Directs a VMS server running in NJE mode to send all outgoing server-to-server requests via the Internet
Defines the system and RSCS spool thresholds for automatic offline/online control
A list of userid@nodes, of which the first one is the "main" postmaster (to receive transferred files).
Defines the "prime time" for your node
Defines domain to be appended to all non-qualified addresses
Defines a list of filemodes which are to be considered as "reserved" and never available for dynamic ACCESS
A list of local userids which must be treated as RSCS virtual machines
The mode (NETWORKED, STANDALONE, or TABLELESS) that LISTSERV runs in.
Determines whether or not the (new) SEARCH command is enabled.
The Internet hostname of the server to which all outgoing SMTP mail should be forwarded for delivery
Defines n number of "SMTP workers" used to split up the SMTP forwarding load
|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|
Directs LISTSERV to reset open SMTP connections every n minutes
Determines whether or not to sort recipients in the RFC821 mail envelope
Sets the server-wide value (in minutes) for the anti-spam quarantine period
Flag telling LISTSERV that it runs in a SSI system
Recipients of start and stop messages
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
Defines the IP address used by the TCPGUI interface
Defines the port number used by the TCPGUI interface
List of userid@node templates from whom LISTSERV should never accept mail
List of userid@node templates to whom LISTSERV should never send mail
Indicates whether or not the VM30091 message suppression functions are available
Indicates whether or not LISTSERV should require "OK" confirmation for commands sent from WWW browsers.
The relative URL that leads to the WWW archive CGI script. (This is a URL, not an OS path name.)
The full OS path name to the WWW archive directory
Disable/enable the web archive interface's IP address verification function
Userid of the virtual machine to which files found in the lists readers should be transferred
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.
* 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.
Dependent on the platform, the required executables are:
|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):
on LISTSERV's A disk
in LISTSERV's "A" directory, normally LISTSERV_ROOT:[MAIN]
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:
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
Internet and Peer Networking Table files
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:
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.
Command line utilities (non-VM)
Depending on your platform, the following executables may have been shipped (under unix they must all be complied from the corresponding *.c files):LCMD.EXE (or lcmd*)
OpenVMS and unix: lcmd command
The user running LCMD must have appropriate permission (e.g., must be a list owner or LISTSERV maintainer) in order to issue the various protected commands.
listview [-h | -s | -e | -a] file1 file2...
You can choose only one of the command line options at a time. The options are:-h Show the header only -s Show the header + the subscribers (without the option string in columns 81-100) -e Show the list of subscribers only (without the option string -a Show the entire list file LISTVIEW executed with no option is the same as 'listview -a'. You can redirect the output of LISTVIEW with standard OS-dependent redirection symbols. For instance, listview -h mylist > mylist.file
redirects the output to the ASCII file 'mylist.file'.
While in use, LISTSERV creates various files for itself. On the A disk or in the MAIN or HOME directory, these are typically:
|.AUTODEL files||Maintain data for LISTSERV's autodeletion functions; one for each list that has Auto-Delete enabled. If no auto-deletion reports are pending, this file will not exist.|
|.CHANGELOG files||Contain data regarding subscription changes for a given list if that list has the "Change-Log= Yes" list header keyword setting. These files are called listname CHANGELG on VM.|
|.DIGEST files||These files are the (volatile) digest files for each list that has digests enabled. They are deleted and restarted when the digest is cut. Note that if the location parameter of the Digest= keyword is not set to something that points to the MAIN or HOME directory, .DIGEST files will not appear in the MAIN or HOME directory, but rather in the directory specified.|
|.LIST files||Mailing list files, including the header and subscriber information. Do not attempt to edit these files with a text editor; use the GET and PUT commands instead.|
|.OKxxxxxx files||Usually found for edited lists, but can also appear for non-edited lists if users are set to REVIEW. These are mail messages that are awaiting "OK" confirmation. If they are not confirmed, they are automatically deleted after about a week.|
|.OLDLIST files||These files contain the last saved version of the list file. If you PUT a header and find that you've made a fatal mistake (like adding users "on the fly" and deleting everyone else on the list, or editing the list file by hand and corrupting the record structure) you can send the command GET listname (OLD to have the listname.OLDLIST file sent to you.|
|.SUBJECT files||Maintain the list of subjects for the digest. Again, if digests are not enabled for a specific list, this file does not exist for that list. Also, the same note for the location of these files as for .DIGEST files applies. .SUBJECT files are deleted and restarted when the digest is cut.|
In the SPOOL directory, the following file types will be found:
|.ERROR||LISTSERV generates an .ERROR file in the spool when it encounters an error in a JOB file. These can be viewed with the jobview utility and are important for tracing certain errors back.|
|.JOB||Files that have been received by LISTSERV and are queued for processing. These files are in Base64 format and can be viewed with the jobview utility.|
|.JOBH||Held .JOB files. Such files are either being processed by LISTSERV (and are thus locked) or have generated an error message. These can also be viewed with the jobview utility.|
|Files that have been processed through LISTSERV and are queued for delivery to the outgoing SMTP mail agent. These are plain-text files.|
|.MAIL-ERR||Files that have been processed through LISTSERV and for which delivery has been attempted, but for which a "permanent" SMTP error has resulted. If you have reason to believe that the error was not actually "permanent", simply rename the file with the .MAIL extension and LISTSERV will pick it up for another try.|
JOBH files containing the string $NOJOB$ in the filename are typically waiting to be processed because the list they are going to has an explicit Prime= variable set and the non-prime time has not yet arrived.
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:
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
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
which allows them to create lists, customize site-wide WWW templates, and manage DBMS and mail-merge operations. This entry point also has a link to the list owner section, so site managers may wish to bookmark this entry rather than the LMGT1 entry.
See chapter 11 for detailed information on the web administration interface.
5.4.3. Installing a web server
Please note that L-Soft cannot help you with the installation or configuration of your web server itself. L-Soft does not recommend or endorse specific web servers, nor does L-Soft have development machines with every possible web server installed. You should ensure that the web server software you choose is installed and operating properly before attempting to install the LISTSERV WWW interface script.
If you do not already have a World Wide Web server installed and operating on your LISTSERV machine, you will need to obtain and install one. There are quite a few free web servers available for downloading on the Internet for most systems; you may want to start your search for server software at the W3 Consortium's web site at http://www.w3.org. Naturally, commercial web servers can also be used.Please note that for security purposes you should always disable directory browsing if it is not disabled by default by your web server.
5.4.4. Installing the web archive interface script
The CGI script for the web archive interface must be installed in the directory where your web server normally keeps CGI scripts and from which they are authorized to run. If in doubt, please read the manuals that came with your web server and/or contact the web server manufacturer's support group; L-Soft cannot help you with this. LISTSERV cannot install the script for you because installation depends on which server you use, which operating system you are running, how the server has been configured, etc.
System specific instructions:
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.
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:
System specific steps:
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:
This is done by modifying LISTSERV's site configuration file (see Appendix C) to add two variables:
at the end of go.user. Again, if these variables are already exported in the 'go' script, there is no need to do this.LISTSERV will then create and maintain a file called http://localhost/archives/index.html from which you can access all the postings. (This is made from the template WWW_ARCHIVE_INDEX--see below.)
Note that proper operation of the interface under LISTSERV 1.8d requires that the 'wa' script be able to talk to LISTSERV via TCP/IP to port 2306 (LISTSERV's TCPGUI port).
5.4.7. Customizing the web pages LISTSERV creates
Under LISTSERV 1.8d, the simplest (and recommended) way to make changes to the templates which contain the information for these pages is to use the tools provided in the WWW administration interface for changing the "look" of your site.The LISTSERV maintainer can create a file called www_archive.mailtpl in the main LISTSERV directory to override the web archive template forms found in default.mailtpl. (See chapter 9 for more information on LISTSERV's mail templates.) There are 3 templates you typically might want to override:
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 listsOnce the interface is installed, LISTSERV will automatically make any mailing list with public archives available through it, provided that a subdirectory has been created for them in the 'archives' subdirectory created above, and provided that LISTSERV has read/write access to the subdirectory.
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:
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 "email@example.com" and tries to log in as "firstname.lastname@example.org", he will be refused access. Also note that unless the list is coded "Confidential= Yes", there will be a link to its archives in the main archive index page.
If you do not want the confidential and/or "Private" list's notebooks available via the WWW interface at all, simply do not make a subdirectory for it under 'archives'.
Please note that when removing a list from the WWW archive interface, you MUST delete the list's directory under 'archives'. Otherwise someone with a bookmarked URL may still be able to access some of the archives via the web.
Also note that under unix, if the 'wa' script does not have the suid bit set, the interface will appear to work normally until you try to read a message. If the suid bit is not set, you will receive a message to the effect that the archives are not available and to try again in 30 seconds.
As an example, let's assume that you have a list called XYZ-L that you want to make available through the Web interface, and that so far you have used the defaults for the installation of the interface.
First, under the 'archives' directory you created above, you must create a directory with the same name as your list. Thus, in order to make the XYZ-L list accessible through the interface, you must create the directory 'archives/xyz-l' Next, you would edit the XYZ-L header to indicate how you want the list to appear to the interface. If you want the archives to be wide open, you must code
* Confidential= No
* Notebook= Yes,where,interval,Public
If you want the archives to be "wide open" but don't want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Public
If you want the archives to be accessible only by subscribers (with a password) and to have a link on the main archives page, you would code
* Confidential= No
* Notebook= Yes,where,interval,Private
And if you want the archives to be accessible only by subscribers (with a password) but you do not want a link on the main archives page, you would code
* Confidential= Yes
* Notebook= Yes,where,interval,Private
Finally, if you want the archives to be available via the interface (either with or without a password), and you want a link on the main archives page, but you do not want your list to appear in the CataList or global list of lists, you would need to code* Confidential= Service
and "Notebook=" would be either Public or Private depending on your preference, as above.
Please note carefully that coding the Confidential= keyword has other implications. For instance, if you want your list to show up in the CataList or be available via the Global List Exchange (GLX), you must set "Confidential= No". Thus advertising your list globally is not compatible with having your archives available via the web but not having a link on the server's main archives index page.
Finally, you would simply perform a GET and PUT of the XYZ-L header. When you PUT the header, LISTSERV will create the XYZ-L.HTML file in the 'archives' directory and build indexes for the list in the 'archives/xyz-l' directory.
Note: If you do not execute a list PUT operation after creating the directory for the list under Ďarchivesí (for instance, if the list already had public archives and it was not necessary to edit the header), LISTSERV will wait until midnight to create the web archive files for the list rather than creating them immediately. (Naturally, stopping and restarting LISTSERV will also force a rebuild of all of the web interface files but is not recommended as the normal way to accomplish this.)
At this point you will be able to access XYZ-L's archives from the URL http://www.yourhost.com/archives/xyz-l.html.
5.4.9. Enabling web-based bulk operations
Bulk operations (part of the list owner administration section of the interface) are not enabled by default when the interface is installed. As the site manager, you must create a directory called "upload" under the directory specified in the WWW_ARCHIVE_DIR= site configuration variable, and give the userid under which the "wa" CGI program is run write permission in that directory. This is the only directory in which "wa" needs write authority, and only for this functionality. If you do not want the functionality, do not create the "upload" directory.Please note carefully that your browser MUST support the RFC1867 file upload extension or you will not be able to use the bulk operations page. Most current browsers do support this extension, including but not limited to Netscape 3.x and later, and Internet Explorer 4.x and later. (If you get an error 2 when you click on the "Import" button, this means that the "upload" directory has not been created. If you get an error 13 when you click on the "Import" button, this means that the "upload" directory has been created but the CGI program user does not have write permission in that directory.)
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:
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.
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:
The only two restrictions placed on local servers are:
5.6.3. Automatic Registration for LISTSERV Lite Servers
LISTSERV Lite servers are registered automatically when you start the software for the first time. This auto-registration is not optional for Free Edition servers, and can only be disabled for non-Free Edition Lite servers by specifying STANDALONE runmode (see "RUNMODE=" in Appendix C).
The auto-registration allows you to take part in the global List of Lists and CataList services maintained by L-Soft. Registrations are verified on a regular basis by a central L-Soft server, which sends out several informational commands that return non-privileged information about your server (anyone can issue these commands). Since these registrations are maintained by regular communication with your server, please note that, should you decommission the server, registration verifications will continue to be mailed to your server for several days until the central server decides that your server is actually gone, and not simply unable to receive mail for some reason. Please note carefully that it is not possible for L-Soft to stop these registration queries manually even if you write to us and tell us that the server has been shut down permanently. They will stop after several days without a response.
Because 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.
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.Where you locate list archives is is particularly important with regard to LISTSERV's file server functions. You MUST NOT set up a file server sub-catalog entry in site.catalog that points to LISTSERV's A directory! The catalog owner will be given FULL ACCESS to all the files in the directory you specify in the sub-catalog entry. Therefore in order to maintain security you MUST make a separate directory for each list catalog you define in site.catalog. For simplicity's sake, it is generally best to use this directory for the list's notebooks as well as any files the list owners may want to store except for the web archive interface files.
Files generated by LISTSERV for the web archive interface MUST NOT be stored in the notebook directories (or vice versa). You MUST make a separate directory tree where the HTML files and index files for the 'wa' interface are kept. Our best recommendation is to place this directory tree under your web server's document root directory, so that the HTML files for the web archive interface are reached by using a URL such as http://yourserver/archives/. The location of this directory naturally varies from platform to platform and web server to web server; the guidelines in 5.4.5, above, will give you a start on finding this location.
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.
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) "email@example.com", which is what Joe wanted, to "firstname.lastname@example.org", "email@example.com", "firstname.lastname@example.org" 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 email@example.com with his actual subscribed address of firstname.lastname@example.org or any of the other cluster hosts in his domain.
This can also handle a situation where an ISP changed name and for instance "email@example.com" is rewritten to "firstname.lastname@example.org". However this does not handle "email@example.com" -> "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 firstname.lastname@example.org . 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.
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 email@example.com ,
or, for instance, for a large GETPOST job,
// GETPOST MYLIST 10769-10770 10772 11079 11086 11095 11099-11100 11104 ,
11111 11115 11118 11121 11124 11131 11144 11147 11153 11158 11166 11168
Be sure to put a space before the comma at the end of the first line, as LISTSERV will not add the space for you.
6.1.1. List subscription commands (from most to least important)SUBscribe listname [full_name | ANONYMOUS] [WITH options]
SUBSCRIBE listname ANONYMOUSThis indicates that the user wishes to join the list anonymously, that is, without specifying a name. The CONCEAL subscription option is automatically set, granting the subscriber the maximal level of protection available. LISTSERV 1.8d and later supports the following additional syntax:
SUBSCRIBE listname full_name WITH option1 option2 ...This syntax allows you to "preset" subscription options at subscribe time. For instance, you might want to subscribe to MYLIST-L in order to be able to search its archives, but don't want to receive postings. You would use the command
SUBSCRIBE MYLIST-L Joe User WITH NOMAILOr you might want to receive individual postings with the SUBJecthdr option and receive copies of your own postings instead of the standard acknowledgement that your message was distributed to the list:
SUBSCRIBE MYLIST-L Joe User WITH SUBJecthdr REPRO NOACK
listname Sign off of the specified list
* Sign off of all lists on that server
* (NETWIDESign off of all lists in the LISTSERV network
The "* (NETWIDE parameter causes the LISTSERV server to forward a copy of the signoff request to all other registered LISTSERV servers. This is a good option for a user who is changing service providers or otherwise losing a specific address that will not be forwarded. Please note that this parameter will not remove the user from non-LISTSERV lists or from LISTSERV lists running on non-registered sites.LISTSERV will attempt to sign off the address it finds in the RFC822 "From:" line and will not "fuzzy match" for "similar" addresses.
These options change the format in which list mail is received by the subscriber. DIGEST turns on digest mode, in which the subscriber receives a digest of postings at set times dependent on how the "Digest=" keyword of the list is set. INDEX turns on index mode, in which the subscriber receives a daily listing of subjects posted to the list, from which he or she may order postings of interest. NODIGEST and NOINDEX toggle the mode back to individual postings sent as received by LISTSERV. Note that these options are interrelated; setting one will negate another.
SHORT822 Essentially the same as "short" mail headers, with the same caveats as noted for FULL822.Note that FULL822 and SHORT822 headers should only be used if a specific problem indicates that they might solve the problem. One possible use would be to determine which subscriber from a specific site is causing the site to throw back delivery errors if that site does not specify which RCPT TO: is generating the error. These headers should never be used by default.
Figure 6.1. Sample output of an INDEX listname command.
* * MYLIST FILELIST from LISTSERV@LISTSERV.MYCORP.COM * * ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: * * The GET/PUT authorization codes shown with each file entry describe * who is authorized to GET or PUT the file: * * ALL = Everybody * CTL = LISTSERV administrators * OWN = List owners * PRV = Private, ie list members * LMC = LISTSERV master coordinator * N/A = Not applicable - file is internally maintained by LISTSERV * MSC = Miscellaneous - contact administrator for more information * * ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: * * * Information files for MYLIST * * filename filetype GET PUT size (bytes) date time * -------- -------- --- --- ------------ ---------- -------- MYLIST FAQ ALL MSC 22,528 1996-02-09 21:30:10 MYLIST WELCOME ALL MSC 279 1998-02-02 09:59:44 MYLIST FAREWELL ALL MSC 92 1998-02-05 11:06:14 * * Archive files for the MYLIST list at LISTSERV.MYCORP.COM * (monthly logs) * * filename filetype GET PUT size (bytes) date time * -------- -------- --- --- ------------ ---------- -------- MYLIST LOG9603 LOG OWN 8,668 1998-05-27 15:29:57 MYLIST LOG9605 LOG OWN 7,865 1998-06-29 08:43:26 MYLIST LOG9606 LOG OWN 17,298 1998-07-23 12:46:20
Stats listname [(options]
GET fn ft [filelist] [(options] [F=fformat] [SPLIT=integer]
(Note: Prior to 1.8d this command is not available on non-VM servers.)Sends a file stored in a LISTSERV file archive to someone else. For instance, you may want to send LISTSERV REFCARD to a new user. Rather than retrieving LISTSERV REFCARD and then forwarding it to the user, you simply issue a GIVE command to tell LISTSERV to send it directly. Note that the token "TO" is optional. Examples: For LISTSERV running under VM: GIVE LISTSERV REFCARD firstname.lastname@example.org
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.
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.
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:
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.
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 creationAt its simplest, creating a list is a matter of setting certain keywords to desired values in a file (called the "list header file") and storing the file in a place where LISTSERV can find it. The format of a typical list header file is relatively free-form, with only a few basic rules:
PUT listname.LIST PW=passwordto the top of the file before mailing it. This PUT line does not begin with an asterisk. (Note that the filename for the list can be either in the format listname LIST or listname.list . The "." character is not necessary, but the word LIST is always necessary.) Here is a sample of a basic list header with its PUT command at the top:
Figure 7.1. A sample list header.
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= email@example.com *
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"where "NAME" is the name of the mailing list, "/BBB" in the directory where the mail interface was installed (BINDIR in the Makefile), and "/SSS" is the LISTSERV spool directory (LSVSPOOL in the Makefile). Note that "/SSS" can be either:
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"(note that the aliases may not wrap to the next line in /etc/aliases) If you should decide to use the explicit definition for the LSVSPOOL parameter, the aliases would look like this instead: mylist: "|/usr/local/bin/lsv_amin /var/spool/listserv mylist" and so forth. Once you've added the new aliases to the file, you need to issue the "newaliases" command and (on some systems) send your Sendmail daemon a hangup (HUP) signal before they will take effect. 7.2.2. VMS: Creating required PMDF aliases This section is for use only by VMS sites running Innosoft International, Inc.'s PMDF® product, version 4.2 or later. Please note that you will require system level privileges to edit the file in this step . If PMDF is installed, in addition to the listserv and owner-listserv aliases which you've created in PMDF_ROOT:[TABLE]ALIASES at install time, you will need to add the following eight aliases for each new mailing list you create, where listname is the name of the list:
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@LISTSERVNote: You can get around this bit of tediousness (and also solve a problem with address probing under VMS with PMDF as documented in 13.5.3, below) by simply creating a dedicated domain for LISTSERV (eg, LISTSERV.XYZ.COM) and adding a rewrite rule to redirect all traffic for that host to the LSV channel. This also simplifies the creation of new lists since it is no longer necessary to make all of the PMDF aliases shown above every time you make a new list.
7.4. Naming ConventionsWhen naming a list, there are a few conventions and restrictions that you should keep in mind. The "-L" convention The "-L" convention isn't required, but it can help people to realize that the mail is coming from a mailing list rather than from a real person. The people we are referring to here are people who run Internet mail systems, who may see a great deal of mail coming from a single host and begin to wonder why. If it comes from a userid that ends in a "-L", they will be more likely to recognize it as list mail. Reserved characters Generally you want to avoid "special" characters such as the ones above the number keys on your keyboard. For example, don't use:
GET listname (HEADERThe GET command automatically locks the list so that no changes can be made to the operating copy on the server until you do one of two things:
* PW=MYPASSWDReplace "MYPASSWD" with the word chosen. Note that there should not be a space between "PW=" and the password. The list password is never changed unless specified explicitly in the list header when it is stored on the server. For additional security, the list password will not appear in the list header on subsequent GETs; to all intents and purposes it is invisible once it is assigned. L-Softís position on list passwords is that they have become obsolete with version 1.8c (they were actually obsolete as far back as 1987), and that personal passwords should be used instead to validate commands (such as the PUT command).
Figure 7.2. A sample list header file for a list called MYLIST.
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... *
Figure 7.3. The edited list header file ready to be sent back to the server.
PUT MYLIST.LIST PW=MYPASSWD * The Descriptive Title of My List * * Owner= NATHAN@LSOFT.COM (Nathan Brindle) * Owner= Quiet: * Owner= firstname.lastname@example.org * Owner= email@example.com * Notebook= Yes,E:\LISTS\MYLIST,Monthly,Public * AutoDelete= Yes,Full-Auto * Errors-To= firstname.lastname@example.org * 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... *
* The coffee lovers' list * * Review= Public Subscription= Open Send= Public * Notify= Yes Reply-to= List,Respect * Notebook= Yes,L,Monthly,Public * * Owner= email@example.com (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> *In other words, you just insert your HTML text in the list header and bracket it with <HTML> and </HTML> tags (these tags tell the web interface where the HTML text begins and ends -- they are not actually sent to the web browser). There are three simple rules that you must follow when inserting your HTML data:
<!--#listref listname@hostname-->This sequence is internally translated to an <a> tag with a URL that will bring up information about the list you indicated. You must then provide a suitable caption and a closing </a> tag. Example: Don't forget to take a look at
* * 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> *In that case, you can just reorder the HTML data so that the equal sign does not appear in this position. Alternatively, if the equal sign was meant to be actually displayed as an equal sign (as opposed to being part of some HTML tag), you can use the HTML escape sequence = instead.
* 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= firstname.lastname@example.org * Notebook= Yes,E:\LISTS\MYLIST-L,Weekly,PublicFor more security, you might want to code * Validate= Yes,Confirm and if you want to cut down on the amount of "me-too"ism on the list, you could set * Reply-to= Sender,Respect to force the default Reply-To: header to point back to the original poster instead of to the list. There is one major caveat with regard to the use of the Reply-To= list header keyword. You should note carefully that not all subscriber-side mail clients either recognize or properly handle an RFC822 "Reply-To:" header. This may result in users posting replies to your list even though LISTSERV put the correct Reply-To: header on the mail. There is absolutely nothing that L-Soft can do to correct this problem since it exists on the subscriber's end in non-compliant mail software that L-Soft does not and cannot support. 7.13.2. Private discussion lists Private discussion lists are similar to public discussion lists, but with varying restrictions on who may subscribe, who may post and who may view the archives. Such lists are relatively safe from random spamming since typically only a subscriber can post (but note that a spammer spoofing mail from a subscriber's address will probably be successful unless first caught by the anti-spamming filters). For instance:
* 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= email@example.com * Notebook= Yes,E:\LISTS\PRIVATE-L,Weekly,Publicis a low-security private discussion list where subscriptions requests are passed on to the list owner(s) for review, only subscribers may post, and only subscribers may view the list archives. Here again, for more security you might want to set "Validate= Yes,Confirm", and of course you can have replies go to the original poster rather than to the list with " Reply-To= Sender,Respect" (with the same caveats as noted above in 7.13.1). 7.13.3. Edited lists An edited list is one which requires a human editor to approve messages sent to the list. Some list software and most USENET newsgroups refer to this as "moderation", but to avoid confusion between two types of moderated LISTSERV lists, the present example will be referred to as an "edited" list. Examples of edited lists range from refereed electronic journals to lists where the list owner simply wishes to exercise control over which postings are allowed to go to the list. To set up a basic edited list, simply add
* Send= Editor * Editor= firstname.lastname@example.org the basic list header. Note that the primary Editor= specification (that is, the first editor defined by an Editor= keyword for the list) must be a human person who will be able to act on postings sent to him or her for approval. You may not use an access-level specification (such as "Owner") when defining the primary editor for a list. Please note that L-Soft recommends setting "Send= Editor,Confirm" so as to add a level of security against malicious users forging mail from an "Editor=" address to get around your moderation settings, or against badly-configured "vacation" programs that simply reflect the message back to the list in a manner that makes it appear that the mail is coming from the editorís address. The "Confirm" option causes LISTSERV to request an "OK" confirmation from an editor when it receives mail claiming to be from that editor. You can define multiple editors, but only the first editor will receive postings for approval. Anyone defined as an editor may post directly to the list without further intervention. Multiple editors can be defined on separate Editor= lines or can be grouped several on a line, e.g.,
* Editor= email@example.com,firstname.lastname@example.org * Editor= email@example.comTo approve postings with the above configuration, the editor simply forwards (or "resends", or "bounces"--the terminology is unclear between various mail programs) the posting back to the list address after making any desired changes to the content. This should be done with a mail program that supports "Resent-" fields; if "Resent-" fields are not found by LISTSERV in the headers of the approved posting, the posting will appear as coming from the editor's address rather than from the original poster. If your mail program does not support "Resent-" fields, you should use the "Send= Editor,Hold" option and approve messages with the "OK" mechanism described below. If you do not need to physically edit the content of your users' posts (for instance, to remove anything considered "off-topic" or to remove included mail headers and so forth), you can code
* Send= Editor,HoldThe "Hold" parameter causes LISTSERV to send you a copy of the posting along with a "command confirmation request". To approve the posting, you simply reply to the confirmation request with "ok". For security purposes, you can code
* Send= Editor,Confirmwhich will cause LISTSERV to request a command confirmation ("ok") from the editor sending the approved posting back to the list. This makes it impossible for an outside user to "spoof" mail from an Editor address. Naturally, you can also code
* Send= Editor,Hold,ConfirmFinally, please note that the NOPOST subscriber option will take precedence over Editor=, if set for someone defined as an editor. This means that if you have "Default-Options= NOPOST" for your list and you add an editor as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor can successfully approve postings but is then told that he or she cannot post to the list. 7.13.4. Moderated lists Note: The Moderator= keyword is disabled in LISTSERV Lite. A moderated list is similar to an edited list, but for LISTSERV's purposes it refers to a list that uses the Moderator= list header keyword to "load-share" posting approvals among several editors. It is set up similarly to an edited list, as follows:
* Send= Editor,Confirm * Editor= firstname.lastname@example.org * Moderator= email@example.com,firstname.lastname@example.org * Moderator= email@example.comThis list will "load-share" the approval process between the three moderators, who will each receive one-third of the postings for approval. Note that a primary editor should still be defined. If it is desired to have one editor handle more than a single share of the approvals, you simply define the editor more than once in Moderator=. For instance,
* Send= Editor,Confirm * Editor= firstname.lastname@example.org * Moderator= email@example.com,firstname.lastname@example.org * Moderator= email@example.com,firstname.lastname@example.org cause every other posting to be forwarded to email@example.com for approval. Beginning with 1.8c, if the parameter "All" is coded at the beginning of the list of moderators, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be * Moderator= All,firstname.lastname@example.org,email@example.com Please note that something like * Moderator= firstname.lastname@example.org,All,email@example.com,firstname.lastname@example.org is not valid. "All" must appear at the beginning of the list of moderators. Assuming "Send= Editor, Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that the message cannot be found and has probably expired (since the cookie for that message will be gone). If the message body is edited in any way before it is approved (i.e., by forwarding an edited copy back to the list), and more than one moderator is involved, duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator. Note carefully that this means if the "All" parameter is used in "Moderator=" with "Send= Editor" (that is, without the "Hold" parameter), again a separate synchronization method will have to be used to prevent duplicates, as two moderators are unlikely to make exactly the same edits to the message. Even if LISTSERV were able to identify the two submissions as being the same message, it would not know which to choose over the other. The "Hold" and "Confirm" options for "Send=" can also be used with these examples, if desired. L-Soft recommends that "Confirm" be used by default. Finally, please note that the NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list. 7.13.5. Semi-moderated lists "Semi-moderation" was developed some years ago after a great debate on whether or not an "urgent" message should be allowed to be posted to an edited list without having to go through the approval process. Although this option is still available, it can be misused by anyone who knows about it, and is therefore not generally recommended for use. However, should this feature be deemed necessary, it is activated by setting * Send= Editor,Semi-Moderated Then anyone needing to send an "urgent" message to the list simply types "Urgent:" in the subject line of their mail, followed by the subject of the message. Messages that do not have the "Urgent:" subject are forwarded to the list editor for approval as usual. 7.13.6. Self-moderated lists So-called "self-moderated" lists were invented in 1993 or 1994 when the current epidemic of spamming was beginning to get cranked up and before the "spam filter" was developed by L-Soft. With the spam filter in operation, self-moderation is not as much of an issue anymore, but some lists still run this way. Self-moderation takes advantage of the ability to make an access-level a secondary list editor, and is implemented as follows:
* Send= Editor,Confirm * Editor= email@example.com,(listname)(The "Hold" and "Confirm" parameters for "Send=" may naturally be used if required. L-Soft recommends that "Confirm" be used by default.) Usually, one of the list owners is the primary editor (here "firstname.lastname@example.org") and the specification of (listname) makes all of the subscribers of the listname list editors, and thus eligible to send messages directly to the list without editor intervention. Postings from non-subscribers (e.g., spammers) are deflected to the primary owner for his or her disposition. There is one caveat to this kind of list. If a user subscribes to the list, and later his mail address changes (for instance, the hostname changes slightly but mail sent to the old address is automatically forwarded to the new address), any postings from him to the list from the new address will be forwarded to the editor because the new address is not subscribed to the list. Thus there is a certain amount of list-owner overhead on this kind of list in keeping track of users whose addresses have changed and modifying the subscriber list to reflect those changes. The "CHANGE" command added in 1.8d can be of help in this regard. 7.13.7. Auto-responders Since LISTSERV Lite does not support list-level mail templates, this functionality is effectively not available in LISTSERV Lite. An "auto-responder" is a type of list that simply responds with a set message whenever it receives mail from someone. This kind of list can be useful for things like service messages or upgrade availability, or even to simply send back a standardized message to a user who has sent mail to a "support" address. A simple auto-responder header might look like this:
* Auto-responder for service messages * Owner= email@example.com * Send= Public Notebook= No Subscription= ClosedIn other words, it can be very simple, since you probably don't want notebook archives for this kind of auto-responder, you don't want people to subscribe to the list as it isn't really a mailing list, and so forth. To make the auto-response message for this list, you'd then create a listname.MAILTPL file (see chapter 10 for details) that includes a POSTACK1 template, like the following:
>>> 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.This particular template would inform the user that LISTSERV would be down (&MYNAMES translates to LISTSERV@NODE where NODE is the value of NODE= in the system configuration file) and to send questions to LSTMAINT@ the local host. In order to change the service message, it would be necessary only to change the POSTACK1 template. 7.13.8. Announce-only lists An "announce-only" list would be used to distribute a newsletter or other timely information where responses to the list are neither expected nor desired. A typical announce-only list header might look like this:
* The FOO Product Announcment List * Owner= firstname.lastname@example.org * Owner= Quiet: * Owner= email@example.com * Owner= firstname.lastname@example.org * Editor= email@example.com * Editor= firstname.lastname@example.org * Editor= email@example.com * Notebook= No * Errors-To= Owner * Subscription= Open,Confirm * Validate= No * Review= Owners * Send= Editor,Confirm * Reply-To= firstname.lastname@example.org,Ignore * Sender= NoneThis list is set up so that generally any response to postings will go back to email@example.com, which might be a special account set up specifically to handle such things, or a mail alias pointing to another account. The newsletter can be posted by foo, or anotheruser, or yetanotheruser, all of whom are editors, but the likelihood is that it would be posted from the foo userid so that the From: line would read "From: firstname.lastname@example.org". L-Soft strongly recommends that all announce-only lists use the "Send= Editor,Confirm" or "Send=Editor,Hold,Confirm " setting. The ",Confirm" parameter tells LISTSERV to require a confirmation for any posting sent by a user defined as an Editor=. This is important for two reasons:
>>> 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.The .TO &WHOM directive is required so that the message is sent to the subscriber rather than to the list owner. If you want the non-quiet list owners to receive a copy of this message (which is admittedly unlikely), you can simply add CC: &OWNERS to the end of the .TO line, e.g., .TO &WHOM CC: &OWNERS Or, if you want to cc: a specific user such as email@example.com, use .TO &WHOM CC: firstname.lastname@example.org Note that you cannot format the SUB_OWNER template; it all comes out as one long paragraph without formatting no matter what you do, because it is a "linear" template. But you should modify it from the default to let people know that they will receive a questionnaire to be filled out and returned. The second template form you need to add to listname.MAILTPL is called ADDREQ1 and it can be as simple or as detailed as you want. All of the available template formatting commands can be used in ADDREQ1. For instance:
>>> 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...In this case you want the message to go to the subscriber, with a Reply-To: header pointing back to the (non-quiet) list owners. The first line indicating the return address is added for those users with mail clients that don't recognize Reply-To: headers. You can also put a pre-formatted ADD job into the questionnaire to simplify your job when the questionnaire comes back. For instance,
.fo off ---------------------------------------------------------------- For List Owner's Use Only -- Be sure to include with your Reply ---------------------------------------------------------------- // JOB ADD &LISTNAME &WHOM &USERNAME // EOJ ---------------------------------------------------------------- .fo onFor more detailed information on mail templates, see chapter 9. 7.13.10. Peered lists This functionality is not available in LISTSERV Lite. Occasionally the need to split a very large list may arise. This was more common when LISTSERV ran only on BITNET, whereas the TCP/IP version of LISTSERV is not limited by BITNET constraints. However, because of the fact that subscribers may be scattered all over the world, in rare cases it can make sense to split (or "peer") a list and share the mail load among two or more LISTSERV servers. Peering also makes it possible to have list archives located in more than one place; for example, a list might be peered between a European host and a North American host, making it possible for subscribers on each continent to retrieve archives from the nearer host. Although there is no problem about peering to another L-Soft LISTSERV list, linking to a non-L-Soft mailing list manager is not supported and can and will cause serious problems (including mailing loops) for which L-Soft international, Inc. could not be held responsible. After the link operation has been completed, it is recommended that you define "Peers=" keywords on lists you just linked. For lists running on LISTSERV for VM, this makes it possible to EXPLODE them for better network efficiency. (Because peering is not widely used today, it is unlikely that the EXPLODE command will be ported to other platforms.) Note also that the peer lists MUST have the same list password (PW= list header keyword setting) or messages approved on one peer will not be accepted by the other peer and an error message will be generated, i.e.,
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) --------------------------This means that under LISTSERV 1.8c and later you must explicitly set the PW= list header keyword for each peer and not use the password LISTSERV generates automatically at list creation time. Moving users from one (peer) server to another: You should be aware of the fact that a MOVE operation is not just an ADD to the new server and a DELete to the current one. This would effectively transfer the person from the old server to the new one but his distribution options would be lost in the process. Besides, you should make sure that the user does not lose any mail in the process. The proper course of action to be taken when people are moved from one list to the other is the following: 1. Send mail to the list telling people that a new peer server is being linked to the list, and that some subscribers will be moved to it. 2a. If the prerequisites for using the MOVE command are met, you should use either individual MOVE commands (in the case that there are very few users to move) or a batch-MOVE command with associated DDname (see the LISTJOB MEMO guide for more information on commands-jobs) to move the users. You may want to use the QUIET option to suppress notification if there are a lot of users to move. Warning: the MOVE command should not be used to move peer list servers. See the MOVE command description for more details. If you cannot use the MOVE command, you should try one of the following two methods: 2b. For each user to be moved, issue the following commands in the following order:
PUT M101 KEYWORDS PW=createpw * Owner= email@example.com (Professor J. Random User) * Owner= Quiet: * Owner= firstname.lastname@example.org (Joe Doakes, Graduate Assistant) * Notebook= Yes,/home/listserv/archives/m101,Monthly,Private * Auto-Delete= No * Errors-To= email@example.com * 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).Note that it is also possible to create this file directly in LISTSERVís A directory with a text editor; if you do so, make sure that you do not include the PUT command shown above. You should still make the filelist or catalog entry for the file so that the list owners can retrieve and store it. Next, the LISTSERV maintainer creates and stores a skeleton list header for each of the section lists. The first section list (M101-001) is illustrated below: PUT M101-001 LIST PW=createpw
* 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 2AAARAA3nAAADepending on how your mail client handles long lines, the subscriber lines will be either:
nxxxxx@LSOFT.COM Nxxxxx Bxxxxxx 2AAARAA2bAAANext, assuming that the subscriber lines are correctly formatted, cut and paste list B into a new mail message addressed to LISTSERV. Make sure that your mail client has all formatting options turned off; for instance, make sure line wrap and any automatic "rich text" or HTML mail formatting is turned off. If you do not do this there is no guarantee that the list file will reach LISTSERV properly formatted. At the bottom of this new message, you can cut and paste the subscribers from list A. Note that you don't want the header of list A, just the subscriber lines. Make sure that there is no blank line between the subscribers you pasted from list B and the subscribers you have just pasted from list A. Finally, you can now PUT your new merged copy of list B. 2 7.14.3. Merging list A and list B into list C In this case (where you may be starting a completely new list and want to merge two old lists into it), follow the directions above depending on whether or not you want to preserve user options across the merge or not. The only difference is that you will be combining the subscribers from two lists into another list instead of combining subscribers from one list into a second list. In this case you do need to be careful not to add duplicate addresses, as LISTSERV will not catch them when you PUT the new list file. In fact it is probably more sensible to set appropriate defaults to the new list and store the header by itself, then add the users with a bulk operation (not preserving their old options) so that LISTSERV can catch any duplicates you might add.
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.
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.,
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 firstname.lastname@example.org POSTPONE NEWLIST NO user's name and reduce it at least to email@example.com user's name Otherwise, the ListProc options will become part of the full_name field.
QUIET ADD listname DD=X IMPORT //X DD * internet-address1 full_name internet-address2 full_name /*
> QUIET ADD XXXXX-L DD=X IMPORT ADD: no error, 2 recipients added, no entry changed, none forwarded.
* New-List= JOESLIST-L@LISTSERV.MYHOST.COM * Confidential= Yesin the list header so that a) the list no longer appears in the global List of Lists and in the CataList and b) so that all mail and inquiries sent to the old list address will be forwarded on to the new one. When you've made the changes to the header, PUT it back on the server. 14. Issue a FREE JOESLIST-L command to LISTSERV. (You should not need to issue a FREE MYLIST-L command.) Congratulations, you've finished renaming the list. At this point you should probably announce the change and let people know where to find the archives, etc.
[QUIET] ADD listname DD=ddname [IMPORT] PW=yourpassword //ddname DD * firstname.lastname@example.org [full name] email@example.com [full name] ... firstname.lastname@example.org [full name] /*The IMPORT option implies a QUIET ADD (in other words you do not need to specify QUIET if you use IMPORT) and otherwise vastly speeds up the ADD process by loosening syntax checking and omitting success messages. If you do not use the IMPORT option and do not specify QUIET, the users you bulk add will receive the normal SIGNUP message and/or WELCOME file as usual. It is also possible to do bulk operations through the Web Administration Interface; see chapter 11 for details. 7.17.2. Bulk DELETE operations If you have a large number of users to delete at one time, you can use a bulk delete syntax that is similar to the bulk ADD documented above. However please note that there is no "IMPORT"-type option for this feature, and as usual for the DELETE command you specify only the user's address in the data DD. There is, however, a BRIEF option that can be specified, which is useful when you don't want a long list of "userid@host has been deleted from list xxxx" messages, one for each user deleted. Use of the BRIEF option tells LISTSERV to return only a count of the users that were deleted. Once again you construct a LISTSERV JOB framework as follows and then send it to LISTSERV:
[QUIET] DELete listname DD=ddname PW=yourpassword //ddname DD * email@example.com firstname.lastname@example.org ... email@example.com /*You will probably want to use the QUIET modifier when doing a bulk delete, in order to suppress the notification message to the users being deleted. It is also possible to do bulk operations through the Web Administration Interface; see chapter 11 for details.
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.
On VM Systems ONLYWith the traditional system (running on the VM servers), the LISTSERV maintainer creates files called "xxxx FILELIST", which contain definitions for all the files belonging to a particular archive. These FILELIST files must be created by the LISTSERV maintainer at the site before they can be edited by the list owner.3 On Workstation and PC Systems The LISTSERV maintainer stores "root-level" file definitions in a file called SITE.CATALOG, which should be placed in the same directory with the SYSTEM.CATALOG file.4 Beginning with 1.8c, the LISTSERV maintainer can also define "sub-catalogs" which in turn can define further files. You should be aware of the differences between VM and workstation file server functions as many people are using and will continue to use the VM file server with different conventions, and may give you incorrect advice. Non-VM sites should skip section 8.3, and use the information below in section 8.4 to maintain their file archives.
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.Maintaining the filelist for your archive is not difficult. It requires only that you have a working knowledge of VM XEDIT (or your local system's editor) and understand how to send files via e-mail. 8.3.1. Creating a filelist Please see FSV GUIDE (available at ftp://ftp.lsoft.com/documents/fsv.guide) for details. 8.3.2. Adding FAC codes Please see FSV GUIDE (available at ftp://ftp.lsoft.com/documents/fsv.guide) for details. 8.3.3. Retrieving the filelist To retrieve your filelist in an editable format, send the command
GET listname FILELIST PW=XXXXXXXX (CTLto the LISTSERV host where the filelist is stored. The (CTL switch causes LISTSERV to lock the filelist until you store it again or explicitly unlock it with an UNLOCK listname FILELIST command. (If you don't want to lock the filelist, use (CTL NOLOCK instead.) If your mail account is not located on the same host as LISTSERV, you will need to provide your personal password (same as your password for getting and putting your lists). A filelist retrieved with the (CTL option does not look like the filelist you get with an INDEX command. A sample (CTL option filelist appears below:
Figure 8.1. Sample filelist retrieved with (CTL option.
* 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 MYLISTNote that the line must begin with a space. Also, you must place five dots separated by spaces between the PUT file access code (here it is OWN) and the short description. These dots are place holders for the record format (recfm), logical record length (lrecl), number of records (nrecs), and the date and time of the last update. If these dots are not present, LISTSERV will return an error message when you try to store the filelist. You will note that the line you have just added does not look like the other lines in the filelist. Ignore the "pretty" formatting. LISTSERV will reformat the information for you. After adding the line, your filelist should look like this:
Figure 8.2. Adding a file descriptor to the filelist
* 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=XXXXXXXXwhere XXXXXXXX is your personal password for LISTSERV on that host. Note that this is similar to the PUT command used when storing the list file. 5. Send the filelist to LISTSERV. Once LISTSERV acknowledges the receipt and storage of the filelist, you can send the files that correspond to the file descriptors in your filelist. See section 8.5, below, for instructions.
MY.FILE my.file./home/lists/xyz ALL JOE@XYZ.COMIn 1.8c a new "native" format for these entries was introduced, and the new format is used in all of the examples below. The old format remains supported for compatibility. However, note that you MUST use the old format if any of the directories in the path contains a period. Documented restriction: All files manipulated by LISTSERV must be accessible through LISTSERV's OS-independent file access methods. This means that files whose name contains spaces or control characters (or, under unix, upper case characters) cannot be accessed. Similarly, files whose name does not contain a period cannot be manipulated by LISTSERV. There is no limit on the length of the file name, only on its contents. Note that these "system filenames" are not visible to the end users, who refer to the files by the names assigned in the catalog. 8.4.1. Adding files to the SITE.CATALOG This is the most basic way to add files to LISTSERV's file archive system so they can be made available to users via the GET command. To register a new file to the server on workstation systems, the LISTSERV maintainer adds a line to the SITE.CATALOG file. If SITE.CATALOG does not already exist (it is not shipped with the installation kits), simply open a new ASCII text file named site.catalog in the same directory as system.catalog and add entries to it as shown below. (Do not just add entries to system.catalog as this file will always be overwritten during a software update.) Here is what a typical SITE.CATALOG entry looks like under Windows NT:
And the same entry under Unix would look like this:
MY.FILE C:\FILES\XYZ\MY.FILE XXX YYY
(Note that under Unix, LISTSERV does not observe case-sensitivity internally. Therefore you cannot define two different files with the same non-case-sensitive filename. In other words, LISTSERV will not differentiate between MY.FILE and my.file, or even My.File. But note carefully that the physical files you store must be named in lower-case; in other words, the output of an 'ls' command must show my.file, not MY.FILE or My.File. LISTSERV will handle this issue automatically when you PUT the files, but be forewarned if you store the files on the server via ftp or the Unix file system.) Finally, here is a VMS example:
MY.FILE /files/xyz/my.file XXX YYY
The first item, MY.FILE, is the name by which the file is known to LISTSERV. That is, the users will use GET MY.FILE to order a copy of that file. The name should contain only one period. The second item, for instance C:\FILES\XYZ\MY.FILE, is the name LISTSERV will use for the actual disk file, in native OS format. Note that the directory must be created before you register the file. For security reasons, LISTSERV will not create the directory (or set the protections) for you. Note that LISTSERV will normally need full access to these files. The third and fourth items are "File Access Codes" (FACs). The first is for read accesses, and the second for writing. The following file access codes are available for non-VM servers (for VM FAC codes, see 8.3.5, above): ALL universal access. CTL only the LISTSERV maintainers have access. PRIVATE(xxx) only members of the xxx list have access. OWNER(xxx) only the owners of the xxx list have access. SERVICE(xxx) only users in the service area of the xxx list have access. NOTEBOOK(xxx) same access as the archives of the xxx list. user@host the user in question is granted access. Except for ALL, which must occur on its own, multiple file access code entries can be specified, separated by a comma with no intervening space. For instance:
MY.FILE XYZ:[FILES]MY.FILE XXX YYY
defines a file that Joe, Jack and the subscribers of the XYZ-L list can order via the GET command, but that only the LISTSERV administrator can update.
MY.FILE C:\FILES\XYZ\MY.FILE JOE@XYZ.EDU,JACK@XYZ.EDU,PRIVATE(XYZ-L) CTL
MY.CATALOG /home/lists/xyz/my.catalog ALL JOE@XYZ.COM (1) (2) (3) (4) (5)Notes: (1) The name must end in '.CATALOG', but otherwise it can be anything. In particular, there does not need to be a list by that name. (2) The directory specification indicated for the catalog file (e.g., /home/lists/xyz) is where ALL the files defined in the sub-catalog will be stored. DO NOT USE LISTSERV'S MAIN DIRECTORY FOR THIS PURPOSE! The catalog owner will be given FULL ACCESS to all the files in this directory, so make sure to create a new, empty directory. If the sub-catalog is being set up for a list owner, it may be a good idea to put the list archives and the sub-catalog in the same directory. (3) A file name must be provided for the sub-catalog file itself. This name, however, does not need to match (1). (4) This file access code controls the authority to INDEX the sub-catalog. This will also be the default GET access code for all the files registered in the sub-catalog. (5) This file access code defines the catalog owner(s) and default file owner(s) for all the files in the sub-catalog. Note that there is no need to reboot LISTSERV after updating the SITE.CATALOG file. Also, bear in mind that you are responsible for the OS-level security of the directory you create for the catalog. The file access codes in SITE.CATALOG only affect operations that go through LISTSERV; it is your responsibility to make sure that other users of the computer are given the appropriate access level to any directory you create for LISTSERV's purposes. 8.4.4. Updating the sub-catalog Once the sub-catalog is created, the catalog owner(s) can register new files using the following procedure (in this example, it will be assumed that the sub-catalog is called MY.CATALOG): 1. Send a GET MY.CATALOG command to LISTSERV (or, if the catalog is brand new, start from an empty file). 2. Register new file(s) in the catalog (see below). 3. Use the PUT MY.CATALOG PW=XXXXX command to store the updated catalog. Alternatively, if the catalog owner has an account on the LISTSERV host system and write access to the directory associated with the sub-catalog, the file can be edited directly. Note however that, in that case, the LISTSERV-ISP quota system will be inoperative as it has no control over disk accesses which do not go through LISTSERV itself. The format of sub-catalogs is similar to that of SITE.CATALOG:
MY.FILE my.file ALL JOE@XYZ.COM (1) (2) (3) (4)Notes: (1) This defines the name of the file as seen by LISTSERV users. That is, the command to retrieve the file will be GET MY.FILE. (2) This defines the name of the actual disk file where the contents of MY.FILE will be stored. Normally, you should specify the same as (1), or just an equal sign (LISTSERV will then substitute the name you provided for (1)). However, in some cases you may want to make a particular file available under multiple names. This can be done by registering multiple files (ie multiple values for (1)), and using the same (2) value every time. (3) This file access code determines who can order the file through a GET command. See section 8.4.1, above, for more information on FAC codes. (4) This file access code determines who can update the file with the PUT command. See section 8.4.1, above, for more information on FAC codes. Note: (2) defaults to the value of (1), and (3) and (4) default to the GET and PUT access codes of the sub-catalog itself, respectively. So, in most cases a sub-catalog entry will be as simple as: MY.FILE Additionally, comment lines (starting with an asterisk) or blank lines can be interspersed with file definitions. These comments will be echoed when the sub-catalog is indexed (see below), in sequence with the file definitions. For instance, your catalog could read:
* * Files for the XYZ sub-project * XYZ.AGENDA XYZ.BUDGET XYZ.PROPOSAL-1 XYZ.PROPOSAL-28.4.5. Indexing the sub-catalog
If MY.CATALOG is defined as:
MY.CATALOG /home/lists/xyz/my.catalog xxx JOE@XYZ.COMthen any user who matches the 'xxx' file access code is authorized to issue an INDEX MY command to get a formatted version of the catalog. For compatibility with older versions of LISTSERV, GET MY.FILELIST will produce the same results. If there is a mailing list called MY, a list of the archive files will be appended automatically.
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:
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.
* MYLIST $PACKAGE * Packing list for MYLIST PACKAGE * * You can make other comments here, such as * the contact email address. * * filename filetype filelist *==========================Following these comment lines, you insert lines for each of the files contained in the package. There are two ways to format entries in your $PACKAGE file:
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
filename.extension <optional_comments>for example,
MYLIST.$PACKAGE The packing list INTEREST.FILE Interest groups NETIQUET.FILE How to behave ANOTHER.FILE No comment
* Notebook= Yes,/usr/listserv/home/mylist-archive,Monthly,PublicNote that only the LISTSERV maintainer may change the location of Notebook archives (or change Notebook= No to Notebook= Yes). Anyone else attempting to PUT the list header after changing these values will result in the following message being sent in response:
Figure 8.3. This output will appear either if an attempt is made to change "Notebook= No" to "Notebook= Yes", or if an attempt is made to change the location where notebook archives are stored on the server, by anyone who is not a LISTSERV maintainer.
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.The last message in the archive is not followed by a separator line (in other words, the separator line is found at the beginning of each message, not at the end of each message). If you can reformat your non-LISTSERV archives this way then you can rename them using standard LISTSERV filenames: For monthly archives: listname.logyymm For weekly archives: listname.logyymmw For yearly archives: listname.logyy (where yy = 2 digit year, mm = 2 digit month, w = letter A-F denoting the week of the month), place them in the directory pointed to by the Notebook= keyword for the list, and LISTSERV will index them and make them available via the web archive interface and so on.5 Note that in order for the web archive interface to notice new notebook files you must either GET and PUT the list header or restart LISTSERV. If a list owner is planning to store archive files via the PUT method, the LISTSERV maintainer must first make dummy files with the same filenames in the list's notebook directory so that LISTSERV will not say that the file does not exist and reject the PUT operation. However please note that you should not make entries for the notebooks in listname.catalog (if one exists). LISTSERV makes its list of notebooks "on the fly" every time an INDEX command is issued for the list. If your old archives have lines at the beginning of each message like this:
From firstname.lastname@example.org Thu Feb 2 15:27:02 1995you should delete them; this is the message separator used by sendmail. LISTSERV does not use it and it may in fact cause problems with indexing if left in. 8.10.4. Deleting old notebook archives The LISTSERV maintainer may delete old notebook archives that are no longer needed in one of two ways:
PUT MYFILE.TEXT PW=XXXXXXXXby itself would delete the file MYFILE.TEXT.
>>> EXAMPLE1 This is the subject linePlease note carefully the following instructions for the form name and subject line:
|&DATE||Long-style date (04 Jan 1998)|
|&WEEKDAY||Three-letter day of the week, in English|
|&MYNAMES||The substitution you will use most of the time when you need to refer to LISTSERV. For Internet-only or BITNET-only servers, this will display LISTSERV's only e-mail address. For servers with both Internet and BITNET connectivity, it will say "LISTSERV@hostname (or LISTSERV@nodeid.BITNET)".|
|&MYSELF||LISTSERV's address, in the form LISTSERV@XYZ.EDU or, if no Internet hostname is available, LISTSERV@XYZVM1.BITNET.|
|&MYNODE||LISTSERV's BITNET nodeid, without the '.BITNET', or its Internet hostname if no NJE address is available.|
|&MYHOST||LISTSERV's Internet hostname or, if none is available, its NJE address (with '.BITNET').|
|&MBX(addr)||Looks up the specified address in LISTSERV's signup file and displays "name <addr>" if a name is available, or just the original address otherwise. This is typically used to give the name of the command originator or target, along with his e-mail address: &MBX(&WHOM) or &MBX(&INVOKER). Please note however that &WHOM and &INVOKER are not always available in every template.|
|&RELEASE||LISTSERVís release number (e.g., "1.8d").|
|&OSTYPE||The operating system under which LISTSERV is running, e.g., VM/VMS/unix/Windows.|
|&OSNAME||The full operating system name including the version number, e.g., "VM/ESA 1.2.3", "Windows NT 3.51", "Linux 2.0.27", "SunOS 5.4", etc.|
|&HARDWARE||The type of machine LISTSERV is running on, e.g., "Pentium (128M)".|
|&LISTNAME||Either the short or long name of the list based on the value of "List-Address=" and/or its system default. By default the long ("List-ID=") name is used if present.|
|&TITLE||Title of the list, or empty string.|
|&KWD(kwd)||Value of the specified keyword for the list. You do not need to specify the name of the list - it is implicit. You need not put quotes around the keyword names either, although quotes will be accepted if present. Optionally, you can specify a second numeric argument to extract just one of the terms of a list header keyword; for instance, if the list header contains "Notebook= Yes,L1,Monthly,Private", &KWD(NOTEBOOK,4) has the value "Private". A third argument, also optional, specifies the default value for the keyword in case it was not initialized. It is meant to be used for conditional formatting in the default templates and list owners should not worry about it.|
|&LITE||(1.8c and following) Has the value 1 when running the LISTSERV Lite product, and 0 otherwise. This variable can be used to write generic templates that account for the differences between the two products.|
|&ISODATE||(1.8c and following) Returns todayís date in ISO format, i.e., yyyy-mm-dd.|
|&DAYSEQ(n)||(1.8c and following) Used to create FAQ templates with rotating topics. May also be used to create bottom banners with rotating text (e.g., for lists with multiple commercial sponsors who get "ad space" in the banner on a rotating basis).|
|Traditional:||For more information, please send mail to &EMAIL or call &PHONE.|
|HTML:||For more information, please send mail to &EMAIL; or call &PHONE;.|
|.*||Comment: anything on this line is simply ignored. This is useful for recording changes to template files when there are multiple owners. Just add a comment line with the date and your initials every time you make a change, for the benefit of the other owners.|
|.FO OFF||Turns off formatting: one template line = one line in the final message. You can resume formatting with .FO ON.|
|.CE text||Centers the text you specify (just the text you typed on the same line as the .CE command). This can be useful to highlight the syntax of a command.|
|.RE OWNERS||Adds a 'Reply-To:' field pointing to the list owners in the header of the generated message. Use this command when you think users are likely to want to reply with a question. You can also use .RE POSTMASTER to direct replies to the LISTSERV administrator, if this is more appropriate.|
|.CC OFF||Removes all "cc:" message recipients, if any. You can also add message recipients by specifying a series of e-mail addresses after the .CC statement, as in .CC JOE@XYZ.EDU. PC mail users should note that in this context "cc:" is a RFC822 term that stands for "carbon copy". RFC822 messages may have "cc:" recipients in addition to their "primary" recipients. There is no real technical difference between the two, the "cc:" indicator just denotes a message that is being sent for your information. Some administrative messages sent to list owners are copied to the user for their information, and vice-versa; this behavior can be disabled by adding a .CC OFF statement to the template.|
|.TO||Replaces the default recipients of a message with the value specified. For instance, if you use the ADDREQ1 template form to send new subscribers a questionnaire, application form or similar material, you will need to add a '.TO &WHOM' instruction to your modified template form, as by default the user will not receive a copy.|
|Cancels the message. LISTSERV stops reading the template form and does not send anything. This is useful if you want to completely remove a particular message; note however that this can be confusing with certain commands, as LISTSERV may say "Notification is being sent to the list owners" when in fact nothing will be sent because of the .QQ command in the template form.|
|.IM name||Imbeds (inserts) another template form at this point in the message. This is used to avoid duplicating large pieces of text which are mostly identical, such as the templates for "you have been added to list X by Y" and "your subscription to list X has been accepted". As noted below, LISTSERV will not pick up an "imbedded" template form from $SITE$.MAILTPL. If you wish to include an "imbedded" template form (e.g., $SIGNUP) in $SITE$.MAILTPL, you must also include the template form that calls it with the .im command.|
|.DD ddname||Copies the contents of the specified DD into the message. This is meaningful only if a DD has been set up by LISTSERV for this purpose. As a rule of thumb, you should either leave these statements unchanged or remove them.|
|.BB cond||Begin conditional block. The boolean expression following the keyword is evaluated and, if false, all the text between the .BB and .EB delimiters is skipped. Conditional blocks nest to an arbitrary depth. The expression evaluator is recursive but not very sophisticated; the restriction you are most likely to encounter is that all sub-expressions have to be enclosed in parentheses if you are using boolean operators. That is, ".BB &X = 3" is valid but ".BB &X = 3 and &Y = 4" is not. String literals do not require quoting unless they contain blanks, but quotes are accepted if supplied. Comparison operators are = <> ^= IN and NOT IN (the last two look for a word in a blank-separated list of options, such as a keyword value). These operators are not case-sensitive; == and ^== are available when case must be respected. Boolean operators are AND and OR. Note that a conditional block must be contained on one physical line and may not wrap, so be careful when sending MAILTPL files back to LISTSERV that you do not accidentally wrap long .BB lines. Starting with LISTSERV 1.8d the operators =* and ^=* are available to perform wildcard matches in conditional blocks. For instance JOHN_DOE@UNIX.EXAMPLE.COM =* J*DOE@*EXAMPLE.COM is a true statement. The wildcard specification is on the right-hand side whereas the actual text (or variable) you are evaluating is on the left.|
|.EB||End conditional block (see .BB).|
|.SE var text||Defines or redefines a substitution variable. This is convenient for storing temporary (text) expression results which need to be used several times. Even standard variables such as &LISTNAME can be redefined - at your own risk. You must enclose the text expression in single quotes if you want leading or trailing blanks.|
|.CS text||Define a (non standard) character set for the template in question, i.e., .CS ISO-8559-7 This setting is ignored if the template does not actually contain special characters (for instance, if the template is written in 7-bit ASCII). Otherwise the appropriate headers are created for the message in question when it is sent out.|
|.TY text||Types one line of text on the LISTSERV console log. This can be useful to the LISTSERV maintainer for debugging, and also to record information in the console log.|
Tells LISTSERV to leave the text immediately following the
.ASIS directive alone, ie, don't convert "<" and ">" characters
into HTML < and > when creating pages. This is
specifically for use in HTML templates where it is important
not to convert parts of a URL reference. For instance,
.ASIS Click <a href="http://some.host.com/some-doc.html">here</a>.As with the .CE directive, the text you intend to affect with the .ASIS directive must not wrap. The .ASIS directive will only work on text it finds on the same physical line into which it is coded.
Figure 9.1. The default contents of the INFO template form of DEFAULT.MAILTPL.
>>> 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 .QQNote that L-Soft does not generally recommend suppressing this message, as it may indicate a serious problem for the deleted subscriber. ADD1: the message sent when a list owner or a LISTSERV maintainer manually adds a subscriber to a list. ADD2: the message sent to the list owner(s) when someone subscribes to their list. As with SIGNOFF1, whether or not the list owner(s) receive this message is controlled by the "Notify=" list header keyword. ADDREQ1: this message is sent to the list owner when a user requests to join a list with "Subscription= By owner". Only the list owner is sent a copy of the ADDREQ1 message. If you use this template form to send new subscribers a questionnaire, application form or similar material, you will need to add a '.TO &WHOMĎ instruction to your modified template form, as by default the user does not receive a copy. SETINFO: the message sent to the subscriber when the list owner or LISTSERV maintainer changes their personal subscription options. Can be suppressed by the invoker with the use of the "QUIET" command modifier. CHANGE1: the message sent when a list owner or LISTSERV maintainer uses the CHANGE command to change a subcriber's address. ADDMOD2: the message sent to the subscriber when the list owner or LISTSERV maintainer changes the subscriber's "real name" field in the SIGNUP database. ADDPW1: the message sent to the user when a LISTSERV maintainer adds a personal password for that user. ADDPW2: an informational message sent to the LISTSERV maintainer when a user adds or changes his password, but only if an LSV$PW exit has been enabled to do so. Most installations will never use this template form, but it should not be deleted from DEFAULT.MAILTPL in any case. ADDPW3: an information message sent to the LISTSERV maintainer when a user tries to add or change his password, but only if an LSV$PW exit has been enabled to do so. Most installations will never use this template form, but it should not be deleted from DEFAULT.MAILTPL in any case. DELPW: the message sent to the user when a LISTSERV maintainer deletes that user's personal password. RENEW1: this message is sent to subscribers whose subscriptions are due for renewal (see the Renewal= list header keyword for more information). RENEW2: this message is sent to subscribers who did not renew their subscriptions within the grace period after being notified that their subscription was due for renewal. SIGNUP1: the basic "Your subscription request has been accepted" message. $SIGNUP: a template form included with SIGNUP1 and ADD1 (assuming that SIGNUP1 and ADD1 template forms include an ".im $SIGNUP" line, which by default they do) which gives the subscriber a basic outline of how to use the list, how various options are set, and where to get more information on using LISTSERV. This template can be used in lieu of a WELCOME file for a list if the list owner doesnít want two messages to go to the user at subscription time. SUB_CLOSED (linear): this is the message that is sent to a subscriber attempting to join a list with "Subscription= Closed". The default is "Sorry, the &LISTNAME list is closed. Contact the list owner (&OWNER) for more information." SUB_NEWNAME (linear): this message is sent to a current list subscriber who has issued a new SUB command in order to change his "real name" field in the SIGNUP files. SUB_OWNER (linear): this message is sent to a subscriber attempting to join a list with "Subscription= By owner". The default is "Your request to join the &LISTNAME list has been forwarded to the list owner for approval. If you have any question about the list, you can reach the list owner at &OWNER." Because this is a linear template form (see above), it is not the best place to put long questionnaires, application forms, terms and conditions, or other material that the subscriber should be required to review prior to joining the list. See the "Tips" section below. POST_EDITOR (linear): this is the message LISTSERV sends to people attempting to post to the list, if it is moderated. The default is "Your &MESSAGE has been submitted to the moderator of the &LISTNAME list: &MBX(&MODERATOR)." REQACK1: this message is sent automatically in reply to any message sent to the xxx-request address. The message acknowledges receipt, explains the difference between the LISTSERV and xxx-request addresses, and contains instructions for joining and leaving the list. To suppress this message for your list, simply redefine it in the 'listname.MAILTPL' and use the .QQ instruction:
>>> REQACK1 This message is not wanted for our list .QQCONFIRM1: The message sent whenever an "OK" confirmation is required. WWW_INDEX: this template form is used by sites which have implemented LISTSERVís WWW archive interface. It includes the HTML code for the main archive access screen for the list. List owners should probably should leave this alone unless they know exactly what they are doing. WWW_REBUILD_ALL: This template is used internally by LISTSERV and should NEVER be edited by end users. PROBE1: this template form is sent as part of LISTSERV's new bounce processing feature if this feature is activated for your list. The desired response from the user is to discard the message and do nothing. See chapter 4.6.2 of the List Ownerís Manual or chapter 13.5 of the Site Manager's Operations Manual for details on the "Probe" option. PROBE2: If the mail containing the PROBE1 message bounces, this template form is sent along with a copy of the bouncing mail. See chapter 4.6.2 of the List Ownerís Manual or chapter 13.5 of the Site Manager's Operations Manual for details on the "Probe" option. (If you have Auto-Delete= ...,Delay(0), PROBE2 is not sent, rather the bouncing user is deleted immediately.) Several template forms for the WWW archive interface follow PROBE1. For more information on these template forms, see section 9.7, below. HTML_DIGEST: Preamble for HTML digests (for users who have set the personal subscription option HTML ) HTML_INDEX: Preamble for HTML indexes (for users who have set the personal subscription option HTML ) BAD_ATTACHMENT (linear): If a posting to a list contains an attachment of a type not allowed by the "Attachments=" setting for the list, this template form is sent back to the poster. The following are template forms that can be defined, but which are not present in DEFAULT.MAILTPL. POSTACK1 (optional): when present, this message is sent in reply to any message posted to the list. This is very useful for creating "infobots", or just for returning a standard acknowledgement to contributors. The &SUBJECT variable contains the subject of the original message, and naturally the usual substitutions (&LISTNAME, &DATE, &TIME) are available. TOP_BANNER, BOTTOM_BANNER (optional): when these template forms are present, their contents are automatically inserted at the top (respectively bottom) of each and every message posted to the list. Typically, the top banner would be used for a copyright or short legal warning which absolutely has to be seen by each and every reader. The bottom banner could contain instructions for signing off the list, a disclaimer, an acknowledgement of a sponsor's contribution, a "tip of the week", etc.
Figure 9.3. Typical contents of a DIGEST-H or INDEX-H file.
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.
>>> LANGUAGE idiomwhere idiom is, of course, the same value we've been talking about above. For instance for a FRANCAIS idiom you'd use
>>> LANGUAGE FRANCAISSee also 9.3.1, above, regarding the use of 8-bit characters in template forms. 9.7.6. Template precedence For template forms found in DEFAULT MAILTPL, the following precedence is used when LISTSERV searches for a given template form:
listname MAILTPL idiom MAILTPL WWW_ARCHIVE MAILTPL8 DEFAULT MAILTPLThat is to say, if LISTSERV needs a copy of the ADD1 mail template form, it will look first in the listname.mailtpl file for the list in question. If no such file exists, or if ADD1 is not present in listname.mailtpl, LISTSERV will look in idiom.MAILTPL (if Language= or DEFAULT_LANGUAGE= is set to idiom). Again, if the ADD1 form is not present in idiom.mailtpl, or if idiom.mailtpl does not exist, LISTSERV will then look in default.mailtpl (www_archive.mailtpl is skipped because ADD1 is not a web template form) and pull out the default ADD1 template form. For template forms found in DEFAULT WWWTPL the precedence is:
listname WWWTPL idiom WWWTPL SITE WWWTPL DEFAULT WWWTPLThe same sequence of events applies as for the MAILTPL files, except that SITE WWWTPL is never skipped (all template forms in the WWWTPL files are web forms).
9.8. Using the DAYSEQ(n) functionThe DAYSEQ(n) function is quite powerful. This function allows the list owner to code template forms (such as the PROBE1 or BOTTOM_BANNER messages) that change or "rotate" automatically. The DAYSEQ(n) function is invoked in a .BB - .EB conditional block, and n corresponds to the number of days in the rotation period, i.e., to the number of variations that you want to make to the text of the message. &DAYSEQ(n) returns a number from 1 to n which increases by 1 every day, with no special regard for weekends. That is, if the rotation period is to last for a week, you code DAYSEQ(7). If the rotation period is 15 days, you code DAYSEQ(15). Two examples follow: 9.8.1. Rotating bottom banner To create a rotating bottom banner, follow this example. A list has three commercial sponsors, each of whom are provided with an advertisement every three days. (Note that this doesnít take weekends into account; in this example, if company A is featured in the banner on Monday, it will be featured again on Thursday and then again on Sunday. However, in the following week it will be featured on Wednesday, Saturday, and Tuesday, so it will actually get rather good coverage.) Our BOTTOM_BANNER template form would look like this:
>>> BOTTOM_BANNER .BB &DAYSEQ(3) = 1 Todayís copy of the &LISTNAME newsletter has been brought to you by Company A. .EB .BB &DAYSEQ(3) = 2 Todayís copy of the &LISTNAME newsletter has been brought to you by Company B. .EB .BB &DAYSEQ(3) = 3 Todayís copy of the &LISTNAME newsletter has been brought to you by Company C. .EB(Naturally you can feel free to be more florid with your prose :) If a company needs to get a higher percentage of "air" time than another, you can simply assign it more than one of the possible n values of &DAYSEQ(n). For instance, if you have two companies but one should get twice as many days of "air" time, you might code something like this:
>>> BOTTOM_BANNER .BB (&DAYSEQ(3) = 1) OR (&DAYSEQ(3) = 3) Todayís copy of the &LISTNAME newsletter has been brought to you by Company A. .EB .BB &DAYSEQ(3) = 2 Todayís copy of the &LISTNAME newsletter has been brought to you by Company B. .EBThis would cause Company Aís message to appear on days 1 and 3 of the rotation period and Company Bís message to appear on day 2 only. 9.8.2. Rotating FAQ via the PROBE1 template and "Renewal= xx-Daily" Subscription renewal can be coded with daily granularity (however, please note that it is and remains inadvisable to use renewal intervals of less than a week). If you further code subscription probing into the "Renewal=" keyword with the ",Probe" parameter, you open up the possibility of turning the standard PROBE1 template form into a periodic FAQ. Hereís how: Weíll assume to start that you will code "Renewal= 15-Daily,Probe" in your list header. (You can experiment with other numbers, but since we have two messages and will be using &DAYSEQ(2), we need an odd renewal period.) Weíll also assume that you want to send two versions of your FAQ each month; the first, a complete FAQ document, and the second, an abbreviated "reminder" version that just contains information about how to sign off, how to post to the list, and so forth. The basic algorithm is therefore: When &DAYSEQ(2) = 1, send the full FAQ.
>>> PROBE1 Periodic FAQ posting for &LISTNAME &WEEKDAY, &DATE &TIME .BB &DAYSEQ(2) = 1 This is the complete FAQ for &LISTNAME. Please read it and keep a copy for future reference. A FAQ document for &LISTNAME is distributed every 15 days, the full FAQ alternating with a shorter "reminder" FAQ. <body of the full FAQ document> .EB .BB &DAYSEQ(2) = 2 This is the abbreviated FAQ for &LISTNAME. Please read it and keep a copy for future reference. A FAQ document for &LISTNAME is distributed every 15 days, the full FAQ alternating with a shorter "reminder" FAQ. <body of the abbreviated FAQ document> .EB9.8.3. Calculating the value for DAYSEQ() When you first start using a rotating banner with the &DAYSEQ variable, the &DAYSEQ(n)= 1 period begins based on the number of days elapsed since a baseline. On VM (and in REXX generally) you can calculate today's value easily with:
/* */ say Date('B') + 1If you do not have access to a REXX interpreter, Date('B') is described as "the number of complete days (that is, not including the current day) since and including the base date, 1 Jan 0001, in the format 'dddddd' (no leading zeros or blanks)."
For example, for Friday 21 May 1999, the value of Date('B') is 729895. This value increases by one every day at midnight.
/XYZ <options> (One line description of /XYZ)and the output of HELP would then be
> help LISTSERV(R) version 1.8d - most commonly used commands Info <topic|listname> Order documentation Lists <Detail|Short|Global> Get a description of all lists SUBscribe listname <full name> Subscribe to a list SIGNOFF listname Sign off from a list SIGNOFF * (NETWIDE - from all lists on all servers REView listname <options> Review a list Query listname Query your subscription options SET listname options Update your subscription options INDex <filelist_name> Order a list of LISTSERV files GET filename filetype Order a file from LISTSERV REGister full_name|OFF Tell LISTSERV about your name There are more commands (AFD, FUI, PW, etc). Send an INFO REFCARD for a comprehensive reference card, or just INFO for a list of available documentation files. The following local commands are available at this installation: /XYZ <options> (One line description of /XYZ) This server is managed by: LSTMAINT@LISTSERV.EXAMPLE.COMFor most sites, however, locally-added commands probably won't be available. If you use the LOCALCMD HELPFILE functionality at all, it will likely be to enhance the output in order to make it more understandable for users. So you probably would not want to see the line "The following local commands are available at this installation:" followed by text that doesn't document commands. You can turn off this line by simply adding .NH as the first line of LOCALCMD HELPFILE. Note that .NH is the only formatting command available in LOCALCMD HELPFILE; it is otherwise a flat ASCII file that outputs exactly as you type it. Let's say that you are having a problem where the LISTSERV postmasters are fielding a lot of questions that really ought to be sent to list owners (get me off this list, my address changed, etc.) and a little investigation indicates that these people are getting the postmaster address from the HELP command. It's not reasonable to remove the postmaster's address from the output since it should always be possible to find out who is running the server (in case loops develop, etc.), but you could create a LOCALCMD HELPFILE like the following to indicate to users where various kinds of questions should be sent:
.NH For help with a specific list, please write to the list owner(s) at the generic list owner's address. This address takes the form listname-REQUEST@LISTSERV.EXAMPLE.COM For instance, if you are subscribed to a list called DOGLIST-L, to contact the list owners you would write to DOGLIST-L-REQUEST@LISTSERV.EXAMPLE.COM PLEASE DO NOT ACTUALLY WRITE TO DOGLIST-L-REQUEST. This is just an example, you must substitute the name of the mailing list in question. There is no DOGLIST-L mailing list on this server and mail sent to DOGLIST-L-REQUEST is discarded unread. Please do not write to the server manager unless you do not get a response from the list owner. Thank you!
This feature is not available in LISTSERV Lite.In some cases, it may be necessary for the LISTSERV maintainer to ensure that all subscribers receive certain information or warnings (typically legal notices required by government regulations) when they leave or join a list. The list owner should not be able to disable these warnings, accidentally or otherwise. The $SITE$.MAILTPL file provides this functionality. However please note that this functionality should be used only if you have a specific need for it as it will increase the number of administrative messages received by users and may cause confusion. If a $SITE$.MAILTPL file is present in LISTSERV's main directory (the one with DEFAULT.MAILTPL), LISTSERV will look it up every time it needs to deliver an administrative message. If the message is not found in the site template, LISTSERV will process the request normally, looking up the list template file, then the language template file and finally the system template file. If the message is listed in the site template, LISTSERV will deliver both the copy in the site template and the copy in the list/language/system template. Note that L-Soft does not ship a $SITE$.MAILTPL file in the LISTSERV distributions. If needed, you must create this template file yourself. $SITE$.MAILTPL will not be overwritten during an upgrade. Also note that LISTSERV will not pick up an "imbedded" template from $SITE$.MAILTPL. If you wish to include an "imbedded" template (e.g., $SIGNUP) in $SITE$.MAILTPL, you must also include the template(s) that calls it with the .im command. For instance, if you include $SIGNUP in $SITE$.MAILTPL, by default you would need to include the SIGNUP1 and ADD1 templates in $SITE$.MAILTPL as well if you expected $SIGNUP to be sent from $SITE$.MAILTPL. Web templates from DEFAULT MAILTPL must be placed in WWW_ARCHIVE MAILTPL if you wish to override the defaults. The web interface ignores $SITE$ MAILTPL .
10.1. Logs kept by LISTSERVLISTSERV keeps logs of all of its activity. On VM systems, this information is kept in the LISTSERV console log. On unix systems, it is kept in $LSVROOT/listserv.log by default. Note that unix systems create the log by redirection of standard output to a file; see the 'go' script if you are interested in this process. On VMS and Windows systems, there may be several different logs depending on the configuration of the system. For instance, in addition to the LISTSERV log itself, there will be logs for the SMTP "workers" if this feature is enabled. On Windows systems, there will also be a log for the SMTP "listener" if it is in service. (Windows systems running L-Soft's LSMTP product will not use the SMTP "listener" service, and thus will not keep logs for it.) By default, logs under VMS are kept in LISTSERV_ROOT:[LOG] and logs under NT are kept in \LISTSERV\LOG .
Figure 10.1. Sample CLEANLOG.REXX script for managing LISTSERV's log files. This particular script runs under Regina REXX on Windows NT or 95.
/**/ logdir = 'E:\LISTSERV\LOG' tempfile = logdir'\CLEANLOG.TMP' keep = 5 /* First zip all the logs, except today's */ 'DIR/B' logdir'\*.LOG >' tempfile If rc ^== 0 Then Exit today = Date('S') Do forever line = Translate(Linein(tempfile)) If line == '' Then Leave Parse var line '-'date'.' If date = today Then Iterate Parse var line fn'.' Say 'ZIPping' line'...' 'ZIP -j -m -q' logdir'\'fn logdir'\'line End Call Lineout tempfile /* Now delete ZIP files older than 'keep' days */ 'DIR/B/O-N' logdir'\*.ZIP >' tempfile If rc ^== 0 Then Exit n. = 0 Do forever line = Translate(Linein(tempfile)) If line == '' Then Leave Parse upper var line pfx'-'date'.' n.pfx = n.pfx + 1 If n.pfx <= keep Then Iterate Say 'Deleting' line'...' 'DEL' logdir'\'line End Call Lineout tempfile 'DEL' tempfile
25 May 1996 00:00:00 Expiring cookie from xxxxx@ICOM.CA: > SIGNOFF TECHLINK 25 May 1996 00:00:00 Sent information mail to xxxxx@ICOM.CA 25 May 1996 00:00:00 Expiring cookie from xxxxxxxx@LIGHTSIDE.COM: > SUBSCRIBE WINNT-L Sxxxx Bxxxxx 25 May 1996 00:00:00 Sent information mail to xxxxxxxx@LIGHTSIDE.COMThese entries refer to expiring "OK" confirmation cookies. 10.3.2. Releasing and reallocating a disk slot
25 May 1996 00:00:00 Virtual disk slot E(E:\LISTSERV\ARCHIVES\NISTEP-L) released . 25 May 1996 00:00:00 Directory E:\EASE\PEACH\LISTS\IATN accessed as virtual disk slot E.LISTSERV uses "disk slots" in rotation to minimize the overhead involved in opening a file, performing an operation, closing the file, and then possibly having to reopen the file immediately to perform another operation. A given "disk slot" stays open until it is needed for another file. 10.3.3. Reindexing a list
25 May 1996 00:00:01 Reindexing IATN LOG9605D...LISTSERV rebuilds the index for the current notebook archive file of a given list immediately prior to sending the DIGEST and INDEX versions of the list. 10.3.4. Distributing a digest Here is a typical log sequence for the distribution of a daily digest:
25 May 1996 00:00:35 Virtual disk slot E(E:\LISTSERV\ARCHIVES\HONYAKU) released. 25 May 1996 00:00:35 Directory E:\LISTSERV\ARCHIVES\SPAM-L accessed as virtual d isk slot E. 25 May 1996 00:00:37 Reindexing SPAM-L LOG9605... 25 May 1996 00:00:37 SPAM-L digest is being distributed... 25 May 1996 00:00:37 Distributing mail ("SPAM-L") from owner-SPAM-L@PEACH.EASE.L SOFT.COM... 25 May 1996 00:00:38 Mail forwarded to H-NET.MSU.EDU for 2 recipients. 25 May 1996 00:00:38 Mail forwarded to UAFSYSB.UARK.EDU for 2 recipients. 25 May 1996 00:00:38 Mail forwarded to LISTMAIL.SUNET.SE for 2 recipients.The preceding 3 jobs were forwarded to LISTSERV servers on the DISTRIBUTE backbone. The following mail is posted to 45 users who are not served by the DISTRIBUTE backbone in a single BSMTP "envelope".
25 May 1996 00:00:38 Mail posted via SMTP to xxx@AMERICAN.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@AOL.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@AOL.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@BCVMS.BC.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@BMACADM.BITNET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@CLEMSON.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxxxxx@COMPUSERVE.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@EMAIL.GC.CUNY.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@ERE.UMONTREAL.CA. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@ETERNA.COM.AU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@GOL.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@GPU.SRV.UALBERTA.CA. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@HAWAII.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@IBM.NET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@IDIR.NET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@INET.UNI-C.DK. 25 May 1996 00:00:38 Mail posted via SMTP to xxx@KSUVM.KSU.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxx@LOC.GOV. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@LOONY-TOONS.TAMU.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@LTRR.ARIZONA.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@MAILBOX.SYR.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@MO.NET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxx@MUSICA.MCGILL.CA. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@NANDO.NET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@NETCOM.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@NYIQ.NET. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@PAMELA.INT.MED.UNIPI.IT. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@PIONEER.STATE.ND.US. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@PSC.LSA.UMICH.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxx@PSUVM.PSU.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@PUCC.PRINCETON.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@SCS.UNR.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@SILVERPLATTER.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@SJUVM.STJOHNS.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@SPCVXA.SPC.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@TELERAMA.LM.COM. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@UA1VM.UA.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@UABDPO.DPO.UAB.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxxx@UCONNVM.UCONN.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@UTARLVM1.UTA.EDU. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@UVVM.UVIC.CA. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxxx@VM1.HQADMIN.DOE.GOV. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxx@VM1.MCGILL.CA. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@VM3090.EGE.EDU.TR. 25 May 1996 00:00:38 Mail posted via SMTP to xxxxxx@WATSON.IBM.COM.LISTSERV always summarizes and tells you what it's done:
25 May 1996 00:00:38 Done - 3 jobs (6 rcpts), 1 outbound file (45 rcpts).10.3.5. Daily error monitoring reports
25 May 1996 00:00:43 Generating daily nondelivery monitoring reports...Here LISTSERV deletes a subscriber who has gone over the Auto-Delete= limits:
25 May 1996 00:00:44 -> Deleted xxxxxxxx@CARIARI.UCR.AC.CR from ACCESS-L.LISTSERV now sends out the daily error monitoring reports to the appropriate people (defined in "Errors-To=" for each list).
As LISTSERV continues to run and process errors for the various lists, it will update the listname.AUTODEL file whenever it receives an error that it understands:
25 May 1996 00:00:44 Sent information mail to xxxxxxxx@CARIARI.UCR.AC.CR 25 May 1996 00:00:45 Sent information mail to xxxxxx@LINUS.DC.LSOFT.COM 25 May 1996 00:00:46 Sent information mail to xxxxx@AF.PENTAGON.MIL 25 May 1996 00:00:46 Sent information mail to xxxxx@ESA.MHS.COMPUSERVE.COM
10.3.6. Processing mail for local lists
25 May 1996 00:05:43 Automatic nondelivery report processing for WIN95-L: 25 May 1996 00:05:43 -> All errors temporary, no action taken. 25 May 1996 00:07:34 Automatic nondelivery report processing for EXCEL-G: 25 May 1996 00:07:34 -> 1 monitoring entry updated.
25 May 1996 00:39:23 Processing file 8209289 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:39:25 Processing mail from xxxxxx@PRIMENET.COM for ACCESS-L 25 May 1996 00:39:25 Virtual disk slot E(E:\EASE\PEACH\FTP\EXCEL-L) released. 25 May 1996 00:39:25 Directory E:\EASE\PEACH\FTP\ACCESS-L accessed as virtual di sk slot E. 25 May 1996 00:39:26 Distributing mail ("ACCESS-L") from owner-access-l@PEACH.EA SE.LSOFT.COM... 25 May 1996 00:39:26 Mail posted via SMTP to xxxxxxxxxxxxxx@NR-COMMS.RADIO.BBC.C O.UK. 25 May 1996 00:39:26 Mail posted via SMTP to xxxxxxxx@OHS.ORG. 25 May 1996 00:39:26 Mail posted via SMTP to xxxxx@POBOX.COM. 25 May 1996 00:39:26 Done - 1 outbound file (3 rcpts). 25 May 1996 00:39:26 Distributing mail ("ACCESS-L") from owner-access-l@PEACH.EA SE.LSOFT.COM... 25 May 1996 00:39:26 Mail forwarded to LISTSERV@HEARN for 4 recipients. 25 May 1996 00:39:27 Mail forwarded to LISTMAIL.SUNET.SE for 11 recipients. 25 May 1996 00:39:27 Mail forwarded to LISTSERV@ICINECA for 4 recipients. 25 May 1996 00:39:27 Mail forwarded to LISTSERV.GMD.DE for 3 recipients. 25 May 1996 00:39:27 Mail forwarded to LISTSERV@AEARN for 2 recipients. 25 May 1996 00:39:27 Processed 192 recipients... 25 May 1996 00:39:27 Done - 5 jobs (24 rcpts), 1 outbound file (192 rcpts). 25 May 1996 00:39:27 Distributing mail ("ACCESS-L") from owner-access-l@PEACH.EA SE.LSOFT.COM... 25 May 1996 00:39:27 Mail posted via SMTP to xxxxx@ADC.COM. 25 May 1996 00:39:27 Mail posted via SMTP to xxxxxxx@MSMEL.PRAXA.COM.AU. 25 May 1996 00:39:27 Mail posted via SMTP to xxxxxxx@SPRYNET.COM. 25 May 1996 00:39:27 Done - 1 outbound file (3 rcpts). 25 May 1996 00:39:27 Message DISTRIBUTEd to 222 recipients. 25 May 1996 00:39:28 Sent information mail to xxxxxx@PRIMENET.COM10.3.7. Administrative mail (X-ADMMAIL) This particular type of mail, sent to the OWNER-listname address, is a delivery error being returned to the RFC 821 MAIL FROM: address.
10.3.8. DISTRIBUTE jobs from remote hosts Just as our LISTSERV sends out DISTRIBUTE jobs to the backbone, it also receives them for distribution from remote backbone hosts.
25 May 1996 00:01:16 From MAILER@PEACH.EASE.LSOFT.COM: X-ADMMAIL OWNER-AFNS 25 May 1996 00:01:16 Processing file 8206153 from MAILER@PEACH.EASE.LSOFT.COM
25 May 1996 00:01:16 Processing file 8206155 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:01:16 From LISTSERV@PSUVM.PSU.EDU: X-B64 ID=PAN-L.MAILDIST CLASS= A 25 May 1996 00:01:16 Rescheduled as: 8206156 25 May 1996 00:01:16 Processing file 8206156 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:01:16 From LISTSERV@PSUVM: DIST2 MAIL I=Y FROM=owner-pan-l@BINGVM B.CC.BINGHAMTON.EDU FORW(CRC) HOST(626 626 (...) 25 May 1996 00:01:17 Distributing mail ("PAN-L") from owner-pan-l@BINGVMB.CC.BIN GHAMTON.EDU... 25 May 1996 00:01:17 Mail posted via SMTP to xxxxxxxx@ACS.RYERSON.CA. 25 May 1996 00:01:17 Mail posted via SMTP to xxxxx@AMAIL.AMDAHL.COM. 25 May 1996 00:01:17 Mail posted via SMTP to xxxxxxx@AOL.COM.and so forth. 10.3.9. Requesting "OK" confirmation for commands
25 May 1996 00:01:17 Processing file 8206160 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:01:17 From xxxxxxx@AUSCONSULT.COM.AU: UNSUB EXCEL-L 25 May 1996 00:01:17 Requesting confirmation, cookie=3EB4F2 25 May 1996 00:01:17 Sent information mail to xxxxxxx@AUSCONSULT.COM.AU10.3.10. Subscription summary updates (SUPD jobs) X-SUPD jobs update the file used by "LIST SUMMARY". LISTSERV receives the file from another LISTSERV host and distributes it down the line:
25 May 1996 00:04:54 Processing file 8206401 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:54 From LISTSERV@INTERNET.COM: X-B64 ID=X-SUPD.JOB ASCII CLASS =J 25 May 1996 00:04:54 Rescheduled as: 8206402 25 May 1996 00:04:54 Processing file 8206402 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:54 From LISTSERV@INTERNET.COM: DIST2 I=Y FROM=LISTSERV@INTERNE T.COM FORW(CRC) HOST(626 626 626 626 626 691 686 (...) 25 May 1996 00:04:54 Distributing file "X-SUPD JOB" from LISTSERV@INTERNET.COM.. . 25 May 1996 00:04:54 File forwarded to LIME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:54 File forwarded to WIN95.DC.LSOFT.COM for 1 recipient. 25 May 1996 00:04:54 File forwarded to SPIDER.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:54 File forwarded to HOME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:54 File forwarded to LISTSERV.GEORGETOWN.EDU for 1 recipient . 25 May 1996 00:04:54 File forwarded to CC1.KULEUVEN.AC.BE for 1 recipient. 25 May 1996 00:04:54 File forwarded to LISTSERV.USHMM.ORG for 1 recipient. 25 May 1996 00:04:54 File forwarded to LISTSERV.CLARK.NET for 1 recipient. 25 May 1996 00:04:54 File "X-SUPD JOB" distributed to LISTSERV@PEACH.EASE.LSOFT. COM. 25 May 1996 00:04:54 Done - 8 jobs (8 rcpts), 1 outbound file (1 rcpt). 25 May 1996 00:04:54 Processing file 8206411 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:54 From LISTSERV@INTERNET.COM: X-SUPD FWD=NO DATE=1996052500:0 0:04 DATA=5 56 PHOTOPRO 465 PHOTOTECH 268 PHOTOAS (...)10.3.11. Global list of lists updates (LUPD jobs) X-LUPD jobs update the list of lists. LISTSERV receives the file from another LISTSERV host and distributes it down the line:
25 May 1996 00:04:08 Processing file 8206361 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:08 From LISTSERV@LISTSERV.UIC.EDU: X-B64 ID=X-LUPD.JOB ASCII C LASS=J 25 May 1996 00:04:08 Rescheduled as: 8206362 25 May 1996 00:04:08 Processing file 8206362 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:08 From LISTSERV@LISTSERV.UIC.EDU: DIST2 I=Y FROM=LISTSERV@LIS TSERV.UIC.EDU FORW(CRC) HOST(626 626 626 626 626 691 (...) 25 May 1996 00:04:08 Distributing file "X-LUPD JOB" from LISTSERV@LISTSERV.UIC.E DU... 25 May 1996 00:04:08 File forwarded to LIME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:08 File forwarded to WIN95.DC.LSOFT.COM for 1 recipient. 25 May 1996 00:04:08 File forwarded to SPIDER.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:08 File forwarded to HOME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 00:04:08 File forwarded to LISTSERV.GEORGETOWN.EDU for 1 recipient . 25 May 1996 00:04:08 File forwarded to CC1.KULEUVEN.AC.BE for 1 recipient. 25 May 1996 00:04:08 File forwarded to LISTSERV.USHMM.ORG for 1 recipient. 25 May 1996 00:04:08 File forwarded to LISTSERV.CLARK.NET for 1 recipient.LISTSERV also sends itself a copy:
25 May 1996 00:04:08 File "X-LUPD JOB" distributed to LISTSERV@PEACH.EASE.LSOFT. COM. 25 May 1996 00:04:08 Done - 8 jobs (8 rcpts), 1 outbound file (1 rcpt). 25 May 1996 00:04:08 Processing file 8206371 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:08 From LISTSERV@LISTSERV.UIC.EDU: X-LUPD FWD=NO DATE=19960524The following entry tells LISTSERV to replace the information it has for NEWIO-L in its global list of lists:
> REP NEWIO-L NEWIO-L /Info about replacing ILLINET Online hardware and software /2616677089 > CKS 3881006631 25 May 1996 00:04:10 GLOBLIST FILE has been successfully updated.Note that entries for deleted lists also are updated (deleted from GLOBLIST FILE):
25 May 1996 00:24:11 Processing file 8207550 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:24:11 From LISTSERV@VM1.NODAK.EDU: X-LUPD FWD=NO DATE=1996052423: 00:04 HDR=YES > DEL WLREHAB > DEL WDAMAGE > DEL POWER-L > DEL QUEST > DEL RS1-L > DEL SANGEET > DEL SPRINT-L > DEL STAFFGOV > DEL TAG-L > DEL TELUGU > DEL THEORY-A > DEL THEORY-B > DEL THEORY-C > DEL THEORYNT > DEL TOW > DEL TWSGIS-L > DEL UND-SEMI > CKS 3794276653 25 May 1996 00:24:13 GLOBLIST FILE has been successfully updated.Note that if the "CKS" checksum does not check out, the job is discarded without being processed. 10.3.12. Valid "OK" confirmation received Here is a set of typical log entries for the receipt of a valid "OK" confirmation. Notice that LISTSERV accepts the OK and then issues itself the command that required confirmation. Other than the "OK", this behavior (at least in the log) is identical to how LISTSERV handles commands that do not require confirmation.
225 May 1996 00:04:58 Processing file 8206418 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:04:58 From xxxxxxxxx@SOL.KISS.DE: OK 25 May 1996 00:04:58 From xxxxxxxxx@SOL.KISS.DE: SIGNOFF AFWEEKLY 25 May 1996 00:04:58 To xxxxxxxxx@SOL.KISS.DE: You have been removed from the AFWEEKLY list. 25 May 1996 00:04:58 Sending FAREWELL message to xxxxxxxxx@SOL.KISS.DE 25 May 1996 00:04:58 Sent information mail to xxxxxxxxx@SOL.KISS.DE 25 May 1996 00:04:58 Sent information mail to: > xxxxxxx@AFSYNC.HQ.AF.MIL xxxxxxx@AFSYNC.HQ.AF.MIL > xxxxx@AFNEWS.PA.AF.MIL xxxxxx@MASTER.PA.AF.MIL 25 May 1996 00:04:58 Sent information mail to xxxxxxxxx@SOL.KISS.DENote that the "OK" may contain the return cookie:
25 May 1996 00:08:50 Processing file 8206772 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:08:50 From xxxxxxxxxx@GENIE.COM: OK 71365E 25 May 1996 00:08:50 From xxxxxxxxxx@GENIE.COM: SUBSCRIBE AFNS Mxxxx Exxx Kxxxxx er 25 May 1996 00:08:51 To xxxxxxxxxx@GENIE.COM: You have been added to the AFNS list. 25 May 1996 00:08:51 Sent information mail to xxxxxxxxxx@GENIE.COM 25 May 1996 00:08:51 Sending WELCOME message to xxxxxxxxxx@GENIE.COM 25 May 1996 00:08:51 Sent information mail to xxxxxxxxxx@GENIE.COM 25 May 1996 00:08:51 Sent information mail to: > xxxxxxx@AFSYNC.HQ.AF.MIL xxxxxxx@AFSYNC.HQ.AF.MIL > xxxxx@AFNEWS.PA.AF.MIL xxxxxx@MASTER.PA.AF.MIL 25 May 1996 00:08:51 Sent information mail to xxxxxxxxxx@GENIE.COM10.3.13. Invalid "OK" confirmation received "OK" confirmation codes relate to specific userids. For instance, if you try to execute a command as "email@example.com" and reply to the "OK" from "firstname.lastname@example.org", LISTSERV will not perform so-called "fuzzy matching" or do a DNS lookup to determine whether or not "unix1.someplace.com" maps to "someplace.com". Therefore, since the code and the userid don't match, LISTSERV will respond that the confirmation code does not match any pending job. This message is also sent if the "OK" comes after the "cookie" expires, since of course there is no longer any pending job matching it.
25 May 1996 01:16:28 Processing file 8211043 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 01:16:29 From xxxxxx@MSN.COM: ok 25 May 1996 01:16:29 To xxxxxx@MSN.COM: The confirmation code you gave (78B484) does not correspond to any pending (...)10.3.14. User is already subscribed to a given list Note that the user may be trying to change his "real name" field in the list. In any case, if the "real name" field matches the one in the SUBSCRIBE command, the following is logged:
25 May 1996 00:11:42 Processing file 8206935 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:11:42 From xxxxxxxx@NS.NET: SUBSCRIBE IN-TOUCH Txxxxx Hxxxxxx 25 May 1996 00:11:42 To xxxxxxxx@NS.NET: You are already subscribed to the IN- TOUCH list as "Txxxxx Hxxxxxx. 25 May 1996 00:11:42 Sent information mail to therrera@NS.NETIf the "real name" field is different, the following is logged:
25 May 1996 00:16:18 Processing file 8207278 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:16:18 From xxxxxxx@EROLS.COM: SUBSCRIBE IN-TOUCH Rxxxxxx Sxxx 25 May 1996 00:16:18 To xxxxxxx@EROLS.COM: The name associated with your xxxxx xx@EROLS.COM subscription has been (...) 25 May 1996 00:16:18 Sent information mail to xxxxxxx@EROLS.COM10.3.15. User has included non-command text (e.g., a .sig file) in his mail to LISTSERV
25 May 1996 00:32:07 Processing file 8207703 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:32:07 From MAILER@PEACH.EASE.LSOFT.COM: X-ADMMAIL OWNER-EXCEL-L M ailer-Daemon@inf.com 25 May 1996 00:32:15 Processing file 8207705 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:32:15 From xxxxxxxx@IX.NETCOM.COM: ok 25 May 1996 00:32:15 From xxxxxxxx@IX.NETCOM.COM: sub WINNT-L Txxxx D. Sxxxx 25 May 1996 00:32:15 To xxxxxxxx@IX.NETCOM.COM: You have been added to the WIN NT-L list. 25 May 1996 00:32:15 Sent information mail to xxxxxxxx@IX.NETCOM.COM 25 May 1996 00:32:15 From xxxxxxxx@IX.NETCOM.COM: Txxxx Sxxxx 25 May 1996 00:32:15 To xxxxxxxx@IX.NETCOM.COM: Unknown command - "TXXXX". Try HELP. 25 May 1996 00:32:15 From xxxxxxxx@IX.NETCOM.COM: email@example.com 25 May 1996 00:32:15 To xxxxxxxx@IX.NETCOM.COM: Unknown command - "XXXXXXXX@IX .NETCOM.COM". Try HELP. 25 May 1996 00:32:15 From xxxxxxxx@IX.NETCOM.COM: http://www.netcom.com/~xxxxxxx x/ 25 May 1996 00:32:15 To xxxxxxxx@IX.NETCOM.COM: Unknown command - "HTTP:". Try HELP. 25 May 1996 00:32:15 Sent information mail to xxxxxxxx@IX.NETCOM.COM10.3.16. Response to list owner or LISTSERV maintainer commands
25 May 1996 00:36:08 From xxxxxxx@WEBCOM.COM: quiet delete iatn firstname.lastname@example.org c.net.sq pw=xxxxx 25 May 1996 00:36:08 To xxxxxxx@WEBCOM.COM: xxxxxx@PO.PACIFIC.NET.SQ is not su bscribed to the IATN list. 25 May 1996 00:36:08 Sent information mail to xxxxxx@WEBCOM.COM10.3.17. Response to a user who tries to post to a held list (or one for which PRIMETIME is in effect)
25 May 1996 00:36:42 Processing file 8208564 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:36:43 To xxxxx@IQUEST.NET: The distribution of your message da ted Fri, 24 May 1996 23:32:59 -0500 with (...) 25 May 1996 00:36:43 Sent information mail to xxxxx@IQUEST.NET10.3.18. Command forwarded via GLX from another host
25 May 1996 00:48:56 Processing file 8210093 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 00:48:57 From LISTSERV@SEARN.SUNET.SE: X-B64 ID=X-FOR.JOB CLASS=M 25 May 1996 00:48:57 Rescheduled as: 8210094 25 May 1996 00:48:57 Processing file 8210094 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 00:48:57 From LISTSERV@SEARN: X-FOR FWDED=2 xxxxxxxx@CS.SFU.CA SUBSC RIBE WINNT-L Pxxxxxxxxx Pxxxxxxxx 25 May 1996 00:48:57 Requesting confirmation, cookie=4E79B8 25 May 1996 00:48:57 Sent information mail to xxxxxxxx@CS.SFU.CA 25 May 1996 00:48:57 Sent information mail to xxxxxxxx@CS.SFU.CA10.3.19. Netwide DELETE (X-DEL jobs)
25 May 1996 01:13:25 Processing file 8210957 from MAILER@PEACH.EASE.LSOFT.COM 25 May 1996 01:13:25 From LISTSERV@PSUVM.PSU.EDU: X-B64 ID=X-DEL.JOB CLASS=A 25 May 1996 01:13:25 Rescheduled as: 8210958 25 May 1996 01:13:25 Processing file 8210958 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 01:13:25 From LISTSERV@PSUVM: DIST2 I=Y FROM=LISTSERV@VM1.NODAK.EDU FORW(CRC) HOST(626 626 626 626 626 626 691 (...) 25 May 1996 01:13:25 Distributing file "X-DEL JOB" from LISTSERV@VM1.NODAK.EDU.. . 25 May 1996 01:13:25 File forwarded to HOME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 01:13:25 File forwarded to SPIDER.EASE.LSOFT.COM for 1 recipient. 25 May 1996 01:13:25 File forwarded to WIN95.DC.LSOFT.COM for 1 recipient. 25 May 1996 01:13:25 File forwarded to INDIAN.DC.LSOFT.COM for 1 recipient. 25 May 1996 01:13:25 File forwarded to LIME.EASE.LSOFT.COM for 1 recipient. 25 May 1996 01:13:25 File forwarded to LISTSERV.GEORGETOWN.EDU for 1 recipient . 25 May 1996 01:13:25 File forwarded to CC1.KULEUVEN.AC.BE for 1 recipient. 25 May 1996 01:13:26 File forwarded to LISTSERV.USHMM.ORG for 1 recipient. 25 May 1996 01:13:26 File forwarded to LISTSERV.CLARK.NET for 1 recipient. 25 May 1996 01:13:26 File "X-DEL JOB" distributed to LISTSERV@PEACH.EASE.LSOFT.C OM. 25 May 1996 01:13:26 Done - 9 jobs (9 rcpts), 1 outbound file (1 rcpt). 25 May 1996 01:13:26 Processing file 8210968 from LISTSERV@PEACH.EASE.LSOFT.COM 25 May 1996 01:13:26 From LISTSERV@VM1.NODAK.EDU: X-FOR xxxx@SDSUMUS.SDSTATE.EDU SIGNOFF * FWDED=2 (NETWIDE10.3.20. FIOC cache notifications LISTSERV caches files that it uses for efficiency. Occasionally, you may see a warning that the FIO cache has reached a preset limit (FIOC_WARNING in the site configuration file). See the FIOC_CACHE, FIOC_TRIM, and FIOC_WARNING site configuration variables in Appendix C for more information. If you get a lot of these warnings, you may want to consider adjusting the cache values.
25 May 1996 01:24:06 Virtual disk slot E(E:\EASE\PEACH\FTP\VBDATA-L) released. 25 May 1996 01:24:06 Directory E:\LISTSERV\ARCHIVES\SPAM-L accessed as virtual disk slot E. *** FIO file cache now totals 20659k. A list of cached files follows. *** File size Usage Flags File name --------- ----- ----- --------- 5071k 1 U E:\LISTSERV\ARCHIVES\SPAM-L\SPAM-L.LOG9605 2k 1 E:\listserv\TMP\LISTSERV.CMSUT1 242k 1 E:\listserv\main\PERMVARS.FILE 4k 1 E:\listserv\main\VBDATA-L.DIGEST 378k 1 E:\EASE\PEACH\FTP\VBDATA-L\VBDATA-L.LOG9605D 121k 1 E:\listserv\main\POSTNOTE.LIST 282k 1 E:\listserv\main\FUTURESUPERSTOCK.LIST 115k 1 E:\listserv\main\AUTOTECHNET.LIST 6k 1 E:\LISTSERV\ARCHIVES\HONYAKU\HONYAKU.DIGEST 1k 3 E:\listserv\main\DIGESTS.FILE 11k 3 E:\listserv\TMP\TEMP.FILELIST(Many more lines were deleted) 10.3.21. Web archive/administration interface logging (starting with 1.8d) When LISTSERV receives a request from the 'wa' interface, it logs the activity as below. Note that LISTSERV receives an X-LOGIN command from 'wa' and issues a validation code if the password and the user's e-mail address match. Note also that LISTSERV logs the IP address of the machine making the request via 'wa'.
5 Aug 1997 10:51:08 From IUSR_XXX@PEACH.EASE.LSOFT.COM: X-LOGIN email@example.com 22.214.171.124 PW=YYYYYYYY 5 Aug 1997 10:51:08 To IUSR_XXX@PEACH.EASE.LSOFT.COM: ***OK*** 6093C01B81CF68D 42B 5 Aug 1997 10:51:09 From IUSR_XXX@PEACH.EASE.LSOFT.COM: X-LOGCK 6093C01B81CF68D4 2B AUTHINFO(126.96.36.199) WM: LIST OWNED 5 Aug 1997 10:51:21 From IUSR_XXX@PEACH.EASE.LSOFT.COM: X-LOGCK 6093C01B81CF68D4 2B AUTHINFO(188.8.131.52) OWNER(TEST) WM: GET TEST (HDR NOL (...)The following indicates a timeout after 60 seconds of inactivity:
4 Feb 1998 10:26:53 From IUSR_XXX@PEACH.EASE.LSOFT.COM: X-LOGCK 37BA2700 C7AA3AE9EE AUTHINFO(184.108.40.206) TIMEKILL(60)This indicates a web archive search and the response:
4 Feb 1998 10:26:53 From IUSR_XXX@PEACH.EASE.LSOFT.COM: X-LOGCK 3EA2D501 187014BB04 AUTHINFO(220.127.116.11) NOTEBOOK(spam-l) DBS: SEARC (...) 4 Feb 1998 10:26:56 Reindexing SPAM-L LOG9802A... 4 Feb 1998 10:27:08 To IUSR_PEACH@LSOFT.COM: -> 23 matches.This indicates a subscrption via the web interface:
4 Feb 1998 10:27:08 From IUSR_PEACH@LSOFT.COM: X-LOGCK 37BA2700C7AA3AE9E E AUTHINFO(18.104.22.168) WM: SUBSCRIBE WINNT-L Kevin Mc (...) 4 Feb 1998 10:27:08 Requesting confirmation, cookie=1723C28410.3.22. X-SPAM jobs From time to time a server receives X-SPAM jobs from other LISTSERV hosts. These jobs are "spam alerts" which tell the server that spam has been detected at another site and a user has been put under 48 hour quarantine.
14 Jun 1999 06:48:52 Processing file 41256617 from MAILER@PEACH.EASE.LSOFT.COM 14 Jun 1999 06:48:52 From LISTSERV@PLUM.EASE.LSOFT.COM: X-B64 ID=X-SPAM.JOB ASCII CLASS=J 14 Jun 1999 06:48:52 Rescheduled as: 41256618 14 Jun 1999 06:48:52 Processing file 41256618 from LISTSERV@PEACH.EASE.LSOFT.COM 14 Jun 1999 06:48:52 From LISTSERV@PLUM.EASE.LSOFT.COM: DIST2 I=Y FROM=LISTSERV@LISTSERV.AOL.COM FORW(CRC) HOST(626) 14 Jun 1999 06:48:52 Distributing file "X-SPAM JOB" from LISTSERV@LISTSERV.AOL.COM... 14 Jun 1999 06:48:52 File "X-SPAM JOB" distributed to LISTSERV@PEACH.EASE.LSOFT.COM. 14 Jun 1999 06:48:52 Done - 1 outbound file (1 rcpt). 14 Jun 1999 06:48:52 Processing file 41256619 from LISTSERV@PEACH.EASE.LSOFT.COM 14 Jun 1999 06:48:52 From LISTSERV@LISTSERV.AOL.COM: X-SPAM exxxx_xxxxxxxxx@YAHOO.COM 4214CE9E 14 Jun 1999 06:48:52 -> Registered.At the end of this, the address exxxx_xxxxxxxxx@YAHOO.COM has been registered as a spammer and will be quarantined for 48 hours. 10.3.23. X-TBREG jobs X-TBREG jobs are sent out by all LISTSERV Lite Free Edition servers and any other servers that are set to TABLELESS runmode (see "RUNMODE" in Appendix C). These jobs register your server with a central L-Soft server, and are important for two reasons: first, so that your server and lists can show up in the L-Soft-maintained CataList service; and second, so that your server can participate correctly in the LISTSERV distributed server model without needing to update LISTSERV's networking tables on a regular basis. Non-Free Edition servers set to NETWORKED or STANDALONE runmode do not generate X-TBREG jobs, although they may receive them from remote hosts to be cached for DISTRIBUTE purposes. For more information about server registration, see chapter 5.6. Note that LISTSERV Lite Free Edition servers cannot change their runmode and therefore will always self-register this way. 10.3.24. Responses to LVMON@VM.SE.LSOFT.COM If you are running in Networked or Tableless mode you may see these from time to time:
13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: RELEASE 13 Mar 2000 16:45:13 To LVMON@VM.SE.LSOFT.COM: LISTSERV(R) High Performance fo r Windows NT version 1.8d, managed by: 13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW 13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW WWW_ARCHIVE_URL 13 Mar 2000 16:45:13 To LVMON@VM.SE.LSOFT.COM: WWW_ARCHIVE_URL = http://peach. ease.lsoft.com/scripts/wa.exe 13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW CTR 200003 13 Mar 2000 16:45:13 From LVMON@VM.SE.LSOFT.COM: SHOW CTR 200002 13 Mar 2000 16:45:13 Sent information mail to LVMON@VM.SE.LSOFT.COMVM.SE.LSOFT.COM is a central L-Soft server that collects publicly-available statistics and other information for the CataList service and for L-Soft's use in developing usage metrics. All of the commands sent by LVMON are documented and can be issued by any user. See also 5.7 of this manual for more information on inter-server information sharing.
Figure 10.2 Typical SMTP log for the SMTPL.EXE "listener"
13 Mar 1998 14:13:31 LISTSERV SMTP listener, version 1.0c 13 Mar 1998 14:13:31 Copyright L-Soft international, 1994-97 13 Mar 1998 14:13:31 Initialization complete. 13 Mar 1998 14:15:59 New connection (1) from 22.214.171.124 13 Mar 1998 14:18:50 New connection (2) from 126.96.36.199 13 Mar 1998 14:18:59 >>>(1) Connection closed by remote host. 13 Mar 1998 14:19:05 Closing connection (2) from 188.8.131.52. 13 Mar 1998 14:19:08 New connection (3) from 184.108.40.206 13 Mar 1998 14:20:08 Closing connection (3) from 220.127.116.11.
Figure 10.2 Typical SMTP log for the SMTPL.EXE "listener"
03 Jun 1996 13:49:21 *** LSMTP extensions activated *** 03 Jun 1996 13:49:03 500 error reading data line 03 Jun 1996 13:49:04 Renaming 8891738.MAIL to 8891738.MAIL-ERR1. 03 Jun 1996 14:06:54 Error opening '8894361.MAIL': Permission denied 03 Jun 1996 14:09:55 Error opening '8894695.MAIL': Permission denied 03 Jun 1996 14:40:45 Error opening '8897761.MAIL': Permission denied
Figure 10.3 Typical SMTPS log for the SMTPW.EXE SMTP "workers"
19980324100330 ADD xxxxxxx@JPS.NET Lxxxx Pxxxxxxxx 19980329120049 AUTODEL xxxxxxxx@EISA.NET.AU 19980329131221 BOUNCE xxxxxxxx@NONEXIST.COM 19980331214433 CHANGE xxxx@MCS.COM txxx@MCS.NET 19980331214434 DELETE xxxxx@SINGNET.COM.SG 19980331232441 POST xxxxxxxx@M4.SPRYNET.COM Printer Drivers 19980401000400 RESUBSCRIBE xxxx@MAIL.MECHWART.MUMSZKI.HU Mxxxxx Zxxxxx 19980426113947 SET xxxxxx.xxxxxxx@WDC.COM REPRO 19980511082712 SIGNOFF xxxxxxxx@STARNET.NET.AR 19980511085642 SUBSCRIBE xxxxxxxx@LYCOSMAIL.COM Kxx WxxxxxxAs you see, the SET entry tells you what options were set, and the POST entry tells you what the subject of the posting was. RESUBSCRIBE is a SUBSCRIBE operation that takes place when the user is already subscribed to the list, e.g., to change the real name field in the user's subscription. BOUNCE is a special operation that takes place when using the "no-list" bounce-processing mechanism (described in the Developer's Guide to LISTSERV). Otherwise these entries are fairly self-explanatory. One caveat: CHANGELOG files can get fairly large. It may be necessary to monitor the size of the changelogs on your server and delete them as disk space fills up. If a list owner wants the changelog information for his list, he should be instructed that it is his responsibility to GET the changelog file regularly and delete it himself each time.
10.7.1. Sample log-processing scriptsThere are two unsupported REXX scripts available from L-Soft which can be used to extract various statistics from the LISTSERV console log and from changelogs. See
Both of these scripts were written for Regina REXX and are (in their current incarnations) Windows-specific, but they could probably be ported to the unix version of Regina with a little work.
Be sure to read the internal documentation before attempting to use either of these scripts.
The first script is used to compile posting data from all lists on the server and issues a weekly report that looks like this:
LISTSERV posting statistics for LISTSERV.EXAMPLE.COM since 8 Feb 1999 ------------------------------------------------------------------------------ Indiv. Digests Indexes Total List Name Postings Generated Generated Recipients ========= ======== ========= ========= ========== LIST1 223 7 0 14574 LIST2 0 0 0 0 LIST3 12 7 7 825 ------------------------------------------------------------------------------ Totals: 235 14 7 15399 DISTRIBUTE and MAIL-MERGE jobs sent by individuals: Start Date/Time End Time Rcpts Job Name Invoker = ==================== ======== ======== ======== ======= D 8 Feb 1999 14:07:08 14:07:09 29 DISTJOB1 USER@EXAMPLE.COM M 12 Feb 1999 10:31:23 10:31:25 10334 MMDISTJO USER@EXAMPLE.COM >>> Full job name: MMDISTJOB25 * FROMfirstname.lastname@example.org This report was generated by cntpost.rexx version 1.8-fix11c 1999/02/19
The second script is designed to be run against a listname.CHANGELOG file and produces a report similar to the old VM STATS command output (addresses have been changed to protect the innocent). There are two options--TOP (which produces posting information for only the top x number of posters--by default this is 20, the value can be raised or lowered by changing the variable setting in the code), and NOP (which suppresses the individual posting data altogether). If neither the TOP or NOP options are specified, individual posting data are produced for each and every address that posted to the list during the period represented by the changelog, which has the potential to produce very long reports. It is probably best to run this script with redirection to a file.
Sample output from the STATS.REXX script is shown below:
C:\rexx>rexx stats.rexx access-l top Statistics for ACCESS-L from 08 Jan 1999 through 13 Jan 1999 (6 days) Total lines processed: 421 Total units Units/day =========== ========= ADD operations: 0 0.0000 AUTODEL operations: 8 1.3333 BOUNCE operations: 0 0.0000 CHANGE operations: 4 0.6667 DELETE operations: 3 0.5000 POST operations: 261 43.5000 RESUBSCRIBE operations: 0 0.0000 SET operations (total): 39 6.5000 ACK: 0 0.0000 NOACK: 4 0.6667 MSGACK: 0 0.0000 CONCEAL: 1 0.1667 NOCONCEAL: 0 0.0000 FILES: 0 0.0000 NOFILES: 0 0.0000 MAIL: 5 0.8333 NOMAIL: 13 2.1667 DIGESTS: 7 1.1667 NODIGESTS: 10 1.6667 INDEX: 1 0.1667 NOINDEX: 0 0.0000 REPRO: 1 0.1667 NOREPRO: 2 0.3333 MIME: 1 0.1667 NOMIME: 0 0.0000 HTML: 2 0.3333 NOHTML: 2 0.3333 TOPICS: 0 0.0000 FULLHDR: 0 0.0000 SHORTHDR: 0 0.0000 DUALHDR: 0 0.0000 IETFHDR: 0 0.0000 SUBJECTHDR: 1 0.1667 FULL822: 0 0.0000 SHORT822: 0 0.0000 SIGNOFF operations: 31 5.1667 SUBSCRIBE operations: 75 12.5000 Ratio of SIGNOFF operations to SUBSCRIBE operations: 0.4133:1 Total Top 20 posters Units Units/day Units/mon(*) ================================================ ===== ========= ========= Gxxxxx.Wxxxxx@xxxxxxxxxxx.xx.xx 19 3.1667 0.6333 email@example.com 18 3.0000 0.6000 firstname.lastname@example.org 11 1.8333 0.3667 email@example.com 11 1.8333 0.3667 firstname.lastname@example.org 8 1.3333 0.2667 email@example.com 8 1.3333 0.2667 Hxxxxxxx@xxxxxx.xxx 7 1.1667 0.2333 firstname.lastname@example.org 7 1.1667 0.2333 email@example.com 7 1.1667 0.2333 firstname.lastname@example.org 7 1.1667 0.2333 email@example.com 7 1.1667 0.2333 firstname.lastname@example.org 6 1.0000 0.2000 email@example.com 6 1.0000 0.2000 Pxxxxxx@xxxx.xxx 5 0.8333 0.1667 G.F.G.Wxxxxxxxx@xx.xxxxxxxx.xx 4 0.6667 0.1333 Nxxxxxxx.Vxx@xxx.xxxxx.xx.xx 4 0.6667 0.1333 firstname.lastname@example.org 4 0.6667 0.1333 email@example.com 4 0.6667 0.1333 firstname.lastname@example.org 4 0.6667 0.1333 email@example.com 3 0.5000 0.1000 ---------- (*) Units per month is total units / 30 days. Top 20 posters Last posted ================================================ =========== Gxxxxx.Wxxxxx@xxxxxxxxxxx.xx.xx 13-Jan-1999 firstname.lastname@example.org 12-Jan-1999 email@example.com 12-Jan-1999 firstname.lastname@example.org 13-Jan-1999 email@example.com 09-Jan-1999 firstname.lastname@example.org 13-Jan-1999 Hxxxxxxx@xxxxxx.xxx 13-Jan-1999 email@example.com 12-Jan-1999 firstname.lastname@example.org 13-Jan-1999 email@example.com 13-Jan-1999 firstname.lastname@example.org 13-Jan-1999 email@example.com 12-Jan-1999 firstname.lastname@example.org 09-Jan-1999 Pxxxxxx@xxxx.xxx 11-Jan-1999 G.F.G.Wxxxxxxxx@xx.xxxxxxxx.xx 13-Jan-1999 Nxxxxxxx.Vxx@xxx.xxxxx.xx.xx 13-Jan-1999 email@example.com 10-Jan-1999 firstname.lastname@example.org 13-Jan-1999 email@example.com 13-Jan-1999 firstname.lastname@example.org 11-Jan-1999 This report was prepared by STATS.REXX 0.4 1998/08/21
Please note carefully that these scripts are not supported in any way by L-Soft, and your use of them is strictly at your own risk.
10.7.2. Interpreting the output of SHOW CTRLISTSERV provides certain raw statistics in response to the command SHOW CTR yyyymm (where "yyyymm" is the year and month for which you are requesting statistics). For instance, SHOW CTR 199901 sent to LISTSERV@PEACH.EASE.LSOFT.COM produces the following:
>SHOW CTR 199901 199901 1 0 34769 28012983 4671 1444858 1939 13724 144131 115889 113714 21162 172559 124323 258387 0 73741 80953 178700227 731465 339375 114770 93409 END EOD
Unfortunately this is fairly obscure (it was originally intended to be used only by LISTSERV to compile network-wide statistics) and requires a certain amount of interpretation. The fields signify, in order:
Month of report
Postings to mailing lists
Number of recipients
Number of digest recipients
Number of index recipients
DISTRIBUTE jobs processed
DISTRIBUTE jobs internally generated
Outbound DISTRIBUTE jobs
Outbound NJE files
Outbound files to MAILER
Outbound files to MAILER in non-BSMTP format
Number of recipients in the outbound files to MAILER
Bandwidth usage register #1
Bandwidth usage register #2
CPU usage in microseconds
Number of bounces received
Number of bounces received in non-standard format
Number of bounces detected by heuristics
END (tells LISTSERV that this is the end of the regular data)
EOD (tells LISTSERV that this is the end of the report)
The two bandwidth registers are used as follows:
Bandwidth used in MB = (first_register/10) + (second_register/10000000)
If you send a SHOW CTR command for the current month, LISTSERV inserts the following between the END and EOD markers:
XPOL integer_value integer_value
For instance, in the month this was written (199902), the output on 19 February at approximately 12:43 was
>SHOW CTR 199902 199902 1 0 22347 18983312 2939 932534 1200 10728 89783 71642 74311 13017 129368 97498 194743 0 47087 71848 107529422 386957 180617 23707 17063 END XPOL 672 444 EOD
The XPOL numbers are used by L-Soft to extrapolate data for the current month and can generally be ignored.
(NOTE: The links shown on these pages will not work from the manual. For a working demonstration site, see http://demo.lsoft.com or see the appropriate pages on your own site.)