Versand und Weiterleitung über qmail extrem verzögert

[rbuch]

Hallo,

ich nutze eine Rootserver von Strato (SuSE Linux Prof. 9.3 inkl. ServerAdmin24).

Seit einiger Zeit werden E-mails, die über SA24 eingerichtet wurden, erst mit einer Verzögerung von 12 bis 24 Stunden dem Empfänger zugestellt. Auch versendete E-mails werden erst nach einer sehr langen Zeit dem Empfänger zugestellt. Es macht den Eindruck, als ob die E-mails noch in einer queue stecken. Die phpmail-Funktion zeigt ebenfalls diese Effekte.

Allerdings gibt es einige Domains, von denen der E-mail Versand reibungslos funktioniert.

Ich habe bereits versucht den apache und qmail zu restarten, aber ohne Erfolg.

Hat jemand eine Idee, wie ich das Problem analysieren bzw. lösen kann?

René

 

[wstuermer]

Hi,

das hört sich irgendwie nach nem Greylisting auf dem Zielsystem an.
Näheres sollte dir die Datei /var/log/mail.log verraten können.

-W

 

[rbuch]

Hi wstuermer,

die mail.log habe ich im Verzeichnis nicht gefunden. Eine mail.err habe ich mir angeschaut, aber keinen direkten Zusammenhang mit meinen Testmails gesehen.

Woran kann ich denn erkennen, ob meine E-mail den Server bereits verlassen hat oder vielleicht noch auf dem Server in einer Queue liegt bzw. was sollte ich finden, wenn der Empfänger die mail ablehnt. Welche Logfiles sind sinnvoll auszulesen...

Noch eine Info: Ich habe mal probiert eine E-mail innerhalb des Servers zu verschicken. Das funktioniert ohne Probleme.

Welche

 

[wstuermer]

Hi,

versuch mal vom Server aus eine SMTP-Sitzung über telnet auf den Zielserver abzuwickeln. Das dürfte dir weiteren Aufschluss geben.

Eine typische SMTP-Sitzung - huschi.net

-W

 

[rbuch]

Bis zum HELO localhost funktioniert es. Wenn ich meine E-mail Adresse eingebe, dann gibt mir der Server eine 501 Bad address syntax.

Ich muss doch die E-mail mit der [at]-Zeichenfolge eingeben, oder? Anfangs hatte es mit "MAIL FROM: test[at]xxx.de noch funktioniert, d.h. der Server hat das Kommando akzeptiert.

Ich teste das morgen noch mal ...

 

[rbuch]

Jetzt wollte ich es doch noch mal wissen und habe einen SMTP-Dialog mit meinem Server aufgebaut. Und siehe da, das MAIL FROM: ... wurde akzeptiert.

Was hat das jetzt zu bedeuten?

 

[rbuch]

Wenn ich an huschi.net mein MAIL FROM: schicke, dann erhalte ich weiterhin die Fehlermeldung 501.

Zwischenzeitlich habe ich noch ein bisschen gelesen: Kann es sein, dass mein Server unfreiwillig als mail-relay benutzt wird und die Queue verstopft ist. Leider weiß ich nicht wirklich wo ich schauen soll.

Ich habe versucht qmHandle zu installieren, um mir die Queue anzuschauen:

#fuer die aktuelle Version auf 
# sourceforge.net nachsehen!
cd /usr/local/src
mkdir qmhandle
cd qmhandle
wget http://heanet.dl.sourceforge.net/sourceforge/qmhandle/qmhandle-1.2.0.tar.gz
tar xzf qmhandle-1.2.0.tar.gz
cp qmHandle /var/qmail/bin/.
chmod 700 /var/qmail/bin/qmHandle

Blöderweise kann ich das Programm nicht aufrufen???

Hat jemand noch eine Idee, wie ich mir die Queue anschauen kann.

Gruß René

 

[Huschi]

/var/qmail/bin/qmHandle -h

huschi.

 

[akxak]

Bei Plesk als Admin anmelden:

Linkes Menu:

System - Server

Dann rechtes Fenster:

Services - Mail

Ansicht "Mail Queue"

 

[rbuch]

Mutmaßlicher Übeltäter überführt.

Hallo an alle,

qmHandle hat gezeigt, dass die remote-queue im 40000 mails gefüllt war. Offensichtlich ging es weder vor noch zurück. Nachdem ich die gesamte queue gelöscht habe, funktionierte es wieder

