Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.35

arc-headers

<domain>

Which headers fall under the forwarding attestation
in the configuration this is a linearc-headersinside the block <domain>
What the attestation protects

A full counterpart of dkim-headers for the forwarding signature. The mandatory set is the same — about thirty headers are always signed if present in the message — and the line adds to it.

A peculiarity of forwarding. Headers you add yourself as a forwarder — a list tag in the subject, service marks — fall under the attestation as usual: it is applied after your edits. The attestation vouches for the message as it leaves you.

The main trap is the same as with the ordinary signature: a named header missing from the message is read by the receiver as removed in transit, and verification fails. With forwarding the risk is higher: messages come from different senders, and their header sets differ.
What the Hub does. It does not write it: it has no forwarding of other people’s mail. The mandatory set would be enough there too — only the forwarder’s own service headers are worth adding.
Recommended values

Add only what you set yourself. Other senders’ headers are unpredictable, and a named missing one breaks verification.

An expression in slashes catches a whole family at once — handy for your own service headers with a common prefix.

The mandatory set cannot be narrowed, as with the ordinary signature.

The advice to add only your own headers is ours. From the manual come the mandatory set and the syntax of names and expressions.
Example configuration
# we add to the mandatory set a tag we set ourselves
<domain *>
    arc-sign yes
    arc-headers /^X-List-/</domain>
The expression will cover all of the forwarder’s own headers with this prefix; other people’s headers are not worth listing — they are not in every message.
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▶

Listing other senders' headers

our experience

What it costsWhen forwarding, messages come from different senders, and their header sets differ. A named missing one is read as removed in transit — verification fails.
How to spot itAttestation verification failures for some forwarded messages.
How to do it rightKeep in the list only headers the forwarder itself sets.

Trying to narrow the set

§ 3.3.10.35

What it costsMandatory headers are attested regardless of the value, and an empty line means “leave as is”.
How to spot itThe value is set, the list in the header is as long as before.
How to do it rightNothing: this is how the engine works.
Compatibility
PowerMTA 6.0
described in the manual of this version · linux
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
arc-headers <header-list>
Values
comma-separated header names and/or expressions in slashes; an empty string means “keep the default set”
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. The mandatory set is attested regardless of the value — the line adds to it. It is picked up by pmta reload.
⇄

Related directives

2 relations

Does not work without

arc-sign<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.35

Same name in other blocks

dkim-headers<domain>The same for the ordinary signature. § 3.3.10.35

How to check on the node
The effective value is printed by the queue settings command; what is actually attested is listed in the attestation header itself:
pmta show settings gmail.com/vmta1 | grep -i arc-headers
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
The list of attested headers is in the attestation header itself — that is the final answer. The Hub does not write this line.
◇

What else to read

3 articles

◇Do not send what will fail the check at the receiverThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇A message header with which the submitting side adjusts the signatureFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Message signing and authentication
Neighboring settings of the block <domain>:dkim-signdkim-identitycheck-spf-outbounddkim-disallow-adding-headersdkim-add-body-limitAll 135 directives of the block →