Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.15

track-recipient-events

<domain>

Whether to keep the last fifty recipient events in memory
in the configuration this is a linetrack-recipient-events falseinside the block <domain>
Who exactly got which answer — if enabled

Enables a memory for the last fifty recipient events of the queue: deliveries, bounces and deferred messages. The depth is fixed and cannot be configured — unlike max-events-recorded, where you set the number.

A different slice than the neighboring directive. max-events-recorded remembers queue errors — “what is wrong with this recipient domain in general.” This one remembers events by address — “who got which answer.” Together they make up what the web monitor shows on the queue page: the last fifty recipient events and the last ten errors.

Where to look. show queues and show topqueues print these events by default when recording is enabled; the –no-rcpt-events option hides them. The fact that the option exists in exactly this form — “hide,” not “show” — suggests they are meant as the main way to look at a queue.

The default is false. Until you enable it, neither the console nor the web monitor will say anything about specific addresses.

The main trap. Memory is spent on each queue, and a queue is a “recipient domain + sending address” pair. Ten sending addresses across twenty receivers are two hundred queues, that is, up to ten thousand events in memory. The multiplier here is noticeably larger than for max-events-recorded, which counts by domain. Enabling it in the general block on a large fleet is a decision worth making consciously.
What the Hub does. It does not write it and does not collect these events: when polling a node it takes the name, the number of recipients, the volume and the connections from the queue list. What specific addresses were answered, the Hub knows from accounting — the same information lies there in more detail and survives a restart.

The directive is useful for manual investigation, when you need to see the queue’s latest events right now without digging into accounting.

Recommended values

Enable it for the duration of an investigation, not forever. Put it in the block of the recipient you are investigating, and remove it afterwards. In the general block the value is multiplied by the number of queues.

On a small fleet it can be permanent. Two or three sending addresses and a dozen receivers are thirty queues, fifteen hundred events; such consumption is unnoticeable, while seeing the receiver’s latest answers is convenient.

The depth cannot be chosen. Fifty events is an engine constant, it has no setting. For another slice use max-events-recorded for queue errors or accounting for history.

The consumption estimate and the advice to enable it temporarily are ours. From the manual here come the false default, the fixed depth of 50 events and their composition: deliveries, bounces, deferrals.
Example configuration
# enable it where you are investigating, not across the whole fleet
<domain problem-mailbox.example>
    track-recipient-events true    max-events-recorded 50
</domain>
The two lines together give the full picture for one queue: what specific addresses were answered and what errors the queue as a whole had.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling it in the general block on a large fleet

our experience

What it costsMemory is spent on each queue, and there are as many queues as there are “receiver + sending address” pairs. On a fleet of ten addresses and twenty receivers that is two hundred queues and up to ten thousand events in memory.
How to spot itThe engine’s memory consumption grew noticeably after recording was enabled.
How to do it rightEnable it in a specific recipient’s block for the duration of an investigation. Permanently — only on a small fleet.

Looking for history in these events

§ 3.3.10.15

What it costsFifty latest events are stored, and only in memory. A service restart erases them, and on a loaded queue fifty events accumulate in minutes — yesterday’s will not be there.
How to spot itThe output has only fresh events, investigating yesterday’s case is impossible.
How to do it rightTake history from accounting: there the records for each recipient are stored on disk and survive a restart.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
track-recipient-events <boolean>
Values
true or false (yes/no are accepted too); the depth is fixed at 50 events
Default
false § 3.3.10.15
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload, no restart needed; a service restart erases accumulated events, like all data in the engine’s memory.
⇄

Related directives

2 relations

Works together with

max-events-recorded<domain>The other half of the same thing: that one remembers queue errors, this one events for specific recipients. § 3.3.10.7

Where you can see it

Queue state together with event historyThe command that prints these events; the –no-rcpt-events option hides them. § 6.3.14

How to check on the node
The events are printed by the queue view command itself — with recording enabled they are shown by default:
pmta show queues problem-mailbox.example
pmta show queues --no-rcpt-events problem-mailbox.example
The difference between the two outputs is what the directive gives: with the second option the recipient events are hidden. If they are not shown even without the option, recording is off. The Hub does not collect these events; for history look at accounting, where they survive a restart.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability
Neighboring settings of the block <domain>:disabled-source-ip-notifybackoff-notifymax-events-recordeddisable-acct-recordsdkim-signAll 135 directives of the block →