max-smtp-data-volume-rate

<virtual-mta>

Сколько байт за интервал допускается со всего этого адреса
в конфигурации это строкаmax-smtp-data-volume-rate unlimitedвнутри блока <virtual-mta>
То же имя ещё 1:<virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Потолок в байтах на весь адрес отправки

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

В счёт идёт только доставленное. Руководство говорит об этом прямо: к пределу причисляется объём успешных доставок. Отказы, повторы и оборванные передачи мимо счётчика, то есть фактический исходящий трафик с узла может быть заметно больше разрешённого здесь.

Единица объёма пишется прямо в значении. b — байты, k — килобайты, m — мегабайты, g — гигабайты, t — терабайты; без суффикса число понимается как байты. Знаменатель — d, h, m, s с необязательным множителем: 6g/10h — шесть гигабайт за десять часов.

Считает адрес целиком, а не очередь. Соседняя по смыслу max-data-volume-rate живёт в блоке приёмника и ограничивает одну очередь: при десяти приёмниках она разрешит вдесятеро больше написанного. Здесь умножения нет — сколько указано, столько и уйдёт со всего адреса.

Главная ловушка. План отправки живёт в письмах, а этот предел — в байтах, и переводить одно в другое приходится через средний размер письма, который меняется. План на десять тысяч писем при среднем размере в шестьдесят килобайт — это шестьсот мегабайт; добавили картинку и средний размер стал сто двадцать — тот же план упёрся в предел на половине. Ни отказа, ни бонуса при этом не будет: отправка просто растянется, и понять, почему она не укладывается в окно, по числу писем нельзя.
Что делает Хаб. Не пишет — ни в адресе, ни в пуле; остаётся вендорское unlimited.

Суточную норму прогрева Хаб держит своим планировщиком и считает её в письмах, а не в байтах: план знает, сколько писем отдать сегодня, умеет остановиться по доле спама и подменить адрес из резервного пула. Байтовый потолок такого не умеет — он просто придержит передачу, ничего не сообщив плану. Поэтому норма живёт наверху, а MTA достаётся темп очереди — max-msg-rate в блоке <domain> внутри адреса.

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

Ставить, когда узкое место — канал, а не приёмник. Байтовый потолок к месту там, где узел делит полосу с чем-то ещё или где провайдер считает трафик. Для доставляемости он почти бесполезен: приёмники смотрят на письма и жалобы, а не на мегабайты.

Пересчитывать при смене шаблонов. Значение привязано к среднему размеру письма, и правка вёрстки меняет его молча. Разумнее брать запас в полтора-два раза к расчётному объёму, чем подгонять число вплотную.

Не путать с суточной нормой. Байты в час не заменяют плана «столько-то писем в сутки»: предел растягивает отправку, но не знает, сколько писем осталось, и не остановит рассылку, если приёмник начал жаловаться.

Про 0. Синтаксис допускает его отдельным значением, но что он делает, руководство не поясняет. По грамматике это нулевой объём, то есть остановка отправки с адреса; проверять — на стенде.

Порядок расчёта и советы по запасу — наши. Из руководства здесь грамматика значения с единицами, умолчание unlimited и то, что в счёт идёт только объём успешных доставок.
Пример в конфигурации
# два потолка одного адреса: один в письмах, другой в байтах
<virtual-mta mta-news-1>
    smtp-source-host 1.2.3.4 news1.example.com
    max-smtp-msg-rate 3000/h
    max-smtp-data-volume-rate 6g/10h</virtual-mta>
Сработает тот, до которого дойдёт раньше. При среднем письме в шестьдесят килобайт три тысячи писем в час — это около ста восьмидесяти мегабайт, и упрётся отправка в верхнюю строку. Утяжелится письмо вчетверо — узким местом станет нижняя.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Переводят суточный план в байты один раз

§ 3.3.12.3

Чем чреватоЗначение остаётся привязанным к среднему размеру письма на день расчёта. Шаблон потяжелел — тот же план перестаёт укладываться в интервал, хотя ни план, ни конфигурация не менялись.
Как заметитьОтправка не успевает за окно, число писем прежнее, отказов приёмников нет.
Как правильноБрать запас к расчётному объёму и пересчитывать при смене вёрстки. Норму в письмах держать там, где она и живёт, — в плане, а не в байтовом потолке.

Считают, что предел ограничивает трафик узла

§ 3.3.12.3

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

Задают потолок в пуле и считают его общим

§ 3.3.13

Чем чреватоПул раздаёт значение каждому участнику, а не делит между ними. Пул из пяти адресов при 6g/10h выпускает до тридцати гигабайт, и добавление шестого адреса поднимает потолок до тридцати шести, хотя конфигурацию не трогали.
Как заметитьСуммарный объём с группы адресов кратен числу участников и растёт при каждом её пополнении.
Как правильноДелить задуманный объём группы на число адресов, либо задавать потолок у каждого адреса отдельно.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-smtp-data-volume-rate <rate>
Значения
unlimited · 0 · N с единицей b|k|m|g|t и знаменателем /[X] и d|h|m|s — например 6g/10h или 12M/m
Умолчание
unlimited § 3.3.12.3
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<virtual-mta>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Свой потолок адреса перекрывает пуловый, пуловый — заданный выше. Пул раздаёт значение каждому участнику как его собственное, а не делит между ними: 6g/10h в пуле из пяти адресов — это тридцать гигабайт с пула. Подхватывается по pmta reload, перезапуск сервиса не нужен.
Как проверить на узле
Действующее значение — уже после слияния с пулом — печатает команда настроек адреса:
pmta show vmta-settings mta-news-1
Строка max-smtp-data-volume-rate идёт там рядом с max-smtp-msg-rate и max-smtp-out — три потолка одного адреса видно сразу. В настройках очереди (pmta show settings) этой строки нет: она принадлежит адресу, а не очереди.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Прогрев адресов · Настроить темп под провайдера