Demo
Demo

Knowledge base

PMTA knowledge base›Block <proxy>›Directive§ 3.3.22.3

protocol-version

<proxy>

The PROXY protocol version for this proxy
in the configuration this is a lineprotocol-version the VirtualMTA's proxy-protocol, then the global settinginside the block <proxy>
Three levels of one setting

The line sets the protocol header version — 1 or 2.

The default here is not a value but a chain. If it is not set here, the engine looks at proxy-protocol on the sending address that uses this proxy; if it is not set there either, it takes the node-level proxy-protocol, where the default is 1. Three levels, and the most specific one wins.

The difference between the versions is practical. The first is a text line that everyone understands. The second is binary and can carry additional fields, which means that include-tlv and passing the queue domain work only with it.

The proxy chooses, not the node: set the version your proxy server understands.

The main trap is setting the second version where the proxy knows only the first. It will not parse the header, and the connection will be closed. From the node’s point of view this is an ordinary proxy failure — it will move on to the next one in the list or go into retry, without reporting the reason.
What the Hub does. It does not write it: there are no <proxy> blocks in the configuration. The Hub sets the protocol version with the proxy-protocol 2 line in every sending address that goes through a proxy — to pass the queue domain to the gate.
Recommended values

The version is dictated by the proxy, not the node:

Value When
1 (chain default) the proxy is old or the queue domain is not needed
2 include-tlv is needed — passing the queue domain

It is worth setting here only when the proxy servers differ and their versions do not match.

Both versions, the three-level default chain and the second-version requirement for passing fields come from the manual (§ 3.3.22.3, § 3.3.22.4). The remark that the proxy dictates the version is ours.
Example configuration
# the version is set on the proxy itself: a neighboring one may use a different one
<proxy mta-proxy>
    server proxy.internal:9999
    client 16.80.77.101  client2.hostname.com
    protocol-version 2    include-tlv domain
</proxy>
The second line from the bottom works only with version 2 — that is why they are written as a pair.
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 version 2 for a proxy that knows only the first

our experience

What it costsThe proxy will not parse the header and will close the connection. The node will see an ordinary failure and move on to the next proxy or into retry — the reason will not appear in its log.
How to spot itThe proxy is first in the list, but the second one always does the work.
How to do it rightMatch the version against the proxy’s configuration; when in doubt, start with the first.
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
protocol-version <integer>
Values
1 or 2
Default
the VirtualMTA's proxy-protocol, then the global setting § 3.3.22.3
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<proxy>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The line lives in <proxy> and overrides the two levels above: first proxy-protocol on the sending address, then the same line at the node level. The most specific one wins — that is, this one.
⇄

Related directives

2 relations

Same name in other blocks

proxy-protocolGlobalA level lower in precision: this line overrides it. § 3.3.22.3

Applies to

A named proxy and three levels of its settingsThe mechanism for which this line sets the protocol version. § 3.3.22.3

Referenced from

include-tlv<proxy>Requires the second protocol version: the first has no extra fields. § 3.3.22.4

How to check on the node
The version is not visible from the node side — check it on the proxy:
tcpdump -A -i any -c 20 'port 5000'
The first version starts with the text PROXY TCP4 …, the second with a binary signature. Look on the proxy or on the path to it; on the node itself the header already goes into the connection.
◇

What else to read

3 articles

◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.◇A named proxy and three levels of its settingsThe block carries the proxy address, the external sending address, the protocol version, the field type and the number of attempts; the first two lines are required.

In the Hub
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Sending through proxies
Neighboring settings of the block <proxy>:clientserverinclude-tlvretry-attemptsAll 5 directives of the block →