Hallo! Ich habe folgendes Problem: vor allem ein Server reagiert bei der Mail-Annahme mit Postfix extrem langsam, obwohl so gut wie nichts los ist. Die Verbindung von außen auf den Server-Port 25 (ist freigeschaltet) wird zwar noch hergestellt (insgesamt 3 Pakete laufen über die Leitung), der Server sendet jedoch nicht einmal einen "Banner" nach außen und reagiert nicht einmal auf "ehlo" oder ähnliches. Ein Verbindungsversuch endet oft mit "read timeout" auf der anderen Seite oder benötigt auch ca. 1 - 3 Minuten, danach geht's dann innerhalb dieser einen Mail normal schnell !!! Zeitweise geht es aber auch wieder schnell (1 - 2 Sekunden). Server: SuSE-Linux 9.0 postfix-2.0.14-41 drac-1.11-363 amavisd-new-20030616p5-23 cyrus-sasl-2.1.15-57 cyrus-imapd-2.1.15-35 perl-spamassassin-2.64-4 spamassassin-2.64-4 DNS-Auflösung erfolgt direkt über den lokalen DNS (127.0.0.1 in /etc/resolv.conf) und erfolgt schnellsten (vorwärts und rückwärts). Die Spam-Kontrolle erfolgt nur mit lokalen Mitteln ($sa_local_tests_only=1;). Die Serverlast (uptime) ist ca. 0.03, also fast gar nichts. Auch der Netzwerk-Verkehr ist sehr gering. Zu viele offene Verbindungen gleichzeitig? Kann eigentlich auch nicht sein, da fast keine Mails übertragen werden. # postconf | grep concurrency default_destination_concurrency_limit = 20 initial_destination_concurrency = 5 local_destination_concurrency_limit = 2 smtp_destination_concurrency_limit=$default_destination_concurrency_limit Hatte jemand von euch auch schon mal so ein Problem? Was war schuld? Was blockiert zeitweise? Habe ich noch Angaben vergessen? Danke im voraus für die Hilfe, Günther
Günther Zinsberger wrote:
Hallo!
Ich habe folgendes Problem: vor allem ein Server reagiert bei der Mail-Annahme mit Postfix extrem langsam, obwohl so gut wie nichts los ist. Die Verbindung von außen auf den Server-Port 25 (ist freigeschaltet) wird zwar noch hergestellt (insgesamt 3 Pakete laufen über die Leitung), der Server sendet jedoch nicht einmal einen "Banner" nach außen und reagiert nicht einmal auf "ehlo" oder ähnliches.
Ein Verbindungsversuch endet oft mit "read timeout" auf der anderen Seite oder benötigt auch ca. 1 - 3 Minuten, danach geht's dann innerhalb dieser einen Mail normal schnell !!! Zeitweise geht es aber auch wieder schnell (1 - 2 Sekunden).
Server: SuSE-Linux 9.0 postfix-2.0.14-41 drac-1.11-363 amavisd-new-20030616p5-23 cyrus-sasl-2.1.15-57 cyrus-imapd-2.1.15-35 perl-spamassassin-2.64-4 spamassassin-2.64-4
DNS-Auflösung erfolgt direkt über den lokalen DNS (127.0.0.1 in /etc/resolv.conf) und erfolgt schnellsten (vorwärts und rückwärts).
Die Spam-Kontrolle erfolgt nur mit lokalen Mitteln ($sa_local_tests_only=1;).
Die Serverlast (uptime) ist ca. 0.03, also fast gar nichts. Auch der Netzwerk-Verkehr ist sehr gering.
Zu viele offene Verbindungen gleichzeitig? Kann eigentlich auch nicht sein, da fast keine Mails übertragen werden. # postconf | grep concurrency default_destination_concurrency_limit = 20 initial_destination_concurrency = 5 local_destination_concurrency_limit = 2 smtp_destination_concurrency_limit=$default_destination_concurrency_limit
Hatte jemand von euch auch schon mal so ein Problem? Was war schuld? Was blockiert zeitweise?
Habe ich noch Angaben vergessen?
Hast du in Postfix eventuell ein paar DNS-Blacklists eingebaut? Wenn ja: auch auf Aktivität prüfen (oder zum Testen abschalten) Hast du in der /var/log/mail mal nach den Gründen für den Reject oder Bounce gesucht? Sind deine smtp_*_restriction richtig gesetzt (richtige Reihenfolge)? Optimal für diese Frage wäre übrigens die postfix-users - Mailingliste auf postfix.org. Paul
Sorry, folgendes Mail ging als PM hinaus: Danke Paul für die schnelle Antwort. Paul Puschmann schrieb:
Hast du in Postfix eventuell ein paar DNS-Blacklists eingebaut? Wenn ja: auch auf Aktivität prüfen (oder zum Testen abschalten)
rbl's ? nein, nichts dergleichen ist vorhanden.
Hast du in der /var/log/mail mal nach den Gründen für den Reject oder Bounce gesucht?
ja, jetzt. gefunden habe ich ein "lost connection after CONNECT" in der selben Sekunde wie das connect: ... Nov 16 10:03:08 inet postfix/smtpd[9277]: connect from xx.xx[x.x.x.x] Nov 16 10:03:08 inet postfix/smtpd[9277]: lost connection after CONNECT from xx.xx[x.x.x.x] ...
Sind deine smtp_*_restriction richtig gesetzt (richtige Reihenfolge)?
smtp_ oder smtpd_ ?? Hier die Einträge: smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_client_restrictions = smtpd_recipient_restrictions = permit_mynetworks, check_client_access btree:/etc/postfix/dracd, reject_unauth_destination Tabelle "access" ist leer Tabelle "dracd" wird dyn. geschrieben MyNetworks ist davon unabhängig (betrifft Mails von intern und extern).
Optimal für diese Frage wäre übrigens die postfix-users - Mailingliste auf postfix.org.
Ich weiß, dass hier die Leute die SuSE-Besonderheiten der jeweiligen Pakete kennen und sonst auch sehr gut bescheid wissen. Darum versuche ich es hier. Ich vermute, dass das "lost connection after CONNECT" am ehesten auf den Fehler hindeutet. Es ist übrigends seit gestern morgen recht oft vorgekommen. Bei anderen Mails geht's wieder sofort und ohne Fehler. Grüße, Günther
Günther Zinsberger wrote:
Sorry, folgendes Mail ging als PM hinaus:
Danke Paul für die schnelle Antwort.
Paul Puschmann schrieb:
Hast du in der /var/log/mail mal nach den Gründen für den Reject oder Bounce gesucht?
ja, jetzt.
gefunden habe ich ein "lost connection after CONNECT" in der selben Sekunde wie das connect: ... Nov 16 10:03:08 inet postfix/smtpd[9277]: connect from xx.xx[x.x.x.x] Nov 16 10:03:08 inet postfix/smtpd[9277]: lost connection after CONNECT from xx.xx[x.x.x.x] ...
Sind deine smtp_*_restriction richtig gesetzt (richtige Reihenfolge)?
smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_client_restrictions = smtpd_recipient_restrictions = permit_mynetworks, check_client_access btree:/etc/postfix/dracd, reject_unauth_destination
Tabelle "access" ist leer Tabelle "dracd" wird dyn. geschrieben MyNetworks ist davon unabhängig (betrifft Mails von intern und extern).
Grüße, Günther
Hi, tritt das denn auch bei 'gewollten' Mails auf? Ansonsten könnte es sich auch einfach um Spammer handeln. Bei mir schauts übrigens so aus: smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc/postfix/disallow_my_domains, check_recipient_access hash:/etc/postfix/recipient_checks, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client cbl.abuseat.org, permit drac kenne ich leider nicht. Paul
Am Dienstag, 16. November 2004 07:22 schrieb Günther Zinsberger:
Hallo!
Ich habe folgendes Problem: vor allem ein Server reagiert bei der Mail-Annahme mit Postfix extrem langsam, obwohl so gut wie nichts los ist. Die Verbindung von außen auf den Server-Port 25 (ist freigeschaltet) wird zwar noch hergestellt (insgesamt 3 Pakete laufen über die Leitung), der Server sendet jedoch nicht einmal einen "Banner" nach außen und reagiert nicht einmal auf "ehlo" oder ähnliches.
Ein Verbindungsversuch endet oft mit "read timeout" auf der anderen Seite oder benötigt auch ca. 1 - 3 Minuten, danach geht's dann innerhalb dieser einen Mail normal schnell !!! Zeitweise geht es aber auch wieder schnell (1 - 2 Sekunden).
Server: SuSE-Linux 9.0 postfix-2.0.14-41 drac-1.11-363 amavisd-new-20030616p5-23 cyrus-sasl-2.1.15-57 cyrus-imapd-2.1.15-35 perl-spamassassin-2.64-4 spamassassin-2.64-4
DNS-Auflösung erfolgt direkt über den lokalen DNS (127.0.0.1 in /etc/resolv.conf) und erfolgt schnellsten (vorwärts und rückwärts).
Die Spam-Kontrolle erfolgt nur mit lokalen Mitteln ($sa_local_tests_only=1;).
Die Serverlast (uptime) ist ca. 0.03, also fast gar nichts. Auch der Netzwerk-Verkehr ist sehr gering.
Zu viele offene Verbindungen gleichzeitig? Kann eigentlich auch nicht sein, da fast keine Mails übertragen werden. # postconf | grep concurrency default_destination_concurrency_limit = 20 initial_destination_concurrency = 5 local_destination_concurrency_limit = 2 smtp_destination_concurrency_limit=$default_destination_concurrency_limit
Hatte jemand von euch auch schon mal so ein Problem? Was war schuld? Was blockiert zeitweise?
Habe ich noch Angaben vergessen?
Überprüf mal den Inhalt der Mailqueue. Ich glaube, das ging mit dem Befehl mailq. Ansonsten sieh mal unter /var/spool/postfix nach, wieviel Dateien da rumgammeln. Bei einem meiner Server war die mal mit hunderttausenden Mails , weil jemand einen Procmailfilter an sich selbst gebaut hatte. Da hat postfix dann auch nicht mehr viel gemacht. Mfg, Thomas
Paul Puschmann schrieb:
tritt das denn auch bei 'gewollten' Mails auf?
ja, hauptsächlich. Auch wenn ich von unserem 2. Mailserver auf diesen ein Mail schicke, passiert es.
Ansonsten könnte es sich auch einfach um Spammer handeln.
Bei mir schauts übrigens so aus: smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc/postfix/disallow_my_domains, check_recipient_access hash:/etc/postfix/recipient_checks, check_helo_access hash:/etc/postfix/helo_checks,
helo-Überprüfungen hatte ich auch mal. Da aber so viele Mail-Server existieren, bei denen das Helo-Statemant nicht paßt (->Ausnahmen), habe ich das aufgegeben.
check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client cbl.abuseat.org, permit
Ich habe somit weniger Einschränkungen als Du. Damit müßte das Empfangen bei mir einfacher funktionieren.
drac kenne ich leider nicht.
drac (= Dynamic Relay Authorization Control, http://mail.cc.umanitoba.ca/drac/index.html ) bewirkt POP3-before-SMTP. Daran kann es eigentlich nicht liegen, da dieser Prozeß nur eine hash-Datei erzeugt, die dann von Postfix verwendet wird. Postfix muß da auf nichts warten. Grüße Günther
Hallo Thomas, Thomas Gräber schrieb:
Überprüf mal den Inhalt der Mailqueue. Ich glaube, das ging mit dem Befehl mailq. Ansonsten sieh mal unter /var/spool/postfix nach, wieviel Dateien da rumgammeln. Bei einem meiner Server war die mal mit hunderttausenden Mails , weil jemand einen Procmailfilter an sich selbst gebaut hatte. Da hat postfix dann auch nicht mehr viel gemacht.
ja, das geht mit "mailq". Im Zielserver befindet sich kein einziges Mail in der Ausgangs-Queue, beim sendenden Mailserver eben die Mails, die dorthin nicht zugestellt werden können. Procmail setzte ich nicht ein, zur Zeit nicht einmal Sieve. Raus geht eigentlich alles sofort (vom Server nach draußen). Auch interne Mail-Clients haben Probleme, das Mail überhaupt dem Mail-Server zu übergeben. Seit Februar funktionierte der Mail-Server eigentlich sehr gut, nur seit etwa 2 - 3 Tagen bereitet er Probleme. Es wurde im letzten Monat _kein_ Online-Update durchgeführt. Grüße, Günther
Günther Zinsberger schrieb:
local_destination_concurrency_limit = 2
war *nicht* schuldig! Sobald per telnet mehr als 2 Verbindungen auf Port 25 gemacht wurden, wurde die dritte und folgende auf "warten" gesetzt, bis eine der beiden vorigen fertig waren, dann ging es auch da weiter. *Schuld war*: in /etc/postfix/master.cf : smtp inet n - n - 2 smtpd ^^^ maxproc war 2. habe es hochgesetzt auf 10 und das sollte vorerst reichen. Danke an alle die mitgeholfen haben. Grüße, Günther
participants (3)
-
Günther Zinsberger -
Paul Puschmann -
Thomas Gräber