Отчёты, которые MTA не понимает сам

non-standard report handling
Когда приёмник пишет отчёт по-своему

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

Механизм прост: своё регулярное выражение с именованными группами. Имя группы — имя поля учёта, и извлечённое ложится в запись рядом с тем, что MTA нашёл сам. Пример руководства снят с настоящего письма службы жалоб: из строки Email from 1.2.3.4 достаётся адрес отправки.

Образцы живут в <email-patterns>, вложенном в обработчик. У каждого обработчика свой набор, и файлов в нём может быть несколько — по одному на формат.

🔴 Пока образца нет, отчёт для аналитики не существует. Он не попадает ни в записи жалоб, ни в записи отказов — он просто непонятое письмо, судьбу которого решает deliver-unmatched-email. То есть доля жалоб по такому приёмнику будет занижена, и объяснить это будет нечем.

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

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

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

Собственных значений у механизма нет — его включают две строки в блоке образцов:

Что Строка
сам образец body-pattern-file, повторяется
какой из них совпал log-match-info

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

Механизм образцов, пример письма и перечень извлекаемых полей — из руководства (§ 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\.]+). Имя группы равно имени поля учёта, и туда попадёт извлечённое значение.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Принимают отсутствие жалоб за отсутствие проблем

наш опыт

Чем чреватоПриёмник, чьи отчёты MTA не понимает, даёт нулевую долю жалоб. Это выглядит как лучший результат в парке, а означает отсутствие данных.
Как заметитьУ крупного приёмника с большим объёмом доля жалоб ровно ноль.
Как правильноПосмотреть, приходят ли от него письма на адрес обработчика, и при необходимости написать образец.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет: образцы живут внутри блока, вложенного в обработчик, и относятся только к нему. У обработчика отказов и у обработчика жалоб наборы независимы.
Как проверить на узле
Проверять надо по журналу, с включённой строкой совпадений:
grep -i "pattern" /var/log/pmta/log | tail -20
Строка matched body-pattern defined in file:… называет сработавший образец. Пусто при приходящих письмах означает, что не совпал ни один и письмо ушло в нераспознанные.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Классификация отказов