Proxy gateways (gates).
PowerMTA and MailerQ
through SOCKS5.

The first screen explains why a sending server needs a proxy gateway. A diagram of one message in four blocks: over the PROXY protocol the MTA tells the gate “who I am” and “where to”, the gate opens a SOCKS5 tunnel through the rented proxy to port 25, and the recipient’s mail server sees the proxy’s address, not the server’s. Below are two lines: why there’s no other way — PowerMTA and MailerQ can’t use SOCKS5 with a login and password — and why the gate sits on the sending server itself rather than on the Hub. Reading this screen once is enough to understand what every message passes through. Further down the page — the path to sending for the selected server and the gate cards for mta-01 and mta-02.

Enlarge

• MTA — PowerMTA or MailerQ; finds the recipient’s mail server on its own.
• HUB-Gate — on the same node; only lets in its own node.
• Proxy — a rented address, a SOCKS5 tunnel to port 25.
• Recipient’s MX — sees the proxy’s address.
• Red line — neither PowerMTA nor MailerQ can use SOCKS5 with a login and password, but they can go through an intermediary over the PROXY protocol.
• Yellow line — the gate lives on the node itself; otherwise your whole fleet’s mail would pass through the panel.

The gate doesn’t touch the conversation with the mail server — it only splices the streams.

The “Path to sending” block answers one question: is the selected server ready to send mail through proxies? The six steps go in order: a gate on the node, a pool with this node, fit addresses, put into sending, written to the node, and handed to the email platform. On mta-01 all of them are done — every step has a green check mark, so the server is ready. Each step has a button to the screen where it’s done, so an unfinished step is easy to complete. The block is usually collapsed; in the screenshot it’s expanded. You open it when the server is set up but mail isn’t going through the proxies: the step without a check mark is where to look for the cause. The gates themselves are covered on the next screens.

Enlarge

• 1 · Gate on the node — hubgate 1.1.0 sits next to the MTA.
• 2 · Pool with this node — pools: 1; a proxy only reaches a node through a pool.
• 3 · Fit addresses in the pool — 3 of 3 passed acceptance: they respond, the protocol is detected, port 25 is open.
• 4 · Put into sending — each has its own subdomain, the address is in SPF, the records are visible.
• 5 · Written to the node — 3 of 3 — the gate knows all the tags.
• 6 · Handed to the email platform — sending points: 3.

You pick the server to check in the top right; the “collapse” link hides the block.

The gate card on mta-01 is an example of everything being fine. In the header: PowerMTA, the gate on 192.0.2.11:5000 and the echo port :5001, hubgate 1.1.0, running for 7 days 2 hours, the “Sending · marketing” pool. Below are five labeled buttons, counters for the week and since the service started, the address check and the tag table. The key thing on the screen is the check: the server knows all 3 of 3 addresses, so sending through them will work. Tunnel failures over the week are 0.6%, and you can see which proxy fails more often than the others — here it’s px-03. If the node has fewer addresses than the Hub’s records say, the missing ones are listed by name, and the “Write to node” button brings them back.

Enlarge

• Header — the server, the gate’s address, version, uptime, poll time, pool and the “running” status.
• Addresses on the node — 3 of 3 per the Hub’s records.
• Successful connections and tunnel failures — 2,377 and 14 (0.6%) over the week; since the service started — 2,793 and 17.
• ⟡ Foreign blocked, gate traffic, latency — 1,771, 471 MB and 1.2 ms — the service’s own counters since it started.
• Breaking tunnels — px-03 (7 of 793), px-02 (4 of 790), px-01 (3 of 808).
• Table — tag (what the MTA sees), upstream (where the gate goes), proxy, protocol, status and whether the gate knows about it.

A tag is the address the MTA asks the gate to present. Usually it equals the proxy’s exit address; for proxies with a rotating exit, the tag is taken from the reserved 240.0.0.0/4 network.

The second card is the gate on mta-02, which is due for an update. It’s been running for 14 days 22 hours on hubgate 1.0.4, while the Hub’s bundle already has 1.1.0 — hence the yellow “update available” mark. The “Reinstall” button updates the service without logging in to the server. There are more tunnel failures here — 1.6% over the week, and the main culprit, px-06, has already been pulled by the “Delivery rate dropped” rule: it isn’t in the server’s table, but its failures over the week still count against the gate. Next by failures come px-04 and px-05. Keep in mind that “Reinstall”, like “Restart”, starts the service again, and open tunnels are dropped.

Enlarge

• Version — 1.0.4 → 1.1.0 and the “update available” mark; “Reinstall” updates the service.
• Addresses on the node — 2 of 2.
• Over the week — 1,984 successful connections and 33 failures (1.6%); since start — 4,338 and 70.
• ⟡ Service counters — 3,733 foreign connections blocked, 714 MB passed through, latency 1.6 ms.
• Breaking tunnels — px-06 (15 of 792), px-04 (9 of 828), px-05 (9 of 397).

The “Delivery rate dropped” rule has already sent px-06 to quarantine, so it isn’t in the server’s table, but its failures over the week still count against the gate.

A list of servers that don’t have a proxy gateway yet. Fifteen servers send mail directly, from their own addresses — they don’t go through proxies. The first step toward sending through proxies is the “Install the gate” button in the server’s row: the service is installed and started only on that server and only after a confirmation. The “Configure” link leads to the server’s page. The names are the same as everywhere in the panel, so the server you need is easy to find. Servers where the MTA sends mail bypassing the gate would be shown on a separate line — there are none in the example. Once the gate is installed, the server goes on through the steps of the “Path to sending” block: pool, fit addresses, writing to the node.

Enlarge

• Server row — name and address: cl-01, lab-01, mq-01 … tx-02.
• Install the gate — installs and starts the service only on the selected server, after a confirmation.
• Configure — leads to the server’s page.
• Caption at the bottom — installation puts one file in place and allows it to accept connections only from its own node’s address.

Servers where the MTA sends mail bypassing the gate would be shown on a separate line — there are none in the example.

A block about the module’s main risk. The PROXY protocol has no password: whoever reaches the gate’s port gets the rented addresses for any purpose, and their owner takes the blame. That’s why the gate accepts connections only from its own server’s address and 127.0.0.1, and the screen shows this with a check, not a promise. For both gates you see which sources are allowed and that the table file with the proxy passwords is locked down with 640 root:hubgate permissions. If the sources line holds only the server’s address and 127.0.0.1, a foreign connection gets dropped. The Hub doesn’t configure the server’s firewall: the port is visible from the network, and the “Foreign blocked” tile on the gate card counts how many foreign connections were turned away.

Enlarge

• Red block — whoever reaches the gate’s port gets the rented addresses for any purpose, and their owner takes the blame.
• Allowed sources — on mta-01, 192.0.2.11 and 127.0.0.1; on mta-02, 192.0.2.12 and 127.0.0.1.
• Table file permissions — 640 root:hubgate on both servers.

The Hub doesn’t configure the server’s firewall: the port is visible from the network, scanners reach it, and only the list of sources keeps them out.