Come posso eliminare definitivamente i messaggi di posta elettronica nella coda di sendmail e impedirgli di tornare?


18

Ho un problema piuttosto fastidioso qui. Ho testato un'applicazione e ho creato alcune e-mail di prova per indirizzi di posta elettronica fasulli (per non parlare del fatto che il mio server non è configurato per inviare e-mail comunque). Ovviamente, sendmailnon è in grado di inviare questi messaggi e si sono bloccati in sendmailcoda. Voglio eliminare manualmente i messaggi che si sono accumulati in coda invece di attendere i 5 giorni che di sendmailsolito impiegano per smettere di riprovare.

Sto usando Ubuntu 10.04 ed /var/spool/mqueue/è la directory in cui ogni how-to che ho letto dice che le e-mail che sono in coda vengono conservate. Quando elimino i file in questa directory, sendmailsmette di tentare di elaborare le e-mail finché non viene eseguito quello che sembra essere uno script cron e popola nuovamente questa directory con i messaggi che non desidero inviare. Ecco alcune righe dal mio 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)

Qualcuno sa come posso eliminare definitivamente questi messaggi? Come nota a margine, vorrei anche sapere se esiste un modo per impostare la sendmail"falsa" invio di e-mail. È lì?


Bene, non ho ancora trovato alcuna soluzione a questo problema. Sembra proprio che sia una specie di cron script che lo sta causando, ma non riesco a capire dove stia memorizzando i messaggi in coda ...
Steven Oxley

Risposte:


28

I messaggi che sono stati inviati o che stanno tentando di essere inviati vengono archiviati /var/spool/mqueue. I messaggi che Sendmail non ha ancora tentato di mettere in coda possono essere trovati /var/spool/mqueue-client.

