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
smime.p7s
Description: S/MIME cryptographic signature
