I'm glad to see that we are in agreement on these topics. Another idea could be to separate your inbound email servers from the pop3 server. Then you could have several inbound servers (via multiple MX records at same weight or a load balancing box to redirect incoming connections) that do all the work and then forward on the to POP3 server. I see Michal has a nice sync utility to do this...
Or if you wanted to avoid the setup of actual mail servers (but don't want to lose your user lists for RCPT TO checks), check out eWall by serversidesolutions (sssolutions.net). I own it (site license... whew!) and it does work good (not currently using it though). Think of it as an inline proxy... the client and servers talk to each other, but eWall can jump in at any point (according to any rules you set up) and then do whatever you want (such as AV and spam scanning). ------------------------------------------------------------ Jason J Ellingson Sr. Web Software Developer 615.301.1682 : nashville 612.605.1132 : minneapolis www.ellingson.com [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shiloh Jennings Sent: Wednesday, December 29, 2004 12:00 PM To: xmail@xmailserver.org Subject: [xmail] Re: AV and SA 1) Most of the popular viruses are not very big. My main virus concern = is the fast spreading email worms. This solution is blocking those nicely. There is always a potential with any solution that something might slip = by the filtering. I am not overlooking that. I may need to do some = tweaking at some point to maintain the effectiveness of this solution if a really large worm were released. 2) Think of this in terms of resource allocation. Some box in my = datacenter will need to filter AV. It will either be an email server or one of the clustered SA boxes. I hate getting complaints about email server performance, so I would rather place the load of AV scanning onto the SA cluster. Also, my SA cluster is made up of all of the old servers that = we no longer want to use for web or email hosting, so there is not really a cost associated with the SA cluster. 3) I agree this could make a mess of the bayes DB pretty quickly, so we = have left autolearning disabled. But this is not a problem, because I am not = a fan of bayes autolearning anyway. I have always felt AL only reinforced mistakes. Manual training is always the best answer for bayes in my experience. We are running ClamD on the SA boxes. The performance of ClamD for = doing a large volume of email is much better than calling clamscan each time. = If you look at the clamav pluggin code, you will see that the pluggin uses = a perl module for connecting to ClamD over TCP. So SpamD does not even = need to spawn clamdscan to talk to ClamD. It just connect directly using = TCP. I respect your opinion about filtering solutions. You obviously have invested a considerable amount of time into thinking about these = solutions. I think it is awesome that we can have such discussions about all of the various ways of solving the virus and spam problems. Personally, I = think we need to stop worrying about virus and spam separately. I think we need = a "garbage filter" that catches everything instead of separate solutions = for each thing. The way I look at it, garbage is garbage regardless of how = it smells. This solution does let me offload all of the garbage filtering = to an inexpensive cluster of boxes, which allows my email servers to = perform better. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
