History / Project Handbook

Running in a Container and the Project Handbook, this wiki's own pages, say what ContainerImage.md, the CHANGELOG and build/make-app-icon.ps1 say with batch54 on master, 9336fdd59, of the Helm chart's listing and the packages' icon. Running in a Container's note on the chart says that since 6.3.6 each release carries it as hmailserver-chart-<version>.tgz, with its Sigstore bundle, and that the project's chart repository, https://updates.progressiverobot.com/helm/, serves it (helm repo add hmailserver https://updates.progressiverobot.com/helm/, then helm install mail hmailserver/hmailserver), which Artifact Hub lists at 6.3.7, and that the chart of 6.3.7 and earlier has no icon while the next release's names the fork's own, the Control Panel's, which Artifact Hub shows on the listing, as ContainerImage.md's The Helm chart and Artifact Hub say, where it said that the chart was not published to a chart repository and was installed from a checkout, which has not been so since 6.3.6: the CHANGELOG's 6.3.6 section has the chart as a file of each release, served from that address, and this wiki's Changes Since 6.2.10 gives 6.3.6 the Helm repository; read on 24 October 2026, the repository's index lists 6.3.7 and 6.3.6, and Artifact Hub's API gives the listing at 6.3.7, from that address, as a verified publisher's, with no logo. The example from a checkout stays. The Handbook's inventory of build/ says that make-app-icon.ps1 also writes the .ico's 256 px image as hmailserver/source/Server/platform/packaging/hmailserver.png, the packages' icon, as the script's header has said since batch54, where it named the .ico alone. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

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 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

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 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

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

Christopher Holloway committed Oct 18, 2026

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

Christopher Holloway committed Oct 18, 2026

Security Policy, Release Process, Governance, the Assurance Case, Contributing, the Regression Test Environment and the Project Handbook say who sees a report, who can approve a batch, what the revoked token laptop-git can do, which runners and licences a release needs and when the accepted findings expire as the documents say it at batch48 (31d656c0c), the batch 6.3.7 is made from, where they said what v6.3.6 says. For 6.3.7 the tree's SECURITY.md, RELEASE.md, GOVERNANCE.md, ASSURANCE-CASE.md, CONTRIBUTING.md and RegressionEnvironment.md were corrected in what they say of the project's members, approvals, tokens, runners and licences, and the stamp counted the accepted findings again on 17 October 2026. The wiki's copies still said what v6.3.6 says: that Zain Ul Abidin can see every report and approves each merge request, that the project access token laptop-git holds the Owner role until 27 September 2027, that 298 findings expire in March 2027, that the release jobs have not run, that two machines run the builds and suites. The push of master to main, the branch GitLab serves the wiki from, would have made most of that live for the first time. Each paragraph, list item or table row that says one of these things is now the document's at 31d656c0c, with the wiki's own links kept and a link to a document the wiki has no copy of pointing at master: - Security Policy: who sees a confidential issue; Why that date and One date comes first, with bench150's Windows licence and the findings as counted on 17 October 2026; the opening and step 3 of How a report is handled; the opening, steps 1 and 4 and the runners of How a security release is made; the opening of What must stay valid and its rows for the exceptions file, the two Windows benches' licences, laptop-git and the release channels' credentials. - Release Process: the status note; who creates release tags; step 2's last paragraph and step 3's first under The release on GitLab; Before starting and steps 2, 3 and 6 of A security release during the pause; and step 7's paragraph on the release's notes, which the copy lacked. - Governance: every paragraph on the members' roles, the approvals, laptop-git and the landings by 14 October 2026, so that the whole copy is the document's, links aside. - Assurance Case: the residual risk "Bus factor is still effectively 1". - Contributing: the opening's paragraph on what runs where, On the project's own runners (the wiki's note marked Now kept), and steps 5 and 7 of Merge requests. - Regression Test Environment: GitLab CI's runs of the suite. Not taken, for the copy from v6.3.7 after the release: SECURITY.md's paragraph on 6.3.7 under What gets a release, with step 3's pointer to it, RELEASE.md's paragraph on 6.3.7 under A security release during the pause, and the latest release lines; Security Policy still gives 6.3.6 as the latest release until 6.3.7 is out. The Project Handbook, the wiki's own page, says the same in its own words: a batch lands through a merge request that a second person approves by the rule, and since 13 October 2026 on the owner's override; the release jobs made 6.3.5 and 6.3.6; the builds and suites run on the project's own runners, bench150, S1-WINBENCH, linix, server2 and s1-linux. Each header says what was brought up, from which commit, and what is left out. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

Security Policy, Release Process, the Project Handbook and Home say what a release is while releases pause as SECURITY.md and RELEASE.md say it at batch48 (834d7a3b8), the batch 6.3.7 is made from: no release is planned by date, and each security release is cut from master with the finished work master holds then. The owner's decision of 16 October 2026 reworded the five places of the two documents that said what a release is during the pause (CHANGELOG.md's entry for the documents). The wiki's copies of them, and its summaries, still said what they said at v6.3.6, which 6.3.7 makes untrue: that 6.3.6 is the last release for the time being, that no feature release follows it, that a security release is 6.3.6 with fixes and that master takes fixes only. Security Policy: Supported versions, the opening of While releases pause and the first point of its What is supported, and for how long are SECURITY.md's paragraphs as batch48 has them, line for line; the last names 6.3.6 beside 6.3.5, 6.2 and older among the installations upgraded in place to the newest release, as the stamp (c92d3c80e) made it say. Release Process: its opening and the first paragraph of A security release during the pause are RELEASE.md's as batch48 has them; the opening, which the copy of 5 October 2026 (95cbd71) had twice, is there once, as the document has it. 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; Security Policy's says that it still gives 6.3.6 as the latest release until 6.3.7 is out, where SECURITY.md already names 6.3.7 of 17 October 2026. The Project Handbook's status note and its section 9, and Home's Current release row, say that 6.3.6 was the last release planned by date and that each security release is cut from master with the finished work it holds then. The two sections for one release that say the pause in 6.3.6's own words, Upgrading hMailServer 18.4e and Changes Since 6.2.10 4g, stay as written, as 6.3.6's section of the CHANGELOG does. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

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

