[Postfixbuch-users] (kein Betreff)

[Andreas Winkelmann]

On Friday 08 June 2007 18:30, Sandy Drobic wrote:

> >>> Anbei noch der log-schnipsel
> >>>
> >>> /var/log/mail
> >>> Jun  7 16:20:11 mail postfix/smtpd[7058]: connect from
> >>> japantest.homelinux.com[83.236.201.154]
> >>> Jun  7 16:20:17 mail postfix/smtpd[7058]: disconnect from
> >>> japantest.homelinux.com[83.236.201.154]
> >>
> >> Sehr seltsam. Denn der Eintrag japantest.homelinux.com[83.236.201.154]
> >> zeigt, dass der Reverse-Eintrag aufgelöst wurde, sonst würde dort
> >> unknown stehen. Auch die Connect-Zeit ist seltsam, denn es dauert
> >> eindeutig länger als 6 Sekunden, bis das Banner erscheint.
> >
> > Sooo seltsam ist es denn auch nicht ;-))
> >
> > Bevor die smtpd-connect Zeile nach Syslog geschickt wird, wurde ja
> > bereits die Namensauflösung gemacht. Auch zu erkennen an dem DNS-Namen in
> > der Zeile.
> >
> > Die 6 Sekunden hast Du - Sandy - gebraucht um QUIT zu tippen ;-)
>
> Das könnte beim zweiten Watchdog-Timing sein, mich verblüfft jedoch, dass
> der erste Timer laut Log schneller kommt als ich es vor der Tastatur
> erlebt habe. Die Gesamtzeit im Log ist kürzer als die Zeit, die ich
> verbunden war mit dem Server.

Was für Watchdog Timer? Was für eine Gesamtzeit? Beziehst Du dich auf die 6 
Sekunden?

Postfix macht bei einem Connect einen Reverse-Lookup der IP-Adresse und 
anschliessend nochmal das gleiche vorwärts um zu kontrollieren ob bei den 
DNS-Antworten alles stimmt. Dann erst schickt Postfix die 
Zeile "postfix/smtpd[7058]: connect from 
japantest.homelinux.com[83.236.201.154]" an syslog. Der klebt die aktuelle 
Zeit und den Hostnamen dazu und schreibts in /var/log/mail. Das bedeutet es 
ist nicht zu erkennen, wie lange die DNS-Auflösung nun wirklich gebraucht 
hat. Der Zeitpunkt wo die Logzeile an syslog geht, dürfte ungefähr zeitgleich 
mit der Sekunde sein, wo Du den Banner gesehen hast.

> > Es gibt keine Zeile wann der wirkliche Connect passiert (ist). Der OP
> > könnte den smtpd mit -vv laufen lassen bzw. auf nem wirklichen Livesystem
> > lieber debug_peer_level und debug_peer_list mit der IP-Adresse des telnet
> > Clients benutzen.
>
> Das wäre allerdings noch einen Versuch wert. Obwohl es wohl mehr
> akademisch sein würde, denn er wird ohnehin einen DNS-Server aufsetzen.

Hmm, ein Caching DNS ist kein Allheilmittel für DNS-Probleme.

In seinem Fall war es ja ein Mailclient, der beim Mailabliefern einen Fehler 
gebracht hat. Da der Caching DNS erst wirkt, wenn er die Daten einmal hat 
wird der Client denselben Fehler auch beim ersten Mal bekommen. Versucht er 
es dann nochmal, dann bringt es erst was. Damit geben sich manche User meist 
nicht zufrieden.

Evtl. hat er ja sogar schon sowas am laufen. Suse war seit einiger Zeit sehr 
grosszügig mit dem Installieren von diesem nscd. 

-- 
	Andreas