Demo
Demo

Knowledge base

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

retain-x-sp-subaccount-id

<inline-seeding>

Whether to keep the subaccount header in the outgoing message
in the configuration this is a lineretain-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
Will the service header reach the recipient

Having read the x-sp-subaccount-id header, the node removes it by default — the service mark must not reach the recipient. A line with the value true tells it to keep the header. The default is false.

There is also a second way for it to stay: if header reading is turned off (process-x-sp-subaccount-id set to false), the header stays in the message regardless of this line — the node simply does not touch it.

🔴 The header reveals internal structure. The subaccount number is your way of dividing clients; once it reaches the recipient, it tells them more than they need to know and ends up in their archives.

The line is shared by two mechanisms — enabled either here or in <signals>, it applies to both.

The main trap is keeping the header “just in case.” The service mark goes to the recipient and lives in their mail forever. If your own side needs it downstream, it is better to take it from accounting rather than from the sent message.
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) always
true the receiving side needs the header, and it is your own

With reading turned off the header stays regardless of this line.

The false default, keeping the header with reading turned off and the line being shared with the event export block come from the manual (§ 11.2.2.2.6).
Example configuration
<inline-seeding>
    api-key 0123456789abcdef012345678901234567890123
    process-x-sp-subaccount-id true
    retain-x-sp-subaccount-id false</inline-seeding>
The default, written explicitly: the header is read and removed, and it will not reach the recipient.
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▶

Leaving the service header in the message

our experience

What it costsThe subaccount number goes to the recipient and stays in their archive. It is an internal division of clients that they have no reason to know.
How to spot itThe header with the number is visible in the delivered message.
How to do it rightRestore the default; take what is needed downstream from accounting.

Configuring the line separately in two blocks

§ 11.2.2.2.6

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
retain-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

Affects

The telemetry contractIf the header is needed downstream, take it from accounting, not from the sent message. § 11.2.2.2.6

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