Every node records DMARC and TLS results for the aggregate reports #47

Merged

jcoffey-dev merged 1 commits from fix/front-node-dmarc into main

2026-09-25 01:46:20 +00:00

jcoffey-dev commented

2026-09-25 01:28:32 +00:00

Owner

DMARC (and TLS) results for mail received on a node without outboundMta never reached an aggregate report. In rehearsal, five messages received on port 25 on a front node were missing from every report. An aggregate report is meant to cover all of a domain's inbound mail, whichever node received it.

Cause

Inbound sessions hand each DMARC result to schedule_report (crates/smtp/src/reporting/send.rs:142). That puts it on the report channel, and the report scheduler (crates/smtp/src/reporting/scheduler.rs) records it. #44 made the scheduler drop events while the node's role lacks outboundMta. Before #44 (and upstream), the scheduler wasn't started on such a node at all, so the events sat in a channel nobody read.

Where the work belongs

Recording is store-backed: schedule_dmarc / schedule_tls read the internal report by its primary key, append, and write it back, creating the report and scheduling its task if it doesn't exist yet. Nothing in that path needs the outbound MTA, and every node already shares the store. Building and sending the report is the DmarcReport / TlsReport task, which #40 already limits to outboundMta nodes.

Change

Scheduler: records on every node, whatever its role. The channel stays: it keeps a node's writes in order and off the SMTP session.
Concurrent writers: the upstream design already guards appends. The report's primary key carries a version, each append asserts it, and a new report asserts the key is absent. So two nodes can't overwrite each other: the loser retries. Upstream retried three times, back to back, when only outbound nodes wrote. With every node writing, a lost write now retries up to ten times after a short random pause that grows with each attempt (reporting/shared.rs).
Sender vs. appenders: the node sending a report used to delete it without checking, so a record another node appended between that read and the delete was lost. The delete now asserts the report is unchanged since the read (hash of the stored bytes) and reads it again if not.

TLS results come from outbound deliveries, so in practice only outbound nodes produce them. They take the same path.

Tests

tests/src/cluster/front_reports.rs (new): two nodes over one store.

The front node (no outboundMta) records two DMARC results; the shared report holds both.
The report is made due now; the front node leaves the task alone.
Eight more results are appended at once, alternating between the front node and the MTA node.
The MTA node sends the report. The sent report's records are exactly the ten source IPs, and the report and its task are gone.

nstest3.sh <wt> PostgreSql --features postgres front_node_report   # ok
nstest3.sh <wt> MySql --features mysql front_node_report           # ok

On main it fails: "no report with 2 records for front-reports.example: None".

Also run: smtp::reporting and smtp::management on RocksDB, and cluster::live_roles, cluster::task_roles, cluster::stress on PostgreSQL, all passing. The test drives the scheduler through schedule_report, the call an inbound session makes, not a real port-25 session: that would need DMARC DNS fixtures.

This changes part of what #44 says: losing outboundMta still stops delivery and report tasks, but no longer stops recording.

DMARC (and TLS) results for mail received on a node without **outboundMta** never reached an aggregate report. In rehearsal, five messages received on port 25 on a front node were missing from every report. An aggregate report is meant to cover all of a domain's inbound mail, whichever node received it. ## Cause Inbound sessions hand each DMARC result to `schedule_report` (`crates/smtp/src/reporting/send.rs:142`). That puts it on the report channel, and the report scheduler (`crates/smtp/src/reporting/scheduler.rs`) records it. #44 made the scheduler drop events while the node's role lacks outboundMta. Before #44 (and upstream), the scheduler wasn't started on such a node at all, so the events sat in a channel nobody read. ## Where the work belongs Recording is store-backed: `schedule_dmarc` / `schedule_tls` read the internal report by its primary key, append, and write it back, creating the report and scheduling its task if it doesn't exist yet. Nothing in that path needs the outbound MTA, and every node already shares the store. Building and sending the report is the `DmarcReport` / `TlsReport` task, which #40 already limits to outboundMta nodes. ## Change - **Scheduler:** records on every node, whatever its role. The channel stays: it keeps a node's writes in order and off the SMTP session. - **Concurrent writers:** the upstream design already guards appends. The report's primary key carries a version, each append asserts it, and a new report asserts the key is absent. So two nodes can't overwrite each other: the loser retries. Upstream retried three times, back to back, when only outbound nodes wrote. With every node writing, a lost write now retries up to ten times after a short random pause that grows with each attempt (`reporting/shared.rs`). - **Sender vs. appenders:** the node sending a report used to delete it without checking, so a record another node appended between that read and the delete was lost. The delete now asserts the report is unchanged since the read (hash of the stored bytes) and reads it again if not. TLS results come from outbound deliveries, so in practice only outbound nodes produce them. They take the same path. ## Tests `tests/src/cluster/front_reports.rs` (new): two nodes over one store. - The front node (no outboundMta) records two DMARC results; the shared report holds both. - The report is made due now; the front node leaves the task alone. - Eight more results are appended at once, alternating between the front node and the MTA node. - The MTA node sends the report. The sent report's records are exactly the ten source IPs, and the report and its task are gone. ``` nstest3.sh <wt> PostgreSql --features postgres front_node_report # ok nstest3.sh <wt> MySql --features mysql front_node_report # ok ``` On main it fails: "no report with 2 records for front-reports.example: None". Also run: `smtp::reporting` and `smtp::management` on RocksDB, and `cluster::live_roles`, `cluster::task_roles`, `cluster::stress` on PostgreSQL, all passing. The test drives the scheduler through `schedule_report`, the call an inbound session makes, not a real port-25 session: that would need DMARC DNS fixtures. This changes part of what #44 says: losing outboundMta still stops delivery and report tasks, but no longer stops recording.

jcoffey-dev added 1 commit 2026-09-25 01:28:32 +00:00

Every node records DMARC and TLS results for the aggregate reports

ci / fork-checks (pull_request) Successful in 43s

Details

ci / build (pull_request) Successful in 17m25s

Details

5dde9793eb

The report scheduler dropped DMARC and TLS events on a node whose role
lacks outboundMta (upstream never started it there, so they sat in a
channel nobody read). Mail received on a front node therefore never
reached an aggregate report, which is meant to cover all of a domain's
inbound mail, whichever node received it. In rehearsal, five messages
received on port 25 on a front node were missing from every report.

- The report scheduler records on every node. Recording is a store write
  the nodes already share, so it needs nothing from the outbound MTA.
  Building and sending a report (the DmarcReport and TlsReport tasks) stay
  with outboundMta nodes, as the task manager already enforces.
- More nodes now append to one report at once. Appends already guard the
  report's versioned primary key; a write that loses now retries up to ten
  times after a short random pause, not three times at once.
- The node sending a report deletes it only if it is unchanged since it
  was read, and reads it again otherwise, so a record another node appends
  meanwhile goes out with the report instead of being deleted unsent.

Test: cluster::front_reports (PostgreSQL and MySQL). A front node's
results appear in the report the MTA node sends, alongside eight appended
at once from both nodes, and the front node never runs the report task.
It fails on main: the front node's results are never recorded.

jcoffey-dev merged commit 59e631eded into main

2026-09-25 01:46:20 +00:00

jcoffey-dev deleted branch fix/front-node-dmarc

2026-09-25 01:46:20 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-server#47