History / Upgrading Guide

The six copies whose documents batch54 changes - the Assurance Case, Contributing, Governance, the Release Process, the Security Policy and the Upgrading Guide - are copied again from the documents as master has them from batch54, 9336fdd59, on master since 24 October 2026, and each header says so and names what changed. The Assurance Case's status note, the Release Process's The copy on GitHub and the opening of the Security Policy's Verifying a release say that GitHub's immutable-releases setting is on, that a release published there with it on keeps its files and its tag as published, though its notes can still be edited, and so do the copies of 6.3.6 and 6.3.7, published after it was switched on during the copying of 18 October 2026 (the Security Policy: at 05:26 and 05:31 UTC), and that the copies of the releases before them, published before it (the Security Policy: 6.0.0-B1 to 6.3.5 and the two build-inputs releases), can still be changed, where they said that a release published after the copies of 18 October 2026 could not be changed and that the copies could; Contributing's row Releases of the table of where things are and Governance's status note say that on GitHub the copies of 6.3.6 and 6.3.7, and every release published after them, are immutable, where they said a release published after that day's copies. The Upgrading Guide's Where you can upgrade from says that the Chocolatey package's log and the file with the refusal's words are in Chocolatey's cache folder, which its CLI makes setup's TEMP, where it said only that the package passes /LOG and shows that file's words when the install fails. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 9336fdd59 has it, where they pointed at 6fb8164c6 or, in the Assurance Case and Governance, at 5e49abf06 and, in the Security Policy, at 72be22b4e, each document being the same at those commits as at 6fb8164c6; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 24, 2026

The four copies whose documents batch53 changes - Contributing, the Release Process, Third-Party Binaries and the Upgrading Guide - are copied again from the documents as master has them from batch53, 6fb8164c6, on master since 22 October 2026, and each header says so and names what changed. Contributing's table of the Python checkers says that check-installer-scripts.py also checks that setup refuses an installation of the original hMailServer's 5.7 first, by bounds the upgrade chain in DBScripts holds, and that the Windows package jobs run that decision's self-test before they build the installer, and it has check-package-texts.py, which holds every package text the tree ships to saying that it is Progressive Robot's fork of hMailServer, the long descriptions and the Chocolatey and winget copyright and authors among them to crediting the original's author, Martin Knafve, and the packages' maintainer to being the project's. The Release Process's step 6 of The release on GitLab says that container-image-start starts the image beside PostgreSQL and beside MariaDB and asks each for SMTP and the REST API, where it said beside PostgreSQL alone, and its note marked Now under step 13, this wiki's own, says that a moderator returned the Chocolatey package of 20 October 2026 on 21 October, asking that its authors also credit Martin Knafve, and that chocolatey-publish sent 6.3.7 again on 22 October 2026, still without that credit, as PackageManagers.md says, where it said that the package of 20 October waited for moderation. Third-Party Binaries names libmariadb3, MariaDB Connector/C, with the mariadb-common and mysql-common it brings, among the packages the container image installs from the archive, from the release after 6.3.7. The Upgrading Guide's Where you can upgrade from says what setup up to 6.3.7 did over an installation of the original's 5.7 - replaced the program files and left a database this server refuses as too old, or, over one that the original's 5.7.0 build 3013 or later made new, set up a new, empty database beside the original's - and that from the release after 6.3.7 the installer refuses one before it changes anything, the installers of 6.3.7 and earlier not looking, so that they must not be run over one, with how setup decides and what the refusal says and where, where it said only that setup ran DBUpdater after it had replaced the program files and not to run this fork's installer over one; the list under If the upgrade fails of what else the installer refuses, this wiki's own, has that refusal as a third point, where it had two. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 6fb8164c6 has it, where they pointed at 72be22b4e or, in Third-Party Binaries, at 5e49abf06; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

