Як я назавжди видаляю повідомлення електронної пошти у черзі sendmail і не дозволяю їм повертатися?

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

Я використовую Ubuntu 10.04 і /var/spool/mqueue/це каталог, в якому кожен прочитаний інструкцією говорить, що електронні листи, що стоять у черзі, зберігаються. Коли я видаляю файли в цьому каталозі, sendmailперестає намагатися обробляти електронні листи до тих пір, поки те, що, як видається, є запущеним сценарієм, не повторно заповнює цей каталог повідомленнями, які я не хочу надсилати. Ось кілька рядків з мого 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"фальшиву" надсилання електронної пошти. Є там?

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

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

Щоб зупинити Sendmail перед видаленням чергових повідомлень, є корисною порадою, особливо якщо потрібно видалити багато повідомлень. Однак, якщо потрібно видалити лише декілька повідомлень або якщо регулярно очищати чергу, наприклад, за допомогою роботи з крон, насправді немає потреби зупиняти 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`;

Потім на початку підпрограми "хотів" додати чек, щоб пропустити активні повідомлення, наприклад, з

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

HTH. І, не забудьте зробити резервні копії :-)

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

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

Я не думаю, що це робота сценарію cron, скоріше, це проблема програми або щось, що стосується самої sendmail; у будь-якому випадку, щоб виключити будь-яку роботу з хроном, ви можете просто зупинитися crondна деякий час і побачити, чи це все відбувається.

Мені вдалося це зробити, використовуючи цей скрипт bash

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