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 suitable...as 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.
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/
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?
