... 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.

Interesting. Thank you.


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.)

If only we could build a cdb file in ten seconds...we have too many records do to it in that space of time.



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.

:D I am sure that the outfit would be very pleased to be compared to Gmail.



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.

This is fine for low trafic sites. When I was still working for that outfit, the problem was to keep the spam away from existing mailboxes and preferably not even allowing it into the queues.



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.

When a scripter manages to stuff your queues with over 500k messages of rubbish, the last thing you want to do is to let any of it out let alone wait for it to disappear. The queues need to be cleared right away before you get even more bogged down.



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.

You should not have to worry about new injects...I'll take a look at your script. I did not use any 'script' when I had to clear queues. Most I found were just too slow. I just had a saved command line that forked off conf-split no. of children after being fed the pattern to look for.



? 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.

postfix has its own virtual mail backend...but you had to build the tables and management scripts/tools yourself. Its virtual mail backend provides the structure but you had to fill it in.


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?

:D. I am sure someone must have built something like that...it is only probably not as well known as vpopmail.


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.

That 'magic' is specific to qmail. I just use 'magic' that will work with postfix and that means using courier-authlib + maildrop for local mail delivery and either courier-imap or dovecot for imap/pop access.


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.

Nope...no dot-qmail support at all in postfix. I had to use maildrop specific filter recipes.


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...

If you try a qmail-lspawn+qmail-local for postfix that would be great :D

Reply via email to