Exim runbook: очередь, логи, отклонения и защита от спама

Ниже — рабочий runbook по Exim для админов: как быстро понять, что происходит с почтой на сервере, почему растёт exim queue, откуда берутся exim deferred и exim rejected, где смотреть mainlog и rejectlog, и как аккуратно влиять на доставку, не устроив сам себе само-DDoS повторными попытками.

Примеры рассчитаны на типичную установку Exim на Debian/Ubuntu/CentOS-подобных системах. Пути логов и сервисов могут отличаться, но логика диагностики одинаковая.

1) Быстрый триаж: что сломалось прямо сейчас

Цель первых 5–10 минут — ответить на три вопроса:

• Очередь растёт из-за внешних проблем (DNS/сеть/получатели) или из-за нашей нагрузки/конфигурации?
• Это задержки (deferred) или жёсткие отказы (rejected)?
• Проблема входящая (нас атакуют/льют спам) или исходящая (мы не можем доставить/нас блокируют)?

Проверка состояния сервиса и ресурсов

systemctl status exim4
systemctl is-active exim4
journalctl -u exim4 --no-pager -n 200

uptime
free -m
df -h
df -i

Критично: нехватка места на диске или inode — частая причина лавинообразного exim deferred. Если раздел с очередью/логами заполнен, Exim начнёт вести себя «странно», а вы будете лечить не то.

Сводка по очереди (exim queue)

exim -bp | head
exim -bpc

exim -bpc даёт размер очереди числом — удобно для мониторинга. exim -bp показывает список писем, но на большой очереди вывод может быть тяжёлым.

Разделяем deferred и rejected

Rejected — сообщение не принято на SMTP-этапе (в rejectlog и/или в mainlog с отказом). Deferred — принято, но доставка откладывается (обычно в очереди; причины — временные ошибки сети/получателя, greylisting, DNS, лимиты, TLS-ошибки и т.д.).

Важно: «очередь растёт» почти всегда про deferred, а «письма не принимаются» — про rejected. Путают часто, а действия разные.

2) Где искать причины: mainlog и rejectlog

У Exim ключевые журналы обычно лежат в /var/log/exim4/ (Debian/Ubuntu) или /var/log/exim/ (часто на RPM-системах). Названия могут быть mainlog, rejectlog, paniclog.

Быстрые выборки по логам

ls -lah /var/log/exim4
tail -n 200 /var/log/exim4/mainlog
tail -n 200 /var/log/exim4/rejectlog

Ищем закономерности: один домен-получатель, один IP-отправитель, массовые AUTH-логины, одна и та же ошибка TLS или DNS.

Поиск deferred в mainlog

grep -i "defer" /var/log/exim4/mainlog | tail -n 50

Типовые причины exim deferred, которые вы увидите в mainlog:

• временная ошибка DNS (SERVFAIL, timeout);
• greylisting на стороне получателя;
• 421/451 «try again later» от удалённого MX;
• лимиты (concurrency, rate limit) — удалённая сторона режет поток;
• TLS-проблемы при исходящей доставке (не совпадают имена, устаревшие протоколы, ошибки цепочки).

Поиск rejected в rejectlog

tail -n 200 /var/log/exim4/rejectlog
grep -i "rejected" /var/log/exim4/rejectlog | tail -n 50

Типовые причины exim rejected:

• RBL/DNSBL (отказ по спискам);
• HELO/EHLO невалиден;
• нет/неверный SMTP AUTH при попытке релея;
• политики антиспама/antivirus/SpamAssassin;
• жёсткие правила ACL (например, блок по гео/IP/подсетям).

Сопоставление события по queue id

Exim оперирует своим внутренним ID письма (queue id). В логах он встречается в начале строки. Если у вас есть ID из очереди — можно быстро собрать «историю».

exim -bp | head -n 20
grep -F "1rXAbC-0002Qw-9n" /var/log/exim4/mainlog | tail -n 50

3) Работа с очередью: просмотр, заморозка, повтор, удаление

В runbook важно не только «найти причину», но и безопасно управлять очередью, чтобы не усугубить ситуацию.

Посмотреть, что доминирует в очереди

exim -bp | awk '{print $4}' | grep -E '@' | awk -F@ '{print $2}' | sort | uniq -c | sort -nr | head

Команда грубая (формат exim -bp зависит от версии и настроек), но часто даёт быстрый ответ: «всё упёрлось в один домен или провайдера».

Показать заголовки и тело конкретного письма

exim -Mvh 1rXAbC-0002Qw-9n
exim -Mvb 1rXAbC-0002Qw-9n

Это помогает понять: кто отправитель, какой маршрут, не подменён ли Return-Path, нет ли очевидного спама, что пишут заголовки про TLS/AUTH.

