У меня тут довольно раздражающая проблема. Я тестировал приложение и создал несколько тестовых писем на фиктивные адреса электронной почты (не говоря уже о том, что мой сервер вообще не настроен на отправку писем). Конечно, не может sendmail
отправить эти сообщения, и они застряли в sendmail
очереди. Я хочу вручную удалить сообщения, которые накапливались в очереди, вместо того, чтобы ждать 5 дней, которые sendmail
обычно требуются для прекращения повторных попыток.
Я использую Ubuntu 10.04, и /var/spool/mqueue/
это каталог, в котором, как я читал во всех how-to, хранятся электронные письма, поставленные в очередь. Когда я удаляю файлы в этом каталоге, sendmail
прекращаются попытки обработки электронных писем, пока не запустится скрипт cron и не заполнит этот каталог сообщениями, которые я не хочу отправлять. Вот несколько строк из моего 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)
Кто-нибудь знает, как мне избавиться от этих сообщений навсегда? Кстати, я бы хотел узнать, есть ли способ настроить sendmail
"поддельную" отправку электронной почты. Есть?
решение1
Сообщения, которые были отправлены или пытаются быть отправлены, хранятся в /var/spool/mqueue
. Сообщения, которые Sendmail еще не пытался поставить в очередь, можно найти в /var/spool/mqueue-client
.
Итак, попробуйте это (я предполагаю, что вы хотите избавиться отвсесообщений в очереди):
- Остановить sendmail
rm /var/spool/mqueue/*
- Если вы хотите удалить ожидающие сообщения,
rm /var/spool/mqueue-client/*
. - Запустить sendmail
Это очистит вашу папку(и) очереди, пока система не получит другое сообщение. Вы можете дважды проверить, запустив mailq
(обе папки очереди) или sendmail -bp
(только папку очереди).
ПРИМЕЧАНИЕ: В большинстве дистрибутивов Linux вы можете запускать/останавливать службы с помощью service sendmail <start|stop|restart>
или /etc/init.d/sendmail <start|stop|restart>
. Оба варианта имеют много других флагов состояния, которые можно наблюдать, введя команду и службу без флагов состояния.
решение2
Вы часто будете встречать предложение удалить файлы из каталога mqueue Sendmail, например, rm /var/spool/mqueue/*
или хуже ( rm -rf
и т. д.). IMHO, это просто опасно. Это сработает во многих случаях, но я рекомендую пристегнуть ремни безопасности. Простое удаление всех файлов из mqueue может удалить легитимные сообщения.
Остановка Sendmail перед удалением сообщений в очереди — хороший совет, особенно если нужно удалить много сообщений. Однако, если нужно удалить только несколько сообщений или если очередь регулярно очищается, например, с помощью задания cron, останавливать Sendmail на самом деле нет необходимости. В худшем случае одно из сообщений будет повторно поставлено в очередь и почти наверняка будет удалено при повторной попытке.
Напротив, остановка Sendmail (например, в Ubuntu с помощью service sendmail stop
) может оказаться недостаточной. Даже при остановке некоторые (дочерние) процессы могут продолжать работать. Придется дождаться их завершения (рекомендуется) или завершить их.
Для безопасного удаления сообщений из mqueue вам понадобятся идентификаторы очереди сообщений. Идентификаторы отображаются в журнале после "sm-mta[...]:". Идентификаторы из вашего отрывка журнала: , o530SlbK009365
, o4VHn3cw003597
... Для каждого идентификатора в mqueue хранятся 2 файла, один из которых начинается с "qf", а другой — с "df".
mailq
обычно используется для перечисления содержимого очереди. Он показывает идентификаторы в первом столбце. Кроме того, вам следует ознакомиться mailq
с выводом , поскольку он также показывает, является ли сообщение активным/обрабатывается в данный момент. Например
-----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]>
В этом примере сообщение с идентификатором oBDDuKAB023946
в данный момент обрабатывается, что показано добавленной звездочкой. Другие сообщения можно безопасно удалить. Например, чтобы удалить сообщение с идентификатором, oBAEMuV8000429
используйте
rm /var/spool/mqueue/{d,q}foBAEMuV8000429
Более универсальный подход к удалению сообщений из очереди представлен Брэндоном Хатчинсоном вУдаление почты из почтовой очереди. Брэндон также включает скрипты для удаления сообщений на основе доменной части, адреса электронной почты и т. д. Скрипты Брэндона очень полезны для регулярной очистки или массового удаления.
Тем не менее, даже скрипты Брэндона не заботятся о статусе сообщений. Однако, это легко добавить. Включать в начало его скриптов
# Get current mailq status
my $mailq = `mailq`;
Затем в начале подпрограммы «хотелось» добавьте проверку, чтобы пропустить активные сообщения, например, с помощью
# skip if file is currently processed by MTA
if ($mailq =~ /\n$queue_id\*/) {
$debug && print "$queue_id is locked.\n";
last;
}
HTH. И не забудьте сделать резервные копии :-)
решение3
У меня была такая же проблема, и я обнаружил, что было 2 папки с сообщениями в очереди. В папке /var/spool/clientmqueue/ были сообщения, которые попадали в /var/spool/mqueue/, если их не удавалось доставить. Для решения проблемы потребовалось удалить файлы из обеих папок.
rm -f /var/spool/clientmqueue/* rm -f /var/spool/mqueue/*
решение4
Мне удалось сделать это с помощью этого bash-скрипта
for i in `sudo ls /var/spool/mqueue`
do
sudo rm -rv `echo /var/spool/mqueue/$i`
done