Demo
Demo

Knowledge base

PMTA knowledge base›Monitor screen§ 11.1.10

Spam traps

Spam Traps Display
The report the service is taken for

The SparkPost Signals report on spam trap hits: the share of total volume that went to known traps of commercial and non-commercial networks in a day. It can be shown as the number of hits or as a share of the messages submitted that day.

Spam traps cannot be seen on your own — that is the main argument for connecting the service. The price is that accounting data with recipient addresses goes to a third party.

A high share of hits is linked by the manual directly to poor list sourcing and weak list hygiene.

The report lives in the SparkPost application, not in the node’s monitor: the node only sends accounting data there and reads nothing back. Access to the report is through a SparkPost account, not http-access.

The main trap is looking at the count, not the share. A hundred hits on the day of a big campaign and a hundred hits on the day of a small one are different troubles; the report can show a share of the day’s volume, and days should be compared by it.
What the Hub does. It does not use it: the Hub does not write a <signals> block, and no data goes from the nodes to SparkPost. The Hub has no trap report of its own and cannot have one without access to trap networks.
Recommended values

Where to look for what:

Question Where
trap hits by day here
the overall health score the Signals overview
where the trap addresses in the list come from a question for the submitting platform
The report’s purpose, the two ways to show it and the link to list hygiene come from the manual (§ 11.1.10). The split of questions and the conclusion about data transfer are ours.
Example configuration
# without a signals block no data goes to the service and the report is empty
<signals>
    api-key 0123456789abcdef012345678901234567890123</signals>
The key is 40 hexadecimal characters issued by SparkPost; without the api-key line the engine with a <signals> block will not start.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
⇄

Related entries

2 relations

Works together with

Seeding campaigns with control addressesThe mechanism that is visible here. inference

Where you can see it

The vendor's analytics — and what leaves the node for itThe mechanism that is visible here. § 11.1.10

How to check on the node
Check whether data goes to the service at all:
grep -n -A3 '<signals>' /etc/pmta/config
grep -n 'enable-signals' /etc/pmta/config
No block means no report. enable-signals false on an address or pool turns off data sending only for them.
◇

What else to read

3 articles

◇Complaints parsed by the node — and they are parsed secondMail that arrives at an address from the configured list is parsed as a complaint report; the parsing order matters — the complaint processor runs after the bounce processor.◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Address suppression