History

Changes Since 6.2.10's 6.3.4 entry on the settings store, Settings Overview, Settings Reference's section 4a and Security Hardening's paragraph on where the pepper lives say that PasswordPepper, set over COM or REST, is written to the file only where the service may write it and is refused with a sentence where it may not, so that under NT SERVICE\hMailServer an administrator sets it in the file with an elevated editor and restarts the service, as ServiceAccount.md's table of the writes to hMailServer.INI has said since the tag v6.3.4 and says with batch51 on master, 5e49abf06, where they said that COM and REST write it to the file whatever the account the service runs as. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

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

Christopher Holloway committed Oct 21, 2026

Four more passages of this wiki's own text say what the documents say of the copy on GitHub with batch51 on master, 5e49abf06, where they still said what batch49 had: the Project Handbook's section 13 says that the codeql.yml it describes, the workflow in the git history at v6.3.3, has not run since 18 September 2026, and that since 18 October 2026 CodeQL analyses the code of the copy on GitHub on each push to master, on each pull request and weekly, GitHub's default setup at first and then the project's workflow .github/workflows/codeql.yml in its place, which OpenSSF Scorecard's SAST check counts where it did not count the default setup, as SECURITY.md's What ran on GitHub now says, where it said that GitHub's own default setup, no workflow of the project's, analysed it, citing that passage as batch49 had it; its section 8 calls .github/workflows/scorecard.yml the copy's Scorecard workflow, as ContinuousIntegration.md's table of the GitHub workflows now does, where it called it the copy's one workflow; the Security Policy's table of standing controls, one of this wiki's two tables, says in its row on memory corruption in a parser that CodeQL has run on the copy since 18 October 2026, GitHub's default setup at first and then .github/workflows/codeql.yml in its place, where it named GitHub's own default setup, and the page's header says so; and Capabilities and Configuration says that from batch51 .github/ also holds CODEOWNERS, which names the code owner a pull request there asks for review, and a new workflows/codeql.yml, CodeQL over the copy in the place of GitHub's default setup, so that scorecard.yml and codeql.yml are the two workflows of the project's that GitHub Actions runs, neither of them the workflow of that name in its list of the workflows from before 18 September 2026, as CONTRIBUTING.md's row for .github/ says, where it said that .github/ held two files and that scorecard.yml was the one workflow GitHub Actions runs. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Six passages of this wiki's own text say what the documents say with batch51 on master, 5e49abf06, where they said otherwise: the Glossary's entry on CodeQL and Changes Since 6.2.10's note on the C++ analysis say that since 18 October 2026 CodeQL analyses the code of the copy on GitHub, GitHub's default setup at first and then the project's workflow .github/workflows/codeql.yml in its place, the Glossary adding that OpenSSF Scorecard's SAST check counts the workflow where it did not count the default setup, where they said that GitHub's own default setup, no workflow of the project's, analysed it; the Project Handbook's section 8 says that from batch51 .github/ also holds CODEOWNERS and workflows/codeql.yml, the two workflows of the project's that GitHub Actions runs, where it called Scorecard's the one; Installing hMailServer says that under NT SERVICE\hMailServer the service says in the application log at a reinitialise, where application logging is on, that the file's copy is not refreshed, as ServiceAccount.md now says, where it said so once a start, and that the file keeps from 6.3.6 the live update's trust beside PasswordPepper; Migration sends a move to another folder or drive to Relocating an Installation and one to a new machine to Backup and Restore, where it sent a new machine to Relocating an Installation, which covers another directory or drive; and Relocating an Installation's own paragraph on moving to new hardware says that from 6.3.6 the live update's trust is read from the file alone and no backup carries it, so that a site that sets it copies it to the new machine with the file (Backup.md), and its header says so. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

