¿Cómo elimino permanentemente los mensajes de correo electrónico en la cola de sendmail y evito que vuelvan?

18

Tengo un problema bastante molesto aquí. He estado probando una aplicación y he creado algunos correos electrónicos de prueba a direcciones de correo electrónico falsas (sin mencionar que mi servidor no está realmente configurado para enviar correos electrónicos de todos modos). Por supuesto, sendmailno puede enviar estos mensajes y se han quedado atascados en la sendmailcola. Quiero eliminar manualmente los mensajes que se han estado acumulando en la cola en lugar de esperar los 5 días que sendmailgeneralmente tardan en dejar de volver a intentarlo.

Estoy usando Ubuntu 10.04 y /var/spool/mqueue/es el directorio en el que todos los procedimientos que he leído dicen que se guardan los correos electrónicos que están en cola. Cuando elimino los archivos en este directorio, sendmaildeja de intentar procesar los correos electrónicos hasta que se ejecuta lo que parece ser un script cron y vuelve a llenar este directorio con los mensajes que no quiero enviar. Aquí hay algunas líneas de mi 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)

¿Alguien sabe cómo puedo deshacerme de estos mensajes de forma permanente? Como nota al margen, también me gustaría saber si hay una manera de configurar el sendmailenvío de correo electrónico "falso". ¿Esta ahí?

Steven Oxley
fuente
Bueno, todavía no he encontrado ninguna solución a este problema. Definitivamente parece que es algún tipo de script cron que está causando que suceda, pero no puedo averiguar dónde está almacenando los mensajes en cola ...
Steven Oxley

Respuestas:

28

Los mensajes que se han enviado o que se están intentando enviar se almacenan en /var/spool/mqueue. Los mensajes que Sendmail no ha intentado poner en cola todavía se pueden encontrar /var/spool/mqueue-client.

Así que intente esto (supongo que desea deshacerse de todos los mensajes en la cola):

  • Deja de enviar correo
  • rm /var/spool/mqueue/*
  • Si desea eliminar los mensajes en espera, rm /var/spool/mqueue-client/*.
  • Inicie sendmail

Esto borrará nuestras carpetas de cola hasta que el sistema reciba otro mensaje. Puede verificar dos veces ejecutando mailq(ambas carpetas de cola) o sendmail -bp(solo la carpeta de cola).

NOTA: Con la mayoría de las distribuciones de Linux, puede iniciar / detener servicios con service sendmail <start|stop|restart>o /etc/init.d/sendmail <start|stop|restart>. Ambas opciones tienen muchos otros indicadores de estado que se pueden observar escribiendo el comando y el servicio sin los indicadores de estado.

weeheavy
fuente
Dijo que ya había hecho esto, pero los mensajes reaparecieron ...
Massimo
1
Pero sin detener primero sendmail, ese es el punto.
weeheavy
Bueno, parece que puede haber dado en el paso que me perdí.
Steven Oxley
En Fedora 19, veo / var / spool / clientmqueue (así como / var / spool / mqueue)
TomG
Por alguna razón, incluso con sudo, esto no funcionaría para mí (diría no matches found). Así que chmodedité las carpetas 777y luego pude eliminar el contenido.
Sridhar Sarnobat
9

A menudo encontrará la sugerencia de eliminar archivos del directorio mqueue de Sendmail con, por ejemplo, rm /var/spool/mqueue/*o peor ( rm -rfetc.). En mi humilde opinión, esto es simplemente peligroso. Funcionará en muchos casos, pero recomiendo abrocharse los cinturones de seguridad. Simplemente eliminar todos los archivos de mqueue podría eliminar mensajes legítimos.

Para detener Sendmail antes de eliminar los mensajes en cola es un buen consejo, especialmente si es necesario eliminar muchos mensajes. Sin embargo, si solo se van a eliminar unos pocos mensajes o si la cola se limpia regularmente, por ejemplo, mediante un trabajo cron, en realidad no hay necesidad de detener Sendmail. En el peor de los casos, uno de los mensajes se volverá a poner en cola, lo que casi seguro se eliminará cuando lo intente nuevamente.

Por el contrario, detener Sendmail (por ejemplo, en Ubuntu con service sendmail stop) podría no ser suficiente. Incluso cuando se detiene, algunos procesos (secundarios) podrían estar ejecutándose. Uno tendría que esperar hasta que terminaran (recomendado) o matarlos.

Para eliminar mensajes de mqueue de forma segura, necesita los ID de la cola de mensajes. Las ID se muestran en el registro después de "sm-mta [...]:". Los ID de su extracto de registro son o530SlbK009365, o4VHn3cw003597... Para cada uno de los ID, 2 archivos se almacenan en mqueue, uno que comienza con "qf" y el otro que comienza con "df".

mailqgeneralmente se usa para enumerar el contenido de la cola. Muestra las ID en la primera columna. Además, debe consultar mailqla salida porque también muestra si un mensaje está activo / en proceso. P.ej

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

En este ejemplo, el mensaje con ID oBDDuKAB023946se está procesando actualmente, mostrado por el asterisco adjunto. Es seguro eliminar otros mensajes. Por ejemplo, para eliminar el mensaje con ID oBAEMuV8000429use

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

Brandon Hutchinson proporciona un enfoque más versátil para eliminar los mensajes en cola en Eliminar correo de la cola de correo . Brandon también incluye scripts para eliminar mensajes basados ​​en la parte del dominio, dirección de correo electrónico, etc. Los scripts de Brandon son muy útiles para la limpieza regular o la eliminación masiva.

Sin embargo, incluso los scripts de Brandon no se ocupan del estado de los mensajes. Sin embargo, es fácil de agregar. Incluir al comienzo de sus guiones

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

Luego, al comienzo de la subrutina "quería", agregue una marca para omitir los mensajes activos, por ejemplo, con

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

HTH. Y recuerde hacer copias de seguridad :-)

xebeche
fuente
4

Tuve este mismo problema y descubrí que había 2 carpetas con mensajes en cola. La carpeta / var / spool / clientmqueue / tenía mensajes que terminaban en / var / spool / mqueue / si no se podían entregar. Fue necesario eliminar los archivos de ambas carpetas para resolver el problema.

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


fuente
0

No creo que este sea el trabajo de un script cron, es más probable que sea un problema de aplicación o algo relacionado con sendmail; de todos modos, para descartar cualquier trabajo cron que haga esto, puede detenerse crondpor un momento y ver si esto sigue sucediendo.

Massimo
fuente
0

Logré hacer esto usando este script bash

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done
Shu Hikari
fuente
Entonces, abre una subshell solo para invocar echoy recuperar la salida de dicho echopara su uso como parámetro rm. Incluso ignorando los tenedores gratuitos de sudoy rm, esta subcartela es simplemente un desperdicio.
Felix Frank
Bueno, si tiene una solución más 'aceptable', no será una pérdida de tiempo explicar su solución en lugar de mostrar cuán inútil puede ser un comentario. Gracias de antemano
Shu Hikari
2
Lo siento si esto resultó ofensivo y arrogante. Sería un enfoque más económico sudo find /var/spool/mqueue -maxdepth 1 -delete. Me pareció importante señalar qué es problemático con su script en particular. Disculpas por la falta de tacto.
Felix Frank
2
Sí, pero ahora explicaste tu punto y lo entendí completamente. Y disculpas aceptadas, no te preocupes. Gracias: D
Shu Hikari