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

retry-upon-new-mail

<domain>

Пробовать ли доставку сразу, когда в стоящую очередь пришло новое письмо
в конфигурации это строкаretry-upon-new-mail falseвнутри блока <domain>
Обход расписания при подаче нового письма

Очередь стоит в режиме повторов и ждёт следующей попытки по retry-after. В неё подаётся новое письмо. Эта строка решает, что произойдёт: дождаться расписания — вендорское умолчание false — или назначить попытку немедленно.

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

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

Главная ловушка. На потоке включённая строка отменяет расписание повторов целиком. Приёмник ответил «приходите позже», очередь встала на полчаса — и тут же получила новое письмо, и ещё одно, и ещё. Вместо получасовой паузы приёмник видит непрерывный поток попыток от отправителя, которого он только что попросил отступить.
Что делает Хаб. Не пишет — остаётся вендорское false. Для рассылки это верное значение: подача идёт потоком, и обход расписания здесь означал бы его отсутствие.
Рекомендуемые значения

Для рассылки — только выключено. На потоке включение равносильно отказу от расписания повторов.

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

Проверяйте вместе с темпом. Обход расписания не отменяет ограничений темпа: попытка будет назначена немедленно, но уедет, когда позволит max-msg-rate.

Разделение «рассылке выключено, транзакционной можно» — наше. Из руководства здесь умолчание false и то, что при включении новое письмо назначает доставку немедленно.
Пример в конфигурации
# рассылка: расписание должно работать
<domain *>
    retry-after 30m
</domain>

# транзакционный поток: свежее письмо не ждёт чужой паузы
<virtual-mta transactional>
    <domain *>
        retry-upon-new-mail true        retry-after 2m
    </domain>
</virtual-mta>
Разделение по потокам здесь важнее самого значения: включённая на общем блоке, эта строка обнулит расписание и для рассылки.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают на общем блоке

§ 3.3.10.96

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

Ждут ускорения там, где упирается темп

наш опыт

Чем чреватоОбход расписания назначает попытку, но не поднимает потолки. Если очередь стоит из-за max-msg-rate, включение ничего не меняет, а расписание повторов при этом сломано.
Как заметитьСтроку включили, доставка не ускорилась.
Как правильноСначала посмотреть, чем ограничена очередь: расписанием повторов или темпом.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
retry-upon-new-mail <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
false § 3.3.10.96
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Блок <domain> можно вложить в <virtual-mta> — тогда обход расписания действует только в этом потоке. Подхватывается по pmta reload.
⇄

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

1 связь

На что влияет

retry-after<domain>Расписание, которое эта строка обходит: при включении новое письмо назначает попытку, не дожидаясь паузы. § 3.3.10.96

Как проверить на узле
Значение печатает команда настроек очереди; результат виден по тому, совпадают ли попытки с расписанием:
pmta show settings gmail.com/vmta1 | grep -i retry-upon-new-mail
pmta show queues --mode=retry --maxitems=20
Если очередь в режиме повторов, а попытки идут чаще расписания, обычно виновата именно эта строка. Хаб такого расхождения не показывает.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Настроить темп под провайдера
Соседние настройки блока <domain>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutВсе 135 директив блока →