Мониторинг почтового сервера — что измеряем?

Почтовый сервер — одна из традиционных заноз в филейной части системного администратора.

Действительно, казалось бы, не было забот — почту приняли, почту отправили. Ан нет! Не проходит и нескольких дней, как приходят спамеры и заставляют вас искать золотую середину между тем, чтобы оградить своих пользователей от бессмысленной корреспонденции, а, с другой стороны, не заблокировать прием почты от некоторых (возможно — очень важных) клиентов.

Но и этого мало! Многие чужие серверы откажутся принимать вашу почту по тысяче причудливых причин. Блэк-листы, грей-листы, коллбэки, фильтрация диалапщиков…

Однако, тема этого поста — не фильтрация спама, а методы печального наблюдения за тем, во что он превращает ваш почтовый сервер. 

Как известно, почтовый сервер в Unix проходит под кодовым названием MTA (Mail Transfer Agent) и занимается исключительно передачей почты и сопутствующими этому процессу задачами. Для новичков будет полезно обратить внимание на то, что обслуживание почтовых ящиков и предоставление почты пользователям в число этих задач не входят.

Работа почтового сервера

Итак, почтовый сервер…

  • принимает письма для доставки куда-нибудь,
  • доставляет письма куда велено,
  • хранит письма с момента успешного приема до момента успешной доставки.

Прием писем (Submission, дословно — «подача»)

Откуда берутся письма?

  • От локального пользователя, отправляющего свою корреспонденцию, т.е., от какого-то другого процесса на этом же сервере;
  • От внутреннего доверенного сервера, для транзитной пересылки наружу;
  • От прочих серверов в мировом пространстве (или от внешнего релея);
  • Генерируются самим почтовым сервером для извещения отправителей об ошибках доставки.

В процессе приема письма может произойти одно из двух событий:

  • либо письмо будет принято в обработку,
  • либо в приеме письма будет отказано.

Отказ в приеме (Reject)

На любом этапе работы SMTP-протокола сервер может принять решение об отказе в приеме письма — если оно не прошло установленных проверок.

Вот некоторые причины отказа:

  • Попытка передать письмо транзитом с одной внешней системы на другую внешнюю (relaying denied);
  • Попытка передать письмо изнутри на внешний сервер, путь к которому невозможно найти (unrouteable address);
  • Попытка передать письмо несуществующему пользователю сервера (user unknown).

Есть и другие причины, в т.ч., используемые в защите от спама. Список отказов не стандартизован — администратор может настраивать логику проверок самостоятельно.

Доставка писем (Delivery)

После того, как письмо было принято почтовым сервером, оно сохраняется в очереди и инициируется его доставка получателю.

Куда доставляются письма?

  • В ящики локальных пользователей;
  • Транзитом на внутренний доверенный сервер — для доставки в почтовые ящики;
  • Во внешнее пространство (возможно — не напрямую, а через внешний релей).

Ошибки доставки (Defer и Failure)

  • Если доставка письма не удалась, то письмо остается в очереди сообщений. Это называется задержка (Defer);
  • Периодически (обычно — раз в несколько часов) сервер будет пытаться повторно отправить сообщения из очереди и, если по истечении времени это не удается — удаляет их из очереди. Отказ доставки, вызвавший удаление письма называется Delivery Failure.

Возвратные письма (Bounce)

В результате Delivery Failure на обратный адрес отправителя генерируется письмо об ошибке (bounce), которое передается на вход почтового сервера (рассмотренный нами ранее процесс Submission).

Кроме писем об отказе доставки генерируются также и сообщения о задержке типа «Письмо бла-бла-бла не может уйти из очереди в течение NN часов…» — это тоже вариант bounce.

Очередь (Message Queue)

Ну и последний, уже упомянутый ранее элемент передачи почты — очередь.

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

К сожалению, и здесь нас поджидает совершенно неожиданная точка отказа — очень часто очередь пухнет, и на больших системах может собирать многие тысячи писем.

Почему это происходит?

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

Второй вариант — письма спамеров, которым все-таки удалось пробиться через наши заслоны, так и не находят не находят адресата. Почтовый сервер будет честно пытаться известить отправителя о невозможности доставки письма — сгенерирует bounce. Но, поскольку отправитель в таких случаях — липовый, то bounce доставлено не будет и тоже осядет в очереди на длительный срок… а поток спама может быть неопределенно велик.

Третий вариант (хотя, может, и не последний) — самый смешной. При ошибках настройки, два сервера могут начать обмениваться bounce’ми и bounce’ми на bounce’ы. Делают они это поразительно быстро.

Мониторинг передачи почты

Теперь, вооружившись Знанием, мы можем набросать общую схему мониторинга почтовой системы.

  • Submit — подача писем для доставки
    • from local — от пользователей и процессов сервера
    • from internal — от внутренних почтовых машин (если есть)
    • from other — от всех остальных
    • from error — bounce-письма
  • Reject — отказ в подаче письма
    • Relaying denied
    • Urouteable Address
    • User unknown
    • сообщения спам-фильтров и прочее
    • other — все прочие сообщения
  • Delivery — доставка
    • to local — в ящики на сервере
    • to internal — на внутренние почтовые машины
    • to other — вовне
  • Delivery Error — ошибка доставки
    • Defer
    • Failure
  • Queue — количество писем в очереди

Чем мониторить почтовый сервер?

На этот счет нет универсального ответа. Хотя бы потому, что почтовые серверы бывают разные.

Для MTA Exim можно использовать следующие инструменты:

Консольная программа eximstat. Параметром ей надо указать журнал работы Exim, например:

eximstat /var/log/exim4/mainlog.

Команда

exim4 -bpc

Выведет количество сообщений в очереди.

Команды less, grep и awk можно применить к журнальным файлам mainlog и rejectlog ;)

Графический мониторинг

Для большинства решений автоматизированного мониторинга, включая Zabbix и Nagios можно легко найти шаблоны для мониторинга параметров вашего почтового сервера. Если в них не окажется чего-то нужного, их всегда можно доработать — на то они и Open Source.

По описанным здесь рекомендациям создан плагин и шаблон для почтового сервера Exim и системы мониторинга Zabbix. Шаблон и плагин доступны в рамках бесплатного интернет-сервиса мониторинга Zabber.ru, построенного на базе Zabbix.

Мониторинг Exim на www.zabber.ru - Hosted Zabbix

Мониторинг Exim на www.zabber.ru - Hosted Zabbix

 

Мониторинг

2 comments


  1. Спасибо за http://www.zabber.ru/ — интересная штука, обязательно попробую.
    Ну и — я тебя читаю постоянно, только не комментирую. Надеюсь, это приятно знать:)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

captcha

Please enter the CAPTCHA text