Узел узнаёт о судьбе письма двумя путями. В разговоре — и это попадает в учёт само. Письмом позже — и вот для этого нужны обработчики.
Их два, и устроены они одинаково. <bounce-processor> разбирает асинхронные отказы, <feedback-loop-processor> — жалобы. У каждого свой список адресов, своя пара решений о судьбе письма и своя возможность вложить образцы.
Четыре строки решают всё:
| Строка | Решает |
|---|---|
| deliver-matched-email | что делать с узнанным (умолчание — выбросить) |
| deliver-unmatched-email | что делать с остальным (умолчание — доставить) |
| forward-unmatched-to | куда переслать непонятое |
| forward-errors-to | куда переслать то, на чём разбор сломался |
🔴 Две строки связаны неочевидно: пересылка непонятого работает только при deliver-unmatched-email true. Иначе письмо выбрасывается раньше, и адрес пересылки бесполезен.
Приём — отдельный вопрос. Обработчик решает судьбу принятого письма. Чтобы письмо приняли, нужен relay-address и запись MX; без них отчёт отобьётся анти-релеем и до разбора не дойдёт.
🔴 И у нас deliver-unmatched-email no в обоих. Значит, всё, что обработчик не узнал, выбрасывается молча: агрегатные отчёты DMARC, которые мы сами запросили записью rua, письма служб на abuse@ и всё, что пишут на postmaster@. Лечится парой строк: true плюс forward-unmatched-to на живой ящик.
Собственных значений у механизма нет — их задают четыре строки в каждом из двух блоков:
| Что нужно | Как |
|---|---|
| принять письмо | relay-address плюс запись MX |
| поймать его обработчиком | список адресов внутри блока |
| записать данные | происходит само, записями rb и f |
| не потерять постороннее | deliver-unmatched-email true плюс пересылка |
# приём, разбор и сохранение постороннего — три разные вещи 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 ошибки▶
наш опыт
§ 3.3.3.1
5 связей
Разбор отказов, пришедших письмомПервый из двух обработчиков и его роль в разборе доставки. § 13.6Жалобы, разобранные узлом — и разбираются они вторымиВторой из двух обработчиков: жалобы пользователей почтовиков. § 13.7
deliver-unmatched-email<bounce-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.3.1deliver-matched-email<bounce-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.3.2forward-unmatched-to<bounce-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.3.4forward-errors-to<bounce-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.3.5deliver-unmatched-email<feedback-loop-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.4.1deliver-matched-email<feedback-loop-processor>Механизм, из которого эта строка — одно из четырёх решений о судьбе письма. § 3.3.4.2
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
3 статьи
◇Что делать с принятым письмомЧто узел делает с принятым входящим письмом: пересылает, кладёт в файл, гасит, передаёт программе или разбирает как отказ или жалобу.◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.