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