On 2006-12-22, at 1006, Christopher Chan wrote:
John Simpson wrote:
http://qmail.jms1.net/patches/validrcptto.cdb.shtml
There is a better patch for vpopmail support in qmail. A mysql
patch that goes straight the vpopmail mysql database but I am not
sure of its location. The writer even rebuffed one of Inter7's
developers when someone floated the idea of qmail supporting
vpopmail's mysql tables and the developer said he would write it
since he was not aware of the patch's existence. So I believe the
Inter7 guy drop it right then and there or maybe not. I believe it
is this one here and the writer was Italian: http://
www.interazioni.it/opensource/chkusr/
that's all well and good, IF your incoming mail always arrives on the
same machine where vpopmail is running, IF you don't mind re-
compiling qmail everytime vpopmail is upgraded, and IF you keep your
user information in a mysql database.
most ISPs handle a large enough volume of email that they have
several internet-facing servers which handle the flood of incoming
mail, and forward the legitimate messages to an internal machine
which contains the mailboxes. the one mailbox machine will be running
vpopmail, but the other internet-facing servers (i call them
mailhubs) are generally not running vpopmail, which means they are
not able to check recipients or process AUTH commands against the
vpopmail information.
i've seen people get around this using mysql, both by having the
mailhubs connect across the network to a database server, and by
setting up mysql servers on the mailhubs and replicating the data.
but what if the company isn't using mysql in the first place? (i
spent eight years building and running ISPs with this exact scenario-
multiple mailhubs, no mysql. yes, we had a customer database- but
that was for billing, and it wasn't directly involved with the
mechanics of the systems themselves.)
my validrcptto.cdb and auth.cdb patches get around these problems by
storing the list of valid recipient addresses and the list of valid
userid/password pairs in cdb files, and just copying those files from
the mailbox server out to the mailhubs whenever they change. PLUS,
the fact that they're cdb files means that the lookups happen without
the added overhead of having to open a connection to a mysql server
(whose connection pool might become overloaded in case of a spam flood.)
the down side is that you have to write some scripts to generate
the validrcptto.cdb and auth.cdb files in the first place, and copy
them out to the mailhubs. however, my web site also has working
mkvalidrcptto and mkauth scripts, along with a web page which
explains how to use ssh to push the files out to your mailhubs... so
while it may not be brain dead easy, it's certainly not as
difficult as setting up and maintaining replication between mysql
servers.
for my needs and my clients' needs, my patches are the best solution.
they may not be for everybody, which is why i'll explain the
differences between validrcptto.cdb and chkusr, but i don't claim
either one to be better than the other. different people have
different needs.
postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb
check.
everybody has their own opinions... mine happen to be the exact
opposite of what you've written here.
First, chkusr vs rcptto.cdb. tcpserver + qmail-smtpd means a fresh
fork for each new connection. The cdb rcptto means a disk access
for each rcpt to check and regular rebuilds of the cdb database.
chkusr/chkuser helps by keeping I/O of disk (okay we can contest
whether looking up cdbs is better than looking up mysql tables or
not but I think it is fair game to say that mysql lookups are more
likely to be disk I/O free) and by not needing regular rebuilds of
a cdb file. In fact, it offers instant/real-time user existence
checks.
until you build in the overhead of mysql replication (or even worse,
qmail-smtpd connecting to a mysql server across the network.)
open() takes less CPU and less time than mysql_connect(), even if the
mysql server is on the same machine (because open() only involves
qmail-smtpd and the kernel, while mysql_connect() also involves
mysqld, which may already be busy with other clients, witness the
complains about this very issue on the courier-imap list.)
and in the case of a file like validrcptto.cdb, which would be used
constantly on a busy server, the file's data blocks would be in the
kernel's disk cache 99% of the time, so there is almost never any
wait for a disk to rotate- any disk reads are satisfied from the
kernel's disk cache. if anything, i think the chances of a single
file already being cached in the kernel's disk cache are higher than
the chances of a mysql server having the right rows from the right
table in memory, plus be idle at the right time and be able to answer
qmail-smtpd's queries
