Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.4

A signature that preserves someone else's verification when forwarding

ARC signing
Who needs it and who does not

An ordinary signature vouches for a message that you composed. ARC vouches for a message that you forwarded: three headers in which the forwarder attests with its signature what the message looked like when it arrived and what the checks on its input showed.

Why this is needed. Forwarding breaks the ordinary signature: a mailing list adds a tag to the subject, appends a footer, changes the return address. The sender’s signature no longer matches after that, and the next receiver sees a message without a valid signature. ARC gives it a second source: a chain of attestations from each forwarder.

It is built on top of the same key. domain-key declarations, the selection rule, the set of lines — all as with the ordinary signature, only with the arc- prefix.

The main trap is that this is a mechanism for a forwarder, not for a sender. A mailing that sends its own messages gets nothing from ARC: it has no one else’s verification to attest, and it already applies its own signature. Three extra headers in every message are the only visible result.
What the Hub does. It does not use it and does not plan to: the Hub’s nodes send their own mail rather than forwarding someone else’s. The mechanism will be needed if a forwarding scenario appears — for example, receiving and re-sending a client’s mail.
Example configuration
# the key is the same as for the ordinary signature; the set of lines is its own
domain-key key1, esp123.com, /etc/pmta/key1.esp123.com.pem

<domain *>
    dkim-sign yes
    arc-sign yes    arc-identity @esp123.com</domain>
Both signatures are applied at the same time and do not interfere with each other: the ordinary one vouches for the message, ARC — for what it looked like when it came to us.
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 on a mailing of your own messages

our experience

What it costsThere is nothing to attest: the message was composed by you, there was no verification on input. Three headers are added to every message, giving the receiver nothing new.
How to spot itARC is enabled on a node that forwards nothing.
How to do it rightTurn it off; the mechanism is for forwarders.

Counting on it on Windows

§ 10.4

What it costsSupport appeared in version 6.0r3 and only for Linux — the manual says so plainly. On Windows the lines are accepted, but there is no signature.
How to spot itThe lines are set, there are no ARC headers in messages.
How to do it rightCheck the node’s platform and version.
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.
⇄

Related entries

1 relation

Same name in other blocks

How the node signs messages and chooses a keyThe same key declarations and the same selection rule, only a different set of signing lines. § 10.4.2

How to check on the node
Whether it works is visible from the message headers: three of them appear at once, with the same number in the chain:
pmta show settings gmail.com/vmta1 | grep -i arc-
grep -ci 'ARC-Seal' /var/log/pmta/pmta.log
The three headers — ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results — are applied together; the appearance of one without the others means a failure. The Hub does not use this mechanism.
◇

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
safe: a wrong value breaks nothing
Scenarios
Message signing and authentication