Mercurial > dnsbl

comparison xml/dnsbl.in @ 76:81f1e400e8ab

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
start coding on new config syntax
author carl
date Sat, 16 Jul 2005 13:47:19 -0700
parents 1142e46be550
children db85c53e3d90
comparison
equal deleted inserted replaced
75:1142e46be550 76:81f1e400e8ab
78 DNSBLs will be used to define the DNSBL-LISTs. 78 DNSBLs will be used to define the DNSBL-LISTs.
79 79
80 <p>DNSBL-LIST - a named list of DNSBLs that will be used for specific 80 <p>DNSBL-LIST - a named list of DNSBLs that will be used for specific
81 recipients or recipient domains. 81 recipients or recipient domains.
82 82
83 <p>The envelope to email address is used to find an initial filtering context. 83 <hr> <center>Filtering Procedure</center>
84 That context then uses the envelope from email address to find the final 84
85 filtering context. The envelope from email address is checked in that context 85 <p>If the client has authenticated with sendmail, the mail is accepted,
86 to see if we should whitelist or blacklist the message 86 the dns lists are not checked, and the body content is not scanned.
87 two names (a named DNSBL-LIST, and a named ENVELOPE-FROM-MAP). If the 87 Otherwise, we follow these steps for each recipient.
88 recipient is not found in the configuration, the named DEFAULT
89 dnsbl-list and DEFAULT envelope-from-map will be used. When mail is
90 received for that recipient,
91 88
92 <ol> 89 <ol>
93 90
94 <li>If the client has authenticated with sendmail, the mail is accepted,
95 the dns lists are not checked, and the body content is not scanned.
96
97 <li>The envelope to email address is used to find an initial filtering 91 <li>The envelope to email address is used to find an initial filtering
98 context. We first look for a context that specified the full email address 92 context. We first look for a context that specified the full email
99 in the env_to statement. If that is not found, we look for a context that 93 address in the env_to statement. If that is not found, we look for a
100 specified the entire domain name of the envelope recipient in the env_to 94 context that specified the entire domain name of the envelope recipient
101 statement. If that is not found, we look for a context that specified the 95 in the env_to statement. If that is not found, we look for a context
102 user@ part of the envelope recipient in the env_to statement. If that is not 96 that specified the user@ part of the envelope recipient in the env_to
103 found, we use the first top level context defined in the config file. 97 statement. If that is not found, we use the first top level context
104 98 defined in the config file.
105 <li>The initial filtering context may redirect to a child context based 99
106 on the values in the initial context's env_from statement. We look for 100 <br><br><li>The initial filtering context may redirect to a child
107 [1) the full envelope from email address, 2) the domain name part of the 101 context based on the values in the initial context's env_from statement.
108 envelope from address, 3) the user@ part of the envelope from address] 102 We look for [1) the full envelope from email address, 2) the domain name
109 in that context's env_from statement, with values that point to a child 103 part of the envelope from address, 3) the user@ part of the envelope
110 context. If such an entry is found, we switch to that filtering 104 from address] in that context's env_from statement, with values that
111 context. 105 point to a child context. If such an entry is found, we switch to that
112 106 child filtering context.
113 <li>We lookup [1) the full envelope from email address, 2) the domain 107
114 name part of the envelope from address, 3) the user@ part of the 108 <br><br><li>We lookup [1) the full envelope from email address, 2) the
109 domain name part of the envelope from address, 3) the user@ part of the
115 envelope from address] in the filtering context env_from statement. 110 envelope from address] in the filtering context env_from statement.
116 That results in one of (white, black, unknown, inherit). 111 That results in one of (white, black, unknown, inherit).
117 112
118 <li>If the answer is black, mail to this recipient is rejected with "no 113 <br><br><li>If the answer is black, mail to this recipient is rejected
119 such user", and the dns lists are not checked. 114 with "no such user", and the dns lists are not checked.
120 115
121 <li>If the answer is white, mail to this recipient is accepted and the 116 <br><br><li>If the answer is white, mail to this recipient is accepted
122 dns lists are not checked. 117 and the dns lists are not checked.
123 118
124 <li>If the answer is unknown, we don't reject yet, but the dns lists 119 <br><br><li>If the answer is unknown, we don't reject yet, but the dns
125 will be checked, and the content may be scanned. 120 lists will be checked, and the content may be scanned.
126 121
127 <li>If the answer is inherit, we repeat the envelope from search in the 122 <br><br><li>If the answer is inherit, we repeat the envelope from search
128 parent context. 123 in the parent context.
129 124
130 <li>The dns lists specified in the filtering context are checked and the 125 <br><br><li>The dns lists specified in the filtering context are checked
131 mail is rejected if any list has an A record for the standard dns based 126 and the mail is rejected if any list has an A record for the standard
132 lookup scheme (reversed octets of the client followed by the dns 127 dns based lookup scheme (reversed octets of the client followed by the
133 suffix). 128 dns suffix).
134 129
135 <li>If the mail has not been accepted or rejected yet, the body content 130 <br><br><li>If the mail has not been accepted or rejected yet, and the
136 is optionally scanned for HTTP URLs (after base64, mime and html entity 131 filtering context enables content filtering, and this is the first such
137 decoding), and the first &lt;configurable&gt; host names are checked for 132 recipient in this smtp transaction, we set the content filtering parameters
138 their presence on the SBL. If any host name is on the SBL, and it is 133 from this context, and enable content filtering for this body.
139 not on the "ignore" list, the mail is rejected. If we are doing body
140 content scanning, we also scan for excessive bad html tags, and if a
141 &lt;configurable&gt; limit is exceeded, the mail is rejected.
142 134
143 </ol> 135 </ol>
136
137 <p>If content filtering is enabled for this body, the mail text is
138 decoded (uuencode, base64, mime, html entity, url encodings), scanned
139 for HTTP and HTTPS URLs, and the first &lt;configurable&gt; host names
140 are checked for their presence on the single &lt;configurable&gt; DNSBL.
141 The only known list that is suitable for this purpose is the SBL. If
142 any of those host names are on that DNSBL (or have nameservers that are
143 on that list), and it is not on the &lt;configurable&gt; ignore list,
144 the mail is rejected. We also scan for excessive bad html tags, and if
145 a &lt;configurable&gt; limit is exceeded, the mail is rejected.
144 146
145 <hr> <center>Sendmail access vs. DNSBL</center> 147 <hr> <center>Sendmail access vs. DNSBL</center>
146 <p>With the standard sendmail.mc dnsbl FEATURE, the dnsbl checks may be 148 <p>With the standard sendmail.mc dnsbl FEATURE, the dnsbl checks may be
147 suppressed by entries in the /etc/mail/access database. For example, 149 suppressed by entries in the /etc/mail/access database. For example,
148 suppose you control a /18 of address space, and have allocated some /24s 150 suppose you control a /18 of address space, and have allocated some /24s
239 <p>Suppose we are processing 20 messages per second, and each message 241 <p>Suppose we are processing 20 messages per second, and each message
240 requires 20 seconds of dns work. Then we will have 400 sendmail 242 requires 20 seconds of dns work. Then we will have 400 sendmail
241 processes, 400 milter threads, and 400 dns resolver processes. Of 243 processes, 400 milter threads, and 400 dns resolver processes. Of
242 course that steady state is very unlikely to happen. 244 course that steady state is very unlikely to happen.
243 245
246 <hr> <center>Rejected Ideas</center>
247
248 <p>The following ideas have been considered and rejected.
249
250 <p>Add max_recipients for each mail domain to the configuration.
251 Recipients in excess of that limit will be rejected, and all the
252 recipients in that domain will be removed if there are some other
253 whitelisted recipients. Current spammers *very* rarely send more than
254 ten recipients in a single smtp transaction, so this won't stop
255 any significant amount of spam.
256
257 <p>Add poison addresses to the configuration. If any recipient is
258 poison, all recipients are rejected even if they would be whitelisted,
259 and the data is rejected if sent. I have a collection of spam trap
260 addresses that would be suitable for such use. Based on my log files,
261 any mail to those spam trap addresses is rejected based on either dnsbl
262 lookups or the DCC. So this won't result in blocking any additional
263 spam.
264
265 <p>Add an option to only allow one recipient if the return path is
266 empty. Based on my log files, there is no mail that violates this
267 check.
268
269 <p>Reject the mail if the envelope from domain name contains any MX
270 records pointing to 127.0.0.0/8. I don't see any significant amount of spam
271 sent with such domain names.
272
273
244 <pre> 274 <pre>
245 $Id$ 275 $Id$
246 </pre> 276 </pre>
247 </body> 277 </body>
248 </html> 278 </html>