Mailheader nach NAT

Started by fw115, February 23, 2025, 12:22:24 PM

Previous topic - Next topic
February 23, 2025, 12:22:24 PM Last Edit: February 23, 2025, 12:25:54 PM by fw115
Hallo, wie sehen eigentlich eure Mailserver Header nach NAT aus, da ich hier gerade das Problem habe das der SPF failed mit SPFsoftfail, da die Header trotz NAT noch die interne IP haben. Bishin zum kompletten Fail, da  eingehende Mails die Interne Domain haben, die der absender Mailserver natürlich nicht gegen SPF prüfen kann.

Wo ist mein Denkfehler ? Oder geht Mailserver nicht mehr hinter NAT  oder NAT falsch ?

Die IP-Adressen in den Received: Zeilen sind völlig irrelevant. Was für den SPF zählt, ist die IP-Adresse, von der aus die Verbindung rein kommt.

Zeig doch mal deinen SPF. Und hast du IPv6? Wird gerne vergessen.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on February 23, 2025, 12:32:38 PMDie IP-Adressen in den Received: Zeilen sind völlig irrelevant. Was für den SPF zählt, ist die IP-Adresse, von der aus die Verbindung rein kommt.

Zeig doch mal deinen SPF. Und hast du IPv6? Wird gerne vergessen.
Da ich das nur noch als Hobby mache und aus der IT seit 10 Jahren raus bin, habe ich mir erlaubt auf IPv6 zu verzichten. Da komme ich nicht mehr hinterher.

hier der SPF :v=spf1 ip4:82.xxx.xxx.23 ip4:82.xxx.xxx.58 ip4:82.xxx.xxx.60 mx a ~all

Und genau das ist das Problem. Der Interne Mailserver hat eine 192.168.x und mit der meldet er sich, wenn eine Connection von außen kommt. Dann läuft das auf den Hammer. Die Firewall nimmt von außen an , Nattet auf eine der ip4:82.xxx.xxx.23 ip4:82.xxx.xxx.58 ip4:82.xxx.xxx.60 Adressen ( habe gerade mehrere zum testen drin)
und der Mailserver kommt mit 192.168.x um die Ecke > SPF failed.
Irgendwo mache ich hier blödsinn mit der config.
Ich habe gerade keine Ahnung wie ich das ändern soll/ muss / kann.

Es ist ganz sicher nicht so, wie Du denkst: Die 192.168.x.y ist außerhalb Deines LANs nicht sichtbar, da sie nicht geroutet wird. WIe Patrick richtig schrieb, ist ausschließlich die einliefernde IP am Zielserver relevant, nicht die E-Mail-Header.

Außerdem wechseln die ISPs bei CG-NAT gerne mal die Outbound IPs oder nutzen dazu ganze Ranges, nicht nur drei IPs. Was bekommst Du denn, wenn Du https://wieistmeineip.de aufrufst?

Eine IPv6? Dann hättest Du doch IPv6 und die wird vorgezogen. Eine IPv4? Eine der drei in Deinem SPF-Record?

Am Rande bemerkt: Unabhängig von SPF gibt es reichlich große E-Mail-Provider, die Einwahl-IP-Bereichen von ISPs sowieso nicht vertrauen - die sind schon vor jedem SPF-Check auf einer Blacklist. Die würden E-Mails von Deinen Einwahl-IPs sowieso nicht annehmen.

Deshalb ist es beim Betrieb einer eigenen Mail-Domain sinnvoll, einen Provider oder eigenen Server mit einer festen, wohlsituierten IP zu nutzen, den man dann u.a. bei dnswl.org anmelden kann, damit er whitelisted ist. Been there - done that.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

