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