On Wed, 2 Oct 2002, Eddie Javier wrote: > Hello, > > If it's possible, avoid using Amavis. It's a memory hog (at least the last > one I used). You mentioned that in every message that comes in, Amavis > spawns the virus scanner. Imagine if you have thousands of email coming in.
Using a fairly modern MTA, you can throttle the number of instances that run the AV-SCANNER. This is a non-issue, unless you are using sendmail which has no such control for this. > Don't use virus scanning daemons as well. If the virus scanner dies or leaks > , you have to have another program watching it whenever that happens. Also, > if your mail servers gets attacked via the "Zip of Death", your virus > scanner may crash. Best practices for sysadministration dictate that a program should be installed that regularly checks the logfiles for trouble, be it a 'daemonised' or 'exec-and-scan'. Also the advantage of an 'exec-and-spawn' is that only the delivery of that particular piece of email is affected. If a daemon dies and is not restarted immediately, the entire mail system grinds to a halt until the daemon is restarted. > A more sophisticated solution is to use a system that scans messages by > batch rather than one by one. It works like this: > > 1. Spawn sendmail and store messages on an alternate folder, say mqueue.in > > /usr/sbin/sendmail -bd -ODeliveryMode=queueonly > -OQueueDirectory=/var/spool/mqueue.in > /usr/sbin/sendmail -q15m > > 2. Have the AV scanner scan the incoming queue. Move to /var/spool/mqueue if > clean, quarantine if not > > A program that does this is mailscanner (http://www.mailscanner.info). > What's cool is that it can also filter spam if you want to. What's even > cooler is that cross-check mails with open relay databases. What's even > "spankingly cool" is that it can use SpamAssassin to filter more spam. This is a good solution however it suffers from the usual problem of store and forward systems. The 'thundering herd' effect which generally happens when the AV/SPAM scanner is finished with its job and it's time to deliver the mail that passed the test. Depending on the amount of mail passing through, you may have time when the bandwidth utilization is almost zero for SMTP traffic, and then shoots up dramatically when the mail is all sent out. It would be better to use an MTA which can throttle connections through the AV/SPAM filter, and have simple spooling servers at the entry point so that incoming SMTP is always available and is spooled, until it is ready to be accepted by the AV scanner and processed. If one wants to avoid the thundering herd by simply making the store and forward regularity scan more frequent, then you might as well simply run an instance of your scanner per email, as it's the same effect resource wise. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
