Demo
Demo

Knowledge base

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

dkim-add-timestamp

<domain>

Whether to put the moment of its creation into the signature
in the configuration this is a linedkim-add-timestamp falseinside the block <domain>
A timestamp in the signature

Adds a field with the moment of its creation to the signature. The default is not to add it.

The field by itself decides nothing. The receiver does not reject a signature by it: the expiry is set by another line, dkim-expire-after. The timestamp is information, not a rule.

The benefit is in investigations. Having received a complaint about a month-old message, the timestamp shows when the node signed it: a big gap between signing and receipt gives away a re-sent copy. Without the timestamp only the Date header remains — and it is set by the submitting side by its own clock, and the node does not vouch for it.

The main trap is taking it for the expiry. The timestamp limits nothing: a signature with it is valid exactly as long as one without it. What limits is dkim-expire-after, and these are different signature fields.
What the Hub does. It does not write it — the vendor value stays. A candidate for enabling: the field costs nothing and makes investigations of old messages possible.
Recommended values

Enabling it is fine and almost free. One field in the signature, no consequences for verification.

Together with an expiry it makes sense. The timestamp says when, the expiry says until when; separately the second is more useful.

Do not confuse it with the Date header. That one is set by the submitting side by its own clock; the timestamp is set by the node itself at the moment of signing.

The assessment “enabling it is fine and almost free” is ours. From the manual here: the default and the purpose of the line.
Example configuration
# timestamp and expiry are different fields, set both
<domain *>
    dkim-add-timestamp true    dkim-expire-after 3d
</domain>
The first tells when the signature was made, the second — until when it is valid. One does not replace the other.
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▶

Taking the timestamp for the expiry

our experience

What it costsA signature with a timestamp is valid exactly as long as one without it. Protection against reuse is believed to be on, but it is not.
How to spot itThe timestamp is enabled, dkim-expire-after is left without a value.
How to do it rightSet the expiry separately — it is a different signature field.

Not enabling it and then investigating by the Date header

our experience

What it costsThe header is set by the submitting side by its own clock, and the node does not vouch for it. In an investigation of an old complaint there is nothing to rely on.
How to spot itA dispute about when the message was sent comes down to the unprovable.
How to do it rightEnable the timestamp: it is set by the node itself at the moment of signing.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
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
dkim-add-timestamp <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.20
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; for queued messages it applies from the next attempt.
⇄

Related directives

1 relation

Does not work without

dkim-sign<domain>Does nothing until signing is enabled. § 3.3.10.20

How to check on the node
The value is printed by the queue settings command; whether the field appeared is visible in the signature itself:
pmta show settings gmail.com/vmta1 | grep -i add-timestamp
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
The t= field in the signature is the timestamp; without the line it is absent. 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 →