Две точки подключения — и два разных поведения

критично

address suppression lists
Где подключён список, там и решается, когда отправитель узнает

Один и тот же список значит разное в зависимости от места подключения, и разница — в моменте, когда отправитель об этом узнаёт.

В источнике поведение задаёт соседняя строка accept-invalid-recipients: no — получатель отвергается прямо в команде RCPT, и подающая программа узнаёт немедленно; yes — письмо принимается и отбивается позже, записью отказа 5.7.1 (delivery not authorized).

В адресе отправки или пуле выбора нет: письмо всегда принимается, встаёт в очередь и отбивается — 5.7.1 (suppressed).

Списков можно подключить несколько, через запятую, в обеих точках. И к пакетной подаче из каталога правило то же, только вместо accept-invalid-recipients решает подтверждение приёма.

Вендор советует не более пятисот образцов в одном списке. Это практический потолок, и он определяет, что сюда можно класть: не весь чёрный список, а его особую часть.

Главная ловушка. Подключение к адресу отправки выглядит удобнее («подавление там же, где адрес»), а на деле это худший из двух вариантов: отправитель ничего не узнаёт при подаче, письмо проходит весь путь до очереди и превращается в отказ, который потом надо правильно классифицировать. Отказ при подаче честнее и дешевле.
Что делает Хаб. Не пользуется: подавление у нас работает до узла. Свой чёрный список Хаб держит в базе, общий с рассылочной платформой (отписался в прогревочном письме — не получит боевую рассылку, и наоборот), и на узел его не отдаёт. Списки на узле были бы второй линией обороны на случай, когда письмо попадает в PowerMTA мимо Хаба, — но потолок в пятьсот образцов делает их непригодными для полного чёрного списка.
Рекомендуемые значения

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

Куда подключать Когда узнаёт отправитель Когда так
<source> с accept-invalid-recipients no сразу, отказом на RCPT своя подача: ошибку видно и можно починить
<source> с accept-invalid-recipients yes потом, записью отказа чужая подача, которая на отказ RCPT не рассчитана
<virtual-mta> или пул всегда потом, записью отказа выбора нет — так работает

Что сюда класть при потолке в 500 образцов: не весь чёрный список, а то, что обязано не уйти ни при каких условиях, — жалобщики, спам-ловушки, адреса по требованию клиента.

Оба кода отказа, зависимость от accept-invalid-recipients и совет про 500 образцов — из руководства (§ 11.15). Что класть в список — наше.
Пример в конфигурации
# в источнике — отказ при подаче; в адресе отправки — отказ потом
<address-list suppression1>
    address /^complaints\+/
</address-list>

<source 10.0.0.0/24>
    accept-invalid-recipients no
    suppression-lists suppression1</source>
С accept-invalid-recipients no подающая программа получит отказ прямо в команде RCPT и сможет что-то с этим сделать. Перенесите строку подавления в блок адреса отправки — и та же проверка превратится в отказ, о котором отправитель узнает из отчёта.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Кладут в список весь чёрный список

§ 11.15

Чем чреватоВендор советует не более пятисот образцов в одном списке. Реальный чёрный список — это десятки и сотни тысяч адресов; на такой конфигурации проверка становится дорогой, а сам файл — неуправляемым.
Как заметитьКонфигурация разрастается, применение замедляется, а править список руками невозможно.
Как правильноДержать полный чёрный список там, где ему место, — в базе отправляющей системы. На узле оставлять короткий список того, что обязано не уйти ни при каких условиях.

Подключают к адресу отправки, ожидая отказа при подаче

§ 11.15.1

Чем чреватоВ адресе отправки и пуле выбора нет: письмо всегда принимается и отбивается потом. Подающая программа считает письмо отправленным, а получатель его не получает.
Как заметитьВ отчётах есть отказы 5.7.1 (suppressed), а подача проходит без единой ошибки.
Как правильноПодключать к источнику и ставить accept-invalid-recipients no — тогда отправитель узнаёт сразу.

Забывают про accept-invalid-recipients

§ 11.15.1

Чем чреватоВ источнике поведение решает именно эта строка. При включённом приёме неверных получателей подавление всё равно работает, но превращается в отказы вместо отказов при подаче — а это разные вещи для того, кто читает отчёты.
Как заметитьОжидали отказ на RCPT, получают записи отказов.
Как правильноСтавить обе строки вместе: список подавления и accept-invalid-recipients no. Это одна настройка из двух.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у самого механизма нет: наследуется директива, которой он включается. В <source> она сливается по правилу источников — более узкий блок перекрывает более широкий; в пуле достаётся участникам, а собственная строка участника пуловую перекрывает. Точки подключения при этом не складываются: список в источнике и список в адресе отправки — две разные проверки, и сработать может каждая.
Как проверить на узле
Что подавление сработало, видно в отказе — по коду и тексту, где названо имя списка:
pmtaacctfind --output csv[rcpt,dsnStatus,dsnDiag] /var/log/pmta/acct-*.csv
5.7.1 (delivery not authorized) — сработал список источника при включённом приёме неверных получателей; 5.7.1 (suppressed) — список адреса отправки или пула. В обоих случаях в тексте отказа стоит имя списка, и по нему видно, какой именно сработал.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подавление адресов · Разделение отправителей
Важность
критично