The block contains patterns by which the engine parses the bodies of non-standard reports. It has two lines: body-pattern-file — the pattern file itself, repeatable; log-match-info — show in the log which of them matched.
The block is nested in a processor, not written at the root of the file. The bounce processor and the complaint processor have their own sets of patterns.
The extracted fields go into accounting and are placed in the record next to what the engine found itself. For analytics a non-standard report then becomes indistinguishable from a standard one.
# each processor has its own set of patterns <feedback-loop-processor> <email-patterns> body-pattern-file /etc/pmta/spamcop.txt body-pattern-file /etc/pmta/other-isp.txt log-match-info true </email-patterns> </feedback-loop-processor>
3 articles
◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.