Too many hops: как найти петлю переадресации почты

При Too many hops восстановите маршрут конкретного письма и найдите повторяющийся переход между правилами доставки. Петлю могут создавать алиасы, пользовательские пересылки и серверные маршруты. Повышение допустимого числа переходов не исправляет цикл: сначала нужно подтвердить, почему письмо возвращается на уже пройденный участок.

Сохраните отказ, а не только пересказ отправителя

Попросите отчёт о недоставке с текстом причины, временем и доступными сведениями о маршруте. Отделите исходное письмо от сообщения об отказе. У них разные назначения, и карта движения уведомления не обязательно повторяет путь исходного сообщения.

В RFC 3463 семейство X.4.6 описывает обнаруженную петлю маршрутизации, связанную с многократной пересылкой. Это расширенный статус. Его не следует превращать в обязательный одинаковый трёхзначный SMTP-ответ для всех почтовых систем.

Зафиксируйте, кому письмо должно было доставиться в конце. Если конечное назначение никто не определил, легко исправить симптом пересылкой ещё в один ящик. Сначала нужен договор: где заканчивается доставка и где хранится рабочая копия.

Отображаемый адрес не объясняет все переходы

Один видимый адрес может быть алиасом, участником группы или входом в дальнейший маршрут. Для каждого шага выясните фактического получателя и условие передачи. Отдельно спросите о настройках, которые добавлялись при старом переезде почты и могли остаться включёнными.

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

Учебный маршрут: где возникает обратная дуга

Предположим, входной алиас направляет письмо в общий ящик, тот пересылает его во внешний сервис, а внешний сервис возвращает на тот же алиас. Обозначения А, Б и В условные; таблица не содержит настоящих адресов, настроек или результата проверки компании.

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

Как читать Received для карты доставки

В RFC 5321 предусмотрено добавление Received в начало сообщения. Поэтому стандартную последовательность прохождения восстанавливают от более ранних записей к новым, учитывая этот порядок. Сохраняйте временные зоны и не переставляйте строки произвольно.

Received помогает выделить кандидатов на переходы, но не заменяет проверку правил владельцами. Уточняйте, какие строки относятся к доверенной части обработки, и сопоставляйте их с доступными событиями своей системы. Публиковать внутренние адреса и идентификаторы для этого не требуется.

Повтор имени хоста в заголовках сам по себе не означает бесконечный цикл. Сообщение могло пройти разные предусмотренные этапы одного сервиса. Подтвердить нужно возврат, который снова приводит к тому же правилу и не приближает к конечной доставке.

Длинный маршрут и петля требуют разных выводов

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

Если маршрут конечный, объясните назначение каждого посредника. Возможно, после изменений сохранились ненужные пересылки. Не переносите предел одного продукта на другой и не делайте увеличение лимита первым действием без разбора цепочки.

Для поддержки почты передайте обезличенную карту и отчёт об отказе. Это помогает обсуждать конкретный переход. Формулировка «почта не работает» не показывает, кто должен изменить правило.

Исправляйте одно подтверждённое правило

Определите владельца изменения и сохраните прежнюю настройку. Согласуйте, что после исправления получает конечный адресат и остаются ли нужные копии. На время проверки не добавляйте новые обходные пересылки: они меняют наблюдаемую цепочку.

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

При переносе почтовой инфраструктуры полезно заранее выписать переходные правила и условие их отключения. Иначе временный мост между старым и новым провайдерами может остаться постоянной частью маршрута.

Контрольное письмо должно проверять путь, а не создавать поток

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

Подтвердите получение там, где доставка должна завершиться, отсутствие повторного круга и нужный результат копирования. Если алиасов несколько, выделите их как отдельные сценарии. Успех одного адреса не подтверждает автоматически все правила домена.

1. Сохраните исходный отказ, время и ожидаемого получателя.
2. Восстановите наблюдаемые переходы по метаданным сообщения.
3. Уточните алиасы, группы, пересылки и серверные маршруты у владельцев.
4. Подтвердите повторяющуюся дугу либо объясните конечный длинный путь.
5. Согласуйте одно исправление и судьбу уже обработанных сообщений.
6. Проверьте небольшое контрольное сообщение и конечную доставку.
7. Закрепите карту маршрута и ответственного за каждое правило.

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