Dafür verantwortlich waren offensichtlich die "catch all"-Einstellungen bei einem Domain-Konto. Hier sollten alle nicht zustellbaren E-mails wieder an den Absender zurückgeschickt werden. Diese Domain erreichen aber täglich einige tausend Spam-E-Mails, die dann dazu geführt haben, dass qmail übervoll zum erliegen kam.

Vielen Dank für alle Tipps ... bis zum nächsten Mal

René

 

[rbuch]

... und da waren sie wieder: meine Probleme ...

Nachdem ich alle meine Email-Konten so eingestellt hatte, dass eingehende und nicht zuordenbare E-mails gelöscht wurde, funktionierte es eine Zeit lang.

Nach dem Fest ist meine qmail remote-Queue schneller gefüllt als abgearbeitet. Ein Blick in die Mail-header zeigt mir, dass offensichtlich die Serveradresse missbraucht wird. Ich befürchte, dass von meinem Server Spams verschickt werden

Einen screenshot von qmHandle findet sich im Anhang.

Ich freue mich auf Tipps, wie herauszubekommen ist, wer meine queue wie zum überlaufen bringt

Gruß Rene

 

[Huschi]

Grundsätzliches: Über meinen Server werden Spam's verschickt!

huschi.

 

[rbuch]

Hi Huschi,

es ist offensichtlich, dass mein Server für den Versand von Spams genutzt wird

Wenn ich mir meine Prozessliste anschaue, dann sehe ich dort eine Reihe von qmail-remote Prozesse, die ebenfalls darauf hindeuten.

Jetzt geht es also darum herauszubekommen, welches Script auf dazu genutzt wird. Dazu habe ich Deinen sendmail-wrapper übernommen und versucht zu testen ... leider funktioniert es nicht.

Bei mir ist /var/lib/sendmail ein link auf /var/qmail/bin/sendmail. Wenn ich sendmail durch den sendmail-wrapper ersetzt habe, und qmail neu starte, dann habe ich Fehlermeldungen erhalten.

Danach habe ich es noch einmal probiert und zumidest der qmail lief wieder und ich sehe auch die vielen qmailr-Prozesse.

Leider sehe ich kein logfile, aus dem ich dann das aufrufende Script erkennen kann. Das sollte doch eigentlich hier zu finden sein: ">>/tmp/mail.send"

Gruß René

 

[Huschi]

sehe ich dort eine Reihe von qmail-remote Prozesse

Wie es im obigen Howto heißt: Qmail stoppen!
Nicht nur weil wir anderen Administratoren unter Deinen Spam-Mails leiden und Dir bestimmt keine Hilfe bieten, wenn Du den Rat nicht annimmst.
Sondern auch, weil es um die Reputation Deines Servers geht. Wer einmal auf Spam-Listen steht kommt nur schwer davon wieder runter...

Bei mir ist /var/lib/sendmail ein link auf /var/qmail/bin/sendmail.

Dann setze den Wrapper auf /var/qmail/bin/sendmail an.

sendmail durch den sendmail-wrapper ersetzt habe, und qmail neu starte, dann habe ich Fehlermeldungen erhalten.

a) Welche Fehlermeldungen?
b) Hat ein Qmail-Neustart (den Du nicht durchführen solltest, s.o.) nichts mit dem Wrapper zu tun.

Das sollte doch eigentlich hier zu finden sein: ">>/tmp/mail.send"

c) ohne ">>"
d) Erst wenn weitere (Spam-)Mails per Script verschickt werden.
Aktuell wird versucht die Mail-Queue abzuarbeiten.

Wirklich ernst gemeinter Tipp:
Halte Dich an das Howto!
- Qmail stoppen
- Mail-Queue leeren

huschi.

 

[rbuch]

Danke für Deine ausführliche Hilfe!

Qmail ist nun gestoppt, d.h. es werden auch keine E-mails aus der queue versendet.

Mit phpinfo() habe ich meinen sendmail_path ermittelt: "/usr/sbin/sendmail -t -i". Das ist allerdings nur ein Link auf /var/qmail/bin/sendmail. Das "sendmail" habe ich nach Anleitung durch den sendmail-wrapper ersetzt (In /var/qmail/bin/sendmail). Im shell-script habe ich dann noch den Pfad für den "sendmail-real" angepasst auf /var/qmail/bin/sendmail-real

