Demo
Demo

Knowledge base

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

use-inbound-proxy

<transmissions-api-listener>

Whether to expect a load balancer header on the HTTP submission entry point
in the configuration this is a lineuse-inbound-proxy falseinside 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
The real client address from behind a load balancer

When a load balancer stands in front of the node, the connection comes from it, and the real client address is lost. The line enables accepting the PROXY header: the load balancer sends it first, and the node extracts the client’s address and port from it and treats them as the source from then on. The default is false.

The engine detects the version itself — it understands both without configuration. This distinguishes the input from the output, where the version is set explicitly.

🔴 The header is mandatory, not optional. With the line on, the node closes the connection if no header arrives. That is, a client that connects directly, bypassing the load balancer, will be rejected — and that is right, since otherwise the address could be spoofed.

Everything that looks at the source address depends on this: <source> blocks, limits, statistics. A mistake here looks not like a proxy error but like “the lists work incorrectly.”

The main trap is turning it on when there is no load balancer. Nobody will send the header, and the node will close every connection. Submission will stop completely, and the reason will not appear in the log unless log-inbound-proxy is on.
What the Hub does. It does not write it: we have no load balancer in front of the nodes, and submitters connect directly.

🔎 If a load balancer appears, the line has to be enabled at the same time as it, not in advance: without it the line stops receiving entirely.

Recommended values

The line and the load balancer are enabled together:

Value When
no (default) clients connect directly
yes a load balancer stands in front of the node and already sends the header

There is no intermediate state: the header is either always expected or never.

The false default, automatic version detection, extracting the address and port and closing the connection without a header come from the manual (§ 3.3.21.13). The remark about address spoofing is ours.
Example configuration
# enable it together with the load balancer, not in advance
<transmissions-api-listener 127.0.0.1:4433>
    use-inbound-proxy yes    inbound-proxy-timeout 5s
</transmissions-api-listener>
With the line on, a direct connection to this entry point will be rejected — no header will come from it.
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▶

Enabling header acceptance before the load balancer exists

§ 3.3.21.13

What it costsThe node closes every connection, because nobody sends the header. Receiving stops completely.
How to spot itAll connections to this entry point drop right after being established.
How to do it rightTurn the line off, or put in a load balancer that sends the header.

Looking for the cause of the “wrong address” in the source lists

our experience

What it costsThe lists work by the address extracted from the header. Until you can see what the load balancer sent, editing the lists explains nothing.
How to spot itThe submitter is on the list, yet the node responds with a refusal.
How to do it rightTurn on log-inbound-proxy and look at the real address.
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
use-inbound-proxy <boolean>
Values
yes | no | true | false
Default
false § 3.3.21.13
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
There is no inheritance: the line lives inside its <transmissions-api-listener> and concerns the connections of its address and port. The same line exists for the second kind of entry point — these are different entry points, not levels of one.
⇄

Related directives

1 relation

Same name in other blocks

use-inbound-proxy<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.13

How to check on the node
The check is direct — connect bypassing the load balancer:
nc -zv NODE 4433
The connection must be closed: no header will come from nc. If it stays open, the line was not applied. Through the load balancer the connection must go through.
◇

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>:log-inbound-proxyinbound-proxy-timeouttls-certificatetls-min-versiontls-ciphersAll 15 directives of the block →