Re: [Exim] New mailhub/virus/spamassassin installation.

Hi Nigel, on Mon, 4 Aug 2003 12:18:59 +0100 you wrote:

> This month I am set to implement a new mail server strategy. Comprising
> two external facing mailhubs in a DMZ and two internal mail relays
> (through which all local and remote mail will pass) which will also
> provide virus scanning and spamassassin checking.

<snip>

> Because the virus checking will be performed at the second hop into my
> institution, virus checking and rejecting at SMTP time is not really an
> option. Instead I would like the relay tier to formulate a sensible
> e-mail message to return to the sender. This is particularly important
> for local senders as we use outlook here and rejecting at SMTP time with
> outlook produces a message which would definitely result in a call to
> our IT helpdesk.

OK, the first thing to say is that whatever you do, SMTP time rejection
really *is* the way to go. The key problem is that when you say "formulate
a sensible message to return to the sender", this sounds like a reasonable
thing to do but in the overwhelming majority of cases, you don't know and
can't find out the real sender, and therefore just end up contributing
(significantly) to the general problem of "collateral spam" by sending
spurious warnings (spam) to innocent third parties. Not only does this
give the junk to other people instead of yourself, but causes work for
*other* people's helpdesks (Joe User: "Help! I received an email
apparently from someone at Hull University saying I sent them a virus! Am
I infected??").

Now, I'm not forgetting "the Outlook factor", but humour me for a while.

Let's consider the main scenarios in turn:

a) incoming spam from outside

b) incoming viruses from outside, manually-generated mail (e.g. document
infected with Word macro virus)

c) incoming virus from outside, automated mass-mailing worm.

d) outgoing spam from inside

e) outgoing virus from inside, manually-generated mail (e.g. document
infected with Word macro virus)

f) outgoing virus from inside, automated mass-mailing worm.



SCENARIO A:
-----------

Consider if you can move the scanning stage to the first-hop servers; this
has *got* to be the best solution all-round. If you can't, figure out how
you can :) Seriously. If you *really* can't, you will have to consider
blackholing (not bouncing) the messages at the second hop. Otherwise,
especially if you're moving large volumes of mail, whatever you do you're
going to end up being an (inadvertent) significant spam *source*, for the
reasons above. And you'll end up with huge queues of frozen bounces. I
wouldn't personally want to blackhole messages, but if you are insistent
that you have to do the scanning at a second stage, it's better that you
make your own mail system unreliable than you clutter up other people's
mailboxes with your spam.

If you do move the scanning stage to the outside servers, you can reject
at SMTP time for this scenario, knowing that you're at least minimising
the risk of collateral spam and you're not actually generating any
yourself. And if you reject at a sensible score, the quantity of "real"
mail you reject is going to be minute if existent at all. If/when it is
from a genuine sender, then they will get the bounce resulting from the
SMTP reject. So no problem.


SCENARIO B:
-----------

As with scenario A, really. A genuine sender will get the bounce along
with whatever message you choose. The worst that might happen is (if they
run Sexchange or something equally braindead) that they get a
vague/ambiguous error due to some crap software at their end, but if
they're going to let themself get infected with viruses *and* send them
out to people *and* run crap software, then they deserve a bit of
confusion, to be honest. It's also their problem, not yours - you've
protected your users, which is presumably the primary concern.

However, this scenario is likely to be relatively rare, at least compared
to Scenario C.


SCENARIO C:
-----------

As for A and B. Very often, the mail will be coming direct from a virus's
own SMTP engine, so when you reject at SMTP time the virus will disappear
into the ether, which is a good thing.


SCENARIO D:
-----------

Whilst I'm sure you want to prevent abuse originating from your systems,
as long as you have got good policies in place I don't think it would be
unreasonable to skip spam-scanning for outbound mail, and it takes one
complication out of the equation.

If you *do* reject then consider that if a user is sending out mail that
exceeds your spam score limit, it's probably a good opportunity for them
to be educated by the helpdesk when they call to complain.


SCENARIO E:
-----------

This seems to be the one you're most concerned about especially re:
helpdesk calls. However, if someone's trying to manually send something
infected with a virus, then it would probably be a good time for someone
from the helpdesk to help them disinfect their machine/files. So surely
that helpdesk call is not such a bad thing? Let's face it, even if you
generate a bounce message and manage to get it back to the real sender,
they're still going to see the word "virus", ignore the rest and call the
helpdesk anyway, saying "I seem to be infected with a virus, what do I
do?".

If you really, really want to avoid this then you could set your systems
up in such a way that if they catch a virus originating internally, they
then generate a bounce *to the authenticated internal user* sending that
virus. In other words, via some (reliable) means of your choosing (perhaps
based on IP address or SMTP AUTH user) you generate a warning message but
make sure you send it to the real (internal) user that was responsible.
But to be honest I think this is probably way more hassle than it's worth,
and like I say the end result will be the same anyway (they'll call the
helpdesk).


SCENARIO F:
-----------

Rejecting at SMTP time isn't a problem, a user is never going to see any
error or problem. Though logging the IP and sending helpdesk to disinfect
the machine might be a good idea :)



In summary:

a) *PLEASE* please please don't generate bounces. Yes, you can do it (e.g.
by adding a header at the scanning stage and rejecting that later).
However, these days this is an incredibly bad way of doing it, especially
since you're setting up new systems and are presumably going to be
handling a significant quantity of mail. Please don't become part of the
problem. Stem the junk, don't generate more of it.

b) You really need to get the scanning/rejection as close to the point of
injection as possible, both for incoming and outbound mail. As soon as you
let known spam/viruses into your network, you're faced with the unenviable
choice of blackholing it (and thus making your mail system unreliable) or
bouncing it (and thus cluttering the rest of the net up with your junk),
neither of which is a particularly good idea. You have *GOT* to get
scanning onto your front-line servers really, and now is the time to do it
if you're planning changes. I know that load might be an issue, but you
can farm off the scanning engines to other servers if need be. The bottom
line is that if you're serious about stopping junk, this is the way to do
it.

c) *Not* doing SMTP-time rejection will barely make much difference, is
unlikely to reduce your helpdesk load, and will just result in you
generating lots of spam. The Outlook scenario will not happen that often
(especially if you're blocking inbound viruses anyway and therefore
hopefully at least limiting the opportunity for your users to get
infected) and even when it does, a user getting momentarily confused by an
unhelpful Outlook error is better than them sending viruses out to other
people.


Hope that helps,


Tim