События получателей

критично

recipient events
Последовательность исходов, а не сводка

Последние 50 событий доставки, отказа и задержки по одной очереди — для разбора в реальном времени.

По умолчанию выключены: включает их track-recipient-events true в <domain>, для всех приёмников или для части. События видны в выводе show queues, show topqueues и на странице очереди в мониторе и живут в памяти, пока в очереди есть получатели.

Отличие от сводки в том, что видна последовательность. Череда мягких отказов подряд говорит одно, чередование успехов и отказов — совсем другое.

Главная ловушка — ждать событий у опустевшей очереди. Они живут в памяти, пока в очереди есть получатели: очередь разошлась — и последовательность исчезла. За прошлым идут в учёт.
Что делает Хаб. Не включает: track-recipient-events в шаблонах нет. Исходы писем Хаб берёт из учёта — там каждый приходит отдельной записью.
Рекомендуемые значения

Когда смотреть события:

Вопрос События ли
что сейчас происходит с очередью да
почему очередь стоит да — вместе с последними ошибками
что было вчера нет — учёт
Число событий, выключенное умолчание, место показа и хранение в памяти — из руководства (§ 11.17). Разграничение вопросов наше.
Пример в конфигурации
<domain *>
    track-recipient-events true</domain>
Пример руководства: включение для всех приёмников; то же можно записать в блок одного домена.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Как проверить на узле
Посмотреть события очереди:
pmta show queues gmail.com/vmta1
Блок «Recipient Events» под строкой очереди — последние исходы; без включения его не будет.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера
Важность
критично