скорости   обмена   данными   между   узлами   локальной   сети,   а   так   же   то,   что   в 
случае   проблем   с   глобальной   линией   связи   офис-ISP  отправка   почты 
пользователями   становилась   невозможной   и   пользователям   необходимо   было 
«следить» за тем, когда восстановится связь с ISP собственными силами, после 
чего   отправлять   почту.   Для   решения   этой   проблемы   было   принято   решение 
установить   в   офисной   сети   собственный   релейный   сервер,   что   позволило 
пользователям:

• Отправлять   почту   со   скорость   обмена   данными,   характерную   для 

локальной сети

• Переложить   заботу   о   «слежении»   за   восстановлением   связи   с  ISP  на 

релейный сервер
Обратите   внимание,   в   случае,   если   релейный   сервер   в   офисной   сети 

настроен   по   умолчанию,   т.е.   передает   полученную   от   клиентов   почту  MX 
целевых   доменов,   его   использование,   помимо   того,   что   дает   перечисленные 
выше преимущества, так же приносит ряд недостатков – фактически отменяются 
описанные РАНЕЕ преимущества. Для объединения преимуществ использования 
как   релейного   сервера   в   офисе,   так   и   релейного   сервера   провайдера   - 
эффективно сконфигурировать  релейный сервер в офисе для использования в 
качестве направляющего узла релейного сервера провайдера. В таком случае 
ВСЕ перечисленные выше преимущества будут достигнуты.. 

Следующая   настройка   –   «Пытаться   отправить   почту   без   использования 

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

Настройка «Выполнять для входящих сообщений обратный поиск в  DNS». 

Когда   клиент   подключается   к  SMTP  серверу,   он   должен   начинать 
взаимодействие с сервером с команды  HELO/EHLO, аргументом которой должен 
быть FQDN клиента. Мы уже обсуждали, как должен вести себя сервер: сервер 
может   вообще   не   требовать   команды  HELO/EHLO,   не   требовать   указания 
аргумента   данной   команды,   проверять   синтаксис  FQDN,   проверять   введенный 
пользователем  FQDN  с помощью обратных  DNS  запросов. По умолчанию  SMTP 
сервер  Microsoft  IIS  требует  использования команды  HELO/EHLO, но  при этом 
даже   не   требует   наличия   аргумента   в   данной   команде   –   в   любом     случае 
клиенту не будет отказано в коммуникациях. Единственная настройка, которую 
позволяет данный сервер относительно аргумента команды HELO/EHLO состоит в 
следующем:   установив   рассматриваемый  checkbox,   можно   заставить   сервер 
выполнять   поиск   в  DNS  введенного   пользователем   аргумента   команды 
HELO/EHLO.   При   этом   реакция   сервера   будет   следующей:   НЕ   зависимо   от 
результата   проверки   сервер   разрешит   коммуникации   с   клиентом,   но   в   том 
случае, если проверка показала НЕ совпадение введенного пользователем FQDN 
и  FQDN  полученного   в   результате   обратного  DNS  преобразования,   строка 
заголовка Received, которую обязательно вписывает в заголовок письма сервер 
будет   содержать   слово  unverified  (не   прошло   проверку).   Никакой   другой 
реакции сервера на неудачную проверку настроить нельзя (например, нельзя 
требовать   разрыва  TCP  соединения),   что,   очевидно,   еще   раз   подчеркивает 
негибкость   конфигурирования   данного   программного   продукта.   Т.е.   сервер 
выполняет прямой DNS запрос, хотя из названия checkbox можно сделать вывод, 
что выполняется обратный DNS запрос.

Таким образом, принципы доставки почты, используемые SMTP сервером

IIS  нами   рассмотрены,   но   возникает   вопрос:   доставка   почты   во   ВСЕ   домены 
конфигурируется   единообразно   с   помощью   настроек   страницы   «Доставка»?   А