Назад | Перейти на главную страницу

Exchange 2003 SP2 / 2007: адресное пространство игнорируется в коннекторе SMTP

MS и Postini (Google) в шоке, и короче говоря, Microsoft заблокировала / заблокировала IP-блокировку Postini. Я думаю, что его снова отменили, но мой способ обхода не работает (см. Ниже).

У меня есть Small Business Server с Exchange 2003 SP2, и SMTP-коннектор по умолчанию настроен для маршрутизации почты через Postini в качестве smarthost. Это прекрасно работает. Адресное пространство:

* cost 1

Из-за этой блокировки я создал еще один SMTP-коннектор под названием «Microsoft Domains», настроенный на использование DNS для доставки почты для всей организации. Под адресными пространствами у меня есть следующее:

hotmail.com cost 1
msn.com cost 1

У меня есть только один виртуальный SMTP-сервер (по умолчанию) в качестве локального плацдарма для обоих этих коннекторов; в разделе Доставка -> Дополнительно поле smarthost пусто.

Проблема в том, что мой коннектор «Microsoft Domains», кажется, игнорируется - я отправил тестовое электронное письмо на свою учетную запись hotmail и ожидал увидеть свой WAN IP в поле «Получено» в заголовках, но он всегда из блока Postini ( 64.18.0.0/20). Более того, я все еще получаю ошибку отказов 5.3.3 от почтовых серверов Microsoft при отправке на учетную запись hotmail.com, так что это определенно все еще выходит из smarthost Postini:

5.5.0 smtp;550 SC-002 Mail rejected by Windows Live Hotmail for policy reasons. The mail server IP connecting to Windows Live Hotmail has exhibited namespace mining behavior.

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

Адресное пространство определяет почтовые адреса или домены для сообщений электронной почты, которые вы хотите маршрутизировать через соединитель. Например, адресное пространство * (звездочка) охватывает все внешние домены - этот соединитель используется для маршрутизации всей внешней электронной почты. Если вы создали второй соединитель с адресным пространством * .net, Exchange будет маршрутизировать всю почту, отправляемую в домен с расширением .net, через второй соединитель. Это действие происходит потому, что Exchange выбирает соединитель с наиболее похожим адресным пространством. Этот параметр настраивается на вкладке «Адрес» в свойствах коннектора SMTP.

Я попытался перезапустить службу Exchange Routing Engine, но безуспешно; Я пробовал изменить стоимость коннектора по умолчанию на 5; Я также пробовал это на SBS 2008 Exchange 2007, но без кубиков. Любые идеи?

Я бы сам скорректировал затраты:

"Если у вас несколько соединителей, особенно соединитель, у которого в адресном пространстве есть * (для отправки электронной почты через вашего интернет-провайдера), вам необходимо тщательно скорректировать стоимость. Коннектор SMTP с подстановочными знаками со знаком * должен иметь самую высокую стоимость, SMTP-коннекторы указывающий на внутренние серверы, должен иметь наименьшее значение (чтобы они использовались первыми). Если вы хотите сбалансировать нагрузку на соединители, вы можете установить несколько соединителей по цене 1. "

Поэтому я бы повысил стоимость коннектора postini до 2, чтобы все сначала пробовали коннектор Microsoft Domains, а затем, когда он замечает, что конкретное адресное пространство переходит к коннектору postini.

Может ли ваш Exchange Server разрешать домены Microsoft? Exchange использует DNS для разрешения доменов перед их категоризацией,

Отправка Интернет-почты Для отправки Интернет-почты Exchange использует те же компоненты, что и для получения Интернет-почты: DNS, протокол SMTP, классификатор сообщений, расширенный механизм очередей и механизм маршрутизации Exchange. Интернет-почта отправляется через Exchange следующим образом:

1. Внутренний пользователь отправляет сообщение в удаленный домен. Сообщение отправляется на сервер Exchange, на котором находится почтовый ящик пользователя.

2. Сообщение передается в расширенную систему очередей одним из двух способов:

Если сообщение было отправлено с использованием клиента Microsoft Office Outlook® Web Access или Outlook (MAPI), хранилище Exchange отправляет сообщение расширенному механизму очередей через драйвер хранилища.

Если сообщение было отправлено с использованием протокола почтового отделения (POP) или клиента протокола доступа к почте Интернета (IMAP), SMTP передает сообщение расширенному механизму очередей.

3. Затем классификатор сообщений запрашивает у сервера глобального каталога адрес получателя, чтобы найти пользователя. Если адрес получателя не указан в политике получателя или если соответствующий получатель с прокси-адресом не существует (адрес получателя не будет сохранен в Active Directory), классификатор сообщений определяет, что сообщение привязано к удаленному домену.

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

5. С помощью этой информации сервер определяет, следует ли отправить сообщение, направить его на промежуточный узел или использовать SMTP-коннектор с удаленным адресным пространством.

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

7. Сообщение направляется на виртуальный SMTP-сервер исходящего коннектора или исходящий SMTP-виртуальный сервер, который отвечает за доставку.

8. Виртуальный SMTP-сервер, расположенный на сервере Exchange, который выполняет категоризацию, затем использует информацию своей метабазы ​​для атрибута действия маршрута для удаленного домена.

9. Затем виртуальный SMTP-сервер на сервере Exchange выполняет одну из двух задач:

Использует DNS для поиска IP-адреса целевого домена, а затем пытается доставить сообщение.

Пересылает сообщение на интеллектуальный хост, который берет на себя ответственность за разрешение и доставку DNS.