Skip to content

History / The Update Feed

Revisions

  • The headers of the four copies whose documents were the same at batch54 as at an earlier copy - the Command Line, Secure Defaults, The Update Feed and Third-Party Binaries - say that batch55, 36bd59faa, changes the document in the places they list, the list following the link to 36bd59faa, and say in a sentence of their own after it that the document was the same at batch54, 9336fdd59, as at the commit or the tag each copy was last made from, 0c0b6bae7, the tag v6.3.7, 5e49abf06 and 6fb8164c6, where the clause saying so stood between the link and the list, so that the list read as that commit's or that tag's changes. Secure Defaults' header says that the copied sentence of The certificate, a host added to AcmeDomains later issued for at once, is so from the release after 6.3.7, and that up to 6.3.7 a host added waits until the certificate in use is due for renewal, as Encryption and Certificates says under When it renews, where it gave the sentence no release; the copied text is the document's, unchanged. Third-Party Binaries' header says that the document's opening named the icon library with its archive, the documents' images and the OpenPGP fixtures alone, where it left the images out. Headers only: no copied text changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 26, 2026
  • The eight copies whose documents batch55 changes - the Assurance Case, the Command Line, Contributing, the Release Process, Secure Defaults, the Security Policy, The Update Feed and Third-Party Binaries - are copied again from the documents as master has them from batch55, 36bd59faa, on master since 26 October 2026, and each header says so and names what changed. The Security Policy's Verifying a release says that the release's SLSA provenance names every file of the release but the Sigstore bundles, how the commit, the tag and the pipeline its statement names are compared with those its signing certificate records, which from the release after 6.3.7 the release pipeline holds before it publishes, and, under SLSA Build level, that the releases from 6.3.6 meet Build L1 of SLSA v1.0 and claim no higher level, with why L2 and L3 are not met; For a security questionnaire names SECURITY-INSIGHTS.yml; and Renovate opens its merge request for an advisory at its next run, for a NuGet package with a fixed release, where it said at once for any dependency. Contributing says, under Code style and licence headers, that a file of the original hMailServer's whose own file in the original carried Martin Knafve's copyright notice keeps it on the line below the header, and that every file of the tree has its copyright and its licence as the REUSE Specification 3.3 asks, by its header or a table of REUSE.toml, with every licence's text in LICENSES/ and the reuse job holding it, which The checkers, the tables of the checkers and generators and Governance, conduct and licence name too. Secure Defaults says that a host added to AcmeDomains later is issued for at once, and that from the release after 6.3.7 the Compose file and the Helm chart secure a new installation's database at its first start, which the charts of 6.3.6 and 6.3.7 do not. The Command Line has the new passage on trusting a server's self-signed certificate on the machine you administer from; the Release Process's step 3 of The release on GitLab has release wait for the AArch64 packages' start jobs and linux-image-arm64, and its step 6 has container-image-start ask whether the update check knows it runs in a container; the Assurance Case's residual risk on coverage gives the linux-coverage job's weekly schedule and its first run on GitLab, where it said that the schedule had yet to be created; The Update Feed says that a server from 6.2.28 to 6.3.3 is offered only the newest release and so reaches neither it nor 6.3.3 by the live update, where it said that a 6.3.3 server found itself up to date and that one on 6.2.28 could go to 6.3.3 that way; and Third-Party Binaries says what the tree still carries that git shows as binary, and that the SQL Server Compact headers are 4.0's. 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 36bd59faa has it, where they pointed at 9336fdd59 or, in the Command Line, The Update Feed and Third-Party Binaries, at 0c0b6bae7, 5e49abf06 and 6fb8164c6 and, in Secure Defaults, at the tag v6.3.7, each document being the same at those commits as at 9336fdd59; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

    Christopher Holloway committed Oct 21, 2026
  • 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
  • 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
  • Release Process and The Update Feed give the path the project began at, gitlab.com/Progressiverobot/hmailserver, in the four lines where RELEASE.md and UpdateFeed.md at the tag v6.3.7 give it - the identity 6.3.5 was signed with, the repository a server from 6.2.28 to 6.3.3 is given beside that identity, the GitLab column's repository before the move, and the second of the two paths whose certificates no setting lets through without the project's id - where each copy gave the group's path, gitlab.com/hmailserver/hmailserver, and each line was false. Release Process, step 4 of The release on GitLab: 6.3.5, before the move, was signed as https://gitlab.com/Progressiverobot/hmailserver//..., as RELEASE.md:234 has it and as build/ci/release-chain.py's SIGNER_IDENTITY_PREFIX at v6.3.5 made it. The Update Feed: the ini example for a server from 6.2.28 to 6.3.3 names UpdateSourceRepository=https://gitlab.com/Progressiverobot/hmailserver beside the identity at the same path (UpdateFeed.md:175), the values the document says 6.3.5's certificate names exactly, where it named the group's path under a sentence that says these settings must not name it; the table's GitLab column, the signer before the move, gives the repository at the path the project began at (:362); and the certificates no setting lets through without the project's id are those that name the group's path or, from 6.3.6, the one the project began at, https://gitlab.com/Progressiverobot/hmailserver// (:498), where the copy gave the group's path for both. dacc831 put the group's path in the example and the table row on 5 October 2026, when it moved every link to the project to the group's address, and 95cbd71's copy from v6.3.6 that day carried it into the other two lines; 1cea3e0 kept all four, the documents' lines being the same at v6.3.6 and v6.3.7. Every line of the twenty-four copies that names the path the project began at in its document now names it as the document does. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

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

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

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

    Christopher Holloway committed Oct 17, 2026
  • The twenty-two pages that copy a repository document are copied again from the documents as the tag v6.3.6, the release, has them, each keeping what this wiki adds of its own. Re-copied from the tag v6.3.6 (e3c448aa6), each header saying so and what 6.3.6 changes in it: The Update Feed (UpdateFeed.md), The Service Account (ServiceAccount.md), Security Policy (SECURITY.md), Release Process (RELEASE.md), Upgrading Guide (Upgrading.md), Secure Defaults (SecureDefaults.md), Third-Party Binaries (ThirdPartyBinaries.md), Contributing (CONTRIBUTING.md), Secrets at Rest (SecretsAtRest.md), Assurance Case (ASSURANCE-CASE.md), Event Scripts (EventScripts.md), Command Line (CommandLine.md), Governance (GOVERNANCE.md), Regression Test Environment (RegressionEnvironment.md), The SNMP Agent (Snmp.md), High Availability Runbook (HighAvailabilityRunbook.md), Regulatory Scope (RegulatoryScope.md) and Fuzzing (Fuzzing.md). Architecture (ARCHITECTURE.md), Database TLS (DatabaseTls.md), Diagnosing Stalled Mail (DiagnosingStalledMail.md) and Migrating the Database Backend (MigratingDatabaseBackend.md) are unchanged at the tag; their headers say so and their links point at it. The wiki's own additions - the diagrams, the tables and the notes each header names as the wiki's - are kept. A link to a document the wiki copies is a wiki link; every other link to a repository file points at it as v6.3.6 has it. Where SECURITY.md and CONTRIBUTING.md say 6.3.6 was published on 1 October 2026, the copies give 6 October 2026, the day of its publication, and their headers say so. Where Upgrading.md says there is no first-class route from one database backend to another, the copy keeps its pointer at Migrating the Database Backend, the repository's own document on it. Secrets at Rest, "Who can open it": a wiki note under the paragraph that still describes the permissions hMailServer.ini inherits under Program Files, which 6.3.6's /ProtectFolders closes. Contributing, the wiki's own Service Desk section: the address at the group's path, as SECURITY.md gives it. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

    Christopher Holloway committed Oct 5, 2026
  • Seven features 6.3.4 added have a page of their own, each a copy of its repository document as the tag v6.3.4 (51e2dbda0) has it, headed by the Source of truth note the other copies carry (GitLab issue #25): The SNMP Agent (Snmp.md), Event Scripts (EventScripts.md: the JavaScript engine of the Linux builds, and the contract for all three languages), Secure Defaults (SecureDefaults.md), The Service Account (ServiceAccount.md), Secrets at Rest (SecretsAtRest.md), Database TLS (DatabaseTls.md) and The Update Feed (UpdateFeed.md). A link to a document the wiki copies became a wiki link - Command Line, Third-Party Binaries, Warm Standby, High Availability Runbook, Upgrading Guide and The Service Account, the last two to their sections - and every other became a link to the document at v6.3.4. Each note says where the tag has moved on from its document. The installer smoke test SecureDefaults.md expects on a branch is in the tree at the tag, and does not yet make the checks it lists. ServiceAccountName and ServiceAccountPassword, which ServiceAccount.md calls no longer read, are still loaded by the settings loader (IniFileSettings.cpp:457-458) and used by nothing. The site that UpdateFeed.md's opening note calls not yet deployed has served the feed over HTTPS since 26 September 2026, and at 05:31 UTC on 27 September answered /releases/latest and /releases.json with 6.3.4 and /download/hMailServer-x64.exe with a 302 to 6.3.4's installer. The sidebar and the landing page list each page in its group: Database TLS, Secure Defaults, The Service Account and Secrets at Rest under Secure it; The SNMP Agent and The Update Feed under Operate it; Event Scripts under Extend it. The landing page counts 72 pages (the 74 files less the sidebar and the footer), the other 71, and twenty-two with a Source of truth note; the guides stay 38, since a copy is a repository document. The Runbooks Digest names the seven among the copies. Monitoring and Health, The COM API and Scripting, Security Hardening, Encryption and Certificates, Migrating the Database Backend and Upgrading hMailServer keep what they say of each feature, and gain a line pointing to its page. Every page was rendered with GitLab's Markdown API in the project's context on 27 September 2026: every wiki link, relative link, anchor and link into the repository, at master and at v6.3.4, resolves, and nothing on the new pages is HTML that could be stripped. The one finding, a link to Sigstore's cosign on GitHub from Installing hMailServer, is that project's own page and predates this change.

    Christopher Holloway committed Sep 27, 2026