Исходная статья опубликована в пятницу, 29 марта 2013 г.
Я инженер технической поддержки в CSS. Я работал с клиентом, который сообщил об ошибке цикла почты для конкретного домена, такого как contoso.com. Эта ошибка наблюдалась только в больших сообщениях электронной почты. Да, это действительно выглядело загадочно, пока не выяснилось, что цикл почты был вызван ограничением размера в соединителе отправки. Я думаю, это было достаточно интересно, чтобы поделиться.
Сведения о конфигурации и коренная причина проблемы
Сначала я подумал, что это может быть результатом того, что пограничный сервер настроен для использования внешнего DNS-сервера (DNS-сервера, который разрешает внешние узлы). Обычно когда пограничный транспортный сервер настроен для использования внешней службы доменных имен (DNS), он разрешает доменное имя в общие IP-адреса (как правило, указывая на себя, на внешний брандмауэр или на поставщика услуг) вместо транспортного сервер-концентратора на сайте Active Diectory, что приводит к циклу почты.
При воспроизведении проблемы я обнаружил, что пограничный транспортный сервер не был настроен для использования внешнего DNS-сервера. Среда, которую я настроил для воспроизведения проблемы, выглядела, как показано на схеме ниже.
В этом сценарии происходит следующее. Когда пограничный транспортный сервер получает сообщение электронной почты размером в 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), которые помогли мне подготовить эту публикацию для блога!
Это локализованная запись блога. Исходная статья находится по адресу Mysterious mail loop on Edge Transport server: Check your size limits!