Demo
Demo

Knowledge base

PMTA knowledge base›Block <signals>›Directive§ 11.1.6.2.16

privacy-policy

<signals>

Whether to anonymize addresses before sending them outside
in the configuration this is a lineprivacy-policy retaininside the block <signals>
The same name 1:<acct-file><signals>— some of them are other settings, some are the same one
The only way not to hand over addresses in full

The line replaces the local part of the recipient address — everything before the at sign — with a one-way SHA-1 hash in the data sent to the service. The default is retain, that is, send it as is.

🔴 This is the only protection for the export. The data leaves the perimeter, and there is no other way to limit its contents: the engine chooses which fields to send by itself.

There is only one method here, unlike in accounting. For an accounting file privacy-policy can do both a placeholder and four kinds of keyed hash; here there is only SHA-1, and without a key. So the strength is different too: an unkeyed hash can be matched against a dictionary of addresses.

Sameness is preserved — the hash shows that this is the same recipient. Analytics does not suffer from it.

The main trap is treating an unkeyed hash as anonymization. It hides the address from a casual glance, but not from someone who has a list of addresses: computing hashes for it and matching them is a matter of minutes. Real protection here is not sending what must not be handed over.
What the Hub does. It does not write it: we do not use export to external analytics. The fleet’s events reach us directly, through the accounting webhook, and there is no reason to hand them outside.
Recommended values

The choice here is short:

Value When
retain (default) the data is handed to the vendor in full anyway
sha1 personal data requirements
Both values, the retain default and the fact that the hash is one-way and computed on the lowercase form come from the manual (§ 11.1.6.2.16). The strength comparison with accounting anonymization is ours.
Example configuration
# addresses leave the node — at least not in plain form
<signals>
    api-key 0123456789abcdef012345678901234567890123
    privacy-policy sha1</signals>
The hash here has no key, unlike accounting file anonymization: the strength is lower.
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▶

Relying on an unkeyed hash as anonymization

our experience

What it costsAn unkeyed SHA-1 hash can be matched against a list of known addresses in minutes. It does not protect against someone who has a database.
How to spot itPeople believe personal data does not leave the node.
How to do it rightSolve the problem through what is handed over at all, not only through the hash.
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
privacy-policy { retain | hash }
Values
retain | sha1
Default
retain § 11.1.6.2.16
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<signals>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside <signals>, and there is only one such block on a node. The export coverage by stream is set not here but with the enable-signals line, which has three levels.
⇄

Related directives

2 relations

Same name in other blocks

privacy-policy<acct-file>The same idea for an accounting file, but there are more methods there: a placeholder and four kinds of keyed hash. inference

Affects

The vendor's analytics — and what leaves the node for itThe mechanism whose operation this line configures. § 11.1.6.2.16

How to check on the node
It has to be checked on the service side — in its reports:
grep -i "signals" /var/log/pmta/log | tail -20
The result is not visible from the node side. The service’s reports should show hexadecimal strings instead of addresses.
◇

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 <signals>:custom-message-id-headerretain-x-sp-subaccount-idhtml-edit-error-modeengagement-trackingtracking-domainAll 16 directives of the block →