<smtp-listener>
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.”
🔎 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.
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.
# enable together with the load balancer, not in advance <smtp-listener 0/0:2525> use-inbound-proxy yes inbound-proxy-timeout 5s </smtp-listener>
what people get wrong and how it ends2 mistakes▶
§ 3.3.17.16
our experience
3 relations
smtp-listenerGlobalThe line lives inside a listener and concerns connections to its address and port. § 3.3.17.16The load balancer header at the entranceThe mechanism this line enables. § 3.3.17.16
inbound-proxy-timeout<smtp-listener>The wait is counted only when header acceptance is enabled at all. § 3.3.17.17log-inbound-proxy<smtp-listener>There is nothing to record until reception of the load balancer header is enabled. § 3.3.17.18use-inbound-proxy<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.13
nc -zv NODE 2525
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.