Demo
Demo

Knowledge base

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

arc-headers-canon

<domain>

How headers are canonicalized before the forwarding attestation
in the configuration this is a linearc-headers-canon relaxedinside the block <domain>
Another line with no choice

The counterpart of dkim-headers-canon, but there is one value here — relaxed, which is also the default. The manual says plainly: other methods are not supported.

The meaning of the method itself is the same: headers are brought to a common form before attestation and before verification, so reformatting in transit — line wrapping, extra spaces, the case of names — does not break the attestation.

For the body the choice remains — it is controlled by arc-body-canon, and there are two values there.

The main trap is carrying simple over from the ordinary signature. For dkim-headers-canon this value is allowed, here it is not. A line with an invalid value is a reason for the node to refuse to parse the configuration, and the reason is named in an unobvious way.
What the Hub does. It does not write it — and there is nothing to write: the value is the only one and matches the default.
Recommended values

Do not set it. The default is the only allowed method.

Do not copy the line from the ordinary signature. Both values are allowed there, only one here.

Tolerance to reformatting is exactly what is needed here. A forwarded message passes through more nodes than your own.

The advice not to set it and the remark about the number of nodes on the path are ours. From the manual come the only supported method and the default.
Example configuration
# no choice for headers, there is one for the body
<domain *>
    arc-sign yes
    arc-headers-canon relaxed    arc-body-canon relaxed
</domain>
The first line can be removed without consequences, the second is a real setting: the body has two values.
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▶

Carrying simple over from the ordinary signature

§ 3.3.10.33

What it costsThe forwarding attestation has no such value. A line with an invalid value interferes with parsing the configuration, and the reason is named in an unobvious way.
How to spot itThe node does not accept the configuration after the ordinary signature block was copied.
How to do it rightRemove the line or keep the only allowed value.
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-canon <enumeration>
Values
relaxed — the only supported method
Default
relaxed § 3.3.10.33
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. It is picked up by pmta reload; with a single allowed value, inheritance affects nothing.
⇄

Related directives

2 relations

Does not work without

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

Same name in other blocks

dkim-headers-canon<domain>The same setting for the ordinary signature — two methods there, one here. § 3.3.10.33

How to check on the node
The value is printed by the queue settings command — it is always the same:
pmta show settings gmail.com/vmta1 | grep -i arc-headers-canon
There cannot be another value in the output. 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 →