Принудительно запустить обработку очереди

exim -qf
exim -qff

-qf форсирует один проход очереди, -qff — агрессивнее. На перегруженном сервере лучше начинать с более мягкого варианта и следить за нагрузкой.

Заморозка и разморозка сообщений

exim -Mf 1rXAbC-0002Qw-9n
exim -Mt 1rXAbC-0002Qw-9n

Заморозка полезна, если вы нашли «ядро проблемы» (например, тысячи писем на домен, который временно не принимает), и хотите остановить ретраи, пока чините.

Удаление сообщений (осторожно)

exim -Mrm 1rXAbC-0002Qw-9n

Для массовых удалений обычно используют связки с фильтрацией по отправителю/получателю. Практика для продакшена: заранее закрепите политику — кто принимает решение, где фиксируем причину удаления и как уведомляем пользователя или клиента.

Перед массовыми действиями сделайте «срез» очереди в файл (хотя бы вывод exim -bp) — это помогает потом разбирать спорные кейсы и восстанавливать картину инцидента.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

4) Exim deferred: типовые сценарии и что делать

Сценарий A: проблемы DNS (временные ошибки резолвинга)

В логах будут намёки на timeout или SERVFAIL при lookup MX/A. Действия:

• проверить локальный резолвер и доступность рекурсивных DNS;
• убедиться, что UDP/53 не режется и нет аномальных потерь;
• оценить, не раздувает ли шквал очереди количество DNS-запросов.

getent hosts example.com
getent hosts mx1.example.com

Сценарий B: 421/451 от удалённого MX, greylisting

Это классический exim deferred: удалённый сервер просит повторить позже. В норме Exim сам будет повторять доставку. Ваша задача — убедиться, что ретраи разумные и не забивают систему, а также что вы не выглядите как спамер (PTR/HELO/SPF/DKIM/DMARC).

Если deferred растёт лавинообразно, временно снижайте давление: уменьшайте параллелизм исходящих доставок и не запускайте агрессивный прогон очереди «по кругу».

Сценарий C: TLS-проблемы при доставке на конкретные домены

Exim может откладывать доставку при невозможности согласовать шифрование или при строгой проверке сертификатов (если вы включали такие политики).

Что проверить:

• версию OpenSSL на сервере и поддерживаемые протоколы;
• нужен ли SNI и корректное имя хоста;
• не сломалась ли цепочка сертификатов у удалённой стороны;
• не включили ли вы слишком жёсткую валидацию для всех доменов разом.

Для диагностики удобно протестировать SMTP STARTTLS на удалённом MX:

openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com

Смотрите на ошибки верификации, протокол, цепочку и имена в сертификате.

Если вы принимаете почту на своём сервере, проверьте и «входной» TLS: корректность цепочки и имён в сертификате. В отдельных случаях проще и быстрее выпустить/заменить сертификат на нормальный коммерческий: на практике это снижает число проблемных клиентов и «странных» отказов. По необходимости можно подобрать SSL-сертификаты под ваш домен и почтовые сервисы.

Сценарий D: локальная перегрузка и рост очереди

Если CPU, диск или IO в потолке, то даже нормальные доставки превращаются в deferred. Типовые причины:

• массовая рассылка с сайта или скрипта;
• всплеск входящих SMTP-сессий (боты, спам, подбор паролей);
• дорогая антиспам-проверка на каждое письмо (например, тяжёлый SpamAssassin без лимитов);
• забитый диск или медленное хранилище очереди.

На этом этапе полезно ответить «кто генерирует исходящую почту»: локальные пользователи, веб-приложения, SMTP AUTH клиенты. Это видно в mainlog по признакам аутентификации и по используемым transport’ам.

Если почта и сайт живут на одной машине и нагрузка растёт непредсказуемо, часто помогает вынести почтовую роль на отдельный VDS с понятными лимитами CPU/IO и отдельными очередями/логами. Так проще и расследовать, и ограничивать «виновника» без влияния на весь стек.

5) Exim rejected: причины отказа и точечные правки

RBL/DNSBL: когда блокируете вы и когда блокируют вас

Есть два разных мира:

• вы отклоняете входящую почту по RBL (это будет exim rejected в вашем rejectlog);
• вас блокируют (тогда исходящие будут получать отказы при SMTP-диалоге на доставке).

В первом случае проверьте корректность DNS-резолвинга RBL, избегайте «агрессивных» списков без понимания последствий и добавляйте исключения для доверенных источников только по утверждённой политике.

AUTH: ошибки SMTP аутентификации

В логах ищите неудачные попытки входа, всплески по одному IP, попытки релея без авторизации.