The ten copies whose documents batch51 changes - the Assurance Case, Contributing, Governance, the Release Process, the Security Policy, Regulatory Scope, Relocating an Installation, The Service Account, Third-Party Binaries and The Update Feed - are copied again from the documents as master has them from batch51, 5e49abf06 (21 October 2026), and each header says so and what the document changes, where they were the documents at batch50, 0c0b6bae7, or at batch49, f14412d39, which batch50 left as they were. Relocating an Installation: a new paragraph after the opening sends an installation whose programs somebody who is not an administrator may have changed to The Service Account's Reinstalling into a new folder; step 0 converts full message paths with the Data Directory Synchronizer on the installation before anything is copied, a row that names a file outside the data directory first, in the folder it names, in five numbered points, where step 8 ran the synchronizer against the new data directory after the copy, which would have imported each such message a second time, and step 8 checks that none is left and converts one that is the same way in the old data folder; step 3 makes the new root with the permissions setup gives a program folder before the copy, since a copy takes the permissions of the folder it lands in; step 4 says that the server reads Bin\hMailServer.ini under the folder the registry's InstallLocation names, so the edited copy only from step 5 on, where it said the file beside the running hMailServer.exe was read first, and, with step 1, that an edit of a stored setting in the file is put back only where the service may write the file; step 6 runs hMailServer.exe /ProtectFolders after /Register, and /GrantServiceAccess for a service that runs as anything but LocalSystem; step 7 names the Diagnostics page's Installation paths, where it named Settings, Directories; step 9 changes a certificate's files with Edit... rather than deleting it and adding it again; step 11 runs the release's setup again at the new root with /DIR, the 32-bit uninstall entry taken away first, and never the old uninstaller; and step 12 keeps the old tree private until it is deleted by hand. Three sentences of this wiki's own additions there say what the document now says: the passage that ends step 4 has a value edited into the file reported as HM5804 and the stored value used, the line put back where the service may write the file, so that the settings-store paths go on pointing at the old tree, and the store writing a new value into the file's copy where the service may write the file, where it had the line put back and the copy written whatever the account; and the paragraph on moving to new hardware has the stored settings written into the new machine's file at its first start where the service may write it. The Security Policy: Build provenance says that from the release after 6.3.7 a release also carries hmailserver-<version>.intoto.jsonl, the provenance bundle's DSSE envelope alone as one line of JSON, no second signature, which OpenSSF Scorecard's Signed-Releases check counts as provenance, where it said the provenance was not copied under that name; and What ran on GitHub has CodeQL there from GitHub's default setup at first and then .github/workflows/codeql.yml. The Release Process: release-verify writes the .intoto.jsonl and holds it to the bundle, the release has 161 links and files where it had 160, release-publish refuses an .intoto.jsonl that is not the envelope, the copy on GitHub carries it, the rehearsal writes and checks it, and GitHub Actions runs two workflows there, which make nothing a release carries; its note marked Now under step 9 of Order of operations stays. The Update Feed: a release from the one after 6.3.7 has 161 links, the .intoto.jsonl adding 308 bytes to releases.json and 302 to releases/latest. The Service Account: Reinstalling into a new folder points at Relocating an Installation for an installation whose programs only the administrators could have changed, and its table of the writes to hMailServer.INI says that the application log's line on the read-only file is written at a reinitialise where application logging is on and dropped at the service's start, where it said once per start. Contributing lists .github/CODEOWNERS and build/check-osv-ignores.py. The Assurance Case, Contributing, Governance, the Release Process, Regulatory Scope, Third-Party Binaries and The Update Feed say that GitHub Actions runs two workflows of the project's on the copy on GitHub, OpenSSF Scorecard's and .github/workflows/codeql.yml, which takes the place of GitHub's CodeQL default setup, where they said one workflow and the default setup; Governance also says that GitHub's rules there let the administrator role alone write master, the batch* branches and the release tags and hold a pull request to two approvals, the code owner's among them, and to CodeQL's check. 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 5e49abf06 has it, where they pointed at 0c0b6bae7 or at f14412d39; the text is otherwise the document's, but for the adaptations and additions the headers declare. 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 headers of three more of the copies 90a1f71 brought to batch50 on master, 0c0b6bae7, name what this wiki adds to them, as the other copies' headers do and as that commit said each header did: Regression Test Environment's, the section The bench, drawn, with its diagram of the bench, its table of where each piece listens, what sets it and what happens without it, and its parts on the one thing that is not real, DNS, and on one run, end to end; Relocating an Installation's, the paragraph on moving to new hardware, the pointers to Monitoring and Health 16.8 in step 0 and under Seeing where the paths are, what 6.3.3 and earlier do - in the note under step 1's table of the settings store, in the hm_inisettings row of its table of the database's columns and in the passage that ends step 4, which also gives two ways of moving the [Settings] paths - and the sentence in step 7 on reading the ERROR log since 6.3.4, where it said only that the copy and the document are kept the same; and Command Line's, the note above its header, beside the note under What it does not carry that it named already. Command Line's header also says that its links point at this wiki's copy of a document where there is one, as they do for The Update Feed and Secrets at Rest, where it said that they point at the documents as 0c0b6bae7 has them. The headers of the Assurance Case, Governance, the Release Process, the Security Policy and Regulatory Scope already name every addition, and Event Scripts and The Service Account have none. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

Migrating the Database Backend's comparison table says what a failed schema upgrade leaves on SQL Server Compact as Upgrading.md says it with batch50 on master, 0c0b6bae7, and as this wiki's Upgrading Guide has said since 9a56d55: nothing applied, but for a chain from a database older than 6072 that crosses 6107, whose steps before 6107 DBUpdater commits so that 6107's greylisting keying runs outside the transaction, and which a failure from 6107 on leaves at 6106, where the cell, written in 90a1f71, said nothing applied with no exception. The page's header says that the table makes that one exception, which the document's PostgreSQL row leaves out, where it said that the table says the same as the document. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

Migrating the Database Backend has the document's em dashes again, thirteen of them in the twelve lines it copies unchanged from MigratingDatabaseBackend.md as master has it from batch50, 0c0b6bae7 - the opening's, the three of Why this works, the line after the comparison table, the check that every message is inside the data folder, the two of step 1, the archive's one file in step 2, the message that opens under Verifying it worked, the rollback, the changed ids and the moved data folder - where it had written them as hyphens since the page was rewritten on 8 September 2026, the copy of 24 September 2026 having brought back the other four. Its header names this wiki's own additions, where it named only the comparison table under Choosing a target and the line under it that points to Database TLS: the flowchart of the procedure; the diagram of the ids; the note that a restore refuses an archive taken by a newer version, the table of the [Database] keys and the note on the machine-bound password, under Before you start; the sentence on the backup's log and its verification, the table of the combinations a restore refuses, which stands in for the document's one example of them, the note on BackupMessagesDBOnly on 6.3.3 and the paragraph on why the database-only mode is close to mandatory on a migration, under step 2; the two lines of step 4's script that show what the archive holds, the diagram of what the restore does and the note on the staged directory; the command that counts each domain's accounts, aliases and lists, and its output; the sentence on the stored settings under Rolling back; the notes on the restore emptying the data directory, on the password on another machine and on InnoDB under Known sharp edges; and the pointer to moving to a new machine. It also says that the paragraph on where a message file lives is this wiki's wording of the document's, giving the public-folder directory as the code names it, #Public - IMAPConfiguration::GetPublicFolderDiskName, which PersistentMessage::GetFileName combines with the data directory - where the document at 0c0b6bae7 says .Public_Folder. So the copy is now the document's text but for its links, the arrangement of the comparison table and what the header declares, as 90a1f71 said each copy was; the document's two other em dashes are in its table of targets, in the MySQL row, and in its one example of a refused restore, which the page gives in its own arrangement and its own table. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

Four more places in this wiki's own text name the rule action that calls a function of the event script "Run script function", as the Control Panel's action dialog lists it and EventScripts.md names it with batch50 on master, 0c0b6bae7, where they said "Run function": the APIs Reference and Capabilities and Configuration, each in its account of the JScript escaping fix of 6.3.4; the entry on that fix in section 4e of Changes since 6.2.10, as Security Hardening's account of it says since 9a56d55; and the header of Rules and Sieve, as the page's table of actions already does. Item 27 of section 4h of Changes since 6.2.10 keeps "Run function", as 6.3.7's notes word it, and so does the header of Event Scripts in its account of the copy of 18 October 2026, which it follows with the document's new name. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

