PowerMTA: Reaction on the node side

The engine responds in the same connection where it saw the rejection

The task. A receiver starts rejecting or deferring messages from one sending address. A reaction on the next telemetry poll is minutes late; a reaction to the reply itself is instant, and only the node is capable of it.

What it is made of:

<smtp-pattern-list> — the replies worth reacting to, as regular expressions;
backoff-max-msg-rate — the rate on a match;
backoff-retry-after — pauses between attempts on a match;
backoff-reroute-to-virtual-mta — the strongest reaction: the queue’s messages go out through another sending address or pool while the queue is in backoff mode.

The parts have different scopes. The reply list is attached in the recipient block, and backoff values are set per recipient inside a sending address — the whole scheme is expressed in the narrowest scope PowerMTA has.

How they interact. The point is the division of labor. The node has the receiver’s reply in hand and acts before the next message. The Hub sees the same receiver across all addresses and nodes for weeks. That is why the Hub writes the rules and the node executes them. This works only if backoff values differ from normal ones: rate and retries match the normal values by default, and switching the mode without them changes nothing.

The main trap is switching the mode without backoff values. A match in <smtp-pattern-list> faithfully switches the queue to the mode, but backoff-max-msg-rate and backoff-retry-after take the normal values by default — a queue “in backoff mode” presses on the receiver with the same force.

What the Hub does. It applies it in full. All fifteen blocks of the policies template carry smtp-pattern-list blocking-errors — the replies on which a queue enters backoff mode; the backoff values are written from the node preset in the mailbox provider rules inside the sending address, and backoff-reroute-to-virtual-mta moves the queue to a reserve address on the same node when there is one. Addresses under warm-up get no backoff lines. The Hub writes the rules and the node executes them — exactly the division of labor the setup describes.

Recommended values

Reactions by strength:

Reaction	Line	What happens
brake	backoff-max-msg-rate	fewer messages to the same receiver
pause	backoff-retry-after	less frequent attempts
reroute	backoff-reroute-to-virtual-mta	the queue’s messages, including new ones, go out from another address until the mode ends

The mode=backoff action, the backoff lines and rerouting come from the manual (§ 3.3.15, § 3.3.10.41, § 3.3.10.48, § 3.3.10.59). The division of labor is our hypothesis.

Example configuration

<smtp-pattern-list blocking-errors>
    reply /421 .*(rate|too many)/ mode=backoff</smtp-pattern-list>
<domain [*.]yahoo.com>
    smtp-pattern-list blocking-errors
    backoff-max-msg-rate 50/h
    backoff-reroute-to-virtual-mta vmta-reserve
</domain>

The expression is for illustration; while the queue is in backoff mode, messages go out from vmta-reserve, and the optional after= delays the rerouting.

yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.

Knowledge base

Reaction on the node side

Sending scripts

MTA & delivery

Ecosystem

Information