/usr/share/doc/mailfront/mailrules.html is in mailfront 1.16-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 | <html>
<body>
<h2><a href="mailfront.html">MailFront</a></h2>
<h2><a href="smtpfront.html">SMTP Front Ends</a></h2>
<h1>Mail Rules Specification</h1>
<hr>
<h2>Selection</h2>
<p>The use of mail rules is controlled by the environment variable
<tt>$MAILRULES</tt>. This variable specifies the path to the mail rules
file. If <tt>$MAILRULES</tt> is set but the path that it points to
cannot be opened, processing will fail with a temporary error. There is
no default value -- if it is not set, mail rules processing is
disabled.</p>
<p>The rules listed are applied <i>before</i> any other sender or
recipient processing is done (such as checking against qmail's
badmailfrom file).</p>
<h2>Syntax</h2>
<p>Each rule in the file occupies a single line. Blank lines and lines
starting with "<tt>#</tt>" are ignored as comments.</p>
<h3>Selector Lines</h3>
<p>Selector lines specify when the following rules are to be applied. A
selector line starts with a colon ("<tt>:</tt>"). The following
selectors are defined:<dl>
<dt><tt>:sender</tt> <dd>Apply the following rules only to senders. Any
recipient pattern present in the rule is ignored.
<dt><tt>:recipient</tt> <dd>Apply the following rules only to
recipients.
</dl> Rules that precede a selector are categorized as follows (for
compatibility with existing rules:<ul>
<li>If the rule has a recipient pattern of "<tt>*</tt>" (which matches
everything), it will be applied as a sender only rule.
<li>All other rules are applied as recipient rules.
</ul></p>
<h3>Rule Lines</h3>
<p>Each rule line starts with one of the following prefixes: <dl>
<dt><tt>k</tt> <dd>Accept the sender or recipient.
<dt><tt>z</tt> <dd>Reject the sender or recipient with a temporary error
code.
<dt><tt>d</tt> <dd>Reject the sender or recipient with a permanent error
code.
<dt><tt>n</tt> <dd>NO-OP: apply the databytes, relayclient, and/or
environment settings, but continue processing further rules.
<dt><tt>p</tt> <dd>Pass the sender or recipient on to the next
processing state (ie <tt>$RELAYCLIENT</tt> or back-end validation).
</dl> The remainder of the line consists of a series of fields seperated
by colons (":"). The fields are: <ol>
<li><b>Sender</b>: A pattern applied to the envelope sender address.
<li><b>Recipient</b>: A pattern applied to the envelope recipient
address.
<li><b>Response</b>: The response message that will be given to the
client with the numerical code. The default for this message depends on
the line's prefix.
<li><b>Data Bytes</b>: Reduces the maximum message size to the lesser of
the current limit (as set at startup by <tt>$DATABYTES</tt>) and the
specified number. This message size limit is reset to its original
value before after each message. If empty or missing, no changes are
made.
<li><b>Relay Client</b>: If present, the current recipient address is
suffixed with this string. Only useful for "k" rules.
<li><b>Environment</b>: Environment variables to set as a result of
matching this rule. This field contains a list of assignments seperated
by commas. Each assignment is formatted as <tt>NAME=VALUE</tt>. If a
value needs to contain a comma, it must be quoted as follows:
<tt>\.</tt>.
</dl>
</ol></p>
<h2>Escaping</h2>
<p>The following escape sequences are recognized in all the fields: <ul>
<li><tt>\n</tt> newline (replaced with a CR+LF pair on output)
<li><tt>\###</tt> character with octal value ### (exactly 3 digits)
<li><tt>\\</tt> backslash
<li><tt>\:</tt> colon
</ul></p>
<h2>Patterns</h2>
<h3>Pattern Syntax</h3>
<p>Patterns are globs, similar to UNIX shell-style wildcards (but quite
different from full regular expressions).<table>
<tr> <th>Pattern</th> <th>Matches</th> </tr>
<tr> <td><tt>*</tt></td> <td>Any sequence of characters (including the
empty sequence).</td> </tr>
<tr> <td><tt>?</tt></td> <td>Any single character.</td> </tr>
<tr> <td><tt>[seq]</tt></td> <td>A single occurance of any character in
<tt>seq</tt>.</td> </tr>
<tr> <td><tt>[!seq]</tt></td> <td>A single occurance of any character
<i>not</i> in <tt>seq</tt>.</td> </tr>
</table>Any other character matches itself, without regard for case.
Patterns containing only "<tt>*</tt>" match anything.
<b>Note:</b> An empty pattern matches <i>only</i> the empty string.</p>
<h3>Special Patterns</h3>
<p>The following patterns are treated specially: <dl>
<dt><tt>[[@<i>filename</i>]]</tt> <dd>Matches the domain portion of the
address against the control file named <tt><i>filename</i></tt>.
Typical uses would be "<tt>[[@rcpthosts]]</tt>" and
"<tt>[[@morercpthosts.cdb]]</tt>" in the recipient field.
<dt><tt>[[<i>filename</i>]]</tt> <dd>Matches the entire address against
the control file named <tt><i>filename</i></tt>. A typical use would be
"<tt>[[badmailfrom]]</tt>" in the sender field.
</dl> If <tt><i>filename</i></tt> ends with <tt>.cdb</tt>, the control
file is opened as a CDB file. Addresses are translated to lower-case
before doing CDB lookups. Otherwise, control files are plain text
lists, with one entry per line. Empty lines and lines starting with
"<tt>#</tt>" are ignored. Lines starting with "<tt>@</tt>" match only
the domain portion of the address. All comparisons are case
insensitive. Missing CDB files are silently ignored. Missing text
files cause an error message at startup.</p>
<h3>Negation</h3>
<p>Prefixing the pattern with a <tt>!</tt> inverts the result of the
match. That is, if the pattern match does <i>not</i> succeed, the rule
will succeed instead of failing. This applies to all patterns including
the special patterns above.</p>
<h2>Semantics</h2>
<p>Each rule is applied in the order they are listed in the rules file
until one matches. At that point, the command that triggered the rule
search is accepted, deferred, or rejected depending on the rule type.
If the sender is not accepted, no recipients can be accepted, as usual.
As long as at least one recipient is accepted the message data may be
accepted.</p>
<h2>Examples</h2>
<h3>qmail Rules</h3>
<p>The following rules provide the functionality similar to that
available in qmail-smtpd. Please note that the qmail validation
routines already provide this functionality. These rules are listed for
illustrative purposes only.</p>
<pre>
:sender
d[[/var/qmail/control/badmailfrom]]:*:sorry, your envelope sender is in my badmailfrom list (#5.7.1)
:recipient
k*:[[@/var/qmail/control/rcpthosts]]
k*:[[@/var/qmail/control/morercpthosts.cdb]]
</pre>
<h3>Abused Patterns</h3>
<p>The following rules block old exploitable addresses that are still
commonly probed: bang paths, multiple domains, and percent hacks.</p>
<pre>
d*:*!*: Sorry, we don't allow that here
d*:*@*@*: Sorry, we don't allow that here
d*:*%*: Sorry, percent hack not accepted here
</pre>
</body>
</html>
|