Knowledge base
A per-address rate that survives the proxy
Limits must count the address the receiver sees
The task. Sending through rented addresses, each with its own reputation and its own rate.
What it is made of:
- enable-source-ip-limits-on-sending-ip — moves the source-ip-max-* limits from the local address to the proxy client address;
- source-ip-max-msg-rate — message rate per address;
- source-ip-max-smtp-out — connections per address;
- enable-tq-record-for-proxy-failure — connection failures to the proxy get into accounting as tq records.
The parts have different scopes. Limits are set per recipient and per address, the switch per recipient, and it is sensible to set it once, in <domain *>. Changing the switch requires a restart, not a reload.
How they interact. The first line does not add to the others but changes their meaning: without it, the four source-ip-max-* limits count the node’s local address, shared by all proxies. The fourth is independent but serves the same purpose: without it, a proxy failure and a receiver failure look the same in telemetry.
The main trap is changing the switch with a reload. enable-source-ip-limits-on-sending-ip takes effect only after a service restart: after pmta reload the limits still count the local address, and there are no errors about it.
What the Hub does. It applies none of the four components — it does not need the setup. There are no source-ip-max-* limits: each proxy has its own sending address, and the limits of <domain> blocks are already counted per the queues of one rented address. The enable-source-ip-limits-on-sending-ip switch sat in <domain *> until Sep 15, 2026 and affected nothing — it was removed. There are no tq records, neither as a switch nor in the telemetry record type set, so a proxy failure is not visible in accounting.
Recommended values
Four lines:
| Line | Default | What to set |
|---|---|---|
| enable-source-ip-limits-on-sending-ip | false | true in <domain *>, then a restart |
| source-ip-max-msg-rate | unlimited | the rate of the address’s warm-up stage |
| source-ip-max-smtp-out | unlimited | few connections for a cold address |
| enable-tq-record-for-proxy-failure | false | true and the tq type in records |
The switch’s effect on the four limits, the restart, the limits and tq records come from the manual (§ 3.3.10.86, § 3.3.10.88, § 3.3.10.93, § 3.3.10.107). The scheme itself is our hypothesis.
Example configuration
<domain *> enable-source-ip-limits-on-sending-ip true enable-tq-record-for-proxy-failure true source-ip-max-msg-rate 198.51.100.0/24 200/h source-ip-max-smtp-out 198.51.100.0/24 2 </domain>
Each address in the range gets its own limit; tq records appear only if the type is in records.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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
Check the switch and the service start time:
pmta show settings gmail.com/vmta1 | grep '^enable-source-ip-limits-on-sending-ip ' systemctl status pmta | grep Active
true in the queue settings does not yet mean the node was restarted after the edit: the service start time must be later than the edit.