Section 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 parameter has the format:
<+|->flag
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. For instance,
DEBUG FLAGS +TRACE_MIME +TRACE_DEV -20000000
The command updates the session debug flags as requested, then displays a summary:
* Debug flags for this session: 00000022 |
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.
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.
LISTSERV maintainers have a few additional options for the Lists command.
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 http://www.lsoft.com/catalist.html. |
|
Additional local management 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.
Create a new list. Requires the LISTSERV maintainer's personal LISTSERV password for authentication. You may specify initial subscribers, one per line, following the list header when creating a list. See also the PUTALL command in the Site Manager’s Manual for LISTSERV.
LISTSERV's CREATEPW is required for validation of this command when it is issued from a remote node. It is unlikely that this will happen today as this tended to be a function restricted to z/VM servers running on BITNET, and we recommend that CREATEPW on a modern LISTSERV server be set to the special value *NOPW* to disable it.
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 |
|
Note: The PWC QUERY function does not actually return the password under LISTSERV 15.5 or later unless SIGNUP_ENCRYPT_PASSWORDS is set to 0 (and the user created their password after that). Instead, LISTSERV simply acknowledges that the user has set a password, for instance, john@EXAMPLE.COM has been assigned a password by John Doe <john@EXAMPLE.COM> on Tue, 12 Mar 2019. Disabling password encryption is NOT RECOMMENDED. If a user has forgotten his or her password, they should simply issue the PW REP command with a new password. |
REGister <name | OFF | QUERY> FOR user
Set or delete the "real name" associated with a user’s SIGNUP FILE entry.
Or, in LISTSERV 16.5 or later, query the signup database to see what name is registered for a given user.
|
Note: This command should ALWAYS be used in preference to editing or viewing the SIGNUP files by hand. The SIGNUP files are not plain text and are not meant to be edited or viewed manually. |
|
Documented Restriction: The QUERY subcommand is available only in LISTSERV 16.5 and later, and may be used to query a single user's registration status. It is not intended to be used, for instance, to produce a list of all registered LISTSERV users and their "real name" fields. For instance, Wildcards in the target address are meaninful only with REGISTER OFF. That is, while "REGISTER OFF FOR *@XYZ" is a valid command, the meaning of a command like "REGISTER John Doe FOR *@XYZ" is difficult to define. As implied, this error is thrown for any attempt to perform REGISTER QUERY for a wildcarded address. |
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,
> serve list JOE@EXAMPLE.COM DROP 2003-08-20 15:51:20 by nathan@EXAMPLE.COM FOOBAR@EXAMPLE.EDU HARD 2003-04-07 14:55:29 by NATHAN@EXAMPLE.COM BLAB@FOO.EXAMPLE.COM SOFT 2004-09-14 10:53:18 SPAMMER@SPAMDOMAIN.COM SPAM 2003-08-20 15:50:55 4 matching entries. |
(LISTSERV HPO 16.5 and following)
SHOW DOWNTIME invokes a built-in downtime monitor. LISTSERV basically keeps track of when it is up, and LISTSERV maintainers can use this privileged command to see when it was down and how good its uptime has been a particular month (or over a period of several months). The command syntax is:
SHOW DOWNtime [yyyymm1[-[yyyymm2]]]
Given a hypothetical command like
SHOW DOWNTIME 201801-201804
the output looks like this:
Downtime started Downtime ended Duration
---------------- -------------- --------
2018-01-17 20:03 2018-01-17 20:06 4 min
2018-01-17 20:13 2018-01-17 20:13 1 min
2018-03-15 03:06 2018-03-15 03:06 1 min
2018-03-15 03:08 2018-03-15 03:09 2 min
2018-04-12 03:06 2018-04-12 03:06 1 min
2018-04-16 20:01 2018-04-16 20:06 6 min
2018-04-16 20:32 2018-04-16 20:33 2 min
2018-04-16 21:07 2018-04-16 21:08 2 min
2018-04-16 22:18 2018-04-16 22:28 11 min
--------
30 min (99.982% uptime)
If there is no downtime in the specified period, LISTSERV simply responds,
There was no downtime in the specified range.
The first time LISTSERV is started, it assumes that there has been no downtime to date in the current month, simply because it is a binary state with no "don't know" option. From that point on, it assumes that every future time period is a downtime period unless marked otherwise as time progresses. DST will cause a false positive when jumping forward by one hour, and will only see 1h of downtime if you are down for 2h during the backward jump.
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.
|
Note: This command restarts LISTSERV only. It does not reboot the machine on which LISTSERV is running. Under Windows, it also does not restart the SMTPL.EXE "listener", which may be required if configuration changes are made which affect SMTPL. |
Same as SHUTDOWN.