spam fighting and the bts
First the good news: the various tweaks I've been making to
spamassassin seem to have significantly reduced the amount of spam
making it into bugs. We are now using SBL, DSBL, and spamcop BL to
help score bugs, as well as razor2. I've also tweaked the spamassassin
rules based on real spam and ham. (I reduced the scores on a few
rules non-spam was sometimes hitting, as well as adding new rules,
revising some old ones, and upping the score on a few.)
The frequent running of bugclean on the list of known spam-target bugs
has significantly reduced the average amount of time spam stays in a
bug.
My version of crossassasin is almost ready for integration into
spamscan. I plan on just adding a X-CrossAssassin-Scores: header at
first, and look at how it does on the real queue. Hopefully it will
go in tonight or tomorrow.
The bad news: It is now taking several seconds to run spamassassin on
each bug. This isn't a local problem on spohr, but just the time the
DNS lookups and razor lookups take. When spammers are hitting the BTS
hard, as happened yesterday, it can take several hours to catch up
with the backlog. Unfortunately, yesterday wasn't particularly bad
compared to recent days. Right now spamscan has been running for over
an hour and there are about 700 messages left to process.
Short-term, we can add procmail rules for massive spam runs, or just
give up on some of the tests for now.
Longer-term, I think spamscan needs to be rewritten to processes
multiple messages at a time.
--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
Reply to: