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

allow-cancel-during-transfer

<domain>

Можно ли обрывать соединение, пока тело письма передаётся
в конфигурации это строкаallow-cancel-during-transfer trueвнутри блока <domain>
Быстрая остановка против чистой передачи

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

Умолчание true — позволено. Служба останавливается быстро. Цена в том, что приёмник получил письмо не до конца, и некоторые почтовые серверы такое письмо всё равно доставляют. Узел при повторе отправит его заново — получатель увидит два письма, одно из них обрезанное.

false — не позволено. Передача доводится до конца, дублей не возникает. Руководство честно называет цену: остановка узла может занять заметно больше времени.

Главная ловушка — цена платится не там, где кажется. Настройка выглядит как «про остановку службы», а бьёт по получателям: каждый перезапуск узла с умолчанием оставляет за собой пачку обрезанных писем, которые потом придут вторично. На узле, который перезапускают часто, это регулярный источник жалоб на дубли.
Что делает Хаб. Не пишет — остаётся вендорское true. Конфигурацию Хаб применяет перезагрузкой (pmta reload), а не остановкой службы. Служба останавливается при операции перезапуска из кабинета и при обновлении MTA — и с умолчанием каждая такая остановка может оставить обрезанные письма.
Рекомендуемые значения

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

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

Смотрите на связку с отказом при обрыве. Ту же неопределённость с другой стороны закрывает bounce-upon-transfer-failure: она решает, что делать с письмом после чужого обрыва.

Разделение по частоте перезапусков — наше. Из руководства здесь умолчание true, механика дублей на приёмниках, доставляющих неполные письма, и прямая оговорка, что выключение замедляет остановку.
Пример в конфигурации
# узел, который часто перезапускают: не рвём передачу
<domain *>
    allow-cancel-during-transfer false</domain>
Остановка службы после этого займёт больше времени — ровно столько, сколько нужно на завершение идущих передач.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Оставляют умолчание на узле, который часто перезапускают

наш опыт

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

Выключают на узле, который надо уметь гасить быстро

§ 3.3.10.61

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

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

1 связь

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

bounce-upon-transfer-failure<domain>Та же неопределённость с другой стороны: эта строка решает, рвать ли передачу самим, та — что делать после чужого обрыва. § 3.3.10.61

Как проверить на узле
Значение печатает команда настроек очереди; последствия видны только по жалобам получателей на повторные письма:
pmta show settings gmail.com/vmta1 | grep -i allow-cancel
Обрыв, сделанный самим узлом при остановке, в учёте не отличается от сетевого. Хаб их не различает и дубли не отслеживает.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера
Соседние настройки блока <domain>:file-destinationcommandconnect-timeoutassume-delivery-upon-data-termination-timeoutauth-usernameВсе 135 директив блока →