Knowledge base

PMTA knowledge base›Block Global›Directive§ 11.1.6.1.1

enable-signals

Global

Where exactly event export is enabled
in the configuration this is a lineenable-signals true at global scope when the configuration block existsinside the block Global
Three levels and one inheritance subtlety

The line decides for which streams the node exports events. There are three levels: the node, a sending address pool, an individual sending address. The rule is the usual one: the pool is stronger than the node, the address stronger than the pool.

The default is non-obvious: if the line is absent at the node level, it counts as true when there is a <signals> block — for compatibility with earlier versions, where export was enabled by the block itself.

Two things are appended to the true value: the subaccount (subaccount=N) and the tracking domain (tracking-domain=X). Only to true — they cannot be appended either to false or to a rule list name.

🔴 true without a subaccount does not inherit it but resets it. The manual says so directly: a value without the qualifier cancels the subaccount set at the level above. Exactly the same subtlety as with seeding.

The fourth form is a rule list name: enable-signals ListName attaches a <signals-filter>. In that case everything that matched no rule counts as disabled.

The main trap is writing true at a lower level to “enable it here too.” The subaccount is lost, and the stream’s events go out without being tied to the client. To simply inherit, the line is not written at all.
What the Hub does. It does not write it: we do not use export to external analytics, and there is no <signals> block in the configuration.

🔎 The structure of the scope is worth knowing all the same: the same technique — three levels with overriding — works for us in limits and in signing, and the reset subtlety occurs only here and in seeding.

Recommended values

Four forms of writing, and three of them come with caveats:

Value What it means
do not write it inherit from above — the only way
true enable, resetting the subaccount from above
true,subaccount=N enable with the specified subaccount
false disable; qualifiers cannot be appended
ListName selection by rules; anything unmatched is disabled
The three inheritance levels, the default when the block exists, the subaccount reset with a bare true, the ban on qualifiers with false and the rule list name form come from the manual (§ 11.1.6.1.1).
Example configuration
# a common subaccount on the node, its own in the pool, its own for one address
enable-signals true,subaccount=555
<virtual-mta-pool pond>
    enable-signals true,subaccount=999
</virtual-mta-pool>

<virtual-mta v3>
    enable-signals true
</virtual-mta>
For v3 the subaccount is reset, not inherited. To inherit, the line is not written in the block at all.
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▶

Writing a bare true to enable it at a lower level

§ 11.1.6.1.1

What it costsThe subaccount set above is reset. The stream’s events go out without being tied to the client, and in the service’s reports they will end up in a common heap.
How to spot itSome streams have an empty subaccount in the reports.
How to do it rightDo not write the line at all if you need to inherit; write it with a subaccount if you need your own.

Appending a subaccount to disabling or to a rule list

§ 11.1.6.1.1

What it costsQualifiers are allowed only with true. With false or a list name the configuration will not pass validation.
How to spot itConfiguration validation complains about the line’s value.
How to do it rightSet the subaccount in the list’s rules if you use selection.
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
enable-signals { true | false } [subaccount N] [tracking-domain X] | enable-signals <filter-name>
Values
true with optional subaccount and tracking-domain, or false, or a rule list name
Default
true at global scope when the configuration block exists § 11.1.6.1.1
Applying
a service restart is required
Queue
also affects what is already in the queue
Where to write it
Global, <virtual-mta-pool>, <virtual-mta>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
Three levels: node → pool → sending address, and the pool is stronger than the node. But inheritance works only when the line is absent: a written line overrides the level above entirely, including the subaccount.
How to check on the node
The value in force for a sending address is shown by its settings summary:
pmta show vmta-settings vmta1 | grep -i enable-signals
A mismatch with expectations most often means a bare true at a lower level — it reset the subaccount.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Node security · Collect telemetry