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]

Reply via email to