Demo
Demo

Knowledge base

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

reject-iprev-check-temperror

<source>

Whether to reject a message when the reverse check failed to run
in the configuration this is a linereject-iprev-check-temperror falseinside the block <source>
Usually your own resolver is to blame

A temporary error means the reverse record query could not be performed: the resolver did not respond, or the address block’s name server is unavailable. The default is to let it through.

As in the SPF family, the cause is more often on your side. A reverse query is the same kind of DNS query, and when the node’s own resolver responds intermittently, this outcome appears regardless of the sender.

There is one difference from SPF, but a substantial one: there the default rejects, here it lets through. An enabled check does not break acceptance by itself.

The main trap is that by enabling rejection you tie mail acceptance to the health of your resolver. While the default is in place, its hiccups do not interfere with accepting messages at all. Enabled rejection turns every such hiccup into rejected messages — for a reason unrelated to the sender.
What the Hub does. It does not write it: inbound checking is not enabled. The vendor default is right: there is no reason to tie mail acceptance to resolver availability.
Recommended values

Keep the default. A rejection here punishes the sender for your malfunction.

If you enable it anyway, fix the resolver first. Stable name resolution must be a precondition, not a consequence.

The rejection is temporary. The message is not lost — the sender will retry; but the load on acceptance will grow.

Pointing to the resolver as the cause is ours. From the manual here come the default and the example cause: a DNS query could not be performed.
Example configuration
# the default is kept deliberately: resolver hiccups must not break acceptance
<source 0/0>
    check-iprev-inbound true
    reject-iprev-check-temperror false</source>
The line is written explicitly as a reminder: once enabled, it ties mail acceptance to the health of your own name resolution.
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▶

Enabling it with an unstable resolver

our experience

What it costsEvery name resolution hiccup turns into rejected messages. Senders retry, the load on acceptance grows, and the cause is inside your node.
How to spot itBursts of rejections coincide with resolver delays.
How to do it rightRestore the default or make name resolution stable first.
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-temperror <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.27
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.27

How to check on the node
The value is set in the source configuration; the resolver’s stability is checked separately:
grep -n reject-iprev-check-temperror /etc/pmta/config
dig +short -x 198.51.100.10
If the second command does not always respond, do not enable rejection on a temporary error. 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-permerrorcheck-iprev-inboundcheck-spf-inbound-max-void-lookupsreject-iprev-check-failprocess-x-dkim-keyAll 74 directives of the block →