Demo
Demo

Knowledge base

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

enable-tq-record-for-proxy-failure

<domain>

Whether to write proxy failures to accounting
in the configuration this is a lineenable-tq-record-for-proxy-failure falseinside the block <domain>
The only trace of a proxy failure in accounting

The line tells the node to record proxy connection failures as tq accounting records — queue-level transient errors. The default is false.

🔴 And it silently does nothing if the tq type is not selected in any accounting block. The manual says this directly. That is, there are two conditions for it to work, and both are easy to forget.

Why it is needed. Without it a proxy failure looks in accounting like an ordinary delivery failure, indistinguishable from a receiving server refusal. And these are completely different troubles: one is fixed on your own side, the other with patience.

The line is per receiver. It makes sense to enable it where noticeable traffic goes through the proxy — or in the asterisk block if there is one proxy for everything.

The main trap is enabling it without selecting the record type. There are two conditions, and the second is in another configuration block, at the accounting file. The line does not complain: simply nothing appears.
What the Hub does. It does not write it, although sending through proxies exists in the fleet.

🔎 And the tq type is not selected in telemetry — the records are d, b, rb, t, feedback-loop. So a proxy failure does not reach the Hub as an accounting record: both lines would have to be enabled — this one and tq in the set of types. For now the Hub learns proxy state from its own checks, not from accounting.

Recommended values

It works only when two conditions are met:

What Where
this line in the receiver block
the tq record type in records of at least one accounting block

tq records are voluminous — the vendor advises keeping them in a separate accounting file.

The false default and the “ignored without the tq type” rule come from the manual (§ 3.3.10.107). The argument about a proxy failure being indistinguishable from a receiving server refusal is ours.
Example configuration
# two conditions in different places of the configuration
<domain *>
    enable-tq-record-for-proxy-failure yes</domain>

<acct-file /var/log/pmta/transient.csv>
    records tq
</acct-file>
The second block is required: without the tq type the first line is ignored. A separate file is the vendor’s advice: there are many such records.
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 ends1 mistake▶

Enabling the line without selecting the tq record type

§ 3.3.10.107

What it costsThe line is ignored. Proxy failures do not get into accounting, and on the dashboard they are still indistinguishable from receiving server refusals.
How to spot itThe line is set, and there is not a single tq record in accounting.
How to do it rightAdd tq to records of at least one accounting block — preferably a separate one.
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
enable-tq-record-for-proxy-failure <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.107
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 directive lives in <domain> and merges by the usual receiver block rule: the most precise match by receiver name wins. The second condition — the set of record types — is set not here but at the accounting file.
⇄

Related directives

2 relations

Does not work without

Temporary queue failureThe record type proxy failures go into. § 3.3.10.107

Depends on

smtp-proxy-source-hostGlobalThe second way to configure a proxy; its failures are recorded the same way. § 3.3.10.107

Referenced from

records<acct-file>Extends what goes into tq records, if they are selected here at all. § 3.3.10.107

How to check on the node
Proxy failures are looked for among tq records — the first column names them:
cut -d, -f1 /var/log/pmta/transient.csv | sort | uniq -c
tq records will appear only if both conditions are met. Empty with the line enabled — check the set of types at the accounting file.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇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
reversible: harms only while it is set
Scenarios
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:disable-acct-recordsdiscard-as-bounceenable-source-ip-limits-on-sending-ipbounce-afterdkim-signAll 135 directives of the block →