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


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)
   1052 RCVD_IN_PBL
    900 RCVD_IN_UCEPROTECT3
    834 RCVD_IN_UCEPROTECT2
    678 RCVD_IN_SBLXBL
    427 RCVD_IN_UCEPROTECT1
    163 RCVD_IN_PSBL
    105 RCVD_IN_BL_SPAMCOP_NET
     15 RCVD_IN_SORBS_WEB
     14 RCVD_IN_NJABL_PROXY
      1 RCVD_IN_SORBS_DUL
    1329 Total Spam

## URIBL Statistics ##
   1060 URIBL_BLACK
    829 URIBL_JP_SURBL
    695 URIBL_OB_SURBL
    611 URIBL_SC_SURBL
    444 URIBL_SBLXBL
    440 URIBL_WS_SURBL
    427 URIBL_AB_SURBL
    163 URIBL_RHS_DOB
     42 URIBL_PH_SURBL
    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.

-Ned

Reply via email to