History / The REST API

Three more clauses of the two rows 038bade corrects say what the code and the documents have said since 6.3.4, where they still said what 6.3.3 did. The REST API's row for the ini routes says that in 6.3.3 the list answers key names only and that since 6.3.4 it answers each with its value too, a secret's as (set), as CommandLine.md's note on the secrets among the ini keys and SettingsApply.md's row for REST say with batch51 on master, 5e49abf06 (RestApiSettings.cpp, IniList), where it said that the list answers key names only. The APIs Reference's row for /api/v1/settings/ini/{name} says that in 6.3.3 the server reads the value at its next start or POST /api/v1/server/reinitialize, and that since 6.3.4 PUT and DELETE publish the change, so that a key marked to apply now is in effect when they answer and one marked to wait answers pending true until a reinitialise or a restart takes it, as the route's OpenAPI text says, where it said that either way the server reads the value at its next start or a reinitialise; and it says that the OpenAPI text for the route has described the database as the store since 6.3.4, and that it says, without the condition that the service may write the file, that the file's copy is written and an edited line put back, where it said that the text still described the file as the store. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Six more passages of this wiki's own text, on four pages, say of a [Settings] line edited in hMailServer.ini, and of a setting saved or removed over REST, what ServiceAccount.md's table of the writes to hMailServer.INI says with batch51 on master, 5e49abf06, and IniSettingStore does: the line is put back, written back or taken out only where the service may write the file, and under NT SERVICE\hMailServer, to which the file is read-only, an edit stays in the file and is not used, a save writes the row alone and a removal of a key whose line is still in the file keeps the row holding the key's default, which the server treats the same, where they said so without the condition 8d8ed94 gave the passages around them. The Upgrading Guide's bullet Not hMailServer.ini under What the upgrade touches, this wiki's own text and not Upgrading.md's, says that an edit to the section is not used at the next start (HM5804), its line put back where the service may write the file and left as edited under NT SERVICE\hMailServer, where it said that the edit was undone, and the page's header names the bullet among this wiki's own additions and says so. Changes Since 6.2.10's note on the settings store finished at the edges says that an edit to the file is not used at the next start, and item 20 of its section 5 is headed that an edit to [Settings] is not used, where both said that the edit was undone; and its 6.3.4 entry on the settings store says that a removal takes out the line and then the row where the service may write the file, and where it may not and the file has the line keeps the row at the key's default, or refuses the removal of PasswordPepper and of a key this build does not read (IniSettingStore::RemoveSetting), where it said that the removal took out the line and the row. The APIs Reference's row for /api/v1/settings/ini/{name} says that PUT brings the file's copy into line where the service may write the file, the row alone under NT SERVICE\hMailServer, a write of the file that fails being HM5806; that DELETE removes the line and then the row where the service may write the file, the line staying and the row kept holding the key's default where it may not, and that there it is a 500 for PasswordPepper and for a key this build does not read, the reason in the error log as HM5806; that a line deleted by hand is written back where the service may write the file, the row kept either way; and that a PUT of PasswordPepper is a 500 where the service may not write the file, the reason in the error log as HM5806, as cb4f10c has Changes Since 6.2.10 and Settings Reference say of the pepper; where it said that PUT brings the copy into line, that a file that cannot be written is HM5806, that DELETE removes the line and then the row, and that the pepper is written to the file, whatever the account. The REST API's row for the ini routes says the same of PUT and DELETE, naming the Linux packages' hmailserver user beside NT SERVICE\hMailServer, where it said that both bring the file's copy into line and that a line deleted by hand is written back. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Nineteen of this wiki's own pages say of a [Settings] line edited in hMailServer.ini what RelocatingAnInstallation.md says with batch51 on master, 5e49abf06, and ServiceAccount.md has said since the tag v6.3.4: at the next start the stored value is used and HM5804 names the key, once, and the line is put back where the service may write the file, while under NT SERVICE\hMailServer, to which the file is read-only, as under the Linux packages' hmailserver user, the edit stays in the file (IniSettingStore::Synchronize), where they said without that condition that the line is put back, undone or restored: the APIs Reference, Backup and Restore, Capabilities and Configuration, Changes Since 6.2.10 (its 6.3.4 entry on the settings store and item 20 of its section 5), Control Panel Pages, Encryption and Certificates, the Glossary, Installing hMailServer's table of what writes each key, Monitoring and Health, Ports Reference, Routes and Relays, the Runbooks Digest, Security Hardening, Settings Overview, Settings Reference, The Control Panel, The REST API, Troubleshooting and Upgrading hMailServer. Where the same passages said that the server keeps the file's copy current, writes a deleted line back, brings an older line up to date or rewrites the line after a save, they now say so of a file the service may write, as step 9 of RelocatingAnInstallation.md now says of a save (IniSettingStore::WriteSetting) and ServiceAccount.md's table of the writes to hMailServer.INI says of every start, reinitialise and save: Settings Overview's flowchart has a step for a file the service may not write, where nothing is written, an edit is still named once and a reinitialise names the older lines in the application log where application logging is on; Settings Reference's section 4a says the same of each of its rules, and its rows for HM5803 and HM5804 say that a file the service may not write is not written at all, which the application log says, not as an error, and that HM5804 is said once there because the row records the edited line; and Upgrading hMailServer's note on rolling back from 6.3.4 to 6.3.3 says that the file's permissions under NT SERVICE\hMailServer, like a Linux package installation's unit, keep the server from writing the copy that note relies on. Where Changes Since 6.2.10, Control Panel Pages, the Control Panel Reference, Settings Overview and The Control Panel said that a Control Panel with no connection refuses rather than write a line or a file the server would undo, they say one whose edit the server would not use. The copies of documents that still say it without the condition - Contributing, Diagnosing Stalled Mail, Event Scripts, Migrating the Database Backend, The Update Feed and Warm Standby - follow their documents and are left as they are. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Monitoring and Health, Backup and Restore, Settings Overview, The REST API and The COM API and Scripting describe the screenshots retaken from 6.3.7, read from each image and from the Control Panel at master, where they described the 6.2.10-era captures: Server status opens with its Configuration checks card, once Warnings at the foot, and the count of auto-ban ranges is under Banned now in its Statistics card rather than among the warnings; the State column of the delivery queue - Delivering now, Due for delivery or Next try in ... - holds what NextTry did, beside Trace message and Deliver all now; API & monitoring is Monitoring & alerts, with the REST API, Metrics, Alerts & webhooks, SNMP and Shutdown tabs, ManageSieve being on Protocols and the Windows event log on Logging, and its settings are stored in the database under their INI names, where the text offered hMailServer.INI; Diagnostics has the Hosted domain and Remote domain boxes, Copy results and the Message-store consistency card; Backup & restore is Backup, restore & migration, the shot showing all six backup options with domains and messages unticked; Server limits & expert settings opens on its Timeouts and queue bounds card; the ACME page is Automatic certificates (ACME), shown switched off and empty as on a fresh installation; Event scripts has Check syntax, Reload from disk, Save & reload and the Insert template... list; and the audit trail is under Compliance. The Logging page keeps its earlier capture and its caption. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Every page's header says whether 6.3.7 is reflected in it, and none calls 6.3.6 the latest release, where thirty-seven headers still said "6.3.6, the latest release (6 October 2026...". The guide and reference pages brought up on 5 October 2026 to 6.3.6 say so with its date and schema, and that 6.3.7, the latest release (17 October 2026, schema 6108), is not yet reflected on them: Aliases, Lists and Public Folders, the APIs Reference, Compliance and eDiscovery, Connecting a Mail Client, Control Panel Pages, the Control Panel Reference, DNS for Your Domain, Encryption and Certificates, Encryption for People, How Email Works, Mail In to a Webhook, Mailing Lists, Message Storage, Migration, Monitoring and Health, Outbound Shaping, the Ports Reference, Profiles and Environment, Rooms and Equipment, Routes and Relays, Rules and Sieve, the Runbooks Digest, Security Hardening, Settings Overview, Sign-in and Identity, Stopping Spam, Stopping Viruses, The Control Deck, The Control Panel, The REST API, The Webmail, Troubleshooting, What hMailServer Is and Is Not and Your First Domain and Mailbox. Backup and Restore says that 6.3.7 is reflected only in the release a failed full restore is made again on, Capabilities and Configuration only in the releases the release jobs have made, and the Settings Reference that its keys were last re-checked at v6.3.6, where its re-check of 5 October 2026 called v6.3.6 the latest release. The COM API and Scripting and the Glossary, whose headers said nothing of a release after 6.3.4, say that 6.3.7 is not yet reflected, the Glossary that its stamp names it; Version History to 6.2.10 that its history ends at 6.2.10 and what came after, up to 6.3.7, is in Changes Since 6.2.10; and the Project Handbook that its status note, and what sections 7, 8, 9 and 11 say of how a change lands, who can approve it, which runners run what and which releases the release jobs have made, are brought up to the tree at 6.3.7, the rest not yet, and that 6.3.7, published on 17 October 2026, was the first of the security releases that go on until 30 September 2027. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

