Demo
Demo

Knowledge base

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

reject-iprev-check-permerror

<source>

Whether to reject a message when the reverse check cannot be performed
in the configuration this is a linereject-iprev-check-permerror falseinside the block <source>
An error on the address owner’s side

A permanent error means the reverse check could not be completed because of how the data is set up: the zone for the address is not delegated, the response cannot be parsed, the record is contradictory. The default is to let it through.

This is neither a sender’s fault nor a network failure. The owner of the address block simply did not finish the setup — a common thing at hosting providers and clouds, where reverse zones are filled in partially.

Like the whole family, the line works only with check-iprev-inbound enabled.

The main trap is rejecting for someone else’s administrative sloppiness. The sender does not know about it and cannot influence it: the reverse zone is managed not by them but by the owner of the address block. At most receivers their mail gets through.
What the Hub does. It does not write it: inbound checking is not enabled. The vendor default is right here anyway — this outcome says less about the message itself than the others.
Recommended values

Keep the default. Of the three outcomes of the reverse check, this one says the least about the sender.

The result will end up in the header anyway. It can be taken into account further down the chain without rejecting the message.

Reject only together with other signals. On its own it proves nothing.

The assessment “says the least about the sender” is ours. From the manual here come the default and the triggering condition.
Example configuration
# the default is kept deliberately: the sender does not manage the zone
<source 0/0>
    check-iprev-inbound true
    reject-iprev-check-permerror false</source>
The line is written explicitly so that it does not get enabled along with the others during the next edit of the block.
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▶

Rejecting on a par with a mismatch

our experience

What it costsMail is rejected from senders whose hosting providers did not finish the reverse zone. The sender has nothing to do with it and cannot influence it.
How to spot itThe rejections include addresses of major cloud providers.
How to do it rightRestore the default; take the result from the header into account.
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-permerror <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.28
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.28

How to check on the node
The value is set in the source configuration; how many such outcomes arrive is visible from the headers of accepted messages:
grep -n reject-iprev-check-permerror /etc/pmta/config
grep -ci 'iprev' /var/log/pmta/pmta.log
A noticeable share of such outcomes means not a stream of forgeries but unfilled reverse zones at hosting providers. 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-failprocess-x-dkim-keyAll 74 directives of the block →