Rejecting incoming messages - zen.spamhaus.org

Hello Hestia community!

It’s been a while since my last post, although I’m still here reading threads :smiley: Anyway, I did a quick search in this forum for the issue I’m facing, but I don’t see it mentioned anywhere. So here it is…

Quick issue description
I have configured one of my Hestia servers to accept email for a specific domain (let’s call it mymail.com) The last few days, when other people send email to mymail.com, I see in /var/log/exim4/rejectlog quite a few logs like these :

2021-10-19 11:22:10 H=mail-oln040092073030.outbound.protection.outlook.com (EUR04-HE1-obe.outbound.protection.outlook.com) [40.92.73.30] X=TLS1.2:ECDHE_SECP384R1__RSA_SHA256__AES_256_GCM:256 CV=no SNI="mail.mymail.com" F=<[user-redacted]@outlook.com> rejected RCPT <[email protected]>: Rejected because 40.92.73.30 is in a black list at zen.spamhaus.org
2021-10-19 11:39:42 H=o1.email.wetransfer.com [192.254.117.71] X=TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128 CV=no SNI="mail.mail.com" F=<[email protected]> rejected RCPT <[email protected]>: Rejected because 192.254.117.71 is in a black list at zen.spamhaus.org
2021-10-19 11:40:39 H=o3.email.wetransfer.com [192.254.123.42] X=TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128 CV=no SNI="mail.mail.com" F=<[email protected]> rejected RCPT <[email protected]>: Rejected because 192.254.123.42 is in a black list at zen.spamhaus.org

When I check the IP(s) at SPAMHAUS it always comes clean with no issues.

Just to clarify a bit more: My mail server is rejecting other peoples’ emails. The senders are getting a delivery error report, telling them that my server rejected their message(s).

Observations
It seems that the issue happens only for incoming mail from:

  • WeTransfer
  • Microsoft (Live, Hotmail, Outlook.com, Office365, etc)
  • Gmail

…but that might just be by chance!

Possibilities?

  1. Is it possible that the query to zen.spamhaus.org fails for whatever reason (e.g. connectivity or load issues) and that failure is interpreted as an actual Reject?
  2. Could it be that the blocked IP address(s) was indeed in the zen blacklist, but it was removed by the time I checked?
  3. Is it possible to whitelist senders’ email addresses? Does the /etc/exim4/white-blocks.conf hold only hosts/IPs, or can it hold email addresses as well?

How to handle?
I understand that this might not be directly related to Hestia, but any idea how to handle this would be highly appreciated.

For the time being, I commented out the zen.spamhaus.org entry inside /etc/exim4/dnsbl.conf and restarted exim4. By doing this, I expect that incoming email will not be checked against the zen blacklist. But this is not an actual solution :frowning:

Contents of dnsbl.conf
bl.spamcop.net
zen.spamhaus.org
1 Like

I have the same issue as well. I noticed this has been happening for at least 10 days, may be due to an update. I commented zen.spamhaus. org as well temporarily. I am able to ping zen.spamhaus. org from the effected servers, checked the IPs rejected and they show no issue on check.spamhaus. org

Is your HestiaCP DNS server querying the DNSBLs (like SpamHaus) directly or using a forwarder?

Because if your HestiaCP server forwards all DNS queries via some public DNS (e.g. Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1) or even some larger ISP (Hetzner), then the DNSBLs often won’t work.

Yes, but why block queries from public recursive name servers?

It’s simple – public recursive name servers act as an anonymizing service and enable large-scale users to hide behind them. Given the lack of transparency and inability to identify those who are abusing the free service, a difficult decision was made to add some public domain name servers to our access control list… ultimately blocking your query. – Successfully accessing Spamhaus' free blocklists using a public DNS - Spamhaus Technology

I’m using Bind9 and have instructed it to DIRECTLY query DNSBL domains (e.g. spamhaus, spamcop, uribl, dnswl etc) by overriding forwarders just for those few domains in /etc/bind/named.conf.local

Same issue discussed here:

but it would be very bad idea if they reported Gmail & Microsoft as bad IPs, when they’re queried via a public DNS!

Very good find @kpv !! Thank you! It seems that is the culprit.

1 Like

I’m using Bind9 and have instructed it to DIRECTLY query DNSBL domains (e.g. spamhaus, spamcop, uribl, dnswl etc) by overriding forwarders just for those few domains in /etc/bind/named.conf.local

@eris Does it make sense to add this behavior to hestia defaults?

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.