Demo
Demo

Knowledge base

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

dkim-add-body-limit

<domain>

Whether to sign only the beginning of the body, allowing appending at the bottom
in the configuration this is a linedkim-add-body-limit falseinside the block <domain>
Allow appending at the bottom at the cost of protection

By default the signature covers the whole body: any footer appended at the bottom breaks it. This line adds the length of the signed part to the signature, and everything after that length is not protected by the signature — it can be appended with no consequences.

Why people enable it. Gateways, antivirus software and corporate servers add their lines at the bottom — “scanned,” a company signature, a warning about an external sender. With a regular signature such messages arrive with a failed check.

The price is high. The signature stops vouching for the end of the message. Anyone along the way can append arbitrary text at the bottom, and the check at the recipient will still pass — the message will look authentic.

The main trap is that this is a hole, not a convenience. What can be appended is not only a “scanned by antivirus” line but also a link, a button, a whole second message. The recipient will see your domain’s signature and believe everything, including what was appended. This is exactly how messages with a valid signature are forged.
What the Hub does. It does not write it — the vendor value stays, that is, the whole body is signed. The Hub will not enable this for the convenience of individual gateways: the price is messages forged in your name that pass the check.
Recommended values

Do not enable it. It is the only line in the signing family that weakens the signature itself.

If the recipient’s gateway appends. The right answer is to negotiate with it or accept the failed check at that recipient, not to open messages for appending to everyone.

Major receivers treat such a signature worse. For some of them, a length limit in itself lowers trust in the message.

The “this is a hole, not a convenience” assessment is ours. From the manual here come the default, the signed-part length mechanics and the direct statement that content beyond it can be added without breaking the signature.
Example configuration
# DO NOT ENABLE: the signature stops vouching for the end of the message
<domain corp.example.com>
    dkim-add-body-limit true</domain>
The example is shown for completeness: the only case where this is discussed is a corporate recipient whose gateway appends a line at the bottom and who cannot be negotiated with.
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▶

Enabling it to fix the check at one recipient

our experience

What it costsEverything that goes out under this block becomes open to appending. Anyone along the way can forge a message in your name that passes the check.
How to spot itThe l= field has appeared in message signatures.
How to do it rightRemove the line; negotiate separately with the gateway that appends.

Believing the limit protects the beginning of the message

our experience

What it costsFormally yes, but the recipient sees the whole message and cannot tell the signed part from the appended one. Protecting the beginning does not prevent deception.
How to spot itThe reasoning “but at least the top is signed” in the justification for the setting.
How to do it rightSign the whole body — that is the default.
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-add-body-limit <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.19
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 merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. In the wildcard block it opens the whole mailing to appending. It is picked up by pmta reload; for queued messages it takes effect from the next attempt.
⇄

Related directives

1 relation

Does not work without

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

How to check on the node
The effective value is printed by the queue settings command; whether it is enabled is visible from the presence of the length field in the signature itself:
pmta show settings corp.example.com/vmta1 | grep -i add-body-limit
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
The l= field in the signature is the length limit: its presence means the end of the message is not protected by the signature. 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-headersdkim-disallow-adding-headersAll 135 directives of the block →