At 09:29 AM 06/12/99 -0500, you wrote:
>2. Modify qmail to pull the mailbox dir/user info _at delivery time_ from
>the DB.
>
>It strikes me that option 1 is probably better from a performance and
>simplicity standpoint (plus in the event of catastrophic database or
>connectivity failure) in that deliveries won't be interrupted. Has anybody
>tried anything like #2, and have some decent insight as to why I might or
>might not want to do this?
I'm running a mail forwarding system for many domains, where by I receive
mail for the domains at one user (forwarding) and then forward it on.
~forwarding/.qmail-default contains a pipe to a perl script that looks up
appropriate values using the HOST, LOCAL and DEFAULT environment variables
and then forwards the mail.
The perl program connects to a mysql database each time it runs at the
moment, to do the lookups.
Apparently I can do about 400 deliveries a minute or something (based on an
"average" pc server) before I run out of CPU power, though, I guess i'll
probably run out of disk space and RAM before that...
My coding skills arn't particularly optimised, I guess a better hack, with
persistent connections, and more RAM, CPU and disk space, could increase an
order of magnitude.
And because it's done on the fly, no one ever complains the data is out of
date!
<side note>
interestingly, I have the database stored on a server in the UK, but the
primary MX is in the US, and this works quite well, because the performance
demands of the database connections are fairly minor compared to the actual
processing of mail. What's better, is that if, for some reason the US
server can't talk to the UK server, then the perl script just exists with
the appropriate exit code and qmail defers the mail back into the queue,
for later delivery.
</s>
The man pages qmail-command and qmail-local will help, along with the
safecat program for delivery to maildirs.
peter
--
peter at gradwell dot com; online @ http://www.gradwell.com/
