Exchange 2003 SP2/2007: адресное пространство игнорируется в соединителе SMTP
MS и Postini (Google) находятся в шоке, и, говоря коротко, Microsoft заблокировала / заблокировала IP-адрес Postini. Я думаю, что он снова был отменен, но мой обходной путь не работает (см. Ниже).
У меня есть Small Business Server с Exchange 2003 с пакетом обновления 2 (SP2), и SMTP-соединитель по умолчанию настроен для маршрутизации почты через Postini в качестве smarthost. Это отлично работает. Адресное пространство:
* cost 1
Из-за этой блокировки я создал еще один SMTP-соединитель под названием "Домены Microsoft", настроенный на использование DNS для доставки почты для всей организации. Под адресными пространствами у меня есть следующее:
hotmail.com cost 1
msn.com cost 1
У меня есть только один виртуальный SMTP-сервер (по умолчанию) в качестве локального плацдарма для обоих этих соединителей; в разделе Доставка -> Дополнительно поле смарт-хоста пусто.
Проблема заключается в том, что мой соединитель "Microsoft Domains", кажется, игнорируется - я отправил тестовое электронное письмо на свою учетную запись hotmail и ожидал увидеть мой WAN IP в поле "Received By" в заголовках, но это всегда из блока Postini (64.18.0.0/20). Более того, при отправке на учетную запись hotmail.com я все еще получаю ошибки отказов 5.3.3 от почтовых серверов Microsoft, поэтому он определенно по-прежнему выходит из списка интеллектуальных хостов 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, но без игры в кости. Есть идеи?
2 ответа
Я бы сам изменил стоимость:
"Если у вас есть несколько соединителей, особенно соединитель, который имеет * в адресном пространстве (для отправки электронной почты через интернет-провайдера), вам необходимо тщательно отрегулировать стоимость. Соединитель SMTP с подстановочными знаками * должен иметь самую высокую стоимость, соединители SMTP указание на внутренние серверы должно быть наименьшим (чтобы они использовались первыми). Если вы хотите сбалансировать нагрузку соединителей, то вы можете установить несколько соединителей по цене 1 ".
Поэтому я бы увеличил стоимость соединителя postini до 2, чтобы все сначала пробовали соединитель Microsoft Domains, а затем, когда он замечает, что конкретное адресное пространство переходит к соединителю postini.
Может ли ваш сервер Exchange разрешать домены 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.