Demo
Demo

Knowledge base

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

reject-iprev-check-fail

<source>

Whether to reject a message when the address does not match the name
in the configuration this is a linereject-iprev-check-fail falseinside the block <source>
The default here is the opposite of SPF

A mismatch means that the address’s reverse record exists but does not match the name the submitter introduced itself with — or there is no record at all. The line decides whether to reject the message for this.

The default is to let it through. The exact opposite of the same-named line in the SPF family, where the default rejects. The vendor distinguishes these cases, and the distinction makes sense: SPF expresses the will of the domain owner, while a reverse record reflects how well the address owner set things up.

The signal is weak on its own: legitimate senders have a mismatch more often than one would like.

The main trap is enabling it by copying the SPF block. The lines are named almost the same, and settings get carried over wholesale. Rejection gets enabled where the vendor deliberately turned it off — and starts cutting off cloud and corporate hosts whose reverse record is shared rather than individual.
What the Hub does. It does not write it: inbound checking is not enabled. For its own sending addresses the Hub, on the contrary, makes sure the reverse record exists: receivers perform this same check.
Recommended values

Keep the default. The signal is weak, and the price of a rejection is lost mail from legitimate senders.

Rejecting makes sense on a narrow source. If it is known that one specific machine with a configured reverse record submits from there, rejection becomes meaningful.

Never on a source covering the whole network.

The assessment of the signal as weak and the advice about a narrow source are ours. From the manual here come the default and the exact triggering condition.
Example configuration
# a known machine with a configured reverse record — rejection is appropriate
<source 198.51.100.10/32>
    check-iprev-inbound true
    reject-iprev-check-fail true</source>
The source is narrowed to one address: on a broad source this rejection cuts off legitimate senders along with forgeries.
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▶

Copying the setting from the SPF block

our experience

What it costsThe defaults are opposite, and carrying the value over enables rejection where the vendor turned it off. Cloud and corporate hosts with a shared reverse record get cut off.
How to spot itMessages are rejected from senders who get through everywhere else.
How to do it rightRestore the default.
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
reject-iprev-check-fail <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.29
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.29

How to check on the node
The value is set in the source configuration; whether the record matches for a specific address is checked directly:
grep -n reject-iprev-check /etc/pmta/config
dig +short -x 198.51.100.10
The name you get should be compared with the one the submitter uses in its greeting — that is exactly what the check does. 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-iprev-inboundcheck-spf-inbound-max-void-lookupsreject-iprev-check-permerrorprocess-x-dkim-keyAll 74 directives of the block →