Wie lösche ich E-Mails in der Sendmail-Warteschlange dauerhaft und verhindere, dass sie zurückkehren?

18

Ich habe hier ein ziemlich nerviges Problem. Ich habe eine Anwendung getestet und einige Test-E-Mails an falsche E-Mail-Adressen gesendet (ganz zu schweigen davon, dass mein Server sowieso nicht zum Senden von E-Mails eingerichtet ist). Natürlich sendmailkönnen diese Nachrichten nicht gesendet werden und sie stecken in der sendmailWarteschlange fest. Ich möchte die Nachrichten, die sich in der Warteschlange sendmailangesammelt haben, manuell löschen, anstatt auf die 5 Tage zu warten, die normalerweise erforderlich sind, um den erneuten Versuch abzubrechen.

Ich benutze Ubuntu 10.04 und /var/spool/mqueue/in diesem Verzeichnis werden nach jeder Anleitung, die ich gelesen habe, die E-Mails gespeichert, die sich in der Warteschlange befinden. Wenn ich die Dateien in diesem Verzeichnis lösche, wird der sendmailVersuch, die E-Mails zu verarbeiten, abgebrochen, bis scheinbar ein Cron-Skript ausgeführt wird, und dieses Verzeichnis mit den Nachrichten aufgefüllt, die nicht gesendet werden sollen. Hier sind einige Zeilen von meinem syslog:

Jun  2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com.
Jun  2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com.
Jun  2 17:39:02 sajo-laptop CRON[9510]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Jun  2 17:39:43 sajo-laptop sm-mta[9372]: o52LHK4s007585: to=, ctladdr= (33/33), delay=03:22:18, xdelay=00:06:28, mailer=esmtp, pri=1470404, relay=c.mx.mail.yahoo.com. [206.190.54.127], dsn=4.0.0, stat=Deferred: Connection timed out with c.mx.mail.yahoo.com.
Jun  2 17:39:50 sajo-laptop sm-mta[9149]: o51I8ieV004377: to=, ctladdr= (33/33), delay=1+06:31:06, xdelay=00:03:57, mailer=esmtp, pri=6601668, relay=alt4.gmail-smtp-in.l.google.com. [74.125.79.114], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Jun  2 17:40:01 sajo-laptop CRON[9523]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)

Weiß jemand, wie ich diese Nachrichten dauerhaft loswerden kann? Als Randnotiz möchte ich auch wissen, ob es eine Möglichkeit gibt, das sendmailVersenden von E-Mails zu "fälschen". Gibt es?

Steven Oxley
quelle
Nun, ich habe immer noch keine Lösung für dieses Problem gefunden. Es sieht definitiv so aus, als wäre es eine Art Cron-Skript, das dazu führt, dass es ausgeführt wird, aber ich kann nicht herausfinden, wo die Nachrichten in der Warteschlange gespeichert werden ...
Steven Oxley

Antworten:

28

Die Nachrichten, die gesendet wurden oder gesendet werden sollen, werden in gespeichert /var/spool/mqueue. Nachrichten, die Sendmail noch nicht in die Warteschlange gestellt hat, finden Sie in /var/spool/mqueue-client.

