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

[Werner Detter]

Hi Peer,

wunderbare Ausführung deinerseits, danke dir. Jetzt wo du es ansprichst mit der
MTU/Fragmentierung/Firwall fällt mir gerade ein, dass ich den Fall auch schon
mal hatte (und da kam ich nach Analyse des Traffics auf die Fragmentierung
die nicht funktioniert hatte da die Firewall des Gegenüber ICMP Fragmentation
verboten hatte). Danke, YMMD :)

Schöne Grüße,
Werner



Am 21.02.13 10:21, schrieb Peer Heinlein:
> 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