John Simpson wrote:
On 2006-12-18, at 0444, Christopher Chan wrote:
Darrel O'Pry wrote:
I'm currently considering replacing qmail in my mail systems.
I was wondering if anyone had tried vpopmail with postfix or exim and
what their experiences were.

Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues.

funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now.

Yes. with a patch. I know patches exist. I have nothing against qmail. I will recommend qmail where it is most the mta for outgoing mails for a mailing list or as the second stage in the inbound system due to dot-qmail which is a delivery system that is second to none.

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:

postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb check.

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.

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.

IM2000 does not appear to be happening, DJB apparently will not make any more improvements to qmail to deal with today's Internet and I do not fancy mixing a bunch of patches to get similar functionality on tcpserver's less efficient architecture (one fork per new connection).

One of these days I am going to try to make dot-qmail/qmail-users support for postfix and see how much more fanatic some qmail guys are about qmail than I was. I can boast the ability to install qmail without even looking at the documentation and the ability to split a qmail queue's directory structure across different disks to get better delivery performance besides using the multiple qmail queue method. And having qmail patched and tuned to be able to push over a thousand qmail-remotes while under constant injections via qmail-smtpd and qmail-qmtpd non-stop.

I probably know/understand qmail better than you do. So if you are running a site with low traffic, by all means, continue using your patched qmail that requires you to stop the queue (and sometimes even the tcpserver for qmail-smtpd) before you can do any clean up of the queue and that might get you blocked for being 'abusive' because it opened up 120 connections to the same mx for whatever reason you got that composition of emails in the queue. I, for my part, cannot recommend qmail except for cases where it does not need an uber number of patches to be acceptable and does not require queue clean up and its delivery behaviour is tolerable. Sigh. But I am more inclined to teach others how to use qmail since it is so SIMPLE. When will spammers disappear?

Reply via email to