Reports in a few sentences, on every report page

jcoffey-dev commented

2026-09-28 20:10:05 +00:00

Owner

Third second-wave item from the settings-reorg spec. Based on main; independent of the other open PRs.

The six report pages (General, DMARC, TLS, DKIM, SPF, DSN) are mostly From names, subjects and signing domains. Whether reports go out at all is a frequency or rate expression inside them. Each report page now opens with Reports, in short.

Reports this server sends

Tell other domains how mail claiming to be from them fared here (DMARC): every hour, once a day, once a week or never (aggregateSendFrequency).
Tell them whether their mail reached us encrypted (TLS): the same (TlsReportSettings.sendFrequency).
Report each message that fails their checks (DMARC, DKIM, SPF), at most once a day per address: one switch for all three failure-report rates.
- On is [1, 1d]. Off is false: a value that isn't a Rate makes eval_if answer None, so nothing is sent.
- A note says they carry message headers (personal data) and that most large providers don't send them.
- If the three pages disagree, it says so, and switching sets all three.
Send them, and bounce messages, from addresses at the default domain or a chosen one (outboundReportDomain), with an example address.

Reports other servers send you

Read reports sent to postmaster@* (editable list) and show them under Management › Reports (inboundReportAddresses).
Then deliver them to that mailbox as well (inboundReportForwarding).

A frequency set by a rule with conditions shows as by a rule on its page and isn't flattened. Changes are sent in one request, only the fields that changed. The page's own settings are folded underneath and reload after a save.

Checked: unit tests for reading plain values, rates vs no rate, the three-way switch, and address lists (429 total), plus typecheck, lint and build. In Chrome against a local server: failure reports off and TLS summaries weekly, saved from the DMARC page. Read back over JMAP, DMARC/DKIM/SPF failure rates were false, TLS was weekly, DMARC summaries were unchanged at daily, and there were no config warnings.

English only: about 30 new strings.

Third second-wave item from the settings-reorg spec. Based on main; independent of the other open PRs. The six report pages (General, DMARC, TLS, DKIM, SPF, DSN) are mostly From names, subjects and signing domains. Whether reports go out at all is a frequency or rate expression inside them. Each report page now opens with *Reports, in short*. **Reports this server sends** - *Tell other domains how mail claiming to be from them fared here (DMARC):* every hour, once a day, once a week or never (`aggregateSendFrequency`). - *Tell them whether their mail reached us encrypted (TLS):* the same (`TlsReportSettings.sendFrequency`). - *Report each message that fails their checks (DMARC, DKIM, SPF), at most once a day per address:* one switch for all three failure-report rates. - On is `[1, 1d]`. Off is `false`: a value that isn't a Rate makes `eval_if` answer None, so nothing is sent. - A note says they carry message headers (personal data) and that most large providers don't send them. - If the three pages disagree, it says so, and switching sets all three. - *Send them, and bounce messages, from addresses at* the default domain or a chosen one (`outboundReportDomain`), with an example address. **Reports other servers send you** - *Read reports sent to* `postmaster@*` (editable list) *and show them under Management › Reports* (`inboundReportAddresses`). - *Then deliver them to that mailbox as well* (`inboundReportForwarding`). A frequency set by a rule with conditions shows as *by a rule on its page* and isn't flattened. Changes are sent in one request, only the fields that changed. The page's own settings are folded underneath and reload after a save. **Checked:** unit tests for reading plain values, rates vs no rate, the three-way switch, and address lists (429 total), plus typecheck, lint and build. In Chrome against a local server: failure reports off and TLS summaries weekly, saved from the DMARC page. Read back over JMAP, DMARC/DKIM/SPF failure rates were `false`, TLS was `weekly`, DMARC summaries were unchanged at `daily`, and there were no config warnings. English only: about 30 new strings.

jcoffey-dev added 5 commits 2026-09-28 21:57:16 +00:00

Guided setup: connect a sign-in directory

ci / build (pull_request) Successful in 2m4s

Details

ci / publish (pull_request) Skipped

Details

0c64ff214b

Directories and Authentication offer a guide ("Guided or manual?" each
time) that:

- starts from Active Directory, OpenLDAP, FreeIPA, Keycloak, Authentik
  or another OpenID Connect provider, with filters and attributes set for
  that directory and example connection values;
- saves the directory, which changes nothing while no domain uses it,
  and tests a real person against it with the server's directory test:
  found or not (with aliases and groups), and whether a password signs
  in, a wrong password told apart from a broken connection. The guide
  won't go on until a person is found and, if given, the password works;