The four copies whose documents batch52 changes - Contributing, the Release Process, the Security Policy and the Upgrading Guide - are copied again from the documents as master has them from batch52, 72be22b4e, on master since 21 October 2026, and each header says so and names what changed. Contributing's table of the Python checkers has check-citation.py, which holds CITATION.cff's version and date-released to Version.h's release and its CHANGELOG.md date and the file to saying that this is Progressive Robot's fork, citing the original and claiming no DOI, and says that check-package-manifests.py also checks that every text a user reads in the winget and Chocolatey manifests says the package is Progressive Robot's fork of hMailServer and, with --release-date, that the manifest is dated by the release, where it checked the manifests against their schemas alone. The Release Process's step 7 stamps eighteen files, CITATION.cff among them, where it stamped seventeen, and the drawing The release at a glance, this wiki's own, says eighteen files at step 7, where it said eleven. The Security Policy's sentence on the upgrade chain - it runs from every earlier version of this fork - and the Upgrading Guide's paragraphs on the original hMailServer's databases - the original's up to schema 5708 are on the chain, its published 5.7 builds (5709 to 5711) are not, and a server of the original's 5.7 moves its mail over IMAP - are the documents' on master now, where 22057dd had brought them ahead of master; the two header notes that said so are gone, and the Upgrading Guide's paragraph ends, as the document does, with the pointer to Migration.md's "From the original hMailServer" and the sentence on ForkAndOriginal.md, which says what else differs between the two projects. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 72be22b4e has it, where they pointed at 5e49abf06 or, in the Upgrading Guide, at the tag v6.3.7; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

Upgrading hMailServer, the Upgrading Guide and the Security Policy say that the original hMailServer's 5.7 builds of August and September 2026 are not on this fork's upgrade chain, and two headers of the copies brought to batch51 name the sections their documents changed: the original went on from schema 5708 by steps of its own - 5709, 5710 and 5711 - which the chain from 5708 to 6001 does not have, so DBUpdater stops before it changes anything after setup has replaced the program files, and the server then refuses the database as too old. Upgrading hMailServer's 18.2 says the chain is continuous from every earlier release of this fork and of the original up to 5.6, where it said from every earlier hMailServer release, says after its flowchart what to do with a 5.7 build - set this server up beside it and move the mail over IMAP (Migration) - and its table's row for 5.6 / 5.7 is 5.6's, with rows for the original's 5.7 development builds (up to 5708, upgraded as 5.6 is) and for its 5.7 builds of August and September 2026 (5709 to 5711, not the installer), where a row for the original hMailServer of any version called this fork a drop-in successor. The Upgrading Guide's paragraph on the original's databases and the Security Policy's sentence on the chain are what the next batch's Upgrading.md and SECURITY.md say, ahead of the documents on master, and each header says so. Third-Party Binaries' header names the section What checks it, where it named Deleted on 11 September 2026, and The Update Feed's names What a server built after 6.3.3 checks and its item The GitHub signer is held to the past, where it named Having the live update make that upgrade anyway: the one passage batch51 changed in ThirdPartyBinaries.md and the first of the two in UpdateFeed.md are there. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Six more passages of this wiki's own text, found by comparing each copy with its document as master has it from batch51, 5e49abf06, and by a further pass over the pages, say what changes where the service may not write hMailServer.ini, as ServiceAccount.md's table of the writes to hMailServer.INI says, where they said without that condition what the server writes into the file. The Upgrading Guide's paragraph on rolling back across schema 6042, under Rolling back, says that the file the newer server left is a full copy of the stored settings, which the older server reads as the truth, only where the service may write the file, and not under NT SERVICE\hMailServer or the Linux packages' hmailserver user, where the copy is as the last account that could write it left it, as Upgrading hMailServer's note in 18.6 has said since 8d8ed94; and its note on where the [Settings] values come from on a new machine says that since 6.3.4 the restored values are written into the new file at the first start where the service may write it, not under NT SERVICE\hMailServer, a new installation's account. Neither passage is Upgrading.md's, and the page's header names every passage of this wiki's own a comparison with the document finds, none of them in Upgrading.md at any point of its history, where it named five: the pointer to Upgrading hMailServer after the opening, the section What one run looks like with its flowchart and the exit codes, the bullet Not hMailServer.ini, the section on what a failed step leaves on each backend, the note that An upgrade without a window is new in 6.3.4, the installer's two refusals and the notes on the two numbers HM5011 carries and on HM5010 under If the upgrade fails, the paragraph on rolling back across schema 6042, the notes under Special cases on the [Settings] values on a new machine, on the database password and on an installation from before hMailServer 5, the notes for contributors and the corrections under Verified against the code; and it says which three of them say what a file the service may not write changes. Changes Since 6.2.10's 6.3.4 entry on the settings store says that a line still holding what the server last wrote is brought back into line where the file may be written, as its other clauses say since 8d8ed94. The Runbooks Digest says that on the same machine the line the store writes into the file, where the service may write it, is adopted by the new database at its first start, and that under NT SERVICE\hMailServer, where the store writes no line, BackupMessagesDBOnly is checked on the new database before the restore, as MigratingDatabaseBackend.md says. Settings Reference's section 4a says that the whole [Settings] section stays mirrored into the file where the service may write it, the copy not refreshed and stale for whatever reads the file itself under NT SERVICE\hMailServer, and that restoring an archive that carries a pepper into a file the service may not write says so as HM5805, for an administrator to put the value there with an elevated editor (IniSettingStore::XMLLoad). 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

