Demo
Demo

Knowledge base

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

dkim-disallow-adding-headers

<domain>

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

A regular signature protects existing headers: a signed Subject cannot be changed. But a second Subject can be added — and the signature stays valid, because the first one is in place. Mail clients usually display the last one.

This is how a message with a valid signature is tampered with. The line closes this road: the listed names are put into the signature one extra time, and the receiver understands that there must be no more headers with that name. A second one appeared — the signature does not match.

The manual calls this protection against reuse of a signed message. Headers listed here and present in the message are also signed in the usual way.

The main trap is forgetting to enable it. The line has no default: without it a message with a valid signature can be supplemented with a second From or a second Subject, and the recipient will see someone else’s text under your signature. This is not theory — the technique is well known, and the protection against it is exactly one line.
What the Hub does. It does not write it yet. It is a candidate for adding to the policies template: the line costs nothing and closes a known way to forge a message that passes the check. The obvious set suggests itself — sender, recipient, subject.
Recommended values

Start with three: from, to, subject. This is the set from the manual’s example and exactly the headers whose substitution changes the meaning of the message for the reader.

Add reply-to if you use it. A second Reply-To diverts replies to someone else’s address, while the message looks authentic.

Do not list everything. Each name is added to the signature one extra time; it makes sense only for headers that are shown to the reader or control replies.

The starting set and the advice not to list everything are ours. From the manual here come the purpose (protection against reuse of a signed message), the syntax and the example.
Example configuration
# a second From or Subject now breaks the signature
<domain *>
    dkim-disallow-adding-headers from,to,subject,reply-to</domain>
The names go into the signature one extra time — the receiver sees that there must 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 costsA message with a valid signature can be supplemented with a second From or Subject. The mail client will show the added one, the recipient will see someone else’s text under your signature, and the check will pass.
How to spot itThe line is missing from the configuration.
How to do it rightSet at least from,to,subject.

Listing all headers indiscriminately

§ 3.3.10.29

What it costsEach name goes into the signature one extra time, and the h= field swells. There is no benefit: headers the reader does not see are not worth tampering with.
How to spot itThe line holds a dozen names, including service ones.
How to do it rightKeep the ones shown to the reader or controlling replies.
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-disallow-adding-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 merges 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 apply. It is picked up by pmta reload; for queued messages it takes effect from the next attempt.
⇄

Related directives

2 relations

Same name in other blocks

arc-oversigned-headers<domain>The same for the forwarding signature. § 3.3.10.38

Works together with

dkim-headers<domain>That line adds headers to the signature, this one lists the names once more so that their appearance breaks the signature. § 3.3.10.26

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 signature’s h= field:
pmta show settings gmail.com/vmta1 | grep -i disallow-adding
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
A name that appears twice in the h= field is the one this line protects. The Hub does not write it yet — a candidate for the policies template.
◇

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-add-body-limitAll 135 directives of the block →