6f3aba06a63fde22906b6e9065631055c53eaa25
20
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jcoffey-dev
|
dc676acf52 |
Say 0.16.21 where the docs still said 0.16.20
The README badge still read 0.16.20, in both the label and the shield it links to. It is the first version number a reader sees and it was the one place the prose update missed, because it is HTML rather than Markdown. Two entries had gone further than stale and were wrong. FEATURES said occurrence ids are not stable across a write, and KNOWN-ISSUES carried that as a live hazard with the five-week series that proved it. 0.16.21 fixed exactly that: an occurrence is identified by its recurrence id now, and holding an id across a write keeps it on its own date. Both entries say so, keep the old behaviour and the evidence for it because the client still supports 0.16 as a whole, and record what replaced it. The defence in the client stays either way, and the reason is written down: re-resolving by recurrenceId costs one lookup, a date can still leave a series, and 0.16.20 is still a server someone may be running. The KNOWN-ISSUES header now says the live instance runs 0.16.21 and, unlike the upgrades before it, that this one was re-run rather than read against the diff — with what was exercised by hand. |
||
|
jcoffey-dev
|
c84f190f76 |
Check S/MIME signatures, and remember who signed
A signed message now says whether that holds up, as it is read. This is
verification only: nothing here signs, encrypts or decrypts, and the
private-key question that blocks those is untouched. Verifying needed
none of it, because the certificate travels inside the message -- which
is why this is the half that could be built.
What it checks. For multipart/signed carrying PKCS#7, the exact bytes of
the signed part -- headers included, canonicalised to CRLF -- are hashed
against the messageDigest attribute, and the signature over the signed
attributes is verified with WebCrypto against the certificate inside the
message. RSA PKCS#1 v1.5 and ECDSA over P-256/384/521, with SHA-256, 384
or 512.
The trust model is the design, and it is deliberately small. A browser
has no system trust store, and the certificate arrives inside the
message, so anyone can self-sign as anyone: on its own a good signature
shows only that the sender held the key they attached. So the word
"verified" is never rendered, and the reassuring case is not the loud
one. What carries the weight is remembering -- the first signed message
from an address pins its fingerprint, later ones are compared, and a
signer that changed is reported with both names and told to check by
another route. Trust on first use, no certificate authority anywhere.
The pins live in the account's settings rather than the browser: one
that only a single device knew would greet the same correspondent as new
everywhere else, which is how people are trained to click past the one
warning that matters. A pin records the message that created it, so the
message that established a signer keeps saying so instead of appearing
to be corroborated by itself -- without that, the very first signed
message anybody receives reads as "the same signer as before", where
before is itself. A changed, mismatched or expired signer is never
pinned, since writing the anomaly into the baseline makes every later
message agree with it.
Three things are declined rather than attempted, and all three say
"could not check" rather than "does not check out", because ignorance
and an accusation are different claims:
- OpenPGP, by name. The signature carries no key and there is nowhere
to get the sender's: x:PublicKey is the account's OWN registry, and
a keyserver or WKD lookup would tell a third party who you
correspond with -- the leak the image proxy exists to close.
- SHA-1. Not forgeable in practice today, still not something to put a
tick beside.
- RSA-PSS, whose salt length lives in parameters this does not read.
Guessing wrong would report a good signature as bad.
Nothing validates a chain: no CA bundle is shipped and revocation is not
checked. "Issued by" reports what the certificate claims, and a
self-signed one claims itself.
The DER, CMS, X.509 and MIME readers are hand-written and deliberately
narrow -- no new dependency, and the whole verifier is a lazily imported
8.6 kB chunk that a reader of unsigned mail never downloads. The one
place this is easy to get quietly wrong has its own function and its own
test: signed attributes are signed as a SET OF, not as the [0] IMPLICIT
they arrive as, and hashing the message instead would make every
signature "pass".
Tested against real `openssl smime -sign` output rather than hand-built
fixtures -- RSA, ECDSA, a tampered copy, and a valid signature by a
certificate for somebody else -- because a signed message written by
hand only agrees with whatever its author believed the format to be.
Also driven in a browser against the mock, which now serves three real
signed messages so every branch of the banner is reachable.
Translations: 34 new strings in all nine catalogues, 306 entries.
Falling back to English is unchanged at 24 per language.
|
||
|
jcoffey-dev
|
45c8929697 |
Withdraw the key manager, and keep what probing it established
A Settings section for public keys is furniture, not a feature. Nothing in ihasmail signs, encrypts, decrypts or verifies with a key, so the page could only ever tell the reader in its own footnote that adding one does nothing. It is withdrawn on that reasoning -- the same reasoning that closed PR #67, reached again with the code in front of us. So this reverts every user-visible part of it: the section, the lib, the mock handlers, the component and the 261 catalogue strings. Nothing in web/ or server/ differs from main now. What stays is the part that was expensive and is true regardless. The x:PublicKey registry was probed against a live 0.16.20 on 2026-09-05, and the findings are now in KNOWN-ISSUES rather than in a closed pull request -- which is where they sat for the nine days between #67 and this branch, and why the work was done twice. Consolidated into one entry, framed as what Stalwart does rather than what ihasmail offers: - an ordinary user may read and write their own keys, whatever the permissions table says - the registry takes S/MIME certificates as well as OpenPGP keys, and parses both -- confirmed with a real self-signed X.509 certificate, and a malformed one gets its own BER decoding error - a key can parse and still be refused, with different words. A sign-and-certify key -- what `gpg --quick-generate-key` makes -- gets "Could not find any suitable keys", which is not a paste error and must not be shown as one - emailAddresses comes back as {} when empty, an object where a list property should be an array. It type-checks, then throws in join() - a create answers with the id alone; patching `key` is allowed - expiresAt is the registry's field and is not derived from the key ROADMAP now says plainly that key management has been built and withdrawn twice, that the registry is not the obstacle, and that verifying a signature -- which needs only public keys -- is the shortest route to a key being worth having. Encryption at rest moves from "not offered yet" to refused: it is a one-way door, since turning it off does not decrypt what is already there, and that is not a switch to hand an ordinary user however easy it would be to add. |
||
|
jcoffey-dev
|
6a467d9bc4 |
Check the S/MIME half against a real server, instead of assuming it
The section offered "an OpenPGP public key or an S/MIME certificate" and
only the first half had ever been tried. Every probe behind it used
OpenPGP keys, and every message the registry returns names OpenPGP --
including for input that is not OpenPGP at all -- so the server reads as
though OpenPGP were the only format it knows. Shipping the claim on that
evidence would have been a guess dressed as a feature, which is the one
thing this section is written not to do.
It holds. Confirmed live on 0.16.20 (2026-09-05) with a self-signed
X.509 certificate carrying emailProtection and an email: SAN:
registered, read back, destroyed. And Stalwart parses it as seriously as
it parses OpenPGP -- a malformed certificate is refused by a decoder of
its own, "Failed to decode X509 certificate: BER decoding error:
Expected Tag { class: Universal, value: 16 } tag…", which is a third
rejection wording and the reason the S/MIME half is real rather than
decorative. The mock now returns it for a certificate, so the branch
exists somewhere a client can meet it.
One thing found on the way: expiresAt is the registry's field and is not
derived from the key. A certificate valid for a year registers with
expiresAt null, so the card says "No expiry set" about a credential that
does expire. Left as it is, deliberately: reading the real date means
parsing the certificate, which is the second opinion this section
refuses to offer, and a date extracted here would disagree with the
server's own field the moment the two ever differed. What the row
reports is what the registry holds, and KNOWN-ISSUES says so.
|
||
|
jcoffey-dev
|
e93d42d27e |
Manage public keys, over Stalwart's x:PublicKey registry
A new Settings section, next to Identities & signatures: list, add, rename and remove the OpenPGP public keys and S/MIME certificates published on this account. Only public material -- no private key is stored, requested or sent by any of this. This is PR #67 revived. That branch was built against 0.16.19, closed unmerged on 2026-08-26, and shares no ancestry with main after the email scrub, so it is ported rather than rebased: the four files it added are carried over, the three it edited are applied by hand, and everything it claimed was re-probed against the live 0.16.20 on 2026-09-05. The i18n work is new -- nine catalogues landed on 2026-08-31, after that branch was written. What the re-probe confirmed, unchanged from 0.16.19: - An ordinary user may read *and* write their own keys, though the permissions table lists every sysPublicKey* permission as administrative. get and query both answered for a normal account, and a malformed create came back invalidProperties naming `key` rather than forbidden -- a rejection of the key, not of the person. - The server parses the key and says precisely what is wrong. So ihasmail does not validate key material; the server's message is shown verbatim, as password-policy rejections already are. - urn:stalwart:jmap is still absent from the session's top-level capabilities and present per-account, so the check that reads all three places is still the one that works. What it added, none of which was known before: - A key can parse perfectly and still be refused, with different words: a sign-and-certify key with no encryption subkey -- what `gpg --quick-generate-key` produces -- gets "Could not find any suitable keys in OpenPGP public key". That is the rejection somebody exporting from GnuPG will actually meet, and it is not a paste error, so collapsing both to "invalid key" would send them back to the clipboard for a problem that is in the key. - emailAddresses comes back as {} when empty -- an object where a JMAP list property should be an array. It type-checks, then throws in join() while the list renders. normalize() checked the shape already; there is now a test saying why, and the mock answers {} the same way, because one that helpfully returned [] would let that crash ship. - A create answers with the id alone, no createdAt, so adding a key reloads rather than believing the response. - destroy works and leaves the registry empty. PR #67 shipped that path untested -- its live probe was refused before anything was created, so there was nothing to destroy. - Patching `key` is allowed by the server. The mock still refuses it, now deliberately rather than for want of evidence: ihasmail replaces a key by adding one and removing the old, which keeps createdAt meaning what it says. x:EncryptionAtRest still does not exist on 0.16.20 -- asking for it is an unknownMethod. encryptionAtRest is a field on x:AccountSettings, and its value is a typed object ({"@type":"Disabled"}) rather than the bare string ROADMAP described. Nothing here writes it. An empty description is now sent as empty rather than filled in with "Key". The description is stored on the server, so a default invented in the client would be whichever language the adder happened to be using; the list labels a blank one at render time instead. Verified in a browser against the mock, not only in tests: both rejections reach the toast in the server's own words with the form still filled in, a good key renders its card, the kind is labelled from the armour header, renaming persists, removing asks first and empties the list, and the whole section reads correctly in German. |
||
|
jcoffey-dev
|
0871d3291b |
Write down what the last week's features actually do
FEATURES.md had nothing on three of them. The scheduling panel and what it will not show, the filter editors no longer discarding work in silence, and where compose-as-new can be reached from — including the reply strip, which is the one a thumb finds. KNOWN-ISSUES.md gains the free/busy finding, which is the sort of thing that page exists for: it was checked against the live server rather than assumed, free/busy between accounts turns out to need no sharing set up, and a principal offers no route to its calendars at all. Also what the check did *not* settle, and which way ihasmail errs in the meantime. ROADMAP.md gains the two things left deliberately unbuilt: a scheduling view you can visit with no event in hand, and per-message actions from the message list on a touchscreen, where the gesture that would open them already means "select". |
||
|
jcoffey-dev
|
ded2f4dc1b |
Ten languages, not nine: correct the count everywhere
The picker offers English plus nine translations. I wrote it up as nine in total with eight unread, which is off by one in the direction that undercounts the work and, worse, misstates how many catalogues are waiting for a speaker to read them. Nine of the ten are machine-made and unread — all of them, not all but one — so the sentence that matters reads more sharply than the wrong version did, not less. |
||
|
jcoffey-dev
|
c26ca90e01 |
Document the nine languages, and what Beta means on them
The translations shipped today and the docs still said "no languages but English". They also need to say the harder thing, which is that eight of the nine have never been read by anybody who speaks them. - README gains the language list, with the Beta caveat in the same line rather than a footnote. - FEATURES.md gains an Interface language section: the list, why it is a separate setting from the date locale, and the two design properties that follow — a missing entry renders English, and plurals are asked of Intl.PluralRules rather than assumed, which is why Russian carries three forms and Japanese one. - ROADMAP.md no longer lists translations as "not yet". What replaces it is the half that is genuinely not done: a translation anybody has checked. RTL is split out as its own entry, because holding Arabic, Hebrew and Persian back is a layout decision and not a queue position. - KNOWN-ISSUES.md gains two entries. The unread catalogues, which is the one thing on that page that cannot be closed by testing. And the coverage number that read 100% while two hundred strings rendered English in every language — recorded as a general lesson rather than an i18n one, since a coverage number measures what it can see and the rest is exactly what nobody is checking. |
||
|
jcoffey-dev
|
06943fd473 |
Mock: let an override move an occurrence, as the server does
Confirmed live on 0.16.20 (2026-08-31): one occurrence of a weekly 09:00 series moved to 14:00 comes back with `start` at 14:00 and `recurrenceId` still at 09:00. The slot the rule made stays put; only the clock time moves. The mock set `start` from the slot after merging the override, so it clobbered any `start` the override carried and a moved occurrence did not move. Per-occurrence *time* editing - one of the main things the feature is for - therefore looked broken against the mock and correct against the server, which is the wrong way round for a mock to be wrong. It also confirms the choice of handle: `recurrenceId` is the one name for an instance that survives both a renumbering and a move, which is why the store re-resolves from it rather than from `start` or a cached id. |
||
|
jcoffey-dev
|
91481965bc |
Calendar: never mutate an occurrence by an id we are holding
Verified against the live 0.16.20 instance, which found two things the
mock had guessed wrong about.
A synthetic id encodes a position in the expanded series, and writing a
`recurrenceOverrides` entry renumbers it. A five-week series came back as
`e i m q u` over 03-01..03-29; after one override was written to 03-08
the same five ids addressed 03-01, 03-15, 03-29, 03-08 and 03-22. Nothing
was rejected. A stale id is not invalid, it is wrong - a confident answer
about the wrong day - so a delete meant for one occurrence removes
another.
`recurrenceId` is the stable name for a slot in a series, because it is
the date. `updateEvent` and `destroyEvent` now look the current id up by
it immediately before acting, and refuse outright when the date has left
the series rather than falling back to the id in hand.
The mock had this exactly backwards: it kept ids stable on purpose, which
agreed with the belief that is wrong. It now renumbers too - a different
permutation to Stalwart's, with the property that matters - and a test
holds an id across a write and watches it change meaning.
Second finding: the inherited properties are dropped *after* the server
has decided to write an override, so a patch made only of them still
writes one, carrying the server-filled start and duration and nothing
else. `{"privacy":"private"}` on one occurrence answered "updated", left
privacy untouched, and left that date with no title at all. Sending
nothing when narrowing empties a patch was written as a principle - a
request whose response could only be a meaningless "updated" is worse
than no request - and it turns out to prevent real data loss.
Both recorded in KNOWN-ISSUES with the dates they were confirmed on.
|
||
|
jcoffey-dev
|
e41742a26c |
Stalwart 0.16.20 on the live instance
INBUXA moved 0.16.19 -> 0.16.20 on 2026-08-31 with eight seconds of downtime. A 0.16.x -> 0.16.x upgrade is a binary replacement: no data migration, no config change. Nothing ihasmail depends on changed. The session capabilities, blob, quota, submission and registry paths are untouched by the release, and `urn:stalwart:jmap` is still absent at session level, so the three-place lookup that sign-in turns on remains both correct and necessary. The Locale enum did move from POSIX names to BCP-47 (`en_US` -> `en-US`, `POSIX` dropped), which `normalizeLocale` already handled. The recurrence entry is rewritten rather than deleted. 0.16.20 added `CalendarEvent/set` support for synthetic ids, so per-occurrence editing is a thing the server allows and ihasmail does not do yet (#132) - and the refusal that used to catch a synthetic id reaching `destroy` is gone, which is why the base-id resolution wants moving into the store (#133). Dates on the existing entries are left at 0.16.19 on purpose: they record what was actually run, and the upgrade was read from the diff, not re-run. |
||
|
jcoffey-dev
|
95f640b24c |
Point at the Coffey-Labs organisation
The repositories moved off LINUXexpert-org. The old URLs redirect, so nothing was broken, but a redirect is not a correct address to publish. The SOURCE_URL defaults matter most: the AGPL asks whoever runs a modified version to offer that version's source, and the sign-in page and About screen show this link. It is in four places that have to agree -- the compose file, .env.example, the server default and the web fallback. The rest is documentation and issue links. |
||
|
jcoffey-dev
|
8d475e2b07 |
Refuse to save a script we only partly read
The transport fix stops the truncation that caused #76, but the save path had no answer for a baseline that arrives incomplete. It is neither unknown nor empty, so every existing guard passes it through: it parses into a shorter rule list that looks exactly like a script with fewer rules, and saving writes that back over the real one. Check the script against the shape the generator emits instead. Every rule comment parses, every enabled rule has an if and a closed body under it, every block ends with a blank line. Structural rather than a re-serialize-and-compare, so a script written by an older version whose serializer differed is still editable. The rule editor reports a short script as unreadable rather than showing the rules that happened to parse, since a list that looks complete over a script that is not is the most dangerous thing it could offer. A cut at the end of a complete rule block is still a valid shorter script and cannot be told apart from one; that residual is the proxy's to cover. |
||
|
jcoffey-dev
|
0277b5b6a8 |
Send the length of the bytes we are actually sending
A gzip response is decompressed before the blob proxy sees the body, but its content-length still describes the compressed bytes. Copying that header onto the longer body made the browser stop reading that many bytes in and call the download complete, so files arrived truncated with nothing reporting a failure. It took a hop that compresses to show up, and one that only compresses above a threshold to look like a race: a Sieve script stayed intact for two rules and came back cut off mid-rule once the third pushed it past 1 KiB. Ask upstream for identity, and forward no length at all rather than one that describes different bytes. |
||
|
jcoffey-dev
|
4c4821b5db |
Ask for shareWith on mailboxes too
The third store fetching everything by asking for nothing. Same cause as the calendars and address books a commit ago: Stalwart does not return `shareWith` unless a client names it, so mail folders never looked shared either. This one has a narrow but real consequence. Sharing a mail folder is withdrawn, because Stalwart stores the share and never delivers it, and the only way left to clear one already made is the "Stop sharing" entry -- which appears only when a folder looks shared. Without the property it never did. The escape hatch built for exactly that situation could not be reached from the situation it was built for. Found by looking for the rest of them rather than waiting for the next report: `ids: null` with no `properties`, across the app. The others it turned up -- Sieve scripts, identities, the vacation response, quotas, participant identities, push subscriptions -- have no `shareWith` to lose, so mailboxes were the last. The mock hides it here as well now, so all three are honest. |
||
|
jcoffey-dev
|
506865ca67 |
Ask for shareWith, or the server does not send it
Nothing was ever badged as shared, "Stop sharing" never appeared, and the share dialog opened on "not shared with anyone yet" over live shares. The sharing itself was fine. The client simply never learned about it. Stalwart does not return `shareWith` unless a client names it. A `Calendar/get` or `AddressBook/get` with no `properties` comes back without the field at all -- not null, not empty, absent -- confirmed against the live 0.16.19 on a calendar and an address book that really were shared with another account. Omit the list and there is no `shareWith`; name it and the sharee is right there. Both stores fetched everything by asking for nothing, and got less than they would have by asking. They name the properties now. The dialog is the part worth dwelling on. It seeds itself from the `shareWith` it was handed, so it has been showing an empty sharee list on collections that were shared -- the one screen whose whole job is managing sharing, and the one most confidently wrong about it. Someone looking there to see who had access, or to take it away, was told there was nobody. Files never had this: `fileNodeProps` has named the property since file sharing went in, for the same reason and after the same surprise. The two stores that fetched with `ids: null` and no properties are the two that were blind. The mock now omits it the same way. One that hands `shareWith` over unasked lets a client that never asks look correct everywhere except against a real server, which is exactly how this got here. Verified against that mock: sharing a calendar puts the sharee in the store, badges the row, adds "Stop sharing", and the dialog lists them -- while a `Calendar/get` with no properties still comes back without the field, so the mock is now failing the way the server does. |
||
|
jcoffey-dev
|
5e5bec31b7 |
Remember an added address book when the server will not
"You are not allowed to modify this address book." That is Stalwart's answer to a sharee subscribing to a book shared read-only, and it is a fair one: `isSubscribed` lives on the collection rather than on the reader, so adding one is a write to the *owner's* account. The identical write on a shared calendar is accepted. The difference is the server's. So the flag is still asked for first -- a preference the server holds is one every client agrees about -- and when it is refused the answer goes in the reader's own synced settings instead, as `addedShares`, keyed by account and collection. Either record counts as added, and the rule has a test of its own because three components ask the question and they must not drift apart. Two things about how this hid. The refusal arrives as a *successful* response with the id in `notUpdated`, so the version that ignored it saw nothing wrong and the button simply did nothing -- fixed a commit ago, and it is what turned "the + does nothing in Firefox" into a sentence from the server. And it cannot be seen from the owner's account at all, where the write succeeds: it took two browsers signed in as two accounts to find, which is why it survived every check made from one. The mock refuses the same write for the same reason. One that accepted it would have gone on agreeing with the belief that shipped. Verified against it: adding the shared book is refused by the server, recorded in settings, and the book moves to "Shared with me" with its contacts reaching the To field; removing undoes all three; and it survives a full page reload, which is the point of putting it where the settings live rather than in this tab. |
||
|
jcoffey-dev
|
350f4f4197 |
Put address books in the left pane, other people's included
Address book sharing was withdrawn a few hours ago on a report that it behaved like mail folder sharing. That was wrong -- it works -- and it is back, built the way Files is rather than the way it was. Three things it inherits from Files. Shared books are listed in the app's own left pane instead of behind an account switch in the profile menu. The reader's books and other people's sit under separate headings, since a book belonging to somebody else behaves differently and a single merged list would be quiet about whose contacts you are reading. And opening Contacts re-reads the session, so a book shared while the tab was open turns up without signing out and in again. The books pane the view kept to itself is gone, and with it the last module that ignored the sidebar it was given. The one thing Files does not need: shared contacts have to answer when somebody types a name into a To field, so they are loaded up front rather than when a book is opened, and they are offered by `suggest` and found by `lookupByEmail` alongside the reader's own. Their own cards win a tie, since a card someone wrote themselves should beat a colleague's copy of the same person. That is the difference between a shared book you can look at and one you can use. Cards from a shared account are held apart from the reader's rather than merged in, and keyed by account as well as id. Ids are only unique within an account -- two accounts each having a book `ab1` is ordinary -- and a flat map would have had one silently replace the other. The mock grew an address book in its shared account, with contacts in it, because none of this could be exercised otherwise. KNOWN-ISSUES records the withdrawal as the mistake it was rather than leaving it in the history looking like a finding. Mail folder sharing stays withdrawn: that one really is broken. |
||
|
jcoffey-dev
|
1e2db95577 |
Stop offering to share mail folders, and let a share be removed
Sharing a mail folder does nothing. `Mailbox/set` takes the `shareWith` map, `Mailbox/get` reads it back, and the folder never appears for the account it was shared with -- confirmed on the live 0.16.19 with a folder shared read-only to another account on the same server, which never saw it. Stalwart's sharing documentation lists calendars, address books and file storage; mail folders are not among them. Nothing anywhere reports a failure, so a client that trusts what it reads back shows the share as live for ever, which is what happened. The entry point is withdrawn. Address book sharing goes with it on a report that it behaved the same way -- not reproduced, and contradicted by Stalwart's own docs, so that one is expected back; it is out because offering a share nobody can verify was worse than the gap. Files and calendars are untouched. Removing a share was impossible, for a reason worth writing down. The dialog rendered the list of who a thing was shared with *inside* the branch that runs when the directory has principals to offer. A server with `allowDirectoryQueries` off returns none -- that is the default, and it is how these shares came to be made in the first place -- so the dialog showed one line of hint and nothing else. The share was there, and there was no way to see it, let alone remove it. The list is now rendered whatever the directory says; only the control for adding somebody new depends on having somebody to add. So the withdrawn entry points do not strand what they created: a folder or book already shared still offers "Stop sharing", which is the one thing you want when the share is invisible everywhere else. The API was never the problem, which is worth recording since it was the first guess: `shareWith: null` is accepted and clears the map, tested against the live server on the stuck folder, which is now unshared. |
||
|
jcoffey-dev
|
9618a0278c |
docs: slim the README, split out known issues and roadmap
The README had grown to 330 lines and was carrying three audiences at once: installing, using, and working on ihasmail. docs.ihasmail.org covers the first two now, and ihasmail.org covers the feature tour, so the README links there instead of restating them. - Known issues / pending QA → KNOWN-ISSUES.md, verbatim - Roadmap / not yet → ROADMAP.md, verbatim (its "see Quick start" pointer now aims at the install docs, since that section is gone) - Dropped the env-var table (docs.ihasmail.org/configure/), the shortcut list (/shortcuts/), the Docker quick start (/install/) and the long feature list (ihasmail.org/#features), leaving a nav table at the top and a six-line summary of what's in it - Kept and tightened what is only true of this tree: architecture, dev commands, the mock, version numbers, deploying - Version examples refreshed from 2.16.57 to the current 2.16.84 |