Say every Administration refusal in the reader's language

Stalwart explains a refused change in English, and several of its words
reached the page as they were: "Invalid domain name" for a reserved TLD,
"Invalid email address" for a catch-all, a grant refusal, and ihasmail's own
proxy messages. Every registry error type now has its own message, and a
value one of the registry's string validators refused is recognised by the
validator's wording and explained again. A domain clash or a missing domain
is worded for a domain rather than an account.

The one exception is kept on purpose: a password policy's reason follows a
translated sentence, because the rule is the server's and dropping it would
leave no way to find out why.

The mock now refuses a reserved TLD and a catch-all without a domain the way
the live server did. KNOWN-ISSUES records the fix, and that the last two live
cases -- an administrator-set password and the outranking guard -- held.

15 new strings in all nine catalogues, 3 retired; strings falling back to
English stay at 16.
This commit is contained in:
2026-09-13 17:18:15 -07:00
parent 822314e8b7
commit 15b1838e21
16 changed files with 270 additions and 50 deletions
+2 -2
View File
@@ -44,9 +44,9 @@ works the same way — and dropped where 0.15 was the whole subject. Support for
- **A domain its keys still name cannot be destroyed**: `objectIsLinked`, with `linkedObjects` listing each as `{"object": "DkimSignature", "id": …}` and no description. Removing through the panel destroys the keys first and then the domain; both were gone afterwards.
- **A reserved TLD is refused**: `example` as a domain's top level comes back `invalidPatch`, *"Invalid domain name"*, naming `name`.
Two things remain unproved, and both need something this session could not do. **A password set by an administrator** is written to the account's existing credential (`credentials/<index>/secret`); the source says it is hashed and keeps the credential's id, which matters because OAuth tokens are tied to it, but signing in with the new password has not been tried. **The outranking guard** exists because the source shows Stalwart skipping its grant check when only a password changes and on a delete; confirming that needs a session with a role below administrator looking at one above it. Until both are tried, trust the guard rather than the gap.
The last two were then tried by hand on the live server the same day and behaved as described. **A password set by an administrator** written to the account's existing credential, `credentials/<index>/secret` — signs in. **The outranking guard** held: an account with more rights than the viewer's role opens read-only. The guard exists because the source shows Stalwart skipping its grant check when only a password changes and on a delete, and it stays for that reason.
- **Some refusals show Stalwart's own English description.** The server's `invalidPatch` — used for a reserved TLD and a malformed catch-all address, among others — is not one of the error types the client explains in its own words, so what appears is the server's text, untranslated. Nothing is lost: the description says what is wrong. It is simply English in a German interface.
- **A refused password shows the server's reason in English.** Every other refusal from the registry is said in the reader's language: each error type has its own message, and a value one of Stalwart's validators refused — a domain name, an address, an empty field — is recognised by the validator's wording and explained again rather than shown. A password policy is the exception, on purpose. Its rule is the server's to set, so there is nothing to translate it from in advance, and its reason follows a translated sentence rather than being dropped, which would leave "not accepted" with no way to find out why.
- **Administration is off for a device not marked as your own, and for an installation that says so.** Both are enforced by the server rather than hidden by the menu: such a session is sent no permissions, and the JMAP proxy refuses registry methods beyond the account's own. That is worth stating because the proxy otherwise forwards whatever the browser sends, and before these gates an administrator's console could make any registry call their role allowed. For a session that may not administer, the proxy reads a request body only when it could name a registry method — a `"x:` in the text, or a `\u` escape that could spell one — so ordinary mail traffic is forwarded untouched.