Тогда возможности сервера SMTP реализуемого службой IIS имеют вид: 

• Можно   сконфигурировать,   кто   сможет   устанавливать   соединение   с 

почтовым   сервером,   и   кто   сможет   релейно   обслуживаться   почтовым 
сервером, т.е. передавать серверу письма в «чужие» домены

• По умолчанию сервер считает «своим» только один локальный домен, имя 

которого   совпадает   с  FQDN  сервера,   все   остальные   домены   считаются 
«чужими»

• Можно создать «свой» локальный домен (создается домен псевдоним)
• Можно   создать   «свой»   удаленный   домен,   тогда   в   свойствах   удаленного 

домена нужно разрешить получение почты в данный домен

• Почта   в   локальные   домены   (они   только   «свои»)   собирается   в   каталоге 

Drop сервера

• Почта   в   «чужие»   НЕ   описанные   особо   домены   передается   либо  MX 

соответствующего   домена,   либо   направляющему   серверу,   для   этого 
предусмотрена настройка в свойствах почтового сервера

• Почта в «чужие» удаленные домены, описанные особо, передается либо 

MX  соответствующего   домена,   либо   направляющему   серверу,   для   этого 
предусмотрена настройка в свойствах удаленного домена

• Почта в «свои» удаленные домены, описанные особо, передается либо MX 

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

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

сервера MS IIS. 

Для начала сконфигурируем почтовый сервер для выполнения следующей 

задачи:   пусть   данный   почтовый   сервер   размещен   небольшим   провайдером   в 
своей   локальной   сети   в   качестве   релейного,   для   обслуживания   своих 
собственных   пользователей,   подключенных   тоже   с   помощью   технологии 
локальных   сетей.   Как   должен   быть   сконфигурирован   сервер?   Очевидно,   по 
соображениям   безопасности   данный   сервер   не   должен   обрабатывать   почту 
релейно в том случае, если она поступила НЕ от собственных клиентов. Или же 
вообще   запретим   серверу   устанавливать   соединения   с   узлами,   которые   не 
являются  клиентами  данного  провайдера.  Рассмотрим следующий вопрос:  как 
данный   релейный   сервер   должен   поступать   с   сообщениями,   которые   ему 
передаются для релейной обработки? Он может либо передавать эти сообщения 
другому релейному серверу, либо передавать их  MX  целевых доменов. Пусть в 
нашем случае сервер передает письма MX целевых доменов. 

Пусть   провайдер   использует   в   локальной   районной   сети   сетевой   номер 

192.168.0.0/24,   пусть   почтовый   сервер   имеет   адрес   192.168.0.89.   Сервер   НЕ 
принимает   соединений   от   всех,   кто   не   принадлежит   сети   192.168.0.0/24, 
разрешает релейное использование для всех, конфигурирования доставки почты 
мы НЕ выполняем, так как сервер по умолчанию передает поступившую почту 
MX целевых доменов. 

Рассмотрим,   как   сервер   отвергает   соединение   в   том   случае,   если   его 

партнер   НЕ   принадлежит   к   списку   тех,   кому   разрешен   доступ   к   серверу. 
Сконфигурируем   почтовый   клиент   на   некоторой   клиентской   машине 
(192.168.0.253)   и   отправим   на   сервер   письмо   по   адресу  kalashnikoff@mail.ru 
Данный   пример   демонстрирует,   как   сервер   поведет   себя   в   том   случае,   если 
клиент   НЕ   перечислен     среди   тех,   кому   разрешено   соединяться   с   сервером. 
Сервер НЕ отвергает  TCP  соединения (это не по  RFC793), вместо этого сервер 
устанавливает соединение и тут же его разрывает. Теперь снова установим те