Re: Exchange Server Virus Scanning

[Graham Toal <gtoal () UTPA EDU>]

> We have been using Antigen 8.0 from Sybari to secure our
> Exchange server
> 2003 infrastructure. Today's issues with the Kaspersky engine
> slowing/breaking mail delivery have our "powers that be"
> asking questions about which product is currently the
> industry standard for education.
>
> Can I ask if anyone out there in the world of higher Ed has
> some personal preferences or areas that I might look to
> evaluate the benefits/costs/ and drawbacks of changing horses?

There are two distinct routes you can go: the first is Exchange-specific
software hosted on the server.  Almost certainly proprietary, and almost
certainly contributing a significant amount of load on your server.  I
don't know much about that route - apart from when I last looked at
it, it was *very* expensive.

The alternative is an external filter that intercepts mail on its
way to your Exchange server.  If you go this route here are some
caveats to watch for:

First, you almost certainly want a system that is configured as a
'transparent bridge'.  This allows you to put it directly in front
of an existing mail server with almost zero configuration.  Several
commercial "spam appliances" work this way.  No freeware ones that
I know of do (which is why I'm working on creating one myself).  If
you don't use a transparent bridge, you'll either need to MX your
mail to the spam filter, or play games with internal IP addresses to
redirect the traffic to your exchange server.

Note there are other network topolgies for spam filtering - you
could put the filter at the edge of your campus, and even have it
serving more than one on-campus Exchange server from different
departments.  However if you do this, make sure that there is no
way for local mail to bypass the filter and go directly to the
Exchange server - if that happens, should a virus get on to your
campus some other way, it will propogate internally through your
Exchange server and not get caught by your spam/virus appliance.

If you buy a generic solution in a box, be careful to check that
it supports all of Micro$oft's non-standard SMTP extensions - if
you use them in your exchange server.  It's perfectly reasonable
for an SMTP-based filter to reject all but the base SMTP commands.
If you have a complex setup such as off-campus users sending mail
via the on-campus server from their home or portable systems, make
sure the spam appliance doesn't get in the way of authentication,
otherwise you may need a second exchange to handle outgoing mail
from the one that handles incoming mail.

Make sure your filter handles both viruses and spam.  Decide if
you want to tag, quarantine, or delete on sight, for both viruses
and spam independantly.  What is the interface to releasing wrongly-
tagged mails from the quarantine jail?; how well integrated is it
with your existing logon/password system?  How much maintenance
is required?  Does the system need regular updates from the vendor
to stay current?  Does it only work well if a large number of users
contribute towards training the spam filter?  Does it have a
mechanism to bypass filtering in emergencies when some bigwig raises
a stink?  Does it perform well under extreme load, such as after a
2-day outage of your network connection and then an abnormally high
load when the connection is restored?

Our experience has been that one modestly competant programmer can
build a very good spam system from freeware components and keep it
running with little maintenance needed; however if you go this
route you need to be sure to have enough people on staff who can
maintain it so that you're not dependent on one person (and so that
he can have the occassional vacation ;-) )

Just FYI our home-made spam filter uses a combination of spamd
on OpenBSD to do greylisting (the biggest win of all), SpamAssassin
on Linux to self-train a Bayesian filter (spamprobe), uvscan (NAI's
A/V product for Linux, actually freely available on their site, I'm
not sure why.  We did check that we are licensed to use it, and
it was basically a freebie under our license terms, which is
hilarious considering that the linux-based version of NAI's software
that's specifically for email checking was pretty darn expensive
when we last looked); and we also use a belt & suspenders approach
of re-checking mails which NAI said were OK with the free AV product,
clamav - and believe me it catches quite a few.  Clamav is also good
in that it filters out a significant number of phishing scams.  We
also have available code to wrap dangerous attachment types, but we
don't have that turned on at the moment because the virus filtering
alone is effective enough.  We don't have a quarantine system
unfortunately, so we're forced to tag spams rather than delete
them.  We do delete viruses on sight and do not report back to
either the sender or the recipient, to keep the noise and user
confusion to a minimum.  Reporting viruses to the sender does
nothing to help whatsoever.  Some commercial systems do this and
we're reasonably sure it's just an excuse to advertise their
product.  Do NOT buy a system that does this.


Graham