There seem to be an abundance of DNSBLs out there nowadays. Here are my observations on two, and an implementation question. The Good, the Bad and the Ugly:
GBUdb.com's truncated list (http://www.gbudb.com/truncate/) went public in May and seems to work very well, catching a lot of things missed by other RBLs, with <1% false positives. YMMV. It's related to Message Sniffer, a commercial anti-spam package, and is fully automated (no user submissions). I'd hazard that a starting score of 2.0 might be appropriate. header RCVD_IN_GBUDB_TRUNC eval:check_rbl('trunc-firsttrusted', 'truncate.gbudb.net.') describe RCVD_IN_GBUDB_TRUNC Connecting IP in truncate.gbudb.net. score RCVD_IN_GBUDB_TRUNC 1.5 tflags RCVD_IN_GBUDB_TRUNC net I've also had good experiences with bl.mailspike.net and the dynamic and noptr lists on spamrats (all.spamrats.com 127.0.0.3[67]). WPBL seems to be less useful than two years ago, with too many FPs. QUORUM.TO is a recent project of Julian Haight, creator of SpamAssassin. Some data is commercial, but there's also a public list, described at http://www.quorum.to/publicbl.html. I'm disappointed by my tests so far, showing its "base rule" as very fuzzy in distinguishing between ham and spam. In addition, quorum.to doesn't follow RFC 5782 convention, for example in its negative response to 2.0.0.127.list.quorum.to. In fact, I was most hopeful of using it as a cleanlist of hosts that had deliberately validated themselves, as it gives a positive response (127.0.0.0) for IPv4 addresses it has no data for. I've been trying it out with the following rules, but I wouldn't suggest anyone else does at the moment: header __RCVD_IN_QUORUM eval:check_rbl('quorum-firsttrusted', 'list.quorum.to.') describe __RCVD_IN_QUORUM Connecting IP in list.quorum.to. tflags __RCVD_IN_QUORUM net header RCVD_IN_QUORUM_BLOCK eval:check_rbl_sub('quorum-firsttrusted', '^127\.0\.0\.2$') describe RCVD_IN_QUORUM_BLOCK Connecting IP failed quorum.to tests score RCVD_IN_QUORUM_BLOCK 0.1 tflags RCVD_IN_QUORUM_BLOCK net header RCVD_IN_QUORUM_REJECT eval:check_rbl_sub('quorum-firsttrusted', '^127\.0\.0\.[45]$') describe RCVD_IN_QUORUM_REJECT quorum.to has been asked to dirtylist connecting IP score RCVD_IN_QUORUM_REJECT 0.01 tflags RCVD_IN_QUORUM_REJECT net meta RCVD_IN_QUORUM_GOOD (! __RCVD_IN_QUORUM) describe RCVD_IN_QUORUM_GOOD Connecting IP not listed on quorum.to (or servfail) score RCVD_IN_QUORUM_GOOD -0.1 tflags RCVD_IN_QUORUM_GOOD net As you can see, the only way to turn use it as a list of clean IPs is to negate any response. My problem, rather theoretical, is that as well as catching an NXDOMAIN response, the cleanlisting (RCVD_IN_QUORUM_GOOD) will trigger on bad configuration (SERVFAIL) or network problems, and it appears SA's Dns module treats all those conditions the same. Intuitively, I'd like to be able to do something like (invalid code follows): header RCVD_IN_QUORUM_GOOD2 eval:check_rbl_sub('quorum-firsttrusted', 'NXDOMAIN') or maybe header RCVD_IN_QUORUM_GOOD2 eval:check_rbl_sub('quorum-firsttrusted', '^$') Does anyone else think work on providing such a facility for negative cleanlists might be worthwhile? CK
