Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.49

retry-recipients-after

<domain>Хаб задаёт сам

Сколько ждать, прежде чем повторить попытку конкретному получателю
в конфигурации это строкаretry-recipients-after 10mвнутри блока <domain>
Личная пауза получателя поверх общего расписания

retry-after управляет очередью целиком. Эта строка добавляет второй замок — на каждого получателя отдельно. Адрес, которому приёмник ответил временной ошибкой 4xx, не будет опробован снова, пока не истечёт этот интервал, даже если очередь к тому времени уже дошла до следующей попытки.

Отсюда простое следствие: действующая пауза для адреса — большая из двух. Задать очереди шаг в минуту и ждать попыток раз в минуту бесполезно: получатель, получивший 4xx, всё равно отлежит десять минут вендорского умолчания.

Смысл разделения в том, что одна очередь везёт много адресов. Приёмник мог отказать одному ящику (переполнен) и принять остальные; общее расписание тут ни при чём, а личная пауза не даёт долбиться именно в тот ящик, который сказал «позже».

Главная ловушка. Строку не видно в расчётах. Считают темп по retry-after, получают одно число попыток, а на деле часть адресов отлёживает свою паузу и в попытку не попадает. Расхождение особенно заметно на коротком шаге очереди: при retry-after 1m и умолчании этой строки девять попыток из десяти для отказавшего адреса проходят мимо него.
Что делает Хаб. В шаблоне политик приёмников — 20m при шаге очереди 30m. Личная пауза намеренно короче шага: она работает страховкой, а темп задаёт очередь. Если шаг когда-нибудь сократят, эти двадцать минут станут действующей паузой сами собой.
Рекомендуемые значения

Держите её не длиннее шага очереди. Иначе она, а не retry-after, определяет реальный темп — и правка расписания перестаёт что-либо менять.

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

В выводе настроек она печатается в секундах. 600 в дампе — это те же десять минут вендорского умолчания, просто в другой единице; ни одна соседняя строка так себя не ведёт.

Правило «не длиннее шага очереди» — наше. Из руководства здесь умолчание 10m, одиночный интервал и то, что адрес не опрашивается до истечения паузы независимо от расписания очереди.
Пример в конфигурации
# шаг очереди — полчаса, личная пауза адреса — двадцать минут
<domain gmail.com>
    retry-after 30m
    retry-recipients-after 20m</domain>
Пока пауза короче шага, темп задаёт очередь. Сделайте её длиннее — и расписание очереди перестанет иметь значение для адресов, ответивших 4xx.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают темп только по расписанию очереди

§ 3.3.10.49

Чем чреватоРеальная пауза для адреса — большая из двух. Расчёт «срок делить на шаг» даёт завышенное число попыток, если личная пауза длиннее шага очереди.
Как заметитьПопыток по очереди много, а конкретный адрес опрашивается заметно реже.
Как правильноСчитать по большему из двух значений либо держать личную паузу короче шага.

Ставят её длиннее шага и правят потом расписание

наш опыт

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

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

2 связи

Зависит от

bounce-after<domain>Общий срок: личная пауза его не продлевает, она лишь уменьшает число попыток, которые достанутся конкретному адресу. § 3.3.10.49

Работают в паре

retry-after<domain>Расписание очереди целиком. Действующая пауза для адреса — большая из двух, а не эта. § 3.3.10.49

Сюда ссылаются

Получатели, отложенные после временного отказаТа директива, которой срок удержания и задаётся. § 6.3.11

Как проверить на узле
Значение печатает команда настроек очереди — и печатает его в секундах, не интервалом:
pmta show settings gmail.com/vmta1 | grep -i retry-recipients-after
600 в выводе означает десять минут. Сколько адресов сейчас отлёживает личную паузу, PowerMTA не показывает; Хаб этого тоже не считает.
◇

Что ещё почитать

3 статьи

◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.◇Щадящий режим — вторая личность очередиОчередь, которой приёмник начал отказывать, переключается на параллельный набор лимитов, повторов и маршрутов — десять директив, действующих только в этом режиме.◇Наблюдение за репутацией внутри узлаMTA сам следит за ответами приёмников и по совпадению с образцом меняет режим очереди — реакция внутри соединения, а не по телеметрии.

В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера
Соседние настройки блока <domain>:bounce-afterretry-afterbackoff-retry-afterbackoff-to-normal-afterbackoff-upon-all-sources-disabledВсе 135 директив блока →