This is a discussion on Re: Spamassassin+amavis - SpamAssassin ; Gary V wrote: > > 6 seconds seems somewhat typical. Mostly due to network tests. Some > RBLs are no longer and you could turn the non functional RBL rules off > by setting to 0. I'm not sure which ...
Gary V wrote:
> 6 seconds seems somewhat typical. Mostly due to network tests. Some
> RBLs are no longer and you could turn the non functional RBL rules off
> by setting to 0. I'm not sure which ones though. Maybe someone else
From my own stats of hits against DNSBLs and URIBLs for the last ~1000
spam (these results are typical for me):
## DNSBL Statistics ##
1223 RCVD_IN_ZEN (Spamhaus PBL, SBL or XBL)
1067 RCVD_IN_UCE_COMBINED (UCEPROTECT level 1, 2 or 3)
1329 Total Spam
## URIBL Statistics ##
1329 Total Spam
Spamhaus Zen is highly effective for me and hits on >90% of spam when
used as -lastexternal, and is the only DNSRBL I'd trust to use at the
smtp level. I've also added custom rules for UCE Protect levels 1-3 and
PSBL blacklists. I wouldn't use either at the smtp level as they do
generate the occasional FP, but UCE Protect is useful in a scoring
environment such as SA. For me NJABL, SORBS and pretty much anything
else are a waste of space relative to the effectiveness of Spamhaus. If
you can implement Spamhaus Zen at the smtp level then blocking ~90% of
spam before it ever reaches SA is hugely beneficial to system load and
the rest could probably be dropped from SA with minimal impact.
I also find the URIBLs to be very effective, especially URIBL_BLACK.
Between Bayes and my top DNSRBLs and URIBLs, nothing gets through -
everything else is just bumping the score further past the spam threshold.
I'd recommend taking a look at your own stats to see which are effective
for you and maybe drop those that are ineffective or, better still, look
at ways to pre-filter spam at the smtp level before it ever reaches
amavisd/SA so as to reduce the load (for example,
http://wiki.centos.org/HowTos/postfix_restrictions). A good setup like
this can easily block the vast majority of spam at the smtp level
meaning that your server/SA now primarily only has to deal with the ham
and an insignificantly small proportion of spam.
BTW, checking my logs I note typical delays of 4-6secs on a 3.0GHz quad
core server with 4GB RAM running 4 amavisd child processes that handles
a very light load.