http://bugzilla.spamassassin.org/show_bug.cgi?id=4157
Summary: Reducing System Load with Temporary Rejections - Penalty
Box
Product: Spamassassin
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P5
Component: spamassassin
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
I've discovered a trick that has significantly reduced the system load using
Spam Assassin and I'm thinking that the idea should be incorporated into SA and
done better than I am doing it.
Often a spammer is sending the same spam over and over to different people and
SA correctly identifies the same spam - but at a cost of load on the system.
Sometimes spammers pound the server over and over with dictionary and various
other attacks. This suggestion is geared to reducing the load on the system by
slowing down the sammers to temporary errors using what I call - a penalty box.
The idea is that once a from address has sent a spam any email from that address
will get a temport error (come back later) from the MTA for the next 5 minutes.
If the sender is sending ham - the message will eventually get through. But in
mant cases spammer make only one attemtp and move on.
I'm using Exim and most of what I'm doing is at the MTA level. Basically
spammers are put into a temporary black list that is used to retern temporary
errors. Sometimes I put the IP address in a similare list to return temp arrors.
Every 5 minutes the list is emptied from a cron job. And - it is working very
well in reducing the load of having to process the same spam over and over, as
well as reducing the load of other "sins" that spammer commit.
So - how does this tie into Spam Assassin? It would be handy if SA could
maintain a short lived database (DB file? Text File?) that contained a list of
recient spammers or spam information in a way that can be read form Exim or
other MTAs - or SA itself - for the purpose of reducing system load from
spammers that hammer the server over and over in a short period of time. It's
sort of a recient sinners list and can contain either from addresses or IP
adresses of offenders.
This is similar in many ways to greylisting but with greylisting you penalize
everyone new with delays. This method only penalizes by delays those who have
previously offended. It isn't as effective as greylisting in some ways - but it
eliminates the delays greylisting causes on new ham that I consider to be
unacceptable.
The penalty box idea is working very well for me and it gets rid of some nasty
load spikes that used to hit pretty hard. I think it's worth considering ways to
reduce load by reducing the number of messages SA has to process.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
