max-message-hops
<source>
Сколько заголовков Received узел согласен увидеть в письме. Каждая почтовая система, через которую письмо прошло, дописывает такой заголовок сверху — получается след маршрута. Слишком длинный след означает, что письмо ходит по кругу, и узел его не принимает.
Это счёт по чужим следам, а не по своим. Узел смотрит на то, что уже есть в письме на момент приёма. Умолчание 100 рассчитано на нормальную почту, где пересылок единицы: письмо со ста заголовками не «долго шло», а зациклилось.
Откуда берутся петли. Обычно из пересылки: ящик A пересылает на B, B настроен обратно на A — письмо ходит между ними, и на каждом круге след удлиняется на два заголовка. Счётчик — единственное, что такой круг останавливает: сами системы петли не видят.
Строка живёт в блоке подачи, а значит применяется на приёме. К исходящей почте она отношения не имеет: письмо, которое узел отправляет, счётчиком не проверяется.
🔴 Но в том же блоке подачи Хаб пишет add-received-header false — осознанно, чтобы не раскрывать в письме внутренние адреса. Побочный результат: наш узел не добавляет своего Received, и счётчик петель на письмах, проходящих только через нас, не растёт. Для нашей подачи это безопасно: письмо приходит напрямую, от подающей платформы или от прогрева самого Хаба, и никуда не пересылается. Но значит это и то, что защита от петель у нас держится не на этой строке, а на том, что пересылки в схеме нет.
Умолчание трогать незачем. Сто пересылок — это заведомо петля, и нормальная почта до такого числа не доходит. Понижение имеет смысл как разовая диагностика, а не как настройка на каждый день.
Понижают, когда ловят петлю. Значение вроде 10 быстрее обрывает круг и раньше показывает его в журнале. После разбора его возвращают: постоянный низкий предел начнёт отбивать честные письма из длинных корпоративных цепочек.
Ноль здесь не описан. Руководство говорит только о положительном целом; что сделает 0, оно не поясняет, и проверять это стоит на стенде, а не на рабочем узле.
# пониженный предел на время разбора петли <source 0/0> add-received-header true max-message-hops 10</source>
▲
Типичные ошибки и проблемы
что делают не так и чем это кончается3 ошибки▶
Понижают предел при отключённом своём Received
§ 3.3.7.6
Держат низкий предел постоянно
§ 3.3.7.38
Ждут, что предел остановит исходящую петлю
§ 3.3.7.38
- Синтаксис
- max-message-hops <integer>
- Значения
- положительное целое число
- Умолчание
- 100 § 3.3.7.38
- Применение
- reload, перезапуск не нужен
- Очередь
- уже поставленное в очередь не затронет
- Где писать
- <source>
- Сколько раз
- один раз в блоке
Связанные директивы
2 связи
grep -n 'max-message-hops\|add-received-header' /etc/pmta/config pmta test config
Что ещё почитать
3 статьи
◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.◇Чем опасна виртуальная машинаРаботать на виртуальной машине можно, но руководство не рекомендует это без достаточного железа и выверенных настроек гипервизора: под нагрузкой узел может перестать отвечать.
- Цена ошибки
- обратимо: вредит, пока стоит
- Сценарии
- Разобрать зависшую очередь