Table of Contents Previous Next Index

Section 14 LISTSERV Commands

Section 14 LISTSERV Commands
This section 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: Some commands are not available on all platforms; these commands are marked appropriately.
Continuation cards (see the Advanced Topics Manual for LISTSERV regarding LISTSERV’s Command Jobs Language) can be used to split long commands (for instance, ADD commands for users with long X.500 addresses) into two or more 80-character cards. In that case you must insert "// " (two slashes followed by a space) before the command text and a comma at the end of each line of the command so that CJLI considers it as a control card and performs the required concatenation. For instance,
His Name
or, for instance, for a large GETPOST job,
// GETPOST MYLIST 10769-10770 10772 11079 11086 11095 11099-11100 11104 ,
11111 11115 11118 11121 11124 11131 11144 11147 11153 11158 11166 11168
Be sure to put a space before the comma at the end of the first line, as LISTSERV will not add the space for you.
14.1 General Commands
14.1.1 List Subscription Commands
The following commands are listed from most to least important.
SUBscribe listname [full_name | ANONYMOUS] [WITH options]
The SUBscribe command is LISTSERV's basic command, issued by users to join mailing lists. This command can also be used to change one's "full_name" field in LISTSERV's SIGNUP database (simply reissue the command with the changed name). Note that the full_name is not required if the user has previously signed up to lists on the same LISTSERV server, or if the user has previously registered in LISTSERV's SIGNUP database by using the REGISTER (q.q.v.) command.
The following syntax:
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.
The following additional syntax:
SUBSCRIBE listname full_name WITH option1 option2 ...
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
Or you might want to receive individual postings with the SUBJecthdr option and receive copies of your own postings instead of the standard acknowledgement that your message was distributed to the list:
QUIET SUBSCRIBE listname full_name WITH option1 option2 ...
suppresses the command response normally sent by LISTSERV that looks like this:
You have been added to the MYLIST-L list.
JOIN listname [full_name | ANONYMOUS] [WITH options]
JOIN is a synonym for SUBscribe.
SIGNOFF listname|*|* [(NETWIDE]
The SIGNOFF command allows the user to cancel his or her subscription to lists. SIGNOFF requires a qualifying parameter, as follows:
listname Sign off of the specified list
* Sign off of all lists on that server
* (NETWIDE Sign off of all lists in the LISTSERV network
The "* (NETWIDE" parameter causes the LISTSERV server to forward a copy of the signoff request to all other registered LISTSERV servers. This is a good option for a user who is changing service providers or otherwise losing a specific address that will not be forwarded. Please note that this parameter will not remove the user from non-LISTSERV lists or from LISTSERV lists running on non-registered sites. It will also not work if the server to which you issue it is running in STANDALONE runmode.
LISTSERV will attempt to sign off the address it finds in the RFC822 "From:" line and will not "fuzzy match" for "similar" addresses. The single exception is when the hostname part of the address is aliased to another hostname in LISTSERV's centrally-maintained ALIASES NAMES file.
UNSUBscribe listname|*|* [(NETWIDE]
UNSUBscribe is a synonym for SIGNOFF.
CHANGE listname|* newaddr
This form of the CHANGE command can be used by any subscriber. It must be sent from the currently-subscribed address and results in an OK confirmation request being sent back to that address. This cookie then MUST be confirmed by the currently-subscribed address, exactly as it was entered, or the command will fail. This is the only case where a LISTSERV cookie must be confirmed by a specific address. Note that this assumes that the user still has login access to both addresses, or at least the ability to send mail from the old address.
SET listname option1 [option2 ...]
Allows the user to change his or her subscription options without administrative intervention. The options available to be changed are as follows:
ACK – A mail message acknowledging the receipt and distribution of the user's posting is sent back to the user.
NOACK – No posting acknowledgement is sent. In general, this setting should only be used if the user has also set himself to REPRO, as it is desirable in most cases that some indication of whether or not the posting was received by LISTSERV be sent.
MSGack – (Obsolete) An interactive message is sent to acknowledge receipt and distribution. Note that this works only if both the machine running LISTSERV and the user's machine have NJE connectivity (e.g., BITNET). If NJE connectivity is not available on both ends, this option is effectively the same as NOACK.
CONCEAL – Allows the user to be concealed from the REVIEW command. Note that the list owner or LISTSERV maintainer can always get the complete list of subscribers, regardless of this setting.
NOCONCEAL – "Unhides" the user.
Files/NOFiles – (Obsolete) These options toggle the receipt of non-mail files from the list. Note that this is NJE-specific, and thus obsolete for systems without NJE connectivity, but retained for compatibility.
Mail/NOMail – These options toggle the receipt of mail from the list. Users who will be away from their mail for an extended period of time may prefer to simply turn the mail off rather than to unsubscribe, particularly if subscription to the list is restricted in some way.
Note: For backward compatibility, the command SET listname MAIL sent by a user who is set to DIGEST but not also set to NOMAIL will cause the user to be set to NODIGEST (the behavior is identical for users set to INDEX but not to NOMAIL). SET listname MAIL sent by users set to DIGEST/NOMAIL or INDEX/NOMAIL will simply remove the NOMAIL setting and leave the user set to DIGEST or INDEX as the case may be.
DIGests/INDex/NODIGests/NOINDex – These options change the format in which list mail is received by the subscriber. DIGEST turns on digest mode, in which the subscriber receives a digest of postings at set times dependent on how the "Digest=" keyword of the list is set. INDEX turns on index mode, in which the subscriber receives a daily listing of subjects posted to the list, from which he or she may order postings of interest. NODIGEST and NOINDEX toggle the mode back to individual postings sent as received by LISTSERV. Note that these options are interrelated; setting one will negate another.
REPro/NOREPro – Causes LISTSERV to send you a copy of your own postings as they are distributed. Some users may prefer this behavior to the ACK option (see above).
MIME/NOMIME – Toggles MIME options on and off. Currently only digests are available in MIME format. If DIGEST mode is set, the user will receive a MIME digest instead of the regular plain-text digest. Note that you must have a mail client that supports MIME digests (Pegasus is one that does) or this setting will do you little good. This option is automatically set at subscribe time for users who send their subscription command using a MIME-compliant agent, unless "Default-Options= NOMIME" is specified for the list.
HTML/NOHTML – Toggle the HTML function for digests and indexes on and off.
TOPICS: ALL | [+/-]topicname – For lists with topics enabled (see the Topics= list header keyword), subscribe or unsubscribe to topics. For instance, if a list has topics SUPPORT and CHAT, a user could subscribe to CHAT by sending SET TOPICS +CHAT. Or the user could unsubscribe to SUPPORT by sending SET TOPICS -SUPPORT. Finally, the user can subscribe to all available topics by sending SET TOPICS ALL.
Options for mail headers of incoming postings (choose one):
FULLhdr – "Full" mail headers, (default) containing all of the routing information.
IETFhdr – Internet-style headers.
SHORThdr – (Obsolete) Short headers (only basic information about the message - Date, From, Subject, To -- is preserved). Setting SHORThdr will break MIME-encoded messages, so it should be used only on lists where MIME and HTML messages are not allowed.
DUALhdr – Dual short headers, useful with older mail programs which do not preserve the RFC822 return email address. Same caveat as with SHORThdr.
SUBJecthdr – "Full" mail headers (like the default) except that setting this option tells LISTSERV to add the list's default subject tag to the subject line of mail coming from the list. (See the listing in the List Keyword Reference document for "Subject-Tag=" for more information.) Note that if the user is set to SHORThdr (or any other header option other than FULLhdr), LISTSERV will automatically switch the user to FULLhdr, as subject tags require full headers. A subject tag is generated (for subscribers with the SUBJecthdr option set) even if the original message had no "Subject:" header. To turn the subject tagging off, the user simply sends a new SET command with any of the other header options (e.g., SET listname FULLhdr) and the SUBJecthdr option is reset.
FULL822 – Essentially the same as "full" mail headers, but with the important difference that the recipient's email address is specified in the "To:" line rather than the address of the list. "FULL822" headers should be used with extreme caution, as they cause LISTSERV to create a separate mail envelope with a single RFC821 RCPT TO: for each address so set. This behavior can significantly affect the performance of both LISTSERV and of your external mail system.
SHORT822 – Essentially the same as "short" mail headers, with the same caveats as noted for FULL822.
Note: 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.
Documented Restriction: The use of the SHORTHDR or DUALHDR options will break messages that depend on MIME encoding, because these options strip the RFC822 headers that identify the message as a MIME message. SHORTHDR and DUALHDR were designed for the non-MIME mail clients which prevailed in LISTSERV's early history. As most mail clients today support MIME, the use of these options is now deprecated.
CONFIRM listname1 [listname2 ]...]]
The CONFIRM command should be issued when LISTSERV requests it. A request for CONFIRM should not be confused with a "command confirmation request" which requires an "OK" response. The CONFIRM command is used in two cases:
When the list in question requires periodic subscription renewals (controlled by the Renewal= keyword). In this case, the amount of time between the request for confirmation and termination of the subscription is controlled by the Delay() parameter of the Renewal= keyword; the default is seven days.
When LISTSERV's automatic address probing function fails and you receive a message to that effect. The response time is controlled by the settings of the Auto-Delete= keyword for the list in question.
14.1.2 Other list-related commands
INDex [listname]
The INDEX command sent to LISTSERV without further qualification sends back the contents of the "root" level archive filelist on VM systems (LISTSERV FILELIST) or archive catalog on non-VM systems (SITE.CATALOG plus the contents of SYSTEM.CATALOG).
If the INDEX command is sent with the name of a list (e.g., INDEX MYLIST) or the name of a special filelist or catalog file (e.g., INDEX TOOLS, if TOOLS FILELIST on VM or TOOLS.CATALOG on non-VM exists), LISTSERV sends back the contents of the specified filelist or catalog. Several possibilities exist:
For mailing lists without an associated filelist or catalog, LISTSERV creates an index "on the fly" containing entries for the accumulated notebook archives for that list. If notebook archives are not enabled for the list, LISTSERV will respond, "This server does not have any file by the name 'listname.filelist'."
For mailing lists with an associated filelist or catalog, LISTSERV will append the "on the fly" index of notebook archives to the entries in the associated filelist or catalog. For instance, for a list called MYLIST with associated catalog MYLIST.CATALOG, INDEX MYLIST might return:
Table 14-1 Sample Output of an INDEX Listname Command
* :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
* 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
Lastly, for catalogs or filelists without an associated list, the INDEX command returns only the entries in the catalog or filelist, since there are no associated list archives to be indexed.
Under VM, instead of the size in bytes, three separate VM-specific columns are used. Please note the following definitions for them:
rec -fm – Indicates whether the file is in a fixed or variable record format.
lrecl – Logical record length. For a file with fixed record format (F), this is the length of each record. For a file with variable record format (V), this is the maximum record length.
nrecs – Number of records (lines) in the file.
Lists [option]
Access the global list of lists maintained by LISTSERV. If no options are specified, then LISTSERV returns only local lists, one line per list. The available options are:
Detailed – All local lists, complete with full header information.
Global xyz – Only those whose name or title contains 'xyz'.
SUMmary [host] – Membership summary for all lists on specified host, or the host to which the command is sent if no host is specified.
SUMmary ALL – Membership summary for all hosts (long output, send request via mail).
SUMmary TOTAL – Membership totals only.
"Lists Global" without a search string, which returns the entire list of lists, may no longer be issued by general users. General users should use the "Lists Global /xyz" format to search the list of lists, or (preferably) use L-Soft's CataList service at
"Lists SUMmary", when issued to an unregistered host or to a host running in STANDALONE mode will generate the response "No information available yet - please try again later." because the file required for this function does not exist.
Query listname
Query your subscription options for a particular list (use the SET command to change them). Using the "*" wildcard in place of the name of a single list queries subscription options on all lists on the server.
REGister full_name | OFF
Register's the user's full name field in LISTSERV's SIGNUP files, or changes the current value of that field. When a user's name is registered, he or she can omit the full name field from subsequent SUBscribe requests to that server. Sending "REGISTER OFF" to LISTSERV deletes the user's entry from the SIGNUP file.
REView listname [(options]
Get information about a list, assuming the list header keyword "Review=" is set appropriately. For general users, REVIEW does not return address information about subscribers who are set to CONCEAL. The options are:
BY sort_field – Sort list in a certain order:
Country – Sorts by country of origin (ISO country codes).
Date – Sorts by subscription date (newest to oldest).
Name – Sorts by user name (last, then first).
NODEid – Sorts by hostname/nodeid
Userid – Sorts by userid
BY (sort_field1 sort_field2) – You can specify more than one sort field if enclosed in parentheses. For instance, BY (NODE NAME).
Countries – Synonym of BY COUNTRY.
Topics – Adds a breakdown of subscribers per topic (if Topics= is defined in the list header) at the end of the subscriber list. If you just want the breakdown, use REVIEW listname SHORT TOPICS. This does not show topics by individual subscribers (see the QUERY command instead). If Topics= is not enabled for a given list then this option is ignored.
LOCal – Don't forward request to peers. This is only useful if the list is peered; normally it should not be necessary to issue this option.
Msg – Send reply via interactive messages (BITNET users only).
NOHeader – Don't send list header, just send the subscriber list.
Short – Don't list subscribers, just send the header and the membership summary for the list.
Note: You can get a quick read of the number of subscribers on the list by sending the command REVIEW listname SHORT NOHEADER.
List owners and site maintainers may also use the additional option:
ALL – List concealed members (who will show up with "[concealed]" next to their entry) as well as non-concealed members. (NOT available to general users even if Review= Public.)
SCAN listname text
Scan a list's membership for a name or address. Helpful if a user attempts to send a SET command or an UNSUB command and is informed that their address is not subscribed to the list. At the non-privileged level, this command will show all non-concealed entries that match the search text, assuming that the list is set to "Review= Public".
Stats listname [(options]
The following command is available on VM servers only.
Get statistics about a list. This command is VM-specific, and was originally intended to return BITNET data. The single option is:
14.1.3 Informational commands
Obtain a list of commonly-used LISTSERV commands. Also explains how to get the comprehensive reference card and tells who the (non-hidden) server manager(s) are.
Info [topic|listname]
Order a LISTSERV manual, or get a list of available ones (if no topic was specified); or get information about a list. For Info listname, the text in the INFO template form of listname.MAILTPL is used; however, if listname.MAILTPL does not exist or does not contain an INFO template form, the INFO template form of DEFAULT.MAILTPL is used.
Query File fn ft [filelist] [(options]
(Available only on VM) Get date/time of last update of a file, and GET/PUT file access code. The single option is:
Flags – Get additional technical data (useful when reporting problems to experts).
Find out who maintains the server, the version and build date of the software, and the version of LISTSERV's network data files.
SHOW [function]
Display information as follows:
ALIAS node1 [node2 [...]]BITNET nodeid to Internet hostname mapping.
DISTribute – Statistics about DISTRIBUTE.
HARDWare or HW – Hardware information; what kind of machine is LISTSERV running on?
LICense – License/capacity information and software build date.
LINKs [node1 [node2 [...]] – Network links at the BITNET node(s) in question.
NADs [node1 [node2 [...]] – Addresses LISTSERV recognizes as node administrators for the specified site(s).
NODEntry [node1 [node2 [...]]BITEARN NODES entry for the specified node(s).
NODEntry node1 /abc*/xyz – Just the ':xyz.' tag and all tags whose name starts with 'abc'.
POINTs [ALL | list1 [list2...]] – Graduated (LISTSERV Classic) license point information. This information can help you plan orderly expansion of your site if you are running with a graduated LISTSERV Classic license. Under Lite this command shows Classic point usage.
STATs – Usage statistics for the server (this is the default option).
VERSion – Same output as RELEASE command.
If no function is specified, the output is per SHOW STATS.
The following options are available for VM servers only:
BITEARN – Statistics about the BITEARN NODES file.
DPATHs host1 [host2 [...]] – DISTRIBUTE path from that server to specified host(s).
DPATHs * – Full DISTRIBUTE path tree.
FIXes – List of fixes installed on the server (non-VM see SHOW LICENSE).
NETwork – Statistics about the NJE network.
PATHs snode node1 [node2 [...]] – BITNET path between 'snode' and the specified node(s).
14.1.4 Commands Related to File Server and Web Functions
GET fn ft [filelist] [(options] [F=fformat] [SPLIT=integer]
GET fn ft [catalogname] [([F=fformat] [SPLIT=integer]]
Order the specified file or package from LISTSERV. The single option is for VM servers only and is:
Typically the filelist name or catalog name is the same as the name of the list to which the files belong. A password (PW=xxxxx at the end of the command) is required to retrieve any file that does not have a GET FAC of ALL. For more information on FAC (File Access Control) codes, see Section 18.3.5 File Access Codes (FAC) for User Access (VM Systems Only) or Section 18.4.1 Adding Files to the SITE.CATALOG.
Do not use dots (periods) in the file specification when specifying the filelist or catalog name, as this will result in an error. For instance
will result in an error, whereas
will not.
To control the format in which LISTSERV returns the file(s) to you, you can specify the F=fformat parameter. Supported formats are Netdata, Card, Disk, Punch, LPunch, UUencode, XXencode, VMSdump, MIME/text, MIME/Appl, Mail.
To split very large files into manageable chunks, you can specify the SPLIT=integer parameter. The integer value is the size you want the chunks to be generated, in kilobytes. For instance if you were ordering a 2MB notebook log and wanted to break it into 100KB chunks, you would specify SPLIT=100. This is handy for people whose mail systems place a limit on the size of an individual mail message that may be received by a given user.
The following syntax is accepted for TCPGUI parameters for Change-Logs:
GET listname CHANGELOG (MSG [COLUMNS(colspec1 colfilter1 [colspec2 colfilter2[...]])
The design goal was to provide access via the TCPGUI (and thus the web interface) for change-log data. Further information can be found in the Advanced Topics Guide for LISTSERV.
VM Syntax: GIVE fn ft [filelist] [TO] userid@host
GIVE fn.ft [TO] userid@host
GIVE fn ft catalogname [TO] userid@host
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.
For LISTSERV running on non-VM hosts there are two syntaxes, depending on whether or not you need to specify a catalog name for the file in question. Note that the only real difference is whether or not you are required to specify a dot between the filename and the extension.
INDex [filelist|catalog]
Same as GET xxxx FILELIST. If no filelist is specified, the default is LISTSERV FILELIST (on non-VM, SITE CATALOG is returned as LISTSERV FILELIST in this case).
PW function
Define/change a "personal password" for protecting AFD/FUI subcriptions, authenticating PUT commands, and so on.
ADD firstpw – Define a password for the first time, or after a PW RESET. Requires confirmation via the "OK" confirmation method.
CHange newpw [PW=oldpw] – Change your existing password. If you do not include your old password for authentication, LISTSERV will require confirmation via the "OK" confirmation method.
REP password – Starting with 1.8d, this function is a hybrid of "ADD" and "CHange". If a password does not exist for the user, one will be added. If a password does exist for the user, it will be changed (with confirmation required via the "OK" confirmation method). "REP" was added primarily for use by the web archive and administration interface but can be used in e-mailed PW commands as well.
RESET – Reset (delete) your password. This function always requires confirmation via the "OK" confirmation method.
Same as GET.
Available on VM servers only.
Automatic File Distribution. The functions are as follows:
ADD fn ft [filelist [prolog]] – Add file or generic entry to your AFD list.
DELete fn ft [filelist] – Delete file(s) from your AFD list (wildcards are supported).
For node administrators:
FOR user ADD/DEL/LIST etc – Perform requested function on behalf of a user you have control over (wildcards are supported for DEL and LIST).
Available on VM servers only.
File Update Information: same syntax as AFD, except that FUI ADD accepts no 'prolog text'.
14.1.5 Other Advanced Commands
DISTribute type source dest [options]
Note: Starting with 1.8d, the ability to send DISTRIBUTE jobs is limited to LISTSERV Maintainers by default, and requires a password. This section is retained for compatibility with 1.8c and earlier, and for 1.8d and later servers which have the DISTRIBUTE security feature turned off.
Distribute a file or a mail message to a list of users (see the Advanced Topics Guide for LISTSERV for more details on the syntax). The various parameters are, briefly:
MAIL – Data is a mail message, and recipients are defined by '<dest>'.
MAIL-MERGE – Data is a mail-merge message. See the Advanced Topics Guide for LISTSERV for specifics.
FILE – Data is not mail, recipients are defined by '<dest>'.
POST – (non-VM only) Same as MAIL except that the message is pre-approved. See the Advanced Topics Guide for LISTSERV for specifics.
RFC822 – Data is mail and recipients are defined by the RFC822 'To:'/'cc:' fields.
DD=ddname – Name of DD holding the data to distribute (default: 'DD=DATA').
<TO> user1 <user2 <...>> – List of recipients.
<TO> DD=ddname – Use a DD called ddname for the destination addresses, one recipient per line.
Options for the general user:
ACK=NOne/MAIL/MSG – Acknowledgement level (default: ACK=NONE).
CANON=YES – 'TO' list in 'canonical' form (uid1 host1 uid2 host2...).
DEBUG=YES – Do not actually perform the distribution; returns debug path information.
INFORM=MAIL – Send file delivery message to recipients via mail.
TRACE=YES – Same as DEBUG=YES, but file is actually distributed.
AV=YES[,FORCE] – Check the message for viruses. See the Advanced Topics Guide for LISTSERV for specifics.
DKIM=NO/YES – Sign the message with a DomainKeys signature (default: DKIM=NO) See Section 5.12 LISTSERV DomainKeys Support for specifics.
Options requiring privileges:
FROM=user – File originator
FROM=DD=ddname – One line: 'address name's
PRE-APPROVED=YES – Pre-approve message (with DISTRIBUTE POST only)
GETPost listname post_number [post_number [...]] [NOMIME]
GETPost is used after receiving the output of a SEARch command to retrieve the postings you want from the SEARch output. For instance, if you want postings numbered 1730, 1731, 1732, and 1840 from the MYLIST list, send the command
GETPost MYLIST 1730-1732 1840
GETPost is analogous to the VM database command PRINT.
In previous versions, the GETPost command returned messages that contained MIME attachments in their "raw" form, which could not be extracted automatically by MIME-aware mail clients. Customers who wished to use list notebooks to archive word-processing documents (for instance) found this to be a problem. From LISTSERV 1.8e, attachments returned in messages by way of the GETPost command will now display as inline clickable links in the individual messages.
Users of certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" as the last parameter of the GETPost command.
For lists running on VM servers, see also below at DATABASE.
The Search command syntax is similar to that of the SEARCH/SELECT commands in the "old" database functions. A very basic Search command for list MYLIST would look like this:
Search search_string IN MYLIST
You can also restrict your search by date, sender, or other criteria, for example,
Search search_string IN MYLIST SINCE 96/01/01
The specific syntax is outlined in LISTDB MEMO (available from LISTSERV with the command "INFO DATABASE") and in the Advanced Topics Guide for LISTSERV.
Note: The "new" Search command does not require a CJLI job framework to operate; simply send the Search command in the body of an email message to the appropriate server. LISTSERV will respond with an index of the postings matching your criteria and instructions on how to use the GETPost command to retrieve the posts you want.
SERVE user
Restore service to a user whose access to LISTSERV has been disabled. This generally occurs when a user has sent 51 incorrect commands in a row to LISTSERV, which LISTSERV interprets as a possible mail loop. (Note also that certain mail packages that send "Read:/Not Read:" notifications back to LISTSERV will trigger this scenario after 51 iterations. The best solution would be for the user to disable receipt notifications.) The user in question cannot restore his or her own service; this command must be issued from another userid. Note that if the user has been manually served out by privileged user (a LISTSERV maintainer), the SERVE command must be issued by a similarly-privileged user (who must also be a LISTSERV maintainer, although naturally the same user who issued the SERVE OFF command can issue the SERVE command).
Note: The THANKs command will not reset the serve-off counter (so vacation messages or auto-replies that contain a sentence starting with something like "Thanks for writing" will not defeat the system and users sending them will eventually be served off instead of continuing to loop ad infinitum).
You can send this command to check to see if the server is alive. If it is, the server politely responds, "You're welcome!".
DATAbase function
This command is only available on VM servers:
Access LISTSERV database(s). The functions are explained in detail in the version of LISTDB MEMO available from VM servers, but the basic syntax is:
Search DD=ddname <ECHO=NO> – Perform database search (see the VM version of LISTDB MEMO for more information on this)
List – Get a list of databases available from that server
REFRESH dbname – Refresh database index, if suitably privileged
This command is only available on VM servers:
14.2 List Owner and File Owner Commands
14.2.1 File Management Commands (for file owners only)
PUT fn ft <filelist <NODIST>>
Update a file you own. Options are:
<PW=password> – Supply your password for command authentication.
The following options are VM-specific and will not work on the non-VM servers.
The "NODIST" option prevents AFD and FUI distributions when the file is updated. Other available VM only options include:
<CKDATE=NO> – Accept request even if the current version of the file is more recent than the version you sent
<DATE=yymmddhhmmss> – Set file date/time.
<RECFM=F <LRECL=nnn>> – Select fixed-format file (not to be used for text files).
<REPLY-TO=userid> – Send reply to another user.
<REPLY-TO=NONE> – Don't send any reply.
<REPLY-VIA=MSG> – Request reply via interactive messages, not mail (Requires NJE connectivity).
<"parameters"> – Special parameters passed to FAVE routine, if any.
Standard parameters supported for all files:
TITLE=file title – Change file "title" in filelist entry.
This command is only available on VM servers.
Automatic File Distribution privileged commands. In addition to the AFD/FUI functions listed above, a file owner may use the following function:
GET fn ft <filelist> – Get a list of people subscribed to a file you own.
GET fn FILELIST <(options>
This command is only available on VM servers.
Special options for filelists:
CTL – Return filelist in a format suitable for editing and storing back.
NOLock – Don't lock filelist (use in conjunction with CTL).
REFRESH filelist <(options>
This command is only available on VM servers.
Refresh a filelist you own. The single option is:
NOFLAG – Don't flag files which have changed since last time as updated (for AFD/FUI).
This command is only available on VM servers.
Unlock filelist after a GET with the CTL option if you decide not to update it after all
14.2.2 List Management Functions
Commands that support the QUIET keyword are marked with an asterisk (*).
ADD(*) listname user [full_name]
ADD(*) listname DD=ddname [IMPORT [PRELOAD]]
The first syntax is used to add an individual user to one of your lists, or update his name field. Note that you can substitute an asterisk ("*") for full_name and LISTSERV will substitute "<No name available>" in the list.
The second syntax is used for bulk ADD operations where a dataset (DD=ddname) is used add multiple users, one address/name pair per line. For bulk operations you may also use the IMPORT option, which 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. The IMPORT PRELOAD option is used to direct LISTSERV to preload the existing e-mail keys in memory before starting the transaction, which speeds the operation up considerably. This option is used primarily with DBMS lists to speed up bulk adds. PRELOAD is not necessary for traditional LISTSERV lists and does not normally lead to a significant performance improvement. However, when importing a new list (no existing subscribers), it does reduce CPU usage somewhat.
For a bulk ADD operation, the users are defined in a separate dataset beginning on the line following the ADD command. For instance,
ADD listname DD=ddname IMPORT
//ddname DD * User Name User2 Name
... more address/name pairs, one per line ...
Please see Section 15.17 Bulk Operations (ADD and DELETE) for specific instructions for bulk ADD operations.
Same as ADD, but means "add the user on this peer, do not forward this request to a (possibly) closer peer". For non-peered lists, is functionally identical to ADD.
CHANGE(*) listname|* newaddr
CHANGE(*) listname|* oldaddr|pattern newaddr|*@newhost
The first form can be used by any subscriber and results in a cookie being sent to the new address. This cookie MUST be confirmed by the new address, exactly as it was entered, or the command will fail. This is the only case where a LISTSERV cookie must be confirmed by a specific address.
The list owner form does not use cookies but simply applies the standard "Validate=" rules (as for a DELETE command). You can specify a wildcard pattern for the old address and *@newhost for the new address to rename certain addresses to a new hostname. The CHANGE1 template is sent unless you specify QUIET.
Change log entries are made (CHANGE oldaddr newaddr) and there is a CHG_REQ exit point which allows you to reject the operation.
DELete(*) listname user [(options]
DELete(*) listname DD=ddname [BRIEF]
The first syntax is used to remove a single user from one of your lists, or from all local lists if listname is '*' The available options are:
Global – Forward request to all peers
LOCal – Don't try to forward request to closest peer if not found locally
TEST – Do not actually perform any deletion (useful to test wildcard patterns)
The second syntax is used for bulk DELETE operations (similar to a bulk ADD operation). See Section 15.17 Bulk Operations (ADD and DELETE) for details. The single available option is:
BRIEF – Good for deleting wildcard patterns (such as *@*) when you don't want a "userid@host has been deleted from list xxxx" for each user deleted. Returns instead only a count of the users that were deleted.
EXPLODE listname <(options>
This command is only available on VM servers.
Examine list and suggest better placement of recipients, returning a ready-to-submit MOVE job.
BESTpeers n – Suggest the N best possible peers to add.
Detailed – More detailed analysis.
FOR node – Perform analysis as though local node were 'node'.
PREFer node – Preferred peer in case of tie (equidistant peers).
SERVice – Check to see that service areas are respected.
With(node1 <node2 <...>>>) – Perform analysis as though specified nodes ran a peer.
WITHOut(node1 <node2 <...>>>) – Opposite effect.
FREE listname <(options>
Release a held list. The single option is:
Global – Forward request to all peers.
GET listname <(options>
Get a copy of a list in a form suitable for editing and storing the list and lock it so that other list owners can't modify it until you store it back (or until you or they issue an UNLOCK command). The options are:
Global – Forward request to all peers.
HEADer – Send just the header; on the way back, only the header will be updated. This is the recommended way to modify your list header.
NOLock – Do not lock the list.
OLD – Recover the "old" copy of the list (before the last PUT).
HOLD listname <(options>
Hold a list, preventing new postings from being processed until a FREE command is sent. The single option is:
Global – Forward request to all peers
Lists [option]
Additional options available for list owners and moderators:
OWNed – Returns a list of local lists owned by the invoker.
MODerated – Returns a list of local lists that are moderated by the invoker.
MOVE(*) listname user <TO> node
Move a subscriber to another peer. Do NOT use this command to move users from one list host site to another during migration. It is strictly for moving subscribers from one peer to another peer.
listname DD=ddname – Move several subscribers to various peers
PUT listname LIST
Update a list from the file returned by a GET command. This is the standard "PUT command" or "list PUT" referred to throughout this document.
Use of the PUT command to store a list header with new subscriber data at the bottom (e.g., an attempt to add subscribers "on the fly") will result in only the header of the list being stored, and in the generation of the following warning:
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.
PUTALL listname LIST
This command allows you to PUT an entire list file, that is, the list header followed by the list of subscribers.
Documented Restriction: PUTALL does not work with DBMS lists; only the header information is replaced. Subscriber information in the DBMS table is not changed. For DBMS lists where the subscriber information needs to be replaced in toto, either the DBMS should be manipulated with your regular DBMS tools or you should use ADD IMPORT.
Query listname <WITH options> FOR user
Query the subscription options of another user (wildcards are supported).
* <WITH options> FOR user – Searches all the lists you own for the specified user(s) with the specified option(s).
REINDEX [options] list1 [list2 [...]]]
Documented Restriction: Because it is resource-intensive, the REINDEX command is considered a "maintenance" command as opposed to an "everyday" command, and should not be issued in production environments outside of regularly-scheduled maintenance windows.
The REINDEX maintenance command rebuilds the WWW indexes (default), database indexes, or both for one or more lists. This command requires list owner privileges.
The wildcard * or the literal ALL is supported to mean "all lists". List owners will be able to rebuild indexes only for their own lists. LISTSERV maintainers may rebuild indexes for all lists on the server.
The available option is:
Notes: By default, web indexes will be rebuilt in the background on LISTSERV Classic HPO unless you specify the IMMEDIATE option. In additions, there is no background reindexing support for LISTSERV Classic non-HPO.
The main reason to use REINDEX is to retroactively add RSS abstracts to an existing list. It may also be useful if an archive file is edited by accident or if there is a corrupt file or the like. LISTSERV Classic non-HPO sites with one or more very large and active list(s) may also wish to run this command when upgrading to HPO.
On non-VM systems where there are no web indexes, normally there is no reason at all to rebuild your database indexes, other than in cases of disk corruption or in an upgrade to HPO coupled with the presence of a list with very large archives.
When rebuilding web indexes, BOTH the HTML files AND the INDxxxx files are reindexed. While there may be legitimate reasons for wanting to rebuild the HTML files (template changes, etc), it is NOT recommended to use the REINDEX command to accomplish that, as the overhead involved in rebuilding the INDxxxx files is prohibitive if they do not actually need rebuilding.
With LISTSERV Classic there is no background support, so REINDEX * should be scheduled for "quiet" periods if there are many lists and/or lists with large archives.
While a particular list has its indexes rebuilt, WA browsing accesses will generally fail and/or LISTSERV will throw "listname.html" not found errors. There is no good way to avoid that since the goal is to recreate the entire index structure from scratch, and during that process files will be deleted and not be available until they are rebuilt.
By default, database indexes are reset and will be rebuilt the next time they are needed; this is a fast operation. Under HPO, the IMMEDIATE option may be used to cause an immediate rebuild of all database indexes if absolutely necessary, but remember that the immediate rebuild will block the server from doing anything else until it completes. However, this can be a useful command when migrating an entire server or perhaps just a single list during off hours and it is desired to pre-index everything so that the server is snappy when traffic increases in the morning.
SET(*) listname options <FOR user>
Alter the subscription options for other users (wildcards are supported when setting options for another user or set of users).
Additional options for list owners:
NORENEW/RENEW – Waive subscription confirmation for this user.
NOPOST/POST – Prevent user from posting to list.
EDITor/NOEDITor – User may post without going through moderator.
REView/NOREView – Postings from user go to list owner or moderator even if user is otherwise allowed to post.
Stats listname (RESET
This command is only available on VM servers.
Resets (BITNET) statistics for the list.
UNLOCK listname
Unlock a list after a GET, if you decide not to update it after all, or unlock a list if it has been locked by another list owner or by the LISTSERV maintainer. Note that if you are not the person who originally locked the list, it is considered good practice to ask the person who originally locked the list whether or not they are done with the list before you unlock it.
14.3 LISTSERV Maintainer Commands
All LISTSERV maintainer commands require a password for validation when issued by email. Commands issued by TELL or SEND from the local host or via the LCMD utility do not require password validation. (Commands issued by LCMDX do require password validation. LCMDX, the LISTSERV TCPGUI demonstration program, is not the same as the LCMD utility shipped with LISTSERV.)
DEBUG FLAGS [update1 [update2 [...]]]
Each update has the format:
where 'flag' can be either the name of a debug flag or its corresponding hex value. A plus sign turns on the flag, minus turns it off, no sign sets the specified flag and clears all others. The command updates the session debug flags as requested, then displays a summary:
* Debug flags for this session: 00000022
* 00000001 TRACE_DIST [Trace DISTRIBUTE processing - OFF]
* 00000002 TRACE_MIME Trace MIME parser
* 00000004 TRACE_LISTS [Trace (a few) list-related functions - OFF]
* 00000008 TRACE_SPAM [Trace spam filter calls - OFF]
* 00000010 TRACE_EMM [Trace Embedded Mail-Merge processor - OFF]
* 00000020 TRACE_DEV Temporary ad hoc tracing for development use
* 00000040 TRACE_FSAV [Trace FSAV calls - OFF]
* 00000080 TRACE_LDAP_CALLS [Trace LDAP library calls - OFF]
* 00000100 TRACE_LDAP_DATA [Trace data obtained from LDAP - OFF]
* 08000000 HOLD_DISTBG [Do not process background DISTRIBUTE jobs - OFF]
* 10000000 HOLD_XB64 [Hold X-B64 jobs instead of processing them - OFF]
* 20000000 KEEP_JOBFILES [Keep successfully processed job files - OFF]
* 40000000 TRACE_TCPGUI [Additional TCPGUI tracing - OFF]
Flags that have not yet been assigned a function will display as RESERVED in the summary and do nothing. The TRACE_DEV flag is used by L-Soft Development to trace various aspects of whatever is being worked on at the time. While TRACE_DEV may be enabled by site maintainers (and in certain cases the support department may request that TRACE_DEV be enabled for debugging purposes), the results will vary depending on the build (and will not be publicly documented for that reason).
Any changes made using the DEBUG FLAGS command are for the current session only (they will be reset when LISTSERV is restarted). For certain purposes it can make sense to have some flags permanently turned on, and the DEBUG_FLAGS site configuration variable remains available for those special cases.
FOR user command
Execute a command on behalf of another user (LISTSERV maintainers only). Note that this command is provided for debugging purposes only -- it provides a method for a LISTSERV maintainer to send commands "from" the specified user. It is not recommended to use this command syntax in production, for instance to issue SET or SUBSCRIBE or UNSUBSCRIBE commands on a user's behalf. For instance, the LISTSERV maintainer should use, respectively, the "SET listname options FOR userid@host", "ADD listname userid@host", or "DELete listname userid@host" syntaxes in preference to the "FOR userid@host command" syntax.
Lists [option]
Global – All known lists, one line per list, sent as a (large!) file. Only LISTSERV maintainers may request this list, as it has become a favorite pastime of Internet mailbombers to issue LIST GLOBAL commands on behalf of users whose mailboxes they wish to bomb. You should direct users who request "the whole list of lists" to L-Soft's CataList service at
Additional options available for site maintainers are:
OWNED BY internet_address – Returns a list of local lists owned by the userid@host specified. Wildcards are acceptable.
MODerated BY internet_address – Returns a list of local lists moderated by the userid@host specified. Wildcards are acceptable.
Regenerate all LISTSERV network tables, or just compile the links weight file (debugging command). This happens automatically when LISTSERV is rebooted if a new BITEARN NODES file is found. Otherwise you should issue a NODESGEN whenever you update BITEARN NODES.
PUT listname LIST
Create a new list. Requires the CREATEPW for validation when issued from a remote node. You may specify initial subscribers, one per line, following the list header when creating a list. See also the PUTALL command in Section 14.2.2 List Management Functions.
PWC function
Password file management:
ADD user newpw – Define a password for the specified user.
DELete user – Delete password for that user.
Query user – Query the password of the specified user.
REGister name|OFF FOR user
Set or delete a user's SIGNUP FILE entry.
SERVE user OFF permanently suspends access from an abusive user or gateway (restore service with SERVE user).
Adding "DROP" (for example, SERVE user OFF DROP) to the command is identical to SERVE user OFF except that the postmaster will not receive any notification messages from LISTSERV when/if the user continues to try to post.
Issuing a SERVE LIST command causes LISTSERV to return a list of all users who are currently served off or who are spam-quarantined.
For instance,
Stop the server, and (optionally) restart it immediately (by specifying either REBOOT or REIPL -- the two options are synonymous). This is available on all platforms.
14.3.1 Commands for LISTSERV on VM Servers Only
CMS command_text
Issue a CMS command and get the last 20 lines of response sent back to you, the rest being available from the console log.
CP command_text
Issue a CP command and get up to 8k of response data sent to you (the rest is lost).
DATAbase function
Control operation of databases:
DISAble – Disable interactive database access, without shutting down existing sessions
ENAble – Re-enable interactive access
SHUTDOWN – Shut down all interactive database sessions, and disable interactive access
INSTALL function
Software update procedure (LISTSERV-NJE only):
CLEANUP shipment – Remove an installed shipment from the log
CLEANUP BEFORE dd mmm yy – Remove all shipments installed before that date
PASSWORD shipment PW=instpw – Confirm installation of a shipment, when requested by LISTSERV
RELOAD shipment – Attempt to reload a shipment which failed due to a disk full condition
STATus – Get a list of installed "shipments"
Suspend processing of reader files and disable the GET command
Cancel OFFLINE condition
PUTC fn ft <fm|cuu|dirid> <RECFM=F LRECL=nnn>
Update a CMS file on one of LISTSERV's R/W mini-disks; note that this is similar to SENDFILE + RECEIVE or LINK + COPYFILE and should NOT be used to update file-server files
SENDFile fn ft <fm|cuu|dirid>
Request the server to send you a file from one of its disks
SHOW <function>
In addition to the standard SHOW functions available on other servers, VM servers support the following functions:
BENCHmarks – CPU/disk/paging benchmarks.
EXECLoad – Statistics about EXECLOADed REXX files.
LSVFILER – Statistics about LSVFILER file cache.
PREXX – Statistics about PREXX functions usage.
STORage – Information about available disk space and virtual storage.
Note: Some debugging commands and options have been omitted.
14.4 Sending commands to LISTSERV
You will see numerous references to "sending commands to LISTSERV" in this and other L-Soft manuals. All LISTSERV commands are sent to the server either by email or via the web administration interface described in Section 6 Introduction to the Web Interface. 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.
14.5 Defining Personal Passwords
The passwords recognized by LISTSERV for various operations (assuming that the NOPW parameter is not used with the "Validate=" keyword) are of two distinct types:
Personal Passwords – LISTSERV can store a personal password in its signup files corresponding to your userid. This password not only can be used for list maintenance operations, but also protects your FUI (file update information) and AFD (automatic file distribution) subscriptions (if available on your server) and must be used to store your archive files, if any, on the server.
List Passwords – List passwords are technically obsolete except in one particular case (peered lists, which require each peer to have the same password). We mention them here only because users upgrading from earlier versions will be aware of their existence. You should define and use a personal password for all protected operations.
To add a personal password, send mail to LISTSERV with the command
PW ADD newpassword
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
PW CHANGE newpassword [PW=oldpassword]
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.

L-Soft international, Inc.