Spamhaus has gone mad

#1

I haven’t got to the bottom of this yet, but thought I’d post about it in case anyone else is affected. A client running Hestia was complaining about not receiving mail. When I replied asking for more information, my own mail was rejected from his server saying my IP was banned at zen.spamhaus.org. However when I went to check at https://check.spamhaus.org/ its not listed. IP and all associated domain names are clear.

I can’t figure out what’s going on. In the meantime, I’ve edited /etc/exim/dnsbl.conf to remove spamhaus and restarted exim, so that is the quick fix.

#2

OK, it hasn’t gone mad, but it seems to have been implementing the changes it threatened in 2021.

Basically if I query the zen.spamhaus.org server manually, I don’t get one of the expected codes any more, but a new one, which makes exim think that the IP address has been rejected, even though its not on the list. For example, if the server sending the mail’s IP is 12.23.34.45, I run the command.

dig -t txt +short 45.34.23.12.zen.spamhaus.org
"Error: open resolver; https://www.spamhaus.org/returnc/pub/162.158.161.164"

So clicking on that link gives you info for the sender. There is another link which email server admins need to read:
https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now

Here’s some more info.

I’ve now removed the spamhaus check from all Hestia servers I know about, and will dig into this a bit further. I’d advise you to check for bouncing mail on your servers too. More news when I have it.

2 Likes
#3

Indeed that was the cause of the problem that you described.

We discussed it in the past here:

1 Like
#4

Ideally Exim4 should be able to distinguish the various status code responses from SpamHaus (like Postfix does) and note that 127.255.255.[1…255] are to be treated differently.

https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html#configuration

HestiaCP behind NAT?
#5

I just did a quick test of querying SpamHaus

  1. directly using my local bind9 (works correctly)
  2. via Google’s 8.8.8.8 (produces empty results but at least doesn’t report a false positive)
  3. via Cloudflare 1.1.1.1 (false positive)
[email protected]:~# dig +short @127.0.0.1 2.0.0.127.zen.spamhaus.org
127.0.0.10
127.0.0.2
127.0.0.4
[email protected]:~# dig +short @8.8.8.8 2.0.0.127.zen.spamhaus.org
[email protected]:~# dig +short @1.1.1.1 2.0.0.127.zen.spamhaus.org
127.255.255.254
[email protected]:~#

For more info please check:
https://www.spamhaus.org/faq/section/DNSBL%20Usage#200
https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now

#6

OK, thanks for those tests, kpv. I’ve been trying it out on a few servers, and have had very inconsistent results. Sometimes a server will report that the IP is blocked, and then when you send again a minute later, it passes through OK. After your post above, I think now what is happening is that those servers are using 8.8.8.8 and 1.1.1.1 randomly, so sometimes they fail and sometimes they don’t. A lightbulb moment.
resolvectl gives a lot of info on this.
I’ve forgotten why I changed the DNS to 8.8.8.8 and 1.1.1.1 originally. I think it was because the cloud host’s DNS servers were overloaded and not working. Anyway I’ll review this now with your results in mind.

Agree that exim should be able to distinguish the codes. However it doesn’t, and there is no code given on the spamhaus wiki for exim, just postfix, exchange etc. Maybe I’ll reach out for them.

For the record I did search the forum for spamhaus before posting, but didn’t turn up your post above. Thanks for pointing that out.

Just as a further note, I haven’t noticed any huge surge of spam since disabling the spamhaus check, so there doesn’t seem to be a huge downside in disabling it. I’ve also found a lot of other DNS are available, so might try one or two of those. eg.
https://oper.io/src/nullspoon/dnsbl-check.git/tree/dnsbls.txt

#7

Excuse me, but where did you change the DNS?

#8

DNS resolver can be changed by modifying /etc/resolv.conf

1 Like
#9

To remove spamhaus from the “dns blocklist”

sed -i "/zen.spamhaus.org/d" /etc/exim4/dnsbl.conf
systemctl restart exim4
5 Likes
#10

I had the same issue couldn’t understand what was going on as it was intermitant and our IP was not on any blacklist even though the bounce back said it was. BTW We use Cloudflare Public DNS. This Thread has saved my mail!! Thanks
@eris I did as you suggested and disabled spamhaus, mail flowing like a charm.

#11

better get your key from spamhaus. They are putting public dns in danger. After getting the key (100% free) from them, service is okay now.

#12

I accepted the first few when it came from custom emails being rejected. But when Gmail email started being rejected, I knew something was wrong lol.

Life saver thread.

1 Like
#13

Exactly, aws was getting rejected, then tried gmail and it was getting rejected aswell.
What public dns you guys suggest that is good and works, apart from cloudflare and google that people say it is the culprit.
Or should I just keep spamhause removed ?

#14

Found another solution to this problem: you can install unbound dns server and use that. A couple of provisos though