February 23, 2025, 02:03:08 PM #4 Last Edit: February 23, 2025, 02:06:26 PM by fw115
Quote from: meyergru on February 23, 2025, 01:37:23 PMEs ist ganz sicher nicht so, wie Du denkst: Die 192.168.x.y ist außerhalb Deines LANs nicht sichtbar, da sie nicht geroutet wird. WIe Patrick richtig schrieb, ist ausschließlich die einliefernde IP am Zielserver relevant, nicht die E-Mail-Header.

Außerdem wechseln die ISPs bei CG-NAT gerne mal die Outbound IPs oder nutzen dazu ganze Ranges, nicht nur drei IPs. Was bekommst Du denn, wenn Du https://wieistmeineip.de aufrufst?

Eine IPv6? Dann hättest Du doch IPv6 und die wird vorgezogen. Eine IPv4? Eine der drei in Deinem SPF-Record?

Am Rande bemerkt: Unabhängig von SPF gibt es reichlich große E-Mail-Provider, die Einwahl-IP-Bereichen von ISPs sowieso nicht vertrauen - die sind schon vor jedem SPF-Check auf einer Blacklist. Die würden E-Mails von Deinen Einwahl-IPs sowieso nicht annehmen.

Deshalb ist es beim Betrieb einer eigenen Mail-Domain sinnvoll, einen Provider oder eigenen Server mit einer festen, wohlsituierten IP zu nutzen, den man dann u.a. bei dnswl.org anmelden kann, damit er whitelisted ist. Been there - done that.
Also, bei diesen IPs handelt es sich nicht um "Einwahl" Ips sondern meinen IP Block /29
Dieser Block ist auf keiner  Blackliste , DNSBL oder sonstiges
Ich habe 2 Leitungen

1 x Glasfaser für das private internte Netz
und

1x eine Telekom Leitung auf dessen Interface per ppoe meine IP adressen groutet werden.
Diese Adressen werden per NAT in die DMZ groutet z.B. 82.xxx.xxx.23 > 192.168.1.22 zum jeweiligen Server mit den entsprechenden Diensten, wie Mail , Web usw.
Da ich gerade ,mehrere Server umbaue und Teste (alle auch mit mail) stehen diese IP adressen eben mit im SPF

IPv6 ist komplett disabled. Sowohl Firewall als auch Server




February 23, 2025, 03:15:38 PM #5 Last Edit: February 23, 2025, 03:19:26 PM by meyergru
O.K., also feste IPs, gut. Die NAT findet also auf Deiner OpnSense statt. Was die DNAT, also Portweiterleitungen zu Deinen internen IPs angeht, kommen dort die echten Quell-IPs an, also würdest Du, wenn Du eingehend SPF prüfst, nichts fehlinterpretieren, denn DNAT schreibt ja nur die Ziel-IPs um.

Was Deine ausgehenden Verbindungen angeht, musst Du ja SNAT machen. Welche IP dort verwendet wird, kannst Du ja selbst bestimmen, es geht aber sicher trotzdem keine RFC1918-IP nach draußen. /29 sind aber 8 mögliche IPs- Wenn Du bei der outbound NAT einfach die Interface IP eingetragen hast, wird auch die nach außen genommen. Du müsstest outbound jeweils ein 1:1-Mapping für die relevanten internen IPs machen.

Was der jeweilige Server nach außen verwendet, kannst Du per CLI mit "curl ifconfig.me" checken.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

Quote from: fw115 on February 23, 2025, 12:22:24 PMHallo, wie sehen eigentlich eure Mailserver Header nach NAT aus, da ich hier gerade das Problem habe das der SPF failed mit SPFsoftfail
Sagt wer?
Quote, da die Header trotz NAT noch die interne IP haben.
Das macht nichts.
QuoteBishin zum kompletten Fail, da  eingehende Mails die Interne Domain haben, die der absender Mailserver natürlich nicht gegen SPF prüfen kann.
Äh, was ist die Interne Domain? Geprüft wird beim Empfang, ober der Sender (IP) berechtigt ist, für die Domain zu senden gemäß SPF.

Ich verstehe noch nicht ganz: Geht es jetzt um Senden oder Empfangen bei Dir?

