Мониторинг почтового сервера

Собственный почтовый сервер — это не всегда ошибка. У кого-то исторически живёт Postfix на VPS, у кого-то почта привязана к старой CRM, у кого-то есть внутренние уведомления, которые проще отправлять через свой MTA. Но если сервер уже работает, его нельзя оставлять в режиме «пока письма ходят, не трогаем». Почта ломается тихо: очередь растёт, диск заполняется, IP попадает в blacklist, сертификат истекает, а бизнес узнаёт об этом по фразе клиента «мы вам писали, ответа не было».

Мониторинг почтового сервера нужен не для красивого графика. Он отвечает на практичные вопросы: письма уходят? входящие принимаются? очередь не застряла? диск не заполнится ночью? домен не попал в блокировки? TLS не сломан? Если своя почта ещё жива, наблюдать нужно именно эти вещи.

Очередь Postfix

Очередь — первый индикатор проблем. В нормальной ситуации письма проходят быстро, а временные отказы постепенно повторяются и доставляются. Если очередь растёт, значит что-то мешает: удалённые сервера отклоняют письма, DNS не отвечает, не хватает места, сломалась авторизация, IP получил плохую репутацию.

Мониторить стоит количество писем в очереди, возраст самых старых сообщений и динамику. Одно отложенное письмо не повод будить администратора. Резкий рост или письма старше разумного порога — повод смотреть логи. Для Zabbix можно использовать готовые шаблоны или простые user parameters вокруг postqueue, но важно не увлечься деталями ради деталей.

Отдельно полезно различать deferred и active. Deferred-письма ждут повторной попытки, active — прямо сейчас обрабатываются. Если deferred растёт часами, бизнесу нужно знать, какие отправки страдают: заявки с сайта, счета, уведомления CRM или внешняя рассылка.

Диск и логи

Почтовый сервер чувствителен к диску. Заполненный раздел может остановить приём писем, сломать очередь и породить цепочку странных ошибок. Следите за свободным местом, inode, размером логов, скоростью роста очереди и каталогов почты, если сервер хранит ящики локально.

Логи нужны не только после аварии. По ним видно частые ошибки доставки, попытки подбора паролей, проблемы с TLS, отказы из-за SPF/DKIM/DMARC, подозрительные всплески отправки. Но лог без ротации и мониторинга сам становится проблемой: может занять весь диск.

Для малого бизнеса часто достаточно нескольких алертов: диск выше порога, очередь растёт, старые письма в очереди, сервис Postfix не отвечает, TLS-сертификат скоро истечёт. Остальное можно смотреть при разборе инцидента.

Blacklists и репутация IP

Если IP почтового сервера попадает в blacklist, часть получателей начнёт отклонять письма или отправлять их в спам. Причины разные: заражённый сайт рассылает мусор, украли SMTP-пароль, сервер стал open relay, соседний адресный блок имеет плохую репутацию, рассылки отправляются слишком агрессивно.

Проверки blacklists стоит делать аккуратно. Не нужно будить всех из-за одного спорного списка, который почти никто не использует. Но попадание в крупные списки или массовые отказы в логах — уже инцидент. Важно смотреть вместе: blacklist, логи отправки, объём исходящих, аутентификацию SMTP, не появилось ли нового источника писем.

Если почта используется для рассылок клуба или интернет-магазина, DNS-аутентификация особенно важна. SPF, DKIM и DMARC помогают получателям доверять письмам, подробнее — в статье SPF DKIM DMARC для рассылок клуба.

TLS, DNS и доступность

Почта зависит от DNS сильнее, чем кажется. MX-записи, A/AAAA, PTR, SPF, DKIM, DMARC — всё это влияет на доставку и репутацию. Мониторинг должен замечать, если MX не резолвится, порт SMTP недоступен снаружи, сертификат истекает или PTR не соответствует ожиданиям.

TLS для входящей и исходящей почты тоже стоит проверять. Истёкший сертификат не всегда полностью остановит доставку, но может ухудшить доверие и создать ошибки у клиентов. Если сервер обслуживает IMAP/SMTP для сотрудников, сертификаты влияют ещё и на почтовые клиенты.

Доступность лучше проверять снаружи, а не только systemctl status postfix на самом сервере. Сервис может быть запущен, но firewall, DNS или провайдер уже мешают реальному соединению.

Безопасность SMTP

Мониторинг должен ловить не только падения, но и странности. Всплеск исходящих писем от одной учётки, много неудачных попыток SMTP-auth, подключения из неожиданных стран, отправка на множество несуществующих адресов — всё это признаки компрометации или ошибки.

Пароли SMTP не должны лежать в открытом виде в скриптах и старых CMS. Если сайт отправляет почту через учётку, проверьте, где хранится пароль и какие права у этой учётки. Тема близка к статье секреты в скриптах и bat-никах: удобство не должно означать открытый пароль на сервере.

Для административного доступа к почтовому серверу используйте SSH/VPN, MFA там, где возможно, и отдельные учётки. Не публикуйте лишние панели управления наружу без защиты.

Когда пора мигрировать

Мониторинг может показать неприятную правду: своя почта требует больше внимания, чем приносит пользы. Если сервер постоянно попадает в блокировки, нет человека на сопровождение, ящики нужны только для обычной переписки, а бизнес критичен к доставляемости, возможно, лучше переехать к управляемому провайдеру. Мы разбирали похожие задачи в материале про миграцию почты в Microsoft 365.

Но миграция не всегда нужна сразу. Иногда достаточно закрыть open relay, настроить SPF/DKIM/DMARC, обновить TLS, добавить мониторинг очереди и диска, убрать старые скрипты рассылки. Решение стоит принимать после аудита, а не из усталости.

Если у вас живёт Postfix и вы не уверены, что он под наблюдением, напишите нам через контакты. Проверим очередь, DNS, blacklists, логи и предложим: оставить с нормальным мониторингом, перенести часть функций или спокойно мигрировать на управляемую почту в рамках администрирования серверов.