Mercurial > dnsbl
diff xml/dnsbl.in @ 75:1142e46be550
start coding on new config syntax
| author | carl |
|---|---|
| date | Wed, 13 Jul 2005 23:04:14 -0700 |
| parents | fb8afa205293 |
| children | 81f1e400e8ab |
line wrap: on
line diff
--- a/xml/dnsbl.in Sun Jul 10 14:19:00 2005 -0700 +++ b/xml/dnsbl.in Wed Jul 13 23:04:14 2005 -0700 @@ -2,7 +2,7 @@ <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> -<title>DNSBL Sendmail milter - Version 4.6</title> +<title>DNSBL Sendmail milter - Version 5.0</title> </head> <center>Introduction</center> @@ -49,13 +49,11 @@ feature that the mail is rejected earlier (at RCPT TO time), and the sending machine just gets a generic "550 5.7.1 no such user" message. -<p>There is an option to reference the DCC whiteclnt file (via an -include_dcc line) in the DNSBL milter config. This will import the -(env_to, env_from, and substitute mail_host) entries from the DCC config -into the DNSBL config. This allows using the DCC config as the single -point for white/blacklisting. When used in this manner, the whitelist -env_to entries from the DCC config become global whitelist entries in -the DNSBL config. +<p>The DCC whiteclnt file can be included in the DNSBL milter config by +the dcc_to and dcc_from statements. This will import the (env_to, +env_from, and substitute mail_host) entries from the DCC config into the +DNSBL config. This allows using the DCC config as the single point for +white/blacklisting. <p>Consider the case where you have multiple clients, each with their own mail servers, and each running their own DCC milters. Each client @@ -63,12 +61,17 @@ Presumably you can use rsync or scp to fetch copies of your clients DCC whiteclnt files on a regular basis. Your mail server, acting as a backup MX for your clients, can use the DNSBL milter, and include those -client DCC config files. The envelope to white/blacklisting will be -global for your system, but the envelope from white/blacklisting will be -appropriately tagged and used only for the domains controlled by each of -those clients. +client DCC config files. The envelope from/to white/blacklisting will +be appropriately tagged and used only for the domains controlled by each +of those clients. <hr> <center>Definitions</center> + +<p>CONTEXT - a collection of parameters that defines the filtering +context to be used for a collection of envelope recipient addresses. +The context includes such things as the list of DNSBLs to be used, and +the various content filtering parameters. + <p>DNSBL - a named DNS based blocking list is defined by a dns suffix (e.g. sbl-xbl.spamhaus.org) and a message string that is used to generate the "550 5.7.1" smtp error return code. The names of these @@ -77,12 +80,10 @@ <p>DNSBL-LIST - a named list of DNSBLs that will be used for specific recipients or recipient domains. -<p>ENVELOPE-FROM-MAP - a named collection of mappings (key->value pairs) -from envelope-from values to the WHITE, BLACK, or DEFAULT keywords. The -names of these maps will be used for specific recipients or recipient -domains. - -<p>The configuration file maps each recipient (or recipient domain) to +<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 @@ -90,22 +91,44 @@ <ol> -<li>If the client has authenticated with sendmail, the mail is accepted -and the dns lists are not checked. +<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. -<li>If either one is BLACK, mail to this recipient is rejected with "no +<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. + +<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 envelope-from-map name is WHITE, mail to this recipient is -accepted 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. + +<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>If the envelope-from-map exists, the map is checked for the presence -of the sender. A WHITE or BLACK answer is definitive and the dns lists -are not checked. +<li>If the answer is inherit, we repeat the envelope from search in the +parent context. -<li>If the dnsbl-list name is WHITE, the dns lists are not checked and -the mail is accepted. Otherwise, the dns lists are checked and the mail -is rejected if any list has an A record for the standard dns based +<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). @@ -145,7 +168,7 @@ OK entries in the sendmail access database will override all the dnsbl checks. With this DNSBL milter, you will need to have the local users authenticate with smtp-auth to get the same effect. You might find <a -href="http://www.ists.dartmouth.edu/IRIA/knowledge_base/linuxinfo/sendmail-ssh-how-to.htm"> +href="http://www.lists.dartmouth.edu/IRIA/knowledge_base/linuxinfo/sendmail-ssl-how-to.htm"> these directions</a> helpful for setting up smtp-auth if you are on RH Linux. @@ -185,6 +208,15 @@ /usr/sbin/dnsbl -c </pre> +You can check a specific envelope from/to pair with + +<pre> +cd /etc/dnsbl +from="$1" # or your from address +to="$2" # or your to address +/usr/sbin/dnsbl -e "$from"'|'"$to" +</pre> + <hr> <center>Performance issues</center> <p>Consider a high volume high performance machine running sendmail.