Dealing with MailScanner overloads

[Michael Janssen]

On Sun, 14 Sep 2003, Julian Field wrote:

> What do you all think of this suggestion? Any ideas for improvements or
> useful ways to implement it?
>
> 'm thinking along the lines of adding entries to the sendmail access db. I
> can't remember if I need to restart sendmail after changing the access db,
> but a way of avoiding having to do that would be good.
>
> I would probably implement it as a Custom Function, as it's a side issue
> from the main point of scanning messages.


Custom Function sounds good in order to make it usefull for more than
sendmail: otherwise the amount of configoptions (on our system:
database server, user and password, database name, table name - given
that the table layout is managed by MS) needed for only this feature
would possibly make a cronjob solution look smarter (which is easy done
by the way). With a Custom Function, anybody how can, can write it as
appropriate.

On the other hand *dropping* those messages with faked sender addresses
is worthy enough to make it - in which way ever - the default: Think of
the impact of misguided VirusWarnings or just the MailDeliveryReports
with VirusWarnings to unknown recipients: under Sobig-F we had to tell
people on the phone just to do nothing on such warnings. It would be
"normal nowadays" :-(

It wouldn't reduce the load much, but it's possibly easier to implement
as a default: Could MailScanner detect that it receives much of one type
of virus and set such a virus to "Silent Virus" in case the admin hasn't
allready? With Sobig-F it would be neccessary to also surpress the
virus-messages alltogether (i.e. set "no" on a per virus "Still Deliver
Silent Virus" option). A mail to the desk in order to make the setting
permanent is also helpfull.

In other words: a feature were MailScanner detects new virusses as
mass-mailing-worms and stops notifcations about them would reduce the
trouble we have about misguided warnings.

Michael

>
> > > >I've been successfully using MailScanner on a Linux server,
> > > until this
> > > >weekend, when it was overwhelmed with Sobig.F messages.  The
> > > mqueue.in
> > > >directory was growing at 90 files/minute, and contained a
> > > backlog of over
> > > >10,000 messages by the time I noticed the problem.  This was
> > > on a lightly
> > > >loaded 1.5GB, 2GHz P4 server, which never gets more than
> > > 1000 legitimate
> > > >emails per day.
> > > >
> > > >To get things back under control, I looked through the
> > > maillog file for the
> > > >relays that were sending the most messages, and blocked them
> > > with iptables.
> > > >There were a lot of them, so my plans for Sunday were
> > > trashed.  However, it
> > > >made me think of a way to automate it, but post-processing
> > > the mail log is
> > > >not the best point to tackle this problem.  Ideally, it
> > > should be done as
> > > >the mail arrives, possibly by simply refusing the SMTP
> > > connection, which is
> > > >where I'm out of my depth.  Here's what I think is required:
> > > >
> > > >Initialise an empty hash table, keyed by IP and containing a
> > > timestamp, a
> > > >usage count and a blocked flag.
> > > >
> > > >For each message:
> > > >     Get the IP of its relay.
> > > >     If not already in the hash table Then
> > > >         Create a new entry for the IP with usage count 1 and current
> > > >timestamp.
> > > >     Else
> > > >         Increment the usage counter and update the timestamp.
> > > >
> > > >         If usage > MAX_PER_HOUR and not already blocked Then
> > > >             Block the IP using:
> > > >                  iptables -I INPUT -s $ip -j DROP
> > > >                  iptables -I OUTPUT -d $ip -j DROP
> > > >             Mark the hask table entry as blocked.
> > > >             Append the IP and timestamp to the log file.
> > > >         Endif
> > > >     Endif
> > > >EndFor
> > > >
> > > >Every hour, scan the table and remove any entries older than 1 hour.
>
> --
> Julian Field
> www.MailScanner.info
> Professional Support Services at www.MailScanner.biz
> MailScanner thanks transtec Computers for their support
>