Probieren Sie es also aus (ich nehme an, Sie möchten alle Nachrichten in der Warteschlange entfernen):

  • Beenden Sie sendmail
  • rm /var/spool/mqueue/*
  • Wenn Sie möchten , Nachrichten entfernen , warten rm /var/spool/mqueue-client/*.
  • Starten Sie sendmail

Dadurch werden Ihre Warteschlangenordner gelöscht, bis das System eine weitere Nachricht empfängt. Sie können dies überprüfen, indem Sie mailq(beide Warteschlangenordner) oder sendmail -bp(nur den Warteschlangenordner) ausführen.

HINWEIS: Bei den meisten Linux-Distributionen können Sie Dienste mit service sendmail <start|stop|restart>oder starten / stoppen /etc/init.d/sendmail <start|stop|restart>. Beide Optionen verfügen über viele andere Statusflags, die durch Eingeben des Befehls und des Dienstes ohne die Statusflags angezeigt werden.

weh
quelle
Er sagte, er habe dies bereits getan, aber die Nachrichten erschienen wieder ...
Massimo
1
Aber ohne sendmail zuerst anzuhalten, ist das der Punkt.
Weeheavy
Nun, es scheint, dass Sie auf den Schritt gestoßen sind, den ich verpasst habe.
Steven Oxley
Auf Fedora 19 sehe ich / var / spool / clientmqueue (sowie / var / spool / mqueue)
TomG
Aus irgendeinem Grund würde dies auch mit sudo nicht für mich funktionieren (es würde sagen no matches found). Also habe ich chmoddie Ordner bearbeitet 777und konnte dann die Inhalte löschen.
Sridhar Sarnobat
9

Sie werden häufig den Vorschlag finden, Dateien aus dem Mqueue-Verzeichnis von Sendmail zu entfernen, zum Beispiel mit rm /var/spool/mqueue/*oder schlechter ( rm -rfusw.). IMHO, das ist eindeutig gefährlich. Es wird in vielen Fällen funktionieren, aber ich empfehle, Ihre Sicherheitsgurte anzulegen. Durch einfaches Entfernen aller Dateien aus mqueue werden möglicherweise legitime Nachrichten gelöscht.

Das Stoppen von Sendmail vor dem Entfernen von Nachrichten in der Warteschlange ist besonders dann empfehlenswert, wenn viele Nachrichten entfernt werden müssen. Wenn jedoch nur wenige Nachrichten entfernt werden sollen oder wenn die Warteschlange regelmäßig bereinigt wird, z. B. durch einen Cron-Job, muss Sendmail eigentlich nicht gestoppt werden. Im schlimmsten Fall wird eine der Nachrichten erneut in die Warteschlange gestellt, die mit ziemlicher Sicherheit entfernt wird, wenn Sie es erneut versuchen.

Im Gegenteil, das Stoppen von Sendmail (zB in Ubuntu mit service sendmail stop) ist möglicherweise nicht ausreichend. Auch im gestoppten Zustand werden möglicherweise noch einige (untergeordnete) Prozesse ausgeführt. Man müsste warten, bis sie fertig sind (empfohlen) oder sie töten.

Um Nachrichten sicher aus der Warteschlange zu entfernen, benötigen Sie die Warteschlangen-IDs der Nachrichten. Die IDs werden im Protokoll nach "sm-mta [...]:" angezeigt. Die IDs aus dem Protokollauszug ist o530SlbK009365, o4VHn3cw003597... Für jede der IDs 2 Dateien in mqueue gespeichert sind, beginnend mit „QF“, dem anderen Ausgang mit „df“.

mailqwird im Allgemeinen verwendet, um den Inhalt der Warteschlange aufzulisten. Es zeigt die IDs in der ersten Spalte. Darüber hinaus sollten Sie mailqdie Ausgabe von konsultieren , da auch angezeigt wird, ob eine Nachricht aktiv ist / gerade verarbeitet wird. Z.B

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------
oBDDuKAB023946*    1058 Mon Dec 13 14:56 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <[email protected]
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <[email protected]>

In diesem Beispiel wird die Nachricht mit der ID oBDDuKAB023946gerade verarbeitet. Dies wird durch das angehängte Sternchen angezeigt. Andere Nachrichten können sicher entfernt werden. Zum Beispiel, um die Nachricht mit ID zu entfernen oBAEMuV8000429Verwendung

rm /var/spool/mqueue/{d,q}foBAEMuV8000429

Eine vielseitigere Methode zum Entfernen von Nachrichten in der Warteschlange bietet Brandon Hutchinson in Löschen von E-Mails aus der E-Mail-Warteschlange . Brandon enthält auch Skripte zum Entfernen von Nachrichten basierend auf dem Domain-Teil, der E-Mail-Adresse usw. Die Skripte von Brandon sind sehr hilfreich für die regelmäßige Bereinigung oder Massenentfernung.

Trotzdem kümmern sich auch Brandons Skripte nicht um den Status der Nachrichten. Es ist jedoch einfach hinzuzufügen. Fügen Sie am Anfang seiner Skripte

# Get current mailq status
my $mailq = `mailq`;

Dann, am Anfang der Subroutine "wollte" man ein Häkchen setzen, um aktive Nachrichten zu überspringen, zB mit

# skip if file is currently processed by MTA
if ($mailq =~ /\n$queue_id\*/) {
   $debug && print "$queue_id is locked.\n";
   last;
}

HTH. Und denk dran, Backups zu machen :-)

Xebeche
quelle
4

Ich hatte das gleiche Problem und stellte fest, dass sich 2 Ordner mit Nachrichten in der Warteschlange befanden. Der Ordner / var / spool / clientmqueue / enthielt Nachrichten, die in / var / spool / mqueue / endeten, wenn sie nicht zugestellt werden konnten. Das Löschen der Dateien aus beiden Ordnern war erforderlich, um das Problem zu beheben.

rm -f / var / spool / clientmqueue / * rm -f / var / spool / mqueue / *


quelle
0

Ich glaube nicht, dass dies die Arbeit eines Cron-Skripts ist, es ist eher ein Anwendungsproblem oder etwas, das mit sendmail selbst zusammenhängt. Um jedenfalls auszuschließen, dass ein Cron-Job dies tut, können Sie einfach crondeine Weile innehalten und nachsehen, ob dies weiterhin geschieht.

Massimo
quelle
0

Ich habe es mit diesem Bash-Skript geschafft

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done
Shu Hikari
quelle
Sie öffnen also eine Subshell, um echodie Ausgabe der Subshell aufzurufen und echoals Parameter abzurufen rm. Sogar das Ignorieren der unbegründeten Gabeln von sudound rm, diese Unterschale ist einfach verschwenderisch.
Felix Frank
Nun, wenn Sie eine "akzeptablere" Lösung haben, wird es keine Zeitverschwendung sein, Ihre Lösung zu erklären, anstatt nur zu zeigen, wie nutzlos ein Kommentar sein kann. Vielen Dank im Voraus
Shu Hikari
2
Tut mir leid, wenn dies beleidigend und arrogant rüberkam. Ein wirtschaftlicherer Ansatz wäre sudo find /var/spool/mqueue -maxdepth 1 -delete. Ich fand es wichtig, darauf hinzuweisen, was besonders an Ihrem Skript problematisch ist. Entschuldigung für den Mangel an Takt.
Felix Frank
2
Ja, aber jetzt hast du deinen Standpunkt erklärt und ich habe ihn vollständig verstanden. Und Entschuldigungen angenommen, keine Sorge. Danke: D
Shu Hikari