Trouble with spamhaus marking any mail as spam

daneel · October 19, 2025, 3:58pm

This thread is quite helpful to better understanding the SpamHaus “open resolver” issue.

Ideally I’d want to solve this without completely disabling all DNSBLs, for instance by making this kind of tweak to /etc/postfix/main.cf:

    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
    # Ignore PBL (127.0.0.10-11) and "open resolver" (127.0.0.254) reponses
    # https://www.spamhaus.org/faqs/dnsbl-usage#what-do-the-127-return-codes-me>
    reject_rbl_client zen.spamhaus.org=127.0.0.[2..9],

YunoHost really doesn’t like manual editing of configuration files, and strongly recommend using the admin interface to tweak settings.

I’d be nice to have more fine-grained control for DNSBL in YunoHost, or a way to tweak/override postfix’s configuration without breaking automatic config generation.

Is this the right place to discuss this? Or should this be raised in a bugtracker?

Cheers

daneel · October 19, 2025, 4:37pm

Replying to myself: it’s possible via a hook but requires some scripting. See configuration on “hooks” within YunoHost’s doc. In particular the hook “conf_regen”.

The forum won’t let me post the direct link to the doc because I’m a new user.

HipsHopsMan · October 21, 2025, 9:54am

oh thank you

rodinux · October 22, 2025, 11:23am

Hello, to do it with a webhook it should like this

First keep back to the original postfix main.cf with a regen-conf

yunohost tools regen-conf -n -d
yunohost tools regen-conf --force

Then edit the hook

mkdir /etc/yunohost/hooks.d/conf_regen
touch /etc/yunohost/hooks.d/conf_regen/70-postfix_customhook
nano /etc/yunohost/hooks.d/conf_regen/70-postfix_customhook

with the editor nano you should add this

#!/bin/bash

action=$1
pending_dir=$4
postfix_main_conf=$pending_dir/../postfix/etc/postfix/main.cf

[[ "$action" == "pre" ]] || exit 0
[[ -e $postfix_main_conf ]] || exit 0

sed -e 's/^[^#].*reject_rbl_client zen.spamhaus.org,/    reject_rbl_client zen.spamhaus.org=127.0.0.[2..9],/' \
    -i $postfix_main_conf

and try the regen-conf

yunohost tools regen-conf -n -d

if it’s ok

yunohost tools regen-conf --force

Aleks · October 22, 2025, 10:26pm

So, we’re hopeful that version 12.1.30 should more exhaustively address the issues, in particular for incorrectly rejecting incoming emails. The fix mainly revolves around tweaking dnsmasq’s configuration to route spamhaus queries directly to spamhaus servers (instead of via an open resolver) - in particular this should also apply to queries from postfix and not just the diagnosis.

Selection of the relevant commits from 12.1.30:

in DNSmasq conf, route queries about spamhaus to spamhaus’s own nameservers to avoid ‘open resolver’ errors (b45b9d4f4)
remove reject_rbl_client abuseat.org from postfix conf because it’s in fact spamshaus.org since a few years (42f0b91bf)
revert prefix prefix fix for diagnosis for spamhaus, which is obsolete now that dns queries for spamhaus are now route at dnsmasq level (51c468735)
remove abuseat.org for DNSbl to check in diagnosis, because it is in fact spamhaus.org since a few years (6af034820)
when obtaining an ‘open resolver’ reason, advise admins to check their /etc/resolv.conf (#2201)

dalecooper · December 17, 2025, 12:09pm

This should be the accepted answer!
it addresses the very problem of the “open resolver” error.
Kudos to @rodinux for also proposing a hook to avoid directly modify postfix’s config files

Aleks · December 17, 2025, 1:54pm

No it doesn’t

It hides the problem under a rug and, if queries always return the “open resolver” code, it’s effectively just disabling this antispam strategy entirely…

dalecooper · December 17, 2025, 2:43pm

fair enough, but none of the other suggestions nor changes in recent minor releases work for the majority of users in the multiple open threads on the topic. so what should we do?

Aleks · December 17, 2025, 2:45pm

As far as I know, the problem was solved for the majority of users in recent minors. The remaining cases are typically people on OVH VPS with IPv6, which Spamhaus also doesnt want to answer DNS queries from, and it’s been discussed in corresponding threads. The other cases remain unknown and should be investigated. But clearly when you have a problem like “I lost the keys for my door”, the proper solution is not “remove the door”…

dalecooper · December 17, 2025, 3:39pm

it’s a matter of priorities, especially when neither the problem nor the solution seem to be very clear as of now. am sure you can appreciate that most people self-hosting emails would rather get a few hypothetical extra spams that see a single important email bounce randomly…

Aleks · December 17, 2025, 3:57pm

The solution is a) upgrade to the latest version ; b) if you are on an OVH VPS, comment-out the IPv6 lines in /etc/dnsmasq/spamhaus and restart dnsmasq ; c) if this still doesn’t work, we need to further dig the issue to understand what’s up.

