Beiträge von Spoils5461

Zitat von terence

Ich kann den SRVFAIL übrigens mit meinem unbound erwartungsgemäß nachstellen, wenn ich tcp-upstream: yes einstelle und sehe dann im unbound-Log Fehlermeldungen wie diese (mit den o. g. Log-Einstellungen):

Hast du es aus dem postfix und dem unbound Container heraus probiert?

Zitat von terence

Das hätte doch genauso fehlschlagen müssen. Da wäre es dann mal interessant, die Logs zu sehen... Wenn Du also noch mal Lust hast, das auszuprobieren, würde mich das Ergebnis interessieren. Wenn nicht, ist es aber auch nicht schlimm.

So richtig motiviert bin ich da aktuell nicht. Vielleicht in den nächsten Tagen, um der Hitze zu entfliehen.

Zitat von terence

Ach ja... wie ist das mit NTP? Hast Du das in der netcup-Firewall konfiguriert, so daß Du keine Probleme mit der Systemzeit bekommst?

Ja, da habe ich mich an dem Spickzettel von deinem Hinweis auf RE: Ab sofort: Firewall für netcup vServer verfügbar orientiert und es genau so angepasst.

Ich habe eben die Ursache gefunden. Da ich ursprünglich noch nicht verstanden habe, dass bei der FW von netcup bei UDP stateless ist, habe ich in der unbound.conf `tcp-upstream: yes` eingetragen. Das habe ich eben entfernt und jetzt funktioniert es.

Ich könnte mich selbst .... vielen Dank noch mal an euch

Zitat von tab

M.E. gibt es keine A oder AAAA Records für "mail.protection.outlook.com"

Stimmt, es geht konkret um einen Empfänger xxx-de.mail.protection.outlook.com. Dort ist es mir aufgefallen, da die Mail nicht angekommen ist und keine DSN Bestätigung zurück kam. mail.protection.outlook.com habe ich u.a. dann immer wieder zum Testen verwendet, da mich eben auch das SERVFAIL gewundert hat. Das Verhalten trifft auf alle Empfänger von mail.protection.outlook.com zu, unabhängig der Subdomain. Mir ist hier bewusst, dass nur für mail.protection.outlook.com keine A oder AAAA zurück kommt.

Nachdem ich mein unbound-Anpassung (forward-zone) vorgenommen habe, wurde prompt die Mail verschickt und es kam die DSN Bestätigung zurück.

Zitat von terence

P.S.: Die angehängte Datei sieht mir nicht nach der unbound.conf aus.

Stimmt, Konzentration lässt nach. Das ist die conf von mailcow.

Zitat von terence

Na, nicht zu schnell aufgeben!

Danke, werde da auch erstmal pausieren. Danke fürs Mut machen.

Zitat von terence

Hast Du schon einmal versucht, mit tcpdump den Traffic zu analysieren?

Das geht mir dann zu weit. Ich werde es versuchen.

Vielleicht sollte ich das mit dem eigenen Mailserver doch noch mal überdenken. Ich bin eingermaßen IT affin, komme glaube langsam an meine Grenzen. Mich verlässt der Mut.

Ich werde die Tag noch mal eine Neuinstallation versuchen - es dann aber bei Misserfolg sein lassen. Trotzdem vielen Dank für die tolle Unterstützung hier.

Ich habe noch mal meine mailcow.conf angefügt.

Meine unbound.conf

server:
  verbosity: 1
  interface: 0.0.0.0
  interface: ::0
  logfile: /dev/console
  verbosity: 1
  log-queries: yes
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes
  do-daemonize: no
  #access-control: 0.0.0.0/0 allow
  access-control: 10.0.0.0/8 allow
  access-control: 172.16.0.0/12 allow
  access-control: 192.168.0.0/16 allow
  access-control: fc00::/7 allow
  access-control: fe80::/10 allow
  #access-control: ::0/0 allow
  directory: "/etc/unbound"
  username: unbound
  auto-trust-anchor-file: trusted-key.key
  #private-address: 10.0.0.0/8
  #private-address: 172.16.0.0/12
  #private-address: 192.168.0.0/16
  #private-address: 169.254.0.0/16
  #private-address: fc00::/7
  #private-address: fe80::/10
  # cache-min-ttl needs to be less or equal to cache-max-negative-ttl
  cache-min-ttl: 5
  cache-max-negative-ttl: 60
  root-hints: "/etc/unbound/root.hints"
  hide-identity: yes
  hide-version: yes
  max-udp-size: 4096
  msg-buffer-size: 65552
  unwanted-reply-threshold: 10000
  ipsecmod-enabled: no
  tcp-upstream: yes
  # https://docs.mailcow.email/de/getstarted/prerequisite-system/#wichtig-fur-hetzr-firewalls
  # outgoing-port-avoid: 0-32767

