Анализ работы почтового сервера SMTP.

Зависимость пользователей от скорости, с которой приходят и отправляются письма, уже давно стала навязчивой, и в случае сбоев счет идет буквально на минуты. Ведь для них операция отправить или получить письмо – это только перемещающиеся конвертики в почтовом клиенте. Если важное письмо адресату не пришло через несколько секунд после того, как его отправили, это не обязательно сбой в работе почтовой системы, а может быть, просто особенность взаимодействия почтовых серверов между собой. Чтобы быстро провести диагностику проблем с доставкой сообщений, необходимо понимать, что за информация записывается в журналах и как правильно ее интерпретировать.

Все описываемые в статье операции производятся на Windows Server 2008R2 c установленным SMTP-сервером на базе IIS. Для журналов коннекторов Exchange или почтовых серверов на базе Linux коды откликов серверов и формат будут аналогичными.

Причинами задержки или недоставки электронной почты могут выступать:

> Неправильное написание пользовательской части адреса получателя, он может быть даже уволен, и его учетная запись была заблокирована. Как правило, почтовый сервер сообщает об этом.
> Просроченная оплата домена, повлекшая аннулирование всех записей про домен получателя. Под эту категорию попадают неправильные или еще «не распространившиеся» настройки DNS.
> Неправильная настройка серверов или другие причины, делающие невозможным корректно провести SMTP-сессию.

Эти часто встречающиеся проблемы мы и разберем ниже.

А есть ли адресат?

Некорректно записанный «на слух» адрес электронной почты – популярная проблема недоставки сообщений. Мы все знаем, что почтовый адрес состоит из двух частей, разделенных между собой знаком «коммерческое at (commercial at)», в простонародии «собачкой», – имен пользователя и домена.

Поэтому задача проверки правильности адреса электронной почты делится на две части: проверка домена и проверка имени пользователя. Все проверки необходимо осуществлять на почтовом сервере, т.к. имена DNS-серверов рабочей станции администратора и почтового сервера могут различаться.

Проверка домена, в свою очередь, делится на «существует ли такой домен» и «работает ли хоть один из почтовых серверов», прописанных в MX-записи.

Чтобы проверить, существует ли MX-запись для домена и правильно она разрешается в IP-адрес на почтовом сервере, можно воспользоваться командлетом PowerSрell – Resolve-DnsName или командой nslookup с ключом type. На рис 1. видно, как для домена mail.ru возвращаются IP адреса серверов.

Следующим этапом требуется проверить, что серверы доступны для приема сообщений.

В консоли почтового сервера вводим команду:

Если произойдет подключение, и вы получите приветствие вроде:

это значит, почтовый сервер работает и готов принимать команды.

Сторонники Powershell могут воспользоваться командлетом:

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

Что творится внутри сессии?

Давайте разберемся, как же письмо передается от клиента на сервер или между серверами по протоколу SMTP и какие оставляет следы.

Каждый системный администратор знает, что SMTP сессия стандартное подключение клиента (MUA) на 25-й порт к серверу (MTA+MSA), в RFC их называют отправитель (sender) и получатель (receiver). Для демонстрации такой сессии можно использовать telnet и отправить небольшое пробное письмо.

В командной строке выполните команду:

Получив приглашение сервера, начните аккуратно вводить команды, завершая каждую нажатием на клавишу <Enter> (указав свои адреса).

Для завершения письма необходимо набрать точку на пустой строке, чтобы сервер понял, что письмо закончилось, и его требуется обработать. Должно появиться сообщение (см. рис. 2):

Message accepted for delivery

Протокол SMTP использует модель «команда – отклик». Каждая правильно введенная вами команда должна завершаться ответом сервера «250». Чуть ниже подробно описываются коды ответов сервера на вводимые клиентом команды. В процессе ввода команд нельзя допускать опечатки, и кнопка <Backspace> или <Delete> в Telnet не работает. В случае опечатки при вводе ввода сервер возвратит ошибку:

и строку придется начинать набирать сначала.
Хотелось обратить внимание на последовательные три строки после команды DATA. В этом примере я их добавил сознательно.
Почти все письма, которые мы получаем, содержат дополнительные поля, как:
> «Тема» (Subject),
> «Копия» (Сс),
> «Скрытая копия» (Bcc),
> «Ответить» (Reply-To)
> и другие.

Но в стандартных командах они не передаются. Формат данных полей описывается в другом RFC – 5322 [2]. Они составляют с точки зрения передаваемой информации заголовки письма, которые будут приоритетно отображаться в почтовом клиенте при просмотре сообщения.

Справочная информация по SMTP

Действующее RFC No 321 [1] – Simple Mail Transfer Protocol от октября 2008 года.

Основные команды, передаваемые клиентом серверу:
> HELO – представьтесь, указывается имя хоста отправителя, будет зафиксирована в журнале как имя отправителя;
> EHLO – представьтесь, указывается имя хоста отправителя и просьба серверу работать с клиентом в режиме расширенных SMTP-команд;
> MAIL FROM: – указывается отправитель;
> RCPT TO: – указывается получатель;
> SIZE – размер сообщения в байтах;
> DATA – серверу указывается, что передается тело письма (в первых трех строках должны быть адрес получателя, адрес отправителя и тема письма);
> RSET – прервать выполнение текущего процесса с удалением всех сохраненных данных;
> QUIT – завершение сессии;
> HELP – запрос у сервера полезной помощи по командам;
> VRFY – проверить адрес;
> EXPN – просит сервер подтвердить, что переданный аргумент это список почтовой группы;
> VERB – подробно.

