домена  company.com,   очевидно   зарегистрированный   в   системе  DNS,   таким 
образом,   действительно   имеет   место   некоторая   аналогия   с   работой  NAT 
маршрутизатора.   Очевидно,   ОТВЕТЫ   на   такие   письма   не   смогут   быть 
доставлены,   так   как   по   сути   соответствующего   почтового   ящика 
user@company.com  может   и   не   существовать,   хотя   на   самом   деле,   если 
почтовый ящик, соответствующий имени user@company.com существует, почта в 
него, очевидно, может быть доставлена. Мы помним, что NAT маршрутизатор не 
только обеспечивает передачу пакетов с автономными адресами отправителей в 
Интернет, но так же и обеспечивает возврат пакетов-ответов тем, кто должен их 
получить, в данном случае ничего подобного не происходит – ответы придут в 
соответствии   с   заголовками   письма.   Вспомним,   что   маршрутизатор, 
перенаправляющий пакеты в Интернет, но не возвращающий ответные пакеты 
обратно   НЕ   представляет   никакой   ценности,   так   как   в   таком   случае   никакие 
коммуникации   все   равно   не   будут   возможны,   но   так   как   почтовая   система 
работает не с пакетами, а с сообщениями, то возможность хотя бы отправлять 
сообщения уже является некоторым результативным решением. Подчеркнем, что 
отдельный  IP  пакет,   доставленный   получателю   (без   возможности   получать 
пакеты в ответ) – еще не есть возможность ДАЖЕ ограниченных коммуникаций, 
а   сообщение   электронной   почты,   доставленное   получателю   (без   возможности 
получить сообщение в ответ) – вполне работоспособные, хотя и ограниченные 
коммуникации.

Следующая   настройка   –   полное   доменное   имя.   Как   мы   знаем,   первым 

этапом  SMTP  коммуникация   является   использование   команды  HELO/EHLO,   с 
помощью которой клиент представляется серверу, сообщая свое доменное имя. 
Как   мы   говорили   выше,   сервера,   к   которым   подключаются   непосредственно 
КЛИЕНТЫ   не   должны   слишком   строго   проверять   корректность   аргумента 
команды HELO/EHLO, так как клиентские системы могут не иметь FQDN вообще 
или   не   иметь   нормального   (принадлежащего   реальному   домену   в  DNS 
Интернета). Однако, почтовые сервера, ориентированные на подключение к ним 
не клиентских компьютеров, в релейных серверов вполне могут себе позволить 
делать   более   строгую   проверку   правильности   доменного   имени,   которое 
предлагает   подключающийся   к   ним   в   качестве   клиента   релейный   сервер. 
Отмечаем при этом, что каждому пользовательскому компьютеру в офисной сети 
действительно может быть проблематично   присвоить  FQDN, но единственному 
релейному серверу этой сети присвоить полноценный  FQDN  вполне реально  . 

Поэтому часто почтовые сервера, например, MX сервера доменов (к которым по 
изученной   нами   идеологии   подключаются   не   компьютеры   конечных 
пользователей, а релейные сервера) проверяют аргумент команды  HELO/EHLO 
по крайней мере на формальную допустимость, т.е. проверяют с помощью DNS 
запросов,   существует   ли  FQDN,   которым   представился   подключившийся 
релейный сервер.  

Возникает вопрос: каким FQDN представляется наш релейный сервер при 

подключении   к   другим   почтовым   серверам?   Разумеется,   по   умолчанию   он 
представляется   свои   доменным   именем,   которое   у   него   есть   в   рамках 
сконфигурированной   операционной   системы,   что   и   видно   при   анализе 
содержимого   параметра   «полное   доменное   имя».   Однако   возможны   ситуации, 
когда почтовый сервер имеет некоторое имя для работы во внутренней сети и 
это имя не допустимо в Интернет, возникает необходимость сконфигурировать 
сервер таким образом, чтобы он представлялся в команде HELO/EHLO не своим 
полным   СИСТЕМНЫМ   именем,   а   другим,   указанным   администратором.   Данная 
настройка «полное доменное имя» как раз и позволяет администратору указать 
почтовому серверу, какое  FQDN  использовать в качестве аргумента в команде 
HELO/EHLO при подключении к удаленным почтовым серверам.