Demo
Demo

Knowledge base

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

server

<proxy>critical

Proxy server address and port
in the configuration this is a lineserverinside the block <proxy>
Where the node goes instead of the receiving server

The line sets the address and port of the proxy itself — the one the node connects to instead of the recipient’s mail server. It can be written as an address or a name.

One of the block’s two required lines. The manual says it directly: a <proxy> block must contain both server and client. Without either of them it is meaningless.

Name resolution stays with the node. It still looks up the recipient’s MX itself and decides which address to connect to — and then connects to the proxy and tells it that address in the protocol header. The proxy only carries it out.

The address here is internal. The whole point of the setup is that the nodes sit on internal addresses, and only one machine faces the outside — the proxy. The port is required: this role has no standard one.

The main trap is thinking that the proxy decides where to deliver. The node decides: it does the name resolution and picks the receiving server. The proxy gets a ready pair of “from which address” and “to which one” — and if it is configured differently, messages will go to the wrong place, and the node will not know about it.
What the Hub does. It does not write it: there are no <proxy> blocks in the configuration, and the Hub’s gate is built on the smtp-proxy-source-host line. The gate address is its second value — the same thing the server line sets here.
Recommended values

It can be written in two ways; the port is required:

Value When
10.1.2.3:5000 an address — the usual case for an internal network
proxy.internal:9999 a name — when the proxy moves around

There is no default: the line is required.

Both lines of the block being required and both forms of writing come from the manual (§ 3.3.22, § 3.3.22.1). The remark that name resolution stays with the node comes from § 11.3.
Example configuration
# two required lines: where to go and which address to go out from
<proxy mta-proxy-a>
    server 10.1.2.3:5000    client 16.70.55.233:0  client.hostname.com
</proxy>
The address in the first line is internal — it is the proxy itself. The address in the second is external: the proxy will go out from it to the receiving server.
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▶

Creating a block with only one of the two required lines

§ 3.3.22

What it costsThe block requires both the proxy address and the outgoing address. With one line it does not work, and the error surfaces when the configuration is applied.
How to spot itConfiguration validation complains about the proxy block.
How to do it rightAdd the second line — client.

Expecting the proxy to find the recipient on its own

§ 11.3

What it costsThe node does the name resolution and passes the proxy a ready destination address. A proxy configured to go somewhere else will silently send messages to the wrong place.
How to spot itAccounting shows delivery, but recipients do not see the messages.
How to do it rightCheck the proxy’s configuration: it must connect to the address that came in the header.
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
server <endpoint>
Values
an address or a name, a colon, a port number
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
There is no inheritance: the line lives inside its <proxy>. There can be several blocks, each with its own name, and sending addresses choose between them with a use-proxy line.
⇄

Related directives

2 relations

Does not work without

client<proxy>The block’s other required line: one says where to connect, the other which address to go out from. § 3.3.22.1

Applies to

A named proxy and three levels of its settingsThe mechanism in which this line is half of the required minimum. § 3.3.22.1

How to check on the node
The first thing worth checking is whether the proxy is reachable from the node:
nc -zv 10.1.2.3 5000
A refused connection means the proxy cannot be reached, and messages will go into retry or to the next proxy in the list. The protocol exchange itself is verified only by delivery.
◇

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
Priority
critical
Neighboring settings of the block <proxy>:clientinclude-tlvprotocol-versionretry-attemptsAll 5 directives of the block →