Demo
Demo

Knowledge base

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

check-arc-inbound

<source>

Whether to verify the forwarding seal on messages submitted to us
in the configuration this is a linecheck-arc-inbound falseinside the block <source>
What to trust when the regular signature is broken by forwarding

Enables checking ARC headers on incoming messages. If a message carries them, the node verifies the seal chain and writes the result into the common checks header.

What for. Forwarding breaks the regular signature: a mailing list added a tag to the subject, a gateway appended a footer. The regular check fails for such a message, although nothing bad happened. The seal chain provides a second source: each forwarder attested what the message looked like when it arrived and what the checks at its entry showed.

As with the signature check, there are no refusals. Only observation.

The main trap is that trust in the chain comes down to trust in the forwarder. A seal only confirms that the forwarder said this. If the forwarder is not trustworthy, the chain is formally valid and useless. You need to check not only its integrity but also who took part in it.
What the Hub does. It does not write it: nodes accept mail only from the Hub itself. The line will be needed together with check-dkim-inbound if a node starts accepting mail from outside.
Recommended values

It is safe to enable and makes sense together with the signature check. Separately, each answers half the question.

Look at the chain’s makeup, not only its integrity. A valid chain from an unknown forwarder is not an argument.

There are no refusals. As with the signature check, the engine only records the result.

The caveat about trust in the chain’s participants is ours. From the manual here come the default, the addition of a header with the result and the condition “if the message has seal headers.”
Example configuration
# both checks together: the regular signature and the seal chain
<source 0/0>
    check-dkim-inbound true
    check-arc-inbound true</source>
A forwarded message often fails the first check and passes the second — the chain was designed exactly for this case.
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▶

Trusting the chain without looking at its participants

our experience

What it costsA seal only confirms that the forwarder said this. A chain from an unknown node is formally valid and means nothing.
How to spot itThe processor takes any intact chain as confirmation.
How to do it rightTake into account who exactly sealed, not only whether the chain is consistent.

Enabling it without the regular signature check

our experience

What it costsThe seal chain answers the question “what happened to the message before me,” not “is it signed by the sender.” Separately, each check gives half the picture.
How to spot itOnly one of the two is enabled.
How to do it rightEnable both.
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-arc-inbound <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.18
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. This check has no paired refusal lines. It is picked up by pmta reload.
⇄

Related directives

2 relations

Works together with

Two inbound report processors and what to do with themThe check result goes to the processor together with the message — the engine cannot reject a message here. § 3.3.7.18

Often used with

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

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 check-arc-inbound /etc/pmta/config
grep -i 'Authentication-Results' /var/log/pmta/pmta.log | tail -3
For messages without seal headers the check is not performed — and they are the majority: only forwarders add a chain. 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.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Receiving inbound mail · Node security
Neighboring settings of the block <source>:reject-spf-check-permerrorcheck-spf-inboundreject-spf-check-failreject-spf-check-temperrorprocess-x-dkim-optionsAll 74 directives of the block →