Demo
Demo

Knowledge base

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

log-inbound-proxy

<transmissions-api-listener>

Whether to log the load balancer header at the Transmissions API input
in the configuration this is a linelog-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
What the load balancer actually sent

When a load balancer stands in front of the node, the client’s real address comes not from the connection but from the PROXY header at its start. The line writes this header to the log. The default is off.

It works only together with use-inbound-proxy. Without it the header is not expected, and there is nothing to record.

It investigates one class of faults: “the wrong address”. Source lists, per-address restrictions and statistics rely on what the node considers the client’s address. If the load balancer sends a header with unexpected content, all of that starts working on the wrong addresses, and the cause can be seen only here.

The header comes in two versions, and the engine detects which by itself. The log shows which one actually arrived — the second common reason to enable the line.

The main trap is looking for the cause of “the wrong address” in the source list. The list works correctly; what is wrong is the address the node extracted from the header. As long as the header is not visible in the log, the investigation starts from the wrong end.
What the Hub does. It does not write it: we do not put a load balancer in front of the nodes — submission API clients connect directly.

The line will be needed when a load balancer appears in front of the fleet: then it is worth enabling right away, for the break-in period, not after the first oddity with addresses.

Recommended values

Enabled for the load balancer break-in period:

Value When
no (default) there is no load balancer, or it was broken in long ago
yes connecting a load balancer or investigating “the wrong address”

Without use-inbound-proxy the line does nothing.

The default and the fact that the line applies only with header reception enabled come from the manual (§ 3.3.21.15). The investigation of the “wrong address” class is ours.
Example configuration
# breaking in the load balancer: watching what it actually sends
<transmissions-api-listener 0/0:2525>
    use-inbound-proxy yes
    log-inbound-proxy yes</transmissions-api-listener>
The first line is mandatory: without it the header is not expected and there is nothing to log.
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▶

Investigating “the wrong address” from the source list side

our experience

What it costsThe list works on the address the node extracted from the header. As long as the header is not visible, edits to the list explain nothing.
How to spot itThe submitter is on the list, yet the node responds with a refusal.
How to do it rightEnable this line and see which address actually arrived.

Enabling logging without enabling header reception

§ 3.3.21.15

What it costsWithout use-inbound-proxy the header is not expected, and there is nothing to record. The line silently does nothing.
How to spot itThe line is on, and there is not a single header entry in the log.
How to do it rightAdd use-inbound-proxy to the same block.
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
log-inbound-proxy <boolean>
Values
yes | no | true | false
Default
false § 3.3.21.15
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

2 relations

Same name in other blocks

log-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.15

Applies to

log-fileGlobalThe entries go into the very log set there. inference

How to check on the node
We watch the log while connecting through the load balancer:
grep -i proxy /var/log/pmta/log | tail -20
The lines will contain the header content and the address extracted from it. Nothing means the header did not arrive at all — and then the node will close the connection, as prescribed.
◇

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