Demo
Demo

Knowledge base

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

arc-oversigned-headers

<domain>

Which headers should break the attestation if they are added after it
in the configuration this is a linearc-oversigned-headersinside the block <domain>
Make adding a header noticeable

A full counterpart of dkim-disallow-adding-headers for the forwarding signature. The listed names are put into the attestation one extra time, and the appearance of a second such header breaks it.

The task is the same: an ordinary attestation protects the existing headers but does not forbid adding one more. A second Subject in a message with a valid attestation is displayed by the mail client, and verification passes.

There is no default. Where the line is not set, the protection does not act.

The main trap is forgetting it when setting up forwarding. ARC was invented precisely so that the receiver would trust the forwarder; without this line the forwarder’s attestation can be supplemented with someone else’s header, and it will stay valid. That is, the trust mechanism works against what it was enabled for.
What the Hub does. It does not write it: it has no forwarding of other people’s mail. If that appears, it has to be set right away together with arc-sign, with the same set as the ordinary signature.
Recommended values

The same set as with the ordinary signature: sender, recipient, subject, reply-to address.

Set it right away together with enabling. An attestation without this line protects less than expected.

Do not list everything. Each name is added to the attestation one extra time; it only makes sense for headers the reader sees.

The starting set is ours, the same as for the ordinary signature. From the manual come the line’s purpose and the syntax.
Example configuration
# attestation and protection against added headers — together
<domain *>
    arc-sign yes
    arc-oversigned-headers from,to,subject</domain>
The names get into the attestation one extra time — the receiver sees that there should be exactly as many headers with those names as there were at signing.
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▶

Not setting it at all

our experience

What it costsThe forwarder’s attestation can be supplemented with a second Subject or From, and it will stay valid. A mechanism enabled for the sake of trust starts working against it.
How to spot itThe line is absent from the configuration while attestation is enabled.
How to do it rightSet at least from,to,subject.

Setting it for the ordinary signature and forgetting it here

our experience

What it costsThe ordinary signature is protected, the forwarding attestation is not. A receiver that trusts the chain of attestations gets an unprotected link.
How to spot itdkim-disallow-adding-headers is set, arc-oversigned-headers is not.
How to do it rightKeep both lines with the same set.
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-oversigned-headers <header-list>
Values
comma-separated header names; there is no default — without the line the protection does not apply
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. There is no default: where the line is not set, the protection does not act. 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.38

Same name in other blocks

dkim-disallow-adding-headers<domain>The same for the ordinary signature. § 3.3.10.38

How to check on the node
The effective value is printed by the queue settings command; the result is visible from repeated names in the attestation header:
pmta show settings gmail.com/vmta1 | grep -i oversigned
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
A name that appears twice in the list of signed headers is the one protected by this line. The Hub does not write it.
◇

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 →