max-smtp-out

<domain>критичноХаб задаёт сам

Сколько одновременных соединений узел держит к одному получателю
в конфигурации это строкаmax-smtp-out 15внутри блока <domain>
То же имя ещё 2:<domain><virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Количество одновременных соединений

Одно соединение — это один «разговор» с почтовым сервером получателя: пока разговор идёт, письма уходят по нему одно за другим. Директива задаёт, сколько таких разговоров вести одновременно. Больше соединений — больше писем в минуту, но и заметнее нагрузка на принимающую сторону.

Зачем это трогать. Одновременные соединения — то, на что провайдеры смотрят внимательнее всего, гораздо внимательнее общего объёма. Десять писем в минуту по одному соединению — обычная отправка; те же десять писем в двадцать потоков — повод ответить временным отказом и придержать отправителя.

Что будет, если перебрать. Получатель начнёт отвечать «слишком много соединений» (код 421), очередь уйдёт в backoff, и доставка замедлится сильнее, чем если бы соединений с самого начала было меньше. Недобрать безопаснее, но очередь копится и письма приходят с опозданием.

Главная ловушка. Лимит считается на очередь, а не на получателя. Десять адресов на Gmail — это десять таких лимитов сразу: при значении 20 получатель увидит 200 соединений, а столько не разрешит никто. Считать надо от парка, а не от очереди.
Что делает Хаб. В общий блок <domain *> эту строку не пишет вовсе: потолок соединений там задан уровнем выше, на самом адресе отправки. В блоке получателя она появляется только у правила почтовика — 2, 5 или 10 соединений по выбранному темпу, всегда сдержаннее адресного значения, потому что Yahoo и AOL режут соединения жёстче прочих. У прогреваемого адреса всё то же самое равно единице, и правится это не здесь, а сменой стадии прогрева.
Рекомендуемые значения
Режим На адрес (vMTA) В правиле провайдера Когда это ваш случай
Прогрев, холодный адрес 1 1 Адрес младше 4–6 недель или после паузы
Аккуратно 5 2 Строгие получатели, спорная репутация, первые недели после прогрева
Сбалансированно по умолчанию 15 5 Обычный режим устоявшегося парка
Агрессивно 40 10 Прогретые адреса, лояльные получатели, срочные объёмы
Умолчание PowerMTA 20 — Если директиву не писать вовсе

Поправка на размер парка. Умножьте значение на число адресов, которые шлют тому же получателю, — это и есть то, что он увидит. Мы держим произведение в пределах полусотни соединений на одного получателя: десять адресов — значит по пять, три адреса — можно по пятнадцать. Потолок узла отдельный (total-max-smtp-out, Хаб ставит 5000) и упереться в него на обычном парке трудно.

Строгие получатели. Yahoo и AOL режут соединения жёстче прочих, поэтому в правиле почтовика лимит всегда ниже, чем на самом адресе, — это видно в таблице.

Значения — наша рекомендация, обкатанная на парке, а не вендорская норма. Из руководства здесь только умолчание 20.
Пример в конфигурации
# общий блок — база для всех получателей
<domain *>
    max-smtp-out 15
    max-msg-rate 10/m
</domain>

# строгий получатель — своё значение
<domain yahoo.com>
    max-smtp-out 5</domain>
Письмам на yahoo.com достанется 5, всем остальным — 15.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Считают лимит на получателя, а не на очередь

§ 3.3.10.84

Чем чреватоКаждый адрес открывает получателю свой лимит. Десять адресов при значении 20 — это 200 одновременных соединений на Gmail. Провайдер начнёт отвечать 421, очередь уйдёт в backoff, и парк станет доставлять медленнее, чем один аккуратный адрес.
Как заметитьВ мониторе очередь в состоянии backoff при живом узле; в отказах — «too many concurrent connections» или 421 без внятного текста. Доставка падает ступенькой, а не плавно.
Как правильноДелить бюджет соединений на парк: сначала решить, сколько соединений допустимо показать получателю, потом разделить на число адресов, которые к нему ходят.

Ставят значение выше потолка узла

§ 3.3.1.2

Чем чреватоПервым сработает лимит экземпляра (total-max-smtp-out), и на лицензии Standard это произойдёт молча: в конфиге стоит 200, фактически работает столько, сколько разрешил потолок. Настройка выглядит применённой, но не действует.
Как заметитьЧисло соединений упирается в одно и то же значение независимо от того, что написано в блоке. Проверяется командой pmta show settings — она показывает, что получилось, а не что написано.
Как правильноСначала поднять потолок узла, потом лимит очереди. Хаб ставит потолок 5000 — обычному парку этого хватает с запасом.

Правят значение на прогреваемом адресе

наш опыт

Чем чреватоПрогрев держит холодный адрес на одном соединении осознанно: провайдер судит новый адрес строже всего в первые недели. Подняли до пятнадцати «чтобы быстрее» — получили жалобы и попадание в папку «Спам», а прогрев придётся начинать заново.
Как заметитьРост доли отказов и падение доставляемости именно на новом адресе, при том что остальной парк работает ровно.
Как правильноНе трогать вовсе: блок прогрева в конфиге помечен маркерами WARMUP-MANAGED и перезаписывается Хабом при каждом применении — ручная правка внутри него всё равно потеряется.

Пишут лимит в общий блок вместо конкретного получателя

§ 3.3.10

Чем чреватоЗначение из <domain *> достаётся всем получателям сразу. Занизили ради Yahoo — замедлили Gmail и корпоративные домены, которые спокойно приняли бы втрое больше.
Как заметитьОчереди ко всем получателям растут одинаково, хотя отказов нет: узел просто не открывает достаточно соединений.
Как правильноОбщий блок — умеренная база, отдельные блоки — под строгих получателей. Побеждает самое точное совпадение, а не порядок строк.

Меняют значение и ждут, что поедет застрявшая очередь

§ 3.3.10.84

Чем чреватоПеречитывание конфига применяет новое значение к новым соединениям, но то, что уже стоит в очереди с назначенным расписанием повторов, поедет по-прежнему. Отсюда вывод «настройка не работает» и вторая правка вслед за первой — обычно в худшую сторону.
Как заметитьПосле применения число соединений растёт, а очередь рассасывается не сразу — это нормально и означает, что расписание повторов доигрывает старое.
Как правильноДать очереди доиграть, а если нужно немедленно — двигать её принудительно из «Управления», а не подкручивать лимит второй раз.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-smtp-out <integer>
Значения
положительное целое, число одновременных соединений; умолчание MTA — 20
Умолчание
20 § 3.3.10.84
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Блоки <domain> сливаются от общего к частному: значение из <domain *> перекрывается значением из <domain gmail.com>. Побеждает самое точное совпадение, порядок строк в файле роли не играет.
Как проверить на узле
Узел умеет сказать, какое значение получилось после слияния всех блоков — читать конфиг глазами не нужно. Имя адреса отправки после косой черты добавляет к выводу второй раздел:
pmta show settings gmail.com/mta-news-1
Вывод делится надвое: Virtual MTA Settings — потолок всего адреса отправки, Queue Settings — лимит этой очереди. Оба называются max-smtp-out, и на одной команде видно, какой из них сработает первым. Хаб этого шага пока не делает: генерирует, применяет и не спрашивает узел, что получилось. § 6.3.16
В Хабе
Управляется
Конфигурации → Лимиты доставки
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Прогрев адресов · Настроить темп под провайдера
Важность
критично