[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: spam fighting and the bts

On Sat, 3 Apr 2004, Blars Blarson wrote:

> 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.

There's a bigger problem.  Twice in the last 4 days the queue has been
bombarded with spams.  Colin cleaned out 15000 a few days ago, and yesterday,
I cleaned out 21000.

I don't know if CA will help to solve this, but it's a rather serious issue.

Reply to: