Demo
Demo

Knowledge base

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

hide-message-source

<source>

Whether to hide the submitter's name and address in the acceptance mark
in the configuration this is a linehide-message-source falseinside the block <source>
The soft form of hiding the source

The default is false. The manual words it carefully: the engine tries to hide the message source, and currently this means exactly one thing — the name and address of the server the message was received from will not get into the added Received header.

The point is security: not showing the recipient the layout of the internal network the message was submitted from.

The line edits the contents of the mark rather than deciding whether it exists. The mark as a whole is turned off by add-received-header; with that set to false, this directive does nothing, because there is nothing to edit.

The main trap is the caveat “currently this means.” The manual describes not an intention but the current implementation: the submitter’s name and address in one header are hidden. Everything else that tells about your infrastructure stays in place — the platform’s service headers, identifiers, names in addresses.

The line cannot be considered a general privacy switch: it closes one specific trace, and no more.

What the Hub does. It does not write it — and does not need to: its add-received-header is set to false in all sources, the mark is not added at all, and there is nothing to edit in it.

The line would be needed with the opposite decision — to restore the chain for investigations but not show the submitter’s address. That is exactly the middle option worth remembering if turning the mark off completely ever becomes inconvenient.

Recommended values

What to set. There are two meaningful combinations, and both depend on the neighboring line:

Combination What you get
mark on, hiding true the chain is intact, the submitter’s address is not visible — the middle option
mark on, hiding false (default) the full chain, everything is visible
no mark this line does nothing, whatever the value

The third row of the table is our current case.

The false default and the exact wording “currently this means” come from the manual, § 3.3.7.36. The analysis of combinations with the neighboring line is ours.
Example configuration
# the middle option: the chain is intact, the submitter's address is hidden
<source 0/0>
    add-received-header true
    hide-message-source true</source>
The first line is mandatory here: without the mark there is nothing to hide. In the Hub it is set to false, so the second line is not written at all.
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▶

Enabling hiding with the mark turned off

§ 3.3.7.36

What it costsThere is nothing to edit: the header does not exist. The line looks like a working privacy setting and does absolutely nothing.
How to spot itBoth lines are in the configuration, and the first is set to false.
How to do it rightDecide whether the chain is needed. If it is, enable the mark and keep the hiding; if not, remove this line as superfluous.

Treating the line as a general privacy switch

§ 3.3.7.36

What it costsIt closes one trace — the submitter’s name and address in one header. The platform’s service headers, identifiers and everything else stay in place and keep telling about your infrastructure.
How to spot itHiding is enabled, but messages still show internal names and service headers.
How to do it rightClean out the rest separately — with a list in remove-header.
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
hide-message-source <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.36
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. It takes effect only where the acceptance mark is enabled in the same merged set.
⇄

Related directives

1 relation

Works together with

add-received-header<source>The applicability condition: this line edits the contents of the mark, and whether the mark exists is decided by the neighboring one. § 3.3.7.36

Referenced from

add-x-virtual-mta-header<source>The exact opposite task: one line hides the internal setup, the other publishes part of it. § 3.3.7.36

How to check on the node
The setting is visible in the configuration, the result — in the message headers:
grep -n 'hide-message-source\|add-received-header' /etc/pmta/config /etc/pmta/virtualhost.txt
Check with a message in the seed mailbox: your node’s mark must not contain the submitting machine’s name and address. If there is no node mark at all, the neighboring line has turned it off completely, and this one has nothing to do with it.
◇

What else to read

3 articles

◇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.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <source>:smtp-serviceretain-x-dkim-keyprocess-x-dkim-keyallowed-sender-listsrequire-authAll 74 directives of the block →