Re: [Hampshire] Spamassassin shortcircuiting

Hi Andy,

Many thanks for your useful reply :)

> Try to get local copies of the DNSBLs. Run a local caching server
> for those you can't get fully locally. Reject more spam based on
> SMTP violations like earlytalk or HELO syntax. Do greylisting.
> Check your spamd box isn't running out of RAM. Outsource your
> antispam. :)

This sounds like a good idea, thanks. The boxes are actually not bad spec
and we have 12 of them in a cluster.. sit at around 0.2 load, so not being
worked too hard really. It was just the scanning time per message that
raised concerns as the inqueue often grows larger than the outqueue!.

>> I've tried the SA 'shortcircuit' plugin, but have had negative results
>> using this. Does anyone know of a way you can get SA to stop processing
>> the message when it hits the threshold score? Ie if you have
>> required_hits set to 4.3, could you stop looking at rules after this score
>> is hit?
>
> Not really because later tests may provide a negative score which
> would bring you down below the threshold, thus by using
> shortcircuiting you will classify a higher percentage of legitimate
> email as spam.

This is a very valid point which I hadn't given any thought. I'll
probably lay off the shortcircuiting for now! (Although I think the SARE
rules do some of their own anyhow..)

I've used a lot of sendmail's spam-fighting functions, like greetpause and
client/rate control etc. Our main problem seems to be dictionary attacks
on one of our main domains! The badrcptthrottle option in sendmail seems
to be a good choice, however because sendmail only delivers in queue mode,
this is no good for me :(


Thanks again for your help

Duncan