Demo
Demo

Knowledge base

PMTA knowledge base›Block <virtual-mta-pool>›Directive§ 3.3.13.7

rewrite-list

<virtual-mta-pool>

The rewrite rule list shared by the pool's addresses
in the configuration this is a linerewrite-listinside the block <virtual-mta-pool>
The same name 1:<virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
One set of rewrite rules for the whole group

The behavior is the same as for a sending address: messages leaving through a pool member go through the named list. What changes is the scope — each member gets the line.

The point of writing it here is one — not repeating it. A wave of addresses that must rewrite the return address the same way is described with one line instead of repeating it for each.

The override is complete. A member with its own line does not extend the pool one but replaces it: lists do not add up.

And the same remark as for the definition: the manual attaches the list to <source>, and in a fleet that is more correct — the return address depends on the sending domain, not on which node address the message left from.

The main trap is expecting them to add up. A member’s own line replaces the pool one entirely. By adding “its own” list to an address, you silently turn off the shared one for it — and this is discovered from the return addresses in accounting, not from a configuration error.
What the Hub does. It does not write it: the list is attached to sources, as the manual advises. The line is yet another example of why a pool is worth using as a scope: today the Hub repeats shared settings for each sending address separately.
Recommended values

The value is the name of a declared list, as for a sending address. Only one thing is decided here — where to keep the rules:

Where Who gets it Careful
in the pool all members a member’s own line will replace it entirely
on a member only that member the pool one stops applying to it
in <source> all submission, before the stream is selected applies earlier and independently
Inheritance by members comes from the manual (§ 3.3.13). The “replaces rather than extends” rule is common to directive inheritance.
Example configuration
# the same rewriting for the whole wave of addresses
<virtual-mta-pool warmup-wave-3>
    rewrite-list abc    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
Both members will get the abc list. If mta1 gets a line of its own, the pool one will stop applying to it entirely rather than being extended.
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▶

Giving a member its own list on top of the pool one

§ 3.3.13

What it costsA member’s line replaces the pool one entirely. The shared rules stop applying to this address, and the wrong return address goes out.
How to spot itOne address in the group sends with a different return address.
How to do it rightList all the needed rules on the member in one list — lists do not add up through inheritance.

Setting up rewriting here when it is already set up in the source

§ 3.3.18

What it costsThe lists apply independently, and both of them: first at acceptance, then when the sending address is selected. The address is rewritten twice.
How to spot itIn accounting the return address matches neither of the two expectations.
How to do it rightKeep rewriting in one place. For a fleet that is <source>.
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.
Reference data
Syntax
rewrite-list <see-reference>
Values
the name of a declared rewrite rule list
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta-pool>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A pool is the middle of three levels. The line goes to each member, and a member’s own line overrides it entirely. Attaching it in <source> is separate and independent: it applies when the message is accepted, that is, before the sending address is selected.
⇄

Related directives

2 relations

Same name in other blocks

rewrite-list<virtual-mta>The manual gives the definition for a sending address; here is only what writing it at the pool level changes. § 3.3.12.13

Applies to

A group of sending addresses with traffic sharesOne of the directives written at the pool level; a member’s own line overrides it. § 3.3.13.7

How to check on the node
What applies to a member is visible from the return address in accounting:
pmtaacctfind --output csv[orig,vmta,rcpt] /var/log/pmta/acct-*.csv | head -20
If one member’s return address differs from the others’, it has its own line — which replaced the pool one. Look in the block of the sending address itself.
◇

What else to read

3 articles

◇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.◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Warm-up built into the engineA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation
Neighboring settings of the block <virtual-mta-pool>:virtual-mtadomain-keymax-smtp-msg-ratemax-smtp-outsuppression-listsAll 9 directives of the block →