bounce-after

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

Сколько добиваться доставки, прежде чем отбить письмо
в конфигурации это строкаbounce-after 4d12hвнутри блока <domain>
Крайний срок жизни письма в очереди

Первый из двух будильников, которые управляют отложенным письмом. Этот задаёт срок: письмо старше указанного интервала отбивается — отправителю уходит отчёт о недоставке (DSN). Второй, retry-after, задаёт частоту: как часто пробовать снова, пока срок не вышел. Порознь ни один из них не имеет смысла.

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

Вендорское умолчание — 4d12h, четверо с половиной суток. Для писем с одноразовым кодом это бессмысленно долго: код, доставленный на четвёртые сутки, хуже недоставленного. Для рассылки — лишние сутки диска и очереди за письма, которые почти наверняка уже не уедут.

Главная ловушка. Срок и шаг повторов задаются порознь, и их легко рассогласовать. При вендорских умолчаниях 4d12h и 10m выходит 648 попыток к одному получателю: узел стучится в приёмника, который уже сказал «позже», шестьсот с лишним раз. Обратная ошибка — длинная лесенка повторов под коротким сроком: дальние ступени не отработают ни разу, письмо уйдёт в отказ раньше.
Что делает Хаб. В шаблоне политик приёмников стоит 3d — трое суток во всех пятнадцати блоках: у четырнадцати крупных почтовиков и в общем <domain *>, с пометкой, что вендорское умолчание другое. Рядом Хаб пишет retry-after 30m: 144 попытки за срок вместо 648.
Рекомендуемые значения

Считайте пару, а не одно число. Срок, делённый на шаг повторов, даёт количество попыток. Трое суток при получасовом шаге — 144 попытки; те же трое суток при вендорском умолчании 10m — 432. Второе число ничем не лучше первого, только шумнее для приёмника.

Письмам со сроком годности — часы, не сутки. Одноразовый код или ссылка на сброс пароля имеют смысл первые минуты. Такую почту отправляют отдельным VirtualMTA со своим <domain> внутри и коротким сроком.

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

Правило «срок делить на шаг» и отдельный VirtualMTA для писем со сроком годности — наши. Из руководства здесь умолчание 4d12h и то, что письмо старше срока отбивается отчётом DSN.
Пример в конфигурации
# крупный почтовик: трое суток и получасовой шаг
<domain gmail.com>
    retry-after 30m
    bounce-after 3d</domain>

# письма с одноразовым кодом живут час — отдельный поток
<virtual-mta otp>
    <domain *>
        bounce-after 1h        retry-after 2m
    </domain>
</virtual-mta>
Один и тот же получатель может иметь два разных срока — они считаются на пару «домен + VirtualMTA», и рассылка с почтой по коду не пересекается.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют вендорское умолчание вместе с умолчанием шага

§ 3.3.10.10

Чем чревато4d12h и 10m дают 648 попыток к одному получателю. Приёмник видит отправителя, который не слышит отказа, и это ровно тот образ, за который ограничивают темп.
Как заметитьВ журнале сотни строк 4xx по одной очереди за сутки.
Как правильноСократить срок до трёх суток и увеличить шаг до получаса.

Держат один срок на всю почту

наш опыт

Чем чреватоРассылке трое суток в самый раз, письму с кодом подтверждения — нет. Общий срок либо тянет мёртвую почту, либо рвёт рассылку.
Как заметитьПользователи получают коды подтверждения через сутки после запроса.
Как правильноВынести почту со сроком годности в отдельный VirtualMTA и задать ей свой короткий срок.

Сокращают срок на живой очереди

наш опыт

Чем чреватоСрок считается от подачи письма, а не от правки конфигурации. После pmta reload всё, что уже старше нового срока, отбивается разом — пачка отказов в одну минуту.
Как заметитьВсплеск отказов сразу после перезагрузки конфигурации.
Как правильноПеред сокращением посмотреть возраст очереди (pmta list –older-than=… по этой очереди) и сокращать ступенями.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
bounce-after <time-interval>
Значения
интервал времени: число и буква — d сутки, h часы, m минуты, s секунды; допускается составной вид, например 4d12h
Умолчание
4d12h § 3.3.10.10
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Блок <domain> можно вложить в <virtual-mta> или <virtual-mta-pool> — тогда срок действует только для писем этого потока. Подхватывается по pmta reload; на уже лежащие в очереди письма новый срок действует сразу — сокращение срока отобьёт всё, что уже старше него.
⇄

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

3 связи

Как проверить на узле
Действующий срок печатает команда настроек очереди — она работает по паре «домен/vMTA», не по домену вообще:
pmta show settings gmail.com/vmta1 | grep -i bounce-after
pmta list --queue=gmail.com/vmta1 --older-than=3d --maxitems=10
Вторая перечисляет письма очереди старше трёх суток — при сроке 4d12h это почта, которая скоро отобьётся. Хаб возраст писем на экран узла пока не выводит.
В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Настроить темп под провайдера
Важность
критично