На какие исходы приходит отчёт — решает каждый получатель

per-recipient notification
Настройка получателя, а не письма

Запрос отчёта — свойство получателя, а не письма. Одна подача может просить разного по разным адресам: за своим наблюдать, за чужими молчать.

Значений четыре, и три из них складываются: отчёт при успехе, при неудаче, при задержке — в любом сочетании. Четвёртое стоит особняком: не сообщать ни о чём.

Умолчание совпадает с тем, чего обычно и хотят: сообщать о неудачах, молчать в остальных случаях.

Запрос путешествует вместе с получателем и исполняется в момент доставки: решает подающая сторона, выполняет узел.

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

Вторая половина — тише: запрос о задержке. Он приходит не один раз, а по расписанию, пока задержка длится, — и как часто, решает уже настройка получателя notify-of-delay-every, а не подающая сторона.

Что делает Хаб. Не запрашивает ничего: библиотека отправки запросов на отчёты не ставит, и умолчание протокола — «сообщать о неудачах» — до узла не доходит как явный запрос.

Впрочем, разницы это не делает: в источниках подачи действует suppress-local-dsn true, то есть локальные отчёты узел не формирует вовсе. Исходы Хаб сводит по записям учёта, приезжающим вебхуком, — это и точнее, и дешевле, чем письма.

Пример в конфигурации
# умолчание — отчёт только при неудаче; запрос ставит подающая сторона
RCPT TO:<user@example.com> NOTIFY=FAILURE,DELAY
Запрос идёт в команде протокола, а не в конфигурации: узел его исполняет, но не назначает. Значение NEVER отключает отчёты для этого получателя целиком.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Запрашивают отчёт об успехе на массовой рассылке

§ 7.4.18

Чем чреватоОтчёт приходит на каждое доставленное письмо. Обратный поток сравнивается по объёму с самой рассылкой, при том что те же сведения уже лежат в записях учёта.
Как заметитьВходящий объём растёт вместе с исходящим, а содержимое — отчёты об успешной доставке.
Как правильноЗапрашивать только неудачу либо не запрашивать ничего и сводить исходы по учёту.

Ждут, что частоту уведомлений о задержке решает отправитель

§ 3.3.10.17

Чем чреватоОтправитель запрашивает уведомление, а как часто его слать, решает настройка получателя на узле. Ожидание «сообщат один раз» не сбывается: писем приходит столько, сколько уместилось в интервал.
Как заметитьПо одному задержанному письму приходит несколько уведомлений.
Как правильноНастроить интервал на узле — или не запрашивать уведомления о задержке вовсе.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Что реально запрошено, видно только в самом разговоре SMTP — узел этого не показывает:
grep -n 'suppress-local-dsn\|notify-of-delay-every' /etc/pmta/config /etc/pmta/virtualhost.txt
grep -i 'NOTIFY=' /var/log/pmta/pmta.log | tail -10
Вторая команда даст что-то только при включённом протоколировании команд. Первая важнее: если локальные отчёты подавлены, запросы получателей не исполняются вовсе, что бы в них ни стояло.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Классификация отказов