Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.17

Recipient events

critical

recipient events
A sequence of outcomes, not a summary

The last 50 delivery, bounce and deferral events for one queue — for real-time analysis.

They are off by default: track-recipient-events true in <domain> turns them on, for all receivers or for some. The events are visible in the output of show queues, show topqueues and on the queue page in the monitor, and they live in memory while the queue has recipients.

Unlike a summary, they show the sequence. A run of soft bounces in a row says one thing, alternating successes and bounces says something else entirely.

The main trap is expecting events from an emptied queue. They live in memory while the queue has recipients: once the queue drains, the sequence is gone. For the past, go to accounting.
What the Hub does. It does not enable them: track-recipient-events is not in the templates. The Hub takes message outcomes from accounting, where each arrives as a separate record.
Recommended values

When to look at events:

Question Events or not
what is happening with the queue right now yes
why the queue is stuck yes — together with the latest errors
what happened yesterday no — accounting
The number of events, the off default, where they are shown and in-memory storage come from the manual (§ 11.17). The split of questions is ours.
Example configuration
<domain *>
    track-recipient-events true</domain>
The manual’s example: enabling for all receivers; the same can be written in the block of a single domain.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
⇄

Related entries

3 relations

Works together with

Reputation monitoring inside the nodeA related mechanism: they work together. inference

Where you can see it

Queue state together with event historyThe command through which the mechanism is observed. § 11.17Three short histories for each queueThe screen where the mechanism is visible. § 11.17

How to check on the node
See a queue’s events:
pmta show queues gmail.com/vmta1
The “Recipient Events” block under the queue line holds the latest outcomes; without enabling it, the block is not there.
◇

What else to read

3 articles

◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Priority
critical