3 ezmlm-request \- Process subject line and body ezmlm commands
12 processes ezmlm commands in the subject line or message body.
14 enables these uses to send the message to
15 .I list\fB\-request\fI@host
16 with the complete command address line in the subject field,
17 or with commands and arguments separated by white
20 uses the text to construct a ezmlm command message to the list.
21 If the subject does not start with a letter,
23 instead uses the first body line that starts with a letter. Processing
24 terminates if a line with a hyphen in the first position is encountered.
26 All commands are expected to be in ezmlm command address format or formatted
30 .BR command [list@listhost [user@userhost]]
36 switch and a configuration file (see below), ignores the subject and processes
37 the first body line (per rules above) in conjunction with the configuration
38 file. It also services the
42 commands. This can be used
43 to construct a global list interface, similar to that used by some other
44 mailing list managers.
47 .I list\fB\-request\fI@host
48 are restricted to the local list. When
52 switch, command messages are limited to lists in
56 Invalid requests for an existing ezmlm list will
57 lead to a ``help'' message from
62 Function as a global interface to ezmlm lists in accordance with
64 This file consists of lines starting in the first position
65 with ``list@host:listdir:description''. Lines that are blank or start
66 with ``#'' are ignored. ``listdir''
67 and ``description'' are optional. If only ``list@host'' is given, the list
68 is used to restrict commands (see below), but not listed. To allow the list
69 to be shown by a ``list'' command, use ``list@host:''. To specify only
70 the list name and description, use ``list@host::description''.
74 command attempts to determine if the user is a subscriber of the list.
76 this will work only if the user running
78 has read access to the lists subscriber database.
80 If ``listhost'' is not specified,
82 will use the ``listhost'' from the first
84 entry matching ``listlocal''. If ``listhost'' is specified, but not found
87 it is set to the contents of
90 Place an invocation of
100 with an invocation of
103 .I ~/.qmail-list-request
106 For the global interface, place
107 .B /path/ezmlm-request -f \fIconfig dir
112 .I ~/.qmail-ezmlm-default
113 to this file. The latter allows
115 to handle its own bounces as well as to reply to messages to e.g.
116 \``user-ezmlm-lists@listhost''.
124 .IR dir\fB/headerremove
125 with headers to be stripped (copy from a list),
126 .IR dir/text\fB/help ,
127 .IR dir/text\fB/top ,
129 .I dir/text\fB/bottom
130 with the appropriate texts.
133 with the appropriate contents.
135 Mail to ``user-ezmlm@listhost'' will now be answered by
137 .SH "RECOGNIZED COMMANDS"
138 Any command not recognized by
140 is assumed to be valid, as long as it consists of only letters, numbers,
141 hyphen, underscore, period, and ``+''. This allows
143 to correctly handle commands added by the list owner.
145 A number of commands are recognized by
147 but not processed. Instead they are mapped to
149 without arguments. These
157 also handles a number of aliases for ezmlm commands. Since
159 only passes on requests to the list, local restrictions apply.
160 For commands that have aliases, accepted aliases are listed:
166 unsub, signoff, remove.
172 recipients, showdist, review, rev, who.
175 Some commands are handled differently when used without arguments:
178 Treated like ``which''.
181 Treated like ``lists''.
184 places stricter requirements on addresses than rfc822. Thus, some addresses
185 that are rfc822-compliant cannot be used as
187 command arguments. If you fix this,
188 please send a patch to lindberg@id.wustl.edu. I think qmail has the same
192 uses NUL as a line terminator internally. Thus, if will fail if NUL is found
193 within the line it tries to interpret as a command. It is harmless, other than
194 that the remainder of the line will be ignored.
199 command does not differentiate between a list for which the command is not
200 available, a list for which the subscriber db is not accessible, and a list
201 for which the address is not a subscriber. This should be considered a feature.
204 when used as a global interface and receiving multipart messages assumes that
205 the first line of the fist part is the command. Further, it assumes that the
206 first line starting``--'' is the first MIME boundary. This is virtually
207 always true, but it is easy to construct legal messages that do not fit these
210 in the global interface role
211 will fail if this first part or the entire message is base64 encoded.