База знаний PMTA›Механизм§ 13.6

Разбор отказов, пришедших письмом

критично

bounce processor

Работает первым, до обработчика жалоб

Часть отказов приходит не в разговоре с приёмником, а отдельным письмом позже. Обработчик <bounce-processor> опознаёт такие письма на адресах из своего списка и пишет записи учёта rb — отказ — и rs — прочие отчёты о состоянии.

Разобранное письмо можно погасить или доставить дальше: deliver-matched-email и deliver-unmatched-email решают судьбу опознанных и неопознанных писем. Изменение списка требует перезапуска службы.

Порядок важен: этот обработчик разбирает почту раньше обработчика жалоб. Если адрес подходит обоим, а неопознанное не доставляется, жалоба до <feedback-loop-processor> не дойдёт — списки адресов лучше держать непересекающимися.

Главная ловушка — пересечь списки с обработчиком жалоб. Обработчик отказов идёт первым: адрес из обоих списков заберёт он, и жалоба, пришедшая на этот адрес, так и не станет записью f.

Что делает Хаб. Настроен: обработчик слушает bounce@bounce.<домен> и роль-адреса dmarc@, postmaster@, abuse@, оба варианта доставки выключены — опознанное становится записями rb, остальное гасится. Записи rb уходят в Хаб вебхуком учёта; обратный адрес bounce@bounce.<домен> включается галочкой в генераторе конфигурации.

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

Настройки обработчика:

Настройка	Что решает
список адресов	какие письма разбирать как отчёты
deliver-matched-email	доставлять ли опознанные; по умолчанию no
deliver-unmatched-email	доставлять ли неопознанные; по умолчанию yes

Для точного учёта руководство советует уникальный обратный адрес на письмо, а не общий bounce@.

Записи rb и rs, два переключателя с умолчаниями, перезапуск и порядок обработчиков — из руководства (§ 13.6, § 13.7). Разбор ловушки — наш.

Пример в конфигурации

<bounce-processor>
    deliver-matched-email no
    deliver-unmatched-email no
    <address-list>
        address /^bounce@bounce\./    </address-list>
</bounce-processor>

Так настроен узел Хаба: опознанные отчёты становятся записями rb, всё прочее гасится.

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

⇄

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

3 связи

Конфликтует

Жалобы, разобранные узлом — и разбираются они вторымиСмежный механизм: они работают вместе. § 13.7

Работают в паре

Обратный адрес, в который вписан получательСмежный механизм: они работают вместе. inference

Где это видно

Разобранный отказ извнеЗапись учёта, в которой результат и виден. § 13.6

Сюда ссылаются

Два обработчика входящих отчётов и что с ними делатьПервый из двух обработчиков и его роль в разборе доставки. § 13.6

Как проверить на узле

Проверить, что отчёты разбираются:

grep -h '^rb,' /var/log/pmta/acct*.csv | tail -5

Нет строк rb при идущих отказах — проверить MX поддомена bounce. и обратный адрес писем.

◇

Что ещё почитать

3 статьи

◇Категория отказа в учёте — настраиваемая, а не вендорскаяСтрока bounceCat в каждой записи учёта берётся из списка образцов, который можно дополнить своими правилами и своими названиями категорий.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.

В Хабе

Цена ошибки: обратимо: вредит, пока стоит
Сценарии: Классификация отказов · Подавление адресов
Важность: критично