Jack put forth on 11/2/2010 3:56 PM:
> I'm just checking all my spam settings on my postfix servers and I wanted to
> know if anyone is using any newer RBL's than below?
>
> (which have a low false positive rate)
Low FP noted, FSVO "low FP".
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client psbl.surriel.com,
> reject_rbl_client ix.dnsbl.manitu.net,
> reject_rbl_client b.barracudacentral.org,
This response may be a little more than what you're asking for, but if
you implement of all of these suggestions you may be pleasantly
surprised by how little spam you see afterward. :)
That's probably plenty you have there already. In fact it may be too
many. I'd suggest analyzing your logs and eliminating any of those that
aren't catching anything regularly. You've got a lot of overlap there,
each successive query having less and less of a chance to do you any
good, at the cost of 5 dns lookups per inbound ham. I did such an
analysis over a year ago and cut my reject_rbl_client config from 6 to
only 2 dnsbls. Currently I use zen and surriel and they don't even
catch much due to the rest of my A/S config, although zen catches more
than surriel. YMMV and all that.
I suggest you try out the following as well and see what results you
get. The DBL should catch a bit of pesky snowshoe spam that the dnsbl
combo above does not:
reject_rhsbl_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.org
reject_rhsbl_helo dbl.spamhaus.org
You may also consider implementing Sahil Tandon's header check tcp
server daemon which also catches a fair amount of snowshow and other
spam. It checks the from, message-id, and reply-to headers against
Spamhaus DBL, SURBL, and URIBL. Instructions for using it are comments
in the perl file itself.
http://people.freebsd.org/~sahil/scripts/checkdbl.pl.txt
And, as always, for performance and other reasons, you should be using a
local dns resolver, not your ISP's, for dns queries originating from
your Postfix server. If you're not already using a local resolver I
recommend you install a caching resolver directly on the Postfix server
and change your /etc/resolv.conf to "nameserver 127.0.0.1". You may
need to restart Postfix for this change to take effect, especially if
running in a chroot. I use pdns-recursor on my Postfix host. Combining
the rhsbl checks to dbl.spamhaus.org and the query to the same dnsbl
made by Sahil's daemon yields _four_ queries to the same destination for
the same information. Using a local resolver cuts this to a single
remote query and 3 cached queries, decreasing your response times,
increasing Postfix performance, and decreasing the load on the dnsbl
servers and the public infrastructure. Use something like
pdns-recursor. It's a win for everyone, esp you.
Last, but not least important by any means (understatement), you may
wish to try out:
http://www.hardwarefreak.com/fqrdns.pcre
Implement this as:
smtpd_recipient_restrictions
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
...
check_client_access pcre:/etc/postfix/fqrdns.pcre
...
Put it above all of your other anti-spam checks (not including the
inbuilt Postfix restrictions such as reject_unlisted_recipient) since
local table lookups are infinitely faster than dns lookups, although not
so much so if you have pdns-recursor. This set of PCREs targets rdns
names of mostly residential broadband IPs in various countries. It's
target is zombie spam sources. It catches things Spamhaus' PBL doesn't
and can stop zombie spam before the CBL lists the IP, which is very
nice. I used to frequently get hit by zombie spam here before it was
listed in CBL. No more. This set has pretty much put an end to that.
It has been noted that these PCREs will infrequently FP on some MTAs
sending from within ISP IP space that contains both residential and
small business customers on an ADSL or cable network. If such cases
arise, simply whitelist the IP. For each one of these that may occur,
you're protecting your mailbixes from thousands of zombies within the
same ADSL/cable network.
--
Stan
