Re: Exchange Server Virus Scanning

[Graham Toal <gtoal () UTPA EDU>]

> A significant disadvantage to the SMTP proxy approach is that
> it can't reject e-mail destined to non-existent users unless
> the proxy has some sort of awareness of what your valid
> usernames actually are.

Aha!  You are not talking about a fully transparent proxy - you're
referring to a store-and-forward proxy.  In a transparent proxy,
your SMTP listener forwards the SMTP conversation one line at a
time to the MX host, so it knows immediately whether the recipient
is valid or not.  It's only the DATA statement which it doesn't
forward in real time, allowing it to scan the body of the mail
first.

If my spam filter detects that mail is being sent to a non-existent
user (actually it looks for the SMTP return code for a closed acct)
it pretends to accept the mail so that it can feed it to the spamtrap
for bayesian training.  Then it will give an error after the final "."...

[by the way my code saves up the whole body then sends it on or
not.  This was a design decision I've slightly regretted because
slow senders can time out during this wait.  It would have been
better to pass the body on in real time, check in parallel, and
then when the sender issues the final ".", blow away the connection
rather than allowing it to be sent.]

> I'm
> also a big fan of address verification, a feature available
> in later versions of Postfix, which checks that the envelope
> sender is valid, and rejects or defers messages for which
> addresses can't be verified.  Like greylisting, though, its
> use should be carefully measured against your mission requirements.

You do have to be _very_ careful not to set up a verification loop however!

> In addition, I'm a pretty big fan of SPF, although I realize
> its use in the .edu environment is somewhat more limited.

Oh, don't get me started about SPF.  It isn't an anti-spam tool
in any way.  It exists to protect the reputation of large
companies like M$. The spam will still get sent.
http://www.advogato.org/article/816.html
http://www.onlamp.com/pub/a/bsd/2004/10/28/openbsd_3_6.html?page=last

> However, at the very least your spam-scanning product should
> be SPF-aware, and weight SPF data accordingly when trying to
> classify a message as spam or not.  For example, if you get a
> message claiming to be from a gmail.com account that
> originated from somewhere other than the hosts gmail.com
> identifies as valid senders, I think that raise the suspicion
> level considerably.

That only works for a set of explicitly whitelisted senders.
Spammers are the biggest users of SPF, so just testing for a
valid SPF record is actually a good indicator of spam!

> victims.  However, I'm not a big fan of silently dropping
> messages, either, as this violates the SMTP spec.

Oh - I didn't mean *completely* silently.  There's an appropriate
SMTP return code.  I just meant silently in terms of notifying
people with chatty emails.  If the sender's MTA wants to
bounce back a message after getting an SMTP return code it's
entirely welcome to.

> I think a better way to handle this sort of thing is to have
> your AV software scan messages as they arrive but *before*
> they get queued locally.  Messages that pass the scan get
> queued normally, but those that fail to pass never get
> accepted in the first place; a 5xx rejection is simply handed
> back to the sending host, which then has the responsibility
> of handling that rejection correctly.

Yep, that's what mine does.  I didn't explain it clearly.

> This sort of thing
> should be possible with reasonably modest hardware and free software.
> In particular, clamav+clamsmtpd+Postfix can do this sort of
> thing very easily, and very, very well.  Again, this sort of
> thing probably isn't suitable for extremely high-volume
> sites; its use should be weighed against needs.

Why not high volume sites?  We have about 20,000 active accounts,
most of whom are targetted with dozens of spams per day if not much
actual email.  Haven't seen much of an issue (at least after we
added the greylisting).  Mail is nice in that it scales well, just
from having the MX mechanism, never mind fancy hardware load balancing
etc.


Graham