remote-control:
  control-enable: yes
  control-interface: 127.0.0.1
  control-port: 8953
  server-key-file: "/etc/unbound/unbound_server.key"
  server-cert-file: "/etc/unbound/unbound_server.pem"
  control-key-file: "/etc/unbound/unbound_control.key"
  control-cert-file: "/etc/unbound/unbound_control.pem"

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

Zitat von bekenz

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.

Nein, nicht genau mail.protection.outlook.com, sondern wie bei dir ****-de.mail.protection.outlook.com.

Zitat von bekenz

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

Das habe ich auch mal so übernommen. Allerdings löst es das Problem nicht (auch nach reboot).

Zitat von terence

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

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

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

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> @ns1-05.azure-dns.com A outlook.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8677
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
outlook.com.            300     IN      A       52.96.222.226
outlook.com.            300     IN      A       52.96.229.242
outlook.com.            300     IN      A       52.96.222.194
outlook.com.            300     IN      A       52.96.228.130
outlook.com.            300     IN      A       52.96.223.2
outlook.com.            300     IN      A       52.96.91.34
outlook.com.            300     IN      A       52.96.214.50
outlook.com.            300     IN      A       52.96.172.98
outlook.com.            300     IN      A       52.96.111.82

;; Query time: 4 msec
;; SERVER: 2603:1061:0:700::5#53(ns1-05.azure-dns.com) (UDP)
;; WHEN: Fri Jul 31 19:10:46 CEST 2026
;; MSG SIZE  rcvd: 184

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

;; missing question section

; <<>> DiG 9.20.26-1~deb13u1-Debian <<>> @ns1-proddns.glbdns.o365filtering.com A mail.protection.outlook.com
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40940
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; Query time: 12 msec
;; SERVER: 52.102.36.118#53(ns1-proddns.glbdns.o365filtering.com) (UDP)
;; WHEN: Fri Jul 31 19:11:43 CEST 2026
;; MSG SIZE  rcvd: 12

Zitat von terence

microsoft.com verwendet aber offenbar auch mail.protection.outlook.com

Hier habe ich mich vielleicht irreführen lassen, da ich nur microsoft.com abgefragt habe. Macht für das Mailthema ja keinen Sinn.

Zitat von terence

Funktioniert denn der folgende Aufruf ohne forward-zone?

Aus dem postfix Container leider nicht, aus dem unbound Container funktioniert es.

postfix

; <<>> DiG 9.20.23-1~deb13u1-Debian <<>> AAAA microsoft-com.mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32618
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;microsoft-com.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 19:02:06 CEST 2026
;; MSG SIZE  rcvd: 59

unbound

; <<>> DiG 9.20.23 <<>> AAAA microsoft-com.mail.protection.outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30612
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;microsoft-com.mail.protection.outlook.com. IN AAAA
;; ANSWER SECTION:
microsoft-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f403:c922::
microsoft-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f403:c92c::2
microsoft-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f403:f805::1
microsoft-com.mail.protection.outlook.com. 10 IN AAAA 2a01:111:f403:c902::1
;; Query time: 32 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Fri Jul 31 19:02:32 CEST 2026
;; MSG SIZE  rcvd: 182

Zitat von terence

Die IPv4-Adresse meines Servers beginnt mit 202.61

Meine beginnt mit 92.60

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.

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?

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.

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

grafik.png

grafik.png

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

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:

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# 

Mit forward-Eintrag in unbound.conf

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# 

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.

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 ...