The reference pages carry what 6.3.6 adds and changes: the live update's trust read from hMailServer.ini alone, the never-ban list by reverse name, each SMTP listener's AUTH, the FQDN checks, the SURBL score, the sessions' bounds, the folders made private, and the COM members, routes, states and figures that go with them. APIs Reference: days to keep with one meaning and the 409 for a page left open; Utilities' helpers answering a signed-in caller; the members added in 6.3.6 with their dispids; UpdateState 6 and 7 and GET /api/v1/update's new fields; the never-ban routes; smtp_authentication on /api/v1/ports; the three anti-spam keys and auto_ban_widen_by_reverse_name; the breach-check test, the audit put-back and the trust keys refused on /settings/ini; the invitation reply's occurrences; the administrator password's delay, the Host the loopback port answers, the IPv6 /64, fifty sessions a holder, API keys' source restrictions, the audit trail's new records. The REST API: the same on its own tables. Settings Reference: the five trust keys file-only, the UpdateSourceRepository row, the four hm_settings rows 6.3.6 adds with hm_neverbannames and portsmtpauth, HelpWikiBaseUrl at the group's path, the [Settings] baseline unchanged, DNSServer and the IP forms refused, DnssecValidationEnabled's IPv6 servers, DaneEnforcementEnabled's resolver, AutoBanCommand's ledger, AutoBanNeverBan's older forms, HttpProxy's callers, the XOAUTH2 token request through it, the Updates folder left out of backups, HM4401. Settings Overview: the five cannot be set over COM, REST, the Control Panel or the Deck. Control Panel Reference: the external account's wording, the update settings shown and not edited, the status card's states 6 and 7 and Install update under NT SERVICE\hMailServer, the thirteenth checklist item, the search phrase, the live logs' message, the Deck's script policy. The Control Panel and The Control Deck: thirteen items, the live logs' message, the Deck's 6.3.6 behaviour. Capabilities and Configuration: the version and schema stamps, the trust keys, the update states, HttpProxy's callers, the never-ban names and the widening, OpenSSL 4.0.3, libpq 18.6, QuickJS 2026-06-04. Ports Reference: portsmtpauth, each listener's AUTH, ManageSieve's deadlines, the bind addresses in older forms, SO_EXCLUSIVEADDRUSE, the forward proxy's callers. The COM API and Scripting: Send a message from a script through Application.CreateMessage, OnExternalAccountDownload's answers for IMAP, QuickJS 2026-06-04 and ES2025, scripting off, the Service Desk address at the group's path. Project Handbook: the libraries and the address. Runbooks Digest: days to keep -1. Architecture: HttpsClient's callers, and the flowchart of an error report that no longer recurses on a missing UseScriptServer. Troubleshooting: the by-hand install and Install update, HM7465 to HM7469 and HM5480, port 25's Honeypot, a disk that fills as a message's last bytes are written. Each page's header says it was brought up on 5 October 2026 to 6.3.6 for what 6.3.6 changes on it; where 6.3.5 changed the page too (the sidebar's order, the quarantine review, its fields and members), the header says that is not yet written in. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 5, 2026

