Re: Exchange Server Virus Scanning

[Graham Toal <gtoal () UTPA EDU>]

> One of Antigen's prime selling points for us was that they ran 8 (more
> now) different scanning engines including Kaspersky, Sophos,
> Norman, NAI, and others. Do the other products you've talked
> about have the multi-engine aspects as well?

My experience from doing this on a home-made system is that
two give the best value per $.  After that it's diminishing
returns - not from the cost of the software, but from the
cost of the machine to run it on.  These guys can eat CPU.

As I've mentioned before, we got the biggest win from adding
Greylisting - which doesn't just reject spam, it cuts your
virus load down by about 90% as well.  Before we added
greylisting, we had two spam/virus servers distributing the
load and they were starting to creak; it was about time to
add more, when we put in the greylist stage instead.  Now
the entire campus load can be run comfortably on one spam/virus
filter (plus one greylist filter in series - the greylist
system has almost zero load even in heavy traffic - it's
doing very little more work than a router)

If you are looking at commercial appliances, do ask if they
can offer greylisting.  It really is worth it.  There's a
couple of small gotchas however.  One is that if you have
multiple spamfilter or mail servers and they are load balancing
(equal valued MX records, or hardware load-balancing like an F5)
then you *must* get a greylist solution which shares its state
between the multiple servers in real time, otherwise you can
have senders back off to a different MX host and end up suffering
multiple greylist retry delays.

I'm not aware of any freeware systems that do this properly.

We got around the problem by having a single greylist appliance
in front of our two spam/virus appliances, which forwarded the
incoming calls to one of the two boxes for load balancing.  We
don't need load balancing for the greylister as the overhead is
tiny; we do need redundancy which we get from having the one
greylist box wired so  that if it fails, another one takes its
place -- or at least we should, which was the plan, but we put
it on hold for various reasons.

Tools like Heartbeat from the High Availability Linux project
make transparently adding failover relatively easy.

      http://www.linux-ha.org/SuccessStories


Graham