Demo
Demo

Knowledge base

PMTA knowledge base›Block <email-patterns>›Directive§ 3.3.6.2

log-match-info

<email-patterns>

Whether to log which rule recognized a report
in the configuration this is a linelog-match-infoinside the block <email-patterns>
Which pattern matched

The line adds to the log information about which pattern recognized a report or complaint. The default is off.

The line is needed exactly when there are several patterns. There can be many pattern files, and during an investigation it is unclear which of them matched — and what the engine extracted from the message depends on that.

The entry is short and telling: the name of the pattern file that matched.

This is a diagnostic switch: enabled when patterns are added or edited, and turned off afterwards.

The main trap is leaving it on after the investigation. The line breaks nothing and therefore outlives the investigation: the log grows, rotation speeds up, and last week’s entries are pushed out before they are needed.
What the Hub does. It does not write it: we do not create our own pattern sets; bounces and complaints are parsed with the built-in ones.

The line will come in handy if a client gets their own pattern set for non-standard receiver reports.

Recommended values

Enabled for the duration of an investigation and turned off afterwards:

Value When
no (default) normal operation
yes setting up or editing a pattern set and you need to understand which one matched
The default and the subject of the record come from the manual (§ 3.3.6.2). The order of investigation and the warning about volume are ours.
Example configuration
# for the duration of the investigation
<email-patterns …>
    log-match-info true</email-patterns>
After the investigation the line is removed. With edits through the Hub it will disappear anyway at the next configuration apply.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Editing patterns blindly with several files

our experience

What it costsIt is unclear which file matched, and editing one pattern changes behavior unpredictably: a completely different one may have matched.
How to spot itAfter editing one file, parsing changed for messages that were not touched.
How to do it rightEnable the line and edit while looking at what actually matches.

Looking for these entries in the accounting file

our experience

What it costsThe log and accounting are different files and different questions. Accounting has the result per message, but not the course of the node’s work.
How to spot itThere is nothing resembling the expected entries in the accounting file.
How to do it rightLook at the log whose path is set by the log-file line.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
log-match-info <boolean>
Values
yes | no | true | false
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<email-patterns>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line lives inside its own <email-patterns> and concerns only it. The log, meanwhile, is one per node — entries from all enabled switches land in it intermixed.
⇄

Related directives

2 relations

Works together with

body-pattern-file<email-patterns>These are exactly the files the entry distinguishes: the log shows which of them matched. § 3.3.6.2

Applies to

log-fileGlobalThe entries go into the very log set there. inference

How to check on the node
We look at the engine log, filtering the relevant lines:
grep -i "pattern" /var/log/pmta/log | tail -20
The line will contain the path to the file of the matched pattern. Nothing means none matched and the message went to the unrecognized ones.
◇

What else to read

3 articles

◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇A return address with the recipient written into itThe bounce arrives at a unique address, and there is no need to parse its content.◇What to return in a bounce reportWhat to enclose in a bounce report: the whole message or only its headers.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Bounce classification
Neighboring settings of the block <email-patterns>:body-pattern-fileAll 2 directives of the block →