Demo
Demo

Knowledge base

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

arc-expire-after

<domain>

After how long the forwarding attestation stops being valid
in the configuration this is a linearc-expire-after neverinside the block <domain>
The attestation’s expiry

The counterpart of dkim-expire-after: adds to the attestation the moment after which it is considered expired. The default is never.

For a forwarder this consideration weighs more. It applies attestations to other people’s messages, which it has many of and did not compose; saving such a message and sending it out again is a noticeably more natural scenario than with your own mailing.

The count starts from the attestation, not from delivery — as with the ordinary signature. A message delayed by the receiver longer than the term will arrive expired.

The main trap is a term shorter than the message’s life in the queue. The same as with the ordinary signature: bounce-after is four and a half days by default, while the term is usually set to a day. A delayed message fails verification through no fault of yours.
What the Hub does. It does not write it: it has no forwarding of other people’s mail. If that appears, a term here makes more sense than for the ordinary signature, but it has to be calculated from the message lifetime.
Recommended values

Calculate from the message lifetime. The attestation term must be noticeably longer than bounce-after.

For forwarding a term is more fitting than for a mailing. Someone else’s message with your attestation is a more attractive target for re-sending.

It does not replace protection against additions. Protection against adding a header comes from arc-oversigned-headers, and these are different tasks.

The consideration about the value of a term for a forwarder is ours. From the manual come both kinds of value and the default.
Example configuration
# the attestation term is noticeably longer than the message lifetime
<domain *>
    bounce-after 1d
    arc-expire-after 3d</domain>
The order of magnitude is the same as for the ordinary signature: the message will bounce before the attestation expires.
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▶

Setting a term shorter than the message lifetime

our experience

What it costsA message delayed by the receiver arrives with an expired attestation and fails verification. The key looks to blame, while the cause is in two neighboring lines.
How to spot itVerification failures only for messages delivered with a delay.
How to do it rightMake the term noticeably longer than bounce-after.
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-expire-after <time-interval>
Values
a time interval or the word never — no term
Default
never § 3.3.10.34
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. The count starts from the moment of attestation, that is, from sending. 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.34

Same name in other blocks

dkim-expire-after<domain>The same setting for the ordinary signature. § 3.3.10.34

How to check on the node
The value is printed by the queue settings command; the result is visible in the attestation header itself:
pmta show settings gmail.com/vmta1 | grep -i arc-expire-after
grep -i 'ARC-Message-Signature' /var/log/pmta/pmta.log | tail -3
Without the line there is no expiry field in the attestation at all. 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 →