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

Отправка Microsoft Exchange на неправильный адрес почтового сервера

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

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

По какой-то причине Exchange Server получает IP-адрес домена учетной записи получателя вместо использования адреса из записи MX. (например, mindspring.com вместо mx3.mindspring.com)

Мой клиент работает под управлением Small Business Server 2011 Standard с Exchange 2010. Остальные ~ 200 сообщений в день отправляются нормально.

(увеличить)

Мои исследования на данный момент:

  1. Microsoft Exchange не использует запись MX
  2. Изменения IP случайного получателя в Microsoft Exchange
  3. обмен отправкой на запись А
    1. Возможно актуально: ссылка на сайт
  4. обмен отправкой на неправильный mx
    1. Та же ситуация, но с другой стороны: ссылка на сайт
    2. Та же ситуация, без разрешения: ссылка на сайт

TL; DR: Один из двух провайдеров, которых мы используем, блокирует DNS-запросы извне своей сети. DNS-запросы иногда приходили из сети другого интернет-провайдера ...

Исправление: Реализуйте статический маршрут в брандмауэре для DNS-серверов интернет-провайдеров, чтобы использовать определенный интерфейс или использовать другую службу (например, OpenDNS или Google DNS).

История: Ну мы выяснили, в чем проблема. Сервер обмена работал в основном так, как мы и ожидали. У нас есть двойное WAN-соединение, на которое брандмауэр переключается, если основной выходит из строя. Итак, на контроллере домена мы добавили DNS-серверы для обоих наших интернет-провайдеров, которые будут опрашиваться (вместе с OpenDNS в качестве третичного варианта). Нам нужно будет провести дополнительное исследование этой конкретной процедуры, но мы обнаружили, что Exchange не все время опрашивал первый сервер (наше основное WAN-соединение).

Казалось, что он постоянно переключался между всеми вариантами. Это работало без проблем, пока наш вторичный интернет-провайдер не изменил настройки на своих DNS-серверах, чтобы отклонять соединения с IP-адресов за пределами их сети. Захват пакета выявил этот ответ, который в конечном итоге привел нас к нашему выводу. Когда Exchange получил отказ, он просто запросил запись A и попытался установить соединение, используя ее.

Что ж, если я попытаюсь использовать telnet mindspring.com:25, я не смогу подключиться, поэтому я подозреваю, что ServerHostname - отвлекающий маневр. Очевидно, что вы подключаетесь к почтовому серверу, но для использования порта 25 требуется проверка подлинности. Вы получаете ошибку 550 либо потому, что на сервере, к которому вы подключены, включена проверка подлинности SMTP, либо потому, что они пытается заставить TLS.

Если вы перейдете в командную строку на этом сервере и наберете:

nslookup
set type=mx
mindspring.com

что ты получишь обратно? Все проверяется? Вы получите тот же ответ, если сделаете? 

nslookup
server 8.8.8.8
set type=mx
mindspring.com

Или вы работаете на mindspring, и это все внутреннее?