Demo
Demo

Knowledge base

PMTA knowledge base›Recipe

Retiring an address without bouncing mail

An order in which the queue has time to empty

The task. A warm-up plan has finished, the address goes back to the hosting provider or a proxy is removed — and the sending address must be removed from a node where mail may still be sitting on it.

What it is made of:

  • show queues — whether any queue holds mail for this address;
  • pause queue — optionally: stop attempts while the fate of the messages is decided;
  • cancel-vmta — delete the definition when nothing is behind the address;
  • change-vmta-live — instead of deleting: change the definition and keep the mail in the queue.

The parts have different scopes. Node level and sending address level. Checking and deleting are separate operations with a gap between them, and mail manages to arrive in that gap unless submission to the address is stopped beforehand.

How they interact. The scheme exists because deletion bounces everything left in the queue with the code 5.3.5 (no such virtual MTA) — the bounce originates on our own node and looks like a delivery failure. The check is one command; redirecting instead of deleting keeps the mail. The order matters: stop submission, check, remove.

The main trap is deleting an address with a non-empty queue. Messages that have already selected the removed address neither wait nor go out through another address, but bounce with the code 5.3.5 (no such virtual MTA) — and the classifier will take them for receiver bounces.
What the Hub does. It applies half of it. The Hub sees queues by address in the monitor, and “Pause queue” is in the “Control” section. But the Hub removes a sending address from the node not with cancel-vmta and not with a redirect, but by regeneration: the pair disappears from the addresses file on the next configuration apply.
Recommended values

Order:

Step How When to go on
stop submission remove the address selection rule new messages do not go to the address
check pmta show queues ‘*/vmta-old’ no queues with messages
optionally pmta pause queue ‘*/vmta-old’ while deciding whether to send the rest
remove delete the block and pmta reload the queue is empty
Deletion, live change, the bounce code and the commands come from the manual (§ 9.5.1, § 9.5.2, § 6.3.14, § 6.3.25). The scheme itself is our hypothesis.
Example configuration
# are there messages left for the address being removed
pmta show queues '*/vmta-old'pmta pause queue '*/vmta-old'
Empty output from the first command — the block can be deleted and the configuration reloaded; otherwise wait or redirect.
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
After deletion, check whether the node bounced messages itself:
grep -c 'no such virtual MTA' /var/log/pmta/acct-*.csv
A non-zero number — messages were bounced by the address deletion, not by the receiver; their addresses must not be added to suppression.