Skip to content

History

Revisions

  • The landing page is now the page GitLab opens. GitLab's Wiki entry takes a visitor to the page named home, and the wiki had none, so the project's Wiki link fell through to the bare list of pages; the landing page is renamed from Hmail-Server to home, its heading names the product, and the sidebar's index link points at it. No other page linked the old name. GitLab also has no footer, so the release stamp, the licence, the repository link and the way to report a documentation error appeared on no page at all; they now close the sidebar, which GitLab shows on every page. The stamp says that 6.3.3 is the latest release, at schema 6040, and that the tree after it, not yet released, is at schema 6096. A documentation error is reported as a GitLab issue with the documentation label. The footer page stays, for GitHub if it returns, with the same stamp and the same GitLab links.

    Christopher Holloway committed Sep 24, 2026
    1dcc04b
  • The wiki's links move from GitHub to GitLab, where the project has lived since 22 September 2026. GitHub suspended the account on 18 September and every one of the project's GitHub addresses answers 404, so the download links, the source links, the security route, the support route and the "report an error" link all led nowhere. Every link to a file in the repository now opens it on GitLab, and the four community files that moved to the repository root on master 540347500 - CONTRIBUTING.md, SECURITY.md, SUPPORT.md and CODE_OF_CONDUCT.md - are linked there, which also mends the seven links to a root SECURITY.md that did not exist when they were written. The download links open the latest GitLab release, and the installer has a link that always fetches the latest one. A private report goes to a GitLab confidential issue or the project's Service Desk address, a question is an issue with the Question template because GitLab has no Discussions, and a reader who wants to hear of releases is told how to watch the project on GitLab. The Project Handbook, written against GitHub on 4 September, says that its GitHub process is the project as it was then. The GitHub facts that stay are facts about the product, and each now says what is true of it: the update feed the server reads by default, which answers 404, so a check fails with "The update feed answered HTTP 404." until UpdateFeedUrl names another feed; the Sigstore identity and issuer that signed every release up to 6.3.3, which verify those files wherever they are hosted and which the verifier's defaults still name, so a release signed anywhere else is refused unless the three settings are changed; and the two GitHub addresses compiled into the product, the Policy line of the security.txt the server serves and the Control Panel's About link. Every GitHub issue, discussion and pull-request number written with a hash is now written in words - "GitHub issue 114", "GitHub discussion 18", "upstream PR 602" - with the kind the repository's CHANGELOG gives each number, because GitLab turns a hash and a number into a link to its own issue of that number, which is something else. The one maintainer handle left in running text is in code, and the webmail's mentions no longer read as a GitLab user. Four things GitLab rendered wrongly are put right. The Stopping Spam link to Routes and Relays was split by a line break and led to a page that does not exist. The Fuzzing page's two repository-relative links resolved inside the wiki; they open the fuzz folder and its regression README on GitLab. Placeholders written outside code, such as <host:port>, <addr> and <culture>, were read as HTML and dropped or turned into links; they are in code now. And the Assurance Case's eight section headings began "1. " above a setext rule, which CommonMark reads as a list and a thematic break, so its contents links had nothing to land on; they are ATX headings with the ids those links name.

    Christopher Holloway committed Sep 24, 2026
    3169cb4
  • The client-connection page gains the delegated mailboxes the Autodiscover answer now carries, to whom they are answered, and what Outlook does and does not do with them.

    @chrisholloway5 chrisholloway5 committed Sep 22, 2026
    3be6af3
  • The Installing on Linux page said the apply step refuses on Linux, which the tree after 6.3.3 made untrue. The live update now applies there: the unprivileged server writes a request into /run/hmailserver, a root path unit takes it and runs /usr/lib/hmailserver/hmailserver-update, which checks the request against root's own configuration, stops the unit, verifies the package again as root against its Sigstore bundle, refuses anything that is not a genuine upgrade - the version read from the package and compared with what dpkg or rpm says is installed, so a signed but superseded release cannot be put back - installs, waits for the server to come back, rolls back if it does not, and writes the outcome the Deck shows. The section says how to check that a machine can do it at all, that the Debian and RPM packages enable the path unit while Arch leaves that to the administrator, and that a refused request is explained in the journal and nowhere else. Labelled as in the tree and not yet released, as the page's other such paragraphs are.

    @chrisholloway5 chrisholloway5 committed Sep 18, 2026
    147a7c2
  • The Installing on Linux page walks the first domain in the Control Deck, with curl kept as the alternative, says what the Deck reaches by the census of 17 September 2026 - 25 views, 382 of the 388 properties the desktop program writes - and gives the regression suite's measure for the tree of 16 September, 1,606 tests against a Linux server with 1,326 passing, run as two CI halves from the 17th.

    @chrisholloway5 chrisholloway5 committed Sep 17, 2026
    d5c752a
  • The changes page carries the third and fourth batches of the tree after 6.3.3 - the twelve branches that landed as batch 10 on 16 September 2026 (sender lists and digests, roles, DKIM rotation, bounces and the suppression list, the breach check, accounts from a spreadsheet, signatures and the disclaimer, the audit trail's holes, the settings store's edges) and the sixteen that landed as batch 11 the same evening (webhooks, country blocking, sessions and devices, Web Push, complaints, mailbox move, the reputation watch, spam traps, the encrypted backup, the OpenPGP key store, changed from stock, response compression, sealed mail, the honest S/MIME, the restored shares, the bind-address fix for issue 276, the star key), each with its schema step and its page in the repository, all labelled as in no release yet. The schema sentence runs to 6059, and the landing page's at-a-glance table says 6059 in the tree, 218 REST paths and 317 operations, and the 2,791-test gate that was run split across two benches.

    @chrisholloway5 chrisholloway5 committed Sep 16, 2026
    1851158
  • The Linux suite on the tree now on master: 1,606 tests, 1,326 passed, none failed, 280 skipped The pages carried a placeholder for the Linux figures until the run finished. It ran on 00bec4412, which is the gated 3233b0cc4 with one change to the Linux test shim - it now puts [Settings] back through the settings store instead of rewriting hMailServer.ini before every test - so the server it tested is the one the Windows gate tested. Six pages name the figures where they named the placeholder.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    ef3f039
  • The Control Panel reference says where a [Settings] value is read and written once the database is the store The pages table pointed at section 6 for the mechanism, and section 6 still described 6.3.3 alone: the local file when it is on the same machine, otherwise COM. The tree after 6.3.3 reads over COM first and falls back to the file only when it exists locally, writes over COM only, and tells a Control Panel with no session that the settings are in the database and need a connection, which is what IniFeatureStore.cs does at 135-162 and 186-197.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    2872ca2
  • Two pages that still called the file the settings store, and six figures in the tree's pages settled against the code The stalled-mail guide and the Control Panel pages table were written when hMailServer.ini was where a setting lived, and neither was in the sets the writers of the last commit covered. Both keep what is true of 6.3.3 and say what the tree after it does, in the wording the repository's own copy of the guide took at 5e7555a99: the keys are stored in the database from schema 6042, changed in the Control Panel, over PUT /api/v1/settings/ini/{name}, with hmctl ini set or Settings.SetIniSetting, still copied into [Settings], and an edit to the file is reported as HM5804 and put back at the next start. The pages table gets one paragraph for every cell that says INI, checked against IniFeatureStore.cs as it now is - reads over COM with the file as the fallback when there is no session, writes over COM only, and a Control Panel without a session says so instead of writing a line the server would undo - and the seven cells that named the file carry the release beside it. Six doubts the checkers left were settled by reading the code at 00bec4412, and four of them were wrong on the page. The Deck's Reports view does draw two bar charts, as SVG, for traffic and storage, and the page now says which. A report is not "at most three grouped queries": the four sections counted from the trace are one each, mailboxes one, storage two and volume six, one per metric, with the trace query capped at 100,000 grouped rows as the page said. The Deck harness figure is written as current - 458 checks at 00bec4412 - with the 336 and 292 kept as the history they were, since both were reproduced by running the harness from the languages commit and its parent. The X-hMailServer-External stamp is shown by the webmail as a warning line above the message, and the page now gives the words and the badge that stands beside it whether or not the domain stamps; the first-contact line is named too. docs/Syslog.md does hold rsyslog configurations for all three transports, and that bullet stands. The settings reference's arithmetic for the keys outside the bootstrap sections was two counts side by side, one of them wrong: there are 21 [LDAP] keys in LdapSettings.cpp, not 20, and the sentence is now one set of numbers, 242 + 4 + 21, with a note that the baseline file holds none of the 25 because it lists only what IniFileSettings reads. The Linux page's proof table still said the schema was built at 6031 without saying when that was true; one sentence after the table gives the schema each release shipped and the tree's 6045. Line endings are each page's own: four are CRLF, the Linux page is LF, and the edit was made on bytes.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    8089dc0
  • The wiki describes the tree after 6.3.3 as it lands on master: the settings store, the audit trail and alerts, what a domain does to a message, remote-domain policy, a backup that carries everything, and the rest of three batches Twenty-seven pages, each written from the code at 3233b0cc4 and then checked sentence by sentence against it by a second reader: 166 claims verified, 23 corrected before this commit. Everything the tree holds that no release has is labelled as in the tree after 6.3.3 and not yet released, and the next release is called that rather than given a number. The changes page carries the four schema steps 6042 to 6045 in section 2, the second and third batches in section 4e beside the first, the gate for 3233b0cc4 (2,410 tests, 2,402 passed, none failed, 8 skipped; the Linux figures are a placeholder until that run lands), and in section 5 the changes an upgrade makes with no switch - above all that the database is the settings store, that an edit to [Settings] in hMailServer.ini is undone at the next start and reported as HM5804, what to do instead, and that the password pepper stays in the file and out of every backup, so a restore onto new hardware needs it brought along. Fourteen pages that told a reader to edit the file now say how the same setting is changed once the store lands, and what an edit to the file does then; the settings reference says the table of INI keys is closed. The feature pages cover the backup that carries every per-account store, the audit trail and alerts with what each does not yet record or raise, syslog export, per-domain reports, remote-domain policy and mandatory TLS, SPF as RFC 7208, hmctl's configuration document, the tours, and the REST routes counted at the commit rather than guessed at. The checking found things the tree itself gets wrong, which are recorded for the next batch rather than papered over here: hmctl's configuration document has an empty ini section because it reads a route that answers names only; the packaged Linux ini's RestApiPort=0 is adopted into the store at first start, so the packaging README's edit-the-file way of turning the REST listener on no longer works; the OpenAPI text for the ini routes and the note the server writes into hMailServer.ini still describe the file as the store; and five repository documents say what their wiki copies said before this commit.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    d1d2412
  • The wiki catches up with the tree after 6.3.3, and one thing the code says that no page said. Section 4e of the changes page is what is on master and in no release at all - checked line by line against the code at 916dec6a1 rather than against the commit messages, which is how three of the draft's claims came to be corrected: the Control Deck speaks twenty languages and the webmail twenty-three, so it is twenty of the webmail's languages rather than "the same twenty"; the server settings page has twenty-nine tabs, not thirty-one; and the Control Panel redesign added thirteen texts to each of the seventeen catalogues, not twenty-six. Everything else in it was verified where it could be: the 592 zone names counted out of the built-in table in ICalendar.cpp, the 501 texts counted in a Deck catalogue and the 631 in a webmail one, the eighteen dialogs counted as the classes deriving from FluentDialogWindow, the two calendar tables read out of Upgrade6040to6041, the schema step read out of DBUpdater's registration and REQUIRED_DB_VERSION, and the four new routes read out of the router rather than out of the OpenAPI prose. The gate numbers are the one thing left blank: the full Windows suite was still running on this exact tree, so the section carries a marked placeholder and section 1's master row says so, because a number invented here is a number somebody quotes. Schema 6041 is in section 2 as a row of its own, marked as in the tree and in no release, and the two places that said "6040" now say what is where. The Control Panel pages describe the program as it is now. The redesign of 15 September is in the tree and unreleased, and every paragraph about it says so, because a reader on 6.3.3 opens a window with the old chrome: the command bar with its search, status pill, theme toggle and administrator menu, the sidebar that collapses to a rail below a thousand pixels, the ten scaffold components, and eighteen dialogs sized to their content rather than to a pixel width typed into a constructor. What did not move is what a reader has learned - the navigation map, the page titles, the tab headers, the setting captions, the automation ids - and the pages say that too, which is why Control Panel Pages was not rewritten around it. Three counts were behind and are corrected from the code: 393 settings in the Ctrl+K index rather than 389, 343 captions with an Alt key rather than 340, and 3,403 texts in each catalogue rather than 3,376. Two of the four settings that moved the index shipped in 6.3.2 and the reference had missed them, so the per-page table's auto-ban and web-services rows are re-counted as well. The settings pages carry the rule adopted on 15 September: a new setting goes in the database, in hm_settings with a Control Panel editor, and no new key is added to hMailServer.ini's [Settings] section. Both pages say the part that matters more than the rule - that nothing already there has moved. The 238 keys are still read from the file, in 6.3.3 and in the tree, and the Settings Reference is still their reference; the migration that flips which store is the truth is a roadmap row, not an event. The file keeps the directories, the database connection and the administrator password and second factor, and anything that genuinely has to be readable before the database opens is an argued-for exception. The API reference gains what the server publishes and the page did not. Comparing the route table with the OpenAPI document the server emits found seventy-four paths of a hundred and forty-five unnamed, so the administration families are now all there: the six anti-spam collections and the blocked attachments as resources, an account's application passwords, folders, folder permissions and message object, all of which shipped in 6.3.3 and were nowhere on the wiki - and then the four that are in the tree and unreleased, groups with their members, the message copy, the rule-criterion probe and the calendar expansion, each with the body it takes and what it answers. The roughly forty /api/v1/me routes the webmail uses are still families rather than rows, and the page now says so in its own words and points at the OpenAPI document as the authority rather than leaving a reader to think the table is complete. Stopping Spam was left alone deliberately. The brief said SPF was being replaced this week; at this commit it is not. The evaluator is still the original one with the ten-term limit and the void-lookup cap, nothing under AntiSpam or SMTP/SPF has changed since v6.3.3, and the page describes it correctly - so the honest edit was none. The finding is on Backup and Restore, and it is the reason this pass was worth running against the code. The built-in backup's XML index is built by each business object's XMLStore. An account's record carries its password, its TOTP secret, its fetch accounts, its application passwords, its rules and its folders. Nothing anywhere writes hm_contacts, hm_accountprefs, hm_scheduled, hm_files, hm_smimekeys, hm_calendars or hm_calendarobjects - no XMLStore reads them - and Message::XMLStore writes Flags but not messagekeywords. So the address book, every webmail preference a user chose, their labels, their second and third stars, their follow-up flags, their scheduled and snoozed mail, their file links, their S/MIME keys and (in the tree) their calendars are in no archive this server writes. Worse than absent: every one of those tables cascades from hm_accounts, and a restore calls Domains::DeleteAll before it puts the backup's domains back, so a restore deletes them. The page now says it, in the short version and in a section of its own, with what to do instead - back the database up with the database server's own tool, and restore from that when recovering a whole server. No page said any of this before. Monitoring and Health was re-checked rather than rewritten: not one metric family, bucket bound, probe condition, reason string or default has moved since it was verified at 6.2.28, and the only change to MetricsServer.cpp is the Linux accept-loop stop. It gains a section on reading the server from a shell - hmctl status, log list, log tail and backup, with the routes behind them - marked as in the tree and unreleased, since a reader on 6.3.3 has neither client. Smaller corrections found while checking: the capabilities page's web-services entry predated CardDAV entirely and now carries both DAV protocols, their paths, their HTTPS-only rule and what CalDAV does not do; the installing page has a paragraph on winget and Chocolatey that says plainly they do not work yet, because a first submission is reviewed by a person; What hMailServer Is and Is Not still called 6.3.3 unreleased and said the webmail speaks twenty languages; the Control Panel reference still called 6.3.0 the current release; and the fuzzing page's "iCalendar reached through attachment handling" is now also reached by an authenticated CalDAV PUT, which is a shorter path to a parser that expands attacker-chosen numbers - the COUNT=100000000 defect fixed by hand this week is the argument for the target.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    04f3622
  • The settings page says which of the two stores a setting is in, and what follows from it. The page already explained the file, how it is found and the mirror that schema 6011 added; what it did not say is that there are two stores at all and that which one a setting is in is history rather than design. The database's hm_settings carries everything the COM Settings object has always carried, and it travels with a backup and between nodes that share a database; the file's [Settings] section carries the 238 keys this fork has added since 6.2.10, each with a Control Panel editor and a REST route, each mirrored into hm_inisettings so a backup and a remote Control Panel can see it, and each still read from the file by the server. The consequence is the part a reader needs: a change to a file setting is saved now and applied at the next start, and two servers cannot share one file. The roadmap item that flips it - the database as the store, the file for what is needed to reach the database - is named with its section.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    8afed3f
  • A page for the two command-line clients, which are in the tree since 15 September 2026 and in no release yet. hmctl is one Python file with nothing but the standard library behind it, which the .deb and the .rpm install as /usr/bin/hmctl, and the HmailServer PowerShell module beside it is the same vocabulary in PowerShell's grammar; both speak the REST API rather than COM, so both work against a Windows server, a Linux server or one on another machine. The page is the repository document copied here as the fuzzing page is: the verbs by resource, the credentials and why --insecure is refused anywhere but the loopback, accounts imported from and exported to a CSV file with a dry run and the rule that an address which already exists is left alone rather than overwritten, and what neither client does - no message store, no backups of its own, no administrator password. The sidebar lists it under "Extend it" beside the two APIs, the REST API page points at it in its first paragraph, and the landing page's index and its "what do you want to do" table carry it.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    24e5745
  • Four pages catch up with what is in the tree since 6.3.3 and with what shipped in it. The client page gains a CalDAV section beside the CardDAV one, written the way the CardDAV section is: the same listener, the same discovery and the same credentials, one calendar per account at /dav/calendars/<address>/calendar/ made the first time it is asked for, VEVENT and VTODO in the one collection so a phone's calendar and its reminders are the same thing, a repeating event expanded by the server across daylight saving in any of the 592 zone names the new iCalendar module knows, and calendar-query, multiget and sync-collection with ETags. It says what is not there too, because a calendar that silently drops an invitation is worse than one that never offered: no iMIP, no free-busy, no per-calendar time zone, no partial calendar-data, and no time-range filter on an alarm. The webmail paragraph loses a label that went stale the moment 6.3.3 was published - it said "6.3.3, unreleased" of what is now the current release - and gains the twelve features that followed it, each in the reader's terms rather than the roadmap's: the page installed as an app with its unread badge, contacts in and out, saved searches as folders, the reader's own time zone, undo on three more actions, the tracker notice counting what it kept out, swipe actions and snooze presets, three stars that every IMAP client sees as keywords, rows coloured by a rule, @mentions that add the person to the recipients, a formatted signature, and Report phishing beside Junk. The container page gains the two files people expect and this repository now ships. The Compose section says that the file is in the tree, that a workflow resolves it with docker compose config on every change - so it is a file known to parse rather than an example in a document - and how it differs from the page's own shortest-thing-that-starts version: the two passwords are Compose secrets read from files, and the REST certificate is mounted in. Then a Kubernetes section: a StatefulSet of one, because a message store is not something two pods may share, the three volumes as claim templates, the database pointed at and never bundled with the chart refusing to render without a host, the two passwords as a Secret the chart makes or an existing one it is pointed at, the REST listener needing a kubernetes.io/tls Secret because off loopback the server requires TLS, a LoadBalancer with externalTrafficPolicy Local so the server sees the client's address, and probes on port 25 as the image's own health check is. It ends with how the chart is proven, since neither Helm nor Docker is on the bench that gates the code: linted, rendered with a real install's values, and checked for its two refusals, on every change. The REST page gains wave J's routes with the unreleased label: the account groups as a resource (a listing, a create, a read, a rename, a delete, and the members beneath a group as their own small collection, because a membership is a pair and not a property of either side), a message copied into another folder of its account, and the rule-criterion probe that answers what the delivery path would decide without reading or writing anything. And the fuzzing page is re-copied from the repository document it declares as its source of truth, which now carries the nightly job: the three harnesses every night on a hosted runner, the corpus kept in the Actions cache under a key that carries the run id so it grows, and the crash, hang or violated invariant that fails the job and lands the reproducer as an artifact.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    8e3f188
  • The client page: bringing contacts in from Google Contacts and Outlook through the webmail's Contacts page, and taking them out as vCard or CSV - in the tree since 15 September 2026, unreleased.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    a89810c
  • 6.3.3, published 15 September 2026: the changes page's section 4d is the release now, with the stamped binary's gate, the timeline row and the picture carry it, the schema section runs to 6040 with the two steps of the release, the landing page's current release and schema rows move, the footer names it, and the live-update and CardDAV paragraphs on the upgrading and client pages lose their unreleased labels.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
    c5b6fe2
  • What is on master since 6.3.2 and in no release yet: a section on the changes page with the gate numbers of the batches that landed it, the live-update note on the upgrading page, CardDAV on the client page.

    @chrisholloway5 chrisholloway5 committed Sep 14, 2026
    e765d73
  • Two pages still said the built-in page is self-service and not a mail client, and pointed readers at Roundcube - true until 6.3.0, wrong since 6.3.2. What hMailServer Is and Is Not, and Connecting a Mail Client, now say what the page is since 6.3.2 and what 6.3.3 brings, labelled unreleased.

    @chrisholloway5 chrisholloway5 committed Sep 14, 2026
    32718b3
  • The API reference after the Linux suite waves (PR #251, merged 14 September 2026): thirteen route rows for the families the waves added - the directories and the ini section of the settings, the logon-failure list, domain aliases, a domain read whole and renamed, an IP range updated in place, the server messages, Sieve evaluation, fetch accounts, scripting and the backup settings - and the status row gains the build object (script_engine, argon2id, post_quantum_key_exchange), each labelled unreleased until 6.3.3.

    @chrisholloway5 chrisholloway5 committed Sep 14, 2026
    4de84cf
  • The wiki after 6.3.2: the changes page's timeline gains 6.3.2 (published 13 September 2026; the full Windows suite 2,219 tests, 2,211 passed, 0 failed, 8 skipped), the schema section runs to 6038, the landing page's current-release and schema rows say 6.3.2 and 6038, and the footer's date moves.

    @chrisholloway5 chrisholloway5 committed Sep 13, 2026
    bdff831
  • The container page no longer says the base release is the only one the package installs on: Boost is linked statically since 11 September, so the .deb installs on later releases too; the image stays on the release it was built for

    @chrisholloway5 chrisholloway5 committed Sep 11, 2026
    d3ba09a
  • Running in a Container: the image, the variables the entrypoint writes, reaching the API, a Compose first start, volumes and ports, upgrading, backups, auto-ban from the host, and how the image is proven; linked from the sidebar, the index and the Linux page, labelled as published with 6.3.2

    @chrisholloway5 chrisholloway5 committed Sep 11, 2026
    03f409d
  • Auto-ban below the server, documented: the three settings on the capabilities page, and the hook, the capability it needs and fail2ban on the Linux page, labelled unreleased until 6.3.2

    @chrisholloway5 chrisholloway5 committed Sep 11, 2026
    1b8ff5c
  • 6.3.1 is the current release, and the installer is Authenticode-signed from it: the footer and the landing page say 6.3.1, and the six pages that said the installer carries no Authenticode signature say what changed on 11 September 2026 and what did not (SmartScreen, and every release before it)

    @chrisholloway5 chrisholloway5 committed Sep 11, 2026
    1d76bad
  • The portal is a webmail since 6.3.0, so the two pages that tell a user what it is say what it gained The self-service portal was documented at its 6.2.28 scope - a page that signs in and reads mail. 6.3.0 gave it addresses on the fragment, so a folder, a message, a search and a half-written draft each survive a reload and can be linked to; a change probe it polls every six seconds and not at all while the tab is hidden; folder create, rename and delete under IMAP's own rules and refused in IMAP's own sentences; and inline images, which it fetches itself and hands to its sandboxed frame as data: URLs, because the frame's opaque origin is exactly what stops the session cookie travelling to a subresource request. Neither page was wrong. Both understated the thing a user is deciding whether to use.

    @chrisholloway5 chrisholloway5 committed Sep 10, 2026
    d8d0b0c
  • 6.3.0 is published, so the pages that were waiting for it say so: Linux is released rather than "in the tree", the write surface has a release number, and the version that never existed is gone The Linux page opened with a banner saying the port was in the tree and not yet released, and that the first release to carry packages would be "the next one". That release is 6.3.0 and it went out on 10 September 2026, so the banner now points at it and the install commands name the packages that are actually on the release page rather than a version number nobody can download. Five places named 6.2.29. There is no such version and there never will be - the release after 6.2.28 is 6.3.0, and README.md already says why - so the two package filenames, the two "since 6.2.29" notes about relative directory values and the Installation paths diagnostic's label all move to 6.3.0. The API reference's route tables gained the write surface a day before the release but nothing in them said which release it belonged to, while the rows around them carried 6.2.27 and 6.2.28. A reader could reasonably have read the settings, rules and certificate routes as shipping in 6.2.27, which is half true and the misleading half: those routes could only be read then. Section 4 now says which routes arrived in 6.3.0 and why the method column is the one to read, and the scope note names the units the write surface was split into. The landing page's At a glance table was stale in five of its rows: the release and its build number, the platform (Windows only, when the whole point of 6.3 is that it is not), the administration surfaces, the suite's size and the wiki's own page count. The route count was stale in a way worth recording: it said 65, which matched neither the number of rows in the reference table nor the number of distinct paths at the commit it was written from, so it is now 82 routes over 68 paths, both countable from the page it points at. The Control Panel reference said "the latest, v6.2.28", and one thing under ControlPanel did move in 6.3.0: the sign-in box's user name is a literal again (#156), which is why a fresh installation in Chinese could not sign in. The page says so, with the twenty-one files that differ between the tags. The footer stamped 6.2.28 on all fifty-one pages.

    @chrisholloway5 chrisholloway5 committed Sep 10, 2026
    7863009
  • The Control Deck writes: the API Reference's page section says what the ten views do, how the page signs in for a session instead of keeping the administrator password, and why a 401 no longer opens the browser's own credential box over it The REST page's session section is named for both browser sessions now, the portal's and the Deck's.

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
    6da57ea
  • The REST API writes: the route tables on the REST and API Reference pages carry the settings groups, the rules, the routes, the aliases, the account update, the certificates and listeners and the restart in place, with what each refuses and who may call it The Installing on Linux page's suite row and the Regression Test Environment page's "On Linux" section say what the write surface changed for the Linux run: 278 of 319 pass where 233 did, and what still skips is a COM-only call or the suite's fake DNS zone rather than a route that does not exist.

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
    bb2a37f
  • The regression suite on Linux: the Installing on Linux page's suite row says what runs (319 of 2,135 tests, 233 passing, 86 skipped for named API gaps, 0 failing, and CI on every push), and the Regression Test Environment page gains an "On Linux" section with the variables, the test-tree recipe and the command The section is the one hmailserver/docs/RegressionEnvironment.md carries at f18c38a04. A first draft of this page edit had appended an older copy of the whole page around the new section (338 lines became 630); this is the committed page plus the sixty lines of the section, inserted before "When a run is interrupted".

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
    1d7ec4f
  • Linux: an Installing on Linux page from the packages to a delivered message, the relocation runbook as a page, the Installation paths diagnostic in the Monitoring table, the domain routes on the REST page, and the platform notes the Settings and Capabilities pages needed

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
    2840c7e