The combination of DNS, SMTP, and *nix provide all of the answers for mail redundancy. The answer to almost all mail failure problems is multiple MX records. The ideal solution we use is to have two or more totally independent servers scanning your mail, and then passing the messages on (via smtproutes) to a system running straight qmail for local delivery. Depending on the bulk of your servers a configuration like this can easily handle in excess of 1/2 a million per day. If you don't have the bank/need for 3 servers you can slim this down to two, by making both servers scan for viruses, but setting your tcpserver cdb file not to scan mail from the IP of your dedicated virus proxying machine. You might be better off to set the MX of the system with local delivery higher than that of the dedicated virusproxying machine. If you're in the one server ball game, you still have quite a few options. The first and most recommended being, make sure clamd/spamd don't crash. Using daemontools, or something similar to monitor the process is always recommended. A while back I saw something that would run a query to clamd every 5 minutes, and if it failed to respond would kill the existing daemon and restart it. If anyone has any information on that, it'd be appreciated. A year or so ago, I wrote a perl app that essentially tails our maillogs, counting messages, errors, etc... Something like this could be easily transformed, so that on a "clamd resource/permissions error" action could be taken to restart the failed clamd process. If you're only handling a few messages per hour, this is probably a bad solution, but if you're handling a few messages per second, it makes you operational again in a hurry. More directly in answer to your question about failing over to not scanning, this is possible also. If you have two IPs for your mail server, run two copies of tcpserver, one for each IP. On one of the IPs, run tcpserver with a cdb with QMAILQUEUE set for qmail-scanner, on the other have it set for qmail-queue. Set the IP with qmail-scanner to a low MX, and the other to a high MX. If clamd fails, mail will get the temporary failure and try the higher MX, which should allow it to pass. That said, this is a horrible solution, and you should just make sure your daemons don't crash, and get fixed when they do. This solution would also probably let a lot of spam pass. Spammers realize that higher MX servers are typically back-ups without all of the spam/virus fighting protection offered by the lower MX servers, so they'll target them.
Thank you,
Cody Baker [EMAIL PROTECTED] http://www.wilkshire.net
Entelin wrote:
If clamd is down for whatever reason mail will stop flowing, if memory serves the smtp session would give a "temporary failure" message. Is it possible to configure qmail-scanner to try to use clam / sa but if it doesnt work to just let the mail pass? Having the mail transfer utterly dependant on several other daemons makes things just a bit less solid than I would prefer. perhaps log a message somewhere about it?
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Qmail-scanner-general mailing list Qmail-scanner-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