Grundsätzlich ist NAT bei Mail kein Problem, läuft bei mir seit Jahren. (Postfix, Rspamd, Dovecot)

Grüße

chris

Quote from: chrs on February 23, 2025, 09:10:31 PMÄh, was ist die Interne Domain? Geprüft wird beim Empfang, ober der Sender (IP) berechtigt ist, für die Domain zu senden gemäß SPF.

Ich verstehe noch nicht ganz: Geht es jetzt um Senden oder Empfangen bei Dir?

Grundsätzlich ist NAT bei Mail kein Problem, läuft bei mir seit Jahren. (Postfix, Rspamd, Dovecot)

Grüße

chris
Hier mal ein Beispiel Header vom Empfang. Egal was ich mache, der spf wird IMMER auf die 192.168.100.1 gecheckt. Das das natürlich auf den Hammer läuft ist klar. Was ich nicht in den Kopf bekomme: Warum ? Warum trotz NAT 192.168.100.1 ?
Das verstehe ich nicht.
Was für einen Hostnamen oder IP ich hinter der FW habe, sollte doch Latte sein. Ich hab hier irgendwo ordentlich den Wurm drin und find es nicht!

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com>
Delivered-To: bexxxx@meineexterne.domain
Received: from lego.meineexterne.domain
    by lego.interne.domain with LMTP
    id nxTnJW+2uWfnewMAtEPwRA
    (envelope-from <2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com>)
    for <bexxxxxxx@meineexterne.domain>; Sat, 22 Feb 2025 12:35:11 +0100
Received: from mail.meineexterne.domain (host.interne.domain [192.168.100.1])
    by lego.meineexterne.domain (Postfix) with ESMTPS id 2E23A1BD08C0
    for <bexxxxx@meineexterne.domain>; Sat, 22 Feb 2025 12:35:10 +0100 (CET)
Authentication-Results: lego.meineexterne.domain;
    dkim=pass header.d=primevideo.com header.s=ykhtrtjevojfofawm52v72jbswwuswc6 header.b=VQE7NHhD;
    dkim=pass header.d=amazonses.com header.s=uku4taia5b5tsbglxyj6zym32efj7xqv header.b=JQyW7zeA;
    spf=fail (lego.meineexterne.domain: domain of 2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com does not designate 192.168.100.1 as permitted sender) smtp.mailfrom=2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com;
    dmarc=pass (policy=quarantine) header.from=primevideo.com
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=meineexterne.domain;
    s=default; t=1740224110;
    h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
     to:to:cc:mime-version:mime-version:content-type:content-type:
     list-unsubscribe:list-unsubscribe-post:dkim-signature;
    bh=Sc1RN7ivoPhFhDQ3TmpKMbFbkeY01YhsYFxzCK0HL48=;
    b=gWwgJMcz4S4kssJWiELrV6T+x9iLa+K/1hiHxSy8vA2EvoDN4FkQcM/0ZobgpEzJIYaqcx
    pm622KMNqlUaBixtvfdHhuhwm0yLDilF0mbM621G2gl7KDjHqFi3bcQH7qXUSpvH9p21ye
    8plzaV/kWg0McATi9gLETlaCEVjzxzCRkqBFzQNB0aahDqm2D21eo15Zu/D/iBm+QEQL/3
    jXdiZPFkV4VM5h5IxC2AuILWjctHG7M2gPjsKGzyXJLkxnivAYt5VsNfKkXGkMn7vVNotD
    aL9cArODatEj0ko9Vfa4OjZdJdDYCb4QgcT+fZy6ICXPh0MBm2+TAJWMmsavAQ==
