
скорости обмена данными между узлами локальной сети, а так же то, что в
случае проблем с глобальной линией связи офис-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 нами рассмотрены, но возникает вопрос: доставка почты во ВСЕ домены
конфигурируется единообразно с помощью настроек страницы «Доставка»? А