You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Paul Griffith <pa...@cse.yorku.ca> on 2007/09/12 17:17:47 UTC

Summary - Handling Spam Surges

Here is summary of all the responses. Thanks to all who resonded, your  
suggestions have been very helpful.

We will

- reduce the number of SA max-children
- look at ratelimit in exim
- only spam scan messages under a certain size

====================
Aaron Wolfe
We reduce the messages bound for SA to less than 10% of our traffic by
a combination of postfix UCE checks, a couple very accurate RBLs,
selective greylisting and our own whitelist.  When the surges/DOS happen,
they tend to increase the number of messages thrown away but rarely effect
the volume running through SA.

Dave Funk
With only 2GB of memory you could die in swapping hell with
max-children=150. Each SA process will take 30~60Mbyes of RSS
(depending upon addition of optional rules & plugins).
This means that 150 children could take 5GB of ram, thus hitting
your swap hard. Either add more RAM or reduce that max-children.

To prevent melt-down from surges/DoS attacks some kind of incoming
SMTP rate limiting is the way to go (with that small a setup).
This would be done by your Exim config, ask the Exim list for
suggestions on this.

Michael Scheidell
Handle it in the MTA.
Best to block all unknown recipients at least.

The rest of what to do in the MTA depends on what MTA you have.
Once the MTA is finished with it  then pass it to SA.  If under attack,
only thing you can do to help SA is disable network tests till its done.

Visit the mailing list or FAQ's of the MTA you are using for more help
on this.

(example:  smtp connection limiting, session tarpiting, even some
firewall rules to limit concurrent connections might help)
===========================

Thanks
Paul