• Sp chevron_right

      HOWTO: Query Spamhaus Safely

      pubsub.slavino.sk / spam_resource · Wednesday, 3 November, 2021 - 12:00 · 2 minutes

    spamhaus.jpg
    You'll recall me warning recently that using Spamhaus data to protect your mail server is a bad idea if you're using open or public DNS resolvers . TL;DR? Spamhaus is worried about too much traffic via public channels but blocking is implemented in a way that makes it effectively intermittent and potentially confusing. You could be fine for weeks and then suddenly you start bouncing all inbound mail accidentally. Or you could be querying a resolver that never shows ANY bad IPs to block, losing you out on the good spam filtering benefit that you were hoping for.

    Here's what to do about that.
    1. No matter how you implement DNSBL usage, check your logs periodically. In the case of Spamhaus, look for the "127.255.255" response codes. That will indicate that your attempt to query Spamhaus data is being blocked , so you've got a problem. That problem is probably interfering with the delivery of legitimate mail.
    2. Test and make sure you are getting a response proving use of Spamhaus data. If you're a unix nerd, type "host 2.0.0.127.zen.spamhaus.org [IP address of your DNS server]" from the command line on your mail server. Make sure you get responses that say 127.0.0.2, 127.0.0.4, 127.0.0.10. That shows that your DNS resolver can get through to Spamhaus (at least for test entries). If you never get any response other than NXDOMAIN, it means your resolver isn't able to get data from Spamhaus and you'll never block a single piece of spam that way. Either the DNS server is not able to connect where it needs to, or you've typo'd something in your configuration. (Google Public DNS seems to only give NXDOMAIN responses to Spamhaus query attempts, for example.)
    3. Install and run your own DNS resolver (server) locally. This used to be a bit sketch back in the day. The common DNS software "bind" was such a magnet for exploits in the past that it drove me to stop hosting my own DNS. Things are slightly better today. There's a great caching DNS resolver called Unbound that will do exactly what you need. I've had smart friends like Tim Wicinski and John Levine tell me it is safe and that it works well, and I'm happily using it myself nowadays.
    4. Sign up for the Spamhaus Data Query service. They provide you with what amounts to an API key (a little short bit of text that will be unique to your queries) and you query the DNSBL via "[key].zen.dq.spamhaus.net" instead of "zen.spamhaus.org" --  allowing Spamhaus to see this traffic as you and you alone, not grouping any usage data together with that of a whole ISP or all users of a public resolver. Spamhaus offers a 30 day free trial of DQS access and say that an annual subscription to the Spamhaus data for commercial use starts at $250/year. Spamhaus also clarified for me that they provide free access for lower volume non-commercial use.
    The point of this is so that Spamhaus sees your query traffic as from you and not all grouped together with all the traffic from your ISP or from a public DNS resolver. This makes you less likely to hit their unpublished query traffic limits through no fault of your own. (It does not, however, provide a free license to query Spamhaus millions of times a day.)

    Which of these steps should you follow? All of them.

    Značky: #howto, #spamhaus, #dnsbls, #Network

    • Sp chevron_right

      Be careful: Using Spamhaus with open resolvers is bad news

      pubsub.slavino.sk / spam_resource · Tuesday, 19 October, 2021 - 12:00 · 2 minutes

    spamhaus.jpg
    Do you use any of the Spamhaus blocking lists (DNSBLs) to protect yourself from inbound spam and email threats? If so, you're not alone. The Spamhaus data is quite popular and used by many ISPs as a front door gatekeeper for IP (and domain) reputation.

    If you do use any of Spamhaus's DNSBLs, though, make sure you're not doing it via a public DNS resolver or via any DNS server that is attempting a high volume of queries against Spamhaus without being registered with them. If you do, you risk the queries triggering blocks simply due to the sheer volume of DNS traffic Spamhaus is receiving. Meaning you'll end up blocking mail that wasn't spam and that you probably didn't mean to block.

    Here's how to catch that. Look in your server's mail log for response codes or response text from Spamhaus queries. For text responses, look for things like "Error: open resolver; https://www.spamhaus.org/returnc/pub/74.63.26.239 " and look for return codes like 127.255.255.252, 127.255.255.254 and 127.255.255.255.

    If you're seeing anything like that in your mail logs, you're blocking non-spam accidentally-- you're making mail bounce that Spamhaus did not intend to reject. If so, please review Spamhaus's guidance for what to do in this instance .

    Let me be clear: I strongly recommend AGAINST using public DNS servers to query Spamhaus DNSBLs. In my testing of various common public DNS servers, I saw problems. In particular, Spamhaus intermittently rejects queries from Quad9's public DNS servers with the "open resolver" error, and in the case of Google Public DNS, Alternate DNS, Yandex and Fourth Estate's public resolvers, all queries resulted in NXDOMAIN (no DNS result found) even for IP addresses that I know were listed on one or more Spamhaus DNSBLs.

    In my testing, I see that various other public DNS servers I queried seem to work OK today, responding to Spamhaus queries with correct data, but I doubt that will be the case in the long term. Spamhaus clearly doesn't want to provide this IP reputation data via these channels and right now it's just a question of how effective they are at blocking it. They're not fully effective at it today, but I'm sure they'll get better at it over time.

    This also presents a particularly vexing problem for email senders. We get bounces in our logs that reference the " open resolver " error message, but it's not something that a sender can fix. It's up to the inbound email server's administrator to fix it. One hopes that administrator is paying attention -- and if not, perhaps they'll learn from posts like this and watch for this problem in the future.

    If you work in deliverability for an email sending platform, you might want to customize how you handle Spamhaus bounces -- perhaps looking for that "open resolver" error message and preventing suppression of addresses that bounce with that error message, because those bounces are indeed false positives.

    Značky: #Network, #spamhaus, #dnsbls