Four passages of this wiki's own text say what the code and the documents say, where they said otherwise before batch50 and still did after it: Relocating an Installation changes the stored [Settings] paths in step 9, once the moved server is running, or through a [SettingsOverride] section at its first start, where its own route stored them "before step 2, while the old server is still running" and said they took effect at the next start - each stored value is applied at once, but for the listeners' certificate paths and the ACME certificate directory, which wait for a reinitialise, so that route pointed the running old server at a tree not yet copied; the same passage says the two trust files are not among the rows that would come back pointing at the old tree, and that from 6.3.6 the live update's trust is read from the file alone like PasswordPepper, with UpdateTrustRootsFile and UpdateLogPublicKeyFile changed there in step 4, where it called PasswordPepper the one exception; the Regression Test Environment's table names pre-flight check 8, the protocol listeners, for a missing SMTP listener, where it named check 11, the orphan test files (build/preflight-tests.ps1); and Migrating the Database Backend and the Upgrading Guide say that a database password re-entered on another machine is written protected by DBSetup.exe, or as a plain value with PasswordEncryption=0, which the server reads as it is and does not protect again, where they said the server would re-protect a plain value (IniFileSettings reads the password by its PasswordEncryption type, and only the COM Database methods DBSetup uses write a protected one). Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

The wiki's own pages say what the documents say with batch50 on master: Before You Install's table of databases has the login allowed to create the database - every privilege on its name on MySQL and MariaDB, dbcreator on SQL Server, CREATEDB on PostgreSQL - with DBSetup creating the database itself and refusing a name that exists, and its checklist an empty database made beforehand refused, where they asked for an empty database and a user that may create tables (MigratingDatabaseBackend.md, step 3); Installing on Linux that --create-database does over COM on Windows what DBSetup does, CreateExternalDatabase, DBSetupQuick creating only the built-in database, where it named DBSetupQuick; the Runbooks Digest, under its record of 4 September 2026, that since 19 October 2026 the document's step 3 runs DBSetup.exe and that DBSetupQuick creates only the built-in SQL Server Compact database when [Database] names no type, the step as it recorded it having made no usable database; the Upgrading Guide's backends table, this wiki's own, that DBUpdater runs the whole chain in one transaction on SQL Server and on SQL Server Compact, but for a chain on SQL Server Compact from a database older than 6072 that crosses 6107, which a failure from 6107 on leaves at 6106, and that on MySQL and MariaDB each step's DDL commits as it goes and the failed step may leave part of itself, where it had SQL Server Compact commit DDL as it executes and SQL Server transactional for most DDL (Upgrading.md); Monitoring and Health that Installation paths lists every path-shaped [Settings] and [Database] value but [Database] TlsCaFile, where it said every one (RelocatingAnInstallation.md); Security Hardening, The COM API and Scripting and section 5 of Changes since 6.2.10 that the rule action is "Run script function", as the Control Panel's action dialog lists it and EventScripts.md now names it, where they said "Run function", and Rules and Sieve that the mail flow rule action is "Add disclaimer", where it said "Add a disclaimer" (MailFlowRules.md); and the Glossary, Installing hMailServer, Upgrading hMailServer and the Project Handbook that SPDX and CycloneDX SBOMs come with every release from 6.2.3, the five earlier releases that carry an installer having a CycloneDX SBOM of it alone, made afterwards, where they said every release (README.md, SECURITY.md), that the release assets from 6.2.19 to 6.3.3 are signed with Sigstore but for the two SBOMs of 6.2.22-pre3, which carry no bundle, where they said every release from 6.2.19, or every asset up to 6.3.3, and that the releases up to 6.3.3 whose files GitLab has are re-published there byte for byte, 6.2.0 and 6.0.0-B4 being notes-only, where they said every release up to 6.3.3 (RegulatoryScope.md). Changes since 6.2.10's section 4h keeps "Run function" as 6.3.7's notes word it. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

