Как я могу навсегда удалить сообщения электронной почты в очереди sendmail и предотвратить их возвращение?

18

У меня здесь довольно неприятная проблема. Я тестировал приложение и создал несколько тестовых сообщений на поддельные адреса электронной почты (не говоря уже о том, что мой сервер не настроен на отправку электронной почты в любом случае). Конечно, sendmailне удается отправить эти сообщения, и они застряли в sendmailочереди. Я хочу вручную удалить сообщения, которые накапливаются в очереди, вместо того, чтобы ждать 5 дней, которые sendmailобычно требуются для прекращения повторных попыток.

Я использую Ubuntu 10.04 и /var/spool/mqueue/это каталог, в котором все инструкции, которые я прочитал, говорят, что электронные письма, находящиеся в очереди, хранятся. Когда я удаляю файлы в этом каталоге, 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«фальшивую» отправку электронной почты. Есть?

Стивен Оксли
источник
Ну, я до сих пор не нашел решения этой проблемы. Это определенно выглядит так, как будто это какой-то скрипт cron, который вызывает это, но я не могу понять, где он хранит помещенные в очередь сообщения ...
Стивен Оксли,

Ответы:

28

Сообщения, которые были отправлены или пытаются быть отправлены, хранятся в /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>. Обе опции имеют много других флагов состояния, которые можно наблюдать, набрав команду и службу без флагов состояния.

weeheavy
источник
Он сказал, что уже сделал это, но сообщения снова появились ...
Массимо
1
Но не останавливая sendmail в первую очередь, в этом все дело.
10:30
Что ж, похоже, вы, возможно, наткнулись на шаг, который я пропустил.
Стивен Оксли
На Fedora 19 я вижу / var / spool / clientmqueue (а также / var / spool / mqueue)
TomG
По какой-то причине даже с sudo это не сработало бы для меня (это было бы сказано no matches found). Поэтому я chmodотредактировал папки 777и смог удалить их содержимое.
Шридхар Сарнобат
9

Вы часто найдете предложение удалить файлы из каталога mqueue Sendmail, например rm /var/spool/mqueue/*или хуже ( rm -rfи т. Д.). ИМХО, это довольно опасно. Во многих случаях это будет работать, но я рекомендую пристегнуть ремни безопасности. Простое удаление всех файлов из mqueue может привести к удалению законных сообщений.

Остановка Sendmail перед удалением сообщений в очереди - хороший совет, особенно если необходимо удалить много сообщений. Однако, если нужно удалить только несколько сообщений или если очередь очищается на регулярной основе, например, с помощью задания cron, фактически нет необходимости останавливать Sendmail. В худшем случае одно из сообщений будет помещено в очередь, которое почти наверняка будет удалено при повторной попытке.

Напротив, остановка Sendmail (например, в Ubuntu с помощью service sendmail stop) может быть недостаточной. Даже когда остановлено, некоторые (дочерние) процессы могут все еще работать. Нужно подождать, пока они закончат (рекомендуется) или убить их.

Для безопасного удаления сообщений из mqueue вам нужны идентификаторы очереди сообщений. Идентификаторы отображаются в журнале после "sm-mta [...]:". Идентификаторы из журнала выписки являются o530SlbK009365, o4VHn3cw003597... Для каждого из идентификаторов 2 файлов , хранящихся в mqueue, один , начиная с «QF», а другой , начиная с «ДФ».

mailqобычно используется для отображения содержимого очереди. Показывает идентификаторы в первом столбце. Кроме того, вам следует ознакомиться mailqс выходными данными, поскольку они также показывают, является ли сообщение активным / обрабатываемым в данный момент. Например

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

В этом примере в oBDDuKAB023946настоящее время обрабатывается сообщение с идентификатором , которое отображается с добавленной звездочкой. Другие сообщения безопасны для удаления. Например, для удаления сообщения с идентификатором oBAEMuV8000429используйте

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

Более универсальный подход к удалению сообщений из очереди предоставлен Брэндоном Хатчинсоном в статье «Удаление почты из почтовой очереди» . Брэндон также включает в себя сценарии для удаления сообщений на основе доменной части, адреса электронной почты и т. Д. Сценарии Брэндона очень полезны для регулярной очистки или массового удаления.

Тем не менее, даже сценарии Брэндона не заботятся о статусе сообщений. Тем не менее, это легко добавить. Включить в начале своих сценариев

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

Затем в начале подпрограммы «wanted» добавьте проверку, чтобы пропустить активные сообщения, например, с помощью

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

НТН. И не забудьте сделать резервные копии :-)

xebeche
источник
4

У меня была такая же проблема, и я обнаружил, что есть 2 папки с сообщениями в очереди. Папка / var / spool / clientmqueue / содержала сообщения, которые заканчивались в / var / spool / mqueue /, если их не удалось доставить. Удаление файлов из обеих папок было необходимо для решения проблемы.

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


источник
0

Я не думаю, что это работа скрипта cron, это скорее проблема приложения или что-то, связанное с самой sendmail; в любом случае, чтобы исключить любую работу cron, вы можете просто остановиться crondи посмотреть, происходит ли это.

Massimo
источник
0

Мне удалось сделать это с помощью этого сценария Bash

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done
Шу Хикари
источник
Таким образом, вы открываете подоболочку только для того, чтобы вызывать echoи извлекать вывод сказанного echoдля использования в качестве параметра rm. Даже игнорируя безвозмездные вилки sudoи rm, этот подобстрел просто расточительный.
Феликс Франк
Что ж, если у вас есть более «приемлемое» решение, объяснение вашего решения не будет пустой тратой времени, вместо того, чтобы просто показать, насколько бесполезным может быть комментарий. Заранее спасибо
Шу Хикари
2
Извините, если это натолкнулось на оскорбление и заносчивость. Более экономичный подход был бы sudo find /var/spool/mqueue -maxdepth 1 -delete. Я считаю важным указать, что является проблематичным с вашим сценарием, в частности. Извиняюсь за отсутствие такта.
Феликс Франк
2
Да, но теперь вы объяснили свою точку зрения, и я полностью ее понял. И извинения приняты, не волнуйтесь. Спасибо: D
Шу Хикари