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

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

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

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

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

Как известно, почтовый сервер в 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.