Spamhaus blockiert Mailserver trotz eigenen Resolvers

Kürzlich hatte ich einen kuriosen Zwischenfall bei einem meiner Kunden: Der Mailserver, der nach meiner Mailserver-Anleitung aufgesetzt wurde, lehnte seit einiger Zeit immer wieder einmal E-Mails von außen ab. Zunächst konnte ich den Fehler nicht nachstellen, doch nach einigen Testmails gelang es mir schließlich, dem Problem auf die Spur zu kommen …

Als Antwort auf meine Testmail bekam ich schließlich eine E-Mail von meinem Mailer Daemon zurück mit:

user@domain.tld: host mail.domain.tld[xx.xx.xx.xx] refused to talk to me: 521 5.7.1 Service unavailable; client [xx.xx.xx.xx] blocked using zen.spamhaus.org

Merkwürdig. War mein eigener Mailserver auf den Spamhaus Zen Blockliste gelandet? Ein schneller Check auf https://check.spamhaus.org zeige zum Glück das Gegenteil. Doch warum wurde die E-Mail dann abgelehnt? Ein Blick in das mail.log offenbarte mehr Details:

Oct 25 12:50:54 sisyphos postfix/dnsblog[12662]: addr xxxx:xxxx:xxxx::xxxx listed by domain zen.spamhaus.org as 127.255.255.254
[...]
Oct 25 12:50:54 sisyphos postfix/dnsblog[12662]: addr xx.xx.xx.xx listed by domain zen.spamhaus.org as 127.255.255.254

Hier kann man erkennen, wie das Mailsystem die beiden Zustellversuche meines Mailservers (einmal IPv4, einmal IPv6) bewertet: Spamhaus liefert für beide Versuche eine Antwort 127.255.255.254 zurück - laut der Tabelle unter “What do the 127...* return codes mean in DNSBL?” steht das für einen Fehler:

127.255.255.254 Query via public/open resolver

Der Fehler ist mir nicht ganz unbekannt, weil viele meiner Leser ihre Mailserver vor vielen Jahren aufgesetzt haben, als offene Resolver für Spamhaus noch kein Problem waren. Doch seit einiger Zeit sperrt Spamhaus Mailserver aus, die über einen offenen DNS-Resolver auf die DNS-Blocklisten (und damit die Nameserver von Spamhaus) zugreifen. Die Lösung dafür ist ganz einfach: Mit einem lokalen, eigenen Resolver, z.B. via unbound, umgeht man das Problem.

Mein Kunde setzte auf fraglichem Mailserver aber bereits einen lokalen Resolver ein. Das konnte also nicht das Problem sein.

Dennoch: Tests via dig zeigten immer wieder (aber nicht immer!) an, dass ein Code 127.255.255.254 zurückgegeben wurde:

root@mail /etc/postfix # dig @127.0.0.1 135.72.1.5.zen.spamhaus.org

; <<>> DiG 9.11.3-1ubuntu1.18-Ubuntu <<>> @127.0.0.1 135.72.1.5.zen.spamhaus.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;135.72.1.5.zen.spamhaus.org.	IN	A

;; ANSWER SECTION:
135.72.1.5.zen.spamhaus.org. 1588 IN	A	127.255.255.254

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 25 13:30:31 CEST 2025
;; MSG SIZE  rcvd: 74

Eigentlich sollte in diesem Fall ein NXDOMAIN zurückgegeben werden.

Schritt 1: Symptome lindern

Die Ursache für das Verhalten von Spamhaus war noch unklar. Also bemühte ich mich, die negativen Auswirkungen auf meinen Kunden erst einmal einzudämmen - schließlich war er durch den Fehler nur sporadisch erreichbar. Die zurückgegebene IP-Adresse 127.255.255.254 wurde durch Postfix nämlich als “blockieren - Spam!” interpretiert. In der alten Anleitung, auf der der Mailserver basierte, hatte ich nämlich nicht genau spezifiziert, welche Return Codes als Spam gewertet werden sollten. Das habe ich nachgeholt. Die Konfiguration sieht nun so aus:

### DNS blocklists
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*2
postscreen_dnsbl_action = drop

Nun werden nur IP-Adressen endend auf 2-11 als Spamalarm gewertet. Andere Adressen lassen Postscreen kalt. Damit führt auch der “Open Resolver” Code nicht mehr zur Ablehnung eingehender E-Mails. Allerdings funktioniert der Zugriff auf die Spamhaus Zen Blockliste noch immer nicht zuverlässig. Die Maßnahme verhindert nur die durch den Fehler verursachten False Positives.

Schritt 2: Hilfe bei Spamhaus anfordern

Eine Anfrage bei Spamhaus zu dem Problem half nur bedingt. Auf die Frage, ob Spamhaus eine Liste mit offenen Resolvern pflege und darin vielleicht fälschlicherweise der Kundenserver stehe, hieß es:

The IPs are not listed in our mirrors but I would recommend using the IPv4 for queries. We are seeing abuse of our mirrors from IPv6 space of Hetzner in millions so some IPv6 queries might fail.

Das hat mich dann eine Idee gebracht …

Schritt 3: Spamhaus nur via IPv4 ansprechen

Schnell kam der Verdacht auf, dass das zufällig erscheinende Verhalten evtl. mit einem Unterschied zwischen IPv4 und IPv6-basierten Anfragen zu tun haben könnte. Das bestätigte sich sofort, als ich den lokalen Unbound-Resolver auf “IPv4 only” Betrieb umgestellt hatte. Folgende Konfiguration in /etc/unbound/unbound.conf.d/ipv4-only.conf:

server:
    do-ip4: yes
    do-ip6: no

… führt dazu, dass Unbound bei der Kontaktaufnahme zu anderen Nameservern (z.B. den Servern von Spamhaus) kein IPv6 mehr verwendet. DNS-Antworten können trotzdem noch v6-Adressen enthalten - diese bleiben unberührt. Funktional bleibt der Mailserver also unverändert - aber die Spamhaus DNSBL funktionierte mit diesem Kniff wieder wunderbar.

War das schon alles?

Bei meiner Recherche bin ich außerdem auf einen zweiten Punkt gestoßen, der für das Problem gesorgt haben könnte. Denn DNS-Resolver, die mit Spamhaus genutzt werden, müssen laut diesem Artikel einen Reverse DNS Eintrag vorweisen können. Fehlt dieser, kann dies ebenfalls Probleme bei der Nutzung der Spamhaus Zen Blockliste verursachen. Es ist also darauf zu achten, dass sowohl die IPv4 Adresse als auch die IPv6 Adresse einen gültigen Reverse DNS Eintrag haben.

Alternative Lösung mit dem Spamhaus DQS

Statt des DNSBL hätte ich meinen Kunden auch auf den Spamhaus DQS Service umstellen können. Mit dem Service habe ich allerdings noch keine Erfahrung gesammelt. Zudem bedingt die Nutzung eine Registrierung. Die weitere Nutzung der öffentlichen DNSBL lag daher auf der Hand.