Function as a global interface to ezmlm lists in accordance with
config. This file consists of lines starting in the first position
with list@host:listdir:description. Lines that are blank or start
with # are ignored. listdir and description are optional. If only list@host is given, the list is used to restrict commands (see below), but not listed. To allow the list to be shown by a list command, use list@host:. To specify only the list name and description, use list@host::description. If listdir is present, the which command attempts to determine if the user is a subscriber of the list. NOTE: this will work only if the user running ezmlm-request has read access to the lists subscriber database.
If listhost is not specified, ezmlm-request will use the listhost from the first config entry matching listlocal. If listhost is specified, but not found in config, it is set to the contents of dir/outhost.
Place an invocation of ezmlm-request in dir/manager anywhere before the ezmlm-manage(1) line.
Alternatively, set up dir/request with an invocation of ezmlm-request. Make a link from ~/.qmail-list-request to this file.
For the global interface, place /path/ezmlm-request -f config dir into a file. Link ~/.qmail-ezmlm and ~/.qmail-ezmlm-default to this file. The latter allows ezmlm-request to handle its own bounces as well as to reply to messages to e.g. `user-ezmlm-lists@listhost. Create dir/outlocal with user-ezmlm, dir/outhost with listhost, dir/headerkeep with headers to keep or dir/headerremove with headers to be stripped (copy from a list), dir/text/help, dir/text/top, and dir/text/bottom with the appropriate texts. Also, create config with the appropriate contents.
Mail to user-ezmlm@listhost will now be answered by ezmlm-request.
Any command not recognized by ezmlm-request is assumed to be valid, as long as it consists of only letters, numbers, hyphen, underscore, period, and +. This allows ezmlm-request to correctly handle commands added by the list owner.
A number of commands are recognized by ezmlm-request but not processed. Instead they are mapped to help without arguments. These are: system, put, and set.
ezmlm-request also handles a number of aliases for ezmlm commands. Since ezmlm-request only passes on requests to the list, local restrictions apply. For commands that have aliases, accepted aliases are listed:
subscribe sub unsubscribe unsub, signoff, remove. index ind. list recipients, showdist, review, rev, who.
Some commands are handled differently when used without arguments: query Treated like which. list Treated like lists.
ezmlm-request places stricter requirements on addresses than rfc822. Thus, some addresses that are rfc822-compliant cannot be used as ezmlm-request command arguments. If you fix this, please send a patch to firstname.lastname@example.org. I think qmail has the same restriction, though.
ezmlm-request uses NUL as a line terminator internally. Thus, if will fail if NUL is found within the line it tries to interpret as a command. It is harmless, other than that the remainder of the line will be ignored.
The ezmlm-request `which command does not differentiate between a list for which the command is not available, a list for which the subscriber db is not accessible, and a list for which the address is not a subscriber. This should be considered a feature.
ezmlm-request when used as a global interface and receiving multipart messages assumes that the first line of the fist part is the command. Further, it assumes that the first line starting-- is the first MIME boundary. This is virtually always true, but it is easy to construct legal messages that do not fit these assumptions. ezmlm-request in the global interface role will fail if this first part or the entire message is base64 encoded.