Demo
Demo

Knowledge base

PMTA knowledge base›Block <signals>›Directive§ 11.1.6.2.12

process-x-sp-subaccount-id

<signals>

Whether to read the header with the subaccount number in the event export
in the configuration this is a lineprocess-x-sp-subaccount-idinside the block <signals>
The same name 1:<inline-seeding><signals>— some of them are other settings, some are the same one
One line for two blocks

The default is false. With true the engine takes the subaccount number from the message’s x-sp-subaccount-id header and attributes the message’s events to it.

The number is a positive integer; zero and negative numbers are not accepted.

The line is shared by two blocks. The manual says so directly: set either here or in the <inline-seeding> block, it applies to both. That is, there is no separate decision “for event export” and “for seeding” — there is one decision and two places to write it.

With mail merge the header does not work — there the number is set with the *subaccountid variable.

And most importantly: the header (like the merge variable) overrides the subaccount set by the configuration. The submitting side takes precedence.

The main trap is that you allow it, but the sender decides. A subaccount is meant to separate traffic between clients, and by enabling the header you hand that separation to whoever submits the message: they can attribute their traffic to any number, including someone else’s. The line in the configuration then stops working — the header overrides it.

The other half is that it is shared by two blocks. Having enabled it for event export, you have enabled it for seeding too, even if you never thought about seeding at all.

What the Hub does. It does not write it: it does not use the Signals service — it collects events with its own telemetry through the accounting webhook.

Our separation of clients rests on our own sending streams and submission logins, not on another service’s subaccounts.

Recommended values

What to set. The question is whom you trust with separating traffic:

Value When
false (default) the configuration assigns the subaccount: the submitting side does not choose it
true submission comes from you, and it is more convenient to put the number in the message than to multiply blocks

The second is reasonable where the submitting platform is yours. It is not worth giving it to someone else’s: it will be able to attribute traffic to another subaccount with no obstacle at all.

The false default, the requirement for the number, the header’s precedence over the configuration, the caveat about the merge variable and the line being shared with the seeding block come from the manual, § 11.1.6.2.12. The breakdown of cases is ours.
Example configuration
# the line applies both here and in the seeding block — it is one line for two blocks
<signals>
    api-key 0123456789012345678901234567890123456789
    process-x-sp-subaccount-id true</signals>
A message with the header x-sp-subaccount-id: 123 will attribute its events to subaccount 123 — and override the number set by the configuration.
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 reading for someone else's submitting platform

§ 11.1.6.2.12

What it costsThe platform gets the right to attribute its traffic to any subaccount, including someone else’s. Separation by clients stops separating anything, and what the configuration set is overridden by the header.
How to spot itIn the service’s events one client shows subaccount numbers belonging to another.
How to do it rightKeep the default and assign the subaccount through the configuration.

Treating the line as a setting of this block only

§ 11.1.6.2.12

What it costsIt is shared by two: enabled for event export, it is enabled for seeding too. A restriction meant to be local turns out to be shared.
How to spot itSeeding behavior changed after the event export block was edited.
How to do it rightRead both lines as one and check both blocks at once.

Setting the header in a message assembled by merging

§ 11.1.6.2.12

What it costsFor mail merge the manual requires the *subaccountid variable and does not read the header. The number will not be set, and the events will go to the subaccount from the configuration or to none.
How to spot itThe subaccount is set on ordinary messages and not set on messages assembled by mail merge.
How to do it rightSet the number with the merge variable.
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-sp-subaccount-id { yes | no }
Values
yes | no | true | false
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<signals>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <signals>, but it has no inheritance in the usual sense: it is shared with the seeding block, and set in either of the two it applies to both. It cannot be overridden at the block level — only the message header itself overrides it.
⇄

Related directives

1 relation

Works together with

Six ways to choose a stream and the order among themThe same order of precedence as for stream selection: the message header is stronger than the configuration. inference

How to check on the node
The line is visible in the configuration; look at both blocks at once:
grep -n -A3 '^<signals>\|^<inline-seeding>' /etc/pmta/config
The line in either of the two blocks enables header reading for both. Whether the header worked is visible from the subaccount in the service’s events: it will be the one from the message, not the one from the configuration.
◇

What else to read

3 articles

◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sender isolation
Neighboring settings of the block <signals>:privacy-policyhtml-edit-error-modecustom-message-id-headerretain-x-sp-subaccount-idengagement-trackingAll 16 directives of the block →