mailcow auf VPS und Probleme bei unbound im Zusammenhang mit mail.protection.outlook.com

Spoils5461

Hallo,

im mailcow-Forum habe Unterstützung gesucht, da ich Probleme mit mailcow habe. Warum frage ich noch mal hier nach? Mich interessiert, ob noch jemand ähnlich Probleme hat in der Hoffnung, dass ich die Ursache finde.

Auf dem netcup VPS läuft Debian GNU/Linux 13 (trixie). Bei der Installation von mailcow bin ich strikt der Anleitung https://docs.mailcow.email/getstarted/install/ gefolgt. Ich musste allerdings bzgl. Firewall die Anpassung analog Hetz... (wieso ist hier im Forum das Wort Hetz... zensiert?) vornehmen, da netcup scheinbar keine stateful-Firewall hat, sondern jedes eingehende Paket isoliert geprüft wird.

Mein Problem steht im Zusammenhang mit postfix und unbound innerhalb mailcows.

Den Firewall habe ich wie in der Dokumentation von mailcow konfiguriert. Konkret besteht das Problem im postfix-Container. Ich kann dort ohne einen forward-Eintrag keine AAAA Abfrage erfolgreich durchführen.

Ohne forward-Eintrag in unbound.conf:

Code

root@server:/opt/mailcow-dockerized# docker compose exec postfix-mailcow dig AAAA domain-de.mail.protection.outlook.com

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> AAAA domain-de.mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31800
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;domain-de.mail.protection.outlook.com. IN AAAA

;; Query time: 4000 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Fri Jul 31 06:43:52 CEST 2026
;; MSG SIZE  rcvd: 73

root@server:/opt/mailcow-dockerized#

Alles anzeigen

Mit forward-Eintrag in unbound.conf

Code

rootserver:/opt/mailcow-dockerized# docker compose exec postfix-mailcow dig AAAA domain-de.mail.protection.outlook.com

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> AAAA domain-de.mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35854
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;domain-de.mail.protection.outlook.com. IN AAAA

;; ANSWER SECTION:
domain-de.mail.protection.outlook.com. 10 IN AAAA 2a01:xxx
domain-de.mail.protection.outlook.com. 10 IN AAAA 2a01:xxx
domain-de.mail.protection.outlook.com. 10 IN AAAA 2a01:xxx
domain-de.mail.protection.outlook.com. 10 IN AAAA 2a01:xxx

;; Query time: 68 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Fri Jul 31 06:42:44 CEST 2026
;; MSG SIZE  rcvd: 196

root@server:/opt/mailcow-dockerized#

Alles anzeigen

Mein Workaround ist die Hinterlegung einer forward-zone in der unbound.conf. Danach hat der Versand und auch die Abfrage mittels "dig" aus dem postfix Container funktioniert.

Code

forward-zone:
  name: "mail.protection.outlook.com"
  forward-addr: 5.1.66.255
  forward-addr: 185.150.99.255

Auch direkt vom Host, außerhalb Docker, funktioniert die dig-Abfrage ohne Probleme mit dem netcup DNS.

Hat jemand ebenfalls eine mailcow Instanz bei netcup und ist auf ähnlich Probleme gestoßen?

Viele Grüße ...

Virinum

Hast du testweise mal die Firewall deaktiviert? Zeig doch mal wie du sie konfigurierst hast

tab

Die netcup Firewall ist stateful für TCP, aber nicht für UDP. UDP betrifft sehr wahrscheinlich auch unbound, außer DNS läuft da nicht über UDP. Es gibt hier im Forum einige Threads, die sich mit dem Thema externe DNS-Server und netcup-Firewall auseinandersetzen. Die netcup DNS-Server funktionieren auch ohne die dortigen Firewall-Regeln, die sind in der Firewall schon von netcup vorkonfiguriert. Aber eben nur für diese Server. Deswegen funktionieren die Abfragen von netcup DNS-Servern auch in deinem Test.

terence

Hast Du das Problem denn nur mit der outlook-Domain oder auch mit anderen? Falls nur die outlook-Domain betroffen ist, könnte es ggf. sein, dass die verantwortlichen Nameserver (direkte) Anfragen Deines Servers blockieren.

Ganzjahresgriller

