Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.1

add-date-header

<source>

Whether to add a Date header if there is none
in the configuration this is a lineadd-date-header noinside the block <source>
Insurance against a message without a date

The default is no. There are three values, and the third is not boolean:

no — leave it alone. yes — add one if there is no header; an existing one is not rewritten. override — set its own in any case.

The Date header is mandatory under the message standard, and receivers take its absence badly. But the submitting platform usually sets it itself, so the line is insurance, not a working mechanism.

It does not work with merging. The manual says so directly: automatic date addition for messages assembled by merging is not supported; there the same task is handled by the *date variable.

The main trap is override combined with deferred sending. With yes the date is set once on receipt, while override also rewrites the one that was sent. Paired with date-header-time delivery, this means the message will carry the time of actual delivery, which may be days after submission — and the recipient will see a message sent “today” although they expected it the day before yesterday.
What the Hub does. It does not write it — the vendor no stays. The date is set by the sending library itself: a warm-up message always goes out with Date, and there is nothing to add.

The line would be useful as insurance on a node where a third-party platform of unknown quality submits — but that is also where it is more dangerous: override will overwrite a date the sender set deliberately.

Recommended values

What to set. The three values solve three different tasks:

Value When
no (default) the submitting platform sets the date itself — the usual case
yes submission is mixed, and some messages arrive without a date
override the sender’s date is known to be wrong: a skewed clock, an old queue on their side

The third value is a last resort: it erases the sender’s intent and, paired with the delivery time, produces a message dated after the fact — backdating in reverse.

The no default, the three values and the caveat about merging come from the manual, § 3.3.7.1. The breakdown of cases is ours.
Example configuration
# the date is added only to messages that arrived without one
<source 0/0>
    add-date-header yes</source>
With this value a Date already in the message is not rewritten. To rewrite it you need override — and then it is worth deciding right away which time to put in it.
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▶

Expecting a date on messages assembled by merging

§ 3.3.7.1

What it costsThe manual excludes this case directly: automatic date addition is not supported for merging. Messages go out without a date, and it becomes noticeable through how receivers treat them, not through an engine error.
How to spot itSome messages have no date — exactly those assembled by merging.
How to do it rightSet the date with the *date variable in the merge itself.

Setting override without settling the time question

our experience

What it costsThe date the sender set deliberately is rewritten too. And if the delivery time is selected alongside, the message will carry the moment of actual sending — for a deferred mailing, that is days later.
How to spot itRecipients see a time in messages that differs from the one at submission.
How to do it rightUse yes, and keep override for the case of a clock known to be wrong on the submitting side.
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
add-date-header <enumeration>
Values
no | yes | override
Default
no § 3.3.7.1
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. For submission under a login the named block applies, and the line has to be repeated in it — we did not see inheritance from address blocks into a named one on our installation.
⇄

Related directives

1 relation

Works together with

date-header-time<source>Decides which time goes into the added header — receipt or delivery. § 3.3.7.2

How to check on the node
The setting is visible in the configuration, the result — in the delivered message:
grep -n 'add-date-header\|date-header-time' /etc/pmta/config /etc/pmta/virtualhost.txt
What actually arrived is shown only by the message in the seed mailbox: it should have exactly one Date header, and the time in it should be the one you intended.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:process-x-jobjobid-prefixbccadd-received-headeradd-x-virtual-mta-headerAll 74 directives of the block →