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

max-rcpt-per-message

<source>

Сколько получателей принимается на одно письмо
в конфигурации это строкаmax-rcpt-per-message 0внутри блока <source>
То же имя ещё 1:<domain><source>— часть из них другие настройки, часть та же самая
Потолок на приёме, а не при отправке

Сколько получателей узел согласен принять в одном письме. Подающая система перечисляет их командами RCPT TO — по одной на адрес, — и как только их число переваливает за предел, следующие получают отказ.

Умолчание — 0, то есть предела нет. Из коробки узел примет письмо с любым числом адресов, сколько бы подающая система ни назвала. Директива нужна там, где такую щедрость надо ограничить: подающих несколько, или она одна, но ошибается.

Отказ приходит не на письмо, а на лишние адреса. Каждый RCPT TO сверх предела отвергается сам по себе; письмо при этом остаётся принятым и уходит тем получателям, что успели уложиться. Переключает это поведение соседняя строка too-many-rcpts-fails-message: с ней отказ переносится на DATA, и тогда письмо не принимается целиком. Без неё лишние адреса просто исчезают из письма.

Тёзка из блока приёмника — другая директива. <domain> несёт настройку с тем же именем, и она не про приём, а про отправку: сколько адресов класть в одну передачу приёмнику. Умолчание там 1000, а не 0, и смысл противоположный — не «сколько принять», а «на сколько кусков резать». Совпадение имён вендорское, и его стоит держать в голове, читая чужой конфиг.

Главная ловушка. Лишние получатели пропадают молча — для подающей системы. Отказ приходит на отдельные RCPT TO, и многие рассыльщики считают такой ответ частным сбоем адреса, а не сигналом «письмо ушло не всем»: письмо принято, отчёт зелёный, часть списка не получила ничего. Пока не поставлена too-many-rcpts-fails-message, разница между «отправлено» и «принято к отправке» видна только в журнале узла.
Что делает Хаб. Не пишет — ни эту строку, ни парную к ней too-many-rcpts-fails-message. В блоках подачи, которые собирает Хаб, — авторизация, выбор адреса отправки, переписывание обратного адреса и правка заголовков; предела на число получателей нет ни в одном, и остаётся вендорское 0.

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

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

Оставить 0, пока подача своя. Предел защищает узел от чужой ошибки. Если письма подаёт наш же планировщик и по одному получателю на письмо, ограничивать нечего, а лишняя строка добавит способ выстрелить себе в ногу.

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

Ставить в паре. Отдельно от too-many-rcpts-fails-message предел почти бесполезен: он уменьшает письмо, вместо того чтобы отклонить его. Пара «предел плюс отказ на DATA» даёт подающей системе честный сбой, который она увидит и сможет повторить.

Порядок выбора — наша рекомендация. Из руководства здесь грамматика значения, умолчание 0 и то, что отказ приходит на RCPT, а с парной директивой переносится на DATA.
Пример в конфигурации
# предел без парной строки урезает письмо; с ней — отклоняет целиком
<source 10.0.0.0/8>
    require-auth true
    max-rcpt-per-message 500    too-many-rcpts-fails-message true
</source>
Верхняя строка задаёт потолок, нижняя решает, что случится при перегибе: без неё лишние адреса отпадут, а письмо уйдёт остальным.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят предел без парной строки

§ 3.3.7.39

Чем чреватоУзел не отказывает в письме, а принимает его без лишних адресов. Подающая система видит успех, часть списка не получает ничего, и расхождение всплывает только при сверке отчётов.
Как заметитьЧисло доставленных стабильно меньше числа отправленных, а отказов в отчётах нет.
Как правильноСтавить too-many-rcpts-fails-message вместе с пределом — тогда перегиб оборачивается честным отказом на DATA, который подающая система запишет как сбой и сможет повторить.

Переносят число из блока приёмника

§ 3.3.10.83

Чем чреватоТам директива с тем же именем режет исходящую передачу на куски и по умолчанию равна тысяче. Здесь то же число становится потолком приёма — смысл другой, и 1000 окажется либо избыточным, либо, на крупной пачке, режущим.
Как заметитьВ конфигурации предел выглядит осмысленным, но не соответствует ни одному реальному размеру пачки подающей системы.
Как правильноСчитать от подачи: взять самый крупный законный размер пачки и добавить запас. Число из блока приёмника сюда не переносится.

Пишут unlimited, подразумевая «побольше»

§ 3.3.7.39

Чем чреватоunlimited и 0 — одно и то же: предела нет вовсе. Строка выглядит настройкой, а на деле возвращает узел к вендорскому поведению, и защита, ради которой её добавляли, не работает.
Как заметитьПредел в конфигурации есть, письмо с любым числом адресов проходит целиком.
Как правильноПисать число. Если предел не нужен, строку лучше убрать совсем — так виднее, что ограничения нет.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-rcpt-per-message <integer>
Значения
целое число, либо 0 или unlimited — без предела
Умолчание
0 § 3.3.7.39
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по совпадающим блокам <source>: у более узкой записи адреса оно перекрывает более широкую — тот же порядок, что и у блоков приёмника. Подхватывается по pmta reload, перезапуск сервиса не нужен; на уже принятые письма не влияет.
⇄

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

3 связи

То же имя в других блоках

max-rcpt-per-message<domain>Тёзка со стороны отправки: там это нарезка передачи, а не потолок приёма. § 3.3.10.83

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

too-many-rcpts-fails-message<source>Решает, отклонить лишние адреса или всё письмо целиком. § 3.3.7.40

Где применяется

Одноимённые директивыОдно из имён, которые в двух блоках значат разное. § 3.3.10.83

Как проверить на узле
Строка живёт в блоке подачи, и ни одна команда узла её не печатает — смотреть надо сам конфиг:
grep -n 'max-rcpt-per-message\|too-many-rcpts-fails-message' /etc/pmta/config
pmta test config
Первая команда покажет обе строки сразу — порознь они мало что решают. Вторая проверит, что конфиг вообще разбирается. Поведение проверяется подачей письма с числом адресов заведомо больше предела: без парной строки письмо будет принято усечённым.
◇

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

3 статьи

◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source>:allow-smtputf8disconnect-on-transient-errorallow-authaccept-invalid-recipientsalways-allow-api-submissionВсе 74 директив блока →