Skip to content

History

Revisions

  • Changes Since 6.2.10's row for work item 110 in section 4i says that one JSON document could hold a thread for seconds to minutes, as the item's CVE request says, where it said for minutes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Nov 2, 2026
    a3a244d
  • Security Policy's paragraph on 6.3.8 under What gets a release says that its fixes but work item 100's were pushed with the batch the release was made from on 1 November 2026, about a day and seven hours before it was published, where it said, as SECURITY.md at the tag v6.3.8 says, about half a day. SECURITY.md was written for a release published on 1 November 2026, the day the stamp expected; the batch was pushed at about 07:14 UTC that day (merge request !33) and the release published at 14:39 UTC on 2 November 2026. The header names this beside the date of the latest release as the copy's two departures from the document, each following from the day of the release. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Nov 2, 2026
    ceee1ff
  • Every page's header says whether 6.3.8 is reflected in it, and none calls 6.3.7 the latest release, where forty-eight pages still did; the own pages' passages that named "the release after 6.3.7" for what it would bring name 6.3.8, which brought it. The guide and reference pages whose headers said that 6.3.7, the latest release (17 October 2026, schema 6108), was not yet reflected say that 6.3.7 and 6.3.8, the latest release (2 November 2026, schema 6108), are not: thirty-eight of them, ten of which also name 6.3.5 and 6.3.6 so. Backup and Restore keeps its exception, the release a failed full restore is made again on, and the Settings Reference that its keys were last re-checked at v6.3.6, its section on the settings store calling 6.3.8 the current release. Capabilities and Configuration reflects 6.3.8 in its version stamp (6.3.8, build 47, at the tag v6.3.8), its list of published releases, the schema each release requires, the releases the release jobs have made and what applies a new installation's secure defaults in a container, and its header says so. Encryption and Certificates' note in When it renews on a host added to AcmeDomains (work item 98), Migration's refusal of the original's 5.7 and the Ports Reference's sentence on the secure defaults of a container's new installation name 6.3.8 where they said the release after 6.3.7, and each header says that this is what of 6.3.8 it reflects. Version History to 6.2.10 says that what came after it, up to 6.3.8, is in Changes Since 6.2.10. The Project Handbook's status note says that 6.3.7 was the first of the security releases and 6.3.8 the second, and sections 8 and 9 that the release jobs made 6.3.8 on 2 November 2026, and the note that these are brought to 6.3.8 and the rest of the page to neither. The headers of eight copies - the Assurance Case, Contributing, Governance, Regulatory Scope, Release Process, Security Policy, The Update Feed and Third-Party Binaries - say in their sentence of 19 October 2026 that 6.3.7 was then the latest release. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Nov 2, 2026
    75cfcfc
  • The release record and the pages on upgrading and installing say what 6.3.8 is - build 47 at schema 6108, which it leaves as 6.3.6 and 6.3.7 have it, a security release cut from master with the finished work it held, tagged on 2 November 2026 and published that day at 14:39 UTC at the group's path, the same sixty-two files and the provenance also as one line of JSON, 161 links - and how each kind of server reaches it, and Home, the footer, the sidebar and the Glossary name it as the latest release, where they named 6.3.7. Changes Since 6.2.10: the timeline's row for 6.3.8, 6.3.7's no longer marked the latest, with the tag pipeline's gates (windows-gate on bench150, 2,869 tests, 2,807 passed, 0 failed, 62 skipped; windows-gate-s1vm on S1-WINBENCH, 1,700 tests, 1,682 passed, 0 failed, 18 skipped; linux-suite, 2,749 tests, 2,374 passed, 0 failed, 375 skipped) and the installer smoke test (an upgrade from 6.3.7, 105 checks, and a new installation, 65, none failed); the picture's 6.3.8; 6.3.8's stamp, the CHANGELOG's heading giving 2026-11-01, the day the release was expected to be published; section 2's 6.3.8 adding no step; and a section 4i for 6.3.8 - the files and their bundles (161 links), the x64 installer's SHA-256, the container image and its tags, its two start tests beside PostgreSQL and MariaDB, the published Helm chart started after the release, who installs the release by the live update, the flaws fixed, each with its work item and "CVE requested", no identifier having been assigned on 2 November 2026, the advisory of work item 103, the hardening beside them, the three requests from outside, the twenty-nine items of "What changes on upgrade without a switch" in the CHANGELOG's numbering, and what else 6.3.8 carries and its known issues; section 5's heading points at it, and the CHANGELOG pointer names 6.3.8's section. 4i says when the fixes were public: work item 100's from 19 and 20 October 2026, the others from the batch's push on 1 November 2026 at about 07:14 UTC (merge request !33), about a day and seven hours before the release. Upgrading hMailServer: 18.1 gives 6.3.8's schema, 6108; the path's chart and table gain 6.3.8; 18.2 and its table say that 6.3.8's installer refuses the original's 5.7, where they said the release after 6.3.7; 18.4's download, its check and the version About shows are 6.3.8's; a section 18.4g for upgrading to 6.3.8, from the release notes' Before you upgrade and Upgrading (the backup and no schema step; the live update's routes from 6.3.6 and 6.3.7, from 6.3.4 and 6.3.5 and from older versions; the three leftover trust settings; the install by hand; the container; a Helm release of the 6.3.6 or 6.3.7 chart; what may need doing before the upgrade; the .NET 10 runtime); and 18.7 names 6.3.8 among the releases the three leftover settings refuse. Home: the latest release, the refusal of the original's 5.7, the live update, and the Current release, Database schema, Platform and Regression suite rows and the Changes Since 6.2.10 row. Installing hMailServer: the download, its check (with the provenance's .jsonl) and the refusal of the original's 5.7, which it said the release after 6.3.7 would make. Installing on Linux: 6.3.8's files and schema, the update applied by the helper of 6.3.6 or 6.3.7, and the image's MariaDB client. Before You Install: 6.3.8's files, and the image reaching MariaDB from 6.3.8. Running in a Container: 6.3.8's image, its tags on Docker Hub copied by the registry-mirror job on 2 November 2026, the MariaDB client, the entrypoint that applies a new installation's secure defaults itself, the chart that starts a server - installed from the Helm repository on 2 November 2026, with a release of 6.3.7's chart Ready after the move - and Artifact Hub's listing at 6.3.8, where the page said each of these would come with the release after 6.3.7. Each page's header says it was brought up on 2 November 2026 to 6.3.8 for what 6.3.8 changes on it, or what of 6.3.8 is not yet reflected. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Nov 2, 2026
    e814bcd
  • The twenty-four pages that copy a repository document are brought to the documents as the tag v6.3.8 (3a2fc29b7), the release of 2 November 2026, has them, each keeping what this wiki adds of its own, and each header says so and what 6.3.8 changes in it, where they named the commits of batch50 to batch55, or the tag v6.3.7, they were last made from. Re-copied from the tag, the eleven whose documents changed since: Command Line (CommandLine.md: from 6.3.8 the image's entrypoint makes the REST listener's pair at a new installation's first start), Contributing (CONTRIBUTING.md: the latest release, the checkers check-com-abi.py, check-mysql-plugin-folder.py and check-openssl-file-names.py, build/test-proxmox-install.sh, string-format-tests under AddressSanitizer, GitLab's secret push protection), Database TLS (DatabaseTls.md: verify-full to this machine without TlsCaFile refused, the CA file's name handed to the client or refused, the file names handed to OpenSSL on Windows, HM7534 to HM7537), Event Scripts (EventScripts.md: OnIMAPMessageMoved, work item 109), Regression Test Environment (the two clamd variables), Release Process (RELEASE.md: the smoke test a step by hand, 6.3.8's paragraph under A security release during the pause, step 15's COM baseline), Relocating an Installation (the API key store named by its function; HM7536 under a new tree), Secure Defaults (the image's entrypoint secures a new installation), Security Policy (SECURITY.md: the latest release, 6.3.8's paragraph under What gets a release, GitLab's security policies and secret push protection), The Service Account (ServiceAccount.md: what setup does before the files, the four narrower cases of work item 78) and Third-Party Binaries (the plugin folder, HM7537; which configurations reached CVE-2026-107819 before 6.3.8). The other thirteen documents are the same at the tag, and each header says so: Architecture, the Assurance Case, Diagnosing Stalled Mail, Fuzzing, Governance, the High Availability Runbook, Migrating the Database Backend, Regulatory Scope, Secrets at Rest, The SNMP Agent, The Update Feed, the Upgrading Guide and Warm Standby. Every link of a copy's text to a repository file that pointed at a commit or at v6.3.7 points at it as v6.3.8 has it, each file being there at the tag; a link to a document the wiki copies is a wiki link, and the links to master and those in the headers' earlier sentences are as they were. Contributing and Security Policy say that 6.3.8 was published on 2 November 2026, the day it was, where the documents at the tag say 1 November 2026, the day it was expected to be published, and their headers name that as the one departure. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Nov 2, 2026
    cbba63e
  • Four of this wiki's own pages say what UpdateFeed.md, README.md, Acme.md, ContainerImage.md and the CHANGELOG say with batch55 on master, 36bd59faa, where they still said what batch55 corrects or what its chart and Compose file changed. Upgrading hMailServer's 18.4c says that a server from 6.2.28 to 6.3.3 pointed at the feed sees the newest release, and that its live update still installs nothing, the feed offering it only the newest release, which it cannot install, and the server downloading only the installer its check found, so that even the re-hosted releases up to 6.3.3, which verify against its signer, are installed by hand, where it said that such a server saw 6.3.4 and could install the re-hosted releases up to 6.3.3 by its live update; and that the releases after 6.3.4 are signed by the project's GitLab CI, which a 6.3.4 server's live update trusts, every release from 6.3.5 having been signed there, where it said that they were to be signed there and that none had been yet. Encryption and Certificates' 9.1 says that the ACME client loads a new certificate by a reinitialise of the server, the listeners restarting for a few seconds and the sessions in flight cut unless ShutdownDrainSeconds gives them a window, the service itself not restarting, where it said that it reloaded the certificate with no restart. Profiles and Environment's note on the container is headed as not run in a container at 6.3.4 and says, in the past, what had been run then, that the tag pipelines of 6.3.6 and 6.3.7 have run the verb in a container since, starting each pushed image through the entrypoint with the REST listener given through the environment, and that on 23 October 2026 docker compose up and helm install of the chart were run as a user runs them, against 6.3.7's published image, where it said in the present that the entrypoint, the chart and the Compose file had been read and not executed. Running in a Container's note on the chart gives helm install from the project's chart repository as the way to install with the values below from the release after 6.3.7, where it gave it with no release while the same note says that the charts the repository serves, 6.3.6's and 6.3.7's, start no server; and the paragraph on how the chart is checked says that CI lints and renders it and has never installed it, that since 26 October 2026 chart-and-compose also holds the rendered StatefulSet to the pod's user and group, 999:999, to the init container and to the new installation secured before the server, and the resolved Compose file to its command and to the REST listener's pair, and that the first installs into a cluster, by hand on 23 October 2026, found that the charts of 6.3.6 and 6.3.7 start no server, where it said that the chart was proven in CI. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 26, 2026
    a06f090
  • 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
    2bae0f5
  • Seven of this wiki's own pages say what ContainerImage.md, the chart's README, SecureDefaults.md, Acme.md, Channels.md, PackageManagers.md and the CHANGELOG say with batch55 on master, 36bd59faa, of the Helm chart and the Compose file, of ACME, of the build services' installs and of the coverage job. Running in a Container's note on the chart says that the charts the Helm repository serves, 6.3.6's and 6.3.7's, start no server - their pod stops at CreateContainerConfigError, the image naming its user, and given the user by number at a configuration file the empty volume hides, nor do they secure a new installation - that the chart in the tree, on master since 26 October 2026, runs the pod as 999:999, fills the new volumes in an init container and secures the new installation before the server, that the release after 6.3.7 is the first to serve it and until then the chart of a checkout starts the published image, as both were installed on 23 October 2026, and how a release of the published charts is moved, helm upgrade --reset-then-reuse-values and then kubectl delete pod, where it gave the repository's chart as the way to install with the values below; the paragraph on the secure defaults says that the image alone does not apply them, that from the release after 6.3.7 the Compose file and the Helm chart run --apply-new-install-defaults --if-marked before the server and the charts of 6.3.6 and 6.3.7 do not, and that anything else is secured by hand, where it said that a container never applied them by itself; the Compose note says that the tree's file differs from the page's example in three ways, its command securing the new installation and its REST listener taking the pair that makes, and that a key of one's own in ./certs must be readable by the image's user, 999, where it said two ways and that the file mounted the REST certificate and key in; the note headed Not yet run in a container is headed as run as a user runs it on 23 October 2026 and says what was run, keeping what the repository said at 6.3.4; and How the image is built and proven says that from the next release's tag pipeline the start test also asks each image whether its update check knows it runs in a container. Home's Platform row and the passages of Capabilities and Configuration and of the Ports Reference on a new installation's defaults say the same of the chart and the Compose file, where Home named a Helm chart among the platforms without that and the other two said that the container ran the step by hand. Encryption and Certificates, under When it renews, says that from the release after 6.3.7 a certificate that does not name every host AcmeDomains lists is due at once and a save of AcmeDomains starts the check, where up to 6.3.7 a host added waited for the renewal, and names the ways to ask for a check and read its state - POST /api/v1/acme/run and GET /api/v1/acme, Utilities.RunAcmeCheck and Utilities.GetAcmeStatus, Check now on the Control Deck's Certificates page - with the spacing every check keeps and the names left out of the order. Installing on Linux's paragraph on the build services says to import OBS's repository key only once gpg shows its fingerprint, BA0868309CFBD36498CE41D22F0B9419E67EE770, and that on 23 October 2026 6.3.7 was installed from OBS, Copr and the PPA as a user installs it and the server started, where it gave zypper addrepo and zypper install alone. The Assurance Case's table of residual risks, this wiki's own, gives the linux-coverage job's first run on GitLab, 57.58% of the lines and 46.10% of the branches in pipeline 2983513656 on 24 October 2026, and the page's header says so. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 26, 2026
    2977ae5
  • 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
    94b073d
  • 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
    eeb8c12
  • Changes Since 6.2.10 and Security Hardening, this wiki's own pages, say what the CHANGELOG, ForkAndOriginal.md and PackageManagers.md say with batch54 on master, 9336fdd59, and what the published CVE records say. Changes Since 6.2.10's timeline row for 6.3.7 calls the fix of CVE-2026-107567, CVE-2026-107568, CVE-2026-107566, CVE-2026-114478 and CVE-2026-114474 mail sent, and signed, in the name of a hosted domain, as the CHANGELOG's 6.3.7 section heads it, where it said mail signed in that name, and gives a REST request a browser made from another site (CVE-2026-114470) and the ACME challenge responder (CVE-2026-114472) places of their own, where 3552b06 put them under what a credential confined to named domains may change, which describes neither: that label now names CVE-2026-114489, CVE-2026-114490, CVE-2026-114476, CVE-2026-114475 and CVE-2026-114477, and ForkAndOriginal.md, which gives each identifier a row of its own, groups none of them. Its 6.3.4 entry on the winget and Chocolatey manifests is headed Listed in Chocolatey's community repository since 23 October 2026; not yet in winget's, where 3552b06 headed it In the public repositories, which is not so of winget, to which nothing has been submitted (PackageManagers.md, "winget: not submitted"), and a semicolon parts the moderator's request of 21 October 2026 from the second sending, where a comma ran the two sentences together. The Affected cells of its tables of what 6.3.6 and 6.3.7 fixed give the versions ForkAndOriginal.md gives, which the records read from the CVE Services API on 24 October 2026 give too, CVE-2026-114490's platform by naming the COM administration API: CVE-2026-103010 Windows, every version up to 6.3.3, where it said every version up to 6.3.3, which took in the Linux builds of 6.3.0 to 6.3.3, its record naming 6.0.0 through 6.3.3 on Windows and the COM method Utilities.BlowfishDecrypt; CVE-2026-104659 every version up to 6.3.5; CVE-2026-114478 and CVE-2026-114474, CVE-2026-114470, CVE-2026-114472 and CVE-2026-114471 every version; CVE-2026-114489 every version, CVE-2026-114475 from 6.3.4 and CVE-2026-114477 from 6.2.25; and CVE-2026-114490 and CVE-2026-114476 from 6.3.4, CVE-2026-114490 on Windows - where each of those seven rows said earlier versions. The page's header says so. Security Hardening's 17.11 says that CVE-2026-100741 was published on 27 September 2026, where it said that it was marked for publication: its record's state is PUBLISHED, published at 07:12 UTC that day, and Roadmap3.md says that it was requested and published. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 24, 2026
    74c919b
  • Installing hMailServer and Changes Since 6.2.10, this wiki's own pages, say what the documents say with batch54 on master, 9336fdd59, of the Chocolatey package and of 6.3.7's CVE identifiers. Installing hMailServer's paragraph on the package managers is headed choco since 23 October 2026; winget not yet, where it said that neither was usable yet, and says that the chocolatey-publish job sent 6.3.7 a third time on 23 October 2026, with the credit of the original hMailServer's author, Martin Knafve, and that a moderator approved it at 11:56 UTC that day, so that the community repository's feed lists it as Approved and choco install hmailserver-progressiverobot installs 6.3.7 from the release's signed installer, every new version waiting for a moderator the same way, as PackageManagers.md and Channels.md say, where it said that the feed listed it as Submitted and that it would install once a moderator had passed it; that until winget works the installer is downloaded or installed with Chocolatey, where it said downloaded; and that the Chocolatey package passes /LOG and that Chocolatey's CLI makes setup's TEMP its cache folder, by default the chocolatey folder in the temporary folder of the account that ran choco, so that the log and the file with the refusal's words that setup from the release after 6.3.7 writes are there, as Upgrading.md and PackageManagers.md now say. Changes Since 6.2.10's 6.3.4 entry on the winget and Chocolatey manifests says the same of the third sending and the approval, where it said that the feed listed the package as Submitted, not approved, and is headed In the public repositories, where it said Not in the public repositories yet. Its timeline's row for 6.3.7 gives each fix it names the CVE identifiers the CHANGELOG's 6.3.7 section and ForkAndOriginal.md give it - mail signed in the name of a hosted domain CVE-2026-114478 and CVE-2026-114474 besides its three, what a credential confined to named domains may change CVE-2026-114489, CVE-2026-114490, CVE-2026-114476, CVE-2026-114475, CVE-2026-114470, CVE-2026-114477 and CVE-2026-114472, the anti-virus strip action CVE-2026-114479, SRS CVE-2026-114473 and the SMTP log CVE-2026-114471 - where it gave those four fixes none, and the page's header says that the row was given them on 24 October 2026. The identifiers of the page's tables of what 6.3.6 and 6.3.7 fixed already agree with the CHANGELOG and ForkAndOriginal.md, and are unchanged. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

    Christopher Holloway committed Oct 24, 2026
    5eceb73
  • The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that a Chocolatey moderator approved hmailserver-progressiverobot 6.3.7, the package sent a third time on 23 October 2026 with the credit of the original hMailServer's author, Martin Knafve, at 11:56 UTC that day, so that choco install hmailserver-progressiverobot installs it, where it said that the community repository's feed listed it as Submitted, waiting for a moderator: the feed now gives PackageStatus Approved (PackageApprovedDate 2026-10-23T11:56:26, its virus scan NotFlagged), and on a clean Windows Server 2025 that afternoon choco install downloaded the release's installer (its SHA-256 the release's, its Authenticode signature Valid), installed 6.3.7 with the service running, and choco uninstall removed it. The page's header says so. Nothing else on the page changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 23, 2026
    efcbefb
  • The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that chocolatey-publish sent hmailserver-progressiverobot 6.3.7 a third time on 23 October 2026, with the credit of the original hMailServer's author, Martin Knafve, that the moderator asked for, and that the community repository's feed lists it as Submitted, waiting for a moderator, where it said that the 22 October package, still without that credit, was Submitted and not approved: chocolatey-publish (job 17399248551, in master's pipeline 2978723670) pushed it at 00:59 UTC that day, and the feed, read at 02:44 UTC, gives PackageStatus Submitted, PackageSubmittedStatus Updated, validation and verification Passing, and the authors "Christopher Holloway, Progressive Robot Ltd (the fork), Martin Knafve (the original hMailServer)". The page's header says so. Nothing else on the page changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 23, 2026
    b30774d
  • Changes Since 6.2.10, this wiki's own page, gives each flaw of its tables of what 6.3.6 and 6.3.7 fixed its CVE identifier, where twenty-four rows said CVE requested and each table said that such a request was still queued when the page was written: GitLab's CNA assigned and published the sixteen identifiers of 6.3.6's work items 62 to 77 on 8 October 2026 (CVE-2026-107572 to CVE-2026-107587) and the twelve of 6.3.7's work items 86 to 97 on 21 October 2026 (CVE-2026-114470 to CVE-2026-114479, CVE-2026-114489 and CVE-2026-114490), as each published record at cve.org gives them, each record naming its own work item; a row that names several work items names their identifiers in its work items' order. Each table's sentence on queued requests now says when the identifiers were assigned, and the page's header says that the identifiers were added on 23 October 2026. Nothing else on the page changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 23, 2026
    c4a99fc
  • Installing hMailServer and Running in a Container, this wiki's own pages, say what the installer's code, the chart and the documents say with batch53 on master, 6fb8164c6, where 3770baf left them saying otherwise. Installing hMailServer's row for the refusal of an installation of the original hMailServer's 5.7, in the table of what setup checks before it shows anything, says that from the release after 6.3.7 setup refuses an earlier installation whose hMailServer.exe is before 6 when the running service answers a database past schema 5708 and before 6001, or, where the service is not running or does not answer, when its DBScripts folder holds the original's own upgrade scripts past 5708 (Upgrade5708to5709*.sql), unless the settings file the installed server reads keeps the database's password as only this fork does (PasswordEncryption 6), a database of this fork's own, which setup does not refuse; and that a refusal by the scripts also says that the database's version could not be read and that a database at 5708 or older, or this fork's own, is upgraded once the service runs and setup is run again, as OriginalHMailServerKind and OriginalHMailServerMessage in hmailserver/installation/OriginalHMailServer.iss and Upgrading.md's Where you can upgrade from have it, where the row said that, with the service's answer unread, the installed server's settings file and the original's scripts showed the database past 5708 and before 6001, a version they do not show. Its section 4.5, Unattended install, says in the row for /adminpassword that with /LOG the setup log records setup's command line, the switch with it, as README.md and PackageManagers.md say since batch53, and its example sets HM_ADMIN_PASSWORD in the elevated prompt and passes no /adminpassword, where it passed /adminpassword=<password> beside /LOG, which put the administrator password in the setup log. Running in a Container's row for the chart's database values says that the chart of 6.3.7 and earlier passes database.port, whose default is 5432, whatever database.type is, so that, told MySQL, it needs database.port: 3306, as templates/statefulset.yaml and values.yaml of the chart at the tags v6.3.4 to v6.3.7 and CHANGELOG.md's Unreleased entry on the chart have it, where it said that that chart passes 5432 whatever the type, as though it could not be given another port. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    d311b08
  • The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that chocolatey-publish sent 6.3.7 again on 22 October 2026, still without the credit the moderator asked for, which the community repository's feed lists as Submitted, not approved, as hmailserver/docs/PackageManagers.md and Channels.md say with batch53 on master, 6fb8164c6, where 2c7abc8 left it saying that the package of 22 October waited for moderation: the documents say that its automated verification failed at 01:44 UTC that day, the verifier's download of it from Chocolatey's own feed having timed out, that its page again shows "Waiting for Maintainer to take corrective action", and that another press of chocolatey-release in master's pipeline sends 6.3.7 a third time, with the credit, once the templates' credit is on master. Installing hMailServer and Changes Since 6.2.10 already say it in the documents' words. The header's sentence on the note says the same, where it said only that the job sent 6.3.7 again, still without that credit. The feed, read at 23:43 UTC on 22 October 2026, gives the package of 22 October 2026 with PackageStatus Submitted, PackageSubmittedStatus Waiting and IsApproved false, its validation passing and its verification failing. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    f62c221
  • Eight of this wiki's own pages say what the documents say with batch53 on master, 6fb8164c6, of the container image and MariaDB, of the installer and the original hMailServer's 5.7, and of the Chocolatey package. Running in a Container says that the image carries libpq and, from the release after 6.3.7, MariaDB Connector/C, which the server opens when HM_DB_TYPE is MySQL, and that 6.3.7's image and the ones before it carry libpq alone, reach PostgreSQL only and, told HM_DB_TYPE=MySQL, stop at the entrypoint's --create-database, as ContainerImage.md says, where it said only to point the image at a PostgreSQL or MariaDB server; its row for HM_DB_TYPE and its row for the chart's database values say the same, the latter also that the chart from the release after 6.3.7 passes database.port only when it is set, the type's own port otherwise, and that the chart of 6.3.7 and earlier passes 5432 whatever the type, as the chart's README and values say; and How the image is built and proven says that the image jobs of a v* tag's pipeline made 6.3.6's and 6.3.7's images and that container-image-start and container-image-start-arm64 start each pushed image beside PostgreSQL alone up to 6.3.7 and, from the next release's tag pipeline, beside PostgreSQL and beside MariaDB, where it said that the smoke test had no replacement yet. Before You Install says that a container image reaches MariaDB from the release after 6.3.7, and Installing on Linux that the image installs libmariadb3 itself from that release, as the packaging README says. Upgrading hMailServer's 18.2, after its flowchart and in its table's row for the original's 5.7 builds of August and September 2026, Installing hMailServer, Home's download line and Migration's row for a server of the original's 5.7 say that from the release after 6.3.7 the installer refuses an installation of the original's 5.7 before it changes anything and that the installers of 6.3.7 and earlier do not look and must not be run over one, as Upgrading.md, ForkAndOriginal.md, Migration.md and README.md say, where Upgrading hMailServer said only that setup replaced the program files before DBUpdater stopped and not to run this fork's installer over one, and the other three said nothing of a refusal. Upgrading hMailServer also says that over an installation that the original's 5.7.0 build 3013 or later made new, setup up to 6.3.7 takes it for a new installation and sets up a new, empty database beside the original's, and Installing hMailServer's table of what setup checks before it shows anything has the refusal as a row of its own, with its exit code 1, its log line and its file in %TEMP%. Installing hMailServer and Changes Since 6.2.10's 6.3.4 entry on the winget and Chocolatey manifests say that a moderator returned the Chocolatey package of 20 October 2026 on 21 October, asking that its authors also credit the original hMailServer's author, Martin Knafve, and that chocolatey-publish sent 6.3.7 again on 22 October 2026, saying that it is the fork but not yet crediting him, which the community repository's feed lists as Submitted, as PackageManagers.md says, where they said that the package of 20 October waited for moderation. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

    Christopher Holloway committed Oct 22, 2026
    2c7abc8
  • Contributing's header says that with batch52 the row for check-package-manifests.py names the checks of the release's date and of the fork's texts, neither of which the row named before, where it said that before batch52 the checker checked the manifests against their schemas alone - CONTRIBUTING.md at 5e49abf06 already had the row name the installer URL's check in the package registry, and the checker's own docstring lists what it checks beyond the schemas; and What hMailServer Is and Is Not's header says that 6.3.5, 6.3.6 and 6.3.7 are not yet reflected on the page but for the Linux packages each carries, which its table of what you provide gives since 22 October 2026 (f5db2bb), where it said that none of the three was reflected. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    2d954d5
  • The Runbooks Digest's heading over its table of migration routes, this wiki's own, is The migration routes, and what each keeps, where it was The five migration routes, and what each keeps: since 988cfbb the table has six rows - from another IMAP server, from mbox files, from a Maildir, from Outlook, from the original hMailServer up to 5.6 and from the original hMailServer 5.7 - its one row for the upstream hMailServer having become two, as Migration.md's table and its From the original hMailServer give the original up to 5.6 in place and its 5.7 releases by a migration of kind imap with batch52 on master, 72be22b4e. The heading gives no count: Migration.md gives none, and its own table has routes this one does not, the migration jobs and PST import among them. No page of the wiki and no file of the repository at 72be22b4e links to the heading's old anchor. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    505b659
  • Home's page index and What hMailServer Is and Is Not's table of what you provide say that the Linux packages are for x86-64 and AArch64, where they said that AArch64 had 6.3.3's alone. Home's row Run hMailServer on Linux says on x86-64 or AArch64, where it said on x86-64, and on AArch64 with 6.3.3's packages; its row for Installing on Linux says that the page covers the .deb and the .rpm for x86-64 and AArch64, each supported distribution release's own package and both AppImages, 6.3.4 and 6.3.5 having carried the x86-64 .deb and .rpm only, and the build services that carry 6.3.7, where it said the .deb and the .rpm for x86-64, and up to 6.3.3 for AArch64 and as an AppImage. Both rows came in with c368a3e on 26 September 2026, for 6.3.4, when 6.3.3 was the last release with AArch64 packages and AppImages; the second said of the AppImages what hmailserver/docs/PackageManagers.md said until batch52, that no release after 6.3.3 carried them, and with batch52 on master, 72be22b4e, the document says that they were attached to 6.3.0 to 6.3.3 and again from 6.3.6, but not to 6.3.4 or 6.3.5, as the same page's Platform row and Installing on Linux say of the AArch64 packages and the AppImages. What hMailServer Is and Is Not's row for the machine says that 6.3.4 and 6.3.5 carried x86-64 packages only and that 6.3.6 and 6.3.7 carry the AArch64 ones again, where it said that 6.3.4's packages were x86-64 only and that the AArch64 packages were 6.3.3's. The releases on GitLab, read on 22 October 2026, agree: v6.3.4 and v6.3.5 have an amd64 .deb and an x86_64 .rpm as their only Linux files, and v6.3.6 and v6.3.7 have the arm64 .deb, the aarch64 .rpm, each distribution release's packages for both architectures and both AppImages. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    f5db2bb
  • The Command Line page's note above its header, this wiki's own, says that both command-line clients have been published since 21 October 2026, at 6.3.7 - hmailserver-cli on PyPI, installed with pipx install hmailserver-cli, and the HmailServer module on the PowerShell Gallery, installed with Install-PSResource HmailServer on PowerShell 7.4 and later or Install-Module HmailServer on Windows PowerShell 5.1 - and that both can also be taken from the repository, as hmailserver/docs/CommandLinePackages.md says with batch52 on master, 72be22b4e, where the note said that on Windows they were to be taken from the repository, which is what that document said until batch52, when neither was published: hmctl came with the .deb and the .rpm, and the module was the file in the tree. The Windows installer still carries neither client: its scripts take nothing from hmailserver/source/Tools/Cli. PyPI's JSON for hmailserver-cli, read on 22 October 2026, gives 6.3.7 alone, its wheel and its sdist uploaded at 00:30 UTC on 21 October 2026, and the PowerShell Gallery's feed gives HmailServer 6.3.7, published at 01:26 UTC that day under the owner progressiverobot, as its latest version. The header says that CommandLine.md is the same at 72be22b4e, so that the copy stays as it was, and what the note now says. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    9f17aef
  • Five of this wiki's own pages say what the documents say with batch52 on master, 72be22b4e, where 22057dd or 988cfbb left them saying otherwise. Upgrading hMailServer's 18.2, after its flowchart and in its table's row for the original's 5.7 builds of August and September 2026, says to install this server on another machine, make the domains and accounts there first and move each mailbox's mail with a migration of kind imap from the original server, a Windows machine holding one of the two since both installers register as hMailServer_is1, as Migration.md's From the original hMailServer and ForkAndOriginal.md say, where it said to set this server up beside it and move the mail over IMAP, which on one Windows machine would have had this fork's installer take the original's installation for its own. Changes Since 6.2.10's 6.3.4 entry on the winget and Chocolatey manifests says that winget's first submission is made by hand and has not been made yet and that Chocolatey's was made by the chocolatey-publish job, which pushed hmailserver-progressiverobot 6.3.7 on 20 October 2026, where it waits for moderation, as PackageManagers.md says, where it said that the first submission to both was by hand; and that the GitHub workflow package-managers.yml was to render and check the manifests on every release, but arrived on 15 September 2026, after the v6.3.3 tag, so that no release ran it, and was not ported to GitLab, where it said that a workflow renders and checks them on every release. The Runbooks Digest's section 6a, on Migration.md, says in What it covers and in Routes (verified) that the original hMailServer moves in place up to 5.6 and its 5.7 releases by a migration of kind imap, with the domains and accounts made here first, as the document says since 21 October 2026 and as the page's own table of routes already said, where both said the upstream hMailServer in place. What hMailServer Is and Is Not's About this fork and Version History to 6.2.10's lineage, in its text and its drawing, no longer say that the original went quiet for years, which README.md no longer says since batch52, the original being developed again; the lineage names the original as Martin Knafve's and says, as README.md does, that it has since resumed development separately. The Contributing copy keeps the clause, CONTRIBUTING.md at 72be22b4e still having it. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    95c0122
  • The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that winget's half of the step is done by hand and nothing has been submitted there yet, the project's submissions being paused, and that Chocolatey's is done in a master pipeline by chocolatey-release, started by hand, and chocolatey-publish, which verify the release's installer, render the package from it and push it, and which pushed hmailserver-progressiverobot 6.3.7 on 20 October 2026, where it waits for moderation, as hmailserver/docs/PackageManagers.md says with batch52 on master, 72be22b4e, where the note said that both halves of the step were done by hand; the community repository's feed, read on 22 October 2026, still gives that version as Submitted and not approved. The drawing The release at a glance, this wiki's own too, has at step 13 winget by hand and Chocolatey by its CI job, where it had by hand since the GitHub workflow, and the header says what both now say. RELEASE.md's own text at 72be22b4e - the history at the head of step 13, and item 7 of The release on GitLab - which still says that the package managers are done by hand, stays as the document has it, the page being its copy. Contributing's link to hmailserver/docs/Licenses, under Governance, conduct and licence, points at the folder as 72be22b4e has it, where ea3795b, which moved every other link of the copy to a repository file, left it at 5e49abf06, a tree link among blob links; the header's sentence that the document's links point at the documents as 72be22b4e has them now holds for every one of them. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 22, 2026
    ec575fc
  • Nine of this wiki's own pages say what the documents say with batch52 on master, 72be22b4e, of the fork and the original, of the channels and of the container image's copies, where they said otherwise. Home says that the wiki documents Progressive Robot's fork of hMailServer, not the original hMailServer by Martin Knafve, with a link to ForkAndOriginal.md, which says how the two differ, where it called it the modernised fork, and that the installer upgrades in place every earlier release of this fork and the original up to 5.6, not the original's 5.7 releases, where it said that it upgraded any earlier hMailServer. What hMailServer Is and Is Not's About this fork says the same, that the original released 5.7.0 on 28 September 2026 and 5.7.1 and a 5.7.2 pre-release on 29 September, and that this fork is not made by Martin Knafve or the original project and is not its successor, and links ForkAndOriginal.md; its two sentences on the design rule say that an installation it upgrades behaves no differently until something is turned on, where they said that an existing hMailServer installation upgrades. Migration's table of routes has the original's 5.7, a migration of kind imap with the domains and accounts made here first, and the Runbooks Digest's table of routes has the original up to 5.6 in place and its 5.7 by that migration, where it had the upstream hMailServer in place; Upgrading hMailServer's 18.2 points at ForkAndOriginal.md. Installing hMailServer says that the Chocolatey package is hmailserver-progressiverobot, pushed by chocolatey-publish on 20 October 2026 and waiting for moderation, that choco install hmailserver finds nothing and is not this project's, the id being the original's, that winget is not submitted and that winget install hMailServer will install the original once a community packager's pull request is merged, and that both installers register as hMailServer_is1, where it said that winget install hMailServer and choco install hmailserver would work once a first submission was reviewed; Changes Since 6.2.10's 6.3.4 entry on the manifests is titled for the manifests and names both ids, where its title was those two commands. Installing on Linux says that OBS, Copr and the PPA carry 6.3.7, for which releases and with what commands, as Channels.md gives them on 21 October 2026, and that the AUR and the Snap Store have nothing yet; it and Running in a Container say that the owner made the copy on ghcr.io public on 20 October 2026 and that the image was copied to Docker Hub as docker.io/progressiverobot/hmailserver on 21 October 2026, each pulling without signing in, where they said that the copy was private and being made public. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

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

    Christopher Holloway committed Oct 22, 2026
    ea3795b
  • 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
    22057dd
  • Settings Reference's row for HM5806 since 6.3.4 names the third case IniSettingStore raises it for with batch51 on master, 5e49abf06 - for the pepper and a removal since the tag v6.3.4, for the live update's trust since 6.3.6 - which 038bade and f2290df cite it for: where the service may not write hMailServer.ini, a change only the file can hold is refused - PasswordPepper, the live update's trust set or removed without an administrator's session, or the removal of a key this build does not read while the file has its line - nothing is changed, and the sentence names the file and the account the server runs as and says what an administrator does instead (IniSettingStore::WriteSetting and RemoveSetting, IniFileSettings::InitializationFileRefusal), where the row named a write that stored the row but could not write the file and a removal that took out the line but could not delete the row, and no refusal. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

    Christopher Holloway committed Oct 21, 2026
    9856281