
представляет собой набор команд, завершающихся байтами CR LF,
передаваемых с помощью набора символов NVT ASCII. Обмен SMTP клиента и
SMTP сервера представляет собой набор некоторых фиксированных команд,
подаваемых клиентом, в ответ на которые сервер отвечает специальными
кодами ответов, снова таки в формате NVT ASCII.
Нам необходимо рассмотреть набор команд протокола SMTP, а так же
набор ответов, которые может послать SMTP сервер в ответ на эти команды.
Начнем с того, что SMTP – протокол, опирающийся на транспортные функции
TCP и за SMTP сервером зарезервирован хорошо известный TCP порт 25. Клиент
устанавливает соединение с сервером с динамического порта на порт 25, после
чего может передавать серверу некоторые команды, которые мы сейчас будем
рассматривать.
Начинаем рассмотрение команд протокола SMTP с команды HELO.
Подчеркиваем, что вообще говоря клиент всегда должен начинать
коммуникации с SMTP сервером с подачи команды HELO, рассматриваем
обобщенный синтаксис команды HELO: HELO FQDN <CR><LF>, где FQDN –
полное доменное имя узла, устанавливающего соединение с сервером. Для чего
это нужно? Изначально протокол SMTP как мы увидим позднее, не
предусматривал возможности авторизации пользователя, отправляющего письмо
через данный сервер (об авторизации, появившейся в качестве расширения
ESMTP мы поговорим позднее).
Поэтому для того, чтобы организовать некую замену авторизации
пользователя, использовалась команда HELO, аргументом которой пользователь
должен указывать совой собственный FQDN, некоторым образом авторизуя себя.
С другой стороны – никто не мешает пользователю ввести в качестве аргумента
команды HELO не свой FQDN узла, а … все, что угодно. Возникает вопрос –
может ли сервер как-то проверить верность введенных данных? В принципе
может! Действительно, сервер узнает от клиента его FQDN, а из заголовка IP
пакета может узнать IP адрес клиента. Соответственно, сервер может провести
обратное DNS разрешение IP адреса клиента в его доменное имя, или наоборот,
произвести разрешение доменного имени в IP адрес и сравнить информацию,
полученную в базе DNS c информацией, которую передал клиент – если
результаты совпадают – можно считать, что клиент «честен» и обслужить его, в
противном случае сервер может и разорвать соединение за попытку «обмана».
Однако такой подход имеет недостатки, фактически не позволяющие его
применять:
• Не каждый узел составной сети обязан иметь FQDN (вспомним, что для
того, чтобы пользоваться DNS, не нужно иметь собственного полного DNS
имени)
• Узлы, находящиеся за NAT маршрутизатором могут сколько угодно
указывать в аргументе команды HELO свое собственное FQDN – в любом
случае SMTP сервер получит пакет от IP адреса интерфейса NAT
маршрутизатора и разрешив его в доменное имя разумеется никогда не
получит тоже, что ввел в аргументе команды HELO пользователь.
Поэтому столь жесткое поведение сервера, разрывающего TCP соединение
с узлом, который ввел в аргументе команды HELO «неправильное» с точки
зрения сервера имя не приветствуется и означает, что сервер не сможет
обслужить многих клиентов.
Сервера могут реагировать на то, что клиент передает в аргументе
команды HELO, и более мягким способом, например: сервер просто пытается
провести обратное разрешение IP адреса клиента в доменное имя, и если это
разрешение удалось (не обязательно совпало с тем, что передал в аргументе
команды HELO клиент), то сервер готов обслужить пользователя (цель такой