Zitat von Spoils5461

im mailcow-Forum habe Unterstützung gesucht, da ich Probleme mit mailcow habe. Warum frage ich noch mal hier nach? Mich interessiert, ob noch jemand ähnlich Probleme hat in der Hoffnung, dass ich die Ursache finde

Ich denke der User DocFraggle hat schon versucht Dir zu helfen. Ich würde so vorgehen:

Netcup Firewall deaktivieren

MC streng nach Anleitung installieren

(dann wird erst mal alles funktionieren)

Erst dann die Netcup FW wieder aktivieren

Spoils5461

Zitat von terence

Hast Du das Problem denn nur mit der outlook-Domain oder auch mit anderen?

Bis jetzt nur bei dieser Domäne (*.mail.protection.outlook.com).

Zitat von Ganzjahresgriller

Netcup Firewall deaktivieren
MC streng nach Anleitung installieren

Ich bin streng nach Anleitung vorgegangen. Ich wüsste nicht warum ich alles noch mal neu installieren soll, nur um dann festzustellen, dass das Problem bestehen bleibt. Aktuell bin ich noch auf der Ursachensuche.

Ich glaube auch nicht an ein Firewallproblem. Auf dem Host und mit der forward-zone-Anpassung funktioniert ja alles. Ich möchte verstehen, warum es ohne die Anpassung der forward-zone nicht geht. Zwischen Host und Docker gibt es auch keine Firewall, die etwas blockieren könnte.

Wenn jemand von euch bei netcup einen VPS hat, funktioniert den docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com bei euch (also ohne der Hinterlegung eines eigenen DNS bei der forward-zone, so wie es Standard bei mailcow ist)?

Zitat von terence

Falls nur die outlook-Domain betroffen ist, könnte es ggf. sein, dass die verantwortlichen Nameserver (direkte) Anfragen Deines Servers blockieren.

Das kann ich mir auch nicht vorstellen. Wenn ich keine forward-zone in der unbound.conf definiere, funktioniert das Kommando docker compose exec unbound-mailcow dig AAAA mail.protection.outlook.com und liefert "NOERROR" zurück. Das gleiche Kommando docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com bei postfix liefert "SERVFAIL" zurück. Kann das jemand von euch mal testen?

Trotzdem hier noch mal meine Firewall-Einstellungen:

grafik.png

Das Verhalten ändert sich nicht, wenn ich die Firewall komplett deaktiviere.

terence

Zitat von Spoils5461

Wenn ich keine forward-zone in der unbound.conf definiere, funktioniert das Kommando docker compose exec unbound-mailcow dig AAAA mail.protection.outlook.com und liefert "NOERROR" zurück.

Wird dabei denn unbound für den Lookup verwendet oder der Resolver des Container-OS (kenne mich mit Docker nicht aus)? Du könntest dem dig-Aufruf ja mal explizit mitgeben, unbound zu verwenden.

Die beiden TCP-Regeln für unbound sollten in Deiner FW-Policy nicht nötig sein, da die FW für ausgehende TCP-Pakete stateful ist.

(Falls Du keine FW-Regel für NTP hast, solltest Du die ggf. auch noch ergänzen.)

tab

War da nicht was mit der Nutzung von ephemeral Ports?

Spoils5461

Zitat von terence

Die beiden TCP-Regeln für unbound sollten in Deiner FW-Policy nicht nötig sein, da die FW für ausgehende TCP-Pakete stateful ist.

Du meinst die eingehenden TCP, oder?

Zitat von terence

Du könntest dem dig-Aufruf ja mal explizit mitgeben, unbound zu verwenden.

Das funktioniert auch nur dann, wenn ich die forward-zone definiert habe.

Zitat von Ganzjahresgriller

MC streng nach Anleitung installieren
(dann wird erst mal alles funktionieren)

Ich bin echt am Überlegen, den Schritt zu wagen und hoffe auf ein erfolgreiches Restore.

Spoils5461

Zitat von tab

War da nicht was mit der Nutzung von ephemeral Ports?

Das sagt mir nichts. Kannst du den Zusammenhang zu meinem Problem genauer beschreiben?

tab

Unbound schickt je nach Einstellung Queries nicht nur über Port 53 raus, da könnten eventuell Antworten blockiert werden.

