Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.57.8

dummy-smtp-update-stats

Global

Whether to mix fake traffic into the node's statistics
in the configuration this is a linedummy-smtp-update-stats trueinside the block Global
The only line that spoils real data

Decides whether the fake receiver’s traffic gets into the counters shown by the web monitor and the node status command. The default is true, that is, it does.

The other seven lines of the family configure the fake itself and do not go beyond the run. This one does: it mixes the load run with production sending in the same figures.

They cannot be separated afterwards. The counter is cumulative, there is no “this was a run” marker in it; all that remains is to remember the run date and subtract by eye.

The main trap is that it is remembered after the run. A load run is usually tens or hundreds of thousands of messages in an hour: a figure that exceeds a day’s production sending and makes the daily report meaningless. By the time it is noticed, the counters are already accumulated.
What the Hub does. It does not write it: the mechanism is not brought up on the nodes. If it appears, this line will have to be turned off: the Hub takes telemetry from the same counters, and a run will show up in its analytics just as in the node monitor.
Recommended values

Turn it off before the run, not after. Counters are not cleaned retroactively.

Check it before every run. It is a node-level line: it is easy to lose during a configuration update, and the consequences are visible only the next day, in the report.

Leaving it on makes sense in exactly one case — when the run goes on a node whose counters nobody cares about.

The requirement to turn it off before the run is ours. From the manual come the true default and which counters exactly are affected: the status counters shown by the web monitor.
Example configuration
# the run must not get into the node's counters
dummy-smtp-port 2525
dummy-smtp-latency 100
dummy-smtp-update-stats false
The line comes last in the set on purpose: it is the easiest to forget, and of the whole family only its consequences are irreversible.
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▶

Forgetting to turn it off before a run

§ 3.3.1.57.8

What it costsHundreds of thousands of fake messages land in the same counters as production sending. The daily report stops meaning anything, and it cannot be restored.
How to spot itA sending spike in the monitor that was not in the mailing.
How to do it rightTurn it off before the run; afterwards reset the counters entirely, if that is acceptable.

Counting on subtracting the run retroactively

our experience

What it costsThere is no “this was a run” marker in the counters. Subtracting has to be done by eye, from memory of when it ran and how many messages it contained.
How to spot itThe report is edited by hand, explaining the discrepancy by the run date.
How to do it rightTurn the line off in advance — there is no other way to separate the flows.
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
dummy-smtp-update-stats <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
true § 3.3.1.57.8
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
A node-level line: it is written at the root of the file, not inside a block. It has no inheritance. It is picked up by pmta reload; already accumulated counters are not recalculated — the edit applies only to further traffic.
⇄

Related directives

1 relation

Applies to

A fake receiver inside the node itselfOne of the eight lines configuring the fake receiver — and the only one whose consequences go beyond the run. § 3.3.1.57.8

How to check on the node
The value is set in the configuration; the accumulated counters are printed by the status command:
grep -n dummy-smtp-update-stats /etc/pmta/config
pmta show status | head -20
Counters can be reset only entirely, with the status reset command — the run cannot be subtracted selectively. The Hub takes telemetry from these same counters.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Capacity planning
Neighboring settings of the block Global:http-mgmt-porttrack-outbound-perf-statstrack-inbound-perf-statshttp-default-max-itemshttp-default-sort-orderAll 108 directives of the block →