Demo
Demo

Knowledge base

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

check-iprev-inbound

<source>

Whether to check that the submitter's address matches its name
in the configuration this is a linecheck-iprev-inbound falseinside the block <source>
Whether what it introduced itself as matches where it came from

The check is simple and old: for the address the connection came from, its reverse record in DNS is taken and compared with the name the submitter introduced itself with in the greeting. The result goes into the same header as the results of the other entry checks.

How it differs from SPF. SPF asks the sender’s domain whether sending from this address is allowed — that is, it relies on someone else’s record, which the domain owner maintains. This one relies on the address record maintained by the address owner — and speaks not about the right to send but about how carefully things are set up.

The defaults of the three refusals here are the opposite of the SPF family. There all three reject, here all three let messages through. Enabling the check by itself rejects nothing.

The main trap is taking a missing reverse record for a forgery. Plenty of legitimate senders do not have one: cloud machines, hosts behind address translation, small mail servers. The check speaks of carefulness, not of the right to send, and rejecting by it means rejecting on circumstantial evidence.
What the Hub does. It does not write it: nodes accept mail only from the Hub itself. On the other hand, the Hub checks the reverse record from the other side — for its own sending addresses, because receivers perform exactly this check and treat an address without a record worse.
Recommended values

It is safe to enable. Unlike SPF, the refusal defaults here let messages through: at first the check only observes.

The result is a marker, not a verdict. Its place is in the overall assessment of the message along with the others, not in the “accept or not” decision.

Enable the trace separately and temporarily — trace-iprev-check.

The “marker versus verdict” distinction is ours. From the manual here come the default, the composition of the check (the address and the greeting name) and the defaults of the three refusal lines.
Example configuration
# we check and record the result; refusals are not enabled
<source 0/0>
    check-iprev-inbound true</source>
The three refusal lines are not needed here: their defaults let the message through. This is the opposite of the SPF family, where enabling the check immediately enables refusals.
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▶

Taking a missing record as a sign of forgery

our experience

What it costsPlenty of legitimate senders have no reverse record — in clouds, behind address translation, small servers. Refusing on this marker cuts them off along with the forgeries.
How to spot itMessages are rejected from senders whose mail passes at other recipients.
How to do it rightKeep the result as a marker in the overall assessment, not as a reason to refuse.

Carrying refusal settings over from the SPF family

our experience

What it costsThe defaults are opposite: there the three lines reject, here they let messages through. By copying the SPF block and changing the names, you enable refusals where the vendor deliberately turned them off.
How to spot itThe three reject-iprev-* lines are set to “reject.”
How to do it rightRestore the defaults and enable refusals deliberately, one at a time.
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
check-iprev-inbound <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.25
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 through a matching source; with several matching blocks the most precise one wins. It is picked up by pmta reload; it does not affect open connections.
⇄

Related directives

2 relations

Affects

reject-iprev-check-fail<source>What to do on a mismatch; by default — let the message through. § 3.3.7.29

Often used with

check-spf-inbound<source>A neighboring check of incoming mail: its result goes into the same header. § 3.3.7.25

Referenced from

trace-iprev-check<source>The line does not fire until the reverse check is enabled. § 3.3.7.26reject-iprev-check-temperror<source>The line does not fire until the reverse check is enabled. § 3.3.7.27reject-iprev-check-permerror<source>The line does not fire until the reverse check is enabled. § 3.3.7.28

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, and the record itself can be looked up directly:
grep -n check-iprev-inbound /etc/pmta/config
dig +short -x 198.51.100.10
The second command shows the address’s reverse record — the thing the node compares the greeting name with. 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
reversible: harms only while it is set
Scenarios
Receiving inbound mail
Neighboring settings of the block <source>:reject-iprev-check-temperrorcheck-spf-inbound-max-void-lookupsreject-iprev-check-failreject-iprev-check-permerrorprocess-x-dkim-keyAll 74 directives of the block →