listproc(1) USER COMMANDS listproc(1) NAME listproc - process requests sent to the ListProcessor request handler SYNOPSIS listproc [-1] [-e] [-i] [-n] {[-a ]}* {[- r ]}* {[-d ]}* {[-b ]}* [-B] [-D] DESCRIPTION listproc processes user requests sent to listproc@your- domain, forwards requests about known remote lists, and processes list-owner administrative requests (see also the LIST OWNERS section below). Each request should appear in a separate line with any possible arguments. The file ".ignored" is used in the system's home directory to filter out unwanted senders. If the system is not instructed to ignore invalid requests (see the CONFIG section in server(1)), the sender is notified of the first invalid request; all subsequent requests are ignored. For each suc- cessfully completed request, a confirmation is sent back to the sender. listproc stops reading requests when it encounters the string "--" in a line by itself, which on most systems sig- nifies the start of the .signature message, or at the first occurence of a thankful request. listproc reads the config file (see server(1)). Subscriptions may be manager-approved (private lists), files and archive indices may be password protected (private archives), and requests may be placed in a batch queue. A single request may span multiple lines if each part ends with &\n. USER REQUESTS The following user requests are recognized (requests may be abbreviated): help [topic] Send a help message on all valid requests or the selected topic (possibly a request) only. set list [option arg(s)] Without the optional arguments, return the current values for all options set for list; otherwise, set subscriber preferences for list. option can be: mail: set mail preferences. arg has to be one of the following: Anastasios Kotsikonas 1 listproc(1) USER COMMANDS listproc(1) ack: send a copy of the current message to the original sender. noack: do not send a copy of the current message to the original sender. This is the default for newly subscribed users. postpone: do not send any messages to the partic- ular subscriber until he changes status again. digest: do not send individual messages to the particular subscriber. Instead, store messages in a digest and send it when the digest exceeds a specified number of lines, or when a specified amount of time has passed since the last digest was sent. If the mail mode is changed from digest to any- thing else, all messages currently stored for the next digest will be sent to the subscriber at once, in digest format. password: change the password (used to establish sub- scriber privileges when connecting to ListProcessor for a "live" session and for the option below). args must be: old-password new-password. address: set the address the user is subscribed with (if allowed for this list). args must be: current-password new-address. conceal: set the user's visibility. arg must be one of the following: yes: the user is not listed in recipients and statistics requests. no: the user's email address and name are made public. subscribe list full_name Subscribe the sender to list (note, his email address is used for subscription, not his full_name). A pass- word is assigned by the system at that time and is included in the reply message to the new subscriber. The password is to be used when connecting to the interactive part of the system for identification pur- poses, and for changing the subscription address if allowed for this list. Anastasios Kotsikonas 2 listproc(1) USER COMMANDS listproc(1) which Get a list of local mailing lists to which the sender has subscribed. unsubscribe list Remove the sender from the specified list. signoff list Alias of the unsubscribe request. recipients list Get a list of all subscribers of list. The request is also forwarded to all peer lists, and the servers han- dling them will respond accordingly. The user is noti- fied when this request is being forwarded. If a list is private, only members may issue this request. review list Alias of the recipients request. information list Get information about a particular list. statistics list {[subscriber email address(es)] | [-all]} Obtain a count of messages sent per subscriber to the specified list, or by those subscribers given as argu- ment only (wild characters are supported). If -all is specified, then statistics are compiled for all users (currently subscribed or not) who have posted to the list in the past. The request is also forwarded to all peer lists and the servers handling them will respond accordingly. The user is notified when this request is being forwarded. If a list is private, only members may issue this request. run list [password cmd [args]] Without the optional arguments, just list all commands that may be executed by subscribers of this list. Oth- erwise, run cmd with the optional args, if the correct password is provided. The reply will contain the output from stdout and/or stderr. lists Obtain a list of mailing list addresses that are ser- viced by this system, with a small description of their purpose. If remote lists (see below) are also defined, their addresses and descriptive messages will also be included. index [archive | path-to-archive] [/password] [-all] Obtain an index of files in the specified archive (or the master archive if none specified) and all of its Anastasios Kotsikonas 3 listproc(1) USER COMMANDS listproc(1) subarchives if the the -all option is specified. Cer- tain archives may be private, and these require a /password to be able to obtain their indices. Archives on different places in the hierarchy may have the same names and they can be distinguished by specifying paths to them; path-to-archive has the form archive[/archive[/archive...]]. index requests always report the paths to the archives they list. get file [/password] [parts] Get the specified file from the archive given. The file may have been split into smaller parts due to its size, in which case each part will be sent in a different email message. If only certain parts are desired, they may be given as arguments (numbers, separated by spaces -- ranges are not recognized). Certain archives may be private, in which case their /password has to be pro- vided in order to get the desired files. Archives on different places in the hierarchy may have the same names and they can be distinguished by specifying paths to them; path-to-archive has the form archive[/archive[/archive...]]. If the file is pure binary, it will be uuencoded first. search [/password] [-all] Search all files in the specified archive (and all of its subarchives if -all) and return lines that match the pattern. The pattern can be an extended regular expression with egrep(1)-style syntax, with support for the following additional operators: '~', if leading the regular expression it reverses its meaning; '|' and '&' separate multiple regular expressions (logical OR and AND); '<' '>' group regular expressions (we preserve the meaning of the parentheses from ed(1), and remove the meaning of < and > from ed(1) since in the ListPro- cessor context they are either the default, or inap- propriate). These can be used literally by escaping them with '\'. In addition, the following characters should be defined in matched pairs: (), <>, []. pattern may be enclosed in single or double quotes. Pattern matching is case insensitive. fax file [/password] [parts] Same as the get request except that the files are faxed to the specified number. release Get information about the current release of this server system. Anastasios Kotsikonas 4 listproc(1) USER COMMANDS listproc(1) execute password #command [arguments] Intended for the system's manager, this will execute the command with the optional arguments and send the output (if any) from stdout and/or stderr to the sender. See the sample config file for password defini- tion. For a list of the list administration requests that may be issued by list owners, see the LIST OWNERS section below. OPTIONS The following command line options are recognized: -1 Execute only once; process any requests and return con- trol to serverd(1); any new messages that may have arrived in the meantime will be processed at a later time. Without this option, listproc will be listening for requests for ever. serverd(1) uses this option by default when spawning listerv. -e Echo reports to the screen; it has no effect if the system has been compiled with -DSYSLOG. -i Go to interactive mode -- messages by listproc are not mailed out but instead serverd(1) reads them during its interactive session. Do not use this option in the con- fig file (see server(1)). -n By default, peer servers are notified upon statistics and recipients requests. The system uses a protocol for avoiding loops as described in server(1). If you detect loops with other servers, you should use this option to turn off notification of peer servers. -a LIST_ALIAS Usually, subscriptions are automatic. This option turns off automatic subscription to the specified list (LIST_ALIAS should be in capital letters), and makes this list private (members only may issue recipients and statistics requests). The sender is notified of this effect, and a message is sent to the list's owner requesting his/her approval, with instructions for placing the subscription. Notice that the specified list has to be defined beforehand via a list directive in the config file. This option may be repeated any number of times. -c LIST_ALIAS Conceal LIST_ALIAS from lists requests. -r request Place a restriction on the specified server request as Anastasios Kotsikonas 5 listproc(1) USER COMMANDS listproc(1) outlined above. If the number of users on the system at the time the request is about to be processed is above the limit given in the config file (using the restriction directive), the request is rejected -- meant for requests that may take a considerable amount of resources such as the statistics request -- this option may be repeated any number of times. List administration requests are not subject to these res- trictions (see later on). -d request Disable request, i.e. make it totally unknown to the server -- this supersedes any disable directives for this request in the config file, i.e. this request will not be recognized for any list (see server(1)). How- ever, help is still available for that request. List administration requests are also subject to these res- trictions (see later on). This option may be repeated any number of times. -b request All such requests will be batch-processed if they arrive between the hours specified in the config file. This option may be repeated any number of times. -B Process the batch queue. This is done automatically by serverd(1) after midnight every day, or when the system is restarted, so no further action needs to be taken. Caution: do not place this option in the definition of server in the config file. If you do so, only the batch queue will be processed (no new requests will be pro- cessed, ever). The batch queue is processed once a day only, unless the system is restarted repeatedly. -D Turns debugging on. When the system mailmethod is used, a copy of the last SMTP transaction can be found in the files HOMEDIR/sent and HOMEDIR/received. PEER SERVERS The system supports the notion of remote lists. A ListPro- cessor may know of remote lists served by remote servers. Yet users may send requests about these remote lists to this server, which will in turn forward them to the remote servers. The user is notified when a list is not local and his/her request is about to be forwarded. A lists request will tell the user which remote lists are known to this server. Remote lists should be made known to this server only if they are served by a server of version 5.31 or higher. This restriction is posed because of incompatible requests across various list management systems. See the discussion about Anastasios Kotsikonas 6 listproc(1) USER COMMANDS listproc(1) the config file for setting up remote lists. In addition, recipients and statistics requests are for- warded to the servers handling peer lists (the -n flag to listproc turns this feature off). LIST OWNERS List owners are individuals responsible for list administra- tion via mail requests. Thus, list owners may be remotely located. Each list has to have at least one list owner. These owners may be different than the system's manager, and have special privileges: they may issue requests on users' behalf (add a user, remove a user, etc.) overriding system restrictions set on regular users (these include disabled commands as described above), obtain reports about the lists they administer, append to the ".aliases" and ".ignored" files, change the welcoming (".welcome") and informative (".info") messages, as well as other system files such as the aliases file (".aliases"), the ".ignored" file, the sub- scribers file (".subscribers"), the news file (".news") and the peers file (".peers"). In addition, they may moderate their lists and they receive various error messages pertain- ing to their lists. All administrative requests are author authenticated and password protected. Whenever a message cannot be author authenticated, the list's owner and manager are notified. On the other hand, list owners may not add restricted users; this service can be provided by contacting the system's manager. List owners may also receive copies of user requests and/or error messages such as invalid postings, syntax errors on requests, etc. These options are described in the following sections. Defining list owners Once a new mailing list is defined in the config file, the list's owner address and access password are pro- vided to the list directive. Of course, this password should be made known to the owner; it will be needed for all administrative requests. Next, the owner's address has to be registered in HOMEDIR/owners; the manager simply edits this file adding the owner's address along with the list's name (alias) he is assigned to, followed by any preferences (see below). Multiple owners for a list may be defined by adding their addresses to this file, and providing them with the list's password. However, only the primary owner's address (as defined by the list directive) will be used as reference in correspondence and for system-error notifications, and only the primary owner will be Anastasios Kotsikonas 7 listproc(1) USER COMMANDS listproc(1) forwarded messages from his moderated list for appro- val. The manager should also add his address (login name) to this file. Owner preferences The primary owner may wish to be copied on certain replies to user requests (such as subscribe), on error conditions (rejected postings, invalid requests, etc.), or on all cases. These preferences are listed in the owners file on the line his address and list are defined. Valid preferences are: CCSET: copy on set requests. CCSUBSCRIBE: copy on subscribe requests. CCUNSUBSCRIBE: copy on unsubscribe requests. CCRECIPIENTS: copy on recipients requests. CCINFORMATION: copy on information requests. CCSTATISTICS: copy on statistics requests. CCRUN: copy on run requests. CCPRIVATE: copy on requests rejected because they are open only to the list's members. CCERRORS: copy on various error conditions. CCALL: all of the above. Owner preferences are optional. The manager may define preferences for himself as well by using the keyword server in place of a list alias. However, such preferences make sense only in the following cases: CCGET: copy on get requests. CCINDEX: copy on index requests. CCLISTS: copy on lists requests. CCRELEASE: copy on release requests. CCHELP: copy on help requests. CCERRORS: copy on various error conditions. CCALL: all of the above. Anastasios Kotsikonas 8 listproc(1) USER COMMANDS listproc(1) Manager preferences are optional. Owner privileges Whenever an owner issues a user request on a user's behalf (see below), all restrictions, including dis- abled commands, do not apply. All other administrative requests are subject to restrictions set by the manager. All requests (user and administrative) are subject to batch-processing. Administrative requests The following requests may be issued by a list's owner: system list password user-address #user-request This request overrides all system restrictions and exe- cutes user-request on behalf of user-address; this address has to appear as listed in the ".subscribers" file, where applicable. The most frequent use of the system request is to subscribe a user to a private list. For example: system herc herc1 john@foo #subscribe herc Some Name If a user-request refers to a list, this list has to be list, so that a list's owner may not have privileges over another list's affairs. Note that all replies about user-request are forwarded to user-address, not the owner; therefore, care has to be taken to avoid syntax errors. The system request is not subject to restrictions, disabled requests, and private list sub- scription verification (it is still subject to private list review as outlined above, and batching). To remove a member from his list, the owner may issue the follow- ing request: system herc herc1 john@foo #unsubscribe herc To bypass restrictions and review his list, the owner may issue the following: system venus venus1 his-address #review venus In general, user-request may be any of the recognized user requests described under listproc. The pound sign is mandatory. There is no help available to users for this request for security reasons. approve list password tag Whenever a new message arrives for a moderated list a copy is sent to the list's owner soliciting his appro- val -- proper instructions for approving or discarding a message are included. This request approves the Anastasios Kotsikonas 9 listproc(1) USER COMMANDS listproc(1) message identified by the tag number for posting to list. The tag number is provided to the list's owner by listproc and is unique. discard list password tag In contrast to the above request, this discards the message identified by tag. Messages that are not approved or discarded remain in the list's moderated file (see list(1)). reports list password Obtain all reports pertinent to list; this will send two mail messages: one with the current report (HOMEDIR/lists/ALIAS/.report.list), and one with the previously archived ones (HOMEDIR/lists/ALIAS/.rep.list.acc); see the REPORTS section below. Once the ".rep.list.acc" file is sent, it is shrunk in size, therefore the owner should make sure he keeps the copy he receives. This request has no effect if the system is using sys- log(3) to generate reports. edit list password file Obtain the specified file for editing; candidate files are: aliases: obtain the list's aliases file. ignored: obtain the list's list of unwelcome addresses. info: obtain the list's informative message. subscribers: obtain the list's subscribers list. welcome: obtain the list's welcoming message. news: obtain the list's list of newsgroup connec- tions. peers: obtain the list's peers. put list password keyword [args] This enables the list's owner to append to the ".aliases" and ".ignored" files, and replace his list's ".welcome", ".info", ".aliases", ".ignored", ".sub- scribers", ".news" and ".peers" files, depending on the keyword. Valid keywords are: alias: Add a user address alias to the list's and system's ".aliases" files (see .ALIASES below). This Anastasios Kotsikonas 10 listproc(1) USER COMMANDS listproc(1) requires the new address and the address used for subscription as arguments: put alias For example: put venus venus1 alias foo!john john@foo ignore: Add a user address to the list's ".ignore" file only. Of course this address has to be provided as argument: put ignore For example: put ermis ermis1 ignore jack@foo put ermis ermis1 ignore foo!jack welcome, info, aliases, ignored, subscribers, news, peers: Create a new system file. For example: put subscribers tasos ACK PASSWORD NO Tasos Kotsikonas john NOACK PASS1 NO John Doe No arguments are needed. The text that is to go to the corresponding file starts at the line following this request and spans till the end of the mail mes- sage. Thus, no more requests can be made in the same mail message -- they are treated as regular text; signature lines also signify the end of text, pro- vided they start with "--" in a single line. A confirmation is sent to the owner once a put request is successfully processed. OWNERS The format of the owners file is as follows: One entry per line; each entry is the full email address of a list's owner, followed by the list alias he owns, followed Anastasios Kotsikonas 11 listproc(1) USER COMMANDS listproc(1) by any optional preferences. If the keyword server is speci- fied in place of the list alias, then preferences are defined for the manager. SEE ALSO catmail(1), farch(1), list(1), queue(1), server(1), ser- verd(1), start(1) AUTHOR Anastasios C. Kotsikonas Copyright (c) 1991-93, Anastasios Kotsikonas Comments to tasos@cs.bu.edu Anastasios Kotsikonas 12