Knowledge base

A fake receiver inside the node itself

Dummy SMTP ("blackholing")
Where to send when you cannot send outside

The manual calls this “blackholing” — a black hole. The node brings up a fake SMTP receiver on its own address: it accepts connections, holds a full conversation, answers like a real server — and throws away everything it received.

Why. To check how much the node can handle without sending a single message outside. The capacity calculations from the first chapter are estimates; this is a way to get a real figure on your own hardware, your own configuration and your own messages.

The receiver is off until the port is set. The default of dummy-smtp-port is zero, and zero here means “do not listen”. The other seven lines configure how convincingly it pretends: which extensions it announces, what network latency it simulates, what it does when there are no slots left.

The main trap is that by default fake traffic gets into real statistics. dummy-smtp-update-stats is on, and the load run shows up in the monitor on a par with production sending: counters, charts, reports. They cannot be separated afterwards.
What the Hub does. It does not use it. Checking a node’s ceiling would be useful for the Hub — but the fake receiver lives on the production node and by default writes to its own statistics; enabling this on a working node is not possible without separate safeguards.
Example configuration
# fake receiver on a local address, the port turns it on
dummy-smtp-ip 127.0.0.1
dummy-smtp-port 2525dummy-smtp-latency 100
dummy-smtp-update-stats false
# and the flow that knocks on it
<domain loadtest.local>
    smtp-hosts [127.0.0.1]:2525
</domain>
The second highlighted line is no less important than the first: without it the load run gets mixed into the node’s real counters.
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▶

Running load without turning off statistics updates

§ 3.3.1.57.8

What it costsFake traffic gets into the monitor counters on a par with production. Reports for the day of the run are wrong, and the flows cannot be separated retroactively.
How to spot itA sending spike in the monitor that was not in the mailing.
How to do it rightBefore the run, turn off dummy-smtp-update-stats.

Bringing up the fake receiver on a production node

our experience

What it costsIt listens on a real port of a real machine. A mistake in any recipient’s server list — and production mail goes into the black hole, while being marked as delivered.
How to spot itSome messages are counted as delivered but did not reach recipients.
How to do it rightKeep the fake receiver only on a separate node, and limit the listening address to local.
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.
How to check on the node
Whether the fake receiver is listening is visible on the node itself; whether a flow goes to it — from the queue list:
ss -ltn | grep 2525
pmta show queues | grep -i loadtest
Empty output from the first command means the port is not set or is zero — the receiver is off. The Hub does not use this mechanism.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning · Prepare a node for sending