Demo
Demo

Knowledge base

PMTA knowledge base›Block <inline-seeding>›Directive§ 11.2.2.2.5

process-x-sp-subaccount-id

<inline-seeding>

Whether to read the header with the subaccount number
in the configuration this is a lineprocess-x-sp-subaccount-idinside the block <inline-seeding>
The same name 1:<inline-seeding><signals>— some of them are other settings, some are the same one
Who decides whose traffic this is

The line allows the node to read the x-sp-subaccount-id header and take the subaccount number for seeding data from it. The default is false, and then the header is ignored and stays in the message.

🔴 The header is stronger than the configuration. If it is present and allowed, the subaccount number from the configuration is ignored. That is, the submitting side gets the right to decide which account the traffic is attributed to — and this needs to be understood before enabling it.

Mail merge has its own path: there, instead of the header, the *subaccountid variable is used, and it also overrides the configuration.

The line is shared by two mechanisms. The vendor stipulates directly: enabled in either <inline-seeding> or <signals>, it applies to both.

The main trap is enabling it without thinking about who sets the header. The submitting platform will be able to attribute its traffic to any subaccount, and the separation by clients will stop being your decision.
What the Hub does. It does not write it: we do not use the vendor’s seeding. Our separation of clients goes through our own streams, not through another service’s subaccounts.
Recommended values

The decision depends on trust in the submitting side:

Value When
false (default) the subaccount is set by the configuration
true the submitting side is trusted and knows the client itself
The false default, the header’s precedence over the configuration, the caveat about the mail merge variable and the line being shared with the event export block come from the manual (§ 11.2.2.2.5).
Example configuration
<inline-seeding>
    api-key 0123456789abcdef012345678901234567890123
    process-x-sp-subaccount-id true</inline-seeding>
With the line enabled, the number from the header overrides any 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 ends2 mistakes▶

Enabling it without checking who sets the header

our experience

What it costsThe number from the header overrides the configuration. The submitting platform will be able to attribute its traffic to any subaccount.
How to spot itSeeding data appears under someone else’s subaccount.
How to do it rightKeep false where the submitting side is not fully trusted.

Configuring the line separately in two blocks

§ 11.2.2.2.5

What it costsThe line is shared: enabled in either seeding or event export, it applies to both. Different values in the two blocks will not produce different behavior.
How to spot itOne block has true, the other false, and they behave the same.
How to do it rightTreat it as one setting for two mechanisms.
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
<inline-seeding>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside <inline-seeding>, and there is one such block per node. But its effect is shared with <signals>: enabled in either of the two, it works for both.
⇄

Related directives

1 relation

Works together with

Six ways to choose a stream and the order among themThe same technique: the message header overrides what the configuration sets. inference

How to check on the node
Check it on a sent message — the header is either there or not:
grep -i "x-sp-subaccount-id" /var/log/pmta/log | tail -10
It is more reliable to look at the headers of a message that reached a seed mailbox: there you can see whether the header went to the recipient or was removed.
◇

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 <inline-seeding>:retain-x-sp-subaccount-idbatch-frequencyeligibility-ttlpersist-thresholdapi-keyAll 6 directives of the block →