ARC-Authentication-Results: i=1;
    lego.meineexterne.domain;
    dkim=pass header.d=primevideo.com header.s=ykhtrtjevojfofawm52v72jbswwuswc6 header.b=VQE7NHhD;
    dkim=pass header.d=amazonses.com header.s=uku4taia5b5tsbglxyj6zym32efj7xqv header.b=JQyW7zeA;
    spf=fail (lego.meineexterne.domain: domain of 2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com does not designate 192.168.100.1 as permitted sender) smtp.mailfrom=2025022211271892e19d4c980342b99eaec3b1ccc0p0eu-chk4q8tw0bis5@bounces.primevideo.com;
    dmarc=pass (policy=quarantine) header.from=primevideo.com
ARC-Seal: i=1; s=default; d=meineexterne.domain; t=1740224110; a=rsa-sha256;

February 23, 2025, 10:01:54 PM #8 Last Edit: February 23, 2025, 10:12:31 PM by meyergru
Das sieht zumindest so aus, als hättest Du in der eingehenden Richtung keine Port-Weiterleitungen (D-NAT), sondern eine S-NAT konfiguriert hast, wo alle externen Adressen auf die LAN-Interface-IP Deiner OpnSense abgebildet wird. In dem Fall kommt dann die externe IP das Absenders bei Dir als 192.168.100.1 an, was bei der SPF-Prüfung für primevideo.com natürlich schiefgeht.

Ob das so ist, kannst Du leicht testen, indem Du einen TCPdump auf Deinem Server laufen lässt und beispielsweise auf Port 25 lauschst. Kommt da Absender-IPs mit 192.168.100.1 rein, ist das der Grund. Das funktioniert zwar grundsätzlich, aber Du siehst den falschen Absender. Also nicht trotz NAT, sondern wegen (S-)NAT.

Zeig doch mal Deine Port-Weiterleitungen (D-NAT) und Deine (S-)NAT-Regeln.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

QuoteReceived: from mail.meineexterne.domain (host.interne.domain [192.168.100.1])
    by lego.meineexterne.domain (Postfix) with ESMTPS id 2E23A1BD08C0
    for <bexxxxx@meineexterne.domain>; Sat, 22 Feb 2025 12:35:10 +0100 (CET)

Das Setup ist mir immer noch unklar. Ist lego.meineexterne.domain Dein Mailserver (192.168.1.22 ?) und wer ist dann mail.meineexterne.domain? 192.168.100.1 ist der Router?

Was sagt denn das postfix.log beim Empfang?

Grüße

chris

February 24, 2025, 09:44:25 AM #10 Last Edit: February 24, 2025, 09:48:00 AM by fw115
Quote from: chrs on February 23, 2025, 11:04:02 PM
QuoteReceived: from mail.meineexterne.domain (host.interne.domain [192.168.100.1])
    by lego.meineexterne.domain (Postfix) with ESMTPS id 2E23A1BD08C0
    for <bexxxxx@meineexterne.domain>; Sat, 22 Feb 2025 12:35:10 +0100 (CET)

Das Setup ist mir immer noch unklar. Ist lego.meineexterne.domain Dein Mailserver (192.168.1.22 ?) und wer ist dann mail.meineexterne.domain? 192.168.100.1 ist der Router?

Was sagt denn das postfix.log beim Empfang?

Grüße

chris
Das Problem scheint der Mailproxy zu sein. Sry gar nicht mehr dran gedacht. Das scheint also schon länger so zu sein und mir ist es
erst jetzt aufgefallen :/

Wenn ich mit NAT "direkt" auf den Mailserver gehe, habe ich trotz 192.x keinen softfail und interner Domain kein problem mit SPF , DKIM usw. hier scheint die umsetzung also richtig zu funktionieren.

kommt das Mailgateway dazwischen, läuft es auf den Hammer

Hier mal der Header

Received: from nemo.externedomain.net (nemo.internedomain.lan [192.168.100.150])
by lego.interedomain.lan (Postfix) with ESMTPS id 7A3211BC1927
^^ ^   ^^
Is der Interne Mailserver. bzw der hinter der Firewall

    for <toxxx@externedomain.net>; Mon, 24 Feb 2025 09:28:54 +0100 (CET)
