include

<domain>

Подключить файл настроек внутри блока получателя
в конфигурации это строкаincludeвнутри блока <domain>
То же имя ещё 4:<domain>Global<smtp-pattern-list><source><virtual-mta>— часть из них другие настройки, часть та же самая
Правила приёмника — отдельным файлом

Форма и правила те же: путь, маска или адрес HTTP. Строки читаются как правила этого получателя.

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

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

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

Три формы значения, как и на уровне узла:

Значение Когда
путь к файлу правила приёмников вынесены из основного файла
маска по файлу на приёмника, одной строкой
адрес HTTP правила раздаются централизованно

Взвесить стоит одно: удобство раздачи против того, что правила перестают читаться из конфигурации глазами.

Формы значения и требования к адресу — из руководства (§ 3.3.10.104). Замечание про читаемость — наше.
Пример в конфигурации
# правила приёмника вынесены и раздаются централизованно
<domain yahoo.com>
    include /etc/pmta/yahoo-limits.txt    include https://mylocalhost.com:4000/domain/yahoo-limits.txt
</domain>
Пример руководства. Обе строки действуют; итоговое значение соберётся по обычным правилам слияния блоков получателя, и увидеть его можно только на самом узле.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ищут значение в конфигурации, а оно в подключённом файле

наш опыт

Чем чреватоСтрока подключения не показывает, что принесла. Разбор идёт по основному файлу и не находит ничего, хотя правило действует.
Как заметить«В конфигурации такого нет», а узел ведёт себя так, будто есть.
Как правильноСмотреть на узел — pmta show queues показывает результат слияния, а не исходники.

Кладут в файл директивы не уровня получателя

§ 3.3.10.104

Чем чреватоПодстановка позиционная: строки читаются как содержимое блока <domain>. Директива другого контекста станет ошибкой разбора.
Как заметитьКонфигурация не применяется, ошибка указывает внутрь подключённого файла.
Как правильноДержать в таких файлах только правила приёмников.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
include <path-or-url>
Значения
путь к файлу, маска или абсолютный адрес http/https без userinfo, строки запроса и якоря
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
можно повторять
Всё здесь — из руководства, с разделом.
Наследование
Наследования у самой строки нет: это подстановка. Подключённые правила дальше наследуются как обычные директивы <domain> — сливаются от общего к частному, и побеждает самое точное совпадение по имени получателя.
⇄

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

1 связь

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