Skip to content

History / Backup and Restore

Revisions

  • 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
  • Six captions of the screenshots retaken from 6.3.7 say where a shot shows the capture server's own values rather than a fresh installation's: Settings Overview's ACME page has the switch off and the contact address and host-name boxes empty as on a fresh installation, while its directory URL box is empty only on that server (a fresh installation fills it with Let's Encrypt's, as the block above it shows) and its port reads 80, where the caption had every box empty "as on a fresh installation"; Stopping Viruses' Blocked attachments page counts the server's own patterns in its pill (a fresh installation seeds fourteen); Security Hardening's Auto-ban card has "Enable auto-ban" unticked on that server, where a fresh installation has it on, as the sentence above says; Monitoring and Health quotes the Diagnostics page's subtitle as the first of its two sentences and says what the second is about; Backup and Restore's caption has the Encryption section begin at the foot of the frame, as the alt text above says, with the buttons, the Scheduled backups card and its Retention section, and the Restore card below it; and Control Panel Pages' Advanced page names the wiki address that server carries as the project's first path and the one a fresh installation has. The check of the refresh found these on 19 October 2026; the shots are retaken on a fresh installation later, with the two left for the Control Panel's fixes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 19, 2026
  • Home, Ports Reference, Monitoring and Health, Backup and Restore and Encryption and Certificates say what the 6.3.7 Control Panel shows where the text around the retaken screenshots still described the older pages, read from the images and from the Control Panel at master: the Welcome page's alt text counts thirteen task rows, as WelcomeIntents lists them and The Control Panel says, where it said twelve; Ports Reference's table of symptoms sends a reader whose listener never accepted a connection to the Listening column of Connections & protocols, TCP/IP ports, where it sent them to a listener list on Server status, which has none, and its table of outbound connections puts the smart host on the Smart host tab of Delivery of e-mail, in the Server-wide smart host card, where it named an SMTP relayer (smart host) card; Monitoring and Health's table of pages gives Server status its Configuration checks card first, the servers' last start and running time, the database, the counts since the service started, the sessions connected now and the auto-ban ranges in force, and the line with Open Updates that says a newer release is waiting, where it listed five statistics, the update check's verdict and a Warnings list, and gives the delivery queue its State column - delivering now, due, or the next try - and the buttons View source, Trace message, Remove, Deliver all now, Deliver now and Refresh, where it listed a next try time, a file column and four buttons; Backup and Restore says that since 6.3.4 a save applies the message-metadata-only switch, and every key of its schedule and verification table, at once, as the Applies on save under each box says, and that a schedule saved on a server that started without one is registered by the save, where it said that each applied after a service restart, which was so up to 6.3.3; and Encryption and Certificates quotes the TLS versions & ciphers page's subtitle whole and says that its last words point to Auto-ban, where the alt text quoted its first sentence alone and the caption said that the subtitle put Auto-ban under Sign-in & access. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 19, 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
  • Backup and Restore, the Settings Reference, Capabilities and Configuration and the Project Handbook say what is true with 6.3.7 out, where they named 6.3.6 as the release to upgrade to, 6.3.4 as the current release, the release jobs as written and not yet run, and GitLab's shared runners as where the checkers run. Backup and Restore: a full restore that failed on an installation made new with 6.3.4 or 6.3.5 is made again from the same archive after an upgrade to 6.3.6 or a later release, where it said to 6.3.6. The Settings Reference: the database is the store of the [Settings] keys from 6.3.4, and in 6.3.7, the current release, where it called 6.3.4 the current release. Capabilities and Configuration: the release jobs for 6.3.5 onwards were written and not yet run when 6.3.4 was made, and have made every release since - 6.3.5 on 29 September 2026, 6.3.6 on 6 October 2026 and 6.3.7 on 17 October 2026 - where it called them not yet run. The Project Handbook, section 8: the checkers run on the project's own runners for master, a batch* branch and a v* tag and on GitLab's hosted runners for a merge request and any other branch, as CONTRIBUTING.md at v6.3.7 says under What GitLab CI runs, where it said GitLab's shared runners; and the release jobs made 6.3.7 on 17 October 2026 as well as 6.3.5 and 6.3.6. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 18, 2026
  • The guide pages say what 6.3.6 changes in anti-spam, DANE and outbound TLS, backups and restores, calendars, sign-ins, the webmail, Sieve, the store commands and the auto-ban, and every page's header says whether 6.3.6 is reflected in it. Stopping Spam: the SURBL test as 6.3.6 runs it (every registrable domain up to 200, 256 names a list, sixteen lookups at a time, SurblTooManyDomainsScore, a list's error answers never a listing), the Sender MX test by the Public Suffix List, the two FQDN checks, the greylisting key of schema 6107, the sender lists' URL entries. Encryption and Certificates: What DANE actually does for 6.3.6 - DANE-TA, the indeterminate lookups, the validated MX RRset, a resolver that strips DNSSEC, the deferrals where mail bounced, and the log lines as the tag writes them. DNS for Your Domain: the indeterminate rule and the resolver requirement. Routes and Relays: the relayer's STARTTLS required refuses permanently, as it always did; a webhook route held to public addresses through HttpProxy. Mail In to a Webhook: the same. Backup and Restore: the Updates folder and a destination inside the data directory left out, the restore that copies in first and undoes a copy that fails, the full restore that failed on installations made new with 6.3.4 or 6.3.5, this installation's own self-signed pair kept, a message deleted while a backup copies. Rooms and Equipment: the organiser verified by the From address, and the send API believed for nobody. Encryption for People and The Webmail: the S/MIME certificates kept, the HTML view's images, OpenPGP's 32 MB, the attachments' types, the invitation card, days to keep. Connecting a Mail Client: a stored event changed only by a verified sender, the AUTH on port 25 that bans, FETCH's NO [LIMIT]. Sign-in and Identity: the pending sign-ins carried by the browser, sealed. Rules and Sieve: ManageSieve's deadlines and a session that ends. Message Storage: the store commands' link rule. Mailing Lists: every field of a posting removed. Security Hardening: the grant through a junction, who else on the computer may read the mail (/ProtectFolders), AutoBanMinutes for an AUTH on port 25, the checklist's row 12a. Migration: days to keep messages, as the repository's document gives it. Aliases, Lists and Public Folders, Compliance and eDiscovery, Control Panel Pages, Monitoring and Health, Outbound Shaping, Profiles and Environment, Stopping Viruses, What hMailServer Is and Is Not, Your First Domain and Mailbox and How Email Works: the header says that 6.3.5 and 6.3.6 are not yet reflected on the page. 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
  • What the check of the wiki's 6.3.4 pages found: the backup page counted 60 per-account tables in the AccountStores declaration where it names 62 (24 carried and 38 declared exceptions), and called the booking answers and the booking queue the two exceptions added in 6.3.4 when they are the last two, added with rooms and equipment on 25 September 2026. Several pages said GitLab CI's jobs build, compile, lint, scan or run the suites, when ContinuousIntegration.md records that no GitLab job had run yet when it was written on 25 September 2026; the Linux page, the container page, the regression environment's header, the project handbook, the regulatory scope's Annex I table and the security policy's table now say the jobs are written and not yet run. And the installer page said the secure defaults' failure is shown in a message box on the built-in database's branch only, when the installer shows it on both branches and only logs an exit 5 after DBSetup, a database it attached.

    Christopher Holloway committed Sep 26, 2026
  • The operator pages describe 6.3.4, the release of 26 September 2026 at schema 6103, as the installer script, the Linux unit and the repository documents at master 92b8f9f63 have it. What they labelled as in the tree after 6.3.3 and not yet released is labelled as 6.3.4's, and what landed after 540347500 is added where an operator meets it. Installing hMailServer walks the installer as it now runs: the server profile and service account pages, a new installation's service on NT SERVICE\hMailServer granted its folders by /GrantServiceAccess and moved only once that succeeds, the administrator password written as PBKDF2 by the server rather than as MD5 by the installer, the secure defaults (a self-signed certificate, STARTTLS on the four seeded listeners, TLS required for authentication on the Internet range) and the stored-secrets key made for a database the installation created, and an upgrade that keeps its account, listeners and ranges. It says 6.3.4 carries an Authenticode signature and no Sigstore bundle, so no server's live update installs it and every server is upgraded by hand, how to check the signature, and which feed and signers a server trusts. Installing on Linux says 6.3.4 carries the x86-64 .deb and .rpm only and links the AArch64 packages and the AppImages to 6.3.3's release, where the latest-release links would break; it adds the unit's first start securing a new installation, the stored-secrets key, database TLS and --check-database, event scripts in QuickJS, SNMP, and the new server verbs. Running in a Container adds HM_DB_TLS_MODE and HM_DB_TLS_CA, the key the container's --create-database makes and how to export it, and that the secure defaults are applied there only by hand; Before You Install gains the service account, the secure defaults, database TLS, MySQL's utf8mb4 floor and where the exported key is kept. Security Hardening rewrites the least-privilege section for the installer's account and the retired ServiceAccountName, and adds secrets at rest, the JScript escaping fix (every release from 6.0.0 to 6.3.3, what it exposed and what closes it) and the database connection, with checklist rows for each. Monitoring and Health adds the SNMP agent, off and answering nobody until a manager is listed, with no COM property or Control Panel page. Backup and Restore adds the restore that lists an archive and refuses an unsafe one whole (HM7540), 7-Zip 26.03, the stored-secrets key that no backup carries, messages in an object store, and the account stores counted at 6.3.4. Encryption and Certificates adds what a new installation starts with, the database's TLS modes, certificates for IP addresses on Linux and what the server keeps encrypted at rest, mailbox encryption at rest off on every account. Troubleshooting gains the rows an operator of 6.3.4 will meet: the sign-in refused before STARTTLS, the self-signed certificate, the unverifiable 6.3.4 offered to a live update, and HM7460, HM7463, HM7494, HM7495, HM7530, HM7531 and HM7540.

    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 four pages on operating the server are brought up to master 540347500. Monitoring and Health counts 38 metric families and lists the six added since 6.3.3 (country blocking, complaints, spam traps), has eleven alert conditions where it had six - the create scripts seed eleven, one more than the audit counted - gives the audit trail its put-back route and the auditor role's access, says which of the trail's recorded gaps are closed and which remain, corrects the reports (spam, virus and storage are per domain since schema 6062), and adds following one connection live and the new places mail can wait: held for review, held for the sandbox, a shaping back-off, a warm-up ceiling, a drain. Backup and Restore says the account stores are 57 tables, 21 carried and 36 declared exceptions with passkeys and shares among the ones left out, adds the encrypted archive and restoring one mailbox or one message, and says how a zero-access mailbox and a domain's S/MIME authority travel. Troubleshooting explains the update check's 'The update feed answered HTTP 404.' on every release since 6.2.28, the applies marks and a setting the environment manages, and where a message waits in the tree. Upgrading hMailServer has the schema at 6096 and fifty-six steps after 6.3.3 (none touches hm_messages; 6072 scales with the greylisting table), the drain, [Database] UpgradeOnStart and the reported roll-back, and says the update settings apply when saved.

    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 chrisholloway5 committed Sep 15, 2026
  • 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
  • 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 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 chrisholloway5 committed Sep 8, 2026
  • The hMailServer 6.2.24 wiki: the corrected manual, the runbooks, and the references generated from the code

    @chrisholloway5 chrisholloway5 committed Sep 4, 2026