[Postfixbuch-users] Postfix + amavis (smtpd_proxy_filter) + Error:timeout exceeded

[Peer Heinlein]

Am 21.02.2013 10:06, schrieb Werner Detter:

Hi,

> mail.host.de[81.x.x.x]: 421 4.4.2 mailgw.domain.de
> Error: timeout exceeded
> 
> Feb 20 19:31:13 mailgw postfix/smtpd[3772]: timeout after DATA (0 bytes)
> from mail.host.de[81.x.x.x]
> 
> Die Frage ist jetzt, warum läuft das in einen Timeout? 

Zu 95% ist das hier immer der Klassiker: MTU-Probleme in Zusammenhang
mit kaputten Firewalls.

> Ich kann "auf meine
> Seite" keine Probleme feststellen, hab testweise auch schon smtpd_proxy_timeout
> von 100s (default) auf 300s erhöht. Leider ohne Besserung. Bei Amavis selbst
> kommt nichts an (debug Mode geprüft). Das Ganze betrifft offensichtlich auch
> nur den einen Horst ? Scheint also wirklich so, als ob der einliefernde
> Mailserver nach dem DATA nichts mehr macht?

Was in diesen Fällen passiert ist:

*) Einer der Beteiligten hat eine MTU unter 1492. Beispielsweise weil da
SDSL oder ein Kabelmodem im Spiel ist oder sonstwas.

*) Einer der Beteiligten schickt ein zu großes IP-Paket los, was an der
Grenze zur kleinen MTU natürlich knallt. Das löst eine ICMP-Antwort
"fragmentation needed" aus, die an den Absender zurückgeht.

*) Es gibt eine ausreichend vertretene Gruppe von Firewall-Admins, die
damals im Sachkundeunterricht in der Grundschule gelernt haben will, daß
"ICMP-Pakete ja alle böse sind" und die pauschal ICMP in der Firewall
verbieten. (Oder die nur "ping" erlauben und das auch noch gut finden.).

*) Das ICMP fragmentation needed geht an der Firewall verloren.

*) Der Client erfährt also nichts davon, daß er kleinere Pakete
lossenden muß, bemerkt nur, daß er keine Antwort mehr kriegt. Er sendet
das ursprüngliche Paket nochmal und nochmal, aber das versackt natürlich
nach wie vor.

*) Irgendwann beschließend dann Postfix, daß er die Nase voll hat, weil
seit <n> Sekunden keinerlei Daten mehr vom Client ankommen und trennt
die Verbindung.

*) Das typische hier: Connect, HELO, MAIL FROM, RCPT TO: klappen bei
Mailservern fats immer noch. Ganz einfach deshalb, weil HELO-Name und
Mailadresse so kleine IP-Pakete erzeugen, daß die noch nicht in die
MTU-Probleme geraten. Die flutschen noch durch. Aber sobald der Client
nach dem DATA dann die Mail sendet, beginnt er die MTU-Größe tatsächlich
auszureizen und das knallt dann.

*) Darum, der Klassiker: Alles geht, aber nach DATA friert die
Verbindung ein. Oft sieht man schon am Reverse-Lookup des Clients, das
da SDSL oder Kabelmodem im Spiel ist...

Abhilfe: Auf beiden Seiten checken, welcher FW-Admin da
unberechtigterweise ICMP komplett gesperrt hat und dem eine
Nachilfestunde geben.

Peer


-- 
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin