Demo
Demo

Knowledge base

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

proxy-retry-after

<domain>

The retry interval when a queue stalls because of a proxy failure
in the configuration this is a lineproxy-retry-after the value of retry-afterinside the block <domain>
A separate step for a failure on our side

The third reason a queue goes into retry mode is neither a receiver refusal nor a name resolution error, but a failure of the connection to the proxy. For it, not retry-after but this line applies.

The logic is the same as for retry-after-dns-error: the receiver did not see this attempt. The connection did not reach its port, it received no messages, and the sender’s reputation is not at risk. So a short step is appropriate here — the manual’s example 5m,5m,10m is two to five times faster than the usual one.

It is set the same way as the regular schedule: with a single interval or as a ramp. Without its own value, retry-after is used — and then a proxy failure costs the queue as much as a receiver refusal.

The main trap. The line does not appear in the queue settings output. pmta show settings prints both retry-after and retry-after-dns-error, but this one is not in the list — there is no way to check the effective value on the node, and all that remains is to check against the configuration.
What the Hub does. It does not write it, although sending through proxies exists in the fleet. So the queue handles a connection failure to the gate or the proxy by the general retry-after — 30m from the policies template — that is, as unhurriedly as a receiver’s rejection.
Recommended values

Shorter than the usual step. A proxy failure is a malfunction on our side: a restart, a dropped connection, exhausted connections. It clears up in minutes, and there is no point in waiting half an hour.

A short ramp is more useful than an even step. 5m,5m,10m tries twice quickly — in case of a momentary failure — and backs off if the proxy is down for real.

Do not confuse this with the number of attempts within one delivery. How many times to try the proxy itself before moving on to the next one in the list is set by retry-attempts in the <proxy> block. This line is about when the queue returns to attempting at all.

The “short ramp versus even step” distinction is ours. From the manual here come the list syntax, the “equal to retry-after” default and the 5m,5m,10m example itself.
Example configuration
# a proxy failure clears up in minutes — we do not punish the queue for it
<domain example.com>
    retry-after 30m
    proxy-retry-after 5m,5m,10m</domain>
Without the second line, after a break in the connection to the proxy the queue would wait half an hour — as long as after a refusal from a receiver that never even saw the messages.
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▶

Relying on the default

§ 3.3.10.47

What it costsWithout its own value, retry-after is used. A break in the connection to the proxy that cleared up in a minute costs the queue half an hour of idle time — even though the receiver never saw this attempt.
How to spot itAfter the proxy recovers, the queue stays idle for tens of minutes more.
How to do it rightSet a short ramp: five minutes, five minutes, ten.

Looking for the line in the settings output

our experience

What it costspmta show settings does not print it. People decide that the directive was not applied and edit the configuration a second time — while it worked from the very beginning.
How to spot itThe line is in the configuration but not in the settings output.
How to do it rightCheck against the configuration, not the settings output.
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
proxy-retry-after <time-interval-list>
Values
a time interval or a comma-separated list of intervals, up to 30 rungs; each is a number and the letter d, h, m or s, without spaces
Default
the value of retry-after § 3.3.10.47
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 default depends on the neighboring line: without its own value, retry-after is used. It is picked up by pmta reload.
⇄

Related directives

3 relations

Depends on

bounce-after<domain>The overall deadline: the message will bounce once it passes, no matter how many attempts the node makes to get through via the proxy. § 3.3.10.47smtp-proxy-source-hostGlobalThe line that makes all of this work: without sending through a proxy there are no proxy failures. § 3.3.10.47

Same name in other blocks

retry-after<domain>The regular retry step, which this line replaces on a proxy failure and which becomes its default. § 3.3.10.47

Referenced from

A named proxy and three levels of its settingsWhat happens when the proxy list is exhausted: the queue’s retry schedule. § 3.3.10.47retry-attempts<proxy>What happens after the proxy list is exhausted: the queue retry schedule. § 3.3.22.5

How to check on the node
The effective value cannot be seen on the node — this line is not in the queue settings output. What remains is the configuration and the log of connections to the proxy:
grep -n proxy-retry-after /etc/pmta/config
grep -i proxy /var/log/pmta/pmta.log | tail -20
The absence of the line in the pmta show settings output is not a sign that it is unset: PowerMTA simply does not print it. The Hub does not collect proxy failure records — it learns proxy state from its own checks.
◇

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
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 →