| 1 | .TH ezmlm-request 1 |
| 2 | .SH NAME |
| 3 | ezmlm-request \- Process subject line and body ezmlm commands |
| 4 | .SH SYNOPSIS |
| 5 | .B ezmlm-request |
| 6 | [ |
| 7 | .B \-f\fI config |
| 8 | ] |
| 9 | .I dir |
| 10 | .SH DESCRIPTION |
| 11 | .B ezmlm-request |
| 12 | processes ezmlm commands in the subject line or message body. |
| 13 | .B ezmlm-request |
| 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 |
| 18 | space. |
| 19 | .B ezmlm-request |
| 20 | uses the text to construct a ezmlm command message to the list. |
| 21 | If the subject does not start with a letter, |
| 22 | .B ezmlm-request |
| 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. |
| 25 | |
| 26 | All commands are expected to be in ezmlm command address format or formatted |
| 27 | as: |
| 28 | |
| 29 | .EX |
| 30 | .BR command [list@listhost [user@userhost]] |
| 31 | .EE |
| 32 | |
| 33 | .B ezmlm-request |
| 34 | when invoked with the |
| 35 | .B \-f |
| 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 |
| 39 | .B lists |
| 40 | and |
| 41 | .B which |
| 42 | commands. This can be used |
| 43 | to construct a global list interface, similar to that used by some other |
| 44 | mailing list managers. |
| 45 | |
| 46 | Messages at the |
| 47 | .I list\fB\-request\fI@host |
| 48 | are restricted to the local list. When |
| 49 | .B ezmlm-request |
| 50 | is invoked with the |
| 51 | .B \-f\fI config |
| 52 | switch, command messages are limited to lists in |
| 53 | .I config |
| 54 | or at the local host. |
| 55 | |
| 56 | Invalid requests for an existing ezmlm list will |
| 57 | lead to a ``help'' message from |
| 58 | .BR ezmlm-manage(1) . |
| 59 | .SH OPTIONS |
| 60 | .TP |
| 61 | .B \-f\fI config |
| 62 | Function as a global interface to ezmlm lists in accordance with |
| 63 | .IR config. |
| 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''. |
| 71 | If ``listdir'' is |
| 72 | present, the |
| 73 | .B which |
| 74 | command attempts to determine if the user is a subscriber of the list. |
| 75 | .B NOTE: |
| 76 | this will work only if the user running |
| 77 | .B ezmlm-request |
| 78 | has read access to the lists subscriber database. |
| 79 | |
| 80 | If ``listhost'' is not specified, |
| 81 | .B ezmlm-request |
| 82 | will use the ``listhost'' from the first |
| 83 | .I config |
| 84 | entry matching ``listlocal''. If ``listhost'' is specified, but not found |
| 85 | in |
| 86 | .IR config , |
| 87 | it is set to the contents of |
| 88 | .IR dir\fB/outhost . |
| 89 | .SH USAGE |
| 90 | Place an invocation of |
| 91 | .B ezmlm-request |
| 92 | in |
| 93 | .I dir\fB/manager |
| 94 | anywhere before the |
| 95 | .B ezmlm-manage(1) |
| 96 | line. |
| 97 | |
| 98 | Alternatively, set up |
| 99 | .I dir\fB/request |
| 100 | with an invocation of |
| 101 | .BR ezmlm-request . |
| 102 | Make a link from |
| 103 | .I ~/.qmail-list-request |
| 104 | to this file. |
| 105 | |
| 106 | For the global interface, place |
| 107 | .B /path/ezmlm-request -f \fIconfig dir |
| 108 | into a file. |
| 109 | Link |
| 110 | .I ~/.qmail-ezmlm |
| 111 | and |
| 112 | .I ~/.qmail-ezmlm-default |
| 113 | to this file. The latter allows |
| 114 | .B ezmlm-request |
| 115 | to handle its own bounces as well as to reply to messages to e.g. |
| 116 | \``user-ezmlm-lists@listhost''. |
| 117 | Create |
| 118 | .IR dir\fB/inlocal |
| 119 | and |
| 120 | .IR dir\fB/outlocal |
| 121 | with ``user-ezmlm'', |
| 122 | .IR dir\fB/outhost |
| 123 | with ``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 , |
| 128 | and |
| 129 | .I dir/text\fB/bottom |
| 130 | with the appropriate texts. |
| 131 | Also, create |
| 132 | .I config |
| 133 | with the appropriate contents. |
| 134 | |
| 135 | Mail to ``user-ezmlm@listhost'' will now be answered by |
| 136 | .BR ezmlm-request . |
| 137 | .SH "RECOGNIZED COMMANDS" |
| 138 | Any command not recognized by |
| 139 | .B ezmlm-request |
| 140 | is assumed to be valid, as long as it consists of only letters, numbers, |
| 141 | hyphen, underscore, period, and ``+''. This allows |
| 142 | .B ezmlm-request |
| 143 | to correctly handle commands added by the list owner. |
| 144 | |
| 145 | A number of commands are recognized by |
| 146 | .B ezmlm-request |
| 147 | but not processed. Instead they are mapped to |
| 148 | .B help |
| 149 | without arguments. These |
| 150 | are: |
| 151 | .BR system , |
| 152 | .BR put , |
| 153 | and |
| 154 | .BR set . |
| 155 | |
| 156 | .B ezmlm-request |
| 157 | also handles a number of aliases for ezmlm commands. Since |
| 158 | .B ezmlm-request |
| 159 | only passes on requests to the list, local restrictions apply. |
| 160 | For commands that have aliases, accepted aliases are listed: |
| 161 | .TP |
| 162 | .B subscribe |
| 163 | sub |
| 164 | .TP |
| 165 | .B unsubscribe |
| 166 | unsub, signoff, remove. |
| 167 | .TP |
| 168 | .B index |
| 169 | ind. |
| 170 | .TP |
| 171 | .B list |
| 172 | recipients, showdist, review, rev, who. |
| 173 | .TP |
| 174 | |
| 175 | Some commands are handled differently when used without arguments: |
| 176 | .TP |
| 177 | .B query |
| 178 | Treated like ``which''. |
| 179 | .TP |
| 180 | .B list |
| 181 | Treated like ``lists''. |
| 182 | .SH BUGS |
| 183 | .B ezmlm-request |
| 184 | places stricter requirements on addresses than rfc822. Thus, some addresses |
| 185 | that are rfc822-compliant cannot be used as |
| 186 | .B ezmlm-request |
| 187 | command arguments. If you fix this, |
| 188 | please send a patch to lindberg@id.wustl.edu. I think qmail has the same |
| 189 | restriction, though. |
| 190 | |
| 191 | .B ezmlm-request |
| 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. |
| 195 | |
| 196 | The |
| 197 | .B ezmlm-request |
| 198 | \``which'' |
| 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. |
| 202 | .SH BUGS |
| 203 | .B ezmlm-request |
| 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 |
| 208 | assumptions. |
| 209 | .B ezmlm-request |
| 210 | in the global interface role |
| 211 | will fail if this first part or the entire message is base64 encoded. |
| 212 | .SH "SEE ALSO" |
| 213 | ezmlm-get(1), |
| 214 | ezmlm-manage(1), |
| 215 | ezmlm-send(1), |
| 216 | ezmlm(5) |