On 2006-12-22, at 1006, Christopher Chan wrote:
John Simpson wrote:http://qmail.jms1.net/patches/validrcptto.cdb.shtmlThere 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 immediately.
believe me, i have tested these scenarios with several clients... and validrcptto.cdb has always ended up being faster than any mysql scenario, both with and without replication. and yes, these were on busy servers- one mailbox server with 120K mailboxes across 4500 domains, and four mailhubs, located at three sites in different parts of florida, handling an average of 1.2 million SMTP connections per hour.
postfix improves on this by 1) no new fork for each connection (except perhaps initially if handling hundreds or thousands of connections right after startup of postfix) and 2) by using mysql connection pooling which means you don't hammer the mysql server into the ground with the constant setting up and breaking down of connections. This is without including all the great anti-spam features that postfix provides too.
i'll be honest, i can't really comment on this. my only exposure to postfix has been removing it from my OSX machines in order to make way for qmail. i can't and won't say that one is "better" than the other, since i haven't ever administered a postfix system. i know that postfix has its collection of zealots, just as qmail does.
I probably know/understand qmail better than you do.
i wouldn't bet on it, but then i have better things to do with my life than play "mine is bigger than yours" with some random person on a mailing list. i know what has worked for me since 1998, and what i will continue using. if you don't want to use my patches, or if you don't want to use qmail, it's no sweat off my back... i just threw it out there as a suggestion, trying to mention that there are other options. there was no need for you to get nasty about why you don't want to use my patches, i truly don't care if you use them or not.
merry christmas, by the way. -------------------------------------------------- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | -------------------------------------------------- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | --------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
