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

data-send-timeout

<domain>

Сколько ждать отправки очередного куска тела письма
в конфигурации это строкаdata-send-timeout 3mвнутри блока <domain>
Пока тело письма уходит в сеть

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

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

Нижняя граница задана стандартом. Руководство говорит прямо: для полного соответствия RFC 2821 таймаут должен быть не меньше трёх минут — ровно столько и стоит в умолчании.

Главная ловушка — сокращают его вместе с остальными. Таймауты разговора правят пачкой, и этот попадает под руку вместе с connect-timeout и smtp-greeting-timeout. Но у тех нижней границы нет, а у этого есть: спустив его ниже трёх минут, вы выходите за пределы стандарта — и рвёте передачу на медленных приёмниках, у которых письмо всё равно бы уехало.
Что делает Хаб. Не пишет — остаётся вендорское 3m, и это верное значение: оно совпадает с нижней границей стандарта. Трогать его стоит только вверх и только под тяжёлые письма на медленных каналах.
Рекомендуемые значения

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

Вверх — под тяжёлые письма. Рассылка с вложениями на медленный приёмник может упереться в этот таймаут честно; пять минут там уместны.

Срабатывание — про приёмника, не про письмо. Оно означает, что тот перестал забирать данные из сети, а не что письмо слишком велико.

Совет поднимать под тяжёлые письма — наш. Из руководства здесь умолчание 3m и прямое требование RFC 2821 держать не меньше трёх минут.
Пример в конфигурации
# тяжёлая рассылка на медленный приёмник — даём запас
<domain slow.example.com>
    data-send-timeout 5m</domain>
Вниз этот таймаут не правят: три минуты умолчания и есть нижняя граница, заданная стандартом.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Сокращают ниже трёх минут

§ 3.3.10.76

Чем чреватоВыход за пределы RFC 2821, о чём руководство предупреждает отдельно. Передача рвётся на медленных приёмниках, у которых письмо уехало бы, — и каждый обрыв несёт риск дубля.
Как заметитьОбрывы передачи на конкретных доменах, у остальных всё в порядке.
Как правильноВернуть три минуты и править только вверх.

Правят его заодно с остальными таймаутами

наш опыт

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

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

2 связи

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

smtp-data-termination-timeout<domain>Следующее ожидание: тело ушло, ждём подтверждения приёма. § 3.3.10.63smtp-greeting-timeout<domain>Предыдущее ожидание той же цепочки, до того как разговор дошёл до тела письма. § 3.3.10.75

Как проверить на узле
Действующее значение печатает команда настроек очереди; обрывы передачи протоколируются отдельно, если их запись включена:
pmta show settings slow.example.com/vmta1 | grep -i data-send-timeout
pmta show settings slow.example.com/vmta1 | grep -i log-transfer-failures
Без включённой записи обрывов передачи их не видно нигде. Хаб таймауты разговора не задаёт и обрывы не собирает.
◇

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

3 статьи

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

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