Server sendet und empfängt teilweise keine Mails mehr

[andreask2]

Hallo!

Ich habe ein seltsames Problem mit qmail. Komischerweise können plötzlich viele User keine E-Mails mehr versenden. Aber bei manchen funktioniert es noch und ich habe keine Ahnung wo sich die Clients hier unterscheiden. Hat nichts mit SSL zu tun.

Komisch ist, wenn ich auf der Kommandozeile einfach mal per telnet port 25 auf dem Server aufrufe, wird die Verbindung zwar hergestellt, aber der Server antwortet aber nichts. Eigentlich müsste da ja sowas wie 220 ... kommen, und auch wenn ich HELO example.com oder sowas absende, passiert einfach nichts.

Der Server empfängt auch keine Mails mehr.

Habt Ihr ne Idee woran das liegen könnte? Sehr seltsam. Lokale mails werden zugestellt, zumindest bei den Leuten die auch versenden können. Was könnte man überprüfen?

Grüße
Andreas

[Roger Wilco]

Übliche erste Frage: Was sagen deine Logs?

[andreask2]

Mal ein Auszug aus /var/log/mail.warn

Code: Select all

Dec 11 12:59:12 muenchen02 pop3d: 
Dec 11 12:59:58 muenchen02 pop3d: 
Dec 11 13:01:12 muenchen02 last message repeated 5 times
Dec 11 13:02:12 muenchen02 pop3d: 
Dec 11 13:03:12 muenchen02 pop3d: 
Dec 11 13:04:12 muenchen02 pop3d: 
Dec 11 13:05:12 muenchen02 last message repeated 2 times
Dec 11 13:05:49 muenchen02 imapd-ssl: 1260533149.94387 DISCONNECTED, user=test, ip=[x.x.x.x], headers=219, body=7285, rcvd=892, sent=24356, maildir=/var/www/qmail_gg/test/Maildir
Dec 11 13:06:12 muenchen02 pop3d: 
Dec 11 13:07:12 muenchen02 pop3d: 
Dec 11 13:08:12 muenchen02 pop3d: 
Dec 11 13:09:12 muenchen02 pop3d: 
Dec 11 13:10:00 muenchen02 imapd-ssl: 1260533400.750163 DISCONNECTED, user=test, ip=[x.x.x.x], headers=0, body=0, rcvd=36, sent=236, maildir=/var/www/qmail_gg/test/Maildir
Dec 11 13:10:12 muenchen02 pop3d: 
Dec 11 13:10:12 muenchen02 pop3d: 
Dec 11 13:10:28 muenchen02 relaylock: /var/qmail/bin/relaylock: mail from x.x.x.x:20815 (not defined)
Dec 11 13:10:28 muenchen02 smtp_auth: SMTP connect from unknown@ [x.x.x.x]
Dec 11 13:10:28 muenchen02 smtp_auth: smtp_auth: SMTP user test@example.com : /var/qmail/mailnames/example.com/test logged in from unknown@ [x.x.x.x]
Dec 11 13:10:58 muenchen02 relaylock: /var/qmail/bin/relaylock: mail from x.x.x.x:20825 (not defined)

[Roger Wilco]

Ich erkenne keine Fehlermeldungen in dem Log. Du könntest über deine Mail Logs (Level INFO, WARN, ERR usw.) nach "qmail" und "smtp" bzw. "SMTP" greppen. Vielleicht zeigt sich dann eine brauchbare Meldung.

Wie genau äußert sich das "nicht verschicken können" auf Seiten des Clients? Generiert der SMTP-Server gleich eine Fehlermeldung oder nimmt er die E-Mails noch an und generiert später eine DSN bzw. macht gar nichts?

[andreask2]

Entweder klappt der Mailversand, oder die Verbindung kommt erst gar nicht zu Stande. Die Rechner befinden sich im gleichen Netzwerk. Bis zu einem bestimmten Zeitpunkt, wo der Server neu gestartet wurde, lief alles ohne Probleme, da sind die Logs voll von Erfolgsmeldungen von allen möglichen Domains. Seit dem Neustart, der vom Provider durchgeführt wurde, enthalten die Logs nur noch Einträge zu einer einzigen Domain, und auch da nur von einem Teil der Accounts. Imap funktioniert noch weitgehend, aber SMTP halt bei den meisten nicht mehr. Kommt mir irgendwie so ähnlich wie ein Verbindungs-Limit vor, wie wir das schonmal bei courrier hatten. Das seltsame ist, dass der Server bei einer Anfrage die Verbindung mit Port 25 zwar zulässt, dann aber nichts mehr passiert, egal was man macht, ob man wartet, ob man ein HELO sendet, ganze egal, nach ein paar Sekunden wird die TCP-Verbindung beendet. Und die Zeit bis zur Beendigung kommt mir auch sehr kurz vor, evtl. ist das auch das Problem. Auf dem Server läuft halt noch inetd. Wenn der Versand klappt, dauert das immer so 30 Sekunden, das war schon immer so. Was könnte daran Schuld sein, dass die Verbindung in vielen Fällen so schnell wieder gekappt wird?

[andreask2]

Problem gelöst, war ein etwas verworrenes Problem im Zusammenspiel mit Plesk, inetd und qmail, ich hasse es :) Danke auf jeden Fall!

[Roger Wilco]

Und jetzt noch die Problemlösung (bzw. die tatsächliche Ursache) hier posten. Dann freut sich auch das nächste Plesk-Opfer. ;)