Demo
Demo

Knowledge base

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

arc-body-canon

<domain>

How the message body is canonicalized before the forwarding attestation
in the configuration this is a linearc-body-canon relaxedinside the block <domain>
The only real choice in this pair

The counterpart of dkim-body-canon, and here, unlike the headers, there are two values: simple and relaxed. The default is relaxed.

The meaning is the same: relaxed tolerates spaces at the end of lines and repeated spaces within a line, simple does not; empty lines at the end of the body do not count under either.

When forwarding, tolerance matters more than in ordinary sending. A forwarded message has already passed through other people’s nodes on its way to you and will pass through several more after; it has twice as many occasions for a cosmetic edit of the body.

The main trap is the same as with the ordinary signature: people expect tolerance to save them from a footer. It will not. A mailing list that appends an unsubscribe link at the bottom breaks the attestation with both values — like any change to the body beyond spaces.
What the Hub does. It does not write it — the vendor relaxed stays, the right value for forwarding too.
Recommended values

Keep relaxed. For forwarding this is all the more right: there are more nodes on the path.

simple gives nothing except additional verification failures.

Canonicalization does not forgive footers. If the forwarder appends the footer itself, the attestation is applied after its edits — and all is well; those who edit the message after you break the attestation.

The remark about the number of nodes on the path and the order of the forwarder’s edits is ours. From the manual come both values and the default.
Example configuration
# the body has a choice; the tolerant method is the right one
<domain *>
    arc-sign yes
    arc-body-canon relaxed</domain>
The value matches the default; the line is useful as a reminder that it should not be changed.
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▶

Setting simple for the sake of strictness

our experience

What it costsThe attestation stops forgiving even a space at the end of a line, while a forwarded message passes through more nodes than your own. Verification failures become noticeably more frequent.
How to spot itAttestation verification failures for some forwarded messages.
How to do it rightReturn the tolerant method.
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-body-canon <enumeration>
Values
simple or relaxed
Default
relaxed § 3.3.10.32
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; for queued messages it applies from the next attempt.
⇄

Related directives

2 relations

Does not work without

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

Same name in other blocks

dkim-body-canon<domain>The same setting for the ordinary signature. § 3.3.10.32

How to check on the node
The value is printed by the queue settings command:
pmta show settings gmail.com/vmta1 | grep -i arc-body-canon
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
The canonicalization method is also visible in the attestation header itself. 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 →