Demo
Demo

Knowledge base

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

client

<proxy>critical

The external address the proxy uses to reach the receiving server
in the configuration this is a lineclientinside the block <proxy>
The address the receiving server will see

The line tells the proxy which address to go out from to the receiving server. This is the external sending address — the one Gmail will see, and the one whose reputation you are warming up.

The port is optional, zero by default. So is the name in the second part: if it is not set, the name of the sending address the connection came from is used.

🔴 The node checks only the form of the entry. The manual says so directly in a comment on the example: the node cannot make sure that such an address is actually configured on the proxy. A typo in the address means messages leaving from the wrong address with a configuration that looks perfectly fine.

The proxy is not visible in accounting. The sending address field will show exactly this address, and the destination field the receiving server’s address; passing through the proxy is transparent. It can be seen only through dlvProxy* fields added to the set.

The main trap is a mismatch between this line and the proxy’s configuration. The node tells the proxy “go out from 16.70.55.233,” and if the proxy has no such address, the behavior depends on the proxy: it may use its main address — and the entire warm-up goes to the wrong address. Check from the receiving server’s side.
What the Hub does. It does not write it: there are no <proxy> blocks in the configuration. The Hub passes the proxy’s external address as a tag — the third value of the smtp-proxy-source-host line — and the gate uses it to choose which proxy to go out through. The Hub itself keeps the tag and the proxy matched: it writes both /etc/pmta/proxy.txt and the gate table /etc/hubgate/upstreams.tsv.
Recommended values

Three parts, of which one is required:

Part Required What it means
address yes the proxy goes out from it
port no zero by default
name no the sending address’s name by default

The name is worth setting explicitly if the proxy has its own reverse DNS records: receiving servers notice a mismatch between the name in the greeting and the reverse record.

The optional port and name, the name default and the warning that the node checks only the form of the entry come from the manual (§ 3.3.22.2, § 11.3). The proxy’s transparency in accounting comes from § 11.3.
Example configuration
# the address is external: the receiving server sees it and reputation is counted by it
<proxy mta-proxy-a>
    server 10.1.2.3:5000
    client 16.70.55.233:0  client.hostname.com</proxy>
The name in the second part is set explicitly — that is more reliable: otherwise the sending address’s name is used, and the external address’s reverse record may be different.
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▶

Making a typo in the address and not noticing

§ 11.3

What it costsThe node checks only the form of the entry and does not know whether such an address is configured on the proxy. Messages will leave from whatever address the proxy picks, and warm-up and reputation will be counted against the wrong one.
How to spot itThe headers of delivered messages show an address different from the one in the configuration.
How to do it rightCompare the list of addresses on the proxy with all the client lines; check with a message to a seed mailbox.

Looking for the proxy in accounting

§ 11.3

What it costsIt is not in the regular fields: the sending address recorded is the proxy’s outgoing address, and the destination is the receiving server. Passing through the proxy is transparent.
How to spot itIn accounting everything looks like direct delivery.
How to do it rightAdd the dlvProxy* fields to record-fields for the record types you need.
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
client <address>
Values
an address, optionally a colon and a port, optionally a name
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>. Each block describes one outgoing address; to have several addresses, you need several blocks.
⇄

Related directives

3 relations

Does not work without

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

Depends on

host-nameGlobalIf the name in the second part of the line is not set, the sending address’s name is used. § 3.3.22.2

Applies to

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

How to check on the node
Check from the receiving server’s side — the node will not show this:
dig +short -x 16.70.55.233
The reverse record must match the name in the second part of the line. The real check is a message to a seed mailbox: its headers will show the address it actually came from.
◇

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>:serverinclude-tlvprotocol-versionretry-attemptsAll 5 directives of the block →