Knowledge base
body-pattern-file
<email-patterns>
Major mailbox providers send bounces and complaints in standard formats, and the engine parses them itself. Some do not. The line sets a file with a pattern by which accounting fields are pulled out of the body of such a message. The line is repeatable: there can be several files.
The pattern is a regular expression with named groups, and the group name is the accounting field name. The manual’s example: Email from (?<dlvSourceIp>[0-9\.]+) — the sending address is pulled out of a line of the message, the very one the message once went out from.
What is extracted goes into accounting — into the complaint or bounce record, next to the fields the engine found itself. That is, a non-standard report becomes indistinguishable from a standard one in analytics.
The block is nested in a processor. <email-patterns> is written inside <bounce-processor> or <feedback-loop-processor> — and each has its own set of patterns.
With several files, the order and the match are visible only through log-match-info: without it, it is unclear which pattern fired, and that determines what exactly was extracted.
🔎 The line will be needed when a receiver turns up whose complaints do not reach the dashboard: its spam rate will be understated, and there will be nothing to explain it. The sign is that messages to fbl@fbl.<domain> arrive, while there are no complaint records for this receiver in accounting.
A file per format, not per receiver:
| What | Note |
|---|---|
| file format | one regular expression |
| group names | equal to accounting field names |
| how many files | as many as formats, the line is repeatable |
| where the block goes | inside a processor, not at the root of the file |
Test the pattern on several messages, not on one.
# the block is nested in a processor, not written at the root of the file <feedback-loop-processor> <email-patterns> body-pattern-file /etc/pmta/report-pattern.txt log-match-info true </email-patterns> </feedback-loop-processor> # the file holds one regular expression with a named group: # Email from (?<dlvSourceIp>[0-9\.]+)
▲
Common mistakes and problems
what people get wrong and how it ends2 mistakes▶
Taking a pattern from one message
our experience
Writing the pattern block at the root of the file
§ 13.10
- Syntax
- body-pattern-file <path>
- Values
- a path to a file with a regular expression
- Applying
- reload, no restart needed
- Queue
- will not touch what is already queued
- Where to write it
- <email-patterns>
- How many times
- may be repeated
Related directives
2 relations
grep -i "pattern" /var/log/pmta/log | tail -20
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.◇What to do with an accepted messageWhat the node does with an accepted inbound message: forwards it, writes it to a file, discards it, passes it to a program or parses it as a bounce or complaint.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.
- Cost of a mistake
- reversible: harms only while it is set
- Scenarios
- Bounce classification · Receiving inbound mail