grep -i "auth" /var/log/exim4/mainlog | tail -n 100
grep -i "authentication" /var/log/exim4/mainlog | tail -n 100

Практические меры:

• ограничить попытки AUTH (ACL, rate limit, fail2ban);
• обязать TLS на submission-портах (587/465) для клиентов;
• проверить, что парольные базы не доступны извне и не используются слабые пароли;
• если видите успешные AUTH от незнакомых IP — это уже инцидент (компрометация учётки или приложения).

SpamAssassin: почему письма режутся или «тормозят»

SpamAssassin может быть:

• фильтром на входящем потоке (тогда рост нагрузки приводит к задержкам и deferred);
• инструментом для выставления score и дальнейшего решения (маркировать, карантин, reject).

Если письма отклоняются, проверьте признаки срабатываний и пороги. Если письма задерживаются — проверьте, не упирается ли SA в CPU/RAM, нет ли очереди на content-scanning, не зависают ли DNS-запросы (SA активно использует DNS).

6) Чек-лист по безопасности: когда очередь растёт из-за спама или компрометации

Exim часто становится «симптомом»: очередь распухает, потому что кто-то начал массово отправлять. Минимальный чек-лист:

1. Определить источник исходящей отправки: локальные скрипты, системные пользователи, SMTP AUTH клиенты.
2. Найти «топ» отправителей и получателей по логам за короткий интервал.
3. Проверить всплеск успешных AUTH и необычные IP.
4. Отключить или ограничить проблемный источник (временно), затем устранять причину.
5. Проверить веб-приложения (CMS/плагины) на почтовые инъекции и утечки ключей.

Примитивная выборка по входящим сообщениям (используйте как отправную точку — формат логов может отличаться):

grep -E "<=\s" /var/log/exim4/mainlog | tail -n 200

И по отказам на входе:

tail -n 200 /var/log/exim4/rejectlog

7) Практика эксплуатации: что полезно иметь заранее

Runbook работает лучше, если базовые вещи подготовлены до инцидента:

• Мониторинг: размер очереди (exim -bpc), скорость роста, заполнение диска, нагрузка, количество SMTP-сессий.
• Ротация логов и контроль места, иначе поиск причин превратится в «лог не пишется».
• Понятные политики: когда мы делаем reject, когда defer, когда принимаем и фильтруем.
• Документированные исключения: доверенные IP/сети, whitelist доменов (если допустимо), кто согласует изменения.
• Тестовый контур или окна изменений для правок антиспама и TLS-политик.

8) Мини-алгоритмы: «если видишь X — делай Y»

Очередь растёт, а в mainlog много defer на один домен

1. Убедиться, что это временные 4xx и проблема на стороне получателя.
2. Снизить давление: заморозить часть писем на домен (если политика позволяет) или уменьшить параллелизм доставок.
3. Не форсировать exim -qff бесконечно: вы только усилите ретраи.

Много rejected по RBL, но жалуются «не принимаете важные письма»

1. Понять, по какому именно RBL идёт отклонение, и насколько он «жёсткий».
2. Проверить стабильность DNS-запросов к RBL (timeouts часто выглядят как «поломалось всё»).
3. Добавлять точечные исключения (IP или диапазон) только после проверки и согласования.

Всплеск AUTH и рост исходящей очереди

1. Срочно ограничить источник (IP, учётку), чтобы остановить рассылку.
2. Сменить пароли или отозвать доступы, проверить компрометацию приложений.
3. Проверить репутацию IP и наличие блокировок у крупных получателей по логам исходящей доставки.

9) Полезные команды в одном месте

exim -bpc
exim -bp
exim -Mvh QUEUE_ID
exim -Mvb QUEUE_ID
exim -qf
exim -qff
exim -Mf QUEUE_ID
exim -Mt QUEUE_ID
exim -Mrm QUEUE_ID

tail -n 200 /var/log/exim4/mainlog
tail -n 200 /var/log/exim4/rejectlog
grep -i "defer" /var/log/exim4/mainlog | tail -n 50
grep -i "auth" /var/log/exim4/mainlog | tail -n 100

openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com

Заключение

Хороший runbook по Exim держится на трёх опорах: очередь (exim queue), логи (mainlog/rejectlog) и политики (что мы отклоняем, что откладываем, что фильтруем). Если вы дисциплинированно разделяете exim deferred и exim rejected, быстро находите паттерн в логах и аккуратно управляете ретраями — большинство инцидентов закрываются без паники и без потери почты.

Если хотите углубиться в доменные нюансы почты (IDN, Punycode, и как это влияет на SMTP/сертификаты), держите полезный материал: IDN и Punycode в почте и SSL.