await-slot

<smtp-listener>

Ждут ли новые соединения на этом приёмнике при исчерпании потолка
в конфигурации это строкаawait-slot falseвнутри блока <smtp-listener>
Подождать или отказать — по приёмнику отдельно

Умолчание — false. Строка решает, что делать с новым входящим соединением, когда узел упёрся в потолок total-max-smtp-in: подождать освободившегося слота или отказать.

С умолчанием MTA отвечает приветствием 421 — служба недоступна — и закрывает соединение.

Отличие от общей строки узла smtp-await-slot в области: та задаёт поведение для всего узла, эта — для соединений на адресе одного приёмника. Так можно развести приёмники: подача ждёт, приём жалоб отказывает — или наоборот.

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

Отказ 421 честнее: он говорит «занят, приходи позже», и подающая сторона знает, что делать.

Что делает Хаб. Не пишет — ни здесь, ни общей строкой узла. Значит действует вендорское умолчание: при исчерпании потолка в 1000 соединений узел отвечает 421 и закрывает соединение.

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

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

Что ставить. Выбор зависит от того, чем занят приёмник:

Значение Когда
false (умолчание) подача от своей платформы, которая умеет повторить позже
true приёмник входящей почты: чужой сервер повторит не скоро, и лучше подержать соединение

Второе оправдано на приёме жалоб и отчётов: там отправитель чужой, и его расписание повторов вам неподвластно.

Умолчание false, привязка к адресу приёмника и связь с потолком входящих — из руководства, § 3.3.17.1. Ответ 421 при отказе — § 3.3.1.32. Разбивка случаев наша.
Пример в конфигурации
# подача отказывает сразу, приём жалоб ждёт слот
<smtp-listener 0/0:2525>
    await-slot false
</smtp-listener>

<smtp-listener 0/0:25>
    await-slot true</smtp-listener>
Своя платформа получит 421 и повторит по своему расписанию. Чужой сервер, приносящий жалобу, подождёт слота — повторять он будет нескоро и может не повторить вовсе.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают ожидание на приёмнике подачи

наш опыт

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

Считают строку способом поднять потолок

§ 3.3.17.1

Чем чреватоПотолок она не меняет: соединений по-прежнему не больше, чем разрешено общей строкой узла. Меняется только то, что видит клиент сверх потолка.
Как заметитьСтрока включена, а число одновременных соединений не выросло.
Как правильноПоднимать сам потолок, а эту строку выбирать по тому, кто подаёт.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
await-slot <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.17.1
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<smtp-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <smtp-listener> и относится к соединениям на адресе одного приёмника. Наследования между приёмниками нет; общая для узла строка задаёт поведение там, где приёмник своего не сказал.
Как проверить на узле
Настройку видно в конфигурации, проявляется она только у потолка:
grep -n 'await-slot\|total-max-smtp-in\|smtp-listener' /etc/pmta/config
pmta show status | grep -i 'smtp-in\|inbound'
Пока число входящих соединений далеко от потолка, разницы между значениями нет никакой. Проверять поведение имеет смысл только под нагрузкой, близкой к пределу.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Подключить платформу отправки