Getestet habe ich mit Förderverein der Schweizerhof-Grundschule Berlin-Zehlendorf. Dort erhalte ich nach dem Absenden Fehlermeldungen, die auch zu erwarten sind, da qmail nicht läuft.

Nur leider wird weder ein logfile angelegt noch geschrieben

Habe ich noch etwas vergessen oder übersehen? Grundsätzlich sollten jetzt doch alle Versuche, mit sendmail etwas zu verschicken im /tmp/mail.send gelogt werden.

Gruß Rene

 

[rbuch]

...und es funktioniert doch!

...war wohl zu ungeduldig.

Nach einigem warten wurde das logfile geschrieben. Der sendmail-wrapper wird immer von einer Stelle aufgerufen.

Kann ich eigentlich auch erkennen, welches script die mails verschickt? Es gibt ein Script, was dort nicht hingehört . Allerdings möchte ich es hier lieber nicht veröffentlichen. Ich schicke es Dir mal per PN. Wäre nett, wenn Du Dir es kurz mal anschaust.

Reicht es erst einmal aus, wenn ich das Script entferne und dann die qmail leere und neu starte?

 

[Huschi]

Ja, das Script ist das böse Element...
Löschen ist ja schon mal gut, aber wie kam es rein?

Durchsuche alle access_log's nach dem Aufruf dieser Datei. (Wahrscheinlich zum Zeitpunkt des Scriptes.)
Und dann durchsuche die Teile davor nach seltsamen Einträgen um die Lücke zu finden.

Oder einfacher:
Bringe Dein Joomla auf den aktuellen Stand.

huschi.

 

[rbuch]

Ja, das Script ist das böse Element...
Löschen ist ja schon mal gut, aber wie kam es rein?
huschi.

Vermutlich über Joomla. register_globals war für diesen einen account auf on, weil eine Komponente ansonsten nicht funktioniert hätte. Allerdings habe ich schon vor einiger Zeit (ca. im Oktober) register_globals auf "on" gestellt. Vermutlich ist das Script schon eine ganze Weile auf dem Server.

Oder einfacher:
Bringe Dein Joomla auf den aktuellen Stand.
huschi.

Joomla ist aktuell. Allerdings sind oftmals die Komponenten von Drittanbietern die Lücke.


Das Script habe ich entfernt. In der Nacht habe ich den wrapper weiter laufen lassen. Nur durch einen Cronjob wurde die Sendmail aufgerufen.

Heute morgen habe ich die sendmail wieder eingespielt und den Server rebootet.

Leider hat das Enfernen des Scripts keinen Erfolg gezeigt: Die queue hat sich wieder gefüllt und die qmailr-Prozesse wurden wieder gestartet

Ich bin echt ratlos? Kann es sein, dass in den betroffenen Verzeichnis des angelegten virtuellen host noch weitere Scripts abgelegt sind. Hilft es, wenn ich diesen einzelnen account platt mache?

 

[Huschi]

Heute morgen habe ich die sendmail wieder eingespielt und den Server rebootet.

Warum???
Was hindert Dich daran den Wrapper weiter drin zu lassen?

Kann es sein, dass in den betroffenen Verzeichnis des angelegten virtuellen host noch weitere Scripts abgelegt sind.

Die Wahrscheinlichkeit ist groß.
Einfach mal alle Dateien durchsuchen.

huschi.

 

[rbuch]

Warum???
Was hindert Dich daran den Wrapper weiter drin zu lassen?

War ich vielleicht zu naiv? Ich dachte, dass mit der Entfernung des Scripts auch mein Problem enfernt wurde.
Wie gesagt, gestern Abend habe ich das besagte Script enfernt und damit über den Wrapper keine neuen Einträge im Logfile gesehen. Ergo bin ich davon ausgegangen, dass das Spammerproblem nicht mehr auftaucht.

Noch eine Frage zwischendurch: Kann es auch sein, dass über eine Joomla-Installation auch Scripte in root-Bereiche eingespielt wurden?

Ich hoffe immer noch, dass ich den Server mit normalen email-Versand auch wieder an das Netz bekomme. Wenn es sein muss, dann entferne ich den kompletten betroffenen account in der Hoffnung, dass ich zum Normalbetrieb zurückfinde.

Erst einmal installiere ich noch einmal den wrapper. Vielleicht gibt er mir ja weiteren Aufschluß.

Gruß Rene