Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.58

process-x-schedule

<source>

Whether to read the x-schedule header and honor delivery windows
in the configuration this is a lineprocess-x-schedule falseinside the block <source>
A permission to leave the sending time to the message itself

The default is false. With the permission the engine reads time intervals from the x-schedule header and tries to deliver the message only within them. Without the permission the header is ignored, and the message goes out in the usual way, with no schedule at all.

How the windows themselves work is described separately — scheduled-delivery. Two consequences come from there that you need to know before enabling it: a schedule cancels the message lifetime, and a window is permission to try, not a promise to send.

The main trap is that the permission changes the rules by which messages expire. Without it, a message lives by the configured lifetime and bounces when the lifetime runs out. With it, the lifetime does not apply to the message at all: it lives until the end of its last window.

That is, a line that looks like “allow scheduling” actually hands the submitting side the decision of when to give up. A message with windows a week ahead will occupy the spool for a week.

What the Hub does. It does not write it: the permission stays at the vendor default, and the Hub does not set a header with windows.

The Hub keeps the warm-up schedule to itself — the scheduler decides when to submit a message and submits it at that moment. With this design it sees a missed send itself; had it handed the schedule over to the message, it would not see it.

Recommended values

What to set. The answer depends on who is responsible for a missed window:

Value When
no (default) the sending time is managed by the submitting side’s scheduler
yes messages are submitted as a batch in advance, and the node must spread them out over time

The second spares the submitting side scheduled jobs but in return hides failure: a window can close inside the node without a single attempt, and the submitting side will not find out.

The false default and the behavior with the permission turned off come from the manual, § 3.3.7.58. The cancellation of the lifetime and the behavior in retry mode are from § 11.13. The breakdown of cases is ours.
Example configuration
# the windows come in the message, the permission is granted to the source
<source 10.0.0.0/24>
    process-x-schedule true</source>
A message with windows in the header will be delivered only within them, and will bounce when the windows run out — not when the configured lifetime expires.
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▶

Enabling it without noticing that the lifetime is cancelled

§ 11.13

What it costsThe configured lifetime does not apply to messages with a schedule. Messages with distant windows sit in the spool until the end of the last window and take up space meant for the live queue.
How to spot itMessages older than the configured lifetime pile up in the queue.
How to do it rightLimit the last window on the submitting side and watch the spool after enabling it.

Setting the header without granting permission

§ 3.3.7.58

What it costsThe message goes out immediately and in full, and the header itself stays in the message. A mailing meant to be spread over time goes out in one piece.
How to spot itAll the messages of the batch went out at once, and the recipient sees a service header with the schedule.
How to do it rightGrant permission to the source block the submission falls under.

Believing that a window guarantees an attempt

§ 11.13

What it costsIf the queue is in retry mode at the time of submission, there will be no attempts within the window: delivery will start after the queue leaves that mode, possibly already outside the window.
How to spot itScheduled messages remained in the queue even though the window has passed.
How to do it rightSet several windows in a row rather than one, and do not treat the schedule as a replacement for a scheduler.
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
process-x-schedule <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.58
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. A permission granted in the 0/0 block goes to everyone — that is, any submission gets the right to occupy the spool until the end of its windows.
⇄

Related directives

1 relation

Applies to

Headers the sender uses to control deliveryOne of the six submission control headers, with its own permission on the source. § 3.3.7.58

Referenced from

retain-x-schedule<source>The first half of the pair; the manual calls them independent, and this is the case where independence creates a question rather than convenience. § 3.3.7.59

How to check on the node
The permission is visible in the configuration, the message schedule as a separate column of the listing:
grep -n 'process-x-schedule' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta list --schedule --maxitems=20
An empty schedule column means the windows were not set: either there is no permission, or the header arrived in the wrong form. For us it is always empty — the mechanism is not used.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇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
reversible: harms only while it is set
Scenarios
Connect a sending platform
Neighboring settings of the block <source>:retain-x-scheduleretain-x-dkim-keyprocess-x-dkim-keydefault-virtual-mtasmtp-serviceAll 74 directives of the block →