History

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The APIs Reference's row for GET /api/v1/settings/ini and two of its Contradictions say what the route, its OpenAPI text and build/check-cli.py have done since 6.3.4, as master has them with batch51, 5e49abf06, where they still said what 6.3.3 did, and the row and the first of them say what a file the service may not write changes. The row says that the answer's names were all it carried in 6.3.3, and that since 6.3.4 settings is beside them, the same names as {name, value, secret} with a secret's value as (set), with applies, pending and environment, as the route's OpenAPI text and SettingsApply.md's row for REST say (RestApiSettings.cpp, IniList), and that the store and the file then list the same names after a start where the service may write the file, where it said that the route answers names and no values and that the two lists are the same after any start. Contradiction 12 says that the OpenAPI text described the file as the store up to 6.3.3, and that since 6.3.4 it says what the handler does, the database first and a 500 only when the database write fails, or for PasswordPepper the file's, while it still says, without the condition that the service may write the file, that the file's copy is written and an edited line put back; and that the descriptions of /api/v1/settings/ini/{name}, not the list's, still say that the route is refused for domain-restricted keys where every API key is refused with 401, where it said that the text still described the file as the store and that the GET descriptions said so. Contradiction 13 says that build/check-cli.py's recorded server and the real route disagreed up to 6.3.3, and that since 6.3.4 the route answers the settings the two clients read and the recorded server answers that shape, held to IniList by check_ini_route_shape, where it said that they still disagreed; e08f7c5f4, in v6.3.4, made both changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Six more passages of this wiki's own text, found by comparing each copy with its document as master has it from batch51, 5e49abf06, and by a further pass over the pages, say what changes where the service may not write hMailServer.ini, as ServiceAccount.md's table of the writes to hMailServer.INI says, where they said without that condition what the server writes into the file. The Upgrading Guide's paragraph on rolling back across schema 6042, under Rolling back, says that the file the newer server left is a full copy of the stored settings, which the older server reads as the truth, only where the service may write the file, and not under NT SERVICE\hMailServer or the Linux packages' hmailserver user, where the copy is as the last account that could write it left it, as Upgrading hMailServer's note in 18.6 has said since 8d8ed94; and its note on where the [Settings] values come from on a new machine says that since 6.3.4 the restored values are written into the new file at the first start where the service may write it, not under NT SERVICE\hMailServer, a new installation's account. Neither passage is Upgrading.md's, and the page's header names every passage of this wiki's own a comparison with the document finds, none of them in Upgrading.md at any point of its history, where it named five: the pointer to Upgrading hMailServer after the opening, the section What one run looks like with its flowchart and the exit codes, the bullet Not hMailServer.ini, the section on what a failed step leaves on each backend, the note that An upgrade without a window is new in 6.3.4, the installer's two refusals and the notes on the two numbers HM5011 carries and on HM5010 under If the upgrade fails, the paragraph on rolling back across schema 6042, the notes under Special cases on the [Settings] values on a new machine, on the database password and on an installation from before hMailServer 5, the notes for contributors and the corrections under Verified against the code; and it says which three of them say what a file the service may not write changes. Changes Since 6.2.10's 6.3.4 entry on the settings store says that a line still holding what the server last wrote is brought back into line where the file may be written, as its other clauses say since 8d8ed94. The Runbooks Digest says that on the same machine the line the store writes into the file, where the service may write it, is adopted by the new database at its first start, and that under NT SERVICE\hMailServer, where the store writes no line, BackupMessagesDBOnly is checked on the new database before the restore, as MigratingDatabaseBackend.md says. Settings Reference's section 4a says that the whole [Settings] section stays mirrored into the file where the service may write it, the copy not refreshed and stale for whatever reads the file itself under NT SERVICE\hMailServer, and that restoring an archive that carries a pepper into a file the service may not write says so as HM5805, for an administrator to put the value there with an elevated editor (IniSettingStore::XMLLoad). Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Three more clauses of the two rows 038bade corrects say what the code and the documents have said since 6.3.4, where they still said what 6.3.3 did. The REST API's row for the ini routes says that in 6.3.3 the list answers key names only and that since 6.3.4 it answers each with its value too, a secret's as (set), as CommandLine.md's note on the secrets among the ini keys and SettingsApply.md's row for REST say with batch51 on master, 5e49abf06 (RestApiSettings.cpp, IniList), where it said that the list answers key names only. The APIs Reference's row for /api/v1/settings/ini/{name} says that in 6.3.3 the server reads the value at its next start or POST /api/v1/server/reinitialize, and that since 6.3.4 PUT and DELETE publish the change, so that a key marked to apply now is in effect when they answer and one marked to wait answers pending true until a reinitialise or a restart takes it, as the route's OpenAPI text says, where it said that either way the server reads the value at its next start or a reinitialise; and it says that the OpenAPI text for the route has described the database as the store since 6.3.4, and that it says, without the condition that the service may write the file, that the file's copy is written and an edited line put back, where it said that the text still described the file as the store. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Ten more passages of this wiki's own text, on seven pages, say what changes where the service may not write hMailServer.ini, as ServiceAccount.md's table of the writes to hMailServer.INI says with batch51 on master, 5e49abf06, and IniSettingStore has done since the tag v6.3.4, where they said without that condition what the server writes into the file, or that an edit to it is undone, the shape of the passages the previous commit corrects. Migrating the Database Backend's own sentence on the stored settings under Rolling back says that the rolled-back server rewrites the file's [Settings] section to match where the service may write the file. Warm Standby's worked commands say that a value typed into the INI is not used once the key has a stored value, where they said it was undone. Settings Overview says that DELETE /api/v1/settings/ini/{name}, hmctl ini delete and Settings.DeleteIniSetting remove the line and the row together where the service may write the file, and that where it may not and the file has the line the line stays and the row is kept holding the key's default, which the server treats the same, or the removal is refused for PasswordPepper and a key this build does not read, and that the server adds the [SettingsStore] section where it may write the file. Settings Reference's section 4a says the same of a removal, a dropped row being put back from the line at the next start and the removal said in the application log (IniSettingStore::RemoveSetting), and that what a file the service may not write changes, which the tag v6.3.4 already has, is read from the tree at 5e49abf06, where the section named 3233b0cc4 alone, a tree from before it. Installing on Linux says that on a package installation, whose file is 0640 root:hmailserver, a value stored over the API is in effect and the line left as it was is not an error, the application log saying, where application logging is on, that the file is read-only to the account the server runs as and that its [Settings] copy is not refreshed (IniFileSettings::InitializationFileWritable, IniSettingStore::WriteSetting and Synchronize), where it said that such a value was reported as HM5806 when it was stored and as HM5803 at every start; the packaging README at 5e49abf06 still says so under What lands where, and this wiki follows the code and ServiceAccount.md, which says of the Linux packages that a setting saved is no longer an error at every start. Changes Since 6.2.10's 6.3.4 entry on the settings store and its note on the closed table say that the server writes the [SettingsStore] section where it may write the file, and Upgrading hMailServer's note on rolling back from 6.3.4 says that the newer server writes the [Settings] secrets into the file as HMK1: envelopes where it may write the file. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Six more passages of this wiki's own text, on four pages, say of a [Settings] line edited in hMailServer.ini, and of a setting saved or removed over REST, what ServiceAccount.md's table of the writes to hMailServer.INI says with batch51 on master, 5e49abf06, and IniSettingStore does: the line is put back, written back or taken out only where the service may write the file, and under NT SERVICE\hMailServer, to which the file is read-only, an edit stays in the file and is not used, a save writes the row alone and a removal of a key whose line is still in the file keeps the row holding the key's default, which the server treats the same, where they said so without the condition 8d8ed94 gave the passages around them. The Upgrading Guide's bullet Not hMailServer.ini under What the upgrade touches, this wiki's own text and not Upgrading.md's, says that an edit to the section is not used at the next start (HM5804), its line put back where the service may write the file and left as edited under NT SERVICE\hMailServer, where it said that the edit was undone, and the page's header names the bullet among this wiki's own additions and says so. Changes Since 6.2.10's note on the settings store finished at the edges says that an edit to the file is not used at the next start, and item 20 of its section 5 is headed that an edit to [Settings] is not used, where both said that the edit was undone; and its 6.3.4 entry on the settings store says that a removal takes out the line and then the row where the service may write the file, and where it may not and the file has the line keeps the row at the key's default, or refuses the removal of PasswordPepper and of a key this build does not read (IniSettingStore::RemoveSetting), where it said that the removal took out the line and the row. The APIs Reference's row for /api/v1/settings/ini/{name} says that PUT brings the file's copy into line where the service may write the file, the row alone under NT SERVICE\hMailServer, a write of the file that fails being HM5806; that DELETE removes the line and then the row where the service may write the file, the line staying and the row kept holding the key's default where it may not, and that there it is a 500 for PasswordPepper and for a key this build does not read, the reason in the error log as HM5806; that a line deleted by hand is written back where the service may write the file, the row kept either way; and that a PUT of PasswordPepper is a 500 where the service may not write the file, the reason in the error log as HM5806, as cb4f10c has Changes Since 6.2.10 and Settings Reference say of the pepper; where it said that PUT brings the copy into line, that a file that cannot be written is HM5806, that DELETE removes the line and then the row, and that the pepper is written to the file, whatever the account. The REST API's row for the ini routes says the same of PUT and DELETE, naming the Linux packages' hmailserver user beside NT SERVICE\hMailServer, where it said that both bring the file's copy into line and that a line deleted by hand is written back. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026