retry-after

<domain>критичноХаб задаёт сам

Через какой интервал повторять попытку доставки
в конфигурации это строкаretry-after 10mвнутри блока <domain>
Шаг повторов, пока письмо ждёт в очереди

Второй будильник пары. bounce-after задаёт срок, этот — частоту: через сколько пробовать снова после того, как очередь попала в режим повторов. Задаётся одним интервалом или лесенкой — списком через запятую, до тридцати ступеней.

Каждая ступень отрабатывает одну попытку, потом наступает очередь следующей; последняя повторяется до самого отказа. Список 10m,10m,10m,1h,1h,4h означает: три попытки с интервалом в десять минут, две — через час, дальше каждые четыре часа, пока не выйдет срок. Так одна строка обслуживает и приёмника, который просто занят, и приёмника, который отступает намеренно.

Лесенка сбрасывается дважды. После успешной доставки отсчёт начинается с первой ступени — приёмник ответил, значит прежняя осторожность больше не нужна. И при перезапуске узла: счётчик попыток живёт в памяти, поэтому после рестарта все очереди опять стучатся по первой, самой короткой паузе.

Главная ловушка. Вендорское умолчание 10m — не лесенка, а единственная ступень, которая повторяется до конца срока. При умолчании bounce-after это 648 попыток к получателю, который уже попросил подождать. Умолчание выглядит безобидно именно потому, что это одно число: лесенки в нём нет, и отступать оно не умеет.
Что делает Хаб. В шаблоне политик приёмников — 30m, обычная длина серой задержки, во всех пятнадцати блоках, включая общий <domain *>; в резервном VirtualMTA переброса шаг свой — время возврата из щадящего режима по пресету узла, от получаса до двух часов. Лесенку Хаб пока не собирает: она появится, когда по парку наберётся статистика, с какой попытки приёмник обычно начинает принимать.
Рекомендуемые значения

Полчаса — разумная отправная точка. Столько обычно держит серая задержка: приёмник намеренно отказывает первому обращению и ждёт, вернётся ли отправитель. Вернуться через десять минут — значит попасть в ту же задержку ещё раз.

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

Сумма ступеней не должна перекрывать срок. Иначе хвост лесенки не отработает ни разу: письмо уйдёт в отказ раньше, чем дело дойдёт до дальних ступеней.

Получас как отправная точка и правило про сумму ступеней — наши. Из руководства здесь синтаксис списка, предел в 30 ступеней, умолчание 10m и оба сброса — по доставке и по перезапуску.
Пример в конфигурации
# ровный шаг — приёмник просто занят
<domain example.net>
    retry-after 30m</domain>

# лесенка — приёмник отступает намеренно
<domain gmail.com>
    retry-after 10m,10m,10m,1h,1h,4h    bounce-after 3d
</domain>
Во втором блоке 4h — последняя ступень, поэтому дальше повторы идут каждые четыре часа до истечения трёх суток.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Оставляют умолчание и считают это расписанием

§ 3.3.10.46

Чем чревато10m — одна ступень, а не лесенка. Она повторяется до самого отказа, и отступа приёмник не увидит ни на десятой попытке, ни на шестисотой.
Как заметитьОчередь стучится ровно каждые десять минут независимо от того, сколько раз ей уже отказали.
Как правильноЗадать хотя бы получас, а для крупных почтовиков — лесенку.

Рассчитывают на длинный хвост лесенки

§ 11.14

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

Правят шаг, забыв про соседей

наш опыт

Чем чреватоbackoff-retry-after и proxy-retry-after без своих значений берут именно эту строку. Сокращение шага здесь ускоряет повторы и в щадящем режиме, и при сбоях прокси — то есть ровно там, где спешить не надо.
Как заметитьПосле правки очередь в backoff повторяет попытки с прежней частотой.
Как правильноЗадать соседям собственные значения, а не полагаться на умолчание.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
retry-after <time-interval-list>
Значения
интервал времени или список интервалов через запятую, до 30 ступеней; каждый — число и буква d, h, m или s, без пробелов
Умолчание
10m § 3.3.10.46
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. От этой строки берут своё умолчание два соседа — backoff-retry-after и proxy-retry-after; меняя её, вы молча меняете и их. Подхватывается по pmta reload, но текущее место в лесенке не сбрасывает — новое расписание вступает в силу со следующей попытки.
⇄

Связанные директивы

1 связь

Как проверить на узле
Действующий шаг печатает команда настроек очереди; фактические паузы видны по тому, как часто у очереди появляются попытки:
pmta show settings gmail.com/vmta1 | grep -iE 'retry-after|bounce-after'
pmta show queues --mode=retry --maxitems=20
Команда печатает действующее значение, но не то, на какой ступени лесенки сейчас очередь — этого PowerMTA не показывает нигде. Хаб место в лесенке тоже не отслеживает.
В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера
Важность
критично