Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.26

trace-iprev-check

<source>

Whether to put reverse check queries into the message header
in the configuration this is a linetrace-iprev-check falseinside the block <source>
A trace in the message, not in the log

Adds to the header with verification results all DNS queries made during the reverse address check. The default is not to add them.

The trace is shorter than for SPF. The reverse check makes one or two queries, not a dozen: it has no nested references. So the price of enabling it here is lower than for trace-spf-check.

But the nature is the same — the trace travels with the message. It is not written to the log: it is added to the message and reaches the recipient, the handler and the archive.

The main trap is forgetting to turn it off because it does not get in the way. Because the trace is short, the enabled line is almost invisible and lives in the configuration for years. Every accepted message meanwhile carries outward details of your name resolution.
What the Hub does. It does not write it: input verification is not enabled. Like the other debugging switches, this line belongs only in a temporary edit.
Recommended values

Only for the duration of an investigation. And with a comment saying when it was enabled.

Narrow the source. The trace will get only into messages from the specified network, not into all accepted mail.

A manual query is often enough. The reverse record is looked up with one command and adds nothing to messages.

The assessment “the trace is shorter than for SPF” is ours. From the manual come the default and the composition of the trace: all DNS queries.
Example configuration
# TEMPORARY: investigating one sender
<source 198.51.100.0/24>
    check-iprev-inbound true
    trace-iprev-check true</source>
By narrowing the source, you leave the trace only in messages from this network — the rest of the accepted mail will not carry it.
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 ends1 mistake▶

Leaving it on because it does not get in the way

our experience

What it costsThe trace is short and unnoticeable, so it lives for years. Every accepted message carries outward details of your name resolution — into other people’s mailboxes and archives.
How to spot itDNS queries are visible in the headers of accepted messages.
How to do it rightTurn it off; enable it with a comment and temporarily.
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
trace-iprev-check <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.26
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is set in a <source> block and applies to mail submitted by a matching source; with several matching blocks the most precise one wins. It fires only with check-iprev-inbound enabled. It is picked up by pmta reload.
⇄

Related directives

1 relation

Does not work without

check-iprev-inbound<source>The line does not fire until the reverse check is enabled. § 3.3.7.26

How to check on the node
The value is set in the source configuration; the result is visible in the header of the accepted message:
grep -n trace-iprev-check /etc/pmta/config
dig +short -x 198.51.100.10
The second command shows the same thing that would go into the trace — and adds nothing to messages. The Hub does not write this line.
◇

What else to read

3 articles

◇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.◇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.◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Receiving inbound mail
Neighboring settings of the block <source>:log-commandslog-tlslog-connectionstrace-dkim-checklog-dataAll 74 directives of the block →