Knowledge base

privacy-policy

<acct-file>

Anonymizing recipient addresses in accounting
in the configuration this is a lineprivacy-policy retaininside the block <acct-file>
The same name 1:<acct-file><signals>— some of them are other settings, some are the same one
Accounting without addresses, but with the ability to match records

The line replaces the local part of the address — everything before the at sign — in all records of this file, in receiver responses and in VERP-form sender addresses. The default is retain, that is, change nothing.

There are five methods, and they fall into two kinds:

Value What it does Can records be matched
retain (default) nothing —
redact “X” replaces with a placeholder, … by default no
siphash “key” a fast keyed hash yes
siphash-hexkey the same, hexadecimal key yes
hmac-sha256 “key” a cryptographically strong keyed hash yes
hmac-sha256-hexkey the same, hexadecimal key yes

The difference between a placeholder and a hash is fundamental. A placeholder erases the address for good: two records about the same recipient become indistinguishable. A hash preserves sameness — it shows that this is the same person — and makes it possible to find their records by computing the hash of a known address with the pmta digest command.

The key requirements differ. A SipHash key is no longer than 16 bytes, and the engine pads a short one with zeros. For HMAC-SHA256 at least 32 bytes are recommended: with a shorter one the engine will warn but accept it.

The main trap is losing the key. Without it the hashes in old accounting turn into placeholders: nothing can be matched against them anymore. And changing the key breaks the link with all previous records — the same recipient before and after the change looks like two different ones.
What the Hub does. It does not write it — addresses in accounting stay as they are, and the panel shows them in full.

The line will be needed where a node serves other people’s mailings and personal data requirements are stricter than ours. Then the right choice is hmac-sha256 with a long key: counting analytics is preserved, while finding a specific address requires knowing both the key and the address itself.

Recommended values

The choice depends on whether matching will be needed later:

Value When
retain (default) your own mailings, access to the node is restricted
hmac-sha256 “long key” personal data requirements, matching is needed
siphash “key” the same, but the accounting volume is large and speed matters
redact accounting is handed outside and matching is not needed at all

The key is stored where other secrets are, and it is not changed without a reason.

The five methods, the key length requirements, lowercasing and the coverage (recipient, receiver responses, VERP) come from the manual (§ 3.3.11.16). The analysis of the choice between a placeholder and a hash is ours.
Example configuration
# accounting without addresses, but with matching: a hash with a long key
<acct-file /var/log/pmta/acct.csv>
    records d, b
    privacy-policy hmac-sha256 "KEY-32-BYTES-OR-LONGER"</acct-file>
The key here is part of the configuration, that is, it is stored in plain text. A record for a known address can be found with the pmta digest command by giving it only the local part of the address.
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 ends3 mistakes▶

Choosing a placeholder where matching will be needed later

our experience

What it costsA placeholder erases the address for good: two records about the same recipient become indistinguishable, and nothing can be counted per recipient anymore.
How to spot itAll addresses in accounting are identical.
How to do it rightUse a hash: it preserves sameness and allows searching by a known address.

Changing the hashing key

our experience

What it costsThe same recipient produces different hashes before and after the change. The link between old and new accounting breaks, and no recalculation will restore it.
How to spot itAfter a configuration edit the number of unique recipients jumped.
How to do it rightChange the key only deliberately, noting the date of the change; keep the previous key for matching old accounting.

Giving HMAC-SHA256 a short key

§ 3.3.11.16

What it costsThe engine will warn but accept it. The hash strength is then below the recommended level, and it cannot be fixed retroactively — only by changing the key, which breaks the link with old accounting.
How to spot itThe log has a key length warning at startup.
How to do it rightChoose a key of at least 32 bytes right away, during the initial setup.
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 <enumeration>
Values
retain | redact | siphash | siphash-hexkey | hmac-sha256 | hmac-sha256-hexkey, with a key or placeholder as the second word
Default
retain § 3.3.11.16
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<acct-file>
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 its <acct-file> and applies only to the records of this stream. Two accounting blocks can write the same events — one with addresses, the other without — and this is the usual way to hand an anonymized copy outside.
How to check on the node
We look at the file itself: an anonymized address is visible right away:
head -3 "$(ls -t /var/log/pmta/acct-*.csv | head -1)"
The local part of the address will be a placeholder or a hexadecimal string. To check the hash of a known address: pmta digest LOCAL_PART — the command is given exactly the local part, without the domain.
In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Node security · Collect telemetry