URIBL_BLOCKED - the endless story

S

Strator

Verified User
Joined
Jan 19, 2011
Messages
283
Hi everyone,

For years now, I've had the problem that I am getting more spam than necessary, because I can't query URIBL via the default nameservers set up for the various servers and VPSs I've had over time. The spam delivered to my inbox typically has this in the header:

0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
* See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
* for more information.

So over the past days/weeks/months I thought it would be worthwhile to tackle this once and for all, but even though I've read the Net up and down, I just couldn't piece it together. (Or actually I thought I could, but it is just not working.) Any help appreciated, not only by myself but also by future generations stumbling across this thread (at least I can't believe that I am really the only one with this issue???).

Current status quo is that I've put the following into my named.conf:

forward only;
forwarders {
8.8.8.8;
8.8.4.4;
};

/* Disable forwarding for DNSBL queries */
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };
zone "combined.njabl.org" { type forward; forward first; forwarders {}; };
zone "activationcode.r.mail-abuse.com" { type forward; forward first; forwarders {}; };
zone "nonconfirm.mail-abuse.com" { type forward; forward first; forwarders {}; };
zone "iadb.isipp.com" { type forward; forward first; forwarders {}; };
zone "bl.spamcop.net" { type forward; forward first; forwarders {}; };
zone "fulldom.rfc-ignorant.org" { type forward; forward first; forwarders {}; };
zone "list.dnswl.org" { type forward; forward first; forwarders {}; };
zone "blackholes.mail-abuse.org" { type forward; forward first; forwarders {}; };
zone "bl.score.senderscore.com" { type forward; forward first; forwarders {}; };
zone "zen.spamhaus.org" { type forward; forward first; forwarders {}; };


The forwarders above are the nameservers that used to be in resolv.conf. In resolv.conf, I put 0.0.0.0 instead (as recommended in most instructions I found on the net), but that had my IP still blocked (even though I am the only one using it). So I put 127.0.0.1 (which I read somewhere else) but it seems like the lookups aren't working at all anymore, and instead I am getting hundreds of these error messages to my messages log:

server named[24541]: error (chase DS servers) resolving '141.in-addr.arpa/DS/IN': 8.8.8.8#53

Any help, advice, consolation? Thanks in advance!
 
8.8.8.8 and 8.8.4.4 are google's free dns servers.
The issue is that everyone uses them.

The RBL checking only allows X number of lookups per dns server per day/hour or whatever time unit they use.
Since everyone uses google's dns server, the count for those server quickly maxes out, and you can't do the RBL lookups anymore.

You'd likely need to use a dns server that has far fewer public requests.
We actually ran into the same issue a few months ago, and even tried our datacenter's dns servers, but they gave the same errors (perhaps the DC was using google too, I'm not sure)

In any case, we ended up just going with nameserver 127.0.0.1 in the /etc/resolv.conf file.

If it doesn't work for you, check
Code: 
dig apple.com @127.0.0.1
to make sure your own server can do external lookups.
If not, you might need to ensure that your /etc/named.conf has some of these settings, to allow recursive lookups for local IPs.
http://help.directadmin.com/item.php?id=115

John
 
Thanks for the quick reply. I am aware of the underlying reasons. What I thought my setup is supposed to do, is configure the system to use my own server for lookups, but then actually forward everything to Google's servers EXCEPT the URIBL lookups (for which forwarding is disabled).

Like I wrote, I also ended up putting 127.0.0.1 in /etc/resolv.conf

dig apple.com @127.0.0.1 is working fine.

Nonetheless, I am getting the errors as described above, and it appears as URIBL isn't working at all anymore (not sure how to prove this, but it is not showing up in my mail headers anymore, no errors, but also no positives, even with obvious spammer URLs).
 
It's entirely possible that they're actually blocking your IP, or your IP range..
If that's the case, there wouldn't be much we could do.
 
I've checked my logs for any signs of what is going on, and found something else (?) instead:

spf: lookup failed: addr is not a string

I am seeing MANY of those. Google came up with this thread:

http://www.gossamer-threads.com/lists/spamassassin/users/188895

Quote from thread:

I'm beginning to understand what is going on here.
Because you have a older version of Mail::DKIM, spamassassin is
unable to provide it with its own resolver, so Mail::DKIM does
it by directly calling Net::DNS, which uses IO::Socket::INET,
while the rest of the SpamAssassin's DNS resolving goes through
IO::Socket::IP. For some reason a TCP DNS request by Net::DNS
affects the socket used by IO::Socket::IP, making a variable
holding a string also get a numerical component, and moreover
it becomes tainted. In the end the getnameinfo() falls into
the snag. Weird...
Click to expand...
So now I am wondering if this is related...
 
You must log in or register to reply here.
Back
Top