AW: Unklare Übertragungsprobleme bei einigen Mails

Mo Jun 27 11:14:15 CEST 2016

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 at de.postfix.org] Im Auftrag von Patrick Ben Koetter
Gesendet: Montag, 27. Juni 2016 10:51
An: postfix-users at 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
>

-- 
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 5990 bytes
Beschreibung: nicht verfügbar
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20160627/4f1006f2/attachment-0001.bin>