Demo
Demo

Knowledge base

PMTA knowledge base›Configuration block§ 11.1.6.2

<signals>

Exporting delivery events to external analytics
The only surface that sends data outside

The block enables exporting delivery events to the vendor’s analytics service. The data goes beyond the perimeter — this sets it apart from all the node’s other surfaces, which only answer requests.

🔴 The engine chooses the data composition, not you. The vendor says directly: there is no need to specify record types and fields — everything the service needs is configured automatically. The composition can be limited only by anonymizing addresses with privacy-policy.

The key is mandatory in the strong sense: without api-key the node will not start.

The scope is not set here but with the enable-signals line with its three levels — or with a <signals-filter> rule list.

The block’s former name — <sparkpost-analytics> — has been declared obsolete.

After adding the block the vendor advises a restart, not a reload: that way all internal processes immediately follow the new settings.

Example configuration
# the key is mandatory: without it the node will not come up
<signals>    api-key 0123456789abcdef012345678901234567890123
    privacy-policy sha1
</signals>

enable-signals true,subaccount=555
The block’s second line is the only way to limit what goes outside. The engine chooses the field composition itself.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Block directives: 16
Message content 6
html-edit-error-modeWhat to do if a message could not be parsed for substitutionengagement-trackingWho collects opens and clickstracking-domainThe domain in inserted tracking linksenable-bottom-open-pixelWhether to track opens — by an image at the bottom of the messageenable-click-trackingWhether to track link clicksenable-top-open-pixelWhether to track opens — by an image at the top of the message
Accounting 3
privacy-policyWhether to anonymize addresses before sending them outsidecustom-message-id-headerThe header by which the service links a message’s eventsretain-x-sp-subaccount-idWhether to keep the subaccount header in the sent message
API 2
customer-idVendor customer ID — the line is no longer neededupload-urlThe service address the data goes to
Access 1
api-keyAccess key for the analytics service
Core 1
min-free-spaceThe free space threshold below which export data is deleted
Mail submission 1
process-x-sp-subaccount-idWhether to read the header with the subaccount number in the event export
Diagnostics 1
log-verboseDetailed logging of the export to the vendor’s analytics
TLS 1
use-httpsWhether to encrypt substituted tracking links
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.
◇

What else to read

2 articles

◇Seeding campaigns with control addressesThe engine mixes the vendor’s addresses into a mailing, and the result is viewed in the vendor’s deliverability tool; independent of event export.◇Job headerThe x-job header tags a message with a job; the node reads it only if the source is allowed process-x-job, and then the job is visible in accounting, the monitor and pause commands.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Seeding and seed mailboxes