log-match-info

<email-patterns>

Записывать ли, какое правило распознало отчёт
в конфигурации это строкаlog-match-infoвнутри блока <email-patterns>
Какой образец сработал

Строка добавляет в журнал сведения о том, какой образец распознал отчёт или жалобу. Умолчание — выключено.

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

Запись короткая и говорящая: имя файла с образцом, который совпал.

Это диагностический переключатель: включают, когда добавляют или правят образцы, и выключают после.

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

Строка пригодится, если у клиента появится свой набор образцов под нестандартные отчёты приёмника.

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

Включают на время разбора и выключают после:

Значение Когда
no (умолчание) обычная работа
yes настраиваем или правим набор образцов и надо понять, какой сработал
Умолчание и предмет записи — из руководства (§ 3.3.6.2). Порядок разбора и предупреждение про объём — наши.
Пример в конфигурации
# на время разбора
<email-patterns …>
    log-match-info true</email-patterns>
После разбора строку убирают. При правках через Хаб она и так исчезнет при следующем применении конфигурации.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Правят образцы вслепую при нескольких файлах

наш опыт

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

Ищут эти записи в файле учёта

наш опыт

Чем чреватоЖурнал и учёт — разные файлы и разные вопросы. В учёте есть результат по письму, но не ход работы узла.
Как заметитьВ файле учёта нет ничего похожего на ожидаемые записи.
Как правильноСмотреть журнал, путь к которому задан строкой log-file.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
log-match-info <boolean>
Значения
yes | no | true | false
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<email-patterns>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <email-patterns> и касается только его. Журнал при этом один на узел — записи всех включённых переключателей ложатся вперемешку.
Как проверить на узле
Смотрим журнал MTA, отобрав нужные строки:
grep -i "pattern" /var/log/pmta/log | tail -20
В строке будет путь к файлу совпавшего образца. Пусто означает, что не совпал ни один и письмо ушло в нераспознанные.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Классификация отказов