Daniel McDonald wrote: > And, uridnsbls look at body text for uris embedded inside the message, > something that postfix doesn't do terribly well (which is why you need to > test these sorts of things after normalizing the text, which SpamAssassin > does very well..)
*nod* Yeah, that too; I've been getting annoyed at the number of messages I see that are base64-encoded for no reason I can see, which makes it hard to eyeball the raw message for rules, or to see what might have triggered a rule on a false positive. > The tack I would probably want to take would be to convince bind that the > public domains are, in fact, local, and then allow the standard rules to > query the "public" addresses, but respond to those queries from your local > rbldnsd... Mmmm, the problem the OP was asking about is "how do I make sure that only the specific URIBLs I want are active, no matter what may be added upstream?". IIRC this was asked a while ago but I don't recall any answer better than "watch the updates closely and disable any new ones when you see them". I think the reasoning was that new DNSBLs are not casually added the way new regex or non-DNS rules, and there's usually some warning on the users and/or dev lists, so you can preemptively add "score NEW_URIBL 0" to your local.cf or local rules channel. If you're redefining the tests anyway (to use local datafeed versions of any give URIBL) I would recommend putting them in a custom local TLD that won't resolve globally, to make sure you really *are* using your local copies. -kgd
