представляет   собой   набор   команд,   завершающихся   байтами  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  клиент),   то   сервер   готов   обслужить   пользователя   (цель   такой