Found a directly relevant “live tracing” endpoint/page. Let’s fetch it.
Two separate things are worth checking here, and each explains a plausible root cause.
1. Console tracer output should appear in docker logs.
The Stdout tracer variant writes every log/trace entry to stderr specifically so container runtimes like Docker can capture it. If you got literally zero output at Trace level, the tracer you edited likely isn’t the one actually active, or its enable field is false. Sanity-check by temporarily setting level to trace with no event filter at all (leave events empty) — at that verbosity you should see a flood of unrelated SMTP/queue events. If you still see nothing, the tracer config itself isn’t being applied (wrong instance, not saved, needs the service to pick it up).
2. Watch out for eventsPolicy.
events/eventsPolicy on the Tracer object work as an include/exclude filter, defaulting to exclude. If you added the Milter events to events but left eventsPolicy at its default exclude, you’re telling Stalwart to suppress exactly those events and emit everything else — the opposite of what you want. Set eventsPolicy to include if you only want to see Milter traffic.
3. Which events actually confirm invocation.
milter.read/milter.write are trace-level raw-byte dumps, but the higher-signal events are logged at info/warn regardless of a custom tracer, so a plain level: info console tracer should already show them if the milter is being called:
milter.action-accept, milter.action-reject, etc. (info) — the milter responded and Stalwart acted on it.milter.io-error, milter.timeout, milter.disconnected, milter.frame-invalid (warn) — connection/protocol problems talking to Rspamd’s milter worker.
If none of these appear at all for a DATA-stage message, the milter call itself isn’t happening, which points back to the enable expression.
4. Double-check the enable expression’s listener variable.
listener in MtaMilter.enable resolves to the identifier of the NetworkListener object handling the connection, not just “any port 25 traffic.” Confirm that your SMTP listener’s ID is literally smtp (as configured under Network › Listeners) — if it was created with a different name, listener == 'smtp' will always evaluate false and the milter will silently never be invoked, which matches “messages accepted, Rspamd scan count never increases, and no Milter events logged at all.”
Reference: Milter filters and Tracing overview / Console tracer.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.