The twelve copies whose document lines still linked to a repository document at master - Architecture, the Assurance Case, Command Line, Contributing, Governance, the High Availability Runbook, Regulatory Scope, Security Policy, Third-Party Binaries, the Upgrading Guide, Warm Standby and Relocating an Installation - link to this wiki's copy of each document they name, and to DkimKeyRotation.md and SettingsApply.md, which it does not copy, as the tag v6.3.7 has them, where forty-six links named master. Each document's own link is relative and resolves at the tag; these forty-six pointed at master, which is the tag only while master stays at 31d656c0c, and had done so since before 5e44fd4, so that the copies from v6.3.7 took a link to a copied document as a wiki link and one at v6.3.6 to v6.3.7, and left these. Forty-three now name the copy: Security Policy (SECURITY.md), Release Process (RELEASE.md), Contributing, Governance, Architecture, Secrets at Rest, the Upgrading Guide (Upgrading.md), The Service Account, the Regression Test Environment, Third-Party Binaries, Fuzzing, Event Scripts and Migrating the Database Backend, with the document's anchor where it gives one (Governance#maintainers, Security-Policy#secrets-and-credentials, Third-Party-Binaries#where-the-build-gets-them, Upgrading-Guide#an-upgrade-without-a-window twice, Migrating-the-Database-Backend#mysql-and-mariadb), and the other three, DkimKeyRotation.md on Warm Standby and Relocating an Installation and SettingsApply.md on Relocating an Installation, are links at v6.3.7. No text but the links changes. Command Line's header and Architecture's, which say that the page's links point at the documents as that tag has them, are now true of every link of the copied text, the Source of truth link aside, which names master on every copy; the links in this wiki's own notes and tables are as they were. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

