Два обработчика входящих отчётов и что с ними делать

bounce and feedback-loop processors
Половина картины доставки приходит письмами

Узел узнаёт о судьбе письма двумя путями. В разговоре — и это попадает в учёт само. Письмом позже — и вот для этого нужны обработчики.

Их два, и устроены они одинаково. <bounce-processor> разбирает асинхронные отказы, <feedback-loop-processor> — жалобы. У каждого свой список адресов, своя пара решений о судьбе письма и своя возможность вложить образцы.

Четыре строки решают всё:

Строка Решает
deliver-matched-email что делать с узнанным (умолчание — выбросить)
deliver-unmatched-email что делать с остальным (умолчание — доставить)
forward-unmatched-to куда переслать непонятое
forward-errors-to куда переслать то, на чём разбор сломался

🔴 Две строки связаны неочевидно: пересылка непонятого работает только при deliver-unmatched-email true. Иначе письмо выбрасывается раньше, и адрес пересылки бесполезен.

Приём — отдельный вопрос. Обработчик решает судьбу принятого письма. Чтобы письмо приняли, нужен relay-address и запись MX; без них отчёт отобьётся анти-релеем и до разбора не дойдёт.

Главная ловушка — думать, что обработчик разрешает приём. Он не разрешает: список адресов внутри него фильтрует уже принятое. Самая частая картина — обработчик настроен верно, а писем нет, потому что анти-релей отбивает их жёстким отказом.
Что делает Хаб. Пишет оба обработчика и обе разрешающие строки: отказы ловятся на bounce@bounce.<домен>, жалобы — на fbl@fbl.<домен>, и результат уходит в телеметрию записями rb и f. Роль-адреса dmarc@, postmaster@ и abuse@ мы тоже принимаем — их приходится, иначе анти-релей отбивает их отказом.

🔴 И у нас deliver-unmatched-email no в обоих. Значит, всё, что обработчик не узнал, выбрасывается молча: агрегатные отчёты DMARC, которые мы сами запросили записью rua, письма служб на abuse@ и всё, что пишут на postmaster@. Лечится парой строк: true плюс forward-unmatched-to на живой ящик.

Рекомендуемые значения

Собственных значений у механизма нет — их задают четыре строки в каждом из двух блоков:

Что нужно Как
принять письмо relay-address плюс запись MX
поймать его обработчиком список адресов внутри блока
записать данные происходит само, записями rb и f
не потерять постороннее deliver-unmatched-email true плюс пересылка
Устройство обоих блоков, умолчания четырёх строк и связь пересылки с разрешённой доставкой — из руководства (§ 3.3.3, § 3.3.4). Разбор того, что теряется в нашей конфигурации, — по шаблону Хаба.
Пример в конфигурации
# приём, разбор и сохранение постороннего — три разные вещи
relay-address /^bounce@bounce\./
<bounce-processor>    deliver-matched-email no
    deliver-unmatched-email true
    forward-unmatched-to postmaster@example.com
    <address-list>
        address /^bounce@bounce\./
    </address-list>
</bounce-processor>
Узнанные отказы выбрасываются — их данные уже в учёте. Всё прочее уходит человеку, а не в никуда.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Настраивают обработчик и не разрешают приём

наш опыт

Чем чреватоСписок адресов внутри блока фильтрует уже принятое. Приём разрешает relay-address; без неё отчёты отбиваются анти-релеем и до разбора не доходят.
Как заметитьОбработчик настроен, записей rb и f в учёте нет ни одной.
Как правильноДобавить relay-address на те же адреса и проверить запись MX.

Выбрасывают нераспознанное на адресах, куда пишут люди

§ 3.3.3.1

Чем чреватоОбработчик не узнаёт агрегатные отчёты, письма служб и обычную почту. Со значением no всё это исчезает без следа.
Как заметитьОтчёты DMARC запрошены записью rua, но их никто никогда не видел.
Как правильноdeliver-unmatched-email true плюс forward-unmatched-to на живой ящик.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у механизма нет — наследуются директивы, которыми он включается, а они живут внутри своего блока. Обработчиков ровно два, и настройки у них независимы.
⇄

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

5 связей

Как проверить на узле
Проверять надо по учёту: записи обоих видов должны появляться:
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
Записи rb и f означают, что обработчики работают. Их отсутствие при идущей отправке — сигнал: либо письма не принимаются (relay-address, запись MX), либо не узнаются (нужны образцы в <email-patterns>).
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Приём входящей почты · Собрать телеметрию