dnsbls
As part of their continuing efforts to lock down unrestricted public access to their reputation data, Spamhaus has announced that as of February 14, 2024, they’ll be blocking DNSBL queries made via Digital Ocean’s Cloud Server infrastructure. Read more about it here. This isn’t really a bad thing; those who want can still sign up for the free tier of “DQS” access from Spamhaus for small volume or hobbyist usage. Requiring registration for this (and using their unique subdomain-based process) reminds me a bit of email authentication — the goal is so that Spamhaus can see you as you, not as just some random bits of data in the blob of all the requests coming from public servers. I’ve blogged about this before. So if you’re wondering how to safely query Spamhaus reputation data, read this and be informed. Email admins asleep at the wheel tend to wake up weeks
Spamhaus just announced that they’ve “reinvigorated” the ASN-DROP list, now available in JSON format. The point of this whole thing is for network operators (think ISPs and similar) to just totally block off any potential connections with really bad networks that are spewing nothing but spam, phish and other garbage.In theory this should not impact your typical marketing sender, but it’s good all of us to be aware of what this is. They’re blocking, in some cases, some bad guys who would happily take threats to a phyiscal level with Spamhaus people, given the chance. If the bad guys can’t route their bad stuff, they can’t rip people off, and they don’t make as much (ill gotten) money. That’s why Spamhaus folks are sometimes cagey about full names and locations, in case you’re wondering — not because they’re worried about how a Fortune 500 retailer might react to an SBL
Hey, fellow email nerds! It’s webinar time again. What do you know about Spamhaus? If not everything, I hope you’ll join Matthew Stith and myself on March 21st at 9:00 am central time, where we’ll talk about Spamhaus, what it is, how (and why) blocklists work, how it intersects with domain reputation (and why domain reputation is such a big thing right now) and a whole bunch of at least slightly interesting info nuggets. We’ll try very hard to have time for your questions as well. Want in? Register here. Thanks and hope to see you there!
This is a question I get a lot. Does Gmail use any blocklists? Or, somebody will tell me that they’re having Gmail issues, and they’ve plugged their own IP address into an online blocklist lookup tool, and they are sure that any results found (blocklisting issues) must somehow be part of the underlying cause of their deliverability woes. Except, that’s just about never the case. Here’s why.There are a zillion blocklists out there. Speaking specifically just about DNSBLs (IP-based blocking lists), there’s a good 90+ of them. But blocklists are a bit like blogs, in that anybody can publish them and the fact that it’s been published doesn’t mean that anybody is guaranteed to be actually looking at the what has been published. The net here is that there are a lot of blocklists that, if your IP or domain ends up listed by them, this does not mean that
Hey, email nerds! Are you like me, running various random EC2 instances with scripts or applications that do a bunch of spam and email message analysis, checking (among other things) all the domains and IPs you find? Okay, there aren’t millions of us, but I know I’m not alone out there! Email nerds unite! Anyway, if you’re querying Spamhaus’s blocklists directly from your AWS-hosted infrastructure, be aware: Beginning October 18th, Spamhaus is likely to block those queries, responding instead with a 127.255.255.254 response code. Why? It sounds like AWS is a large source of traffic for Spamhaus, and it’s hard for them to sort out who’s who– including who should be getting access for free and who shouldn’t be. Don’t fret, though. Just sign up for the Spamhaus Data Query Service (DQS), and you should be able to keep the access flowing.Is this really surprising at this point? Not to me.
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.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…
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…