Mercurial > dnsbl

diff xml/dnsbl.in @ 59:510a511ad554

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add resolver processes to allow better performance on busy machines
author carl
date Mon, 03 Jan 2005 18:35:50 -0800
parents 419e00901570
children 390ed250c5d2
line wrap: on
line diff
--- a/xml/dnsbl.in	Thu Oct 28 22:54:34 2004 -0700
+++ b/xml/dnsbl.in	Mon Jan 03 18:35:50 2005 -0800
@@ -2,7 +2,7 @@
 
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<title>DNSBL Sendmail milter - Version 3.7</title>
+<title>DNSBL Sendmail milter - Version 4.0</title>
 </head>
 
 <center>Introduction</center>
@@ -31,8 +31,7 @@
 startup, and whenever the config file (or any of the referenced include
 files) is changed.  The entire configuration file is case insensitive.
 
-<hr>
-<center>DCC Issues</center>
+<hr> <center>DCC Issues</center>
 <p>If you are also using the <a
 href="http://www.rhyolite.com/anti-spam/dcc/">DCC</a> milter, there are
 a few considerations.  You may need to whitelist senders from the DCC
@@ -69,8 +68,7 @@
 appropriately tagged and used only for the domains controlled by each of
 those clients.
 
-<hr>
-<center>Definitions</center>
+<hr> <center>Definitions</center>
 <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
@@ -121,8 +119,7 @@
 
 </ol>
 
-<hr>
-<center>Sendmail access vs. DNSBL</center>
+<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,
 suppose you control a /18 of address space, and have allocated some /24s
@@ -152,13 +149,13 @@
 these directions</a> helpful for setting up smtp-auth if you are on RH
 Linux.
 
-<hr> <center>Installation and configuration</center> <p>Usage:  Note
-that this has ONLY been tested on Linux, specifically RedHat Linux.  In
-particular, this milter makes no attempt to understand IPv6.  Your
-mileage will vary.  You will need at a minimum a C++ compiler with a
-minimally thread safe STL implementation.  The distribution includes a
-test.cpp program.  If it fails this milter won't work.  If it passes,
-this milter might work.
+<hr> <center>Installation and configuration</center>
+<p>Usage:  Note that this has ONLY been tested on Linux, specifically
+RedHat Linux.  In particular, this milter makes no attempt to understand
+IPv6.  Your mileage will vary.  You will need at a minimum a C++
+compiler with a minimally thread safe STL implementation.  The
+distribution includes a test.cpp program.  If it fails this milter won't
+work.  If it passes, this milter might work.
 
 Fetch <a href="http://www.five-ten-sg.com/util/dnsbl.tar.gz">dnsbl.tar.gz</a>
 and
@@ -188,10 +185,31 @@
 /usr/sbin/dnsbl -c
 </pre>
 
-<pre>
+<hr> <center>Performance issues</center>
+
+<p>Consider a high volume high performance machine running sendmail.
+Each sendmail process can do its own dns resolution.  Typically, such
+dns resolver libraries are not thread safe, and so must be protected by
+some sort of mutex in a threaded environment.  When we add a milter to
+sendmail, we now have a collection of sendmail processes, and a
+collection of milter threads.
 
+<p>We will be doing a lot of dns lookups per mail message, and at least
+some of those will take many tens of seconds.  If all this dns work is
+serialized inside the milter, we have an upper limit of about 25K mail
+messages per day.  That is clearly not sufficient for many sites.
 
+<p>Since we want to do parallel dns resolution across those milter
+threads, we add another collection of dns resolver processes.  Each
+sendmail process is talking to a milter thread over a socket, and each
+milter thread is talking to a dns resolver process over another socket.
 
+<p>Suppose we are processing 20 messages per second, and each message
+requires 20 seconds of dns work.  Then we will have 400 sendmail
+processes, 400 milter threads, and 400 dns resolver processes.  Of
+course that steady state is very unlikely to happen.
+
+<pre>
 $Id$
 </pre>
 </body>