Postfix macht Zicken
Hallo Liste. Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. In den Logs erscheint ständig: ...postfix/smtpd[13442]: lost connection after CONNECT from... Die Folge ist, daß der einliefernde Mailclient (Thunderbird) irgendwann einen Timeout kriegt, und eine Fehlermeldung bringt. Ich habe schon nach der Fehlermeldung gegoogelt, und Dinge gelesen wie - RBL (nutze ich nicht) - Kann man nix machen (Postfix-FAQ) - nicht ausreichende Anzahl von Prozessen für smtpd in der master.cf (steht bei mir auf Standard, also 100, sollte reichen). - Problem mit einem zwischengeschalteten Cisco-Router (da ist aber kein Router) - Falsche MTU (ist aber nur Ethernet dazwischen, kein DSL) Hat jemand hier einen Tip, wo ich noch suchen könnte? -- Andre Tann
Andre Tann wrote:
Hallo Liste.
Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. In den Logs erscheint ständig:
...postfix/smtpd[13442]: lost connection after CONNECT from...
Die Folge ist, daß der einliefernde Mailclient (Thunderbird) irgendwann einen Timeout kriegt, und eine Fehlermeldung bringt.
Hi
Hast du mal probiert dich manuell zu verbinden um zu sehen was passiert?
Also einfach
telnet 1.2.3.4 25
wobei 1.2.3.4 die IP des mailhosts ist
Was kommt dann? Kommt er bis zum greeting? Oder kommt gar nichts?
Wenn nichts kommt - oder lange nichts kommt würde ich mal die DNS
Einstellungen checken. Wenn du reverse DNS aktiviert hast kann dies bei
IPs die er nicht auflösen kann durchaus zu verzögerungen führen.
Solltest du das greeting sehen (zB 220 postfix ESMTP)
probier mal manuell ein mail zu verschicken:
HELO abc
MAIL FROM:
Matthias Keller, Montag, 13. März 2006 15:04:
Hast du mal probiert dich manuell zu verbinden um zu sehen was passiert? Also einfach telnet 1.2.3.4 25 wobei 1.2.3.4 die IP des mailhosts ist
Was kommt dann? Kommt er bis zum greeting? Oder kommt gar nichts?
Das geht, ebenso ein echo blabla | mail meine@adresse. Es ist auch nicht so, daß man nie etwas einliefern könnte. Oft funktioniert es ja, aber eben nicht immer.
Wenn nichts kommt - oder lange nichts kommt würde ich mal die DNS Einstellungen checken. Wenn du reverse DNS aktiviert hast kann dies bei IPs die er nicht auflösen kann durchaus zu verzögerungen führen.
DNS funktioniert in alle Richtungen. Und wenn postfix eine Mail annimmt, dann gehts richtig schnell. Wenn es keine Mails annimmt, dann geht überhaupt nichts.
Solltest du das greeting sehen (zB 220 postfix ESMTP) probier mal manuell ein mail zu verschicken: HELO abc MAIL FROM:
RCPT TO: DATA balblablalbla . Wie weit kommst du damit? Schickt er das mail korrekt ab? Wenn ja, ist der Fehler wohl beim Thunderbird zu suchen, ansonsten reporte was der server so antwrotete (wenn überhaupt)
Thunderbird hat gewiß keine Probleme, denn es hat mit dem postfix der SuSE 7.3 bis vor ein paar Tagen einwandfrei funktioniert. Jetzt hab ich ein OS 10.0 draufgezogen, und jetzt gehts plötzlich nicht mehr. Aber ich werde trotzdem mal versuchen, händisch was abzuschicken. Mal sehen, was ich beobachten kann. -- Andre Tann
Andre Tann wrote:
Hallo Liste.
Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. In den Logs erscheint ständig:
...postfix/smtpd[13442]: lost connection after CONNECT from...
Die Folge ist, daß der einliefernde Mailclient (Thunderbird) irgendwann einen Timeout kriegt, und eine Fehlermeldung bringt.
Ich habe schon nach der Fehlermeldung gegoogelt, und Dinge gelesen wie
- RBL (nutze ich nicht) - Kann man nix machen (Postfix-FAQ) - nicht ausreichende Anzahl von Prozessen für smtpd in der master.cf (steht bei mir auf Standard, also 100, sollte reichen). - Problem mit einem zwischengeschalteten Cisco-Router (da ist aber kein Router) - Falsche MTU (ist aber nur Ethernet dazwischen, kein DSL)
Hat jemand hier einen Tip, wo ich noch suchen könnte?
Im Log. Leider hast du deine Fehlermeldung fast gänzlich von nützlichen Hinweisen gesäubert. Eigentlich ist nur übrig geblieben, dass der Timeout von smtpd gemeldet wurde. Zeige mal "postconf -n" und den Auszug aus dem Log mit der Queue-ID dieses "lost connection after CONNECT". Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 13. März 2006 15:06:
Im Log. Leider hast du deine Fehlermeldung fast gänzlich von nützlichen Hinweisen gesäubert. Eigentlich ist nur übrig geblieben, dass der Timeout von smtpd gemeldet wurde.
Ich hab nix gesäubert, da kommt nicht mehr. Postconf ist hier [1]
Zeige mal "postconf -n" und den Auszug aus dem Log mit der Queue-ID dieses "lost connection after CONNECT".
Es gibt keine Queue-ID. Die vollständige, ungekürzte Zeile lautet: Mar 13 15:18:03 mailsrv postfix/smtpd[13969]: lost connection after CONNECT from client70.mydomain.lan[192.168.0.70] Oder auch so: Mar 11 14:03:29 mailsrv postfix/smtpd[7803]: lost connection after CONNECT from localhost[127.0.0.1] Mehr ist da leider nicht zu sehen, sonst hätte ich es schon gepostet. Danke und Gruß. AT [1] mailsrv:~ # postconf -n alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = delay_warning_time = 3h disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all inet_protocols = all mail_name = mydomain mail service mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = mailsrv.mydomain.net masquerade_exceptions = root message_size_limit = 30000000 mydestination = $myhostname, localhost.$mydomain, mydomain.net myhostname = mailsrv.mydomain.net mynetworks = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3 newaliases_path = /usr/bin/newaliases notify_classes = resource, software, bounce, delay, policy, protocol queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relayhost = smtp.1und1.de relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_use_tls = no smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 -- Andre Tann
Andre Tann wrote:
Sandy Drobic, Montag, 13. März 2006 15:06:
Im Log. Leider hast du deine Fehlermeldung fast gänzlich von nützlichen Hinweisen gesäubert. Eigentlich ist nur übrig geblieben, dass der Timeout von smtpd gemeldet wurde.
Ich hab nix gesäubert, da kommt nicht mehr. Postconf ist hier [1]
Huh, irgendwas muss da noch drinstehen. Wieviele smtpd-Prozesse erlaubst du in der master.cf gleichzeitig? Wenn der Timeout regelmäßig kommt, nachdem du eine dicke Mail abgeschickt hast und danach versuchst, eine weitere Mail zu schicken, dann würde ich auf eine sehr geringe Zahl von smtpd-Prozessen tippen. Zeige mail die Zeile von master.cf, die mit "smtp" anfängt.
Mar 13 15:18:03 mailsrv postfix/smtpd[13969]: lost connection after CONNECT from client70.mydomain.lan[192.168.0.70]
Oder auch so:
Mar 11 14:03:29 mailsrv postfix/smtpd[7803]: lost connection after CONNECT from localhost[127.0.0.1]
Das deutet immer mehr auf eine zu geringe Zahl von smtpd-Prozessen hin! Ich glaube, Suse hat als Standard nur 2 eingetragen. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 13. März 2006 15:41:
Huh, irgendwas muss da noch drinstehen. Wieviele smtpd-Prozesse erlaubst du in der master.cf gleichzeitig? Wenn der Timeout regelmäßig kommt, nachdem du eine dicke Mail abgeschickt hast und danach versuchst, eine weitere Mail zu schicken, dann würde ich auf eine sehr geringe Zahl von smtpd-Prozessen tippen. Zeige mail die Zeile von master.cf, die mit "smtp" anfängt.
mailsrv:~ # grep ^smtpd* /etc/postfix/master.cf smtp inet n - n - 2 smtpd -o content_filter=smtp:[127.0.0.1]:10024 smtp unix - - n - - smtp Heißt das, es können nur zwei Leute gleichzeitig Mails einwerfen? Ich hatte schon in dieser Richtung überlegt, aber das dann wieder verworfen, denn ich konnte von drei Terminals aus ein telnet localhost smtp machen. Außerdem denke ich, daß postfix sicher gesprächiger wäre in den Logfiles, wenn es an der zu geringen Zahl der smtpd-Prozesse läge. Schließlich: die 2 hab ich nicht reingeschrieben, das kam so out of the box.
Das deutet immer mehr auf eine zu geringe Zahl von smtpd-Prozessen hin! Ich glaube, Suse hat als Standard nur 2 eingetragen.
Hmja... Also wie gesagt - telnet von drei Terminals aus geht... Gruß. Andy -- Andre Tann
Andre Tann wrote:
Sandy Drobic, Montag, 13. März 2006 15:41:
Huh, irgendwas muss da noch drinstehen. Wieviele smtpd-Prozesse erlaubst du in der master.cf gleichzeitig? Wenn der Timeout regelmäßig kommt, nachdem du eine dicke Mail abgeschickt hast und danach versuchst, eine weitere Mail zu schicken, dann würde ich auf eine sehr geringe Zahl von smtpd-Prozessen tippen. Zeige mail die Zeile von master.cf, die mit "smtp" anfängt.
mailsrv:~ # grep ^smtpd* /etc/postfix/master.cf smtp inet n - n - 2 smtpd -o content_filter=smtp:[127.0.0.1]:10024
Hochsetzen! Nimm mal 20 hier.
smtp unix - - n - - smtp
Heißt das, es können nur zwei Leute gleichzeitig Mails einwerfen? Ich hatte schon in dieser Richtung überlegt, aber das dann wieder verworfen, denn ich konnte von drei Terminals aus ein telnet localhost smtp machen. Außerdem denke ich, daß postfix sicher gesprächiger wäre in den Logfiles, wenn es an der zu geringen Zahl der smtpd-Prozesse läge.
Schließlich: die 2 hab ich nicht reingeschrieben, das kam so out of the box.
Out-of-the-box ist Postfix auch nur als Nullclient rein zum Versenden konfiguriert. Postfix ist normalerweise aber mit 100 gleichzeitigen Prozessen konfiguriert (wenn man Postfix als Server einsetzt).
Das deutet immer mehr auf eine zu geringe Zahl von smtpd-Prozessen hin! Ich glaube, Suse hat als Standard nur 2 eingetragen.
Hmja... Also wie gesagt - telnet von drei Terminals aus geht...
Aus dem Netzwerk? Mache doch einfach mal drei "telnet serverip 25" von deiner Workstation aus. Kommt dann auch noch das dritte Smtpbanner? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 13. März 2006 17:00:
Hochsetzen! Nimm mal 20 hier.
OK, gemacht.
Out-of-the-box ist Postfix auch nur als Nullclient rein zum Versenden konfiguriert. Postfix ist normalerweise aber mit 100 gleichzeitigen Prozessen konfiguriert (wenn man Postfix als Server einsetzt).
Jo, das läuft hier als Server, wenn auch nicht von außen erreichbar. Aber maximal dürften so 20, 30 Leute drauf zugreifen. Natürlich nicht gleichzeitig, aber wer weiß.
Hmja... Also wie gesagt - telnet von drei Terminals aus geht...
Aus dem Netzwerk? Mache doch einfach mal drei "telnet serverip 25" von deiner Workstation aus. Kommt dann auch noch das dritte Smtpbanner?
Jep, da kamen vorhin (=vor derm Umstellung oben) drei banner daher. Aber vielleicht hätte ich versuchen sollen, tatsächlich eine Mail zu verschicken. Egal, jetzt schaue ich, ob das Problem weg ist, und falls nicht, dann melde ich mich wieder hier. Danke für die Hilfe! -- Andre Tann
Andre Tann schrieb:
[...] Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. [...]
Mit Postfix oder einem Programm, das darauf zugreift, stimmt schon seit längerem irgendetwas nicht. Alle paar Wochen, wenn ich die Installations-DVD einlege und den Reparaturmodus laufen lassen muss, wird bei Postfix ein Fehler gemeldet, obwohl ich vorher keinen Hinweis auf Postfix bekommen habe. Nach meiner Erinnerung besteht dieser Zustand schon mindestens seit Version 9.3. Weiß jemand mehr darüber, evtl. auch über Abhilfe? MfG Wolfgang Gruhn
Wolfgang Gruhn wrote:
Andre Tann schrieb:
[...] Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. [...]
Mit Postfix oder einem Programm, das darauf zugreift, stimmt schon seit längerem irgendetwas nicht. Alle paar Wochen, wenn ich die Installations-DVD einlege und den Reparaturmodus laufen lassen muss, wird bei Postfix ein Fehler gemeldet, obwohl ich vorher keinen Hinweis auf Postfix bekommen habe. Nach meiner Erinnerung besteht dieser Zustand schon mindestens seit Version 9.3. Weiß jemand mehr darüber, evtl. auch über Abhilfe?
Welcher Fehler wird gemeldet? Was steht dazu in den Logs? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic schrieb:
Wolfgang Gruhn wrote:
Andre Tann schrieb:
[...] Mir macht neuerdings Postfix in der Version postfix-2.2.5-5 Zicken. [...]
Mit Postfix oder einem Programm, das darauf zugreift, stimmt schon seit längerem irgendetwas nicht. Alle paar Wochen, wenn ich die Installations-DVD einlege und den Reparaturmodus laufen lassen muss, wird bei Postfix ein Fehler gemeldet, obwohl ich vorher keinen Hinweis auf Postfix bekommen habe. Nach meiner Erinnerung besteht dieser Zustand schon mindestens seit Version 9.3. Weiß jemand mehr darüber, evtl. auch über Abhilfe?
Welcher Fehler wird gemeldet? Was steht dazu in den Logs?
Sandy
Die Reparaturprozedur von YaST liefert folgendes Protokoll (beim "Status" gebe ich nur die roten Meldungen wieder): Paketname Dateien Konfigurationsdatei Status ------------------------------------------------------------------------------------------------- postfix /usr/sbin/postdrop Nein ......G. /usr/sbin/postqueue Nein ......G. Nach der Reparatur und Reboot bietet sich dasselbe Bild, d.h. trotz gegenteiliger Behauptung wurde nichts repariert; oder es war nichts kaputt! In jedem Fall stimmt hier etwas nicht an den Meldungen, und dies, obwohl ich keinerlei Update eingespielt habe. Auch SuSE darf man eben nicht alles glauben, was einem so aufgetischt wird. MfG Wolfgang Gruhn
Wolfgang Gruhn wrote:
Mit Postfix oder einem Programm, das darauf zugreift, stimmt schon seit längerem irgendetwas nicht. Alle paar Wochen, wenn ich die Installations-DVD einlege und den Reparaturmodus laufen lassen muss, wird bei Postfix ein Fehler gemeldet, obwohl ich vorher keinen Hinweis auf Postfix bekommen habe. Nach meiner Erinnerung besteht dieser Zustand schon mindestens seit Version 9.3. Weiß jemand mehr darüber, evtl. auch über Abhilfe?
Welcher Fehler wird gemeldet? Was steht dazu in den Logs?
Die Reparaturprozedur von YaST liefert folgendes Protokoll (beim "Status" gebe ich nur die roten Meldungen wieder):
Paketname Dateien Konfigurationsdatei Status -------------------------------------------------------------------------------------------------
postfix /usr/sbin/postdrop Nein ......G.
/usr/sbin/postqueue Nein ......G.
Nach der Reparatur und Reboot bietet sich dasselbe Bild, d.h. trotz gegenteiliger Behauptung wurde nichts repariert; oder es war nichts kaputt! In jedem Fall stimmt hier etwas nicht an den Meldungen, und dies, obwohl ich keinerlei Update eingespielt habe. Auch SuSE darf man eben nicht alles glauben, was einem so aufgetischt wird.
Keine Ahnung, was Yast uns damit sagen will, aber die Dateien gehören zu Postfix. Lasse doch mal "postfix check" laufen, ob der auch was meldet. Vielleicht gibt es ein Problem mit der Gruppenzugehörigkeit/Rechten. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Wolfgang, hallo Leute, Am Montag, 13. März 2006 18:50 schrieb Wolfgang Gruhn: [...]
Die Reparaturprozedur von YaST liefert folgendes Protokoll (beim "Status" gebe ich nur die roten Meldungen wieder): [...] postfix /usr/sbin/postdrop Nein ......G. /usr/sbin/postqueue Nein ......G.
Das sieht nach einem rpm --verify aus. Aus man rpm (Suche nach "--verify test"): S file Size differs M Mode differs (includes permissions and file type) 5 MD5 sum differs D Device major/minor number mis-match L readLink(2) path mis-match U User ownership differs G Group ownership differs T mTime differs Die beiden genannten Dateien gehören also einer anderen Gruppe als im PRM festgelegt.
Nach der Reparatur und Reboot bietet sich dasselbe Bild, d.h. trotz gegenteiliger Behauptung wurde nichts repariert; oder es war nichts kaputt! In jedem Fall stimmt hier etwas nicht an den Meldungen, und dies, obwohl ich keinerlei Update eingespielt habe. Auch SuSE darf man eben nicht alles glauben, was einem so aufgetischt wird.
Ich vermute, dass diese Abweichung von /etc/permissions.* verursacht wird - SuSEconfig setzt anhand dieser Dateien diverse Berechtigungen. Falls es das nicht ist, zeige mal die Ausgabe von ls -l /usr/sbin/postdrop /usr/sbin/postqueue rpm -qlv postfix | grep "postdrop\|postqueue" Gruß Christian Boltz -- "Der wahrscheinlich ärgerlichste Aspekt eines Computerprogrammes ist die Art und Weise, in der es auf Ihre Fehler reagiert" [L. Lamport, LaTeX-Handbuch]
Christian Boltz schrieb:
[...]
zeige mal die Ausgabe von ls -l /usr/sbin/postdrop /usr/sbin/postqueue rpm -qlv postfix | grep "postdrop\|postqueue"
Hallo Christian, xyz@linux:~> ls -l /usr/sbin/postdrop /usr/sbin/postqueue -rwxr-sr-x 1 root maildrop 10592 2005-09-09 20:33 /usr/sbin/postdrop -rwxr-sr-x 1 root maildrop 10692 2005-09-09 20:33 /usr/sbin/postqueue xyz@linux:~> rpm -qlv postfix | grep "postdrop\|postqueue" -rwxr-sr-x 1 root maildrop 10592 Sep 9 2005 /usr/sbin/postdrop -rwxr-sr-x 1 root maildrop 10692 Sep 9 2005 /usr/sbin/postqueue -rw-r--r-- 1 root root 5747 Apr 18 2005 /usr/share/doc/packages/postfix/html/postdrop.1.html -rw-r--r-- 1 root root 8795 Mär 8 2005 /usr/share/doc/packages/postfix/html/postqueue.1.html -rw-r--r-- 1 root root 1606 Sep 9 2005 /usr/share/man/man1/postdrop.1.gz -rw-r--r-- 1 root root 2276 Sep 9 2005 /usr/share/man/man1/postqueue.1.gz xyz@linux:~> Aber warum sollen wir einen Fehler suchen, den offensichtlich SuSE verursacht hat, wenn er den normalen Betrieb nicht weiter stört? MfG Wolfgang Gruhn
participants (5)
-
Andre Tann
-
Christian Boltz
-
Matthias Keller
-
Sandy Drobic
-
Wolfgang Gruhn