Demo
Demo

Knowledge base

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

dkim-body-canon

<domain>

How tolerant the signature is of edits to the message body in transit
in the configuration this is a linedkim-body-canon relaxedinside the block <domain>
What counts as a change to the body

The same fork as in dkim-headers-canon, but for the message body. The default is relaxed.

Little is forgiven. For the body, relaxed tolerates spaces at the end of lines and repeated spaces within a line — exactly what mail nodes and gateways change along the way. Extra empty lines at the end of the message do not count under either value. Everything else — an added line, a changed character, a footer at the bottom — breaks the signature under any value.

A footer at the bottom is a separate matter. It can be allowed only through dkim-add-body-limit, and that is no longer about tolerance of formatting but about which part of the body the signature covers at all.

The main trap is expecting relaxed to save you from a footer. It will not. A gateway that adds a line like “scanned by antivirus” or a company signature at the bottom breaks the signature under both values. Canonicalization tolerance ends at spaces.
What the Hub does. It does not write it — the vendor relaxed stays. It is the right value: the message’s path is beyond our control, and simple gives nothing but additional verification failures.
Recommended values

Leave relaxed. The difference between the values is only in spaces, and tolerance costs nothing here.

simple — only for a controlled path. In bulk mail there is no such thing.

Canonicalization does not protect against footers. If someone else’s text appears at the bottom of messages, look at the body length limit, not here.

The distinction “spaces versus footers” is ours. From the manual here: both values and the default.
Example configuration
# the default is left deliberately
<domain *>
    dkim-headers-canon relaxed
    dkim-body-canon relaxed</domain>
In the signature this looks like c=relaxed/relaxed: first the method for headers, second for the body.
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▶

Setting simple for the sake of strictness

our experience

What it costsThe signature stops forgiving even a space at the end of a line — and ordinary mail nodes add one along the way. The failure rate grows with no benefit at all.
How to spot itVerification failures at some recipients with a correct key.
How to do it rightReturn to relaxed.

Changing canonicalization because of footers at the bottom of messages

our experience

What it costsCanonicalization tolerates only spaces and empty lines. A footer is a change to the body, and the signature breaks under any value.
How to spot itVerification failures only at recipients behind a gateway that appends its own text.
How to do it rightSolve it with the body length limit — and understand its price.
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
dkim-body-canon <enumeration>
Values
simple or relaxed
Default
relaxed § 3.3.10.22
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

1 relation

Does not work without

dkim-sign<domain>Does nothing until signing is enabled. § 3.3.10.22

Referenced from

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

How to check on the node
The effective value is printed by the queue settings command; what came out is visible in the signature’s c= field:
pmta show settings gmail.com/vmta1 | grep -i dkim-body-canon
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
In the c= field the second value is the method for the body. 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 →