Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.19.4.2

Reserved merge variable names

critical

reserved mailmerge variables
You cannot give your own variables these names

Mail merge variable names that start with a star are taken by the engine. Five control the recipient’s message: *from — the envelope sender, *envid — the envelope identifier, *vmta — the sending address or pool, *jobid — the job, *parts — the set and order of parts.

The rest set delivery and SparkPost details: *schedule — the schedule, *priority — priority from 1 to 100, 50 by default, *subaccountid and *custommessageid. *to and *date are filled in automatically and cannot be overridden.

The star beats the configuration: *vmta overrides any other way of choosing the sending address, *envid and *jobid override what was set otherwise, *priority overrides the priority from <pattern-list>. Recipient data becomes a control channel.

The main trap is someone else’s mail merge on your node. *vmta overrides any configuration method of choosing the sending address: a source allowed to merge decides for itself which address its mail leaves through.
What the Hub does. It does not use mail merge: messages are submitted one per recipient, and the sending address is chosen by the sender’s domain. The reserved names matter to whoever enables mail merge — and to whoever accepts outside content on the node: these variables override the configuration.
Recommended values

Reserved names:

Variable What it sets
*from the envelope sender
*envid the envelope identifier
*vmta the sending address or pool
*jobid the job
*parts the set and order of parts
*schedule, *priority delivery schedule and priority
*subaccountid, *custommessageid SparkPost details
*to, *date filled in automatically, cannot be overridden
The star, the list of variables, what they do and the priority default come from the manual (§ 11.19.4.2). The conclusion about a control channel is ours.
Example configuration
# the recipient gets its own sending address and job
XDFN *vmta="mta4" *jobid="TravelAlerts"RCPT TO:<alice@example.com>
Based on the manual’s example: variables are set with XDFN commands before the recipient’s RCPT — several in one command.
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.
⇄

Related entries

3 relations

Does not work without

Numbered merge partsA related mechanism: they work together. § 11.19.4.3

Overrides

Six ways to choose a stream and the order among themA related mechanism: they work together. § 11.19.4.2Two tags the sender puts on a messageA related mechanism: they work together. § 11.19.4.2

Referenced from

Personalization inside the engineNames taken by the engine: your own variables must not be named that way. § 11.19.4.2

How to check on the node
Check who is allowed mail merge:
grep -rn 'allow-mailmerge\|always-allow-api-submission' /etc/pmta/
A source with mail merge can override the choice of sending address; the others cannot.
◇

What else to read

3 articles

◇Six ways to choose a stream and the order among themA message’s stream is set by a merge variable, an API call, a header, a pattern rule, a listener and a source default — the manual lists them by precedence.◇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.◇The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation · Address warm-up · Sender isolation
Priority
critical