Возвращённая почта как источник телеметрии
Отчёты, приходящие письмом, превращаются в данные
Задача. Узел, чей MX-слушатель принимает отказы и жалобы по доменам, с которых он отправляет.
Из чего складывается:
- deliver-matched-email в <bounce-processor> — опознанные отказы поглощаются, а не доставляются;
- deliver-unmatched-email — неопознанное письмо идёт дальше, чтобы на него можно было посмотреть, — это же условие для forward-unmatched-to;
- deliver-matched-email в <feedback-loop-processor> — то же деление для жалоб;
- check-spf-inbound — подлинность отчёта по SPF.
Области у составляющих разные. Обработчики — собственные блоки, проверка SPF — у источника и подчиняется слиянию источников.
Как они взаимодействуют. Зависимость пересылки руководство называет прямо: forward-unmatched-to работает только при deliver-unmatched-email true. Умолчания отклонения описаны отдельно, и ловушка возникает на стыке: включив check-spf-inbound ради подлинности, включаешь и отказ по результатам проверки — reject-spf-check-fail и reject-spf-check-temperror по умолчанию true.
Главная ловушка — включить проверку SPF, не глядя на отказы. check-spf-inbound вместе с умолчаниями reject-spf-check-fail и reject-spf-check-temperror отклоняет письма со сломанным или недоступным SPF: отчёты такого провайдера перестают доходить, а временная ошибка DNS превращается в отказ на MAIL.
Что делает Хаб. Применяет наполовину. Обработчики отказов и жалоб на узле стоят, и опознанное оба поглощают — deliver-matched-email no. Но и неопознанное Хаб не сохраняет, а отбрасывает (deliver-unmatched-email no), так что посмотреть на письмо, которого обработчик не понял, негде; подлинность отчётов по SPF не проверяется.
Рекомендуемые значения
Строки обработчиков и проверки:
| Строка | Умолчание | Что задать |
|---|---|---|
| deliver-matched-email, оба обработчика | false | оставить false |
| deliver-unmatched-email | true, если нет forward-unmatched-to | true и ящик, который читают |
| check-spf-inbound | false | true, но с решением об отклонениях |
| reject-spf-check-fail, reject-spf-check-temperror | true | задать явно |
Строки, умолчания и зависимость пересылки — из руководства (§ 3.3.3.1–3.3.3.4, § 3.3.4.2, § 3.3.7.22, § 3.3.7.69–3.3.7.71). Сама схема — наша гипотеза.
Пример в конфигурации
<bounce-processor> deliver-matched-email no deliver-unmatched-email yes forward-unmatched-to bounces-review@example.com <address-list> address /^bounce@bounce\./ </address-list> </bounce-processor>
Отчёты, которые обработчик не узнал, уйдут в ящик разбора, а не пропадут; адрес — для примера.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Проверить, что узел делает с неопознанными отчётами:
grep -n -A6 '<bounce-processor\|<feedback-loop-processor' /etc/pmta/config
deliver-unmatched-email no — неопознанное отбрасывается, и посмотреть на него негде.