Exim4 і небажане пересилання пошти: розбір випадку 2013 року

У березні 2013 року провайдер повідомив, що через наш сервер надсилається спам. На ньому працював Exim4, тому я почав із журналу поштових операцій:

tail -f /var/log/exim4/mainlog

За тодішніми спостереженнями, сервер приймав зовнішні спроби пересилання з адресами відправників, для яких у нас не було скриньок. Сама відсутність локальної скриньки ще не встановлює джерело повідомлення чи причину проблеми: потрібно перевіряти журнали приймання, автентифікацію та правила relay.

Щоб припинити потік, я тимчасово закрив поштові порти брандмауером. Такий крок зупиняє й потрібні з'єднання, тому його слід узгоджувати з призначенням сервера.

Черга повідомлень

У первинній нотатці були наведені дві команди очищення:

exipick -zi | xargs exim -Mrm

Перша відбирає заморожені повідомлення.

exipick -i | xargs exim -Mrm

Друга видаляє всі відібрані повідомлення черги, а не лише спам. Статус frozen також сам собою не означає небажану пошту. Перед видаленням перегляньте відбір, збережіть потрібні повідомлення й матеріали для аналізу. За документацією Exim, -Mrm прибирає повідомлення без сповіщення про недоставлення. Параметри відбору пояснює довідка exipick.

Локальний сценарій надсилання

У моєму випадку пошта була потрібна для повідомлень від сайтів на самому сервері. У /etc/exim4/update-exim4.conf.conf тоді були задані:

dc_local_interfaces='127.0.0.1'
dc_readhost='localhost'

Ці параметри виконують різні завдання. dc_local_interfaces визначає адреси, на яких слухає демон; значення 127.0.0.1 обмежує його IPv4 loopback-адресою. dc_readhost стосується переписування адрес у відповідних режимах конфігурації й не є загальною забороною relay. Це пояснює довідка Debian.

Після змін я перезапускав службу:

service exim4 restart

Потім у журналі бачив rejected RCPT ...: relay not permitted. Це підтверджувало відмову в конкретних спробах пересилання. Однак якщо демон справді слухає лише 127.0.0.1, пряме зовнішнє TCP-з'єднання до нього не має доходити. Тому старі рядки журналу не можна автоматично вважати доказом, що саме наведені два параметри усунули всі причини інциденту.

Для чинного сервера перевірте ефективну конфігурацію, адреси прослуховування, правила relay, потрібне надсилання від сайтів і зовнішню відмову. Очищення черги саме по собі не виправляє причину небажаного надсилання.