Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.3.5

A signing key that came along with the message

X-DKIM-Key header
A private key in a message header

The extreme form of handing the decision over to the submitting side: the private key arrives in the message itself, in the X-DKIM-Key header. The node signs with it and removes the header before sending — for security reasons, as the manual says.

It works only in combination. Two lines are needed on the source: key processing and signing options processing. Plus the selector itself: it is passed in a separate header, and without it the message cannot be signed.

The key takes several lines, so the header in the message is folded — like any long header.

The main trap is that the private key travels in the message. It passes through everything between the submitting application and the node: queues, logs, intermediate stores. Removing the header before sending protects the recipient, not the path to the node. The mechanism is justified only where that path is entirely yours.
What the Hub does. It does not use it and does not plan to: it keeps the keys itself and distributes them to the nodes. Passing a private key in a message is the opposite of how key storage works in the Hub.
Example configuration
# processing of both headers is enabled on the source
<source 10.0.0.0/8>
    process-x-dkim-key true    process-x-dkim-options true</source>
The message itself needs both headers: one with the key, the other with the selector. Without the selector there is nothing to sign the message with — that is the manual’s requirement.
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 processing on a broad source

our experience

What it costsAnyone who can submit a message gets the right to sign it with an arbitrary key. The node acts as the signing party, and your domain will answer for the signature in the receivers’ logs.
How to spot itProcessing is enabled in a source block covering the whole network.
How to do it rightEnable it only for sources you trust as much as yourself.

Passing a key without a selector

§ 10.3.5

What it costsThere is nothing to sign the message with: the selector is passed in a separate header, and without it the node does not add a signature. The key has meanwhile traveled the whole way to the node for nothing.
How to spot itMessages with a key in the header leave unsigned.
How to do it rightPass both headers and enable processing of each.
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.
⇄

Related entries

2 relations

Does not work without

A message header with which the submitting side adjusts the signatureA neighboring mechanism: that one chooses a key among the declared ones, this one brings the key right in the message. § 10.3.5

Can be replaced by

How the node signs messages and chooses a keyThe key arrives with the message instead of sitting in the configuration. § 10.3.5

Referenced from

Seeding campaigns with control addressesA signing key passed in a header is not fully supported: seed messages may go out unsigned. § 11.2.2.1

How to check on the node
Whether processing is enabled is visible in the source configuration; whether it worked — by the presence of a signature with no declared keys:
grep -n 'process-x-dkim' /etc/pmta/config
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
The header with the key does not reach the recipient: the node removes it before sending. The Hub does not use this mechanism.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Message signing and authentication · Node security