terence

Zitat von Spoils5461

Du meinst die eingehenden TCP, oder?

Ja, laut Screenshot hast Du ja nur eingehende Regeln.

Zitat von Spoils5461

Das funktioniert auch nur dann, wenn ich die forward-zone definiert habe.

Ok, also genauso wie beim postfix-Container!?

Spoils5461

Zitat von terence

Ok, also genauso wie beim postfix-Container!?

Genau, mit forward-zone liefert docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com @172.22.1.254 NOERROR zurück.

Zitat von tab

Unbound schickt je nach Einstellung Queries nicht nur über Port 53 raus, da könnten eventuell Antworten blockiert werden.

Dachte ich auch erst. Habe dann allerdings die Firewall deaktiviert, alles neu gestartet und noch mal ohne Erfolg getestet.

terence

Habe ich jetzt auch gerade erst gesehen. Du brauchst normalerweise nur eine eingehende UDP-Regel mit Source-Port 53 für die Antworten auf die Anfragen von unbound.

tab

Zitat von Spoils5461

Genau, mit forward-zone liefert docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com @172.22.1.254 NOERROR zurück.
Dachte ich auch erst. Habe dann allerdings die Firewall deaktiviert, alles neu gestartet und noch mal ohne Erfolg getestet.

Ok, wenn es bei deaktivierter netcup Firewall schon nicht funktioniert, dann scheidet das wohl zumindest fürs Erste aus. An der Front geht es dann allenfalls weiter, wenn es mal bei deaktivierter netcup Firewall funktioniert.

terence

Zitat von Spoils5461

Genau, mit forward-zone liefert docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com @172.22.1.254 NOERROR zurück.

Hattest Du denn dem dig-Aufruf für den unbound-Container auch explizit unbound als Resolver mitgegeben?

bekenz

Ich habe bei meiner Mailcow nur diese Regel für DNS.

Screenshot 2026-07-31 144506.png

Das spuckt dann mein Postfix-Container aus

Code

 <<>> DiG 9.20.26-1~deb13u1-Debian <<>> AAAA mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28591
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mail.protection.outlook.com.   IN      AAAA

;; AUTHORITY SECTION:
mail.protection.outlook.com. 300 IN     SOA     ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600

Alles anzeigen

ist die abfrage genau diese Domain mail.protection.outlook.com ?

Ich hab mail bei meinen Mails geschaut da kommt z.B. ***********-de02i.mail.protection.outlook.com da bekomme ich dann IPV6 Adressen als Antwort zurück.

terence

Zitat von terence

Du brauchst normalerweise nur eine eingehende UDP-Regel mit Source-Port 53 für die Antworten auf die Anfragen von unbound.

Ich würde bei Regel 19 Source-Port 53 ergänzen und die anderen drei unbound-Regeln entfernen. Die Destination-Ports einzugrenzen macht auf jeden Fall auch Sinn und der Bereich passt ja wohl zu dem, was Du in unbound konfiguriert hast.

terence

Was kommt denn raus, wenn Du direkt auf dem VPS die folgenden Aufrufe machst? Dabei wird der jeweils verantwortliche Name Server verwendet.

dig @ns1-05.azure-dns.com A outlook.com

dig @ns1-proddns.glbdns.o365filtering.com A mail.protection.outlook.com

Ich kann das selbst gerade nicht testen, aber wenn ich nachher daheim bin, probiere ich es mal auf meinem VPS aus und kann dann auch mal meine unbound-Instanz darauf loslassen.

Virinum

Zitat von Spoils5461

Wenn jemand von euch bei netcup einen VPS hat, funktioniert den docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com bei euch (also ohne der Hinterlegung eines eigenen DNS bei der forward-zone, so wie es Standard bei mailcow ist)?

Code

/opt/mailcow-dockerized# docker compose exec postfix-mailcow dig AAAA mail.protection.outlook.com

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> AAAA mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31837
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mail.protection.outlook.com.   IN      AAAA

;; AUTHORITY SECTION:
mail.protection.outlook.com. 60 IN      SOA     ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600

;; Query time: 89 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Fri Jul 31 16:11:36 CEST 2026
;; MSG SIZE  rcvd: 136

Alles anzeigen

Tags