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

Поток выбирается сопоставлением конверта или заголовка

pattern-based selection
Правила на узле вместо договорённости с отправителем

Самый выразительный из шести способов и единственный, которому не нужно согласие отправителя. Список правил объявляется один раз блоком <pattern-list> и подключается к источнику директивой pattern-list. Внутри списка правила сверяют обратный адрес конверта (mail-from), адрес получателя (rcpt-to) или произвольный заголовок (header) — и каждое называет поток или пул.

Порядок важен и оговорён: побеждает первое совпадение. Значит, список — не набор независимых правил, а приоритетная очередь. Самые вероятные образцы ставят первыми, а правило, дописанное в конец, может не сработать никогда.

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

Условные правила разрешены. Правило может открывать вложенный список — «обратный адрес такой И получатель такой» — со звёздочкой в роли «всё остальное». Отдельный приём — call-to:, переход к другому именованному списку.

Диалект — регулярные выражения Perl (PCRE), и по умолчанию они нечувствительны к регистру. Вернуть чувствительность можно модификатором (?-i) внутри образца.

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

Порядок правил у Хаба ровный: по одному на домен, пересечений нет, поэтому «первое совпадение» здесь не создаёт неожиданностей. Правил по получателю Хаб не пишет — именно из-за поведения при нескольких адресатах.

Обратный адрес Хаб переписывает на bounce@bounce.<домен> ради приёма отказов, но правила сверяют исходный: проверено на узле 15.09.2026 — письма общим логином без X-Virtual-MTA ушли потоками своих доменов, а в учёте у них стоял уже переписанный адрес.

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

Собственных значений у механизма нет: значения — это сами правила. Что стоит помнить, составляя список:

Что сверять Когда брать Чем рискуете
обратный адрес почти всегда: он стабилен и принадлежит вам ничем
заголовок когда отправителя различает только он заголовок легко поменять на стороне отправителя
получателя только письма с одним адресатом при нескольких получателях поток берётся по первому совпадению

Правило может задавать не только поток, но и приоритет получателя (recipient-priority=N, шкала 0–100, умолчание 50) — отдельно или вместе с потоком.

Из руководства здесь три вида правил, «первое совпадение», диалект PCRE и оговорка про нескольких получателей. Таблица «когда что брать» — наша.
Пример в конфигурации
# порядок руководства: список объявлен выше источника, который на него ссылается
<pattern-list mta-hub-senders>
    mail-from /@shop\.example\.com$/ virtual-mta=shop-example-com    mail-from /@news\.example\.com$/ virtual-mta=news-example-com
</pattern-list>

<source {pmta-auth}>
    pattern-list mta-hub-senders
    default-virtual-mta mta-hub-pool
</source>
Так рабочую конфигурацию собирает Хаб. Письмо с обратным адресом в домене магазина уйдёт своим потоком; всё, что не подошло, достанется пулу из последней строки. Руководство требует ставить список выше источника; MTA 6.0 разрешает и ссылку вперёд, но порядок руководства надёжнее на любой версии.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Сверяют получателя в рассылке

§ 3.3.14.3

Чем чреватоПри нескольких получателях в письме поток первого совпадения применяется ко всем — включая тех, кто под правило не подходил. Часть рассылки уходит чужим адресом, и по учёту это выглядит как ошибка маршрутизации без причины.
Как заметитьУ получателей одного домена в учёте стоит поток, назначенный совсем другому домену.
Как правильноСверять обратный адрес, а не получателя. Если разделение нужно именно по получателю — подавать по одному адресату на письмо.

Дописывают правило в конец списка

§ 9.4.2

Чем чреватоПобеждает первое совпадение, поэтому широкое правило, стоящее выше, навсегда закрывает более узкое, дописанное ниже. Новое правило есть в конфигурации и не срабатывает никогда.
Как заметитьПравило добавлено, применение прошло, поведение не изменилось.
Как правильноСчитать список приоритетной очередью: узкие образцы — выше, широкие — ниже. Генератору стоит собирать список в этом порядке, а не в порядке добавления.

Ставят список ниже источника в файле

§ 3.3.7.42

Чем чреватоРуководство требует, чтобы список был объявлен до источника, который на него ссылается. MTA 6.0 ссылку вперёд разрешает (проверено на узле 15.09.2026), но это не обещано: на другой версии конфигурация может не примениться.
Как заметитьНа 6.0 — никакого. После смены версии перезагрузка не проходит, а строка ошибки указывает на источник, а не на список.
Как правильноДержать порядок «сначала списки, потом источники», как требует руководство.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у самого списка нет: правила действуют внутри своего блока. Наследуется подключение — pattern-list записан в <source> и сливается по правилу источников, более узкий блок перекрывает более широкий. Из «одного списка на источник» следует важное: узкий блок не добавляет правил к списку широкого, а заменяет список целиком.
⇄

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

2 связи

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

Выбор адреса отправки по содержимому письмаСам список правил: он объявляется отдельно и подключается к источнику по имени. § 9.4.2

Зависит от

Как узел выбирает источник и складывает его настройкиСписок действует только на тот источник, к которому подключён, и подключить к источнику можно ровно один список. § 9.4.2

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

Авторизация при доставкеСмежный механизм: они работают вместе. § 10.1.2Диалект регулярных выраженийСмежный механизм: они работают вместе. § 9.4.2

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

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

3 статьи

◇Шесть способов выбрать поток и порядок между нимиПоток письма задают переменная слияния, вызов API, заголовок, правило по образцу, слушатель и умолчание источника — руководство перечисляет их по старшинству.◇Занятые имена переменных слиянияЧасть имён переменных слияния занята MTA: свои переменные так называть нельзя.◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки · Разделение отправителей