Unklare Übertragungsprobleme bei einigen Mails

[Walter H.]

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


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 3827 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20160627/d1f6e72f/attachment.bin>