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

  • Article

Исходная статья опубликована в пятницу, 29 марта 2013 г.

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

Сведения о конфигурации и коренная причина проблемы

Сначала я подумал, что это может быть результатом того, что пограничный сервер настроен для использования внешнего DNS-сервера (DNS-сервера, который разрешает внешние узлы). Обычно когда пограничный транспортный сервер настроен для использования внешней службы доменных имен (DNS), он разрешает доменное имя в общие IP-адреса (как правило, указывая на себя, на внешний брандмауэр или на поставщика услуг) вместо транспортного сервер-концентратора на сайте Active Diectory, что приводит к циклу почты.

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

clip_image002

 

В этом сценарии происходит следующее. Когда пограничный транспортный сервер получает сообщение электронной почты размером в 20 МБ от отправителя в Интернете, он принимает это сообщение. Пограничный транспортный сервер имеет два соединителя, соответствующие адресным пространствам — один для адресного пространства contoso.com на сайте Active Directory, а другой для адресного пространства *. Когда решение о маршрутизации зависит от всех доступных соединителей, один из них от пограничного сервера к серверу-концентратору не учитывается из-за ограничения размера (он имеет ограничение 10 МБ). Лучшим соответствием оказывается соединитель * от пограничного сервера в Интернет, который имеет ограничение на размер сообщений в 30 МБ (см. описание алгоритма выбора соединителя в статье Общие сведения о маршрутизации сообщений).

Результат: сообщение перенаправляется обратно в Интернет, и возникает цикл сообщения между Интернетом и пограничным сервером.

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

При использовании DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ## (записи DNS для этого домена настроены в цикле)

При использовании промежуточного узла:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP# (Число прыжков превышено — возможен цикл почты)

Решение

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

  • Установить для параметра MaxMessageSize в соединителе получения (который получает входящую почту из Интернета) значение 10MB, чтобы сообщения из Интернета были ограничены размером в 10 МБ.
  • Установить для параметра MaxMessageSize в соединителе отправки из пограничного сервера на сервер-концентратор значение 30MB, которое позволит получать от внешних отправителей сообщения размером до 30 МБ.

Загадка разрешена! Мои благодарности Ариндему Токдеру (Arindam Thokder) и Скотту Лендри (Scott Landry), которые помогли мне подготовить эту публикацию для блога!

Суреш Кумар (Suresh Kumar) (XCON)

Это локализованная запись блога. Исходная статья находится по адресу Mysterious mail loop on Edge Transport server: Check your size limits!