Every link to the project points at its address in the group, gitlab.com/hmailserver/hmailserver, where it has been since 29 September 2026; the identities 6.3.5 was signed with, and the setting row that lists both paths, keep the path the project began at. The project's path in all 63 pages that linked it (548 links), 6.3.6 being the first release made at the group's path. Left as they were: the seven signing identities https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v... (Release Process, Security Policy, The Update Feed, and the UpdateSigningIdentity row of Settings Reference), which name what 6.3.5 was signed as; and the UpdateSourceRepository row of Settings Reference, which lists both paths on purpose. The container registry's name is corrected with the container page. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 5, 2026

The wiki is brought up to the published release: 6.3.4 is the signed tag v6.3.4 at 51e2dbda0, published on GitLab on 27 September 2026 (02:37:56 UTC), not 8adce850a of 26 September, where the tag was first made and whose release gate failed. Every page that named 8adce850a as the tag or the release names 51e2dbda0, and every page that dated the release 26 September dates it 27 September: the footer, the sidebar, the page headers, the landing page's Current release, the release timeline's row and picture, section 4e's heading. Each fact those pages took from 8adce850a was checked at 51e2dbda0: the commits between the two change 42 files, whose only documents are CHANGELOG.md, BrandLogos.md, OpenPGP.md and SecretsAtRest.md, none of which a page copies, and which include none of Constants.h, Version.h, formMain.cs, the create scripts, IniFileSettings.cpp, SettingsDefaults.h, the IDL, the Control Panel or .gitlab/allowed_signers, so every file and line cited at the tag holds. Where a page said it read the tag on 26 September, it says it read 8adce850a and that what it read is the same at the tag. The suite has 3,811 [Test] attributes at the tag, not 3,809 (the fixes add two tests); twelve places say so. Changes Since 6.2.10 gains, in batch 40, what the release gate found and the eleven fixes: three change tests alone; of the other eight, three fix what 6.3.3 did too - a relay that refused the OAuth2 login got the server's token into the bounce and the logs (open since 6.2.22-pre1), a rule's forward, copy, reply or notice and an account's forwarding could wait a minute in the queue, and IMAP LIST and LSUB took a literal's length for the pattern - and five fix code new in 6.3.4 (sealed mail and an unnamed part, a closed key's FETCH refusal logged as a critical error, the help desk's password reset read as bytes, the logo and key-directory holds, an alert's encoded Subject over 76 characters). The gate table and the timeline give the re-run on 51e2dbda0 as the logs have it: 2,349 on the first bench (2,252 passed, 0 failed, 97 skipped) and 1,462 on the second (1,446 passed, 0 failed, 16 skipped), the 71 live-update tests elevated, all passed, and the Linux suite on the packaged binary, 2,013 tests, 1,562 passed, 0 failed, 451 skipped (results/b40full3 on linix); the database upgrade gates, the security scans, the fuzzers and the installer smoke test, 65 of 65. The JScript flaw is CVE-2026-100741 (CVSS 3.1 9.8), and the project's issue #43 is public: Security Hardening 17.11, the scripting page, the changes, the capabilities and the API reference name them. The project's download links work (the site has served HTTPS since 26 September; on 27 September they led to 6.3.4's files), so Installing on Linux and Running in a Container no longer say they work once it does. The copies of SECURITY.md and CONTRIBUTING.md give the day GitLab published the release, and the security policy's copy counts the 455 findings .gitlab/security-exceptions.yml accepts at the tag - the 169 of the SAST triage and the 286 that held the release scan - where the repository document still says 169; each header says where the copy differs. Three places said no pipeline had run on the fixed tree; one has, the schedule of 27 September 2026 on master 6bc09509d, which ran the update feed's pages and package-repos jobs alone, and they say so.

Christopher Holloway committed Sep 27, 2026

The wiki is brought up to the release itself, the signed tag v6.3.4 at 8adce850a: what it said of 6.3.4 had been read from master 92b8f9f63, which the tag's last batch, batch40, follows. Schema 6104, not 6103: 6.3.4 is sixty-four steps from 6.3.3's 6040, the last, 6103 to 6104, adding hm_fetchaccounts.faorigin (Constants.h:1224, formMain.cs:314 and the three create scripts at the tag); every header, table, count and diagram that gave 6103 as 6.3.4's schema says 6104, the upgrade table's step counts are each one more, the step tables gain the 6104 row, and where 6103 means the secrets-at-rest step it stays. No page calls 92b8f9f63 the release or the tree 6.3.4 was cut from any more: a page checked against it says so and that the tag adds a last batch, and a page that copies a repository document the tag leaves as it was says the document is the same at the tag. The copies of repository documents batch40 changes are brought up to the tag, hunk by hunk from the version each copy had reached, their own additions kept: Security Policy (the SSH-signed sums of a release made by hand and the two commands that check a download, an SBOM for every compiled file, a release held by its security scans, secrets refused before they are pushed; its note no longer says the document calls 6.3.3 the latest), Release Process (A release made by hand, the security gate, the SBOM jobs), Upgrading Guide (the installer's HM_ADMIN_PASSWORD, the named lock on MySQL and MariaDB, the probe that stops an upgrade on too old a server at 6041 and the repair of a half-done one), Contributing, Governance (rebuilt on the tag's document, which gives the GitLab roles the owner set on 26 September 2026; the map and the note on code-signing material kept), Assurance Case, Regulatory Scope, Third-Party Binaries, Fuzzing, Migrating the Database Backend and Regression Test Environment. The installer's password handling as the tag has it: the password page is skipped for HM_ADMIN_PASSWORD as for /adminpassword, the database step hands the password (or the live update's token, as token:<hex>) to DBSetupQuick and DBSetup in HM_ADMIN_PASSWORD and DBSetupQuick to DBUpdater the same way, never on a command line, the switch table has the variable, and the unattended upgrade takes either (Installing hMailServer, Upgrading hMailServer 18.4a). How to verify a download: 6.3.4's hmailserver-6.3.4-SHA256SUMS.txt and its .sig, checked with ssh-keygen -Y verify against .gitlab/allowed_signers and sha256sum -c, as SECURITY.md at the tag gives them, and each installer's and package's own SBOM (Installing hMailServer 4.1, Installing on Linux, Upgrading hMailServer 18.4 and 18.4c, home, Release Process, Project Handbook, Troubleshooting, Glossary, Assurance Case, Regulatory Scope). The /download/ links no longer wait on issue #30: the feed's site has had its certificate since 26 September 2026. Changes Since 6.2.10 gains batch 40 in section 4e (the audit before the release, GitLab's SAST and the release gate, the installer's password, the SBOMs and signed sums, the stable download links, the release chain and landing through merge requests, what the first pipeline found, Windows on ARM compiled), items 47 to 51 in section 5 (reserved domain names, a one-time code taken once, the outbound relay's OAuth2 token over TLS only, the fetchers and schema 6104, a pre-6.3.4 hash of a password above U+00FF refused), SQLOLEDB in item 38, the 6041 probe in item 36, and the installer's own PBKDF2 in item 39. Also what the tag makes false elsewhere: the suite has 3,809 [Test] attributes, not 3,698; hmailserver/docs holds 105 documents; Windows on ARM compiles and has never run, where it was "not built"; IMAP offers STARTTLS only before sign-in and TLS and COMPRESS=DEFLATE only after sign-in (Capabilities and Configuration); a parent-domain passkey relying party needs passkey_allowed_origins (Sign-in and Identity); the Settings Reference counts 193 hm_settings rows with PasskeyAllowedOrigins and WebPushLoopbackHttpForTests; and the Linux suite's CI job first ran in the pipeline of 26 September 2026 rather than never.

Christopher Holloway committed Sep 26, 2026

The wiki is brought up to the tree batch40 will contain: the branches ns-verifier, gl-project, gov, ci-hyg and tf, read from the repository on 26 September 2026. The copies of repository documents take the changes batch40 makes to them - CONTRIBUTING, SECURITY, RELEASE, GOVERNANCE, ASSURANCE-CASE, Fuzzing, RegulatoryScope, ThirdPartyBinaries and RegressionEnvironment - each header saying so. The seven links into /-/blob/master/.github/ point at .gitlab/allowed_signers, .gitlab/hmailserver.openvex.json, or name the GitHub workflow as being in the git history at v6.3.3, since .github/ is gone from the tree; the verify-tag commands read .gitlab/allowed_signers. What the sweep made false is put right: the PKGBUILD builds from the tag on GitLab; the Compose file and the chart name registry.gitlab.com/progressiverobot/hmailserver, a registry that is switched on and holds no image yet; OpenSSL's release archive comes from Debian's archive against its pinned hash; linuxdeploy is no longer downloaded; the build-inputs-1 files come from the package registry; the manifests name the installer's file there. The live update's third signer, the group hmailserver the project is to move to, with the project's id required, is on the update and security pages, the Settings Reference and the changes for 6.3.4, with the three GitLab settings that keep a server to the present path. Governance names Zain Ul Abidin as zainulabidin1990 on GitLab and gives the owner's rule that release tags are created by the Progressiverobot account alone. The /download/ links at updates.progressiverobot.com are given beside the permalinks, labelled as working once that site serves HTTPS (issue #30; it still failed at 05:16). Contributing gains a section of its own on the issue and merge-request templates, the Service Desk, the two boards and the labels as they are on GitLab.

Christopher Holloway committed Sep 26, 2026

The reference pages, the figures and the release notes now describe 6.3.4, the latest release, published on 26 September 2026 at schema 6103, read from 92b8f9f63, the tree it was cut from. What the pages called the tree after 6.3.3, not yet released, is in 6.3.4 and is labelled so, and what landed after master 540347500 is added as 6.3.4's. Changes Since 6.2.10 gains 6.3.4 as a release: its row in the timeline and the picture, its gate size (3,698 tests), the seven schema steps 6097 to 6103 with what each script does, the four steps that deserve planning (6101 on hm_messages and 6102, which rebuilds every MySQL and MariaDB table, beside 6025 and 6030), the upgrading note, section 4e retitled as New in 6.3.4 with a new part for batches 34 to 39 - eDiscovery, storage compression and de-duplication, mailbox encryption at rest, mail in to a webhook, rooms and equipment, utf8mb4, secrets at rest, the JScript escaping fix, event scripts on Linux in QuickJS, PST import and its reader process, SNMP, secure defaults and the service account, database TLS, object storage, the update feed off GitHub and the Updates folders, address erasure, the scan fixes and 7-Zip 26.03, the IMAP fixes, the webmail at 100,000 messages, the load generator, Windows on ARM and the CI on the project's own runners, each with its schema step, its commits and its repository document - and eleven more behaviour changes without a switch (items 36 to 46). Windows on ARM, the published numbers and the webmail's timings are said to be written, empty and unmeasured, as they are. The landing page and the footer stamp 6.3.4 as the latest release; the figures are recounted from 92b8f9f63: 65 Control Panel pages, 441 OpenAPI paths and 621 operations, 40 Deck views and DeckParity.md's 458 of 466, 3,698 [Test] attributes. The download line says 6.3.4 has x86-64 packages only and points the AArch64 packages and the AppImage at 6.3.3's release, and the PKGBUILD's GitHub source is named for what it is. The APIs Reference and The REST API gain the 24 paths added after 540347500 (nine for eDiscovery, seven for the inbound webhooks, four for mailbox encryption at rest, the booking policy, the store's two and the webmail's bulk action) and the routes that answer differently; The COM API and Scripting gains Settings.MessageStoreCompression, MessageStoreDedupMinKB, MessageStoreStatus and Account.Kind, what a COM change to a shared configuration object now does (a copy, in effect at Save(), commit 15cfff25d), the JScript escaping fix of 5a3de9001 and what an administrator with a JScript EventHandlers.js must do (a rule's Run function name a plain identifier), and event scripts on Linux in JavaScript, with what a handler cannot reach. Settings Overview and Settings Reference gain the 27 hm_settings rows of 6.3.4 (191 in all), [Database] TlsMode and TlsCaFile, [Security] StoredSecretsKey and the sealed secrets, and ServiceAccountName no longer used by /Register. Ports Reference gains the SNMP agent, the secure defaults a new installation's listeners get, and the outbound connections 6.3.4 adds. Upgrading hMailServer gains 18.4c: every server installs 6.3.4 by hand, since it carries no Sigstore bundle; the UpdateFeedUrl line for 6.2.28 to 6.3.3; the slow steps and what 6102 needs; what an upgrade keeps. Capabilities and Configuration, the Glossary (eDiscovery and legal hold, object store, sealed secret, stored-secrets key and the rest) and the Runbooks Digest (the nineteen new documents) are brought up to the same tree.

Christopher Holloway committed Sep 26, 2026

What the adversarial check of the wiki's catch-up found, put right. The REST API's route counts left out the settings groups: RestApiSettings.cpp writes /api/v1/settings and its named groups into the OpenAPI document from its group tables, so no path literal shows them, and the document names 146 paths and 219 operations in 6.3.3 and 417 and 588 at master 540347500, not the 137 and 202 and 404 and 563 the literals alone give; the landing page, The REST API, the APIs Reference and Capabilities and Configuration now say so. The landing page counted 53 pages and listed none of the eight new ones: it counts 61, lists all eight where the sidebar has them, says fifteen pages carry a Source of truth note rather than eight, and names the eight among the guides. A documentation error was said to become an issue with the documentation label, which neither the Default template nor a visitor can set; the sidebar, the footer and the landing page ask for an issue naming the page. Regulatory Scope's table linked Changes Since 6.2.10 as [[Page|Page]], which GitLab splits at the pipe. Capabilities and Configuration placed the 6.3.3 version stamp at 3233b0cc4; it is still 6.3.3 build 42 at 540347500. The Webmail counted Greek, Korean and European Portuguese among what the tree adds, when 6.3.3's twenty already had them; Connecting a Mail Client listed S/MIME in the page as new, which it has been since 6.3.2, where the new thing is a domain's S/MIME authority; Changes Since 6.2.10's collection sweep read 87 calls, six fixed and 84 others, which is three loops and three members; the COM page said every class now carries ISupportErrorInfo, where the checker holds every class that raises an error. And the wiki's own pages stop saying that GitHub's CI runs: Encryption for People's GnuPG proof, the Linux builds on the ARM runner and with both compilers, the translation-unit census, the Compose file and the chart, the settings-index generator, the ini-coverage checker, the account-stores checker and the C++ CodeQL job ran there until 18 September 2026 and are run by hand, or not at all, since. The APIs Reference's server states gain 5, Draining.

Christopher Holloway committed Sep 24, 2026

The reference pages that name GitHub because the code still does now say, beside each such fact, that GitHub is unavailable and that moving it off GitHub is planned roadmap work, not yet done. The update check's default feed is api.github.com and has answered 404 since 18 September 2026 (Settings Reference, Settings Overview, The REST API, APIs Reference); the three signing-trust defaults name GitHub's release workflow and token service, which only GitHub Actions can issue, so no release after 6.3.3 can carry that identity (Settings Reference, Settings Overview, the Glossary's Sigstore row); and the Policy URL compiled into the served security.txt is a GitHub address (APIs Reference). Each was checked against master 540347500: UpdateChecker.cpp's STABLE_FEED and PRERELEASE_FEED, SigstoreVerifier.cpp's three constants and WebServicesServer.cpp's policy URL are still GitHub's. The Glossary's CodeQL row is put in the past tense and says nothing runs it on GitLab yet.

Christopher Holloway committed Sep 24, 2026

The REST API page's route map stopped at the remote-domain policies, the reports, the audit trail and the alerts of 15 September. It now has a row for every family the OpenAPI document names at master 540347500 - the webmail's calendars, contacts, directory, other accounts, masked and send-as addresses, recovery, OpenPGP, protected messages, zero-access, devices and push; the sign-in, reset and reading pages; the setup checklist, drain, pending settings, environment, levels and profiles; roles, the message trace and every list; DKIM rotation, bounces, complaints, spam traps and reputation; the reports received and the S/MIME authority; webhooks, review, shaping, sandbox, warm-up, migrations and mailbox restore; the send API and SCIM - and the 6.3.3 families it had left out, each labelled 6.3.3 or in the tree after 6.3.3, not yet released. The route count is 404 paths and 563 operations there. The credentials section says where the three credentials overlap in the tree after 6.3.3: an account holding an administrator role reaches the administrative routes its role allows, a key may name a sender and is the only credential of the send API and of SCIM, and a recovery code is taken where an authenticator's code is. The browser-session section gains the four other ways a session is minted - a passkey, OpenID Connect, SAML and the second account's bearer token - and the password reset; the live update gains the drain before it stops the service, the apply on Linux, and the 404 the default feed has answered since 18 September; and the 401 row and one troubleshooting row follow.

Christopher Holloway committed Sep 24, 2026

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 committed Sep 15, 2026

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 committed Sep 15, 2026

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 committed Sep 15, 2026

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 committed Sep 10, 2026

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 committed Sep 9, 2026

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 committed Sep 9, 2026

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 committed Sep 9, 2026

The wiki rewritten in depth: 141 diagrams drawn from the code, every reference page made exhaustive, and twenty-one defaults corrected that no page had ever stated The wiki was accurate after this morning's sweep and thin. This is the depth pass the owner asked for: every page read against the code again, every reference page completed, and a diagram wherever a diagram says it better than a paragraph. 141 Mermaid diagrams across 49 pages, each drawn from the handler rather than from memory: the SMTP submission sequence with the checks in the order ProtocolMAIL_ and ProtocolRCPT_ actually run them, the IMAP session state machine from the per-command authentication guards, the DMARC evaluation, the delivery pipeline and its retry arithmetic, the ACME renewal state machine, the spam decision from connection to delivery, the schema chain, the component and threading models of the whole server, the CI workflows and what each one gates, the release draft-sign-publish flow, and a map of the journeys through the wiki itself on the landing page. The reference pages are now exhaustive rather than representative: every route with its method, authentication, request and response shape and its error codes; every [Settings] key with its default, its effect and whether it needs a restart; every port with the key that opens it; every rule criterion and action; every Sieve extension the server advertises; every metric the listener exposes. Twenty-one facts were wrong or absent, and each is corrected against the code rather than adjusted. The ones that will save somebody an afternoon: IMAP SASL PLAIN and SCRAM are not advertised on a default install, which looks exactly like a client bug; SMTP AUTH PLAIN is off by default too; DMARC checking is on while SPF and DKIM as scored tests are off, and the DMARC test evaluates both itself regardless; the seeded DNSBL and SURBL servers are inactive; a new mailbox contains INBOX and nothing else, which is the real cause of the classic missing Sent folder; MTA-STS hosting and autoconfiguration default on while both web-service ports default to 0, so the shipped default is features on with nothing listening; and TLS-RPT and DMARC report sending are inert until their From address is set, with each completed day discarded unsent. Eleven screenshots are named as wanted, with what each should show. The existing images are from a 6.2.10-era build and the pages say so where it matters.

chrisholloway5 committed Sep 8, 2026

Every page read against the tree on 8 September 2026: the release and schema stamps (6.2.27, schema 6031, 2,124 tests), the routes, keys and pages that were missing, the listener paragraphs that were false, and the unreleased work labelled as such An audit of all 51 pages against master produced about 360 findings on 43 of them, applied here. The largest: the APIs reference lacked 47 routes and described the listeners as single-threaded HTTP/1.0 (they run on the Boost.Asio HTTP/1.1 server); the settings reference lacked the fourteen Update* keys and IMAPCompressionEnabled and counted 195 keys instead of 236; every "current release" stamp said 6.2.24; Changes Since 6.2.10 ended three releases and one schema step early; Architecture said the optional listeners were deliberately not Boost.Asio and built their own SSL contexts (neither is true); the upgrading pages still warned of a silent-upgrade hang fixed in 6.2.23; the Control Panel pages knew nothing of the seventeen languages, the Updates card or the stalled-mail page; and two pages did not render (a header inside a code block, CR and TAB bytes in file names). Anything in the tree but not in v6.2.27 - the live update, the self-service portal and /api/v1/me, the HttpServer listeners, IMAP COMPRESS=DEFLATE, the seventeen-language Control Panel, the Control Deck views - is documented and marked "in the tree after 6.2.27, not yet released". The Control Panel screenshots are still from a 6.2.10 build and the pages now say so.

chrisholloway5 committed Sep 8, 2026

The hMailServer 6.2.24 wiki: the corrected manual, the runbooks, and the references generated from the code

chrisholloway5 committed Sep 4, 2026