[Postfixbuch-users] Probs mit "timeout after END-OF-MESSAGE"

[Andreas Winkelmann]

On Donnerstag, 1. November 2007, ram at i-tux.de wrote:

> > On Donnerstag, 1. November 2007, ram at i-tux.de wrote:
> >> >> ... aber viel häufiger kommt es zu folgendem:
> >> >> Nov  1 13:56:14 mx01 postfix/smtpd[14228]: timeout after
> >> END-OF-MESSAGE
> >> >> from mxout2.volkswagen.de[194.114.62.48]
> >> >> Nov  1 13:56:14 mx01 postfix/smtpd[14228]: disconnect from
> >> >> mxout2.volkswagen.de[194.114.62.48]
> >> >> [...] ca. 5 mal hintereinander die gleichen 2 obrigen Zeilen, nur
> >>
> >> andere
> >>
> >> >> PIDs jeweils
> >> >
> >> > Versuche doch mal, deine MTU runter zu drehen. z.B. ifconfig eth0
> >>
> >> <edit
> >> +: mtu> 1456
> >>
> >> bringt leider nichts:
> >
> > Ja, weil smtpd != smtp ist. Du bist der Empfänger.
> >
> > Bei SMTP schickt der Sender die grossen Pakete, der Empfänger gibt nur
> > kurze Quittungen zurück. Daher ist es relativ unsinnig die MTU-Grösse
> > beim Empfänger herunterzudrehen.
>
> Sehe ich ein.
>
> > MTU-Probleme gibt es, wenn eine Station auf dem Weg zwischen Sender und
> > Was steht denn zwischen dem Client und dem Internet? Ist da noch ein
> > Router im Spiel?
>
> sagtest nicht gerade ich sei Empfänger? ;) Ich habe ehrlich keine Ahnung,
> was die VW AG Wolfsburg da alles zwischen seinen MXern und dem Internet
> haben könnte. Aber es wird nicht nur ein D-Link Router sein... Zwischen
> Client und Server stehen zumindest sichtbar 10 weitere Hops, ganz normales
> Routing im Inet halt.

Meine Frage bezog sich darauf was zwischen Deinem Server (Postfix) und dem 
Internet steht. Wenn es ein Root-Server bei nem Provider ist, wird da wohl 
kein eigener Router mehr im Spiel sein.

> > Kann vielleicht einfach nur der Sender ein Problem haben?
>
> Aus meiner Sicht ist es so. Nur bringt mir dieses Wissen nichts ohne
> Lösung. Wir sind als Dienstleister für VW tätig und müssen/sollten sogar
> etwaige Schwächen unseres Auftragsgebers meistern können. Und der Sender
> ist der Prio 10 MX eines DAX-Konzerns. Ist für mich immer sehr riskant da
> jemand ans Bein zu pinckeln ohne wirklich zu wissen, was los ist ;)
>
> > Am eindeutigsten bekommst Du den schuldigen heraus indem Du die Pakete
> > mitschneidest (z.B. tcpdump). Am besten sogar möglichst nah am Internet.
>
> Was würde mir der Dump verraten? Das der Client die Connection nicht
> abbaut? Hättest den Tip, auf was ich achten könnte? Mein smtpd hat eine
> öffentliche IP an eth0 (keine DMZ etc) - steht bei Hetzner.

Von der Fehlermeldung her hat der Client (Sender) die komplette Mail bei Dir 
abgeliefert hat aber das "250 2.0.0 OK ..." nicht bestätigt. Dies kann daran 
liegen, dass Dein Server es nicht gesendet hat oder dass TCP-Paket, welches 
das bestätigt verschütt gegangen ist.

Mit nem Sniffer sähe man das recht schnell. Alternativ dazu das 
Verbose-Logging für den Server einschalten und ins Log schauen.

Möglich wäre auch, dass Dein Server so lange braucht um das "250 2.0.0 
OK ... " zu senden. Was auf zuviele bzw. zu langsame Überprüfungen der Mail 
schliessen liesse. Evtl. zu viele header/body_checks oder ein lahmer 
proxy-content_filter...

-- 
	Andreas