Received reports: who sends as your domains, and whether they pass #88

Merged

jcoffey-dev merged 1 commits from feature/incoming-reports into main

2026-10-06 16:05:49 +00:00

jcoffey-dev commented

2026-10-06 14:40:50 +00:00

Owner

Admin UX roadmap, item 6: the DMARC / TLS-RPT report view. Admin only; the server already stores every received report parsed (x:DmarcExternalReport, x:TlsExternalReport).

Inbound DMARC Reports now opens with a card per domain:

every sender seen, named by the domain whose DKIM or SPF passed (else its IP), with message counts and which providers reported it
failing senders first, grouped by IP, with what receivers did (delivered, to spam, rejected)
spoofing said in plain words; a "none" policy gets the next step (quarantine or reject once real senders pass)
domains where everything passes stay folded, with no "all good" banner

TLS Reports opens with secure vs failed deliveries per domain, each failure kind explained in plain words, with the MX hosts involved.

The raw report lists stay underneath, unchanged. Summaries are pure functions with tests (summarize.test.ts). Report periods are shown as UTC days.

Translation: 49 new strings in en.json (inReports., inTls.), English only for now.

Checked locally: typecheck, lint, i18n:check, 614 tests, build, notice-check; previewed against a local server with sample reports.

Admin UX roadmap, item 6: the DMARC / TLS-RPT report view. Admin only; the server already stores every received report parsed (x:DmarcExternalReport, x:TlsExternalReport). **Inbound DMARC Reports** now opens with a card per domain: - every sender seen, named by the domain whose DKIM or SPF passed (else its IP), with message counts and which providers reported it - failing senders first, grouped by IP, with what receivers did (delivered, to spam, rejected) - spoofing said in plain words; a "none" policy gets the next step (quarantine or reject once real senders pass) - domains where everything passes stay folded, with no "all good" banner **TLS Reports** opens with secure vs failed deliveries per domain, each failure kind explained in plain words, with the MX hosts involved. The raw report lists stay underneath, unchanged. Summaries are pure functions with tests (`summarize.test.ts`). Report periods are shown as UTC days. Translation: 49 new strings in en.json (inReports.*, inTls.*), English only for now. Checked locally: typecheck, lint, i18n:check, 614 tests, build, notice-check; previewed against a local server with sample reports.

jcoffey-dev added 1 commit 2026-10-06 14:40:50 +00:00

Received reports: who sends as your domains, and whether they pass

ci / build (pull_request) Skipped

Details

ci / publish (pull_request) Skipped

Details

ci / notices (pull_request) Successful in 13s

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 1m23s

Details

79d50e552b

Inbound DMARC Reports opens with a card per domain: every sender seen,
named by the domain whose DKIM or SPF passed (else its IP), how many
messages passed, and what receivers did with the ones that failed.
Failures say in plain words that someone may be pretending to be you,
and a "none" policy gets the next step. TLS Reports opens with secure
and failed deliveries per domain, each failure kind explained.

Admin UX roadmap, item 6.

jcoffey-dev merged commit 3b238a0329 into main

2026-10-06 16:05:49 +00:00

jcoffey-dev deleted branch feature/incoming-reports

2026-10-06 16:05:49 +00:00

jcoffey-dev referenced this pull request

2026-10-06 16:18:57 +00:00

Received reports: read the report lists as the server sends them #89

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-admin#88