The twenty-two pages that copy a repository document are copied again from the documents as the tag v6.3.7 (31d656c0c), the release of 17 October 2026, has them, each keeping what this wiki adds of its own, and each header says so and what 6.3.7 changes in it, where the nine brought up on 17 October 2026 named the batch 6.3.7 was to be made from, at the same commit, and said that the rest of the copy was v6.3.6's. Re-copied from the tag: Security Policy (SECURITY.md: its latest release 6.3.7, published on 17 October 2026; "6.3.7 was the exception" under What gets a release, and step 3's pointer to it; Every change and Declaring a finding not exploitable; the release's scans as the second evaluation; the libraries dependency-scan says UNKNOWN for), Release Process (RELEASE.md: the release's notes and their Download table, step 9's gate asked before the tag with master's copy of the exceptions, 6.3.7's paragraph under A security release during the pause), Contributing (CONTRIBUTING.md: the runners each pipeline runs on, the change checks, the eighteen fetched inputs, the new checkers and generated files, the secret scans, sign-off since batch41, step 6 of Merge requests), Governance, Assurance Case, Regression Test Environment (Connector/C 3.4.11's folder; the 7-Zip path the document now writes right), The Service Account (/ProtectFolders hardening the program folder, Bin and ControlPanel, and the steps before upgrading an installation at a drive's root), The Update Feed (the Control Panel's Updates page, the summary past the Download table, the pages job on the project's own runners, where this copy said GitLab's shared runners), Upgrading Guide (the route between backends, the .NET 10 runtime setup leaves as it is), Third-Party Binaries (MariaDB Connector/C 3.4.11 built from MariaDB's source and fetched from build-inputs-2), Database TLS, Diagnosing Stalled Mail (the spam tests' failed lookups and the DNSSEC deferral's reasons), Event Scripts, Fuzzing (UTS 46 against ada), High Availability Runbook (the PROXY protocol behind a load balancer), Secrets at Rest, Secure Defaults, The SNMP Agent, Migrating the Database Backend, Regulatory Scope and Architecture (a transaction is its thread's). Command Line is unchanged at the tag; its header says so and its links point at it. A link to a document the wiki copies is a wiki link; every other link to a repository file that pointed at v6.3.6 points at it as v6.3.7 has it. The headers no longer list as this copy's departures what the tag's documents now say themselves: the day 6.3.6 was published (Security Policy, Contributing), the count of the findings accepted at 6.3.4 (Security Policy), the report of a command run as root on Linux (The Service Account), the route between backends (Upgrading Guide) and the 7-Zip path (Regression Test Environment). Release Process's notes marked Now at steps 9 and 11 say that every release since 6.3.5 has been made by its tag's pipeline, where step 9's said that no pipeline had run on a release tag, and that the installer's inputs are fetched from the build-inputs-1 and build-inputs-2 releases. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

Security Policy, Release Process, the Upgrading Guide, The Service Account and The Update Feed name batch48 at 31d656c0c, its tip now, as the document their paragraphs brought up for 6.3.7 are copied from, where they named 7f685f0df, its tip when they were moved last. batch48 has moved on by two commits since, f4da607b8 and 31d656c0c, which change CHANGELOG.md and the server's code alone (PersistentMessageMetaData.cpp and .h, SQLStatement.cpp and WorkQueue.cpp): SECURITY.md, RELEASE.md, Upgrading.md, ServiceAccount.md and UpdateFeed.md are the same at both. Each paragraph these pages brought up for 6.3.7 is the document's at 31d656c0c, line for line, and each header's commit and its link to the document now name that commit, the batch 6.3.7 is made from. Nothing else on the pages changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

Security Policy, Release Process, the Upgrading Guide, The Service Account and The Update Feed name batch48 at 7f685f0df, its tip now, as the document their paragraphs brought up for 6.3.7 are copied from, where they named 834d7a3b8, its tip when they were copied. batch48 has moved on by two commits since the copies were made, 10fb5b5b4 and 7f685f0df, which change CHANGELOG.md and the server's code alone (WorkQueue.cpp, PersistentMessageMetaData.cpp and .h, ClassTester.cpp): SECURITY.md, RELEASE.md, Upgrading.md, ServiceAccount.md and UpdateFeed.md are the same at both. Each paragraph these pages brought up for 6.3.7 is the document's at 7f685f0df, line for line, and each header's commit and its link to the document now name that commit, the batch 6.3.7 is made from. Nothing else on the pages changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

