Demo
Demo

Knowledge base

PMTA knowledge base›Procedure§ 9.5.2

Removing a sending address — and what happens to its queue

critical

Canceling a VirtualMTA
Removing a sending address bounces everything left behind it

The dangerous half of address management, and the manual describes it precisely. The removal itself is simple: delete or comment out the definition and reload the configuration. The connection overlap is the same as when changing an address.

What matters is something else: what happens to messages that have already chosen this sending address. They bounce. They are not deferred and do not leave through another stream — they bounce, with their own delivery code 5.3.5 (no such virtual MTA).

The manual separately distinguishes this code from a similar one. 5.5.0 specified Virtual MTA ‘…’ does not exist is a refusal at submission, when a message is only being put on the node with a header naming a nonexistent sending address. Two codes, two different moments, and confusing them means looking for the cause on the wrong side.

The bounce originates on our node. It says nothing about the recipient, and the bounce classifier must not add such addresses to any suppression lists.

The main trap is the order. Checking the queue after removal is pointless: there is nothing left to ask about, the messages have bounced. And a check without stopping submission is nearly useless — new messages will arrive between it and the reload.
What the Hub does. It can remove a sending address — by rebuilding the configuration. It does not fulfill the preconditions, though: it does not look at whether a queue remains behind the address being removed. The difference between “looking” and “not looking” here is the difference between calmly taking an address out of service and a batch of silent bounces for the client. The check costs one command.
Recommended values

The recipe has no values — it has steps. Only one thing is decided here: what to do with the rest of the queue.

Decision How Cost
let it finish stop submission and wait for the queue to drain time; the address is still occupied
move it by rerouting reroute-to-virtual-mta to another sending address messages will leave from a different address than intended
change the address instead of removing the change recipe — the queue is preserved the sending address name stays in the configuration
accept the loss remove right away messages bounce; the classifier must not treat this as the recipient’s fault
Both bounce codes and the “edit plus reload” order come from the manual (§ 9.5.2). The analysis of decisions about the remainder is ours.
Example configuration
# removal is a configuration edit, not a command
# <virtual-mta shop-example-com>
#     smtp-source-host 203.0.113.10 shop.example.com
# </virtual-mta>
A commented-out definition and a deleted one are equivalent. After the reload, messages left behind this sending address will bounce with code 5.3.5; an attempt to submit a new message with its name in the header will give a different code — 5.5.0, already at submission.
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 ends3 mistakes▶

Removing an address without looking into the queue

§ 9.5.2

What it costsEverything left behind it bounces. The bounces look like delivery bounces and end up in recipient statistics, even though the cause is entirely ours.
How to spot itA spike of bounces right after the configuration is applied, for messages to different recipients and with no common cause on their side.
How to do it rightStop submission, check the queue, then remove. The check is one command with the name substituted.

Confusing the two bounce codes

§ 9.5.2

What it costs5.3.5 — the message was already on the node and could not leave; 5.5.0 — the message was not accepted onto the node at all. The causes and the sides are different, the wording is similar, and the analysis goes astray.
How to spot itPeople look for an error in submission, while the messages bounced at delivery. Or the other way around.
How to do it rightLook at the code. 5.3.5 — the node configuration changed under the queue; 5.5.0 — the sender named a nonexistent name.

Removal bounces end up in suppression

our experience

What it costsRecipient addresses go onto the blocklist for an event that has nothing to do with them. After that, messages to these people are not sent at all — for a reason that never existed.
How to spot itAfter an address is taken out of service, some recipients stop receiving the campaign for no visible reason.
How to do it rightThe bounce classifier should tell internal bounces apart: a bounce caused by removing a sending address says nothing about the recipient and must not go into suppression.
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.
Inheritance
A recipe never has inheritance — it is a procedure. Inheritance matters at the check step: messages could have chosen this sending address not only with a header but also by a pattern rule or a source default. When stopping submission, disable all ways of selecting it, not just one.
⇄

Related entries

3 relations

Does not work without

Queue state together with event historyThe check before removal: are there still messages tied to this sending address. inference

Works together with

Refusal at the greetingUnlike a refusal from the receiving server, this bounce originates on our node and says nothing about the recipient. inference

Can be replaced by

Change a sending address when messages are already queuedChanging a definition preserves the messages, removing it does not; the choice is made before, not after. § 9.5.2

How to check on the node
The recipe’s only mandatory check is whether any queues remain behind this sending address:
pmta show queues */shop-example-com
Empty output means removal is safe. Non-empty output shows how many messages will bounce if it is removed now. The check is done after stopping submission and immediately before the edit: the gap between it and the reload should be minimal.
◇

What else to read

3 articles

◇The regular expression dialectConfiguration regular expressions are Perl-compatible, based on the PCRE library: that is how sending address selection, reply rules, bounce categories, address lists and signing headers are written.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Bounce classification · Sending address rotation
Priority
critical