Quindi prova questo (suppongo che tu voglia sbarazzarti di tutti i messaggi in coda):

  • Ferma sendmail
  • rm /var/spool/mqueue/*
  • Se si desidera rimuovere i messaggi in attesa, rm /var/spool/mqueue-client/*.
  • Inizia sendmail

Questo cancellerà le nostre cartelle della coda fino a quando il sistema non riceverà un altro messaggio. È possibile ricontrollare eseguendo mailq(entrambe le cartelle della coda) o sendmail -bp(solo la cartella della coda).

NOTA: con la maggior parte delle distribuzioni Linux è possibile avviare / interrompere i servizi con service sendmail <start|stop|restart>o /etc/init.d/sendmail <start|stop|restart>. Entrambe le opzioni hanno molti altri flag di stato che possono essere osservati digitando il comando e il servizio senza i flag di stato.


Ha detto di averlo già fatto, ma i messaggi sono riapparsi ...
Massimo

1
Ma senza interrompere prima sendmail, questo è il punto.
weeheavy

Bene, sembra che potresti aver colpito il passo che mi mancava.
Steven Oxley,

Su Fedora 19, vedo / var / spool / clientmqueue (così come / var / spool / mqueue)
TomG

Per qualche ragione anche con sudo questo non funzionerebbe per me (direbbe no matches found). Così ho modificato chmodle cartelle 777e sono stato in grado di eliminare il contenuto.
Sridhar Sarnobat,

9

Troverai spesso il suggerimento di rimuovere i file dalla directory mqueue di Sendmail con, per esempio rm /var/spool/mqueue/*o peggio ( rm -rfecc.). IMHO, questo è chiaramente pericoloso. Funzionerà in molti casi ma raccomando di allacciare le cinture di sicurezza. La semplice rimozione di tutti i file da mqueue potrebbe eliminare i messaggi legittimi.

Per interrompere Sendmail prima di rimuovere i messaggi in coda è un buon consiglio soprattutto se è necessario rimuovere molti messaggi. Tuttavia, se devono essere rimossi solo pochi messaggi o se la coda viene ripulita su base regolare, ad esempio mediante un processo cron, in realtà non è necessario interrompere Sendmail. Nel peggiore dei casi, uno dei messaggi verrà nuovamente messo in coda e quasi sicuramente verrà rimosso quando si riprova.

Al contrario, arrestare Sendmail (ad esempio in Ubuntu con service sendmail stop) potrebbe non essere sufficiente. Anche quando interrotto alcuni processi (figlio) potrebbero essere ancora in esecuzione. Si dovrebbe aspettare fino al termine (consigliato) o ucciderli.

Per rimuovere in sicurezza i messaggi da mqueue sono necessari gli ID di coda dei messaggi. Gli ID vengono visualizzati nel registro dopo "sm-mta [...]:". Gli ID del tuo estratto del registro sono o530SlbK009365, o4VHn3cw003597, ... Per ciascuno dei 2 ID file sono memorizzati in mqueue, uno che inizia con "qf", l'altro inizia con "df".

mailqviene generalmente utilizzato per elencare il contenuto della coda. Mostra gli ID nella prima colonna. Inoltre, dovresti consultare mailql'output perché mostra anche se un messaggio è attivo / in fase di elaborazione. Per esempio

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------
oBDDuKAB023946*    1058 Mon Dec 13 14:56 <vfn-l-bounces+so=example.com@fam.tuwi
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <vfn-l-bounces+sby=example.com@fam.tuw
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>

In questo esempio il messaggio con ID oBDDuKAB023946è attualmente in fase di elaborazione, mostrato dall'asterisco aggiunto. Altri messaggi sono sicuri da rimuovere. Ad esempio, per rimuovere il messaggio con l' oBAEMuV8000429uso dell'ID

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

Un approccio più versatile per rimuovere i messaggi in coda è fornito da Brandon Hutchinson nell'eliminazione della posta dalla coda . Brandon include anche script per rimuovere i messaggi in base alla parte del dominio, all'indirizzo di posta elettronica ecc. Gli script di Brandon sono molto utili per la pulizia regolare o la rimozione di massa.

Tuttavia, anche gli script di Brandon non si occupano dello stato dei messaggi. Tuttavia, è facile da aggiungere. Includi all'inizio dei suoi script

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

Quindi, all'inizio della sub routine "ricercato" aggiungi un segno di spunta per saltare i messaggi attivi, ad es. Con

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

HTH. E, ricorda di fare dei backup :-)


4

Ho avuto lo stesso problema e ho scoperto che c'erano 2 cartelle con messaggi in coda. La cartella / var / spool / clientmqueue / aveva messaggi che finivano in / var / spool / mqueue / se non venivano consegnati. L'eliminazione dei file da entrambe le cartelle era necessaria per risolvere il problema.

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


0

Non penso che questo sia il lavoro di uno script cron, è più probabile che sia un problema dell'applicazione o qualcosa legato a sendmail stesso; in ogni caso, per escludere qualsiasi lavoro cron che lo faccia, puoi semplicemente fermarti crondper un po 'e vedere se questo continua a succedere.


0

Sono riuscito a farlo usando questo script bash

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done

Quindi si apre una subshell solo per invocare echoe recuperare l'output di detto echoper l'uso come parametro per rm. Anche ignorando le forchette gratuite di sudoe rm, questa sottoscrizione è chiaramente uno spreco.
Felix Frank,

Bene, se hai una soluzione più "accettabile", non sarà una perdita di tempo spiegare la tua soluzione invece di mostrare quanto un commento possa essere inutile. Grazie in anticipo
Shu Hikari,

2
Scusate se questo è risultato offensivo e arrogante. Un approccio più economico sarebbe sudo find /var/spool/mqueue -maxdepth 1 -delete. Ho trovato importante sottolineare ciò che è problematico con la tua sceneggiatura in particolare. Ci scusiamo per la mancanza di tatto.
Felix Frank,

2
Sì, ma ora hai spiegato il tuo punto e l'ho capito completamente. E le scuse accettate, non ti preoccupare. Grazie: D
Shu Hikari il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.