Demo
Demo

Knowledge base

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

retry-recipients-after

<domain>set by the Hub

How long to wait before retrying a specific recipient
in the configuration this is a lineretry-recipients-after 10minside the block <domain>
A recipient’s personal pause on top of the common schedule

retry-after controls the queue as a whole. This line adds a second lock — for each recipient separately. An address to which the receiver responded with a temporary 4xx error will not be tried again until this interval expires, even if the queue has reached its next attempt by then.

Hence a simple consequence: the effective pause for an address is the larger of the two. Setting the queue step to a minute and expecting attempts once a minute is pointless: a recipient that got a 4xx will still sit out the vendor default of ten minutes.

The point of the separation is that one queue carries many addresses. The receiver may have refused one mailbox (full) and accepted the rest; the common schedule has nothing to do with it, while the personal pause keeps you from hammering exactly the mailbox that said “later.”

The main trap. The line is not visible in calculations. People calculate the pace by retry-after and get one number of attempts, but in reality some addresses sit out their pause and miss the attempt. The discrepancy is especially noticeable with a short queue step: with retry-after 1m and this line at its default, nine out of ten attempts pass the refused address by.
What the Hub does. In the receiver policy template it is 20m with a queue step of 30m. The personal pause is deliberately shorter than the step: it works as a safety net, while the queue sets the pace. If the step is ever shortened, those twenty minutes will become the effective pause by themselves.
Recommended values

Keep it no longer than the queue step. Otherwise it, not retry-after, determines the real pace — and editing the schedule stops changing anything.

Zero is not needed here. Removing the pause brings back the behavior it was introduced to prevent: the queue polls the refused address on every attempt.

In the settings output it is printed in seconds. 600 in the dump is the same ten minutes of the vendor default, just in a different unit; no neighboring line behaves this way.

The “no longer than the queue step” rule is ours. From the manual here come the 10m default, the single interval and the fact that the address is not polled until the pause expires, regardless of the queue schedule.
Example configuration
# queue step — half an hour, personal address pause — twenty minutes
<domain gmail.com>
    retry-after 30m
    retry-recipients-after 20m</domain>
As long as the pause is shorter than the step, the queue sets the pace. Make it longer — and the queue schedule will stop mattering for addresses that got a 4xx.
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▶

Calculating the pace only from the queue schedule

§ 3.3.10.49

What it costsThe real pause for an address is the larger of the two. The “deadline divided by step” calculation gives an inflated number of attempts if the personal pause is longer than the queue step.
How to spot itThe queue has many attempts, yet a specific address is polled noticeably less often.
How to do it rightCalculate by the larger of the two values, or keep the personal pause shorter than the step.

Setting it longer than the step and then editing the schedule

our experience

What it costsEdits to retry-after stop changing anything: the pace is capped by the personal pause. The setting gets tweaked, there is no effect, and the cause is looked for in the wrong place.
How to spot itChanging the queue step has no effect on how often refused addresses are attempted.
How to do it rightKeep the personal pause shorter than the queue step — then the schedule sets the pace.
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
retry-recipients-after <time-interval>
Values
a single time interval — a number and the letter d, h, m or s; a list is not accepted here, unlike the queue schedule
Default
10m § 3.3.10.49
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. The line has no paired value for backoff mode — the same one applies in backoff. It is picked up by pmta reload.
⇄

Related directives

2 relations

Depends on

bounce-after<domain>The overall deadline: the personal pause does not extend it; it only reduces the number of attempts a specific address gets. § 3.3.10.49

Works together with

retry-after<domain>The schedule of the queue as a whole. The effective pause for an address is the larger of the two, not this one. § 3.3.10.49

Referenced from

Recipients deferred after a temporary refusalThe directive that sets the hold period. § 6.3.11

How to check on the node
The value is printed by the queue settings command — and printed in seconds, not as an interval:
pmta show settings gmail.com/vmta1 | grep -i retry-recipients-after
600 in the output means ten minutes. PowerMTA does not show how many addresses are currently sitting out a personal pause; the Hub does not count this either.
◇

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
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:bounce-afterretry-afterbackoff-retry-afterbackoff-to-normal-afterbackoff-upon-all-sources-disabledAll 135 directives of the block →