From d407509f59f40058dcf1269e465a73c1750a1ebb Mon Sep 17 00:00:00 2001 From: John Coffey Date: Sat, 19 Sep 2026 20:10:50 -0700 Subject: [PATCH] Compat: what the recording holds, and what two of the tests now prove MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit record-compat.py ran against the live server as a server-level administrator: 8 accounts, which matches the dashboard, so it reached all of them. One tenant with its quotas and members; no masked addresses, no archived items. The empty files are right rather than short. INBUXA has no masked addresses and retention is off, so masked_email_compat and undelete_compat iterate an empty list: they pass without comparing anything, which is worth saying plainly, because a green run from either would otherwise read as evidence of compatibility. That puts them where scim_compat and per_domain_directory_compat already sit. So one recording carries weight, expected.json, and it is made. SPEC §7's cutover steps 2 and 3 come down to the tenant, the domains and the accounts until either feature is switched on. --- docs/spec/SPEC.md | 5 ++++- docs/spec/compat-tests.md | 32 +++++++++++++++++++++++++++++--- 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/docs/spec/SPEC.md b/docs/spec/SPEC.md index 39f7aef..d366594 100644 --- a/docs/spec/SPEC.md +++ b/docs/spec/SPEC.md @@ -534,7 +534,10 @@ before anything that could prompt that notice happens. 2. INBUXA's data opens in the fork on a copy: tenants, masked addresses, archived items, every account. 3. Masked addresses already handed out still deliver; archived items still - restore. + restore. Moot as things stand: INBUXA has no masked addresses and + retention is off (2026-09-19), so steps 2 and 3 come down to the tenant, + the domains and the accounts. It applies again the moment either feature + is switched on (`compat-tests.md`). 4. Cutover on the running host, with the Enterprise build kept for rollback. 5. Only then: public repository and announcement, with the INBUXA fork of ihasmail released alongside. Public ihasmail stays Stalwart-facing (§5). diff --git a/docs/spec/compat-tests.md b/docs/spec/compat-tests.md index 4a47e63..bf853f4 100644 --- a/docs/spec/compat-tests.md +++ b/docs/spec/compat-tests.md @@ -129,11 +129,37 @@ plumbing before the day the copy exists. What that established: What it can't establish is anything about INBUXA's data: every run ended at the authentication check, since an empty store holds no such administrator. +## What was recorded, 2026-09-19 + +`record-compat.py` ran against the live Enterprise server as a server-level +administrator and saw 8 accounts, which is what the dashboard reports, so it +reached all of them. It recorded: + +| File | Contents | +|---|---| +| `expected.json` | 1 tenant, with its quotas and members. `tenantAdmins` empty: no `--tenant-admin` was passed | +| `masks.json` | nothing | +| `archived.json` | nothing | + +The two empty files are right, not a short recording: INBUXA has no masked +addresses and deleted-mail retention is off (John, 2026-09-19). So +`masked_email_compat` and `undelete_compat` iterate over an empty list. +**They pass without comparing anything, and a green run from either proves +nothing about compatibility** — the same standing as `scim_compat` and +`per_domain_directory_compat`, which assert INBUXA uses neither feature. + +That leaves one recording that carries weight, `expected.json`, and it is +made. Should either feature be switched on before the cutover, record again: +the files are a picture of the day they were taken. + ## What a failure means -- `tenant_compat`, `masked_email_compat`, `undelete_compat`, - `branding_compat`, `ai_compat`: the fork reads that data differently from - the Enterprise server. Treat as a cutover blocker and fix before moving. +- `tenant_compat`, `branding_compat`, `ai_compat`: the fork reads that data + differently from the Enterprise server. Treat as a cutover blocker and fix + before moving. +- `masked_email_compat` and `undelete_compat` would mean the same, but as of + 2026-09-19 they have nothing to read: see "What was recorded" above. They + can only fail once INBUXA has masked addresses or retention on. - `monitoring_compat`: old telemetry that can't be decoded is expected and is skipped; a failure here means the settings differ from what was observed.