You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mike Jackson <mj...@barking-dog.net> on 2006/12/01 17:55:03 UTC

Help for old-school SA?

I work for a large hosting provider. Some of our hosting accounts are 
(effectively) stuck using SA 2.63, since they are using older Redhat 
installs coupled with older versions of the Plesk control panel. (Why 
stuck? Because Plesk and ES2.1 won't recognize post-2 versions, provide 
proper startup options, or write out the proper header-munging rules.) 
Needless to say, SA 2.63 isn't very effective anymore. I will often set up 
SARE rulesets and RulesDuJour, install & configure Razor, lower the Bayes 
autolearn thresholds and minimum message counts, make sure Net::DNS and 
Mail::SPF::Query are installed, and use RBLs within Qmail. It's not all 
that effective, or at least not as effective as they want.

So, what other tools can I add to my arsenal under these circumstances?

Re: Help for old-school SA?

Posted by Kris Deugau <kd...@vianet.ca>.
Mike Jackson wrote:
> I work for a large hosting provider. Some of our hosting accounts are 
> (effectively) stuck using SA 2.63, since they are using older Redhat 
> installs coupled with older versions of the Plesk control panel. (Why 
> stuck? Because Plesk and ES2.1 won't recognize post-2 versions, provide 
> proper startup options, or write out the proper header-munging rules.) 
> Needless to say, SA 2.63 isn't very effective anymore. I will often set 
> up SARE rulesets and RulesDuJour, install & configure Razor, lower the 
> Bayes autolearn thresholds and minimum message counts, make sure 
> Net::DNS and Mail::SPF::Query are installed, and use RBLs within Qmail. 
> It's not all that effective, or at least not as effective as they want.
> 
> So, what other tools can I add to my arsenal under these circumstances?

I'm not sure what sort of mail is slipping through in your case, but 
I've got three (fairly heavily tweaked) 2.64 installs that are still 
"good enough".  I've kept the default threshold of 5 (except for a few 
specific customers, and three ISP role accounts).

-> A well-trained Bayes DB is crucial.  One system's Bayes db is 4+ 
years old, and only occasionally misfiring.  I regularly feed missed 
spam into it;  occasionally I get a ham or two to feed it.  I've pushed 
the autolearn-as-ham threshold down to -0.1.

-> There are a few known security/DoS issues with 2.63.  Move heaven and 
earth to go to 2.64;  it's a drop-in upgrade that should be painless.

-> The SARE stocks ruleset has helped eliminate *most* of the 
image-based stock spam I've been seeing.  IIRC I'm also using the 
"adult" ruleset;  I can't afford too many more due to memory limits.  :/

-> The SURBL patch for 2.6x has been *very* useful - less so now than it 
was when it was released maybe, but it still pushes a fair chunk of the 
spam over the threshold.

-> Local rules for whatever is slipping through are generally pretty 
effective;  eveyone gets a somewhat different mix of spam.  I have rules 
that would be pretty much useless for anyone else, because they rely on 
specific aspects of *this* particular mail system.

-> For an ISP, customer feedback is critical.  Over time, I've managed 
to teach a few customers exactly how to forward mail they've downloaded 
so I can feed it back to Bayes ("right-click, forward as attachment" 
works in everything but Outlook and Eudora IIRC), and check the raw 
message for possible local rules.  Accumulating a useful global 
whitelist is also useful - some perfectly legitimate bulk senders just 
don't have a clue, so whitelisting them at some layer makes sure 
customers get their joke-of-the day spam^H^H^H^Hmail.

-> A little bit of statistics can do wonders for customer opinions. 
"I'm complaining about 5 spams a day" becomes "Wow, keep up the good 
work!" when you point out that the filter has diverted 500 spams a day 
from their inbox.  This is particularly effective if they haven't had 
problems with legit mail getting tagged.

-kgd

Re: Help for old-school SA?

Posted by Mike Jackson <mj...@barking-dog.net>.
> First thing: find the patch for the URIBL rules and get that enabled.  It 
> will probably catch 90% of the spam making it through.

Thanks for the suggestions. Actually, I was mistaken; the server that 
prompted this request had 2.61 installed. I upgraded him to 2.64, and 
tracked down the SpamCopURI plugin. But, he's already using every 
conceivable RBL at the SMTP level, so it may not help a lot.

Re: Help for old-school SA?

Posted by Loren Wilton <lw...@earthlink.net>.
First thing: find the patch for the URIBL rules and get that enabled.  It 
will probably catch 90% of the spam making it through.

It would probably be possible to build an eval test for 2.63 that would do 
what FuzzyOCR does, but it woudl take some work by someone that knows perl 
(which isn't me).

        Loren

----- Original Message ----- 
From: "Mike Jackson" <mj...@barking-dog.net>
To: <us...@spamassassin.apache.org>
Sent: Friday, December 01, 2006 8:55 AM
Subject: Help for old-school SA?


>I work for a large hosting provider. Some of our hosting accounts are 
>(effectively) stuck using SA 2.63, since they are using older Redhat 
>installs coupled with older versions of the Plesk control panel. (Why 
>stuck? Because Plesk and ES2.1 won't recognize post-2 versions, provide 
>proper startup options, or write out the proper header-munging rules.) 
>Needless to say, SA 2.63 isn't very effective anymore. I will often set up 
>SARE rulesets and RulesDuJour, install & configure Razor, lower the Bayes 
>autolearn thresholds and minimum message counts, make sure Net::DNS and 
>Mail::SPF::Query are installed, and use RBLs within Qmail. It's not all 
>that effective, or at least not as effective as they want.
>
> So, what other tools can I add to my arsenal under these circumstances?