Demo
Demo

Knowledge base

PMTA knowledge base›Recipe

The daily warm-up quota in one submission

Merging instead of a thousand separate messages

The task. A warm-up plan sends an exact number of messages from exact addresses at exact times with content that differs between recipients — and with one submission per message this requires a scheduler that must run without interruption.

What it is made of:

  • mailmerge-smtp-extensions — the batch goes over the same SMTP that is already in use;
  • merge-reserved-variables — the sending address, job and envelope sender for each recipient within one submission;
  • merge-parts — differences in message structure;
  • scheduled-delivery — the time travels in the message as the x-schedule header instead of being held by a scheduler.

The parts have different scopes. Permission to merge is set on the source (allow-mailmerge), delivery windows on the message. Both are properties of what is submitted, not of the node, so one node serves both batched warm-up and ordinary mail.

How they interact. Each part removes one reason to submit messages one by one: merge removes the one-by-one submission itself, reserved variables the loss of control at the recipient level, parts the uniformity, windows the scheduler. The price is the exact moment of sending: the node decides within the window, and if the queue is in retry mode at that time, delivery starts only after it leaves that mode.

The main trap is allowing merge for a source someone else uses. The *vmta variable overrides any sending address selection from the configuration: with merge allowed, the submitter decides which address the mail goes out from.
What the Hub does. It does not apply this: warm-up is submitted over SMTP one message per recipient through a shared login, the sending address is named by the X-Virtual-MTA header, and the daily quota and timing are held by the Hub scheduler. Text variety comes from spintax; merge and delivery windows are not used.
Recommended values

What each part takes on:

Warm-up task What solves it Where it is set
one submission per quota XMRG, XDFN, XPRT submission
the recipient’s address and job *vmta, *jobid recipient variables
different texts *parts recipient variables
sending time the x-schedule header message
the right to merge allow-mailmerge source
The commands, variables, parts and delivery windows come from the manual (§ 11.19.4–11.19.5, § 11.13). The scheme itself is our hypothesis.
Example configuration
XMRG FROM:<warmup@example.com>
XDFN *vmta="vmta-new" *jobid="warmup-day3" *parts=1,2
RCPT TO:<alice@example.org>
XPRT 1
The x-schedule header is set in the first part among the other headers; the last part goes with LAST.
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
Check which source is allowed to merge:
grep -rn 'allow-mailmerge\|always-allow-api-submission' /etc/pmta/
The line is needed only in the warm-up source: where someone else submits, *vmta hands them the choice of address.