Skip to content

History / Fuzzing

Revisions

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

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

    Christopher Holloway committed Oct 5, 2026
  • The 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
  • Fuzzing and Contributing: the fuzz and Renovate schedules are chosen by their description, not a variable. The project refuses pipeline variables and GitLab counts a schedule's as pipeline variables, so a schedule carrying HM_PIPELINE=fuzz or RUN_RENOVATE=1 would not be saved, and a pipeline on master cannot be started by hand with one either; batch40's CI branch (ci-hyg) selects linux-fuzz and renovate by CI_PIPELINE_SCHEDULE_DESCRIPTION, `fuzz` and `renovate`. Contributing also said a v* tag's release job is a placeholder; the release jobs for 6.3.5 onwards are written and have not run. The repository's CONTRIBUTING.md still says both, and the header says this copy differs there.

    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 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
  • Fuzzing and Third-Party Binaries each say, where the section describing a GitHub workflow begins, that the workflow has not run since 18 September 2026, so a reader who lands on that section does not take the nightly fuzzing job or the binary provenance check for something that runs. Fuzzing names what still runs, the release checklist's timed run on the release source (step 8c), as SECURITY.md at master 540347500 does; Third-Party Binaries points to its header note, which says get-installer-binaries.ps1 checks the fetched files against the JSON.

    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
  • The wiki catches up with the tree after 6.3.3, and one thing the code says that no page said. Section 4e of the changes page is what is on master and in no release at all - checked line by line against the code at 916dec6a1 rather than against the commit messages, which is how three of the draft's claims came to be corrected: the Control Deck speaks twenty languages and the webmail twenty-three, so it is twenty of the webmail's languages rather than "the same twenty"; the server settings page has twenty-nine tabs, not thirty-one; and the Control Panel redesign added thirteen texts to each of the seventeen catalogues, not twenty-six. Everything else in it was verified where it could be: the 592 zone names counted out of the built-in table in ICalendar.cpp, the 501 texts counted in a Deck catalogue and the 631 in a webmail one, the eighteen dialogs counted as the classes deriving from FluentDialogWindow, the two calendar tables read out of Upgrade6040to6041, the schema step read out of DBUpdater's registration and REQUIRED_DB_VERSION, and the four new routes read out of the router rather than out of the OpenAPI prose. The gate numbers are the one thing left blank: the full Windows suite was still running on this exact tree, so the section carries a marked placeholder and section 1's master row says so, because a number invented here is a number somebody quotes. Schema 6041 is in section 2 as a row of its own, marked as in the tree and in no release, and the two places that said "6040" now say what is where. The Control Panel pages describe the program as it is now. The redesign of 15 September is in the tree and unreleased, and every paragraph about it says so, because a reader on 6.3.3 opens a window with the old chrome: the command bar with its search, status pill, theme toggle and administrator menu, the sidebar that collapses to a rail below a thousand pixels, the ten scaffold components, and eighteen dialogs sized to their content rather than to a pixel width typed into a constructor. What did not move is what a reader has learned - the navigation map, the page titles, the tab headers, the setting captions, the automation ids - and the pages say that too, which is why Control Panel Pages was not rewritten around it. Three counts were behind and are corrected from the code: 393 settings in the Ctrl+K index rather than 389, 343 captions with an Alt key rather than 340, and 3,403 texts in each catalogue rather than 3,376. Two of the four settings that moved the index shipped in 6.3.2 and the reference had missed them, so the per-page table's auto-ban and web-services rows are re-counted as well. The settings pages carry the rule adopted on 15 September: a new setting goes in the database, in hm_settings with a Control Panel editor, and no new key is added to hMailServer.ini's [Settings] section. Both pages say the part that matters more than the rule - that nothing already there has moved. The 238 keys are still read from the file, in 6.3.3 and in the tree, and the Settings Reference is still their reference; the migration that flips which store is the truth is a roadmap row, not an event. The file keeps the directories, the database connection and the administrator password and second factor, and anything that genuinely has to be readable before the database opens is an argued-for exception. The API reference gains what the server publishes and the page did not. Comparing the route table with the OpenAPI document the server emits found seventy-four paths of a hundred and forty-five unnamed, so the administration families are now all there: the six anti-spam collections and the blocked attachments as resources, an account's application passwords, folders, folder permissions and message object, all of which shipped in 6.3.3 and were nowhere on the wiki - and then the four that are in the tree and unreleased, groups with their members, the message copy, the rule-criterion probe and the calendar expansion, each with the body it takes and what it answers. The roughly forty /api/v1/me routes the webmail uses are still families rather than rows, and the page now says so in its own words and points at the OpenAPI document as the authority rather than leaving a reader to think the table is complete. Stopping Spam was left alone deliberately. The brief said SPF was being replaced this week; at this commit it is not. The evaluator is still the original one with the ten-term limit and the void-lookup cap, nothing under AntiSpam or SMTP/SPF has changed since v6.3.3, and the page describes it correctly - so the honest edit was none. The finding is on Backup and Restore, and it is the reason this pass was worth running against the code. The built-in backup's XML index is built by each business object's XMLStore. An account's record carries its password, its TOTP secret, its fetch accounts, its application passwords, its rules and its folders. Nothing anywhere writes hm_contacts, hm_accountprefs, hm_scheduled, hm_files, hm_smimekeys, hm_calendars or hm_calendarobjects - no XMLStore reads them - and Message::XMLStore writes Flags but not messagekeywords. So the address book, every webmail preference a user chose, their labels, their second and third stars, their follow-up flags, their scheduled and snoozed mail, their file links, their S/MIME keys and (in the tree) their calendars are in no archive this server writes. Worse than absent: every one of those tables cascades from hm_accounts, and a restore calls Domains::DeleteAll before it puts the backup's domains back, so a restore deletes them. The page now says it, in the short version and in a section of its own, with what to do instead - back the database up with the database server's own tool, and restore from that when recovering a whole server. No page said any of this before. Monitoring and Health was re-checked rather than rewritten: not one metric family, bucket bound, probe condition, reason string or default has moved since it was verified at 6.2.28, and the only change to MetricsServer.cpp is the Linux accept-loop stop. It gains a section on reading the server from a shell - hmctl status, log list, log tail and backup, with the routes behind them - marked as in the tree and unreleased, since a reader on 6.3.3 has neither client. Smaller corrections found while checking: the capabilities page's web-services entry predated CardDAV entirely and now carries both DAV protocols, their paths, their HTTPS-only rule and what CalDAV does not do; the installing page has a paragraph on winget and Chocolatey that says plainly they do not work yet, because a first submission is reviewed by a person; What hMailServer Is and Is Not still called 6.3.3 unreleased and said the webmail speaks twenty languages; the Control Panel reference still called 6.3.0 the current release; and the fuzzing page's "iCalendar reached through attachment handling" is now also reached by an authenticated CalDAV PUT, which is a shorter path to a parser that expands attacker-chosen numbers - the COUNT=100000000 defect fixed by hand this week is the argument for the target.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
  • Four pages catch up with what is in the tree since 6.3.3 and with what shipped in it. The client page gains a CalDAV section beside the CardDAV one, written the way the CardDAV section is: the same listener, the same discovery and the same credentials, one calendar per account at /dav/calendars/<address>/calendar/ made the first time it is asked for, VEVENT and VTODO in the one collection so a phone's calendar and its reminders are the same thing, a repeating event expanded by the server across daylight saving in any of the 592 zone names the new iCalendar module knows, and calendar-query, multiget and sync-collection with ETags. It says what is not there too, because a calendar that silently drops an invitation is worse than one that never offered: no iMIP, no free-busy, no per-calendar time zone, no partial calendar-data, and no time-range filter on an alarm. The webmail paragraph loses a label that went stale the moment 6.3.3 was published - it said "6.3.3, unreleased" of what is now the current release - and gains the twelve features that followed it, each in the reader's terms rather than the roadmap's: the page installed as an app with its unread badge, contacts in and out, saved searches as folders, the reader's own time zone, undo on three more actions, the tracker notice counting what it kept out, swipe actions and snooze presets, three stars that every IMAP client sees as keywords, rows coloured by a rule, @mentions that add the person to the recipients, a formatted signature, and Report phishing beside Junk. The container page gains the two files people expect and this repository now ships. The Compose section says that the file is in the tree, that a workflow resolves it with docker compose config on every change - so it is a file known to parse rather than an example in a document - and how it differs from the page's own shortest-thing-that-starts version: the two passwords are Compose secrets read from files, and the REST certificate is mounted in. Then a Kubernetes section: a StatefulSet of one, because a message store is not something two pods may share, the three volumes as claim templates, the database pointed at and never bundled with the chart refusing to render without a host, the two passwords as a Secret the chart makes or an existing one it is pointed at, the REST listener needing a kubernetes.io/tls Secret because off loopback the server requires TLS, a LoadBalancer with externalTrafficPolicy Local so the server sees the client's address, and probes on port 25 as the image's own health check is. It ends with how the chart is proven, since neither Helm nor Docker is on the bench that gates the code: linted, rendered with a real install's values, and checked for its two refusals, on every change. The REST page gains wave J's routes with the unreleased label: the account groups as a resource (a listing, a create, a read, a rename, a delete, and the members beneath a group as their own small collection, because a membership is a pair and not a property of either side), a message copied into another folder of its account, and the rule-criterion probe that answers what the delivery path would decide without reading or writing anything. And the fuzzing page is re-copied from the repository document it declares as its source of truth, which now carries the nightly job: the three harnesses every night on a hosted runner, the corpus kept in the Actions cache under a key that carries the run id so it grows, and the crash, hang or violated invariant that fails the job and lands the reproducer as an artifact.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
  • The wiki rewritten in depth: 141 diagrams drawn from the code, every reference page made exhaustive, and twenty-one defaults corrected that no page had ever stated The wiki was accurate after this morning's sweep and thin. This is the depth pass the owner asked for: every page read against the code again, every reference page completed, and a diagram wherever a diagram says it better than a paragraph. 141 Mermaid diagrams across 49 pages, each drawn from the handler rather than from memory: the SMTP submission sequence with the checks in the order ProtocolMAIL_ and ProtocolRCPT_ actually run them, the IMAP session state machine from the per-command authentication guards, the DMARC evaluation, the delivery pipeline and its retry arithmetic, the ACME renewal state machine, the spam decision from connection to delivery, the schema chain, the component and threading models of the whole server, the CI workflows and what each one gates, the release draft-sign-publish flow, and a map of the journeys through the wiki itself on the landing page. The reference pages are now exhaustive rather than representative: every route with its method, authentication, request and response shape and its error codes; every [Settings] key with its default, its effect and whether it needs a restart; every port with the key that opens it; every rule criterion and action; every Sieve extension the server advertises; every metric the listener exposes. Twenty-one facts were wrong or absent, and each is corrected against the code rather than adjusted. The ones that will save somebody an afternoon: IMAP SASL PLAIN and SCRAM are not advertised on a default install, which looks exactly like a client bug; SMTP AUTH PLAIN is off by default too; DMARC checking is on while SPF and DKIM as scored tests are off, and the DMARC test evaluates both itself regardless; the seeded DNSBL and SURBL servers are inactive; a new mailbox contains INBOX and nothing else, which is the real cause of the classic missing Sent folder; MTA-STS hosting and autoconfiguration default on while both web-service ports default to 0, so the shipped default is features on with nothing listening; and TLS-RPT and DMARC report sending are inert until their From address is set, with each completed day discarded unsent. Eleven screenshots are named as wanted, with what each should show. The existing images are from a 6.2.10-era build and the pages say so where it matters.

    @chrisholloway5 chrisholloway5 committed Sep 8, 2026
  • Every page read against the tree on 8 September 2026: the release and schema stamps (6.2.27, schema 6031, 2,124 tests), the routes, keys and pages that were missing, the listener paragraphs that were false, and the unreleased work labelled as such An audit of all 51 pages against master produced about 360 findings on 43 of them, applied here. The largest: the APIs reference lacked 47 routes and described the listeners as single-threaded HTTP/1.0 (they run on the Boost.Asio HTTP/1.1 server); the settings reference lacked the fourteen Update* keys and IMAPCompressionEnabled and counted 195 keys instead of 236; every "current release" stamp said 6.2.24; Changes Since 6.2.10 ended three releases and one schema step early; Architecture said the optional listeners were deliberately not Boost.Asio and built their own SSL contexts (neither is true); the upgrading pages still warned of a silent-upgrade hang fixed in 6.2.23; the Control Panel pages knew nothing of the seventeen languages, the Updates card or the stalled-mail page; and two pages did not render (a header inside a code block, CR and TAB bytes in file names). Anything in the tree but not in v6.2.27 - the live update, the self-service portal and /api/v1/me, the HttpServer listeners, IMAP COMPRESS=DEFLATE, the seventeen-language Control Panel, the Control Deck views - is documented and marked "in the tree after 6.2.27, not yet released". The Control Panel screenshots are still from a 6.2.10 build and the pages now say so.

    @chrisholloway5 chrisholloway5 committed Sep 8, 2026
  • Settings and Control Panel reference: the authenticated-sender check, Send-As and the outbound pipelining keys

    @chrisholloway5 chrisholloway5 committed Sep 5, 2026
  • References regenerated for 5 September 2026: message retention, scrypt, the ClamAV connection test, tarpitting, the server-enforced administrator second factor, and the assertion build; the landing page keeps its new name

    @chrisholloway5 chrisholloway5 committed Sep 5, 2026
  • The hMailServer 6.2.24 wiki: the corrected manual, the runbooks, and the references generated from the code

    @chrisholloway5 chrisholloway5 committed Sep 4, 2026