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

bounce-upon-transfer-failure

<domain>

Отбивать ли письмо, если связь оборвалась во время передачи тела
в конфигурации это строкаbounce-upon-transfer-failure falseвнутри блока <domain>
Выбор между дублем и потерей

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

Вендорское умолчание false выбирает доставку. Письмо остаётся в очереди и повторяется до срока bounce-after. Если приёмник на самом деле его принял, получатель увидит две копии — а иногда и обрезанную первую.

true выбирает отсутствие дублей. Письмо отбивается после первого же оборванного переноса. Дубля не будет — но не будет и письма, если обрыв случился на нашей стороне и приёмник ничего не получил. Третьего варианта у протокола нет.

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

Рассылке — false. Потеря письма стоит дороже, чем вторая копия в ящике.

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

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

Разделение по типу почты — наше. Из руководства здесь вендорское умолчание, механика риска дублей со ссылкой на RFC 1047 и прямая оговорка, что при включении получатель может не получить письмо вовсе.
Пример в конфигурации
# рассылка: доставить важнее, чем избежать повтора
<domain *>
    bounce-upon-transfer-failure false</domain>

# счета и коды: второй экземпляр опаснее недоставленного письма
<virtual-mta billing>
    <domain *>
        bounce-upon-transfer-failure true    </domain>
</virtual-mta>
Разделение по потокам здесь и есть решение: одно значение на всю почту всегда неверно для одной из её частей.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают её на всю почту ради борьбы с дублями

§ 3.3.10.72

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

Лечат этой строкой нестабильную сеть

наш опыт

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

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

1 связь

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

allow-cancel-during-transfer<domain>Второй рычаг того же риска: он решает, можно ли прервать перенос по своей воле, этот — что делать с письмом после чужого обрыва. § 3.3.10.72

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

bounce-upon-pix-transfer-failure<domain>Общий вид того же решения: эта строка — его сужение до одного вида оборудования. § 3.3.10.71

Как проверить на узле
Значение печатает команда настроек очереди; сами обрывы переноса протоколируются отдельной строкой, если их запись включена:
pmta show settings gmail.com/vmta1 | grep -i bounce-upon-transfer-failure
pmta show settings gmail.com/vmta1 | grep -i log-transfer-failures
Вторая строка показывает, пишутся ли обрывы в журнал вообще: при выключенном протоколировании их не видно нигде. Хаб обрывы переноса не собирает.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Настроить темп под провайдера
Соседние настройки блока <domain>:smtp-pattern-listsmtp-553-means-invalid-mailboxbounce-category-patternsbounce-upon-no-mxbounce-upon-5xx-greetingВсе 135 директив блока →