RBL not working in Postfix

Ruler2112

Ruler2112

I run a small mail server and have employed multiple layers of spam blocking. (Instead of filtering, I prefer to block techniques used by spammers and thereby cut the number of false positives.)

One of these techniques is to use spamhaus.org to check to see if the sender's IP is known to send spam. I had a problem with ppp last night because of a storm and while in the process of troubleshooting that problem, realized that the RBL check isn't working. Now that the mail server is back online, I'm digging into the RBL, however I'm not finding anything unusual.

Postfix's main.cf has the following:
Code: 
smtpd_recipient_restrictions =
  reject_unauth_pipelining,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_invalid_hostname,
  reject_non_fqdn_hostname,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_unauth_destination,
  reject_rbl_client zen.spamhaus.org,
  check_policy_service inet:127.0.0.1:10023,
  permit


Spamhaus works by using a DNS lookup with the reverse of the IP you want to look up followed by .zen.spamhaus.org. Something strange is going on and I feel that the problem may be elsewhere in my system because if I ping a known spammer on their list from my mail server console:

Code: 
# ping 64.199.62.64.zen.spamhaus.org
ping: cannot resolve 64.199.62.64.zen.spamhaus.org: Host name lookup failure

64.62.199.64 was randomly plucked from the list of the last 25 IPs added to the spamhaus blacklist; I reversed the notation as Postfix does to check. Since it's listed in their blacklist, I should get a response. However, as you can see, this does not happen.

I can ping other machines on the internet without trouble though:

Code: 
# ping google.com
PING google.com (74.125.45.100): 56 data bytes
64 bytes from 74.125.45.100: icmp_seq=0 ttl=55 time=57.651 ms
64 bytes from 74.125.45.100: icmp_seq=1 ttl=55 time=66.529 ms
--- google.com ping statistics---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 57.651/62.090/66.529/4.439 ms
# ping yahoo.com
PING yahoo.com (69.147.114.224): 56 data bytes
64 bytes from 69.147.114.224: icmp_seq=0 ttl=56 time=60.047 ms
64 bytes from 69.147.114.224: icmp_seq=1 ttl=56 time=60.505 ms
--- yahoo.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 60.047/60.276/60.505/0.229 ms

I'm at a loss of where to look or what to try next. Any ideas?
 
No, you should NOT get a response to a ping attempt directed at that hostname.

Blackhole lists use DNS but they don't return a routeable address. 127.0.0.2 is returned for the query to 64.199.62.64.zen.spamhaus.org.

Use dig, i.e. "dig 64.199.62.64.zen.spamhaus.org"

On a related note, you might consider using policyd-weight rather than using RBLs directly in postfix. It works. Well.
 
I should also add that when the ping of a known spammer fails, there's a significant pause (15 seconds or more) before the lookup error comes up. When I typo a random domain name and it cannot be found (googl.com), the lookup error pops up within a second of my pressing enter.
 
Thanks for such a quick response.


mwatkins said:
No, you should NOT get a response to a ping attempt directed at that hostname.
Click to expand...

I do from a machine on a different line. Even if the DNS resolves to 127.0.0.2, I shouldn't get a host name lookup failure; only no response to the pings because there's nothing at 127.0.0.2.


mwatkins said:
Blackhole lists use DNS but they don't return a routeable address. 127.0.0.2 is returned for the query to 64.199.62.64.zen.spamhaus.org.

Use dig, i.e. "dig 64.199.62.64.zen.spamhaus.org"
Click to expand...

When I run the dig command you suggest:

Code: 
# dig 64.199.62.64.zen.spamhaus.org
]
 
BINGO! I found an article on the apple discussion forums of all places (just happened to come up via google) that suggested that many ISPs block lookups to spamhaus because they think it puts too much of a load on their system. I added one of the opendns name servers to /etc/resolv.conf and things are working as they should.

This also explains why it worked when I first set up the box and wasn't earlier today. I'm so glad I'm not completely losing my mind. :)


On a side-note, this event does prove the efficacy of greylisting and the other spam blocking techniques. Didn't hear any complaining about people getting spammed... :)
 
Is this for a host running on a "retail" (home) internet connection? I can imagine they very well might block NS requests to popular RBLs, since so many "home network administrators" would have improperly configured local name servers. Are they blocking UDP requests from all client machines sent direct to the internet (i.e. not via their name servers) or blocking requests to their name servers for certain names?

Since we are speaking of this, are you running a local name server, that is pointed to as your primary source of NS lookups in /etc/resolv.conf? I like to have a local caching name server very close to my mail servers.
 
Nope - I have a business-grade DSL line.

I didn't even bother contacting my ISP; just changed the /etc/resolv.conf file to have one of the OpenDNS servers as the first one. The two from my ISP are both still in there, just below the OpenDNS one. I'd like to use the ones from my ISP, but to me the effort required just isn't worth the benefit of saving a few jumps through the internet for DNS queries.

I am indeed running a name server on the same box as my mail server, though all it resolves is the domains on my box - everything else is forwarded. (At least I think... setting it up was very confusing to me, so I could easily be mistaken in this. It works though. :) )
 
You must log in or register to reply here.
Back
Top