On 12/22/2020 6:56 PM, Grant Taylor wrote:
Is there a way to bypass RBL checks for a specific address? I've tried
the all_spam_to option, but it looks like it artificially lowers the
score and still runs normal tests. I'd like to disable RBL checks for
one address.
Grant,
First, I'm NOT an expert on all of this - so somebody might be able to
follow up with BETTER information, but this will hopefully point you in
the right direction.
So at some point, I think 10+ years ago, I needed to do this, and
instead of doing this at the spam filter level - I found that it worked
well to do this via BIND - so this works if you're using your own
locally-hosted BIND server for resolving DNSBL queries. So, for example,
if you qualified for use of the free version of SpamCop (as an example),
and you wanted to whitelist the IP 1.2.3.4, you could add the following
to your named.conf file:
zone "4.3.2.1.bl.spamcop.net" in { type master; notify no; file
"master/null.zone"; };
Then add another such record for each DNSBL that you use. Then the
"master/null.zone" file can be the following EMPTY zone (or something
like this - change as desired! This might not even be the best or
"right" way to do this - this is just what I had in that null.zone file
when I was doing this 10+ years ago):
$TTL 52w
@ IN SOA root.localhost. root.localhost (
2005012001 ; serial
52w ; refresh
52w ; retry
52w ; expire
52w ; ttl
)
@ IN NS localhost
localhost IN A 127.0.0.1
So by referencing an empty zone file, that way, each "zone" entry just
points to this one file, for maximum efficiency and caching, and you
don't have to reenter this for each zone. In the named.conf file, I
think each zone statement (my 1st example abovw) would go AFTER the
"options" section, but before the "includes" section. Obviously, if you
suddenly needed to do this for 10s of thousands of IPs or hostnames,
then maybe it would then start to have resource/maintenance issues - but
on a smaller scale, this works great!
HOWEVER - This was so long ago, that I don't know if this STILL works in
more recent version of BIND without causing issues? It is possible that
in more recent version of BIND, DNSSEC might interfere with being able
to do this?
So ANOTHER option might be to use the newer "response-policy" feature -
my first idea was a sort of hack - but this "response-policy" might be
more intended for exactly this purpose. So do a search on the following:
"response-policy" "BIND" "NXDOMAIN"
...with each in quotes, as shown, for instructions on how this is done.
So I think the example above, if implemented using "response-policy",
would be the following:
response-policy {
4.3.2.1.bl.spamcop.net IN CNAME .
};
Or something like that. Double-check my syntax. It might be wrong! So,
again, I've never done the "response-policy", so this is just to get you
started and point you in the right direction. If someone comes along and
corrects my possible mistakes, or provides BETTER info - that is
excellent - in the meantime, hopefully this will point you in the right
direction, or give you some ideas.
-- Rob McEwen, invaluement
