track-recipient-events

<domain>

Держать ли в памяти последние пятьдесят событий по получателям
в конфигурации это строкаtrack-recipient-events falseвнутри блока <domain>
Кому именно и что ответили — если включить

Включает память на последние пятьдесят событий по получателям очереди: доставки, отказы и отложенные письма. Глубина фиксированная, её не настроить — в отличие от max-events-recorded, где число задаёте вы.

Другой срез, чем у соседней директивы. max-events-recorded помнит ошибки очереди — «что не так с этим получателем вообще». Эта помнит события по адресам — «кому и что ответили». Вместе они и составляют то, что веб-монитор показывает на странице очереди: последние пятьдесят событий по получателям и последние десять ошибок.

Где смотреть. show queues и show topqueues печатают эти события по умолчанию, когда запись включена; ключ –no-rcpt-events их прячет. То, что ключ существует именно в таком виде — «спрятать», а не «показать», — говорит, что задуманы они как основной способ смотреть на очередь.

Умолчание — false. Пока не включите, ни консоль, ни веб-монитор про конкретные адреса ничего не скажут.

Главная ловушка. Память тратится на каждую очередь, а очередь — это пара «получатель + адрес отправки». Десять адресов отправки на двадцати приёмниках — двести очередей, то есть до десяти тысяч событий в памяти. Множитель здесь заметно больше, чем у max-events-recorded, который считает по домену. Включать в общем блоке на большом парке — решение, которое стоит принимать осознанно.
Что делает Хаб. Не пишет и события эти не собирает: при опросе узла он берёт из списка очередей имя, число получателей, объём и соединения. Что именно ответили конкретным адресам, Хаб знает из учёта — там та же информация лежит подробнее и переживает перезапуск.

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

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

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

На маленьком парке можно и постоянно. Два-три адреса отправки и десяток приёмников — это тридцать очередей, полторы тысячи событий; такой расход незаметен, а видеть последние ответы приёмника удобно.

Глубину не выбрать. Пятьдесят событий — величина MTA, настройки у неё нет. Нужен другой срез — max-events-recorded для ошибок очереди или учёт для истории.

Оценка расхода и совет включать на время — наши. Из руководства здесь умолчание false, фиксированная глубина в 50 событий и их состав: доставки, отказы, отложенные.
Пример в конфигурации
# включаем там, где разбираемся, а не на всём парке
<domain problem-mailbox.example>
    track-recipient-events true    max-events-recorded 50
</domain>
Две строки рядом дают полную картину по одной очереди: что отвечали конкретным адресам и какие ошибки были у очереди целиком.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Включают в общем блоке на большом парке

наш опыт

Чем чреватоПамять тратится на каждую очередь, а очередей столько же, сколько пар «приёмник + адрес отправки». На парке из десяти адресов и двадцати приёмников это две сотни очередей и до десяти тысяч событий в памяти.
Как заметитьРасход памяти MTA заметно вырос после включения записи.
Как правильноВключать в блоке конкретного получателя на время разбора. Постоянно — только на небольшом парке.

Ищут в этих событиях историю

§ 3.3.10.15

Чем чреватоХранится пятьдесят последних событий, и только в памяти. Перезапуск службы стирает их, а на нагруженной очереди пятьдесят событий набегают за минуты — вчерашнего там не будет.
Как заметитьВ выводе только свежие события, разбор вчерашнего случая невозможен.
Как правильноИсторию брать из учёта: там записи по каждому получателю лежат на диске и переживают перезапуск.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
track-recipient-events <boolean>
Значения
true или false (принимаются и yes/no); глубина фиксирована — 50 событий
Умолчание
false § 3.3.10.15
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Подхватывается по pmta reload, перезапуск не нужен; накопленные события перезапуск службы стирает, как и все данные в памяти MTA.
Как проверить на узле
События печатает сама команда просмотра очередей — при включённой записи они показываются по умолчанию:
pmta show queues problem-mailbox.example
pmta show queues --no-rcpt-events problem-mailbox.example
Разница между двумя выводами и есть то, что даёт директива: со вторым ключом события по получателям скрыты. Если они не показываются и без ключа — запись выключена. Хаб эти события не собирает; для истории смотрите учёт, там они переживают перезапуск.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью