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

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

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

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

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

Скриншот] [1] (пока не могу прикрепить изображение (увеличить)

Мои исследования до сих пор:

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

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

Или вы работаете на разумную пружину, и это все внутреннее?

Источник
Другие вопросы по тегам