Is anyone else experiencing this? I’m wondering if there was a change made in one of the recent releases or is this a spamassassin / spamhaus issue.
Emails have recently been getting blocked by legitimate email servers that never had a problem in the past. For example, I have seen emails blocked by legitimate email servers that are using Proofpoint to process their emails and the message in the exim4 mainlog states that the IP address is blacklisted in spamhaus.
I was just attempting to get a password reset from EA games and even their website shows up in my exim4 log stating that the IP address is blacklisted in spamhaus. Which is quite odd, I’m starting to question what the email server is blocking. Or am I reading these log entries incorrectly.
Here are a few examples:
Here is the EA.com games website email that was blocked
2024-03-30 10:48:09 H=mta11.e.ea.com [136.147.183.216] X=TLS1.2:ECDHE_SECP256R1__RSA_SHA512__AES_128_GCM:128 CV=no F=<[email protected]> rejected RCPT <[email protected]>: Rejected because 136.147.183.216 is in a black list at zen.spamhaus.org
Here is another example of one being sent by Proofpoint’s servers and it’s being blocked:
2024-03-30 11:06:10 H=dispatch1-us1.ppe-hosted.com [67.231.154.164] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_128_GCM:128 CV=no F=<[email protected]> rejected RCPT <[email protected]>: Rejected because 67.231.154.164 is in a black list at zen.spamhaus.org
I’m seeing a lot of these in the /var/log/exim4/mainlog log file. I can provide other examples, but can’t be sure they are legit email servers. But the above examples from EA games and a Proofpoint server shouldn’t be getting blocked, and never had before. And I find it hard to believe, suddenly all these legitimate email servers are suddenly blacklisted on Spamhaus.
Is anyone else seeing this or has advice on what I can do. I’m having a lot of emails that are now not coming through and this is getting frustrated.
I checked both 67.231.154.164 and 136.147.183.216 and both show as being clean. So why is the exim4 server blocking with this response in the log file. Something has to be wrong right?
However, since it’s closed, I can’t comment on it. Did you guys ever decide to put this behavior as Hestia defaults? It’s odd that I’m just realizing this now, so I’m wondering if this was added into the defaults and somehow lost the configuration on a recent update. Or, perhaps my server has been blocking tons of emails and I just realized it now.
Can someone share an update on the status of this. Also, I can follow the solution that @kpv speaks of, but what do I actually put in the /etc/bind/named.conf.local file. Would someone be so kind to copy/paste the lines of text that needs to be added to the named.conf.local file to accomplish what @kpv is stating. I would greatly appreciate it. Thank you!
After researching this further, I found the solution and the cause (although I don’t really understand the cause). So it seems this issue must have started when I moved from Google hosting my domains to Cloudflare hosting my domains. It seems to have something to do with Cloudflare’s Public DNS (which is referenced in the below articles). If someone can explain why moving from Google DNS to Cloudflare DNS broke this, I would greatly appreciate the education.
In summary, some emails were being blocked by Exim4 and Spamhaus and being logged with a misleading error message that the sender’s IP was in a blacklist on Spamhaus, which it wasn’t. I still have no idea why it was being blocked or that was the error message. But here is the fix. This was the post that I stumbled upon which helped me to solve this:
You have to register for a Spamhaus DQS account, which will provide you with a query key that you can then add to your /etc/exim4/dnsbl.conf file. The details of how to register the account and update Hestia are on the HestiaCP documentation pages here (Scroll down to the section titled: Rejected because [ip] is in black list at zen.spamhaus.org. Error open resolver):
This fixed the blocking issue. It’s kind of annoying that the error messages are completely misleading, which made it difficult to identify what was actually going on, but this did take care of the issue.
I’m still wondering if the above account registration was necessary, or could I have simply went with KPV’s solution. I would still like to know how to use KPV’s solution if it’s easier and doesn’t require the DQS registration with Spamhaus.
Other related articles I came across on Hestia’s discord forum to help research this, in case others are interested…
If you don’t want to use DQS key, instead of Cloudflare public dns resolvers like 1.1.1.1 you can use Google’s DNS servers like 8.8.8.8.8 (those are not being blocked by spamhaus).
You can check whether a public dns resolver is blocked by spamhaus with this comand:
dig +short @public-dns-server-ip "$(echo 'here-the-ip-to-check' | awk -F '.' '{print $4,$3,$2,$1}' | sed 's/\s/\./g' | sed 's/$/\.zen\.spamhaus\.org/')"
If you receive a response like 127.x.x.x then the ip is blocked by spamhaus and if you receive this exact ip 127.255.255.254 then the public dns server is being blocked. If you receive no response then all is good.
Example checking the EA ip 136.147.183.216 with Cloudflare DNS resolver 1.1.1.1
$ dig +short @1.1.1.1 "$(echo '136.147.183.216' | awk -F '.' '{print $4,$3,$2,$1}' | sed 's/\s/\./g' | sed 's/$/\.zen\.spamhaus\.org/')"
127.255.255.254
Example checking the EA ip 136.147.183.216 with Google DNS resolver 8.8.8.8:
$ dig +short @8.8.8.8 "$(echo '136.147.183.216' | awk -F '.' '{print $4,$3,$2,$1}' | sed 's/\s/\./g' | sed 's/$/\.zen\.spamhaus\.org/')"
I don’t use bind so I can’t help to implement KPV’s solution.
Thank you @sahsanu! Your reply is very helpful and informative. I will definitely give those a try to look up in the future. Thank you for sharing.
Excuse my ignorance on this. But how do I change which DNS resolvers I am using? Is this a setting I need to change in my DNS settings with Cloudflare or something on the Hestia server? I’m a bit confused by all of this as I didn’t change anything on the server and the only change I made was to move from Google’s domain registrar service (when they sold off this service to a 3rd party) to Cloudflare. I believe Cloudflare simply copied over the DNS settings from Google, so I still don’t understand what changed and why I’m now having this issue.
Any help you can provide on where I should be changing the DNS resolvers would be much appreciated. Thanks again!
Those are the nameservers you are using but maybe you are using systemd-resolved or resolvconf so to change them it will depends what you are using.
Note: Maybe I’m not clear but all this depends on your own Hestia server and the nameservers configured there to resolve domains, so nothing to touch in your Cloudflare conf for your domains.
So your above code came in handy. I checked this file: /etc/systemd/resolved.conf and the contents were as follows:
[Resolve]
DNS=67.207.67.2 67.207.67.3
Those IP addresses are the Digital Ocean DNS servers. I assume they got added when I built the server. When I used one of those IPs with the command you provided above, I got the response of 127.255.255.254
$ dig +short @67.207.67.2 "$(echo '136.147.183.216' | awk -F '.' '{print $4,$3,$2,$1}' | sed 's/\s/\./g' | sed 's/$/\.zen\.spamhaus\.org/')"
The above command resulted with a response of “127.255.255.254”.
So based on that, it appears that public DNS server is being blocked. I don’t think I ever changed this, so I guess Spamhaus just recently started blocking the DigitalOcean DNS IPs.
So do I understand this correctly? So what is the fix without using the DQS key? Do I just replace what I have in /etc/systemd/resolved.conf with this:
[Resolve]
DNS=8.8.8.8
Would that fix my issue? I guess I could just leave the current changes I made to use DQS, but would the above at least fix the problem if I ever removed the DQS settings? Thanks in advance!
Yes, but it is better to add that conf to a file inside dir /etc/systemd/resolved.conf.d/ (file example user7632726.conf) so even if the main conf file is modified, that new conf file will have a higher priority.
So I created a file in /etc/systemd/resolved.conf.d/ with filename mydomain.conf (I assume the filename doesn’t really matter?). The file contents are as follows:
[Resolve]
DNS=8.8.8.8
I restarted bind9 and the ran this command: resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 67.207.67.2
DNS Servers: 67.207.67.2 67.207.67.3 8.8.8.8
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.2
DNS Servers: 67.207.67.2 67.207.67.3
Link 3 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.2
DNS Servers: 67.207.67.2 67.207.67.3
I assume since the DigitalOcean DNS servers come first in this list, then the same issue will arise as that will be used when trying to reach spamhaus. Is there something I should do to have the Google DNS take priority, or do I need to remove the DigitalOcean DNS from the file at: /etc/systemd/resolved.conf
I don’t know whether there is an option to modify priority because I don’t use systemd-resolved but you can edit directly the main conf file /etc/systemd/resolved.conf and replace the digital ocean dns.
