Demo
Demo

Knowledge base

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

arc-sign

<domain>

Whether to seal messages to this recipient with a forwarding signature
in the configuration this is a linearc-sign falseinside the block <domain>
Enabling the chain of seals

Enables the forwarding signature for messages to this recipient. Three headers are added to the message, in which the node attests what the message looked like when it arrived and what the inbound checks showed.

The keys are the same. As with the regular signature, they are taken from domain-key declarations, by sending domain; there are no separate keys for ARC. Without declarations the line does nothing — the manual says so in the same words as for dkim-sign.

The two signatures are independent. Enabled together, both are applied: the regular one vouches for the message, ARC — for how it reached you.

The main trap is enabling it where there is no forwarding. The mechanism is designed for those who resend someone else’s mail. It gives nothing to a mailing of your own messages: there is no one else’s check to attest, while three headers are added to every message.
What the Hub does. It does not write it: nodes send their own mail rather than forwarding someone else’s. If a forwarding scenario appears, this line and the whole arc- set will be needed.
Recommended values

Enable it only when forwarding. The sign is simple: the message came to you from outside, and you are sending it further.

Keys first. Without domain-key declarations the line stays silent, just like the regular signature.

Check the platform. Support appeared in version 6.0r3 and only for Linux; on Windows the line is accepted and does not work.

The “enable only when forwarding” sign is ours. From the manual here come the default, the requirement of configured keys and the version and platform restriction.
Example configuration
# we forward someone else's mail — attesting how it came to us
domain-key key1, esp123.com, /etc/pmta/key1.esp123.com.pem

<domain *>
    dkim-sign yes
    arc-sign yes</domain>
The two lines side by side do not conflict: the message will get both the regular signature and the three headers of the seal chain.
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 costsThree headers are added to every message and tell the receiver nothing: there is no one else’s check to attest.
How to spot itARC is enabled, but the node forwards nothing.
How to do it rightTurn it off.

Enabling it on Windows

§ 10.4

What it costsSupport is Linux-only, starting with version 6.0r3. The line is accepted without error, and there are no headers in the messages.
How to spot itThe line is set, but ARC-Seal never appears in the log.
How to do it rightCheck the node’s version and platform.
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.
Reference data
Syntax
arc-sign <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.30
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. It is picked up by pmta reload; for queued messages it takes effect from the next attempt — the signature is applied at sending. Requires version 6.0r3 and the Linux platform.
⇄

Related directives

2 relations

Does not work without

domain-keyGlobalKeys must be configured, otherwise enabling it achieves nothing. § 3.3.10.30

Same name in other blocks

dkim-sign<domain>The same for the regular signature — the manual describes both in the same terms. § 3.3.10.30

Referenced from

arc-algorithm<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.31arc-body-canon<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.32arc-headers-canon<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.33arc-expire-after<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.34arc-headers<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.35arc-identity<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.36

How to check on the node
The effective value is printed by the queue settings command; whether the headers were added is visible from the log:
pmta show settings gmail.com/vmta1 | grep -i arc-sign
grep -ci 'ARC-Seal' /var/log/pmta/pmta.log
A value of yes with zero output from the second command means either no suitable key or an unsupported platform. 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-signcheck-spf-outbounddkim-identitydkim-headersdkim-disallow-adding-headersAll 135 directives of the block →