If people just blindly apply a workaround instead of investigating, then the root cause of the issue never gets fixed.

dalecooper · December 18, 2025, 1:22pm

Here’s an example with the following configuration running on an OVH kimsufi dedicated server:

yunohost –version**:**
repo: stable
version: 12.1.36
yunohost-admin:
repo: stable
version: 12.1.13
yunohost-portal:
repo: stable
version: 12.1.2
moulinette:
repo: stable
version: 12.1.3
ssowat:
repo: stable
version: 12.1.1

/etc/dnsmaq.d/spamhaus (IPV6 commented out):

server=/.zen.spamhaus.org/213.81.185.73
#server=/.zen.spamhaus.org/2a00:12a8:8000::fff0:3
#server=/.zen.spamhaus.org/2a05:9404::e0
#server=/.zen.spamhaus.org/2a05:f480:2000:1246:9998:cf46:6cf8:1e7a
server=/.zen.spamhaus.org/70.34.211.66
server=/.zen.spamhaus.org/82.118.21.219

With only this configuration and leaving spamhaus’s setting in postfix as default, an email bounces with the following open resolver error in /var/log/mail.log:

2025-12-18T13:07:38.591394+00:00 redacted_servername postfix/smtpd[2084268]: NOQUEUE: reject: RCPT from ``o4.ptr6272.saymine.io``[168.245.7.145]: 554 5.7.1 Service unavailable; Client host [168.245.7.145] blocked using ``zen.spamhaus.org``; Error: open resolver; ``https://check.spamhaus.org/returnc/pub/2001:IPV6/``; from=<bounces+19032465-6192-email+filter=redacted.xyz@em7583.sender.com> to=<email+filter@redacted.xyz> proto=ESMTP helo=<``o4.ptr6272.saymine.io``>

The exact same email successfully lands in my inbox with the following edit to /etc/postfix/main.cf

reject_rbl_client zen.spamhaus.org=127.0.0.[2..9], #reject_rbl_client ``zen.spamhaus.org``,

One thing I’ve noticed that might be relevant: the open resolver error seems to be related to the type of sender. It occurs almost always when the email is an automated message from an online service (email verification, password reset request, …) but does not seem to impact manually sent emails from users, even when hosted on the same server.

Aleks · December 18, 2025, 4:06pm

And can you confirm that grep nameserver /etc/resolv.conf only returns nameserver 127.0.0.1 ?

dalecooper · December 19, 2025, 10:24am

yep

user@server grep nameserver /etc/resolv.conf

# run “resolvectl status” to see details about the actual nameservers. nameserver 127.0.0.1

The OVH DNS is still present in `/etc/resolvconf/resolv.conf.d/original` but I believe `yunohost` does its magic to hide it and update /etc/resolv.conf?

prinlu · March 24, 2026, 2:47pm

When my YUNOHOST installation stopped resolving any domains (still trying to find the reason), I looked into recursive name servers of my VPS provider, removed the open ones from usr/share/yunohost/conf/dnsmasq/plain/resolv.dnsmasq.conf, added the provider/hoster’s internal ones (not open to public), regenerated dnsmasq with yunohost tools regen-conf dnsmasq --force

resolving started to work again and spamhouse issue dissapeared.

so for those who are running a server in a datacenter and your provider provides an internal non-open recursive name servers limited/exclusive to that datacenter, this is a workaround for the spamhaus “open resolver” issue.