Unklare Übertragungsprobleme bei einigen Mails
Hallo Postfixler,
ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. hat einer von euch eine Idee, wie folgende Situation zu Stande kommt:
Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert (Regeln sind unten beschrieben). Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 verschiedene Mailserver weiterleiten. Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der Uniklinik) kam es bei vereinzelnden Mails zu Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation with uniklinikmailserver[149.AAA.BBB.CCC] timed out while sending message body)" gequeued.
Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. Dort aber auch nicht bei allen "großen" Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver gesendet habe, konnte ich den Fehler nicht nachstellen. Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 Stunden) von alleine aus der Queue und wurden laut Log auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der Fehler auftritt auf einen anderen Kanal erfoglreich Mails zum dem Mailserver durch, d.h. er war auch verfügbar.
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
(In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein Mailversand dort stattfinden)
Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation mit dem Uniklinik-Server gedropt werden mitgeloggt. Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam folgende Log-Einträge gefunden:
Jun 23 12:23:33 mx3 kernel: [ 10.790460] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00 PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK URGP=0
Oder bei einer anderen Mail: Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00 PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 ACK PSH URGP=0
(149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur Sicherheit noch einmal: Diese Einträge kamen als ich (141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe.
Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung nicht funktioniert hat. Zu dem Zeitpunkt, wo die zuvor durch fehlerhafte Übertragung gequeueten Mails übertragen wurden, finden sich auch keine gedroppten Pakete im IPTabeles Log. Das Problem konnte ich dadurch vermeiden, indem ich in der IPTables sämtliche Kommunikation von und zu dem Uniklinik Mailserver erlaubt habe: -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -j ACCEPT
Der Mailserver der Uniklinik betreibt Postfix in unbekannter Version. Mails zu einem anderen Postfix Server intern und unserem Exchange Server intern laufen ohne Probleme. Ich betreibe Postfxi 2.11.
Meine Fragen sind nun: - Was werden da für TCP Pakete an mich gesendet, die verworfen werden? Wenn diese zur "normalen" Kommunikation beim Mailaustausch gehören, müssten die doch bei jeder Mail kommen oder? - Wieso, findet diese Kommunikation nur bei einigen wenigen Mails statt und bisher nur bei einen der 3 Mailserver? Und teilw. bei ein und derselben Mail mal und mal nicht? - Wie müssten IPTabels Rules auf einem Relay für sowohl eingehenden als auch ausgehenden Mailverkehr aussehen, damit es nicht zu solchen Übertragungsproblemen kommt? Ich kann ja nicht die ganze Welt Whitelisten?!?
VG
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
Hi!
Am 27.06.2016 um 10:25 schrieb Stephan Jacob:
Hallo Postfixler,
ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. hat einer von euch eine Idee, wie folgende Situation zu Stande kommt:
Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert (Regeln sind unten beschrieben). Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 verschiedene Mailserver weiterleiten. Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der Uniklinik) kam es bei vereinzelnden Mails zu Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation with uniklinikmailserver[149.AAA.BBB.CCC] timed out while sending message body)" gequeued.
Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. Dort aber auch nicht bei allen "großen" Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver gesendet habe, konnte ich den Fehler nicht nachstellen. Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 Stunden) von alleine aus der Queue und wurden laut Log auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der Fehler auftritt auf einen anderen Kanal erfoglreich Mails zum dem Mailserver durch, d.h. er war auch verfügbar.
Der entgegennehmende Server ist temporär überlastet und kann während dieser Lastspitzen keine grossen Mails in akkzeptabler Zeit prüfen. Ein Timeout im Client ist die Folge. Wenn die Last gesunken ist *und* wenn Dein Client einen erneuten Zustellversuch unternimmt, geht die Mail dann durch.
p@
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
(In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein Mailversand dort stattfinden)
Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation mit dem Uniklinik-Server gedropt werden mitgeloggt. Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam folgende Log-Einträge gefunden:
Jun 23 12:23:33 mx3 kernel: [ 10.790460] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00 PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK URGP=0
Oder bei einer anderen Mail: Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00 PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 ACK PSH URGP=0
(149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur Sicherheit noch einmal: Diese Einträge kamen als ich (141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe.
Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung nicht funktioniert hat. Zu dem Zeitpunkt, wo die zuvor durch fehlerhafte Übertragung gequeueten Mails übertragen wurden, finden sich auch keine gedroppten Pakete im IPTabeles Log. Das Problem konnte ich dadurch vermeiden, indem ich in der IPTables sämtliche Kommunikation von und zu dem Uniklinik Mailserver erlaubt habe: -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -j ACCEPT
Der Mailserver der Uniklinik betreibt Postfix in unbekannter Version. Mails zu einem anderen Postfix Server intern und unserem Exchange Server intern laufen ohne Probleme. Ich betreibe Postfxi 2.11.
Meine Fragen sind nun:
- Was werden da für TCP Pakete an mich gesendet, die verworfen werden? Wenn diese zur "normalen" Kommunikation beim Mailaustausch
gehören, müssten die doch bei jeder Mail kommen oder?
- Wieso, findet diese Kommunikation nur bei einigen wenigen Mails statt und bisher nur bei einen der 3 Mailserver? Und teilw. bei
ein und derselben Mail mal und mal nicht?
- Wie müssten IPTabels Rules auf einem Relay für sowohl eingehenden als auch ausgehenden Mailverkehr aussehen, damit es nicht zu
solchen Übertragungsproblemen kommt? Ich kann ja nicht die ganze Welt Whitelisten?!?
VG
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
Hm. Also an die Überlastung glaube ich nicht. Denn das Problem hatte sich sofort nach Einrichtung der Firewall-Freigabe auf meiner Seite (also auf der Senderseite) erledigt. Auch weiß ich, dass die Gegenseite nur Mails von 5 IP's annimmt, bei denen ich jeweils Einblick in die Logs habe. Zu den Zeitpunkten waren nur wenige bis hin zu der einen problematischen Mail zur Gegenseite unterwegs. Nachdem ich die Firewall Freigabe eingerichtet habe gehen sehr große Mails ohne Hängen sofort durch.
Auch habe ich mal zum Spaß dann meine Firewallfreigabe wieder zurückgenommen und hatte dann nach wenigen Stunden gleich wieder eine Mail die hängen blieb. Mit der Firewallfreigabe lief es tagelang ohne Probleme. Habe ich ggf. einen Denkfehler bei meinen IPTables rules?
VG
Stephan
-----Ursprüngliche Nachricht----- Von: postfix-users [mailto:postfix-users-bounces+stephan.jacob=ovgu.de@de.postfix.org] Im Auftrag von Patrick Ben Koetter Gesendet: Montag, 27. Juni 2016 10:51 An: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Hi!
Am 27.06.2016 um 10:25 schrieb Stephan Jacob:
Hallo Postfixler,
ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. hat einer von euch eine Idee, wie folgende Situation zu Stande kommt:
Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert (Regeln sind unten beschrieben). Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 verschiedene Mailserver weiterleiten. Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der Uniklinik) kam es bei vereinzelnden Mails zu Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation with uniklinikmailserver[149.AAA.BBB.CCC] timed out while sending message body)" gequeued.
Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. Dort aber auch nicht bei allen "großen" Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver gesendet habe, konnte ich den Fehler nicht nachstellen. Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 Stunden) von alleine aus der Queue und wurden laut Log auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der Fehler auftritt auf einen anderen Kanal erfoglreich Mails zum dem Mailserver durch, d.h. er war auch verfügbar.
Der entgegennehmende Server ist temporär überlastet und kann während dieser Lastspitzen keine grossen Mails in akkzeptabler Zeit prüfen. Ein Timeout im Client ist die Folge. Wenn die Last gesunken ist *und* wenn Dein Client einen erneuten Zustellversuch unternimmt, geht die Mail dann durch.
p@
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
(In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein Mailversand dort stattfinden)
Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation mit dem Uniklinik-Server gedropt werden mitgeloggt. Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam folgende Log-Einträge gefunden:
Jun 23 12:23:33 mx3 kernel: [ 10.790460] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00 PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK URGP=0
Oder bei einer anderen Mail: Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00 PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 ACK PSH URGP=0
(149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur Sicherheit noch einmal: Diese Einträge kamen als ich (141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe.
Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung nicht funktioniert hat. Zu dem Zeitpunkt, wo die zuvor durch fehlerhafte Übertragung gequeueten Mails übertragen wurden, finden sich auch keine gedroppten Pakete im IPTabeles Log. Das Problem konnte ich dadurch vermeiden, indem ich in der IPTables sämtliche Kommunikation von und zu dem Uniklinik Mailserver erlaubt habe: -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -j ACCEPT
Der Mailserver der Uniklinik betreibt Postfix in unbekannter Version. Mails zu einem anderen Postfix Server intern und unserem Exchange Server intern laufen ohne Probleme. Ich betreibe Postfxi 2.11.
Meine Fragen sind nun:
- Was werden da für TCP Pakete an mich gesendet, die verworfen werden? Wenn diese zur "normalen" Kommunikation beim Mailaustausch
gehören, müssten die doch bei jeder Mail kommen oder?
- Wieso, findet diese Kommunikation nur bei einigen wenigen Mails statt und bisher nur bei einen der 3 Mailserver? Und teilw. bei
ein und derselben Mail mal und mal nicht?
- Wie müssten IPTabels Rules auf einem Relay für sowohl eingehenden als auch ausgehenden Mailverkehr aussehen, damit es nicht zu
solchen Übertragungsproblemen kommt? Ich kann ja nicht die ganze Welt Whitelisten?!?
VG
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
On 27.06.2016 10:51, Patrick Ben Koetter wrote:
Hi!
Am 27.06.2016 um 10:25 schrieb Stephan Jacob:
Hallo Postfixler,
ich bin auf ein Phänomen gestoßen, welches ich mir nicht erklären kann. Ggf. hat einer von euch eine Idee, wie folgende Situation zu Stande kommt:
Ich habe einen Relay Server aufgesetzt und diesen mit IPTables abgesichert (Regeln sind unten beschrieben). Der Server soll vornehmlich Mails "von außen" annehmen und dann intern an 3 verschiedene Mailserver weiterleiten. Bei der Weiterleitung an einen der 3 Mailserver (den unserer Kollegen aus der Uniklinik) kam es bei vereinzelnden Mails zu Zustellungsproblemen und die Mails wurden mit "status=deferred (conversation with uniklinikmailserver[149.AAA.BBB.CCC] timed out while sending message body)" gequeued.
Das Problem trat grundsätzlich nur bei "großen" Mails (beobachtet bei 5MB bis 35MB) auf. Dort aber auch nicht bei allen "großen" Mails. Als ich verschiedene Testmails verschiedener Größe an den Mailsserver gesendet habe, konnte ich den Fehler nicht nachstellen. Problematische Mails verschwanden irgendwann (mal nach 20 Minuten, mal nach 5 Stunden) von alleine aus der Queue und wurden laut Log auch an den Uniklinik-Server übertragen. Auch gingen zum Zeitpunkt, wo der Fehler auftritt auf einen anderen Kanal erfoglreich Mails zum dem Mailserver durch, d.h. er war auch verfügbar.
Der entgegennehmende Server ist temporär überlastet und kann während dieser Lastspitzen keine grossen Mails in akkzeptabler Zeit prüfen. Ein Timeout im Client ist die Folge. Wenn die Last gesunken ist *und* wenn Dein Client einen erneuten Zustellversuch unternimmt, geht die Mail dann durch.
p@
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
diese line ist merkwürdig, öffnest du ungehindert jeden port für die ganze Welt?
-A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP
diese line kommt hier gar nicht mehr zum tragen ...
-A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT
diese line ebenfalls obsolete in dieser reihenfolge ... weil darüber schon jeder port für alle freigegeben ist ...
-A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT
sicher, daß SSH nicht von woanders ebenfalls geht ..., sehe oben
-A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
ich denke hier ist irgendwo der hund begraben
(In Zeile 7 wird bewusst eines unserer Subnetze ausgeschlossen, es soll kein Mailversand dort stattfinden)
könntest die intentionen, welche du mit iptables bewirken wolltest zusammenfassen, dann kann ich dir die korrigierte variante zeigen ...
Im Zuge der Problemfindung habe ich dann die Pakete, die in der Kommunikation mit dem Uniklinik-Server gedropt werden mitgeloggt. Dabei habe ich bei den Mails, bei denen der oben beschriebene Fehler vorkam folgende Log-Einträge gefunden:
Jun 23 12:23:33 mx3 kernel: [ 10.790460] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=64 TOS=0x00 PREC=0x00 TTL=60 ID=64801 DF PROTO=TCP SPT=25 DPT=60337 WINDOW=480 RES=0x00 ACK URGP=0
hier wird ein antwort-paket verworfen ...
Oder bei einer anderen Mail: Jun 23 12:48:32 mx3 kernel: [ 1509.990907] IPTables-Dropped: IN=eth0 OUT= SRC=149.AAA.BBB.CCC DST=141.AAA.BBB.CCC LEN=168 TOS=0x00 PREC=0x00 TTL=60 ID=36782 DF PROTO=TCP SPT=25 DPT=32982 WINDOW=3797 RES=0x00 ACK PSH URGP=0
hier ebenso ...
(149.AAA.BBB.CCC ist der Uniklinikserver und 141.AAA.BBB.CCC bin ich). Zur Sicherheit noch einmal: Diese Einträge kamen als ich (141.AAA.BBB.CCC) an die Uniklinik (149.AAA.BBB.CCC) Mails gesendet habe.
SRC=149.AAA.BBB.CC DST=141.AAA.BBB.CCC SPT=25 DPT=xxxx source = uniklinik server port 25 dest = dein server irgendein port
Es wurden aber nur Pakete bei den Mails verworfen, bei denen die Übertragung nicht funktioniert hat.
oder die Umkehrung, weil Pakete verworfen wurden, funktionierte die Übertragung nicht ...
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
diese line ist merkwürdig, öffnest du ungehindert jeden port für die ganze Welt?
Nein, tut er meines erachtens nicht. Wenn ich das richtig sehe, dann gilt diese Rule nur für Verbindungen mit dem State „RELATED“ oder „ESTABLISHED“. Das sind in der Regel eingehende Pakete die sich auf bereits bestehende Verbindungen beziehen. Also in der Regel Antwort-Pakete für Verbindungen, die der Server selbst nach aussen iniitiiert hat. Ohne eine solche Regel würden keine Antwort-Pakete durch die Firewall kommen, die der Server selbst angefragt hat (z.B. Antworten auf DNS-Anfragen, die der Server an die DNS-Server verschickt).
Viele Grüße, Jörn Bredereck
Guten Morgen,
nach einen Tipp gestern, nicht nur ICMP-Ping Pakete in der IPTables zu erlauben, habe ich meine Regeln gestern Abend wie folgt modifiziert und über Nacht laufen lassen: Zunächst habe ich meine "erlaube Alles von Uniklinikserver Regel" rausgenommen und an das Ende meines Regelwerkes die Regel "erlaube alle ICMP Pakete von Uniklinikserver" angefügt. Leider bin ich nicht so hundertprozentig bewandert mit IPTabels und hatte mir das Grundgerüst von einem Kollegen geben lassen, der es so ähnlich auf Webservern (da nur Port 443 offen anstatt 25) betreibt. Folgendes Regelwerk war heute Nacht aktiv:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.MMM.NNN.OOO/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.XXX.YYY.ZZZ/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -i eth0 -p icmp -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
(141.AAA.BBB.CCC ist wieder mein Mailserver, der beim Senden an 149.AAA.BBB.CCC ab und zu Probleme hat; 149.AAA.BBB.CCC ist der problematische Uniklinik Mailserver; alles andere mit 141.*.*.* sind subnetze bei uns)
Kurz gesagt es ging nicht. Ich hatte das selbe Phänomen bei einigen Mails erneut. Und laut Log wurden wieder nur TCP und keine ICMP Pakete bei den gescheiterten Übertragungen verworfen.
Dann bin ich dem Hinweis von (ich glaube es war Walter) nachgegangen, der meinte das diese Zeile -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT alles aufmacht. Ich habe einfach mal versucht eine SSH Verbindung aus einem Subnetz, welches nicht in der Zeile mit dem Port 22 erlaubt ist, aufzumachen. Das ist dann mit einem Timeout gescheitert. D.h. das sollte doch alles dicht sein?
Mein Intension die ich mit meiner IPTables Regel durchführen möchte:
1) Connection zum Mailserver per SSH nur aus ausgewähltem Subnetz möglich 2) Da es ein Relay ist soll der Server Mails von jedem annehmen und an jeden verteilen dürfen (alles weitere habe ich in der main.cf und entspr. restrictions gelöst) 3) Das Relay soll von einem definierten Subnetz keine Mails annehmen. Das habe ich eigentlich auch schon mit Restrictions in Postfix geregelt, dachte mir aber, wenn ich die Firewall dicht mache, brauch der Postfix sich damit gar nicht erst beschäftigen. 4) Ansonsten soll natürlich alles laufen was für den Betrieb eines Servers notwendig ist (Updates einspielen, interne Kommunikation, etc)
Eigentlich nichts wildes. Es lief auch mehrere Wochen Reibungslos zu zwei weiteren internen Mailservern. Nur als ich auf einmal letzte Woche Mailverkehr der für unsere Uniklinik bestimmt ist über das Relay geleitet habe, bekamm ich ab und an das beschriebene Phänomen beim Abliefern der Mails in der Uniklinik.
Danke für eure Hilfe
VG
Stephan
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
-----Ursprüngliche Nachricht----- Von: postfix-users [mailto:postfix-users-bounces+stephan.jacob=ovgu.de@de.postfix.org] Im Auftrag von Jörn Bredereck Gesendet: Montag, 27. Juni 2016 20:13 An: Walter H. Walter.H@mathemainzel.info Cc: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
diese line ist merkwürdig, öffnest du ungehindert jeden port für die ganze Welt?
Nein, tut er meines erachtens nicht. Wenn ich das richtig sehe, dann gilt diese Rule nur für Verbindungen mit dem State „RELATED“ oder „ESTABLISHED“. Das sind in der Regel eingehende Pakete die sich auf bereits bestehende Verbindungen beziehen. Also in der Regel Antwort-Pakete für Verbindungen, die der Server selbst nach aussen iniitiiert hat. Ohne eine solche Regel würden keine Antwort-Pakete durch die Firewall kommen, die der Server selbst angefragt hat (z.B. Antworten auf DNS-Anfragen, die der Server an die DNS-Server verschickt).
Viele Grüße, Jörn Bredereck
Hallo Stephan,
hast du mal die MTU händisch getestet? Dass das Path-MTU-Discovery nicht zuverlässig läuft, kann auch an der Gegenseite liegen. Versuch doch mal mit verschieden grossen PING-Paketen herauszufinden, welche MTU zwischen den beiden Servern möglich ist. Anschließend könntest du der Netzwerkkarte einfach die maximale MTU geben, die möglich ist.
Unter Linux kannst du mit
ping -M do -s <packet size> <ZIEL>
testen, ob entsprechend grosse Pakete ohne Fragmentierung durchgehen. Fang mit einer MTU von 1500 an. Wenn du die Rückmeldung „Frag needed and DF set“ bekommst, dann versuch es mit einer kleineren MTU (z.B. 1490), bis das Paket sauber durch geht. Danach einfach mit
ifconfig <device> mtu <wert>
die MTU für dein Interface festlegen.
Anschließend sollten nur noch Pakete verschickt werden, die maximal diese Größe haben. Ggf. ist dein Problem damit dann gelöst.
Siehe auch: http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pi...
Viele Grüße, Jörn Bredereck
Ok, ich glaube hier benötige ich Interpretationshilfe:
Zuerst die Ausgabe von ping -M do -s 1500 149.AAA.BBB.CCC
user@m:~$ ping -M do -s 1500 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1500(1528) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ^C --- 149.AAA.BBB.CCC ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3023ms
Das kam mir spanisch vor. Bei Google habe ich gefunden, dass der noch 28 Bytes Paketheader auf die angegebene auf die angebende Größe packt. Somit ergeben sich 1528 was größer als die MTU auf meinem Server von 1500 ist. Ich habe mal zum Spaß einen Server von mir angepingt, wo ich in der ifconfig gesehen habe, dass die MTU auf 1500 beim Zielsystem steht; da kam der selbe Fehler.
Dann habe ich mal eine Größe von 1500-28 = 1472 angegeben und das scheint zu klappen: user@m:~$ ping -M do -s 1472 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1472(1500) bytes of data. 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=1 ttl=60 time=1.65 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=2 ttl=60 time=1.66 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=3 ttl=60 time=1.73 ms ^C --- 149.AAA.BBB.CCC ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.650/1.681/1.730/0.058 ms
(All Pings mit Größen zw. 1500 und 1472 sind mit derselben Fehlermeldung wie der Ping mit 1500 [siehe oben] gescheitert)
Heißt dass, ich muss meine MTU auf 1472 runterschrauben? Das glaube ich aber irgendwie nicht, weil zu einem System wo auch eine MTU von 1500 konfiguriert ist bekomme ich auch die oben beschriebene Fehlermeldung.
Danke für eure vielen Hinweise.
VG
Stephan
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
-----Ursprüngliche Nachricht----- Von: Jörn Bredereck [mailto:jb@bw-networx.net] Gesendet: Dienstag, 28. Juni 2016 10:15 An: Stephan Jacob stephan.jacob@ovgu.de Cc: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Hallo Stephan,
hast du mal die MTU händisch getestet? Dass das Path-MTU-Discovery nicht zuverlässig läuft, kann auch an der Gegenseite liegen. Versuch doch mal mit verschieden grossen PING-Paketen herauszufinden, welche MTU zwischen den beiden Servern möglich ist. Anschließend könntest du der Netzwerkkarte einfach die maximale MTU geben, die möglich ist.
Unter Linux kannst du mit
ping -M do -s <packet size> <ZIEL>
testen, ob entsprechend grosse Pakete ohne Fragmentierung durchgehen. Fang mit einer MTU von 1500 an. Wenn du die Rückmeldung „Frag needed and DF set“ bekommst, dann versuch es mit einer kleineren MTU (z.B. 1490), bis das Paket sauber durch geht. Danach einfach mit
ifconfig <device> mtu <wert>
die MTU für dein Interface festlegen.
Anschließend sollten nur noch Pakete verschickt werden, die maximal diese Größe haben. Ggf. ist dein Problem damit dann gelöst.
Siehe auch: http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pi...
Viele Grüße, Jörn Bredereck
Am 28.06.2016 um 11:27 schrieb Stephan Jacob stephan.jacob@ovgu.de:
Ok, ich glaube hier benötige ich Interpretationshilfe:
Zuerst die Ausgabe von ping -M do -s 1500 149.AAA.BBB.CCC
user@m:~$ ping -M do -s 1500 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1500(1528) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ^C --- 149.AAA.BBB.CCC ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3023ms
Das kam mir spanisch vor. Bei Google habe ich gefunden, dass der noch 28 Bytes Paketheader auf die angegebene auf die angebende Größe packt. Somit ergeben sich 1528 was größer als die MTU auf meinem Server von 1500 ist. Ich habe mal zum Spaß einen Server von mir angepingt, wo ich in der ifconfig gesehen habe, dass die MTU auf 1500 beim Zielsystem steht; da kam der selbe Fehler.
ja, das macht Sinn. Da der Header noch drauf kommt, muss man das bei der Grösse der ICMP-Pakete berücksichtigen.
Dann habe ich mal eine Größe von 1500-28 = 1472 angegeben und das scheint zu klappen: user@m:~$ ping -M do -s 1472 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1472(1500) bytes of data. 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=1 ttl=60 time=1.65 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=2 ttl=60 time=1.66 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=3 ttl=60 time=1.73 ms ^C --- 149.AAA.BBB.CCC ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.650/1.681/1.730/0.058 ms
Ok, dann scheinen alle beteiligten Router und die Gegenstelle eine MTU von 1500 zu unterstützen. Dann kannst du das als Ferhlerquelle wohl ausschließen. Schade, das wäre einfach zu fixen gewesen.
-----Ursprüngliche Nachricht-----
Von: Jörn Bredereck [mailto:jb@bw-networx.net] Gesendet: Dienstag, 28. Juni 2016 10:15 An: Stephan Jacob stephan.jacob@ovgu.de Cc: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Hallo Stephan,
hast du mal die MTU händisch getestet? Dass das Path-MTU-Discovery nicht zuverlässig läuft, kann auch an der Gegenseite liegen. Versuch doch mal mit verschieden grossen PING-Paketen herauszufinden, welche MTU zwischen den beiden Servern möglich ist. Anschließend könntest du der Netzwerkkarte einfach die maximale MTU geben, die möglich ist.
Unter Linux kannst du mit
ping -M do -s <packet size> <ZIEL>
testen, ob entsprechend grosse Pakete ohne Fragmentierung durchgehen. Fang mit einer MTU von 1500 an. Wenn du die Rückmeldung „Frag needed and DF set“ bekommst, dann versuch es mit einer kleineren MTU (z.B. 1490), bis das Paket sauber durch geht. Danach einfach mit
ifconfig <device> mtu <wert>
die MTU für dein Interface festlegen.
Anschließend sollten nur noch Pakete verschickt werden, die maximal diese Größe haben. Ggf. ist dein Problem damit dann gelöst.
Siehe auch: http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pi...
Viele Grüße, Jörn Bredereck
--
B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info@bw-networx.net
AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch
Trotzdem vielen Dank! Ich lebe jetzt erst einmal damit. Mit meiner totalen Firewallfreigabe zu dem besagten Server läuft der Verkehr ja erst einmal ohne Probleme. Und da die Gegenseite vertrauenswürdig ist, kann ich damit Leben das meine Ports von dort aus erreichbar sind.
Ich werde mal beobachten, ob ich ggf. zu irgendwelchen anderen Stellen im großen weiten Internet auch ein solches Phänomen auftreten wird. Der Server ist noch recht jung und hat daher bei weitem noch nicht mit allen mehr oder minder "exotischen" Gegenstellen, die es so gibt gesprochen.
VG
Stephan
Stephan Jacob
Otto-von-Guericke Universität Magdeburg Universitätsrechenzentrum (URZ)
Universitätsplatz 2 Gebäude 26 - 035
39106 Magdeburg
Tel.: 0391-67-58572 Fax: 0391-67-11134
-----Ursprüngliche Nachricht----- Von: Jörn Bredereck [mailto:jb@bw-networx.net] Gesendet: Mittwoch, 29. Juni 2016 17:12 An: Stephan Jacob stephan.jacob@ovgu.de Cc: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Am 28.06.2016 um 11:27 schrieb Stephan Jacob stephan.jacob@ovgu.de:
Ok, ich glaube hier benötige ich Interpretationshilfe:
Zuerst die Ausgabe von ping -M do -s 1500 149.AAA.BBB.CCC
user@m:~$ ping -M do -s 1500 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1500(1528) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ^C --- 149.AAA.BBB.CCC ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3023ms
Das kam mir spanisch vor. Bei Google habe ich gefunden, dass der noch 28 Bytes Paketheader auf die angegebene auf die angebende Größe packt. Somit ergeben sich 1528 was größer als die MTU auf meinem Server von 1500 ist. Ich habe mal zum Spaß einen Server von mir angepingt, wo ich in der ifconfig gesehen habe, dass die MTU auf 1500 beim Zielsystem steht; da kam der selbe Fehler.
ja, das macht Sinn. Da der Header noch drauf kommt, muss man das bei der Grösse der ICMP-Pakete berücksichtigen.
Dann habe ich mal eine Größe von 1500-28 = 1472 angegeben und das scheint zu klappen: user@m:~$ ping -M do -s 1472 149.AAA.BBB.CCC PING 149.AAA.BBB.CCC (149.AAA.BBB.CCC) 1472(1500) bytes of data. 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=1 ttl=60 time=1.65 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=2 ttl=60 time=1.66 ms 1480 bytes from 149.AAA.BBB.CCC: icmp_seq=3 ttl=60 time=1.73 ms ^C --- 149.AAA.BBB.CCC ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.650/1.681/1.730/0.058 ms
Ok, dann scheinen alle beteiligten Router und die Gegenstelle eine MTU von 1500 zu unterstützen. Dann kannst du das als Ferhlerquelle wohl ausschließen. Schade, das wäre einfach zu fixen gewesen.
-----Ursprüngliche Nachricht-----
Von: Jörn Bredereck [mailto:jb@bw-networx.net] Gesendet: Dienstag, 28. Juni 2016 10:15 An: Stephan Jacob stephan.jacob@ovgu.de Cc: postfix-users@de.postfix.org Betreff: Re: Unklare Übertragungsprobleme bei einigen Mails
Hallo Stephan,
hast du mal die MTU händisch getestet? Dass das Path-MTU-Discovery nicht zuverlässig läuft, kann auch an der Gegenseite liegen. Versuch doch mal mit verschieden grossen PING-Paketen herauszufinden, welche MTU zwischen den beiden Servern möglich ist. Anschließend könntest du der Netzwerkkarte einfach die maximale MTU geben, die möglich ist.
Unter Linux kannst du mit
ping -M do -s <packet size> <ZIEL>
testen, ob entsprechend grosse Pakete ohne Fragmentierung durchgehen. Fang mit einer MTU von 1500 an. Wenn du die Rückmeldung „Frag needed and DF set“ bekommst, dann versuch es mit einer kleineren MTU (z.B. 1490), bis das Paket sauber durch geht. Danach einfach mit
ifconfig <device> mtu <wert>
die MTU für dein Interface festlegen.
Anschließend sollten nur noch Pakete verschickt werden, die maximal diese Größe haben. Ggf. ist dein Problem damit dann gelöst.
Siehe auch: http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pi...
Viele Grüße, Jörn Bredereck
--
B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info@bw-networx.net
AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch
On 28.06.2016 07:32, Stephan Jacob wrote:
Mein Intension die ich mit meiner IPTables Regel durchführen möchte:
- Connection zum Mailserver per SSH nur aus ausgewähltem Subnetz
möglich
Der sshd ist für gewöhnlich gegen die libwrap gelinkt, honoriert also die in /etc/hosts.allow und /etc/hosts.deny getätigten Einträge.
=> Kein Gebastel mit iptables notwendig.
- Da es ein Relay ist soll der Server Mails von jedem annehmen und
an jeden verteilen dürfen (alles weitere habe ich in der main.cf und entspr. restrictions gelöst) 3) Das Relay soll von einem definierten Subnetz keine Mails annehmen. Das habe ich eigentlich auch schon mit Restrictions in Postfix geregelt, dachte mir aber, wenn ich die Firewall dicht mache, brauch der Postfix sich damit gar nicht erst beschäftigen.
Ich würde es andersherum angehen, denn dann: => Kein Gebastel mit iptables notwendig.
Natürlich spricht nichts dagegen, um die so "abgeschotteten" Konfigurationem der einzelnen Dienste nochmal einen Zaun mit iptables herumzuziehen, aber man stellt sich damit oftmals selbst ein Bein. Been there, done that...
Mit freundlichen Grüßen Christian Schmidt
Hallo zusammen,
ich seh im Moment scheinbar der Wald vor lauter Bäumen nicht mehr. Folgendes Gebilde hat mir ein Kollege hinterlassen:
Ironport-> Host A -> Host B
die Ironport leitet eingehende Mails aus dem Internet für eine Domain Namens xxx.de an Host A, Host A nutzt die Ironport als Relay ins Internet.
Host A (172.2.1.10) hält ein Postfach prod@xxx.de Host B (172.2.1.9) hält ein Postfach test@xxx.de
Host A soll also Mails an prod@xxx.de lokal zustellen und Mails an test@xxx.de an Host B weiterleiten. Die User sind lokale Betriebssystemuser. Das hat mein Kollege angefangen und ich habe die Ehre das fertig zu machen. Der Posteingang funktioniert scheinbar fehlerfrei. Aber beim internen Routing der Mails von einem host zum anderen gibts Probleme.
also
Host A: transport: xxx.de : [172.2.1.9] smtp:[172.2.1.9] * smtp:ip.der.iron.port
Host A: virtual: test@xxx.de test@172.2.1.9
Host A: main.cf: relay_host = ip.der.iron.port mydomain = xxx.de mynetwork = 172.2.1.10 172.2.1.9
Host A: main.cf: relay_host = 172.2.1.10 mydomain = xxx.de mynetwork = 172.2.1.9
Mein Problem ist folgendes: Wenn von Host B eine Mail an prod@xxx.de geschickt werden soll, dann wird sie zwar zu Host A relayed, aber dort nicht zugestellt. Host A versucht die Mail an die Ironport weiterzuleiten
das logfile sieht so aus:
Jun 30 17:09:06 host_a postfix/smtpd[48417]: connect from host_b[172.24.6.9] Jun 30 17:09:06 host_a postfix/smtpd[48417]: 624A2386: client=host_b[172.24.6.9] Jun 30 17:09:06 host_a postfix/cleanup[48420]: 624A2386: message-id=<20160630150931.A2B592CA@host_b.xxx.de> Jun 30 17:09:06 host_a postfix/qmgr[47357]: 624A2386: from=root@xxx.de, size=667, nrcpt=1 (queue active) Jun 30 17:09:06 host_a postfix/smtpd[48417]: disconnect from host_b[172.24.6.9] Jun 30 17:09:06 host_a postfix/smtp[48421]: 624A2386: to=fbelau@vwi-immoblue.de, relay=ironport.yyyyy.de[ironport.yyyyy.de]:25, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent (250 ok: Message 6760152 accepted) Jun 30 17:09:06 host_a postfix/qmgr[47357]: 624A2386: removed Jun 30 17:09:06 host_a postfix/smtpd[48417]: connect from unknown[ironport.yyyyy.de] Jun 30 17:09:06 host_a postfix/smtpd[48417]: 66451386: client=unknown[ironport.yyyyy.de] Jun 30 17:09:06 host_a postfix/cleanup[48420]: 66451386: message-id=63061f$6e9mp@ironport.yyyyy.de Jun 30 17:09:06 host_a postfix/qmgr[47357]: 66451386: from=<>, size=2336, nrcpt=1 (queue active) Jun 30 17:09:06 host_a dovecot: lmtp(48425): Connect from local Jun 30 17:09:06 host_a dovecot: lmtp(48425): Error: user root: Invalid settings in userdb: userdb returned 0 as uid Jun 30 17:09:06 host_a postfix/lmtp[48424]: 66451386: to=root@xxx.de, relay=host_a.xxx.de[private/dovecot-lmtp], delay=0.01, delays=0.01/0/0/0, dsn=4.3.0, status=deferred (host host_a.xxx.de[private/dovecot-lmtp] said: 451 4.3.0 root@xxx.de Invalid user settings. Refer to server log for more information. (in reply to RCPT TO command)) Jun 30 17:09:06 host_a dovecot: lmtp(48425): Disconnect from local: Successful quit Jun 30 17:09:11 host_a postfix/smtpd[48417]: disconnect from unknown[ironport.yyyyy.de]
das Problem ist, das muß schnell funktionieren... aber ich steh im moment auf dem Schauch. Kann mir einer von euch nen Tipp geben wo ich drehen muß.
MfG, Frank
Hallo Frank,
also ohne jetzt wirklich dein Problem verstanden zu haben, kann ich dir nur den Tipp geben, für das interne Routing mit sauber getrennten Subdomains zu arbeiten.
D.h. wenn dein Host-A Mails für die selbe externe Domain an andere User der selben externen Domain auf Host B routen soll, dann map die Ziel-Adresse über einen Eintrag in der Virtual-Table auf eine andere Subdomain um, und route nur diese Subdomain auf den Host B.
Auf dem Host-B brauchst du dann die offizielle (externe) Domain gar nicht zu hinterlegen, sondern arbeitest dort ausschließlich mit der Subdomain. Alle mails die für externe Domains sind, werden wieder zu Host A geroutet.
Viele Grüße, Jörn Bredereck
ja wenn das so einfach wäre... der Kunde fordert das so, einer unserer super System-Architekten hat ihm versprochen das geht, der Kollege vor mit hat sich in Elternzeit verabschiedet und ich stehe jetzt da und muß den Müll bauen...
das mit subdomains wäre eine Möglichkeit, die andere wäre ne eigene Domain für die Testsysteme, aber das möchte der Kunde alles nicht.
MfG, Frank.
Am 30.06.2016 um 18:52 schrieb Jörn Bredereck:
Hallo Frank,
also ohne jetzt wirklich dein Problem verstanden zu haben, kann ich dir nur den Tipp geben, für das interne Routing mit sauber getrennten Subdomains zu arbeiten.
D.h. wenn dein Host-A Mails für die selbe externe Domain an andere User der selben externen Domain auf Host B routen soll, dann map die Ziel-Adresse über einen Eintrag in der Virtual-Table auf eine andere Subdomain um, und route nur diese Subdomain auf den Host B.
Auf dem Host-B brauchst du dann die offizielle (externe) Domain gar nicht zu hinterlegen, sondern arbeitest dort ausschließlich mit der Subdomain. Alle mails die für externe Domains sind, werden wieder zu Host A geroutet.
Viele Grüße, Jörn Bredereck
Hallo Frank,
Am 30.06.2016 um 17:51 schrieb Frank Belau:
Host A: transport: xxx.de : [172.2.1.9] smtp:[172.2.1.9]
- smtp:ip.der.iron.port
Schnellschuss:
Die transport auf Host A würde ich ausschließlich so schreiben:
test@xxx.de smpt:[172.2.1.9]
"* smtp:ip.der.iron.port" brauchst Du m.E. nicht, da relayhost (ohne underscore) in main.cf.
Mein Problem ist folgendes: Wenn von Host B eine Mail an prod@xxx.de geschickt werden soll, dann wird sie zwar zu Host A relayed, aber dort nicht zugestellt. Host A versucht die Mail an die Ironport weiterzuleiten
Ja, weil IMHO Deine bisherige transport auf Host A falsch ist ("* smtp:ip.der.iron.port").
Übrigens und ohne Deine main.cf komplett zu kennen: Ich würde bei mynetworks (hast Du das 's' bei Deinem Config-Schnipsel nur vergessen zu tippen?) immer auch 127.0.0.0/8 mit angeben.
HTH und Gruß Markus
On Thu, 30 Jun 2016 at 07:50:54PM +0200, Markus Winkler wrote:
Die transport auf Host A würde ich ausschließlich so schreiben:
test@xxx.de smpt:[172.2.1.9]
----------------^^^^ natürlich muss es 'smtp' heißen, sorry.
Gruß Markus
Hallo,
Das Problem trat auf, als ich folgende IPTabels Regeln aktiv hatte:
*filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 141.AAA.240.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j DROP -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn --dport 25 -j ACCEPT -A INPUT -s 141.AAA.13.CCC/24 -d 141.AAA.BBB.CCC -i eth0 -p tcp -m tcp --syn -m multiport --dports 22 -j ACCEPT -A INPUT -d 141.AAA.BBB.CCC -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 141.AAA.BBB.CCC -o eth0 -j ACCEPT COMMIT
Das Problem konnte ich dadurch vermeiden, indem ich in der IPTables sämtliche Kommunikation von und zu dem Uniklinik Mailserver erlaubt habe: -A INPUT -s 149.AAA.BBB.CCC -d 141.AAA.BBB.CCC -j ACCEPT
erlaub testweise auch mal die anderen ICMP-Typen. Evtl. hast du es mit Paket-Fragmentierung aufgrund fehlschlagender Path-MTU-Discovery zu tun. Die Hosts tauschen sich per ICMP über die maximale Paket-Grösse aus. Wenn du das blockierst kann es zur Fragmentierung kommen, die sich bei längeren Verbindungen „hochschaukelt“ und in einem Timeout endet. Ich bin nicht sicher, ob Typ8 (Echo) hier ausreicht.
- Wie müssten IPTabels Rules auf einem Relay für sowohl eingehenden als auch ausgehenden Mailverkehr aussehen, damit es nicht zu
solchen Übertragungsproblemen kommt? Ich kann ja nicht die ganze Welt Whitelisten?!?
Ich mache immer nur Port 25 (ggf. noch 587) und ICMP (komplette) auf und das reicht eigentlich.
Viele Grüße, Jörn Bredereck
participants (7)
-
Christian Schmidt -
Frank Belau -
Jörn Bredereck -
Markus Winkler -
Patrick Ben Koetter -
Stephan Jacob -
Walter H.