Demo
Demo
База знаний PMTA›Механизм§ 11.16

Разные домены в одну очередь, потому что шлюз один

критично

MX rollup
Механизм, без которого лимит на провайдера не работает

Приёмник видит не домены, а свою инфраструктуру. Пять корпоративных доменов на одном Exchange, десять тысяч доменов у хостера, msn.com, live.com и hotmail.com за одним шлюзом — для него это один вход, и нагрузку он считает по нему. Узел же по умолчанию считает по домену получателя: пять доменов — пять очередей, у каждой свой темп, а на шлюз приходит их сумма.

Сведение чинит расхождение. Домены, чьи младшие записи MX совпали с настроенным списком, попадают в одну очередь, и всё, что считается «на получателя» — темп, потолок соединений, щадящий режим, метрики, — считается по ней.

Сведений два, и они не равны. Явное — блок <mx-rollup-list>, где вы сами перечисляете записи MX и имя очереди. Автоматическое — auto-mx-rollup, где узел сам группирует домены с одинаковым набором младших MX. Явное имеет приоритет: автоматическое рассматривается только там, где в списке совпадения не нашлось. Отказаться от обоих для конкретного домена можно строкой disable-mx-rollup.

Главная ловушка — тихое несовпадение. Если в списке для очереди перечислено больше младших MX, чем DNS отдаёт на самом деле, совпадения не происходит. Это не ошибка конфигурации и не запись в журнале: домен просто продолжает ехать своей очередью, а вы считаете, что он сведён, и удивляетесь, почему лимит не держит.
Что делает Хаб. Не задействует: списков сведения он не пишет, и auto-mx-rollup в его конфигурации нет. Провайдеров Хаб группирует у себя — в аналитике и в правилах политик — а очереди на узле остаются подоменными. Расхождение это осознанное: сведение меняет структуру очередей, и решать о нём должен человек.
Пример в конфигурации
# явное сведение: перечисляем младшие MX и имя очереди
<mx-rollup-list>
    mx mx1.hotmail.com hotmail.rollup
    mx mx2.hotmail.com hotmail.rollup
    mx *.mail.protection.outlook.com outlook.rollup rollup-by-ip</mx-rollup-list>

# сведённую очередь описываем отдельно — вендор советует именно так
<domain hotmail.rollup>
    max-smtp-out 20
    smtp-hosts lookup-mx:hotmail.com
</domain>
Имя очереди обязано оканчиваться на .rollup. У очереди с подстановочным знаком без пометки rollup-by-ip строка smtp-hosts обязательна: вывести записи MX для всех доменов такой очереди узел не может.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Перечисляют все записи MX, а не только младшие

§ 11.16

Чем чреватоСовпадения не будет: узел сравнивает набор младших MX, и лишняя строка в списке его отменяет. Ошибка тихая — ни отказа, ни записи в журнале, домен просто едет своей очередью.
Как заметитьОчередь .rollup создана, но получатель в неё не попадает.
Как правильноОставить в списке только записи с наименьшим приоритетом (dig +short MX и взять верхнюю группу).

Заводят очередь с подстановочным знаком без smtp-hosts

§ 11.16

Чем чреватоУзел не может вывести записи MX для всех доменов такой очереди и не знает, куда стучаться. Руководство ставит эту строку требованием, а не советом.
Как заметитьОчередь есть, письма в ней стоят, соединений нет.
Как правильноЗадать smtp-hosts в блоке сведённой очереди — либо добавить пометку rollup-by-ip, тогда узел проставит хосты сам.

Настраивают очередь rollup-by-ip по её имени из списка

§ 11.16

Чем чреватоПри группировке по адресам имена очередей узел придумывает сам и добавляет числовой префикс: q1.outlook.rollup, q2.outlook.rollup. Блок с именем outlook.rollup не подойдёт ни к одной из них, и настройки не применятся.
Как заметитьНастройки сведённой очереди игнорируются, в списке очередей имена с префиксом q и цифрой.
Как правильноОписывать такие очереди шаблоном [*].outlook.rollup.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

Связанные записи

3 связи

Конфликтует

Приёмник объявляет требование шифрования на своём сайтеСведение и политика приёмника уживаются плохо: политика привязана к домену, а очередь стала общей. § 10.6

На что влияет

Вводить новый адрес частью чужого трафикаПри включённом сведении суточная норма прогрева берётся у сведённой очереди, а не у отдельных доменов. § 11.16Очередь — это приёмник вместе с адресом отправкиМеняет то, что означает «получатель» в паре «получатель + адрес отправки»: им становится шлюз, а не домен. § 11.16

Сюда ссылаются

auto-mx-rollupGlobalМеханизм целиком, вместе с ручным списком. Ручной список имеет приоритет: автоматическое сведение рассматривается после него. § 3.3.1.52Свести домены в одну очередь вручную, назвав еёТо же сведение, выведенное из записей DNS, а не объявленное. Точнее там, где шлюзы устойчивы; надёжнее здесь, где они меняются. § 11.8.1

Как проверить на узле
Сведение видно по списку очередей: у сведённой очереди имя оканчивается на .rollup, и доменов в ней больше одного:
pmta show queues | grep -i rollup
dig +short MX example.com | sort -n | head -3
Вторая команда показывает младшие записи MX получателя — их и надо сверять со списком: лишняя строка в списке отменяет совпадение молча. Хаб сведённые очереди в телеметрии показывает как обычные.
◇

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

3 статьи

◇Ключ активации — условие установки, а не шаг после неёБез ключа активации от поддержки SparkPost MTA не ставится и не работает, а уровень лицензии задаёт потолок исходящих соединений: на стандартной всё сверх 200 игнорируется.◇Ограничения облакаОблака ограничивают исходящую почту через порт 25, пока не попросишь снять лимит, а их диапазоны адресов почтовики встречают с подозрением.◇Как перевести план отправки в железоДве постоянные, по которым считается любой узел: около 2 КБ памяти на каждого получателя в очереди и место под спул, пропорциональное суммарному размеру писем.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Планирование мощности · Настроить темп под провайдера
Важность
критично