4 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	e1e8a9aeb0	Send "none" instead of "pass" as the DMARC report disposition ... Cloudflare's DMARC report intake rejects every aggregate report we send with "555 5.7.1 invalid_report_schema". Bisected against the live endpoint: the only element it objects to is <disposition>pass</disposition>, the value RFC 9990 added for mail that passed DMARC under an enforcing policy. The RFC 9990 namespace, <np>, <discovery_method>, <testing> and a missing <pct> are all accepted, and a report that differs only in using "none" there goes through. "none" (no action taken) is valid under both RFC 9990 and RFC 7489 and says the same thing to the reader, so reports now go out with it. The stored report keeps "pass"; only the serialized copy changes.	2026-09-27 22:31:13 -07:00
jcoffey-dev	5dde9793eb	Every node records DMARC and TLS results for the aggregate reports ... 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.	2026-09-24 18:28:00 -07:00
jcoffey-dev	3a272096c0	Import upstream v0.16.23, stripped ... Upstream commit: 9d1c75ab68435e4417337f768291e5f947686203 Enterprise-only files removed or emptied: 63 Enterprise-only snippets removed: 118 in 50 files Dangling module declarations removed: 5 Edits turning enterprise off: 25 Third-party code: 14 files, 0 not in THIRD-PARTY.md Verification: clean One snippet more than v0.16.22, in crates/common/src/auth/authentication.rs (3, was 2).	2026-09-22 16:31:25 -07:00
jcoffey-dev	7dae9b29fd	Import upstream v0.16.22, stripped ... Upstream commit: 474dd0229cb20cf513036619781ed97bd8073c3f Enterprise-only files removed or emptied: 63 Enterprise-only snippets removed: 117 in 50 files Dangling module declarations removed: 5 Cargo edits turning enterprise off: 14 Verification: clean Enterprise feature gates left for rebuilt features: 19 in 18 files Produced by tools/fork/strip.py. The full report is in docs/fork/strip-reports/ on main.	2026-09-18 10:21:56 -07:00