deliver-matched-email

<feedback-loop-processor>Хаб задаёт сам

Доставлять ли письма, узнанные как жалобой
в конфигурации это строкаdeliver-matched-email falseвнутри блока <feedback-loop-processor>
То же имя ещё 1:<bounce-processor><feedback-loop-processor>— часть из них другие настройки, часть та же самая
Судьба письма после разбора

Обработчик узнал письмо, извлёк из него данные и записал их в учёт записью вида f. Эта строка решает, что делать с самим письмом. Умолчание — false, то есть выбросить.

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

Доставлять имеет смысл в двух случаях. Первый — адрес обработчика настоящий, и человек хочет видеть жалобы глазами. Второй — рядом работает своя программа, разбирающая те же письма по-своему.

В обычной схеме доставлять некуда: адрес вроде fbl@fbl.<домен> заводится ради обработчика, ящика за ним нет, и true здесь означал бы попытку доставить в никуда.

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

Обработчик у нас ловит fbl@fbl.<домен>. Ящиков за этими адресами нет: они существуют ради приёма и разбора, а не ради чтения. Данные уходят в Хаб вебхуком записями вида f — этого достаточно.

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

Ответ зависит от того, есть ли за адресом ящик:

Значение Когда
no (умолчание) адрес заведён ради обработчика, ящика нет
yes ящик настоящий и его читают

Данные в учёт попадают при любом значении.

Умолчание false и то, что письмо при этом значении выбрасывается, — из руководства (§ 3.3.4.2). Предупреждение про петлю — наше.
Пример в конфигурации
# адрес заведён ради обработчика: доставлять некуда
<feedback-loop-processor>
    deliver-matched-email no    deliver-unmatched-email no
    <address-list>
        address /^fbl@fbl\./
    </address-list>
</feedback-loop-processor>
Данные из распознанных писем уже записаны в учёт: выброс письма их не затрагивает.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают доставку на адрес, за которым нет ящика

наш опыт

Чем чреватоПисьмо уйдёт в доставку, получателя не найдёт и породит собственный отказ. Тот придёт на тот же адрес и снова попадёт в обработчик — до срабатывания счётчика пересылок.
Как заметитьВ журнале ошибки маршрутизации на адресах обработчика.
Как правильноОставить no там, где ящика нет; данные и так в учёте.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
deliver-matched-email <boolean>
Значения
yes | no | true | false
Умолчание
false § 3.3.4.2
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<feedback-loop-processor>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Наследования нет: строка живёт внутри своего <feedback-loop-processor> и решает судьбу писем, пойманных его списком адресов. У соседнего обработчика своя такая же строка.
Как проверить на узле
Проверять надо по учёту: записи должны появляться независимо от судьбы письма:
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
Записи вида f означают, что разбор работает. Их отсутствие — что письма не доходят до обработчика или не узнаются им; судьба письма после разбора тут ни при чём.
В Хабе
Управляется
Аналитика → Учёт узла
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Приём входящей почты