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

smtp-data-termination-timeout

<domain>

Сколько ждать финального 250 после отправки тела письма
в конфигурации это строкаsmtp-data-termination-timeout 10mвнутри блока <domain>
Письмо ушло, ответа нет

Тело письма отправлено целиком, точка поставлена. Приёмник должен ответить 250 ok — то есть подтвердить, что письмо принято. Это ожидание и отмеряет здешний таймаут.

Это самый неоднозначный момент разговора. Пока ответа нет, узел не знает, принято письмо или нет. Приёмник мог его принять и не успеть ответить; мог не принять; мог зависнуть на антивирусной проверке. Почтовый протокол этого различия не даёт.

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

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

Оставьте умолчание. Из всех таймаутов разговора этот — единственный, у которого сокращение стоит дороже ожидания.

Если очередь стоит, дело не в нём. Долгое ожидание финального ответа занимает слот соединения, но лечится это потолком max-smtp-out, а не сокращением таймаута.

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

Правило «не сокращать» и совет лечить очередь потолком соединений — наши. Из руководства здесь умолчание 10m и прямое предупреждение: слишком малое значение скорее всего приведёт к дублям.
Пример в конфигурации
# умолчание оставлено намеренно; очередь разводим потоком, а не таймаутом
<domain gmail.com>
    smtp-data-termination-timeout 10m    max-smtp-out 20
</domain>
Строка написана явно не ради изменения значения, а ради того, чтобы её не сократили при следующей правке таймаутов: рядом стоит настоящее лекарство от стоящей очереди.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Сокращают, чтобы очередь не стояла

§ 3.3.10.63

Чем чреватоУзел перестаёт дожидаться подтверждения и повторяет письма, которые приёмник уже принял. Получатель видит вторую копию, а иногда и третью — руководство предупреждает об этом прямо.
Как заметитьЖалобы на повторные письма, при этом отказов в учёте нет.
Как правильноВернуть умолчание, а очередь развести потолком max-smtp-out.

Считают долгий ответ поломкой приёмника

наш опыт

Чем чреватоКрупные приёмники после точки уходят на проверку содержимого, и ответ в несколько минут у них штатный. Сокращение таймаута под них ломает доставку ровно там, где она работала.
Как заметитьДубли появились у одного крупного почтовика, у остальных всё по-прежнему.
Как правильноРазличать долгий ответ и отсутствие ответа: первое — норма.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
smtp-data-termination-timeout <time-interval>
Значения
интервал времени: число и буква — d сутки, h часы, m минуты, s секунды
Умолчание
10m § 3.3.10.63
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Подхватывается по pmta reload; на идущие разговоры не влияет.
⇄

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

1 связь

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

assume-delivery-upon-data-termination-timeout<domain>Второй ответ на ту же неопределённость: считать доставку состоявшейся вместо повтора. § 3.3.10.63

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

data-send-timeout<domain>Следующее ожидание: тело ушло, ждём подтверждения приёма. § 3.3.10.63

Как проверить на узле
Действующее значение печатает команда настроек очереди; жалобы на дубли — единственный внешний признак, что оно занижено:
pmta show settings gmail.com/vmta1 | grep -i data-termination-timeout
pmta show queues --connected=yes --no-rcpt-events
Сам по себе таймаут в учёте не виден: сработавший даёт временную неудачу, неотличимую от прочих. Хаб дублей не отслеживает — о них узнают от получателей.
◇

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

3 статьи

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

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