On 2006-12-25, at 1111, Christopher Chan wrote:
... So it appears to me that your comment "(whose connection pool might become overloaded)" indicates you have no idea what I meant by 'connection pooling'. This is software on the mailhub side, not the mysql server side, that addresses mysql's poor connection handling performance.
you are correct, i wasn't aware of any way to do this on the client side. this reminds me of the IMAP connection pooling program that some people use with courier-imap.
... You apparently do the way it was formerly done too at the outfit; generate cdb and then scp the cdb file across to relevant boxes. What did you do to ensure that it is an atomic operation on the push/copy out to mailhub?
the mailbox server sends the file using a command line this:
cat file | ssh -I id_dsa_blah [EMAIL PROTECTED] filename
the SSH key is in the authorized_keys file on the mailhub, with a
forced command which uses the original command as a filename... it
makes sure the filename is one of a small number it recognizes, and
then runs a specific handler for each file. for "validrcptto.cdb" it
does this:
case "validrcptto.cdb" )
cat > validrcptto.new
chmod 644 validrcptto.new
mv validrcptto.new validrcptto.cdb
;;
and "/var/qmail/control/validrcptto.cdb" is a symlink to the file in
this non-root user's home directory.
other files which need to be atomically updated work the same way.
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.Yes, so long as you do not need the 'instant' creation of accounts or what not, your system will do fine for those who have a controlled generation of the cdb files.
i've never had anybody get upset over a ten-second delay (which is actually why i wrote the "onchange" patch, to kick off this whole distribution process... the delay was previously up to one minute, and even that i never heard any complaints about.)
For your traffic patterns, cdb will probably do. The outfit I worked for handled on a daily average, 200 million SMTP connections or over 8 million connections hourly. It was not acceptable to spend minutes pushing the cdb file across for the mailhubs and probably still is. (Please don't give me the get proper hardware. If I could have gotten more servers or replacements that had better disk i/o...)
actually, once the process started, the new cdb files were active on the mailhubs in under five seconds. i'm not running a system the size of gmail, and i doubt anybody else on this list is either.
ROTFL. I have done sendmail, postfix and qmail. qmail is the best in that it is simple and elegant. I had colleagues who would not touch qmail with a ten foot pole. They did not care to delve into the internals of qmail and qmail is a pain if you have to go in the clear out spam. sendmail and postfix are much better in the queue management area.
after i wrote the validrcptto.cdb patch and stopped accepting messages for non-existent mailboxes to start with, it's rare for my queue to have more than five messages in it. i saw the same results with my clients' servers, when i upgraded them to use the validrcptto.cdb feature.
Stopping qmail-send to scrounge out spam and then making sure you delete the stuff properly and do not end up with a corrupt queue is not their cup of tea since it is something they have to do regularly (yes...partly free webmail provider).
if they can identify the messages they don't want (using grep or whatever) then instead of DELETING them, they can simply "touch" the mess/*/___ files with an old timestamp (i use 1998-01-01 00:00:00 for this) and then "kick the queue" by sending an ALRM signal to qmail-send.
what happens is that qmail-send will try each message exactly one more time, and then delete it through the normal timeout mechanism.
which means that, for individual spam-deletion cases, qmail-queue never needs to be stopped at all.
the only time i ever stop a queue is if the filesystem has filled up and caused real corruption.
Don't give tell me about qmHandle. That script is broken and will leave you with corrupt bounce messages under certain conditions besides being awfully slow.
i've never used qmhandle.i wrote my own "qfixq" script years ago, and tested the living daylights out of it. and since releasing it, whenever somebody reports a problem with it, i fix it and release a new version immediately. the version on my web site has been free of any reported bugs since 2005-08-30, and the only change since then was to add an "empty" option to just plain delete everything in the queue, and to add a check to compensate for brain-dead users who couldn't be bothered to read the directions and make sure the bucket count in the script matches the bucket count on their system. the only thing i haven't added to it is an explicit check to make sure qmail-queue is not running, and i haven't done this because some people may have multiple queues, and will therefore be running multiple copies of qmail-queue at the same time.
? I see I have got off on the wrong foot. I thought postfix was the 'other option'. qmail is not an option. qmail is a must whether patched or not.
well, vpopmail WAS originally written as a virtual domain management add-on package for qmail, after all... i've heard of people trying to make other MTAs work with it but i didn't pay much attention because it didn't affect me.
I'd like to see vpopmail get an option to run without needing the presence of qmail. I don't fancy telling others to install a 'stub qmail' so that they can benefit from vpopmail without having to build their own virtual mail backend.
i didn't realize that postfix didn't have support for virtual domains. this would be a show-stopper for me installing it on my own server, or on a client's server.
why not just write something similar to vpopmail, but which works using whatever low-level mechanism postfix provides to handle virtual mailboxes? or if there is no such support, add it in?
the bulk of vpopmail's "magic" relies on how the virtualdomains and users/assign files work in qmail. if these two features weren't there, vpopmail would be vastly different than what we have today (that is IF it existed at all.) so if you're interested in adding virtual-mailbox functionality to postfix, that might be one reasonable avenue of attack- to duplicate the functionality of these two files.
and if you're able to duplicate them exactly, so that the formats are the same, then the rest of vpopmail would probably fall right into place, and "just plain work" with postfix.
now i almost wish i had enough free time to dig into postfix's source code and see how difficult this would be to write into it...
---------------------------------------------------------------- | John M. Simpson --- KG4ZOW --- Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | ---------------------------------------------------------------- | http://video.google.com/videoplay?docid=-4312730277175242198 | ----------------------------------------------------------------
PGP.sig
Description: This is a digitally signed message part
