max-message-size

<source>Хаб задаёт сам

Наибольший размер письма, принимаемого по SMTP от этого источника
в конфигурации это строкаmax-message-size unlimitedвнутри блока <source>
То же имя ещё 1:<source><transmissions-api>— часть из них другие настройки, часть та же самая
Наибольший размер принимаемого письма

Письмо крупнее указанного размера не принимается от этого источника — отказ приходит на этапе подачи, до того как письмо ляжет в очередь.

Умолчание — без ограничения. Источник, у которого строки нет, примет письмо любого размера. Потолок ставится осознанно, и обязательно в общем блоке <source 0/0> тоже: узкие блоки перекрывают только то, что называют, а всё остальное остаётся с вендорским «сколько угодно».

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

Тёзка из другого блока считает не то же самое. max-message-size внутри <transmissions-api> ограничивает размер запроса HTTP-подачи и имеет своё умолчание — сто мегабайт. К почтовой подаче он отношения не имеет.

Главная ловушка. Считается размер письма после кодирования, а не размер вложения. Base64 добавляет примерно треть, поэтому вложение в 7 мегабайт даёт письмо около 10. Лимит, выставленный «под двадцатимегабайтный файл», этот файл и отвергнет.
Что делает Хаб. Пишет max-message-size 30M в источниках, подобранных по адресу: для подачи с самой машины (<source 127.0.0.1>) и для адресов из списка «Кому разрешена подача». В именованных источниках подачи с логином строки нет вовсе, и там действует вендорское «без ограничения». Тридцать мегабайт выбраны с запасом и ни от чего не считаются.
Рекомендуемые значения

Считать от приёмника, а не от отправителя. Крупные почтовые службы останавливаются в районе 25 мегабайт на письмо целиком; всё, что больше, узел примет, довезёт и получит отказ. Ставить свой потолок выше чужого — значит платить спулом и попытками за письма, которым всё равно откажут.

Заложить треть на кодирование. Ограничение считает письмо таким, каким оно приехало по SMTP. Чтобы принять вложение в 15 мегабайт, потолок нужен около 20.

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

Умолчание unlimited и форма записи — вендорские. Оценка «около 25 мегабайт у крупных приёмников» — наш ориентир, а не строка из руководства.
Пример в конфигурации
# общий блок — потолок для всех, кого не назвали отдельно
<source 0/0>
    max-message-size 20M</source>

# платформе, которая шлёт каталоги, — свой
<source 10.0.0.5>
    max-message-size 40M
</source>
Двадцать мегабайт достанутся всем подающим, кроме 10.0.0.5: узкий блок перекрывает общий.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят потолок только подающим платформам

§ 3.3.7.37

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

Считают предел по размеру вложения

наш опыт

Чем чреватоКодирование добавляет к вложению около трети, и письмо приезжает больше файла. Пользователь видит отказ там, где по его расчётам запас был.
Как заметитьФайл, который «точно меньше лимита», отвергается на подаче.
Как правильноБрать потолок примерно на треть выше наибольшего вложения, которое должно проходить.

Ставят потолок выше того, что принимает получатель

§ 3.3.7.37

Чем чреватоМесто в спуле, попытки доставки и запись об отказе тратятся на письмо, которое нельзя было доставить в принципе. Отказ при этом достаётся не отправителю, а статистике узла.
Как заметитьКрупные письма уходят в очередь и возвращаются отказом по размеру от приёмника, а не отвергаются на подаче.
Как правильноДержать свой потолок не выше того, что принимает самая строгая из нужных вам почтовых служб.

Путают с одноимённой строкой блока подачи по HTTP

§ 3.3.20.5

Чем чреватоmax-message-size внутри <transmissions-api> — другая настройка с другим умолчанием (сто мегабайт). Имя одно, блоки разные.
Как заметитьПравка не действует ни на что: почтовая подача принимает прежнее, а запросы HTTP-подачи и не ограничивались.
Как правильноСмотреть блок, а не имя: почтовую подачу ограничивает строка в <source>.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-message-size <size>
Значения
N с суффиксом b, k, m, g или t — например 20M; либо 0, либо unlimited; голое число в байтах вендор объявил устаревшей формой
Умолчание
unlimited § 3.3.7.37
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Блоки <source> сливаются так же, как блоки получателя: от общего к точному, побеждает самое узкое совпадение. Значение из <source 0/0> достаётся всем, кого не назвали отдельно. Подхватывается по pmta reload.
Как проверить на узле
Команды, печатающей настройки источника, у MTA нет — проверять надо живым соединением с приёмника:
printf 'EHLO test\r\nQUIT\r\n' | nc -w5 узел 2525
Если в ответе на EHLO есть строка 250-SIZE, число в ней и есть действующий потолок для этого соединения. Если строки нет, остаётся проверка подачей: отправить письмо чуть больше предела и увидеть отказ до постановки в очередь.
В Хабе
Управляется
Конфигурации → Лимиты доставки
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Планирование мощности