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

Три правила пула, названные руководством прямо

VirtualMTA pool behaviour
Раздача, наследование и общее имя

Глава 9 добавляет к описанию пула три факта, и средний из них закрывает вопрос, который в разборе главы 3 приходилось оставлять открытым в нескольких местах.

Раздача — обычный круг по перечисленным участникам (доли задаются отдельно, строкой участника).

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

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

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

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

Что Уровень узла Пул Адрес отправки
правило одного приёмника на весь парк да — —
правила волны прогрева — да повтор у каждого
адрес, имя, ключ подписи — — да

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

Все три правила — из руководства (§ 9.3), включая формулировку про перекрытие. Таблица уровней — наша.
Пример в конфигурации
# правило приёмника задано один раз на всю группу
<virtual-mta-pool warmup-wave-3>
    <domain yahoo.com>        max-msg-rate 10/h
    </domain>
    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
Обоим участникам достанется max-msg-rate 10/h для yahoo.com. Если у mta1 есть собственный блок <domain yahoo.com> — победит он. Пример руководства с добавленным именем волны.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Повторяют общие правила у каждого участника

§ 9.3

Чем чреватоВолна прогрева из восьми адресов с одинаковыми правилами приёмников — это восемь копий одного и того же. Правки в одну из них не попадают, значения расходятся, и разница обнаруживается по поведению, а не по чтению конфигурации.
Как заметитьАдреса одной волны ведут себя по-разному у одного и того же приёмника.
Как правильноВынести общее в блок <domain> внутри пула. Участнику оставить только то, что действительно его — адрес, имя, ключ.

Называют пул именем существующего адреса отправки

§ 3.3.13

Чем чреватоВыбор идёт одними и теми же заголовками, и совпадение неразрешимо. MTA отвергает определение целиком — на применении это неудачная перезагрузка, а не предупреждение.
Как заметитьКонфигурация не применяется после добавления пула.
Как правильноДержать имена пулов и адресов отправки одним списком и проверять уникальность до записи файла.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Уровней три — узел, пул, адрес отправки, — и порядок руководство называет прямо: блок получателя внутри адреса отправки наследует сначала от пула, потом от узла. Отсюда же и запрет: участник не может состоять в двух пулах, у которых есть блоки <domain>, — источников наследования оказалось бы два.
⇄

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

3 связи

Зависит от

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

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

Как складывается политика для приёмникаБлок получателя внутри пула достаётся участникам, а собственный блок участника его перекрывает. § 9.3

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

Группа адресов отправки с долями трафикаСама конструкция, которую описывает этот раздел; здесь — три её правила, названные руководством прямо. § 9.3

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

max-smtp-data-volume-rate<virtual-mta-pool>Что пул делает с директивой — от этого и зависит арифметика числа. § 3.3.13

Как проверить на узле
Наследование по конфигурации не читается — надо смотреть, что получилось у участника:
pmta show queues yahoo.com/mta1
В очереди участника действуют слитые правила: своё поверх пулового поверх общего. Если ожидаемого значения не видно, ищите собственный блок того же получателя у самого участника — он перекрывает пуловый.
◇

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

3 статьи

◇Четыре способа сказать «медленнее»Письма, объём данных, темп подключений и число соединений — у каждого свой лимит, и у каждого есть вариант «на адрес источника» и двойник для щадящего режима.◇Очередь — это приёмник вместе с адресом отправкиMTA группирует письма по паре «домен получателя плюс адрес отправки»: один домен с двух адресов — это две независимые очереди со своими счётчиками, соединениями и режимом.◇Четыре типа значений, на которых написан весь конфигЛогическое, образец домена, регулярное выражение и промежуток времени — определены один раз в § 3.2 и дальше используются всеми директивами.

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