Thanks a lot for your help, André! I completely misunderstood your other statements that you gave in some of the github issues. And I didn’t think far enough…
To summarise the issue (and with that maybe help others that run into similar problems; and please, if someone reads this that knows more, feel free to correct me!):
- Mailcow uses a own unbound installation that does the DNS lookup itself (by querying the root servers if it musts)
dig in Mailcow will thus use that Unbound resolver which obviously has the server IP visible to the root servers and all to other queried name servers
- If using
dig outside the mailcow containers, the system’s DNS resolvers are used for the lookup
- In standard installs, the system doesn’t have an own resolver (on localhost) but uses a resolver preset by the hosting provider, manual config or via DHCP
- If a third party resolver is used, the outgoing IP address is not the one of the server, but the IP of the resolver.
- Spamhaus blocks Server-IPs from hosting provider’s VPS/cloud server range, as it does for Hetzner. Seemingly, an exception are the Hetzner recursive name servers
- For black-lists/spam requests, external resolvers should never be used (except if they don’t cache their requests, which is never the case). Thats why Mailcow uses an own unbound resolver: to avoid cached results that are not valid anymore. If needed, it will internally cache the results to be more efficient and not to DoS the root servers.
However, the good news is that Spamhaus provides it services free-of-charge for non-commercial use. To that end, one can request a free account and get personalised DNSBL server endpoints.
The bad news is that one cannot simply register for it to work without changing the mailcow installation. As noted in Spamhaus’ documentation:
To query the datafeed query service, your key is added to the DNSBL zone names that you will use in the same way as you would use any normal DNSBLs in your mail server. If, for example, you have been using zen.spamhaus.org, you simply delete zen.spamhaus.org and replace it with abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net.
This needs to be done once for postfix (to block messages before even being accepted) and once for rspamd (to block contents or block messages according to the contents’ domain reputation). For postfix, the change is quite easy but I nevertheless don’t like it. It is dirty and will perhaps one day trigger merge conflicts but it will not be problematic if new DNSBLs are added.
In /data/conf/postfix/main.cf, item postscreen_dnsbl_sites
Comment:
zen.spamhaus.org=127.0.0.[10;11]*8
zen.spamhaus.org=127.0.0.[4..7]*6
zen.spamhaus.org=127.0.0.3*4
zen.spamhaus.org=127.0.0.2*3
and add:
abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.[10;11]*8
abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.[4..7]*6
abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.3*4
abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.2*3
(don’t forget to restart the unbound container)
That’s where I am right now. I have not yet tried how to include the spamhaus check into rspamd but I think it’s harder because there is no mailcow-specific config of rspamd mentioning spamhaus.
If someone fiends a cleaner way to make this happen, feel free to comment.
I will further explain my findings if I find some time to tackle the rspamd issue.
DNS stopped resolving after recent update
request a free account and get personalised DNSBL server endpoints