The Upgrading Guide, The Service Account and The Update Feed say of a server on 6.3.5 or older what the 6.3.7 stamp (c92d3c80e) made their documents say for the time after 6.3.7 is out: it is brought to the newest release, or to 6.3.6 or a later one, where they named 6.3.6 alone. Upgrading Guide (Upgrading.md): a server on 6.3.4 or 6.3.5 under NT SERVICE\hMailServer is brought to the newest release from the release page, once; and, on Windows and on Linux, an update from 6.3.5 or earlier, to 6.3.6 or a later release, is made as before, the rules for an update holding for one from 6.3.6 on, where the copy said that the update to 6.3.6 was made as before and that the rules held from the update after it. The Service Account (ServiceAccount.md, From 6.3.4 and 6.3.5): such a server under the virtual account cannot install 6.3.6 or a later release by its live update. The Update Feed (UpdateFeed.md): it reaches 6.3.6 or a later release by hand, once. Each paragraph is the document's as batch48 (834d7a3b8), the batch 6.3.7 is made from, has it, line for line, with the wiki's own links kept; each header says what was brought up on 17 October 2026, and that the rest of the copy is as it was copied from v6.3.6. The sixth of the stamp's edits that a page here copies, SECURITY.md's, is in Security Policy, in the change before this one. Diagnosing Stalled Mail copies DiagnosingStalledMail.md, whose two edits by the stamp change sentences that came into the document after v6.3.6, the text this copy has; it holds neither, and waits for the copy from v6.3.7 with the rest of the document's changes since. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

The twenty-two pages that copy a repository document are copied again from the documents as the tag v6.3.6, the release, has them, each keeping what this wiki adds of its own. Re-copied from the tag v6.3.6 (e3c448aa6), each header saying so and what 6.3.6 changes in it: The Update Feed (UpdateFeed.md), The Service Account (ServiceAccount.md), Security Policy (SECURITY.md), Release Process (RELEASE.md), Upgrading Guide (Upgrading.md), Secure Defaults (SecureDefaults.md), Third-Party Binaries (ThirdPartyBinaries.md), Contributing (CONTRIBUTING.md), Secrets at Rest (SecretsAtRest.md), Assurance Case (ASSURANCE-CASE.md), Event Scripts (EventScripts.md), Command Line (CommandLine.md), Governance (GOVERNANCE.md), Regression Test Environment (RegressionEnvironment.md), The SNMP Agent (Snmp.md), High Availability Runbook (HighAvailabilityRunbook.md), Regulatory Scope (RegulatoryScope.md) and Fuzzing (Fuzzing.md). Architecture (ARCHITECTURE.md), Database TLS (DatabaseTls.md), Diagnosing Stalled Mail (DiagnosingStalledMail.md) and Migrating the Database Backend (MigratingDatabaseBackend.md) are unchanged at the tag; their headers say so and their links point at it. The wiki's own additions - the diagrams, the tables and the notes each header names as the wiki's - are kept. A link to a document the wiki copies is a wiki link; every other link to a repository file points at it as v6.3.6 has it. Where SECURITY.md and CONTRIBUTING.md say 6.3.6 was published on 1 October 2026, the copies give 6 October 2026, the day of its publication, and their headers say so. Where Upgrading.md says there is no first-class route from one database backend to another, the copy keeps its pointer at Migrating the Database Backend, the repository's own document on it. Secrets at Rest, "Who can open it": a wiki note under the paragraph that still describes the permissions hMailServer.ini inherits under Program Files, which 6.3.6's /ProtectFolders closes. Contributing, the wiki's own Service Desk section: the address at the group's path, as SECURITY.md gives it. 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 eighteen pages that copy repository documents are copied again from master 92b8f9f63, the 6.3.4 release, so they say what the repository says on the day 6.3.4 is published. Each was brought forward from the version it was last copied from, 540347500, hunk by hunk, and the wiki's own additions were kept where they are still true. What the documents gained: the stored-secrets key in the command line, the high-availability runbook and the warm standby, which now say that it is made once, exported and imported on the other node, and what a node without it does (HM7495); the service account, the COM rule that a change to an item of a shared collection is written onto a copy until Save(), and MySQL's utf8mb4 step in the upgrading guide; database TLS and utf8mb4 in the backend migration; the fuzz job moved from GitHub Actions to GitLab CI's linux-fuzz; the Windows and Linux suites on GitLab CI in the regression environment; the security policy's scans on the project's own runner and its questionnaire pointer; the contributing guide's CI checks; MessageStore and QuickJS in the architecture; a pre-release tag's suffix and the pinned .NET runtime in the release checklist; the update verifier's two signers in the assurance case. Third-Party Binaries follows a rewritten document: the tree commits no executable binary, and the sections this copy had added about where the forty committed binaries lived and their dispositions described the tree before 11 September 2026, so they are gone. Regulatory Scope's note loses four of the five things it called out of date, which the repository has corrected, and its own Annex I table now says the installer has been Authenticode-signed since 6.3.1, that 6.3.x is the supported line, and what a new installation's secure defaults are. The wiki's labels that said "in the tree after 6.3.3, not yet released" now say what is new in 6.3.4, and each header names 92b8f9f63. Where the repository text itself is now stale - the release checklist's and Regulatory Scope's statements that no release can be cut while the chain is on GitHub, the contributing guide and the security policy naming 6.3.3 as the latest release, the assurance case pointing at the changelog's Unreleased section - the copy keeps the repository's words and the header says so where a reader would be misled; 6.3.4 was built and Authenticode-signed by hand and carries no Sigstore bundle.

