assume-delivery-upon-data-termination-timeout

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

Считать ли доставку состоявшейся, когда подтверждения так и не пришло
в конфигурации это строкаassume-delivery-upon-data-termination-timeout falseвнутри блока <domain>
Ставка вместо повтора

Тело письма отправлено, smtp-data-termination-timeout истёк, подтверждения нет. Дальше у узла ровно два пути, и эта строка выбирает между ними.

Умолчание false — повторить. Узел считает попытку неудачной и вернёт письмо в очередь. Если приёмник его на самом деле принял, получатель увидит вторую копию.

true — записать доставку. Дубля не будет, но и уверенности тоже: запись в учёте появится независимо от того, дошло письмо или нет. Руководство говорит об этом прямо — «может привести к дублям, если применять без нужды», то есть само по себе включение не лечит, а меняет сторону риска.

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

Цена решения стоит того, чтобы её знать. Хаб считает доставляемость по записям учёта, а запись, сделанная на предположении, в этот счёт попадает наравне с подтверждённой. Дубль заметен получателю и вызывает жалобу; ложная доставка не заметна вовсе и тихо завышает показатель.

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

Рекомендуемые значения

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

Включать — только под конкретного приёмника. У почтовика, который систематически не отвечает после точки, но письма принимает, включение оправдано. В блоке со звёздочкой — никогда.

Учтите, что показатель доставляемости станет несопоставим. До и после включения его нельзя сравнивать: числитель считается по-другому.

Порядок «сначала таймаут, потом эта строка» и предупреждение о несопоставимости показателя — наши. Из руководства здесь умолчание false, точное условие срабатывания (ответ на точку после DATA или на последний сегмент BDAT) и оговорка о дублях при применении без нужды.
Пример в конфигурации
# известный приёмник молчит после точки, но письма принимает
<domain legacy.example.com>
    smtp-data-termination-timeout 10m
    assume-delivery-upon-data-termination-timeout true</domain>
Строка стоит рядом с полным таймаутом намеренно: включать её имеет смысл, только когда ожидание уже доведено до предела и не помогло.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают в блоке со звёздочкой

§ 3.3.10.102

Чем чреватоВсе таймауты подтверждения по всем приёмникам превращаются в доставки. Показатель доставляемости растёт, а связь его с реальностью теряется.
Как заметитьДоставляемость выросла ровно в день правки конфигурации.
Как правильноУбрать из общего блока; включать точечно, под конкретного приёмника.

Включают вместо того, чтобы поднять таймаут

наш опыт

Чем чреватоПричина — недостаточное ожидание — остаётся, а её признак исчезает. Приёмник по-прежнему не успевает ответить, но узел этого больше не замечает.
Как заметитьВключено при таймауте подтверждения заметно ниже умолчания.
Как правильноСначала вернуть таймаут к десяти минутам и посмотреть, останется ли проблема.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
assume-delivery-upon-data-termination-timeout <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
false § 3.3.10.102
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Срабатывает только при истечении smtp-data-termination-timeout — на прочие неудачи разговора не влияет. Подхватывается по pmta reload.
Как проверить на узле
Значение печатает команда настроек очереди; отличить предположенную доставку от настоящей в учёте нельзя — остаётся сверять объёмы:
pmta show settings legacy.example.com/vmta1 | grep -i assume-delivery
pmta show queues | grep -i legacy.example.com
Резкий рост доставляемости сразу после включения — единственный доступный признак того, что доля таких записей велика. Хаб их не различает.
В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Настроить темп под провайдера