Christopher Holloway committed Oct 5, 2026

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

Christopher Holloway committed Oct 5, 2026

The pages on CI, the release process, the test environment and the project's home are brought up to the tree as it stands for 6.3.6 (batch42 at d8a84f66c, with the branch b42-feeds-docs) and to master's first full pipeline (GitLab work item #21). The five copies of repository documents take every change their documents have had since the tag v6.3.4 (51e2dbda0), merged three ways from the document at the tag to the document now, so that this wiki's own additions stay: Security Policy (SECURITY.md: "While releases pause" - 6.3.6 the last release for the time being, security fixes for the 6.3 line until 30 September 2027 by the maintainers' decision, what gets a release, how a report is handled, the five steps of a security release only the owner can take, what a release depends on that expires; no Azure secret on GitLab; the .sigstore.json copies and the SLSA provenance from 6.3.6), Release Process (RELEASE.md: "A security release during the pause", placed before this wiki's "The release at a glance"; the release jobs' fifty-seven files from 6.3.6 and the batch branches' rehearsal), Contributing (Roadmap3.md, the AppImage's own runtime, the upgrade gate from 6029's create script, linux-repro, three new checkers, and the package, release and rehearsal jobs in place of the release job the document called a placeholder, which the tree now corrects as well), Fuzzing (the commit the old workflow is at) and Regression Test Environment (the Linux suite's counts and the coverage schedule). Each header says what it was brought up to, and where it still differs from its document: the latest release is given as 6.3.4, published on 27 September 2026, until 6.3.5 is out, where the tree is already stamped for 6.3.5; Security Policy keeps its account of the 455 findings accepted at 6.3.4. The statements that no GitLab job had run are replaced with what ran. Master's pipeline 2886389460, 27 September 2026 04:19 to 07:55 UTC on 6bc09509d, read from GitLab's API on 29 September 2026: 29 jobs, 25 passed; windows-gate on bench150, 3,811 tests, 3,736 passed, 0 failed, 74 skipped, 1 inconclusive, and linux-suite on linix, 2,020 tests, 1,710 passed, 0 failed, 310 skipped, each 8,563 s; db-matrix left manual; secret_detection, semgrep and static-analysis failed, each on a fault of the tree's that batch41 mends (#21's notes). So on Home (the regression suite; the current release, with the pause; following releases, with updates.progressiverobot.com/releases.atom from 6.3.6 beside GitLab's own feed; the Security Policy and Release Process rows), the Project Handbook (the status note and sections 7, 8, 9, 11 and 12: GitLab CI's jobs have run, a change lands through a merge request the other maintainer approves with build/land-via-mr.py, the pause), Installing on Linux (linux-cross passed, 559 s), Running in a Container (linux-image and chart-and-compose passed), Changes Since 6.2.10 (GitLab CI runs the checks' replacements; the first full pipeline on the fixed tree), Contributing (a note marked Now) and Regression Test Environment (its header). Fuzzing's Now note: the schedule exists (4461177), and its first two nights, pipelines 2887914840 and 2891652158 on 28 and 29 September 2026, ran linux-fuzz alone and passed, about an hour each. Governance and Regulatory Scope were read and left: their documents have not changed since v6.3.4, and what they say of CI and the release jobs (written, not yet run on a release tag) is still true. Every wiki link and in-page anchor the changes add resolves. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Sep 29, 2026

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

Christopher Holloway committed Sep 27, 2026

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

Christopher Holloway committed Sep 26, 2026

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

Christopher Holloway committed Sep 26, 2026

The Project Handbook's link to Release Process was broken across two lines, [[Release at the end of one and Process]] at the start of the next, and GitLab rendered it as a link to a page called Release, a newline and Process, which does not exist. The link is on one line now. Every page was rendered with GitLab's Markdown API in the project's context on 26 September 2026: this was the one link that did not resolve. Every other wiki link, relative link, image, table and #anchor resolves, the 145 Mermaid diagrams parse with Mermaid 10 and 11, and no HTML is stripped.

Christopher Holloway committed Sep 26, 2026

What the check of the merged wiki found, put right. The landing page counted 61 pages, 34 guides and 'the other 60', and listed none of the four pages written for 6.3.4: it counts 65, 38 and 64, and Message Storage, Compliance and eDiscovery, Rooms and Equipment and Mail In to a Webhook have their rows where the sidebar groups them. Twelve sentences named the next release as 6.3.5; each now says the releases after 6.3.4, since nothing after 6.3.4 has a number yet. Installing on Linux said the AppImages began in 6.3.2, where the GitLab releases of 6.3.0 and 6.3.1 carry both of them. Capabilities and Configuration gave 23 per-account tables as today's count, where AccountStores.cpp declares 62 in 6.3.4, 24 carried and 38 exceptions; the old figures stay, labelled with 3233b0cc4. The Settings Reference counted 26 bootstrap keys, where build/ini-settings-baseline.txt has 29. And Stopping Spam said the quarantine digest needs its domain's switch and hour, when an account may hold a value of its own for both (EffectiveSetting.cpp, QuarantineDigestTask.cpp).

Christopher Holloway committed Sep 26, 2026

What the check of the wiki's 6.3.4 pages found: the backup page counted 60 per-account tables in the AccountStores declaration where it names 62 (24 carried and 38 declared exceptions), and called the booking answers and the booking queue the two exceptions added in 6.3.4 when they are the last two, added with rooms and equipment on 25 September 2026. Several pages said GitLab CI's jobs build, compile, lint, scan or run the suites, when ContinuousIntegration.md records that no GitLab job had run yet when it was written on 25 September 2026; the Linux page, the container page, the regression environment's header, the project handbook, the regulatory scope's Annex I table and the security policy's table now say the jobs are written and not yet run. And the installer page said the secure defaults' failure is shown in a message box on the built-in database's branch only, when the installer shows it on both branches and only logs an exit 5 after DBSetup, a database it attached.

Christopher Holloway committed Sep 26, 2026

The 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 Project Handbook's disclosure line says what SECURITY.md says: GitLab is a CVE Numbering Authority for public projects hosted on GitLab.com, not for every project there.

Christopher Holloway committed Sep 24, 2026

The pages on how the project runs stop describing GitHub as its process. Governance copies GOVERNANCE.md, whose status note says its passages on the GitHub ruleset, repository admin and private vulnerability reporting describe how the project ran there but whose body still says them in the present tense; the copy now puts them in the past tense and says what happens now, from that note and from CONTRIBUTING.md and SECURITY.md at master 540347500: merge requests, no approval rule on GitLab, a gated tree landing on master by fast-forward, reports arriving as confidential GitLab issues that one maintainer receives, and the ownership of the GitLab project as the critical asset where GitHub repository admin stood. It also says plainly that GOVERNANCE.md does not yet record the second maintainer's access on GitLab. Release Process keeps RELEASE.md as it is and adds short notes at steps 9, 11, 12 and 13, where a reader of one step would otherwise miss the status note: the alert pages are GitHub's, build-inputs-1 is unreachable, the draft, packaging, SBOM, signing, smoke test and package managers cannot run until the chain moves, which is planned roadmap work, and a gated tree lands by fast-forward with no pull request. Its own publishing section now says the releases are on GitLab with the same files, that no later release can carry the GitHub signing identity, and that the installer has been Authenticode-signed since 6.3.1, where it said it was not. The Project Handbook, a record of 4 September, says in sections 7 to 12 what has changed - the merge-request route, checks by hand, no CI, the release chain stopped, CVE IDs through GitLab and the Security template - and puts the GitHub checks it records in the past tense. The home page's pointer to Contributing speaks of a merge request.

Christopher Holloway committed Sep 24, 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

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

chrisholloway5 committed Sep 11, 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