Knowledge base

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

arc-algorithm

<domain>

Which algorithm the forwarding attestation is computed with
in the configuration this is a linearc-algorithm rsa-sha256inside the block <domain>
A line with no choice

Sets the attestation algorithm. There is one value — rsa-sha256, which is also the default: the manual says plainly that others are not supported.

The difference from the ordinary signature is telling here. dkim-algorithm formally has two values, and the second is obsolete, which is why it manages to migrate from old configurations and devalue the signature. Here there is no such possibility at all: the mechanism appeared after the old algorithm was recognized as unfit.

The line exists so that the arc- set mirrors the dkim- set line for line.

The main trap is thinking there is something to configure here. The line is added to the configuration by analogy with the ordinary signature, changes nothing and stays around as noise. Each such line is one more reason, at the next edit, to decide that its value is somehow important.
What the Hub does. It does not write it — and there is nothing to write: the value is the only one.
Recommended values

Do not set it. The default matches the only allowed value.

The difference from the ordinary signature is that there is nothing to inherit here. This mechanism never had an old algorithm.

If the line is already there — it can be removed. The behavior will not change.

The advice not to set it is ours. From the manual come the only supported value and the default.
Example configuration
# the line is redundant: the value matches the only possible one
<domain *>
    arc-sign yes
    arc-algorithm rsa-sha256</domain>
It can be removed without consequences — the manual knows no other values.
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 ends1 mistake▶

Adding the line by analogy with the ordinary signature

our experience

What it costsIt changes nothing and stays in the configuration as noise. At the next edit someone will decide its value matters and waste time.
How to spot itThe line is set to a value that matches the default.
How to do it rightRemove it.
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-algorithm <enumeration>
Values
rsa-sha256 — the only supported value
Default
rsa-sha256 § 3.3.10.31
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 is merged 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; with a single allowed value, inheritance affects nothing.
How to check on the node
The value is printed by the queue settings command — it is always the same there:
pmta show settings gmail.com/vmta1 | grep -i arc-algorithm
There cannot be another value in the output. The Hub does not write this line.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Message signing and authentication