Demo
Demo

Knowledge base

PMTA knowledge base›Block <address-list>›Directive§ 3.3.5.4

hashed-address-file

<address-list>

Address hashes from a separate file
in the configuration this is a linehashed-address-fileinside the block <address-list>
A long list nobody will read

A combination of two other lines: the list is kept in a file, and the entries in it are hashes. Each line of the file is the hash of a whole address, computed by the same rule: lowercase, SHA256, BASE64URL.

In practice this is the only usable form for someone else’s list. The client hands over a file of hashes, the node enforces it, and neither the configuration, nor the backup, nor a person with access to the server sees the addresses.

The limitations are the same as for hashed-address: only whole addresses, no patterns, domains or local parts.

The main trap is that the list cannot be checked by eye. An error in generating the file (the wrong case before hashing, regular BASE64 instead of BASE64URL, extra spaces) produces a list that silently matches nothing. The only way to make sure is to compute the hash of a known address with the bundled tool and look for the line in the file.
What the Hub does. It does not write it: suppression works before the node. The form matters as a ready answer to the request “respect our list, but we will not give you the addresses”: the client sends a file of hashes, the Hub puts it on the node and plugs it in — and does not receive someone else’s database along with it.
Recommended values

The value is a file path. What to put in order alongside it:

What Why
the generation rule at whoever provides the file lowercase, SHA256, BASE64URL — otherwise it will not match
a control address used to check that the file works at all
file permissions hashes are not addresses, but there is no reason to show them either

Check only with the control address. Such a list cannot be read either by you or by anyone who gains access to the server — that is its whole point.

The file format comes from the manual (§ 3.3.5.4). The control address technique is ours — otherwise an error in generating the file cannot be caught.
Example configuration
# a client's suppression list that we cannot read
<address-list foo>
    hashed-address-file /etc/pmta/suppression-address-list-hashed.txt</address-list>
The manual’s example. The file holds lines like f80vxObv18a0Gk2et394B6-S-TTgZp-RdYjUuUwnsRk~ — one per address. Agree on a control address with whoever provides the file: it is used to check that their generation rule matches yours.
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▶

Accepting a file without checking the generation rule

§ 3.3.5.4

What it costsHashes computed with regular BASE64 or without lowercasing will match nothing. The list is plugged in, there are no errors, suppression does not work — and there is nothing to notice it with.
How to spot itMessages go to addresses that are definitely on the client’s list.
How to do it rightAgree on a control address and check its hash with the bundled tool before the list goes into service.

Expecting pattern matching from hashes

§ 3.3.5.4

What it costsA hash is computed from a whole address. There can be no domains, local parts or patterns in such a file — they simply will not match.
How to spot itSome entries work and some do not, with no clear pattern.
How to do it rightHash only whole addresses. Everything else goes into a regular list.
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
hashed-address-file <path>
Values
a file path; in the file one hash of a whole address per line
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<address-list>
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The line has no inheritance: it applies inside its <address-list> block. What is inherited is the reference to the list — suppression-lists in <source> merges by the source rule, in a pool it goes to the members, and a member’s own line overrides the pool one.
⇄

Related directives

2 relations

Works together with

hashed-address<address-list>The same entry format, only one hash per line of a file. § 3.3.5.4

Can be replaced by

address-file<address-list>The same file in plain form: readable and more flexible, but the addresses in it are visible. § 3.3.5.4

How to check on the node
The only working check is to compute the hash of a known address and look for it in the file:
grep -c "$(pmtahashedAddress control@example.com)" /etc/pmta/suppression-address-list-hashed.txt
One means the generation rule matched between you and the file’s supplier. Zero means something diverged: most often the case before hashing or the encoding of the result.
◇

What else to read

3 articles

◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.◇Configuration through the API and the file do not reconcileObjects created through the configuration interface cannot be edited in the file: two sources of truth about the configuration do not reconcile.◇The bounce category in accounting — configurable, not vendor-fixedThe bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address suppression
Neighboring settings of the block <address-list>:hashed-addressaddressaddress-filedomainAll 5 directives of the block →