Если читать RFC No5321, то в ряде примеров встречается, что первой строкой после команды DATA вводится параметр даты и времени сообщения по часам на клиенте.


В описанной выше telnet-сессии по отправке себя, себя в получателях (поле «Кому» в outlook) я не увижу, там будет стоять director, да еще из другого домена, совершенно нам не знакомого, another-example.com.

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

Сервер SMTP ведет журнал в формате W3C (World Wide Web Consortium) (описание формата доступно по ссылке [3], так же как и другие службы IIS. По умолчанию журнал располагается по адресу C:\Windows\System32\LogFiles\ SMTPSVC1.

В журнале SMTP-сервера среди записей о других письмах сможете найти похожие на эти строки.

Как можно увидеть, журнал последовательно фиксирует команды, которые вводились во время telnet-сессии. Место, где записаны коды откликов сервера на введенные команды, выделены жирным. Код «250» обозначает, что все прошло хорошо, и введенная команда корректно обработана сервером.

В этот же журнал также записываются сообщения, не только принимаемые сервером, но и им же отправляемые. Такие сессии отличаются наличием слова «OutboundConnectionResponse»:

Для детального анализа для исходящих подключений команды SMTP-сервера и сервера получателя записываются на разных строках, т.к. важными являются все детали.

Коды откликов сервера

Коды ответов SMTP состоят из трех цифр, при этом каждая цифра (первая, вторая и третья) имеет собственное значение. Первая цифра определяет статус ответа, при этом может принимать только четыре значения, четко зафиксированных в RFC 5321 (Раздел 4.2).

> 2XX – позитивный отклик о завершении, свидетельствует о том, что команда принята и обработана сервером корректно. Подтверждение корректности ввода «250» в примере выше как раз из этой группы.

> 3XX – позитивный промежуточный отклик, например, сервер просит начать ввод данных (код 354) или передать другую команду, содержащую необходимые данные.

> 4XX – негативный отклик о временных проблемах, свидетельствует о том, что команда не была принята сервером и запрошенная в ней операция не выполнена. Клиенту необходимо, получив такой отклик сервера, вернуться к началу последовательности команд или попробовать ввести команду заново.

> 5XX – негативный отклик о постоянной проблеме, связанной с вводом и обработкой команды клиента. Клиенту SMTP не следует просто повторять команду, поскольку она заведомо не будет выполнена. Например, код «550», когда на сервере нет пользователя, которому планируется отправка сообщения. Различие между временными (коды 4XX) и постоянными проблемами (коды 5XX) сводится к тому, что отклики о временных проблемах обычно возвращаются в тех случаях, когда возможен положительный результат при повторе без изменения формы команды и свойств отправителя или получателя (т.е. команда просто может быть повторена без изменений).

Вторая цифра отклика показывает категорию ошибки:
> X0X – отклик сообщает о наличии синтаксической ошибки (сама команда корректна, но она относится к нереализованным командам или излишняя).
> X1X – отклик на запрос информации (например, справка или состояние).
> X2X – данные отклики относятся к каналу передачи данных внутри сессии.
> X3X и X4X – для этих двух кодов описания пока не заданы.
> X5X – отклики, возвращающие состояние принимающей почтовой системы по отношению к запрошенной команде.

Вместе с кодами сервер, как правило, возвращает строку текста, которая помогает человеку анализировать происходящее. Часто эта текстовая строка передается программным обеспечением сервера SMTP и отображается как часть ответа сервера. Со всеми возможными вариантами ошибок можно ознакомиться в таблице 1.

Сводные данные таблицы 2 могут оказаться полезными для быстрого просмотра ожидаемых откликов принимающего почтового сервера при попытках отправки почты.

Проверка учетной записи

Мне показалась интересной команда, позволяющая проверить, существует ли запрашиваемый пользователь на почтовом сервере. В этом поможет команда VRFY, переданная почтовому серверу. Но есть важный момент.

Разрешенная на почтовом сервере команда VRFY может использоваться хакером для получения списка логинов, чтобы потом провести брут-форс атаку на пользовательские учетные данные.

Поэтому, если в ответ получите ошибку:

это означает, что выполнение команды отключено администратором. Корректные варианты ответов сервера на VRFY приведены на рис. 3.

Если сервер не готов принимать почту для этого адреса, вы получите ошибку 550 или 252, если адрес пользователя для данного сервера корректный.

Анализ журналов нагруженных почтовых систем – достаточно трудоемкая операция, но это верный способ получить четкую картину происходящего с письмом, когда оно должно прийти или быть отправленным. Но у нас для вас хорошая новость. Любой пакет нашего сервиса включает бесплатное системное администрирование и мы с радостью решим все пролемы за вас.

Для автоматизации и ускорения процесса анализа можно рекомендовать использовать дополнительные утилиты, например, универсальный анализатор Microsoft LogParser.

[1] RFC 5321 – https://tools.ietf.org/html/rfc5321.
[2] RFC 5322 – https://tools.ietf.org/html/rfc4021.
[3] Описание формата журнала SMTP cервера – https://msdn.microsoft.com/ru-ru/library/cc780772(v=ws.10).aspx.
[4] Страница Log Parser – https://technet.microsoft.com/ru-ru/scriptcenter/dd919274.aspx?f=255&MSPPError=-2147217396.

Рейтинг материала
[Голосов: 2 Рейтинг: 5]
26 января 2017, 05:48

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

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