Demo
Demo

Knowledge base

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

add-received-header

<source>set by the Hub

Whether to add a Received header when accepting a message
in the configuration this is a lineadd-received-header trueinside the block <source>
Leave a mark in the chain or disappear from it

The default is true: having accepted a message, the node adds its own Received. Every mail server does this — the header records who accepted the message, when and from whom, and such marks add up to a transfer chain used later to reconstruct the path.

With false the node does not appear in the chain at all. The message reaches the recipient as if nothing came before their server.

There is also a softer option: hide-message-source keeps the header but removes from it the name and address of whoever submitted the message. It solves the privacy task without breaking the chain — if privacy is exactly the task.

The main trap is that a broken chain is noticed not by recipients but by you. While everything works, there is no difference. It shows up in an investigation: a complaint came in, the message has to be found, and the path it took is unknown, because the node left no mark of its own.

The other half: receivers look at the chain. A message with not a single mark between the sender and the receiver looks unusual — not fatal, but not a plus either.

What the Hub does. It writes false — in every source it generates: both in the baseline configuration and in every named submission source. That is, the node does not appear in the chain.

The reason in the template is recorded briefly: hiding the source. The Hub does not write the soft form hide-message-source — and rightly so, it would be useless: there is nothing to edit in the contents of a header that does not exist.

Recommended values

What to set. A choice between investigability and privacy:

Value When
true (default) the chain is needed for investigations, and the soft form hides the internal details
false the submitting side must not be visible at all — and the trail for investigations disappears with it

The middle option is true plus hide-message-source: the mark is there, but the submitter’s name and address are not in it. It is more honest than the second and almost as closed.

The true default comes from the manual, § 3.3.7.6. What exactly the soft form removes — § 3.3.7.36. The breakdown of cases is ours.
Example configuration
# this is how the Hub writes the configuration — the node does not appear in the chain
<source 0/0>
    add-received-header false    remove-header X-PreviewEmail,X-Mailer,X-Priority
</source>
Both lines are about the same thing: not showing the recipient more than necessary. The first removes the node’s mark entirely, the second cleans out the submitting platform’s service headers.
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▶

Turning off the mark when the soft form was needed

§ 3.3.7.36

What it costsThe task is usually not to show the submitter’s internal address. There is a separate line for that, which keeps the chain intact. Turning the mark off completely solves the same task and also deprives you of a trail for investigating complaints.
How to spot itMessages have none of your marks, while only the submitter’s address needed hiding.
How to do it rightRestore the default and add the soft form.

Relying on the chain where you removed it yourself

our experience

What it costsInvestigating a complaint runs into the fact that the message’s path cannot be reconstructed: the node left no mark of its own, and the others show only the last step.
How to spot itThe investigation cannot determine from which node and when the message went out.
How to do it rightKeep the link between a message and its send on your side — by the message identifier and accounting records, not by the chain in the message itself.
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-received-header <boolean>
Values
yes | no | true | false
Default
true § 3.3.7.6
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 — the Hub repeats the line there too, because we did not see inheritance from address blocks into a named one.
⇄

Related directives

2 relations

Works together with

max-message-hops<source>Loop protection counts hops by the marks — without them there is nothing to count. § 3.3.7.38

Can be replaced by

hide-message-source<source>The soft form of the same task: the mark stays, but the submitter’s name and address are not in it. § 3.3.7.36

How to check on the node
The setting is visible in the configuration, the result — in the headers of the delivered message:
grep -n 'add-received-header\|hide-message-source' /etc/pmta/config /etc/pmta/virtualhost.txt
Look at the message in the seed mailbox: how many Received marks it has and whether your node is among them. The receiver’s mark will always be there — the receiver sets it itself, and this line does not affect it.
◇

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
Managed at
Infrastructure → Node parameters
Value
The Hub picks it itself — pace, warm-up stage, metrics
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-message-id-headeradd-x-virtual-mta-headerAll 74 directives of the block →