Christopher Holloway committed Sep 26, 2026

The pages that copy repository documents are copied again from master 540347500, so they say what the repository says after the move to GitLab and after the batches that have landed since each was last copied. Contributing and Security Policy follow their files to the root of the repository, where both were rewritten for GitLab: the contributing guide is now the full one - where things are, how to report, the rule for GitHub's issue numbers, the prerequisites, one build command per component, the suites, every checker, the change checklists, commits, sign-off and merge requests - and the security policy supports 6.3.x and takes a report by a GitLab confidential issue or the project's Service Desk address. Governance names two maintainers, and it, the Release Process and the Assurance Case carry the repository's note that the release chain runs on GitHub Actions and cannot run until it moves. The runbooks gain what the tree after 6.3.3 added to them: the settings store in the database and a save that applies the setting, the drain as a state of its own and UpgradeOnStart, the message held for a sandbox, SPF as an RFC 7208 implementation, the Linux update helper, the locked copies of shared collections, the second bench and the gate in halves. Command Line becomes the whole current document, with every verb the clients have gained since 15 September. Most of these pages carry the wiki's own additions - diagrams, tables, worked commands, and corrections the repository has not taken - so each was merged three ways, from the version of the document it was last copied from to master, and the additions were kept wherever they are still true. Where the repository text describes something in the tree after 6.3.3 and not yet released, the page labels it, as the wiki does elsewhere, and says what 6.3.3 does instead where that matters to someone running it. Additions the repository has overtaken are gone or rewritten: the contribution flowchart and the table of required checks, which were GitHub's, are gone; so are the governance duty table and the bus-factor section, which the document now covers with two maintainers; the security flowchart and timeline send a report to GitLab and ask for the CVE there. The Project Handbook and the release diagram describe build/generate-com-wrapper.ps1, which replaced build/regenerate-interop.ps1 on 11 September 2026 when the COM wrapper left git. Each copy says at the top that it was re-copied from master 540347500 on 24 September 2026. Two say plainly where the repository document is itself out of date, and the copy with it: Third-Party Binaries and Regulatory Scope still count forty committed binaries, none of which has been in git since 11 September 2026, and Regulatory Scope still calls Authenticode signing outstanding and the releases GitHub's. The regression environment's 7-Zip path, which the repository document writes with a control character where \7 belongs, reads correctly here. Fuzzing.md has not changed since the wiki's copy, and its page says so.

Christopher Holloway committed Sep 24, 2026

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

Christopher Holloway committed Sep 24, 2026

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

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