Dealing with MailScanner overloads

[John Rudd]

On Sunday, Sep 14, 2003, at 01:50 US/Pacific, Antony Stone wrote:

> The only question I have is regarding the relay address as being the
> right
> one to block.   For example, I run a primary mail server with my ISP
> acting
> as secondary MX.   All my Sobig.F emails went to their mail server,
> because
> Sobig.F went for the highest MX value, and then got relayed on to me.

The fix proposed doesn't completely block your email (because it cleans
itself out every hour), it throttles it into hourly chunks from each
incoming relay, with each chunk being MAX_PER_HOUR large.  Of course,
it's possible that you'd never catch up, or that it might take you DAYS
or more to catch up (by which time messages would have timed out, as
there's no guarantee against starvation in a method like this).

> This code would then result in me blocking my own fallback MX server,
> and I
> think this is not an uncommon situation?

It might be common, but I avoid it (at home) for pretty much this type
of reason.  I want to receive email as directly from the senders as I
can, so that I can be as aggressive about blocking as I can.  I don't
want those messages to back up onto a machine which is "friendly", I
want it to sit in the mail queues of servers that are adversarial
(either by being the originator, or by being slack about allowing such
senders to freely use their system for relaying or proxying).

(we're not using remote MX's at work for other reasons)

> So, this idea may be useful to some people in some situations,
> certainly,
> however for Sobig.F I think it would only have helped the people
> running a
> primary MX without a backup relay, or else running MailScanner on their
> backup relay as well.

Even then, you have to worry about starvation of legitimate messages if
there are common relay points involved (you get lots of email from
people at some ISP, and now you're blocking that ISP's relays because
_some_ of the users are infected, which means you're also now worried
about starvation and catching up on deferred messages from non-infected
senders).

> If we assume that future viruses may similarly target secondary (or
> highest
> MX) mail servers, we should be careful not to create some automated
> tool
> which can break that secondary-to-primary connection.

And, it doesn't do that.  It just throttles it.  But I think there are
other flaws in the solution than whether or not it's breaking that
relationship.  We've done well, at work, by rejecting certain subject
lines during the SMTP session (the fix posted here a while ago).  It
cut our sobig traffic dramatically (though, not completely -- there
must be another subject or two that my list doesn't contain).  From
10's of thousands (or even 100's of thousands) per day during the first
week to less than one thousand per day (I think we're averaging
catching around 400 per day with sophos, now; it's the first virus to
out-pace klez-h here for more than 2 days).

Luckily, at home, I've had so few of them that I only barely remember
seeing one or two of the subject lines in my nightly spam report (I
don't directly review spam messages anymore, procmail puts them into a
folder, and then the procmail log grepped for relevant entries at
midnight and then mailed to me; if I can't tell from the sender and
subject that it was a legit message, I don't mind missing it and I've
only had 2 false positives so far, both caused by my change in home
email addresses and the need to update my whitelist accordingly).  That
may be because my main domain is now going through 2 remote sites that
are probably doing virus filtering for me (I just sold that domain, but
that's the domain most likely to be attacked, so if it is getting
attacked, it's probably getting filtered 2 or 3 hops before it gets to
my home network).