Demo
Demo
База знаний PMTA›Блок <pattern-list>›Директива§ 3.3.14.1

header

<pattern-list>

Правило по названному заголовку письма, выбирающее поток или приоритет
в конфигурации это строкаheaderвнутри блока <pattern-list>
Выбор потока по любому заголовку письма

Единственное правило списка с параметром: сначала имя заголовка, потом образец, потом результат. Сверять можно любой заголовок — служебный вроде x-eval или обычный вроде subject и from.

Сверяется всё содержимое заголовка целиком — вместе с пробелами, табуляциями и переносами строк, которые в нём остались. Руководство делает на этом отдельный акцент: если закрепляете образец знаками ^ и $, оставьте место для пробелов — метасимвол \s для этого и нужен.

Заголовок From — не обратный адрес. Правило по from сверяет то, что видит получатель, и отправитель волен написать там что угодно. Для надёжной маршрутизации берут конверт, а не заголовок.

Главная ловушка — пробел после двоеточия. Заголовок приезжает как value, с ведущим пробелом, и образец /^value$/ не совпадёт никогда. Правильная форма — /^\s*value\s*$/. Ошибка тихая: правило выглядит верным и просто не срабатывает.
Что делает Хаб. Не пишет. Своя подача называет поток заголовком X-Virtual-MTA — это отдельный механизм, стоящий на лестнице выше и не требующий списка. Правило по заголовку остаётся для платформы, которая служебных заголовков не умеет, но проставляет свой опознавательный: тогда он и становится ключом маршрутизации.
Рекомендуемые значения

Что сверять и чем это чревато:

Заголовок Годится Оговорка
собственный служебный платформы да самый устойчивый вариант
subject иногда меняется от кампании к кампании
from с осторожностью это не конверт: отправитель пишет туда что хочет

Обязательная привычка — допускать пробелы вокруг значения: /^\s*образец\s*$/. Содержимое заголовка приходит как есть, вместе с пробелами после двоеточия и переносами внутри длинных значений.

Требование учитывать пробелы и метасимвол \s — из руководства, отдельным предупреждением. Таблица «что сверять» — наша.
Пример в конфигурации
# опознавательный заголовок платформы как ключ маршрутизации
<pattern-list partner-selector>
    header x-platform /^\s*partner-crm\s*$/ virtual-mta=partner-crm    mail-from /@partner\.example\.com$/ virtual-mta=partner-crm
</pattern-list>
Пробелы вокруг значения допущены намеренно: заголовок приходит с ведущим пробелом после двоеточия. Второе правило — страховка на случай, если платформа перестанет ставить свой заголовок.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Закрепляют образец якорями без допуска на пробелы

§ 3.3.14.1

Чем чреватоСодержимое заголовка приходит вместе с пробелами после двоеточия. Образец /^value$/ не совпадёт ни разу, и правило будет молча пропускаться.
Как заметитьПравило в конфигурации есть, заголовок в письме есть, поток берётся из умолчания.
Как правильноПисать /^\s*value\s*$/. Руководство приводит это как отдельное требование к правилам по заголовку.

Маршрутизируют по заголовку From

§ 3.3.14.2

Чем чреватоЗаголовок From — это то, что видит получатель, и отправитель заполняет его сам. Маршрут, построенный на нём, меняется вместе с оформлением письма и не защищён ничем.
Как заметитьПосле смены оформления рассылки письма начинают уходить другим потоком.
Как правильноМаршрутизировать по обратному адресу конверта — он задаётся при подаче и виден в учёте в поле orig.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
header <regex-rule>
Значения
имя заголовка, образец в косых чертах и результат — virtual-mta=имя, recipient-priority=N или call-to:имя
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<pattern-list>
Сколько раз
можно повторять
Всё здесь — из руководства, с разделом.
Наследование
Наследования у правила нет: оно действует внутри своего блока <pattern-list>. Наследуется ссылка на список — pattern-list записана в <source> и сливается по правилу источников, причём узкий блок заменяет список целиком.
⇄

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

2 связи

Без чего не работает

pattern-list<source>Правило работает только если список подключён к источнику, а список объявлен в файле выше него. § 3.3.7.42

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

Выбор адреса отправки по содержимому письмаОдин из трёх видов правил: сверяются обратный адрес, получатель или заголовок. § 3.3.14.1

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

Диалект регулярных выраженийДиректива, которой этот механизм и включается. § 3.3.14

Как проверить на узле
Заголовки в учёт не пишутся, поэтому проверять приходится по результату — какой поток выбран:
pmtaacctfind --output csv[vmta,orig,jobId] /var/log/pmta/acct-*.csv | head -30
Если поток стоит из умолчания, а заголовок в письме есть, причина почти всегда в пробелах: закреплённый якорями образец без \s не совпадает с реальным содержимым заголовка.
◇

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

3 статьи

◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.◇Выбор адреса отправки по содержимому письмаРегулярные выражения сопоставляются с заголовком, обратным адресом или получателем и выбирают адрес отправки либо назначают приоритет; списки умеют вызывать друг друга.◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки · Подключить платформу отправки
Соседние настройки блока <pattern-list>:mail-fromrcpt-toВсе 3 директив блока →