Demo
Demo

Knowledge base

PMTA knowledge base›Block <smtp-listener>›Directive§ 3.3.17.17

inbound-proxy-timeout

<smtp-listener>

How long to wait for the load balancer header at the mail submission entry
in the configuration this is a lineinbound-proxy-timeout 5sinside the block <smtp-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, the equivalence of zero and never, dropping the connection on expiry and the “only with header acceptance enabled” condition come from the manual (§ 3.3.17.17).
Example configuration
# the load balancer is on the same network — a second is enough
<smtp-listener 0/0:2525>
    use-inbound-proxy yes
    inbound-proxy-timeout 1s</smtp-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>
Values
a time interval or never; 0 is equivalent to never
Default
5s § 3.3.17.17
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<smtp-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <smtp-listener>. The second kind of entry has the same line — these are different entries, not levels of one.
⇄

Related directives

2 relations

Does not work without

use-inbound-proxy<smtp-listener>The wait is counted only when header acceptance is enabled at all. § 3.3.17.17

Applies to

smtp-listenerGlobalThe line lives inside a listener and concerns connections to its address and port. § 3.3.17.17

Referenced from

inbound-proxy-timeout<transmissions-api-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 2525 </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.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Connect a sending platform
Neighboring settings of the block <smtp-listener>:use-inbound-proxysourcetls-certificateawait-slotimmediate-tlsAll 18 directives of the block →