Demo
Demo
База знаний PMTA›Блок <email-patterns>›Директива§ 3.3.6.1

body-pattern-file

<email-patterns>

Файл с образцом для разбора нестандартного отчёта
в конфигурации это строкаbody-pattern-fileвнутри блока <email-patterns>
Когда приёмник шлёт отчёт по-своему

Крупные почтовики отдают отказы и жалобы в стандартных форматах, и MTA разбирает их сам. Некоторые — нет. Строка задаёт файл с образцом, по которому из тела такого письма вытаскиваются поля учёта. Строка повторяется: файлов может быть несколько.

Образец — регулярное выражение с именованными группами, и имя группы это имя поля учёта. Пример руководства: Email from (?<dlvSourceIp>[0-9\.]+) — из строки письма достаётся адрес отправки, тот самый, с которого письмо когда-то ушло.

Извлечённое попадает в учёт — в запись жалобы или отказа, рядом с полями, которые MTA нашёл сам. То есть нестандартный отчёт становится в аналитике неотличим от стандартного.

Блок вкладывается в обработчик. <email-patterns> пишется внутри <bounce-processor> или <feedback-loop-processor> — и у каждого свой набор образцов.

При нескольких файлах порядок и совпадение видны только через log-match-info: без него непонятно, какой образец сработал, а от этого зависит, что именно извлеклось.

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

🔎 Строка понадобится, когда обнаружится приёмник, чьи жалобы до панели не доходят: доля спама по нему будет занижена, и объяснить это будет нечем. Признак — письма на fbl@fbl.<домен> приходят, а записей жалоб по этому приёмнику в учёте нет.

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

Файл на формат, а не на приёмник:

Что Замечание
формат файла одно регулярное выражение
имена групп равны именам полей учёта
сколько файлов сколько форматов, строка повторяется
где лежит блок внутри обработчика, не в корне файла

Проверять образец надо на нескольких письмах, а не на одном.

Формат образца, именованные группы как имена полей учёта и повторяемость строки — из руководства (§ 3.3.6.1, § 13.10). Совет проверять на нескольких письмах — наш.
Пример в конфигурации
# блок вкладывается в обработчик, а не пишется в корне файла
<feedback-loop-processor>
    <email-patterns>
        body-pattern-file /etc/pmta/report-pattern.txt        log-match-info true
    </email-patterns>
</feedback-loop-processor>

# в файле — одно регулярное выражение с именованной группой:
#     Email from (?<dlvSourceIp>[0-9\.]+)
Имя группы dlvSourceIp — это имя поля учёта. Извлечённое значение ляжет в запись жалобы рядом с тем, что MTA нашёл сам.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Снимают образец с одного письма

наш опыт

Чем чреватоОтчёты того же приёмника отличаются мелочами. Образец перестаёт совпадать на следующем письме, и жалобы этого приёмника пропадают из статистики.
Как заметитьЖалобы по приёмнику были и вдруг кончились.
Как правильноСобрать несколько писем и проверить образец на всех; включить log-match-info на время настройки.

Пишут блок образцов в корне файла

§ 13.10

Чем чреватоБлок вкладывается в обработчик. Написанный в корне, он не относится ни к отказам, ни к жалобам, и образцы не применяются.
Как заметитьОбразец задан, в журнале совпадений нет.
Как правильноПеренести блок внутрь <bounce-processor> или <feedback-loop-processor>.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
body-pattern-file <path>
Значения
путь к файлу с регулярным выражением
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<email-patterns>
Сколько раз
можно повторять
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри <email-patterns>, а тот — внутри обработчика. У обработчика отказов и у обработчика жалоб наборы образцов свои, и общего между ними нет.
⇄

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

2 связи

Зависит от

Четыре типа значений, на которых написан весь конфигЗначение — регулярное выражение, и правила диалекта общие с остальной конфигурацией. § 3.2

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

Два обработчика входящих отчётов и что с ними делатьОбразцы подключаются внутрь одного из двух обработчиков. § 3.3.6.1

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

log-match-info<email-patterns>Именно эти файлы и различает запись: в журнале видно, какой из них совпал. § 3.3.6.2

Как проверить на узле
Проверять надо по журналу — какой образец совпал, показывает соседняя строка:
grep -i "pattern" /var/log/pmta/log | tail -20
Строка вида matched body-pattern defined in file:… называет сработавший файл. Пусто означает, что не совпал ни один образец и письмо ушло в нераспознанные.
◇

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

3 статьи

◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Что делать с принятым письмомЧто узел делает с принятым входящим письмом: пересылает, кладёт в файл, гасит, передаёт программе или разбирает как отказ или жалобу.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Приём входящей почты
Соседние настройки блока <email-patterns>:log-match-infoВсе 2 директив блока →