--- a/xml/dnsbl.in	Wed Jul 13 23:04:14 2005 -0700
+++ b/xml/dnsbl.in	Sat Jul 16 13:47:19 2005 -0700
@@ -80,68 +80,70 @@
 <p>DNSBL-LIST - a named list of DNSBLs that will be used for specific
 recipients or recipient domains.
 
-<p>The envelope to email address is used to find an initial filtering context.
-That context then uses the envelope from email address to find the final
-filtering context. The envelope from email address is checked in that context
-to see if we should whitelist or blacklist the message
-two names (a named DNSBL-LIST, and a named ENVELOPE-FROM-MAP).  If the
-recipient is not found in the configuration, the named DEFAULT
-dnsbl-list and DEFAULT envelope-from-map will be used.  When mail is
-received for that recipient,
+<hr> <center>Filtering Procedure</center>
+
+<p>If the client has authenticated with sendmail, the mail is accepted,
+the dns lists are not checked, and the body content is not scanned.
+Otherwise, we follow these steps for each recipient.
 
 <ol>
 
-<li>If the client has authenticated with sendmail, the mail is accepted,
-the dns lists are not checked, and the body content is not scanned.
-
 <li>The envelope to email address is used to find an initial filtering
-context. We first look for a context that specified the full email address
-in the env_to statement. If that is not found, we look for a context that
-specified the entire domain name of the envelope recipient in the env_to
-statement. If that is not found, we look for a context that specified the
-user@ part of the envelope recipient in the env_to statement. If that is not
-found, we use the first top level context defined in the config file.
+context.  We first look for a context that specified the full email
+address in the env_to statement.  If that is not found, we look for a
+context that specified the entire domain name of the envelope recipient
+in the env_to statement.  If that is not found, we look for a context
+that specified the user@ part of the envelope recipient in the env_to
+statement.  If that is not found, we use the first top level context
+defined in the config file.
 
-<li>The initial filtering context may redirect to a child context based
-on the values in the initial context's env_from statement.  We look for
-[1) the full envelope from email address, 2) the domain name part of the
-envelope from address, 3) the user@ part of the envelope from address]
-in that context's env_from statement, with values that point to a child
-context.  If such an entry is found, we switch to that filtering
-context.
+<br><br><li>The initial filtering context may redirect to a child
+context based on the values in the initial context's env_from statement.
+We look for [1) the full envelope from email address, 2) the domain name
+part of the envelope from address, 3) the user@ part of the envelope
+from address] in that context's env_from statement, with values that
+point to a child context.  If such an entry is found, we switch to that
+child filtering context.
 
-<li>We lookup [1) the full envelope from email address, 2) the domain
-name part of the envelope from address, 3) the user@ part of the
+<br><br><li>We lookup [1) the full envelope from email address, 2) the
+domain name part of the envelope from address, 3) the user@ part of the
 envelope from address] in the filtering context env_from statement.
 That results in one of (white, black, unknown, inherit).
 
-<li>If the answer is black, mail to this recipient is rejected with "no
-such user", and the dns lists are not checked.
-
-<li>If the answer is white, mail to this recipient is accepted and the
-dns lists are not checked.
+<br><br><li>If the answer is black, mail to this recipient is rejected
+with "no such user", and the dns lists are not checked.
 
-<li>If the answer is unknown, we don't reject yet, but the dns lists
-will be checked, and the content may be scanned.
+<br><br><li>If the answer is white, mail to this recipient is accepted
+and the dns lists are not checked.
 
-<li>If the answer is inherit, we repeat the envelope from search in the
-parent context.
+<br><br><li>If the answer is unknown, we don't reject yet, but the dns
+lists will be checked, and the content may be scanned.
 
-<li>The dns lists specified in the filtering context are checked and the
-mail is rejected if any list has an A record for the standard dns based
-lookup scheme (reversed octets of the client followed by the dns
-suffix).
+<br><br><li>If the answer is inherit, we repeat the envelope from search
+in the parent context.
 
-<li>If the mail has not been accepted or rejected yet, the body content
-is optionally scanned for HTTP URLs (after base64, mime and html entity
-decoding), and the first &lt;configurable&gt; host names are checked for
-their presence on the SBL.  If any host name is on the SBL, and it is
-not on the "ignore" list, the mail is rejected.  If we are doing body
-content scanning, we also scan for excessive bad html tags, and if a
-&lt;configurable&gt; limit is exceeded, the mail is rejected.
+<br><br><li>The dns lists specified in the filtering context are checked
+and the mail is rejected if any list has an A record for the standard
+dns based lookup scheme (reversed octets of the client followed by the
+dns suffix).
+
+<br><br><li>If the mail has not been accepted or rejected yet, and the
+filtering context enables content filtering, and this is the first such
+recipient in this smtp transaction, we set the content filtering parameters
+from this context, and enable content filtering for this body.
 
 </ol>
 
+<p>If content filtering is enabled for this body, the mail text is
+decoded (uuencode, base64, mime, html entity, url encodings), scanned
+for HTTP and HTTPS URLs, and the first &lt;configurable&gt; host names
+are checked for their presence on the single &lt;configurable&gt; DNSBL.
+The only known list that is suitable for this purpose is the SBL.  If
+any of those host names are on that DNSBL (or have nameservers that are
+on that list), and it is not on the &lt;configurable&gt; ignore list,
+the mail is rejected.  We also scan for excessive bad html tags, and if
+a &lt;configurable&gt; limit is exceeded, the mail is rejected.
+
 <hr> <center>Sendmail access vs. DNSBL</center>
 <p>With the standard sendmail.mc dnsbl FEATURE, the dnsbl checks may be
 suppressed by entries in the /etc/mail/access database.  For example,
@@ -241,6 +243,34 @@
 processes, 400 milter threads, and 400 dns resolver processes.  Of
 course that steady state is very unlikely to happen.
 
+<hr> <center>Rejected Ideas</center>
+
+<p>The following ideas have been considered and rejected.
+
+<p>Add max_recipients for each mail domain to the configuration.
+Recipients in excess of that limit will be rejected, and all the
+recipients in that domain will be removed if there are some other
+whitelisted recipients.  Current spammers *very* rarely send more than
+ten recipients in a single smtp transaction, so this won't stop
+any significant amount of spam.
+
+<p>Add poison addresses to the configuration.  If any recipient is
+poison, all recipients are rejected even if they would be whitelisted,
+and the data is rejected if sent.  I have a collection of spam trap
+addresses that would be suitable for such use.  Based on my log files,
+any mail to those spam trap addresses is rejected based on either dnsbl
+lookups or the DCC.  So this won't result in blocking any additional
+spam.
+
+<p>Add an option to only allow one recipient if the return path is
+empty.  Based on my log files, there is no mail that violates this
+check.
+
+<p>Reject the mail if the envelope from domain name contains any MX
+records pointing to 127.0.0.0/8. I don't see any significant amount of spam
+sent with such domain names.
+
+
 <pre>
 $Id$
 </pre>