Списки адресов — именованные и безымянные

<address-list>
Одна конструкция на три разные задачи

Список наполняют пять директив: адрес или образец, целый домен, адреса из файла и две хешированные формы.

Имя решает, для чего список. Именованный подключается по имени — suppression-lists для подавления, allowed-sender-lists для разрешённых отправителей. Безымянный пишется внутри блока обработчика отказов или жалоб и отбирает почту, которую тот разбирает.

Хешированная форма заслуживает больше внимания, чем ей уделено в руководстве. Адрес приводится к нижнему регистру, хешируется SHA256 и кодируется BASE64URL; MTA хеширует проверяемый адрес и сравнивает хеши. То есть список подавления можно передать и хранить, не имея в нём ни одного читаемого адреса. Образцы к хешам не применяются — только целые адреса.

Три задачи на одной конструкции — что подавлять, кому разрешено отправлять и какую входящую почту разбирать. Поэтому это механизм, а не деталь одной из трёх.

Главная ловушка — смешать две формы в голове. К хешам не применяются образцы: /^bounce@/ в хешированном списке не совпадёт ни с чем, потому что сравниваются хеши целых адресов. И наоборот, обычный список читаем всеми, у кого есть доступ к конфигурации или к её резервной копии.
Что делает Хаб. Пользуется безымянной формой, и активно: в базовой конфигурации узла два безымянных списка — один внутри обработчика жалоб (ловит fbl@fbl.<домен>), другой внутри обработчика отказов (ловит bounce@bounce.<домен> и роль-адреса dmarc@, postmaster@, abuse@). Именованных списков Хаб не пишет: подавление у нас работает до узла, своим списком в базе.
Рекомендуемые значения

Собственных значений у механизма нет — их задают пять директив внутри. Выбор формы:

Форма Что кладут Особенность
address адрес, локальную часть или образец самая гибкая, читаемая всеми
domain целый домен одна строка вместо перечисления
address-file адреса из файла, по одному на строку конфигурация не разрастается
hashed-address хеш целого адреса в файле нет читаемых адресов
hashed-address-file хеши из файла то же для длинного списка

Когда брать хеши. Когда список нельзя показывать — например, клиент требует уважать своё подавление, но адреса не отдаёт. Узел исполнит список, который не может прочитать.

Все пять форм, устройство хеша и правило «к хешам образцы не применяются» — из руководства (§ 3.3.5). Совет про клиентский список — наш.
Пример в конфигурации
# безымянный список отбирает почту для обработчика — так пишет Хаб
<bounce-processor>
    deliver-matched-email no
    deliver-unmatched-email no
    <address-list>        address /^bounce@bounce\./
    </address-list>
</bounce-processor>

# именованный подключается по имени — так включают подавление
<address-list suppression1>
    hashed-address iZ0zh6XFp1VdUdLwoLe1Djl_5IH9mlj6-zibfclOEfY~
</address-list>
Верхний список безымянный: он живёт внутри обработчика и отбирает письма, которые тот будет разбирать. Нижний именованный — его подключают строкой suppression-lists. В нём хеш, и по файлу конфигурации нельзя узнать, чей это адрес.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Пишут образец в хешированный список

§ 3.3.5.2

Чем чреватоК хешам образцы не применяются: сравниваются хеши целых адресов. Строка вида /^bounce@/ не совпадёт ни с чем и при этом не вызовет ошибки.
Как заметитьСписок настроен, подавление не срабатывает ни разу.
Как правильноВ хешированных списках — только целые адреса, посчитанные инструментом. Образцы держать в обычном списке.

Забывают, что безымянный список — не подавление

§ 3.3.5

Чем чреватоБезымянный список внутри обработчика отбирает почту для разбора, а не подавляет её. Ожидание «положил адрес — письма не пойдут» здесь не выполняется вовсе.
Как заметитьАдрес в списке, а письма ему по-прежнему уходят.
Как правильноДля подавления заводить именованный список и подключать его строкой suppression-lists.

Кладут читаемый чужой список в конфигурацию

наш опыт

Чем чреватоФайл конфигурации и его резервные копии читают все, у кого есть доступ к узлу. Клиентский список подавления в открытом виде — это выгрузка его базы, лежащая в бэкапе.
Как заметитьОбнаруживается при разборе доступа, а не в работе.
Как правильноПользоваться хешированной формой. Узел исполнит список, который не может прочитать, и ни файл, ни бэкап адресов не покажут.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у самого списка нет: он объявляется в корне файла (или внутри процессора) и ничего не наследует. Наследуются ссылки на него — suppression-lists в <source> сливается по правилу источников, в пуле достаётся участникам, а собственная строка участника пуловую перекрывает.
⇄

Связанные записи

3 связи

Как проверить на узле
Хеш можно посчитать тем же инструментом, что и MTA, — и сверить с тем, что в списке:
pmtahashedAddress test@FOO.com
Инструмент приводит адрес к нижнему регистру сам, поэтому test@FOO.com и test@foo.com дают один хеш. Если строка списка с ним не совпадает посимвольно — совпадения не будет: к хешам образцы не применяются.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Приём входящей почты · Подавление адресов · Разделение отправителей