- then asks which domains sign in through it, with each domain's account
  count, and the server default as a separate switch. Choosing the
  domain you sign in on, or the default, needs an explicit "I've checked
  I can still sign in";
- switches the chosen domains over, putting them back if making it the
  default is refused.

Needs inbuxa-server's POST /api/directory/test.

Sender checks as a level: Relaxed, Recommended or Strict

ci / build (pull_request) Successful in 1m38s

Details

ci / publish (pull_request) Skipped

Details

86ae2c6672

Mail flow › Receiving › Sender checks opens with one choice instead of
six strategy fields, and a table of what each level does to mail that
fails. From the SMTP code:

- Relaxed (the stock settings): SPF, DKIM, DMARC and reverse DNS are
  checked on port 25 and scored by the spam filter; nothing is refused.
- Recommended: also refuses mail that fails DMARC for a domain that
  publishes p=reject, and checks ARC.
- Strict: also refuses senders that fail reverse DNS or SPF on MAIL
  FROM (including senders with none), and broken ARC chains. It warns
  that some real mail from small or badly set-up servers will bounce.

No level refuses unsigned mail (strict DKIM, which RFC 6376 advises
against). Checks stay on port 25, like the stock settings. Values set by
hand show as "Set by hand below", and applying a level then says it
replaces them. The form reloads after a level is applied; DKIM signing
isn't touched.

Limits as sentences, with presets for who uses the server

ci / build (pull_request) Successful in 2m4s

Details

ci / publish (pull_request) Skipped

Details

8fdae4a32b

A stock server has no rate limits: one stolen password can send without
end. A guide ("Guided or manual?" each time) asks who uses the server
(me and my family, a company or school, open to the public) and offers
five rules as sentences with numbers you can change:

- each outside server may connect N times a minute on port 25;
- each signed-in person may send N messages an hour;
- each signed-in person may address N recipients an hour in total
  (keyed by account alone; the condition reads rcpt, so the server
  checks it at RCPT TO);
- at most N deliveries a minute to any one receiving server;
- each sender may have at most N messages waiting.

Rules it writes are marked "Preset:" so running it again edits them; it
never touches rules made by hand. Above the incoming, outgoing and quota
lists, every rule now reads as a sentence, and an empty list says that
nothing is limited.

Retention on one page, as sentences

ci / build (pull_request) Successful in 2m2s

Details

ci / publish (pull_request) Skipped

Details

7b65b8eb34

Every "how long is this kept" setting was spread over four pages of
fields named after the config, plus log files on the Hardening page.
Each retention page now opens with all of them as sentences:

- in people's mailboxes: empty Trash and Junk after, clear handled
  calendar invitations after, forget share notices after, forget the
  sending status of sent mail after;
- getting deleted things back: deleted items and deleted accounts;
- the server's own records: delivery history, charts' history, DMARC
  and TLS reports from other servers, and old log files.

Each has a number and unit (or its own never / off / forever), its
default beneath, and an unsaved mark until the changes are saved
together. It says that mail under a legal hold is kept whatever these
say. The page's own settings (schedules and the like) are folded
underneath and reload after a save.

Reports in a few sentences, on every report page

ci / build (pull_request) Successful in 1m29s

Details

ci / publish (pull_request) Skipped

Details

c12b117fe7

Six report pages were mostly From names, subjects and signing domains;
whether reports go out at all was a frequency or rate expression inside
them. Each report page now opens with:

- tell other domains how their mail fared here (DMARC summaries):
  every hour, once a day, once a week or never;
- tell them whether their mail reached us encrypted (TLS summaries):
  the same;
- report each message that fails their checks (DMARC, DKIM and SPF
  failure reports together): on, at most once a day per address, or off,
  noting they carry message headers and that most large providers don't
  send them. Off is a value that isn't a rate, which sends none;
- send them, and bounce messages, from addresses at the default domain
  or a chosen one;
- read reports sent to postmaster@* (or other addresses) and show them
  under Management › Reports, and whether to still deliver them.

A value set by a rule with conditions is shown as such and left to its
page. The page's own settings are folded underneath and reload after a
save.

jcoffey-dev force-pushed feature/reports-page from baf0e304c2 to c12b117fe7

2026-09-28 21:57:16 +00:00

Compare

jcoffey-dev merged commit 253881735a into main

2026-09-28 22:01:15 +00:00

jcoffey-dev deleted branch feature/reports-page

2026-09-28 22:01:15 +00:00

Reports in a few sentences, on every report page #44