
домена 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 при подключении к удаленным почтовым серверам.