Comment supprimer définitivement les e-mails de la file d'attente sendmail et les empêcher de revenir?

18

J'ai un problème assez ennuyeux ici. J'ai testé une application et créé des e-mails de test vers de fausses adresses e-mail (sans oublier que mon serveur n'est pas vraiment configuré pour envoyer des e-mails de toute façon). Bien sûr, sendmailn'est pas en mesure d'envoyer ces messages et ils se sont retrouvés coincés dans la sendmailfile d'attente. Je souhaite supprimer manuellement les messages qui se sont accumulés dans la file d'attente au lieu d'attendre les 5 jours qui sendmailprennent généralement pour arrêter de réessayer.

J'utilise Ubuntu 10.04 et /var/spool/mqueue/c'est le répertoire dans lequel chaque guide que j'ai lu indique que les e-mails mis en file d'attente sont conservés. Lorsque je supprime les fichiers de ce répertoire, sendmailarrête d'essayer de traiter les e-mails jusqu'à ce que ce qui semble être un script cron s'exécute et re-remplit ce répertoire avec les messages que je ne souhaite pas envoyer. Voici quelques lignes de mon 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)

Est-ce que quelqu'un sait comment me débarrasser définitivement de ces messages? En guise de remarque, j'aimerais également savoir s'il existe un moyen de configurer l' sendmailenvoi de "faux" e-mails. Y a-t-il?

Steven Oxley
la source
Eh bien, je n'ai toujours pas trouvé de solution à ce problème. Il semble que ce soit une sorte de script cron qui provoque cela, mais je n'arrive pas à comprendre où il stocke les messages en file d'attente ...
Steven Oxley

Réponses:

28

Les messages qui ont été envoyés ou tentent de l'être sont stockés dans /var/spool/mqueue. Les messages que Sendmail n'a pas encore essayé de mettre en file d'attente peuvent être trouvés dans /var/spool/mqueue-client.

Essayez donc ceci (je suppose que vous voulez vous débarrasser de tous les messages dans la file d'attente):

  • Arrêter sendmail
  • rm /var/spool/mqueue/*
  • Si vous voulez supprimer les messages dans l' attente, rm /var/spool/mqueue-client/*.
  • Lancer sendmail

Cela effacera nos dossiers de file d'attente jusqu'à ce que le système reçoive un autre message. Vous pouvez vérifier mailqdeux fois en exécutant (les deux dossiers de file d'attente) ou sendmail -bp(uniquement le dossier de file d'attente).

REMARQUE: Avec la plupart des distributions Linux, vous pouvez démarrer / arrêter les services avec service sendmail <start|stop|restart>ou /etc/init.d/sendmail <start|stop|restart>. Les deux options ont de nombreux autres indicateurs d'état qui peuvent être observés en tapant la commande et le service sans les indicateurs d'état.

weeheavy
la source
Il a dit qu'il l'avait déjà fait, mais les messages sont réapparus ...
Massimo
1
Mais sans arrêter d'abord sendmail, c'est le point.
weeheavy
Eh bien, il semble que vous ayez peut-être franchi le pas que j'ai raté.
Steven Oxley
Sur Fedora 19, je vois / var / spool / clientmqueue (ainsi que / var / spool / mqueue)
TomG
Pour une raison quelconque, même avec sudo, cela ne fonctionnerait pas pour moi (cela dirait no matches found). J'ai donc chmodédité les dossiers 777et j'ai ensuite pu supprimer le contenu.
Sridhar Sarnobat
9

Vous trouverez souvent la suggestion de supprimer des fichiers du répertoire mqueue de Sendmail avec par exemple rm /var/spool/mqueue/*ou pire ( rm -rfetc.). À mon humble avis, c'est tout simplement dangereux. Cela fonctionnera dans de nombreux cas, mais je recommande de boucler vos ceintures de sécurité. La simple suppression de tous les fichiers de la file d'attente peut supprimer des messages légitimes.

Arrêter Sendmail avant de supprimer les messages en file d'attente est un bon conseil, surtout si de nombreux messages doivent être supprimés. Cependant, si seulement quelques messages doivent être supprimés ou si la file d'attente est régulièrement nettoyée, par exemple au moyen d'une tâche cron, il n'est en fait pas nécessaire d'arrêter Sendmail. Dans le pire des cas, l'un des messages sera remis en file d'attente, ce qui sera presque certainement supprimé lorsque vous réessayez.

Au contraire, arrêter Sendmail (par exemple dans Ubuntu avec service sendmail stop) peut ne pas être suffisant. Même à l'arrêt, certains processus (enfants) peuvent toujours être en cours d'exécution. Il faudrait attendre qu'ils aient fini (recommandé) ou les tuer.

Afin de supprimer en toute sécurité les messages de la file d'attente, vous avez besoin des ID de file d'attente des messages. Les identifiants sont affichés dans le journal après "sm-mta [...]:". Les ID de votre extrait de journal sont o530SlbK009365, o4VHn3cw003597... Pour chacun des ID 2 fichiers sont stockés dans mqueue, en commençant par un « QF », l'autre en commençant par « df ».

mailqest généralement utilisé pour répertorier le contenu de la file d'attente. Il affiche les ID dans la première colonne. De plus, vous devriez consulter mailqla sortie de car elle indique également si un message est actif / en cours de traitement. Par exemple

-----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]>

Dans cet exemple, le message avec ID oBDDuKAB023946est en cours de traitement, indiqué par l'astérisque ajouté. Les autres messages peuvent être supprimés en toute sécurité. Par exemple, pour supprimer le message avec ID, oBAEMuV8000429utilisez

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

Brandon Hutchinson propose une approche plus polyvalente pour supprimer les messages en file d'attente dans Suppression du courrier de la file d'attente . Brandon inclut également des scripts pour supprimer les messages basés sur la partie du domaine, l'adresse e-mail, etc. Les scripts de Brandon sont très utiles pour un nettoyage régulier ou une suppression en masse.

Néanmoins, même les scripts de Brandon ne prennent pas en charge le statut des messages. Cependant, il est facile à ajouter. Inclure au début de ses scripts

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

Ensuite, au début de la sous-routine "voulu", ajoutez une coche pour ignorer les messages actifs, par exemple avec

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

HTH. Et n'oubliez pas de faire des sauvegardes :-)

xebeche
la source
4

J'ai eu ce même problème et j'ai découvert qu'il y avait 2 dossiers avec des messages en file d'attente. Le dossier / var / spool / clientmqueue / contenait des messages qui se terminaient dans / var / spool / mqueue / s'ils n'étaient pas remis. La suppression des fichiers des deux dossiers était nécessaire pour résoudre le problème.

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


la source
0

Je ne pense pas que ce soit le travail d'un script cron, il est plus probable que ce soit un problème d'application, ou quelque chose lié à sendmail lui-même; de toute façon, pour exclure tout travail cron faisant cela, vous pouvez simplement vous arrêter crondun moment et voir si cela continue.

Massimo
la source
0

J'ai réussi à le faire en utilisant ce script bash

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done
Shu Hikari
la source
Donc, vous ouvrez un sous-shell juste pour appeler echoet récupérer la sortie de ladite echopour l'utiliser comme paramètre rm. Même en ignorant les fourchettes gratuites de sudoet rm, cette sous-utilisation est tout simplement un gaspillage.
Felix Frank
Eh bien, si vous avez une solution plus «acceptable», ce ne sera pas une perte de temps d'expliquer votre solution au lieu de simplement montrer à quel point un commentaire peut être inutile. Merci d'avance
Shu Hikari
2
Désolé si cela vous a paru offensant et arrogant. Une approche plus économique serait sudo find /var/spool/mqueue -maxdepth 1 -delete. J'ai trouvé important de souligner ce qui pose problème en particulier avec votre script. Toutes mes excuses pour le manque de tact.
Felix Frank
2
Oui, mais maintenant vous avez expliqué votre point et je l'ai parfaitement compris. Et excuses acceptées, ne vous inquiétez pas. Merci: D
Shu Hikari