Demo
Demo

Knowledge base

PMTA knowledge base›Block <transmissions-api-listener>›Directive§ 3.3.21.14

inbound-proxy-timeout

<transmissions-api-listener>

How long to wait for the load balancer header at the HTTP submission input
in the configuration this is a lineinbound-proxy-timeout 5sinside the block <transmissions-api-listener>
The same name 1:<smtp-listener><transmissions-api-listener>— some of them are other settings, some are the same one
Patience at the start of a connection

The load balancer header must arrive first, before anything else. The line sets how long to wait for it. The default is 5s, and when it expires the node drops the connection.

The value 0 is equivalent to never — that is, wait as long as it takes. This is a dangerous setting: a hung connection will hold an acceptance slot indefinitely.

It applies only together with use-inbound-proxy. Without it the header is not expected at all, and there is nothing to wait for.

Five seconds is a lot for a local network. The load balancer usually sits nearby and sends the header immediately; a second is more than enough, and a smaller value cuts off those who came around it faster.

The main trap is setting zero “so connections are not dropped.” Every hung connection will take an acceptance slot for good. When the slots run out, all submission will stop, and linking that to the wait setting will not be easy.
What the Hub does. It does not write it: there is no load balancer in front of the nodes.

🔎 When one appears, the default will be enough: the header arrives in the very first packet, and five seconds is already plenty.

Recommended values

Less means cutting off outsiders faster:

Value When
5s (default) always
1s the load balancer is on the same network
0 or never never: acceptance slots will be taken forever
The 5s default, zero being equivalent to never, dropping the connection on expiry and the condition “only with header reception enabled” come from the manual (§ 3.3.21.14).
Example configuration
# load balancer on the same network — a second is enough
<transmissions-api-listener 127.0.0.1:4433>
    use-inbound-proxy yes
    inbound-proxy-timeout 1s</transmissions-api-listener>
The value 0 here reads as “wait forever” and occupies an acceptance slot for every hung connection.
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▶

Setting zero so that connections are not dropped

our experience

What it costsZero means “wait forever.” Every hung connection takes an acceptance slot for good, and when they run out, submission stops.
How to spot itThe number of open incoming connections grows and does not drop.
How to do it rightRestore a finite value — five seconds is more than enough.
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
inbound-proxy-timeout { TIME-INTERVAL | never }
Values
a time interval or never; 0 is equivalent to never
Default
5s § 3.3.21.14
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<transmissions-api-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
No inheritance: the line lives inside its own <transmissions-api-listener>. The same line exists for the second kind of input — these are different inputs, not levels of one.
⇄

Related directives

1 relation

Same name in other blocks

inbound-proxy-timeout<smtp-listener>The same-named line of the mail listener; here it is about a separate entry point, the API’s own. § 3.3.21.14

How to check on the node
We connect and stay silent — the connection should close when the time expires:
time nc NODE 4433 </dev/null
The time until closing should match the set value. A connection that hangs longer means either zero in the value or that header acceptance is off altogether.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security
Neighboring settings of the block <transmissions-api-listener>:use-inbound-proxylog-inbound-proxytls-certificatetls-min-versiontls-ciphersAll 15 directives of the block →