Four pages say what the documents say with batch50 on master, 0c0b6bae7, of the files and the signatures of the releases up to 6.3.3, in sentences 9a56d55 left as they were: the residual risk on the installer's Authenticode signature, in the table this wiki adds to its copy of the Assurance Case, that every release up to 6.3.3 whose files GitLab has is re-published there, and since 18 October 2026 copied to GitHub, with its original files and signatures, byte for byte, 6.2.0 and 6.0.0-B4 being notes-only, where it said every release up to 6.3.3; section 10 of the Project Handbook that, for each release up to 6.3.3 whose files GitLab has, GitLab's releases page carries the same files, byte for byte, with the same signatures and, from 6.2.19, the same Sigstore bundles, 6.2.0 and 6.0.0-B4 being notes-only there, where it gave every release up to 6.3.3 the same files and the same bundles; Installing hMailServer that its table of assets is what the releases from 6.2.19 to 6.3.3 carry, the two SBOMs coming with every release from 6.2.3 and the five earlier releases that carry an installer having a CycloneDX SBOM of it alone, made afterwards, and that every asset but the two SBOMs of 6.2.22-pre3 has its Sigstore bundle, where it gave the table to every release up to 6.3.3 and a bundle to every asset; and Verifying what was published, in the section on publishing that this wiki adds to its copy of the Release Process, that the releases up to 6.3.3 are on GitLab, those whose files GitLab has with the same files, byte for byte, as when they were published on GitHub, 6.2.0 and 6.0.0-B4 being notes-only there, where it said so of every release (RegulatoryScope.md, SECURITY.md, and Roadmap3.md's row on the files GitLab does not have). The copies' headers are as they were. 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 eleven copies whose documents batch50 changes - the Assurance Case, Governance, the Release Process, the Security Policy, Regulatory Scope, Command Line, Event Scripts, Relocating an Installation, the Regression Test Environment, The Service Account and Migrating the Database Backend - are copied again from the documents as master has them from batch50, 0c0b6bae7, and each header says so and what the document changes, where they were the documents at batch49, f14412d39, or at v6.3.7, which batch49 left as they were. Migrating the Database Backend: step 3 runs DBSetup.exe - the wizard's Create a new hMailServer database, or DBSetup.exe /unattended with the HM_DB_* variables and HM_ADMIN_PASSWORD - which creates the database and its schema, writes the [Database] section through the service, the password encrypted (PasswordEncryption=6), and restarts the server on the new database, the login allowed to create a database and the database not existing yet, with Not DBSetupQuick.exe and the refusal of DBSetup under NT SERVICE\hMailServer, where it said to create an empty database, point hMailServer.ini at it by hand and run DBSetupQuick.exe, which made no usable database there; the short version, the MySQL and MariaDB section's account of who creates the database on Windows and on Linux, and step 4's first open of the new database follow it; the PostgreSQL row says that SQL Server's, PostgreSQL's and SQL Server Compact's DDL is transactional and that only MySQL and MariaDB commit each step's DDL as it runs, where it called PostgreSQL the only one of the four; and the note after the restore says that the schema is created in no transaction on every backend, where it said so of MySQL and SQL Server Compact alone. This wiki's comparison table under Choosing a target now has SQL Server and SQL Server Compact transactional and a failed upgrade leaving nothing applied on them, where it had SQL Server mostly transactional and SQL Server Compact committing as it goes, and its flowchart of the procedure has one step for DBSetup between the backup and the restore, where it stopped the service, created an empty database, edited the ini file, ran DBSetupQuick and started the service again; the table's link to DatabaseTls.md goes to this wiki's copy, Database TLS. The Service Account: in Reinstalling into a new folder, step 2 changes the settings file's other paths into the old installation - PostgreSQLSslRootCert and TlsCaFile, UpdateTrustRootsFile and UpdateLogPublicKeyFile, a path in [SettingsOverride] - to copies where nobody but the administrators may change them and deletes the lines the site did not set, and step 4 keeps the old folder private to SYSTEM and the Administrators until it is deleted; the live update's internal tests name 6.3.1 and 6.3.3 to 6.3.5, where they said 6.3.1 to 6.3.5; and its link to RelocatingAnInstallation.md under the message files outside the data folder goes to this wiki's copy, as its two others do. Relocating an Installation: step 1's inventory and step 4 name TlsCaFile beside PostgreSQLSslRootCert, and Seeing where the paths are says that Installation paths lists every path-shaped setting but that one. The Regression Test Environment: the list of what a new Windows bench needs names the release installers build/fetch-installer-fixtures.ps1 fetches for AdminUpdateTester and AdminUpdateStageTester. Command Line: the two queue examples filter on tries, the field a queue item has, where they named retry_count. Event Scripts: the rule action is "Run script function", as the Control Panel lists it, where it said "Run function". Regulatory Scope: the releases up to 6.3.3 whose files GitLab has are re-published there, 6.2.0 and 6.0.0-B4 being notes-only; SBOMs from 6.2.3, the five earlier releases that carry an installer having a CycloneDX SBOM of it alone; the assets from 6.2.19 to 6.3.3 signed but for 6.2.22-pre3's two SBOMs; and the releases before 6.3.1 unsigned because their original files are published byte for byte, where it gave a published release's immutability as the reason. The Assurance Case, Governance and the Release Process: GitHub's signer signed the releases from 6.2.19 to 6.3.3, where they said the releases up to 6.3.3. The Security Policy: Verifying a release names 6.2.22-pre3's two SBOMs and 6.3.4 beside the withdrawn and superseded pre-releases as the assets from 6.2.19 on without a Sigstore bundle. 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 0c0b6bae7 has it, where they pointed at f14412d39 or at v6.3.7; the text is otherwise the document's, but for the adaptations and additions the headers declare. The wiki's own tables on these pages say what the documents now say: the Assurance Case's traceability row for anyone downloading has the Sigstore signatures from 6.2.19 to 6.3.3 and the SBOMs from 6.2.3, and the Security Policy's row on the supply chain among the standing controls has 6.2.22-pre3's two SBOMs carrying no bundle and the SBOMs from 6.2.3, the five earlier releases that carry an installer having a CycloneDX SBOM of it alone, made afterwards. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 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

Five of the screenshots retaken from 6.3.7 showed the paths and the data of the server they were captured on rather than what a reader's server shows, and are retaken, or cut: cp-hardening.png is the Server limits & expert settings page scrolled to its first card, Timeouts and queue bounds, so that the note under the subtitle, which names the hMailServer.ini of that server, is out of the frame, and the alt texts of Security Hardening and Settings Overview say what is in view - the card's description, then the message finalisation deadline 240, the DNS query timeout 10, the absolute lifetime of one client session 1800, the wait for a free database connection 60 and the event script execution timeout 60, each marked Applies on save - where Security Hardening's quoted the subtitle and described the note; cp-domain-dkim-record.png has the key generated into C:\hMailServer\DKIM, where the private key file was in the administrator's Documents folder; cp-backup-restore.png has the destination folder D:\Backups\hMailServer, the one the page's own examples use, where it was a temporary folder a test had left; cp-groups.png lists one group, Sales, where its one row was a group a test had left; and cp-event-scripts.png, whose path line names that server's own Events folder, which cannot be shown there as an installation's, has that line cut out above the Insert template... list, the card's content moved up into its place and the editor's empty body lengthened by as much, as the card draws itself without a description. The captions of the other four need no change: none of them quotes a path or the group. 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

Encryption and Certificates, Security Hardening, Stopping Spam, Stopping Viruses and Ports Reference 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 and the groups of that build: TLS & certificates is Certificates & encryption, with Automatic certificates (ACME), TLS certificates and TLS versions & ciphers (tabs Protocol versions, Ciphers & verification and Session resumption), and the ACME page says its settings are stored in the database, where the text offered hMailServer.INI instead; Access & abuse protection is Sign-in & access, and Security Hardening embeds the Auto-ban page itself (cp-autoban.png) where the TLS page's capture stood in for it; the Control-Panel-only second factor is set up with the button on the Two-factor tab of Administrative access, the sign-in card no longer carrying a link; Server limits & expert settings opens on its Timeouts and queue bounds card, the front-end proxies being a card of Incoming relays; Spam & virus filtering is two groups, Spam filtering, whose Lists section holds Spam exemptions and Greylisting exemptions, and Virus scanning; DNS blacklists is DNS block lists (DNSBL), and the reject message is the Refusal text, the caption saying that the page was empty on the server it was captured on and that a fresh install has the two inactive rows; Blocked attachments replaces a matching attachment with a short note, where the text said it refused files, and lists file-name patterns; the DANE, DNSSEC and MTA-STS settings of Transport security are on its Encryption tab, ARC and the DKIM timestamps on Signing and the reports on Reports; and the TCP/IP ports page and dialog are described with their AUTH and Listening columns and the dialog's own labels - Bind address, Port, TLS certificate, SMTP authentication and Client certificate policy (mutual TLS) - with the Listening column, not Server status, saying which listeners are up. The sentence that opens the Anti-spam settings page in Stopping Spam is left as it was, with that page's earlier capture. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Your First Domain and Mailbox, Aliases Lists and Public Folders, Connecting a Mail Client, DNS for Your Domain, How Email Works, Rules and Sieve and Routes and Relays 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 and the notes beside them said the left rail predated the grouped navigation: the Domains page puts the Domain box and Add domain above the domain list and the Address and Password boxes above the accounts, and a domain, an account or a distribution list is opened with the pencil button on its row (Edit domain ..., Edit account ..., Edit distribution list ...) or a double-click, a list's members with the people button (Members of ...), where the text said Properties and Edit; the domain dialog has seventeen tabs, General carrying the domain name, and the account dialog sixteen, Identity holding the account's kind, a person, a room or a piece of equipment, so that the kind is no longer among what only the Control Deck sets, while a room's booking policy is; the distribution list editor shows Moderator, Bounce address and the membership query; the public folders, routes and incoming relays pages are described as they are, the routes page with Properties... and its empty-list text, the relays page with its Front-end proxies (PROXY protocol and XCLIENT) card; an account's Two-factor tab is embedded as cp-account-twofactor.png where the Control-Panel-only administrator dialog stood in for it, and Live logs is described streaming the sample domain's local delivery rather than an SMTP and IMAP session, with the Listening column of TCP/IP ports, not Server status, saying which listeners are up; Protocols has a tab each for SMTP, IMAP, POP3 and ManageSieve and one for Timeouts; IP ranges is under Sign-in & access, with Allow delivery and Only after SMTP authentication in its Permissions card; Generate key pair... asks where to save the DKIM key; DNS records and the Setup checklist, once External setup, are under Set up this server, and the ARC and TLS reporting settings of Transport security are on its Signing and Reports tabs; the Rules page is titled Rules, with Show rules for and the Match list of the IF card (Match all criteria (AND), Match any criterion (OR)); the ManageSieve card is on the ManageSieve tab of Protocols; and the smart host is on the Smart host tab of Delivery of e-mail, where it was the Relayer tab, its fields Smart host name (empty = direct delivery) and The smart host requires authentication, with Journaling & dual delivery under Compliance. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Home, What hMailServer Is and Is Not, The Control Panel and Control Panel Pages describe the screenshots retaken from 6.3.7 in the previous commit, read from each image and from the Control Panel at master, where they described the 6.2.10-era captures: the notes that called the pictures 6.2.10's and their tree the older one say they are 6.3.7's, in the default light theme, over the sample domain example.test, and Control Panel Pages' note says that its tree and its table of every page are 6.3.4's and that the old names are search aliases; the sign-in card is headed Sign in, with a Sign in button and no two-factor link, both second factors being set up on Sign-in & access, Administrative access, Two-factor, with the buttons Set up the server-enforced second factor... and Set up Control-Panel-only two-factor authentication...; the Welcome page has thirteen task rows, Set up this server first (to the Setup checklist), then the sample domain's card and one area tile for each group of the tree the credential sees, where the text said twelve rows and six tiles, and its rows go to TLS certificates and Backup, restore & migration, the last one named Protect the administrator password; the Dashboard's tiles are Servers running for and Spam detected, and its Action needed card is at the top, not below the charts, running the checks of the Setup checklist, as External setup is now called; the metrics history is set on Monitoring & alerts, on its Metrics tab; the collection editors are a list with Add..., Edit... and Delete and a dialog per entry, their columns Refusal text, Email address and File-name pattern, on the pages now called DNS block lists (DNSBL), Spam exemptions and Greylisting exemptions; Protocols has six tabs, ManageSieve among them, Performance five, Message store among them, and Advanced three - General, Copies of mail and Scripting - the administrator password being on Administrative access; the About page has a Get help card and a version table with Copy version details; the domain dialog has seventeen tabs in 6.3.7 and the account dialog sixteen, Identity holding the account's kind, its external ID and whether its OpenPGP keys are published, each opened with the pencil button on its row (Edit domain ..., Edit account ...), as is a distribution list (Edit distribution list ...); DKIM's Generate key pair... asks where to save the key and fills in the selector dkim when it is empty, and DNS records is under Set up this server; and the TCP/IP port dialog, opened with Properties..., is titled for its port, with TLS certificate, SMTP authentication and Client certificate policy (mutual TLS), whose Request or Require shows the CA bundle field. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

The wiki's Control Panel screenshots are retaken from 6.3.7: forty-seven of the cp-*.png images, which showed a 6.2.10-era build in the dark theme with the older tree, now show the 6.3.7 Control Panel in its default light theme at 1280x800, with the sidebar's groups as they are today (Set up this server, Accounts & domains, Mail flow & delivery, Connections & protocols, Certificates & encryption, Spam filtering, Virus scanning, Sign-in & access, Monitoring & troubleshooting, Compliance and Maintenance) and the pages, tabs and dialogs under their current names, over a sample domain example.test; two new images are added for the pages that embed them next, cp-autoban.png (the Auto-ban page, now a page of its own under Sign-in & access) and cp-account-twofactor.png (an account's Two-factor tab). cp-logging.png and cp-antispam-settings.png keep their earlier captures for now. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

The wiki's own pages say what the documents say with batch49 on master: the Project Handbook's Scorecard record that the OpenSSF API serves the GitHub copy's score since 19 October 2026, published by the copy's workflow on its first run on master, where it said the API served none for the copy yet; Changes since 6.2.10 and the Settings Reference that nothing has run the Linux suite or the checkers on GitHub Actions since 18 September 2026, and that GitLab CI's checkers job runs every build/check-*.py since 26 September 2026, where they said GitHub Actions had not run for the project at all and the checkers were run by hand; the Glossary, Installing hMailServer and the Project Handbook that the releases before 6.3.1 stay unsigned because every release up to 6.3.3 is re-published on GitLab, and copied to GitHub since 18 October 2026, with its original files and signatures, byte for byte, where they gave a published release's immutability as the reason (SECURITY.md: the GitHub copies were published before the immutable-releases setting was switched on, and can be changed); the Glossary, Installing hMailServer, the Release Process, Upgrading hMailServer, the Settings Reference and Changes since 6.2.10 that GitHub's release workflow signed the releases from 6.2.19 to 6.3.3, where they said every release up to 6.3.3 (no release from 6.0.0-B1 to 6.2.18 carries a Sigstore bundle; SECURITY.md, Verifying a release); Regulatory Scope's Annex I table that the 6.3 line's support period is defined, security fixes until 30 September 2027 and, unless the maintainers write otherwise before then, no support from 1 October 2027, where it said no support period was defined; the Release Process's note at step 9 that since 6.3.6 static-analysis and semgrep fail the pipeline on a finding new to their baselines that master's exceptions file does not accept, while dependency-scan still does not, where it said all three may fail without failing it; and Contributing's paragraphs on the Service Desk and the board without the sentence that the address may change if the project moves to the group hmailserver, which it did on 29 September 2026, and without the clause that a scoped label is not exclusive on GitLab's Free tier, the group having been on GitLab's open-source plan since 13 October 2026. The re-check of the wiki brought to batch49 found these on 19 October 2026; the same shapes were swept on the wiki's own pages, and the copies of repository documents left as their documents have them. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Six of this wiki's own pages name the feed a server from 6.2.28 to 6.3.3 reads by default as the suspended account's Releases API on GitHub, which has answered 404 since 18 September 2026, as UpdateFeed.md says from batch49 and Upgrading hMailServer and Troubleshooting already say, where they called it GitHub's feed or GitHub's API, answering 404, or said that such a server still reads GitHub, which reads as GitHub itself unavailable now that it serves the project's releases again; the Project Handbook and Changes Since 6.2.10 say that GitHub's own CodeQL default setup has analysed the copy on GitHub since 18 October 2026, where the Handbook said that nothing ran CodeQL; and Capabilities and Configuration calls the Scorecard workflow .github/ holds from batch49 a new one. Installing hMailServer, What a server's own update check trusts: a server from 6.2.28 to 6.3.3 reads by default the Releases API of the suspended account's repository, github.com/Progressiverobot/hmailserver, which has answered 404 since 18 September 2026 and still does, the releases copied to GitHub since 18 October 2026 being under another account, where such a server does not look, as Upgrading hMailServer says, where it said GitHub's release feed. Installing on Linux, the update checker: a server from 6.3.0 to 6.3.3 reads the suspended account's Releases API on GitHub, which has answered 404 since 18 September 2026 and still does, where it said GitHub's feed. Capabilities and Configuration, The feed and the signers, as of 6.3.4: up to 6.3.3 the default feed is the Releases API of the suspended account's repository on GitHub, where it said GitHub's Releases API. The Control Deck, the Update view: the default feed since 6.3.4 is in place of the suspended account's Releases API on GitHub, and a server from 6.2.28 to 6.3.3 still reads the suspended account's Releases API on GitHub until UpdateFeedUrl is set, where it said in place of GitHub's and still reads GitHub. Ports Reference, the update feed's row, and Settings Overview, the comment on UpdateFeedUrl: up to 6.3.3 the suspended account's Releases API on GitHub, which answers 404, where both said GitHub's API. On 19 October 2026 api.github.com answered 404 for the releases of Progressiverobot/hmailserver and 200 for the latest release of RainbowWizard-coder/hMailServer, v6.3.7. The Project Handbook, section 13, Static analysis: codeql.yml, a GitHub Actions workflow of the project's, has not run since 18 September 2026, and nothing runs it on GitLab; since 18 October 2026 GitHub's own CodeQL default setup, no workflow of the project's, analyses the code of the copy on GitHub on each push to master, on each pull request and weekly, and holds no change and no release (SECURITY.md, What ran on GitHub, from batch49; the default setup read as configured, weekly, on 19 October 2026), where it said that CodeQL had not run since 18 September 2026 and nothing ran it on GitLab yet, as the Glossary's row on CodeQL now says too. Changes Since 6.2.10, batch 14: after nothing runs it on GitLab yet, that the default setup analyses the code of the copy on GitHub since 18 October 2026. Capabilities and Configuration, the quality-gates line: from batch49 .github/ holds the pull-request template and a new workflows/scorecard.yml, not the workflow of that name the line lists - the tag v6.3.3's, run on a push to master, weekly on Sundays and on demand, where the new one, for the copy on GitHub, runs on a push to master, weekly on Mondays and on a change to branch protection - where it named workflows/scorecard.yml with nothing to tell the two apart. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

The tables the Assurance Case and Security Policy add to their copies say what the documents say from batch49, f14412d39, and what these pages copy from them: the Assurance Case's residual risks give coverage below the bar, and 6.3.0 and earlier unsigned because their files are re-published and copied as they were, and its traceability table the Sigstore bundles of 6.3.5 onwards, where they said that only the .NET Control Panel's coverage was measured, in CI, that releases were immutable and that the signatures stopped at 6.3.3; Security Policy's table of what the project already does says that static-analysis and semgrep have failed the pipeline since 6.3.6 and that the release's files are signed by the tag's pipeline from 6.3.5, where it said that the scans did not stop a push's pipeline and stopped the signatures at 6.3.3. The Assurance Case, The residual risks, ranked by what an operator can do about them: the row Coverage is below the bar, the project to repeat coverage for each release and raise it towards 80% - the native server's lines 73.48% over the Windows suite on 15 September 2026 and 49.01% (38.87% of branches) on Linux on 26 September 2026, neither build/coverage-windows.ps1 nor the linux-coverage job a release step, and the .NET Control Panel's coverage, collected by CI on GitHub until 18 September 2026, collected on neither forge since (the document's section 8, which the page copies) - where the row said that native statement coverage was not measured and that the Control Panel was already measured in CI. The row on Authenticode before 6.3.1 says that 6.3.0 and earlier stay unsigned, every release up to 6.3.3 being re-published on GitLab, and since 18 October 2026 copied to GitHub, with its original files and signatures, byte for byte (RegulatoryScope.md, Who is asking, and the document's status note), where it said that releases are immutable, which the status note the page copies makes true on GitHub only of a release published after the copies of 18 October 2026, the copies themselves being changeable (GitHub listed none of the 47 as immutable on 19 October 2026); and that the Sigstore bundle proves provenance for every asset that carries one, which Security Policy's Verifying a release lists, where it said for every asset, 6.3.4's among them, which carry none. The traceability table's row for anyone downloading gives, after 6.3.4's signed sums file, from 6.3.5 a Sigstore bundle on every file, signed by the tag's GitLab pipeline, and the release jobs of .gitlab-ci.yml among its evidence, as the status note and the evidence table say. Security Policy, What the project already does about each class: for memory corruption in a parser, since 6.3.6 static-analysis and semgrep fail the pipeline of master, a batch* branch or a release tag on a finding new to their baselines that master's exceptions file does not accept, semgrep-sast stops a change only through semgrep-sast-gate, in the files the change touches, and since 26 September 2026 the scans hold a release (the page's own Source code (static analysis) and Before a release, README.md's Quality gates and ContinuousIntegration.md's Before a release: the scans hold it, from batch49), where it said that they did not stop a push's pipeline; GitHub's own CodeQL default setup on the copy there since 18 October 2026, which holds no change and no release, beside the CodeQL workflow that ran while CI ran on GitHub; and GitLab's own SAST from 26 September 2026, the day after the other three, with no runner named, where it put the three on the project's own runner and semgrep-sast on GitLab's shared runners, as they ran in September (since 9 October 2026 a merge request's pipeline runs its checks on GitLab's hosted runners, and every job of a protected ref's pipeline runs on the project's runners: ContinuousIntegration.md). For the supply chain: the Sigstore signatures of every release from 6.2.19 to 6.3.3, the withdrawn 6.2.22-pre4 and the superseded -pre5 aside, as Verifying a release says, and from 6.3.5 a Sigstore signature on every file of every release, by the tag's GitLab pipeline, where the row stopped at 6.3.3. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Home, the sidebar, the footer and thirteen of this wiki's own pages say where the project is worked on and where to ask as the documents say it from batch49 - GitLab the one place the project is worked on, and github.com/RainbowWizard-coder/hMailServer its mirror since 18 October 2026, with Discussions and no Issues - where they said that GitHub had been unavailable to the project since 18 September 2026, sent a question to GitLab alone, called the original hMailServer unmaintained and gave the licence as AGPL-3.0; the suspension of the account Progressiverobot on 18 September 2026, and what did not run or answered 404 after it, stay as history. Home's Source and issues: the repository on GitLab, the one place the project is worked on, its mirror on GitHub with copies of the releases and of this wiki, Discussions and no Issues, a pull request there landed through GitLab, and the former account's addresses answering 404 since its suspension, where it said the project's GitHub addresses answered 404; a new Questions: an issue with the Question template, the Q&A of GitHub's Discussions or the forum, and a vulnerability privately, never in a public issue, a discussion or a pull request (SUPPORT.md, SECURITY.md and README.md from batch49). Its row for The Update Feed says since GitHub suspended the project's old account, where it said since GitHub went. The sidebar names the mirror and where a question goes, and the footer links the mirror. Troubleshooting 19.12: issues opened on GitLab alone, a question also in GitHub's Discussions or on the forum, the former project's issues and discussions still gone, a vulnerability reported privately, never in a public issue, a discussion or a pull request; and its row for an update feed answering 404 names the former account's API, where it said the project's GitHub account had been unavailable. The Glossary's footer names the mirror and the licence AGPL-3.0-or-later, and its CodeQL row says that GitHub's own CodeQL default setup analyses the copy on GitHub since 18 October 2026, no workflow of the project's, and that since 6.3.6 static-analysis (cppcheck and clang-tidy) and semgrep fail the pipeline of master, a batch* branch or a release tag on a finding new to their baselines that master's exceptions file does not accept, while dependency-scan (Trivy with OSV) blocks no pipeline and the release job reads its report, as README.md says, where it said only that the workflow had not run since the suspension and that the jobs in its place were not yet blocking. The Project Handbook's and the Runbooks Digest's status notes say that GitLab is the project's home and the one place it is worked on, the account Progressiverobot suspended and GitHub's copy GitLab's mirror, where they began "GitHub has been unavailable to the project since 18 September 2026"; the Handbook also says where a question and a security report go now - a security report never to a public issue, a discussion or a pull request - that sbom.yml and sign-release.yml ran once on 18 October 2026 on the copies of the releases up to 6.2.22-pre6 and have been disabled since, what .github/ holds from batch49, the third reporting route, and that the OpenSSF API, which on 19 October 2026 still served the old workflow's last result, of 18 September 2026, and none for the GitHub copy, is to carry the copy's score once its workflow has run on master (ContinuousIntegration.md from batch49). Changes Since 6.2.10's preamble and Capabilities and Configuration's quality-gates line say the same of the old workflows, where they said that none had run since GitHub became unavailable. Running in a Container and Installing on Linux say that the image was copied to ghcr.io/rainbowwizard-coder/hmailserver on 18 October 2026 and is private, and is not to be pulled from there, as ContainerImage.md words it from batch49, where Running in a Container said that the old account's registry had been unavailable and Installing on Linux that GitLab's registry held no image yet. Installing hMailServer says that every release from 6.0.0-B1 to 6.3.7 is also on GitHub's releases page, copied from GitLab byte for byte, where it called 6.3.4 the first release published on GitLab alone, and gives the licence as AGPL-3.0-or-later; Upgrading hMailServer names the suspended account's Releases API that a server from 6.2.28 to 6.3.3 reads, and the original hMailServer without "unmaintained"; Version History to 6.2.10 says the original project had gone quiet for years and has since resumed development separately, as README.md does from batch49, and What hMailServer Is and Is Not's About this fork says so too, and that Progressive Robot Ltd forked it in 2026 and released 6.0.0 on 12 June 2026, where it said that the original project stopped being maintained; and The COM API and Scripting names GitHub's private vulnerability reporting beside the confidential issue and the Service Desk address. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

The eight copies whose documents batch49 changes - the Assurance Case, Contributing, Governance, Regulatory Scope, Release Process, Security Policy, The Update Feed and Third-Party Binaries - are copied again from the documents as master has them from batch49, f14412d39, in which 6.3.7 is reflected as at the tag, and each header says so and what the document changes since the tag, where they were the documents at v6.3.7 and said that GitHub had been unavailable to the project since 18 September 2026, that issues and questions went to GitLab alone and that the original project was no longer developed upstream. The Assurance Case's status note: the account Progressiverobot, which GitHub suspended on 18 September 2026, stays suspended, and since 18 October 2026 the project is published on GitHub again, at github.com/RainbowWizard-coder/hMailServer, with GitLab canonical; every release from 6.0.0-B1 to 6.3.7 is copied there with the same files byte for byte; no pipeline of the project's runs there, where GitHub Actions runs one workflow of the project's, scorecard.yml, beside GitHub's own CodeQL default setup; and sbom.yml and sign-release.yml, in the trees of the old tags, ran once there on 18 October 2026 on the copies of the releases from 6.2.3 to 6.2.22-pre6, what they wrote was undone, and both have been disabled since. Contributing: the original project went quiet for years and has since resumed development separately; GitLab is the one place the project is worked on and GitHub its mirror, with the repository, every release, the wiki's copy, pull requests and Discussions and no Issues; the table of where things are, the tree's .github/, the GitHub numbering, the rule that no build step downloads from GitHub, and a pull request on GitHub accepted and landed through a GitLab merge request. Governance: the status note, the private vulnerability reporting switched on and read by the maintainers, the repository on GitHub belonging to the account RainbowWizard-coder, its only administrator, Zainulabidin90 removed from it on 18 October 2026, and accepting, reviewing and proposing a change taking in a pull request on GitHub. Regulatory Scope: the releases copied to GitHub, GitHub's own CodeQL default setup there and the one workflow of the project's that GitHub Actions runs there, OpenSSF Scorecard's, which signs and publishes nothing of a release, the old release workflows run once there and disabled, and the one signer a server up to 6.3.3 trusts named as the release workflow of the repository under the former account Progressiverobot. Third-Party Binaries: the build-inputs files fetched from GitLab alone, both releases copied to GitHub with the others and never read there, and nothing on GitHub doing what the old binary-provenance workflow did. Release Process: GitHub unavailable to the project from 18 September to 18 October 2026; The copy on GitHub, under The release on GitLab; step 9's sentence on CodeQL's default setup, which the gate does not read; step 14's issues answered on GitLab; and the federated credential made on the app registration the protected variable AZURE_CLIENT_ID names. Security Policy: GitHub's private vulnerability reporting as a third route, and never a public issue, merge request or pull request on either forge or a GitHub discussion; a report made there carried into a confidential GitLab issue; the exceptions file counted again on 18 October 2026, 491 accepted findings, 157 expiring on 25 September 2027 and 3 on 12 October 2027, and in Why that date 159 and 42; and Verifying a release for a file from GitHub's releases page. The Update Feed: no server reads a feed on GitHub, the address 6.2.28 to 6.3.3 read is the suspended account's and still answers 404, and a certificate for a workflow of the repository on GitHub names an identity no server trusts. 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 f14412d39 has it, where they pointed at v6.3.7. The text is otherwise the document's, but for the adaptations and additions the headers declare: Contributing's paragraph on reporting and asking keeps the Service Desk for anyone without a GitLab account, as SUPPORT.md does, and now also sends a question from someone with a GitHub account to the Q&A of GitHub's Discussions, where the document still says only a security report can go by email; Release Process's note marked Now at step 9 stands after the document's new sentence there; and the Assurance Case's own additions of 8 September 2026 - the chart of the trust boundaries drawn in section 4 in place of the document's text figure, the sentence on a forward proxy that ends section 6's paragraph on the update path, and the traceability table, the chart of which claim each weakness class answers and the table of the residual risks that close section 7 - are named as this wiki's own in its header, which named none of them. The wiki's own additions on these pages that name the reporting routes - Security Policy's decision chart and its timeline after a report, Governance's map of which document governs what - name GitHub's private vulnerability reporting and the Q&A of GitHub's Discussions beside the confidential issue, the Service Desk address and the forum, and never a pull request or a discussion for a vulnerability; and Governance's note on code-signing material says that the old release workflow could not sign once GitHub had suspended the project's account, where it said it cannot sign while GitHub is unavailable. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Security Policy's sentence on the fallback of a release that cannot be made by the pipeline reads 'The fallback is a release made by hand, as 6.3.4 was', the document's own words at v6.3.7 (SECURITY.md:219-220), where the copy of 5 October (95cbd71) had put the page's title, Release Process, in the link's text, so that the rendered sentence said 'The fallback is Release Process'; the link's target, the Release Process page's section on a release made by hand, is unchanged. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

Upgrading hMailServer's upgrade path says that a 6.3.6 server installed from a distribution release's own package is upgraded with its package manager, as Home now does, and Installing on Linux's note says that 6.3.5's packages were made by its tag's pipeline, where the row gave 6.3.6 the live update or the installer alone and the note had 6.3.4's and 6.3.5's packages both built by hand. Upgrading hMailServer, 18.2, the row Coming from 6.3.6: its live update installs 6.3.7, or the 6.3.7 installer is run, and one installed from a distribution release's own package is upgraded with its package manager (18.4f; the CHANGELOG's From 6.3.6 at v6.3.7: apt refuses the generic package on Debian 12 and dnf on Enterprise Linux 9). Installing on Linux, the note at the head of the page: 6.3.4 and 6.3.5 carried the x86-64 .deb and .rpm only - 6.3.4 built by hand after GitHub's suspension, with no ARM machine to build on, and 6.3.5 by its tag's pipeline, which kept its AArch64 packages and AppImages as CI artifacts, out of the release (the CHANGELOG's 6.3.5 section, What the release carries) - where it said that both were built by hand, a sentence 35b7545 wrote on 5 October 2026 when it added 6.3.5 to one first written for 6.3.4. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

The Project Handbook's section 9 says that the release jobs made 6.3.7 on 17 October 2026 and that the installer's fetched inputs come from build-inputs-2 as well, as its header says the section is brought up to 6.3.7; Capabilities and Configuration gives 6.3.7's version stamp and every release published since the page was first written, 6.3.7 the latest; and the APIs Reference says that 6.3.4 was the latest release when its markers were written - where the three said 6.3.6 was the last release the jobs had made, gave 6.3.6's stamp beside "v6.3.4 (26 Sep 2026, latest)", and called 6.3.4 the latest release under a header that names 6.3.7. The Project Handbook, section 9: since 26 September 2026 the installer's fetched inputs come from the project's package registry on GitLab - the build-inputs-1 files, and from 6.3.7 the build-inputs-2 files as well, the MariaDB client the project builds from MariaDB's source (RELEASE.md step 11 and CONTRIBUTING.md at v6.3.7) - and the release jobs made 6.3.5 on 29 September 2026, 6.3.6 on 6 October 2026 and 6.3.7 on 17 October 2026, where it named build-inputs-1 alone and stopped at 6.3.6; only section 8 had gained 6.3.7 (3c46100). Capabilities and Configuration, section 1: the version stamp is 6.3.7, build 46 (Version.h:6-8 at the tag v6.3.7, 31d656c0c), 6.3.6 build 45, and the releases published since the page was first written run to v6.3.4 (27 Sep 2026; the tag was made on 27 September, not the 26th), v6.3.5 (29 Sep 2026), v6.3.6 (6 Oct 2026) and v6.3.7 (17 Oct 2026, latest); its header says that the stamp, the releases and the schema each release requires reflect 6.3.7, as the schema list has since 354870f. The APIs Reference, section 4: 6.3.4 (27 September 2026, schema 6104) was the latest release when the markers were written. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

Installing hMailServer gives 6.3.7's check, as its header says it does, and it and seven more pages say that the project's GitLab CI has signed every release since 6.3.5 - 6.3.5 at the path the project began at, and from 6.3.6 at the group's, which the project moved to on 29 September 2026 - where they said, as 6.3.4 was made, that the pipeline was to sign the releases after it, had signed none yet and would follow the project to the path it was to move to. Installing hMailServer, section 4.1: a paragraph on checking 6.3.7 - made by its tag's GitLab pipeline, each of its sixty-two files signed with Sigstore and its bundle beside it, hmailserver-6.3.7.intoto.sigstore.json its SLSA provenance, no .sig; the installer checked against the SHA-256 the Download table of the release's notes gives it, dcae96bd75d6cae8e5a910d15940567067539ed99db5aeed40a815added4d85f for hMailServer-6.3.7-x64.exe, or against its bundle with cosign, the identity https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7 and the issuer https://gitlab.com, the project's id 86730559 read as Security Policy's Verifying a release says, then its Authenticode signature - where the page checked releases up to 6.3.3 and 6.3.4 alone; the releases after 6.3.4 are signed by the project's GitLab CI, a signer every server from 6.3.4 on has compiled in, and Upgrading hMailServer 18.4f says which servers install 6.3.7 by their live update, where they were to be signed and a 6.3.4 server's live update was to install them; and what a 6.3.4 server trusts is that pipeline at the path the project began at, where it signed 6.3.5, and at the group's, where it has signed every release from 6.3.6, there only with the project's id. The same stale sentence, swept: Settings Overview (the update feed's two signers), Release Process (Verifying what was published, this wiki's own section: the identities the releases from 6.3.5 carry), the Glossary (Sigstore), the Control Panel Reference (the Updates card), The Control Deck (the Update view: a 6.3.4 server's live update trusts the releases after it, where the signing job was written and had not yet run), the Project Handbook's section 10 and the Settings Reference's UpdateSourceRepository row (the three settings at the path the project began at keep a server to it, so that it refuses every release from 6.3.6, and since the move a server from 6.2.28 to 6.3.3 is upgraded by hand; the row's link to UpdateFeed.md now at the group's path). Home: the Atom feed's entries' ids are made from each release's tag alone, so that they do not change when a release is edited or the project moves, as UpdateFeed.md's The Atom feed says, where they were to keep their ids when the project moved into the group. The sections for one release - Changes Since 6.2.10's 4e and Upgrading hMailServer's 18.4c, written for 6.3.4 - and Capabilities and Configuration's paragraph marked as of 6.3.4 say it as 6.3.4 stood, and stay as written. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026