Authentication-Results: lego.internedoamin.lan;
    dkim=pass header.d=proton.me header.s=protonmail header.b=Ki9SOr7r;
    spf=softfail (lego.internedomain.lan: 192.168.100.150 is neither permitted nor denied by domain of xxx@proton.me) smtp.mailfrom=xxxx@proton.me;
    dmarc=pass (policy=quarantine) header.from=proton.me

Die Mail wird zwar richtig an den Mailsever übergeben. aber da ist dann Schluss mit NAT.
Im Postfix log sehe ich nur die privaten IPs, es sein denn ich switche direkt auf den Mailserver per NAT
Auffälligkeiten kann ich keine erkennen.

Irgendwie bin ich zu lange raus und bau mir scheinbar nur noch Mist zusammen :(
Den Mailsever aber so ohne Schutz direkt am Netz finde ich jetzt auch doof.

Die SPF-Prüfung darf dann natürlich nur auf dem Mail-Proxy gemacht werden, denn dahinter kommen die Mails ja immer von dort.
Übrigens: das Proxmox Mail Gateway kann das, verwende ich selbst.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

Quote from: meyergru on February 24, 2025, 09:48:21 AMDie SPF-Prüfung darf dann natürlich nur auf dem Mail-Proxy gemacht werden, denn dahinter kommen die Mails ja immer von dort.
Übrigens: das Proxmox Mail Gateway kann das, verwende ich selbst.
Ja ich hab auch den PMG im Einsatz dahinter ISPconfig mit postfix.
Wenn ich mit dem PMG sende sieht der Header so aus:
Return-Path: <torsten@schrammen.net>

X-Original-To: xxx@proton.me

Delivered-To: xxx@proton.me

Authentication-Results: mail.protonmail.ch; dkim=pass (Good 2048 bit

    rsa-sha256 signature) header.d=meineexterne.net header.a=rsa-sha256

Authentication-Results: mail.protonmail.ch; dmarc=pass (p=quarantine dis=none)

 header.from=meineexterne.net

Authentication-Results: mail.protonmail.ch; spf=pass smtp.mailfrom=meineexterne.net

Authentication-Results: mail.protonmail.ch; arc=none smtp.remote-ip=82.xxx.xxx.23

Authentication-Results: mail.protonmail.ch; dkim=pass (2048-bit key)

 header.d=meineexterne.net header.i=@meinexterne.net header.b="yRzk7Y3u"

Received: from nemo.meineexterne.net (unknown [82.xxx.xxx.23]) (using TLSv1.3 with cipher

 TLS_AES_256_GCM_SHA384 (256/256 bits)

Jetzt die Preisfrage: Wie ist die config, dass die SPF Prüfung nur auf dem Proxie stattfindet ?

February 24, 2025, 10:15:15 AM #13 Last Edit: February 24, 2025, 10:17:03 AM by meyergru
Naja, auf dem dahinterliegenden Mailserver eben abschalten. Wenn es ein Postfix ist, kommt es darauf an, wie es konfiguriert wurde, aber meistens benutzt man dazu einen check-policy-service Eintrag in smtpd_recipient_restrictions (in main.cf), der dann auf einen Policy-Daemon in master.cf verweist, z.B. policyd-spf-perl oder policy-spf. Den lässt man weg und kommentiert die Zeile in master.cf aus.

ISPconfig kenne ich nicht, aber da wird es ja eine einfache Konfigurationsoption sein.

Auf dem PMG ist es unter Configuration: Mail Proxy: Options: Use SPF.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

Das Problem scheint mit der Abschaltung von DKIM und SPF auf dem Internen Mailserver gelöst zu sein.

Ich behalte das noch im Auge, aber denke ich kann das so lassen.

Ich möchte mich bedanken, bei allen die sich die Zeit genommen haben mir hier zu helfen !

Danke !