Demo
Demo

Knowledge base

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

arc-identity-fallback

<domain>

A fallback attestation identity if no key was found for the main one
in the configuration this is a linearc-identity-fallbackinside the block <domain>
For a forwarder this is the norm, not an exception

It works the same way as dkim-identity-fallback: if no key is found for the main identity, the fallback one is taken. It requires arc-identity to be set.

But its role is different. For the ordinary signature, falling back to your own identity is an exception: the client did not hand over a key, and that is a reason to investigate. A forwarder never has other people’s keys: it forwards mail from arbitrary senders and can attest it only on its own behalf.

Hence a simple conclusion: when forwarding, it is more sensible to set your own identity directly in arc-identity, and to keep this line for the case where some senders did hand over keys.

The main trap is keeping the default main identity and relying on the fallback. Then on every message the node first looks for a key by someone else’s domain, does not find it and falls back. It works, but extra work is done on every message, and the configuration describes the intent backwards.
What the Hub does. It does not write it: it has no forwarding of other people’s mail. If that appears, it is more correct to set your own identity as the main one rather than fall back to it on every message.
Recommended values

When forwarding, set your own identity as the main one. Keep the fallback for senders whose keys you have.

The identity must match the domain of the declaration domain-key or be its subdomain — like the main one.

Without arc-identity the line does not work. A requirement of the manual, not a recommendation.

The advice to set your own identity as the main one is ours. From the manual come the line’s purpose and the requirement to set the main attestation identity.
Example configuration
# some senders handed over keys, the rest we attest on our own behalf
domain-key key1, esp456.com, /etc/pmta/key1.esp456.com.pem

<domain *>
    arc-sign yes
    arc-identity sender-or-from
    arc-identity-fallback @esp456.com</domain>
The order here is: first the sender’s key is looked for, and only if it is not found does the node attest the message with its own identity.
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▶

Setting it without a main identity

§ 3.3.10.37

What it costsThe line does not work: the manual requires arc-identity to be set. The fallback looks configured and never triggers.
How to spot itSome messages go out without an attestation.
How to do it rightSet the main identity next to it.

Building forwarding on the fallback

our experience

What it costsOn every message the node looks for a key by someone else’s domain, does not find it and falls back. The result is right, the work is extra, and the intent in the configuration is described backwards.
How to spot itThe main identity is left at the default, all messages are attested with the fallback.
How to do it rightSet your own identity as the main one.
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-identity-fallback <address-or-domain>
Values
a domain or an email address; requires arc-identity to be set
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 requires arc-identity to be set and obeys the same rule of matching the domain-key declaration domain. It is picked up by pmta reload.
⇄

Related directives

2 relations

Does not work without

arc-sign<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.37

Same name in other blocks

dkim-identity-fallback<domain>The same for the ordinary signature — but there falling back to your own identity is an exception, while a forwarder never has other people’s keys at all. § 3.3.10.37

How to check on the node
The value is printed by the queue settings command; whether the fallback triggered is visible from the domain in the attestation headers:
pmta show settings gmail.com/vmta1 | grep -i arc-identity
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
Your domain in the header with someone else’s sender means the fallback triggered. 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-signdkim-identitycheck-spf-outbounddkim-disallow-adding-headersdkim-add-body-limitAll 135 directives of the block →