hMailServer 6.3.5: the first release built and signed by its GitLab pipeline, and the quarantine grouped by domain and HELO

[chris]

This release is superseded by hMailServer 6.3.6, published on 6 October 2026, which fixes security flaws in every earlier version, 6.3.5 included. Read its announcement before upgrading.

hMailServer 6.3.5 was published on 29 September 2026. It is the first release the project's GitLab CI made from its signed tag. The tag's pipeline built the Windows installer after the whole Windows suite had passed, signed it with Authenticode, signed every file of the release with Sigstore, and checked every signature with the server's own verifier before anything was published. A 6.3.4 server trusts that signer, and a 6.3.4 server has installed 6.3.5 by its own live update. The release also fixes two defects 6.3.4 has, and lets an administrator review the quarantine by the sender's domain and the HELO name. The schema moves from 6104 to 6105 in one step.

Who is affected

• Every server on 6.3.4. Two of its defects are fixed:
  • A mail flow rule with a Readable text or Sensitive content found condition, which 6.3.4 added, read a message's HTML part in time that could rise with the square of its size. 400,000 & - two million characters - held the delivery for about a minute, and on a server with such a rule anybody could send one. Each entity is now unwrapped in one pass, with the same result. A server with no such rule was not affected.
  • An invitation whose calendar part carries parameters in its Content-Type and has no .ics name - the shape Outlook sends - was never marked as an invitation, so the webmail showed no card for it. It now shows the card with Accept, Maybe and Decline.
• A server older than 6.3.4 gets everything 6.3.4 brought as well, including the fix for CVE-2026-100741. Read the 6.3.4 announcement first: all of its "Before you upgrade" applies.

Before you upgrade

• Back up the database and the data directory first. The schema goes from 6104 to 6105 in one one-way step, which adds a column to the quarantine's table, hm_quarantine.quarantinehelo. From 6.3.3 or older the upgrade runs 6.3.4's steps first, and 6.3.4's notes apply: on MySQL and MariaDB, step 6102 rebuilds every table as utf8mb4, and at the first start the [Settings] section of hMailServer.ini moves into the database.
• A server from 6.2.28 to 6.3.3 cannot install 6.3.5 by its live update. It trusts only the GitHub workflow that signed the releases up to 6.3.3, and it refuses a file the GitLab pipeline signed: "The certificate names https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v..., not this repository's release workflow." Nothing is installed and the server runs on. What to do:
  • Install 6.3.4 or 6.3.5 by hand, once. On Windows run hMailServer-6.3.5-x64.exe over the existing installation; on Linux install the .deb or the .rpm with apt or dnf. After that the server reads the new feed without being told and trusts both signers.
  • Until then, keep UpdateAutoDownload off. With it on, such a server downloads the whole installer, 84 MB, at every check and refuses it every time, since the verification comes after the download.
  • Its update check works only once it is pointed at the new feed: under [Settings] in hMailServer.ini, UpdateFeedUrl=https://updates.progressiverobot.com/releases.json, then restart the service.
  • On Windows only, there is a second way: three settings that make the old server trust the GitLab signer. They cost the rollback image, must be cleared afterwards in the Control Panel or over REST (not in the file), and must never name the group path hmailserver/hmailserver. UpdateFeed.md, "Having the live update make that upgrade anyway", gives the values and the costs. Installing by hand is simpler.

The live update from 6.3.4

A 6.3.4 server reads https://updates.progressiverobot.com without being told, and trusts the identity the GitLab pipeline signs with; that verifier is unchanged in 6.3.5. On the Control Panel's Status page: Check for updates, Download update, then Install update; or POST /api/v1/update/install over REST, or Status.InstallUpdate over COM. With UpdateAutoDownload on and an update window open, the server does it by itself.

It was tried on 29 September 2026 on a clean Windows Server 2025, against the published release and the live feed:

• A service running as LocalSystem found 6.3.5, downloaded and verified it, took its backup and installed it. The schema went from 6104 to 6105, mail was unavailable for about 24 seconds, and the domain, the account, its messages and the settings were intact. A server upgraded to 6.3.4 that kept LocalSystem runs this way.
• A service running as NT SERVICE\hMailServer does not install it itself. That is how a new 6.3.4 installation runs the service. Such a server found, downloaded and verified 6.3.5, then logged HM7463 and left the install to an administrator. Download the installer from the release, check that Get-AuthenticodeSignature says Valid, and run it as an administrator - not the copy the server downloaded, which is in a folder the service can write.
• There is no rollback image for 6.3.4. Before it installs, the server fetches and verifies the installer of the version it runs, to put it back if the new one does not start. 6.3.4 carries no Sigstore bundle, so that copy cannot be verified, and the application log says "Update: no rollback image for hMailServer 6.3.4 could be had (release 6.3.4 carries no x64 installer with a Sigstore bundle.); if 6.3.5 does not start, it will need a manual reinstall." Take the backup first.
• On Linux the live update was not part of that test. A server installed from the release's own amd64 .deb or x86-64 .rpm is offered the same file of 6.3.5. A server installed from a .deb or .rpm the CI builds for another distribution release is offered the release's file too, whose dependencies its distribution may not meet; apt or dnf then refuses it and the server stays as it was. One installed from an AArch64 package, an AppImage or the ARM64 installer is told that the release carries nothing for it to download.

The test found three defects in code 6.3.4 and 6.3.5 share, to be fixed in 6.3.6: the outcome of an update is dropped by the check that runs one second after start-up, so Status.UpdateApplyOutcome is empty though the log has it; a first check on a new machine can fail with "The response carried no HTTP headers", which hides the real cause (on the test machine, probably a slow first certificate revocation check); and a service that cannot install downloads the installer again after every restart.

What changes on upgrade without a switch

The 6.3.5 section of CHANGELOG.md lists five.

• The Control Panel's sidebar is in a new order. Welcome and Dashboard come first, then a new group, Set up this server: the Setup checklist (it was External setup, under Monitoring & troubleshooting), Setting profiles and DNS records. TLS & certificates is now Certificates & encryption, and Access & abuse protection is Sign-in & access. Connections & protocols has a new Webmail page. Ctrl+K still finds the checklist as External setup. A page's nav-<key> UI Automation id is unchanged; the navgroup- and navrail- ids of the new and renamed groups follow their new headings, so a UI test that finds a group by its old id must be changed.
• The quarantine shows the HELO name, and groups. The Control Panel's Quarantine page and the Control Deck's Quarantine view have a HELO column and group held messages by the sender's domain unless told otherwise. Messages held before the upgrade have no HELO name recorded. The Deck now asks before a delete with a Yes or No of its own whose default is No; it used the browser's confirm(), whose default is OK. It offers whitelist and blacklist only to a credential holding manage_settings, and a held message's headers and preview only to one holding view_mailbox, as the server requires.
• The webmail's keyboard. The message list is one Tab stop, and its keys reach what a row holds. Enter on a button in the mail view presses the button; it used to open the message under the list's cursor. A letter typed into the formatted signature is text, where c opened a new message. Escape closes every modal dialogue as its Cancel does. The compose window's Plain is Remove formatting.
• Invitations. GET /api/v1/me/messages/{id} answers "invitation": true for the Outlook-shaped invitation above, where it answered false.
• What a script sees. GET /api/v1/quarantine gives each message three more fields - helo, sender_domain and helo_domain - and four routes are new. Over COM, Quarantine gains Bulk and QuarantinedMessage gains HeloName, SenderDomain, HeloDomain, ReadHeaders and ReadPreview, added to the existing interfaces; no existing member or dispid changes. A program built against 6.3.5's type library that calls one of them needs a 6.3.5 server.

Also in this release

• Reviewing the quarantine: grouping by the sender's domain, by the HELO name's domain or not at all; release, delete, whitelist then release, and blacklist then delete, on one message, a group or the checked ones, with a dry run first; and a held message's headers and a plain-text preview read without releasing it. The Control Deck does the same as the Control Panel (SenderListsAndDigests.md).
• Every database setting that should have an editor has one in the Control Panel: 137 that needed one and had none, on new tabs and on the new Webmail page. 103 of them are reached over the REST API alone, which is off as shipped (RestApiPort 0); with it off, each such tab says so.
• The Control Panel and the webmail, audited in both themes, by keyboard and, for the webmail, with NVDA in English and German: contrast raised where it fell short, focus rings restored, and 82 texts that were English on a translated webmail page are now in all 23 languages.
• The packages for Debian, Ubuntu, Fedora, RHEL and openSUSE, for x86-64 and AArch64, the AppImages and both Windows installers are built on GitLab CI, on the project's own runners. Only the files listed below are in the release; the others are CI job artifacts, kept for 7 to 30 days, not signed and not offered by the update feed.
• Reproducible Linux packages: the server, the .deb and the .rpm are built a second time from a copy of the tree at another path, and the release waits until all three are byte for byte the same.

How it was checked

Every gate of the tag's pipeline passed: the Windows suite on the project's Windows runner, 3,828 tests, 3,753 passed, 0 failed, 74 skipped and 1 inconclusive; the Linux suite on the project's Linux runner, 2,213 tests, 1,892 passed, 0 failed, 321 skipped; linux-repro, which rebuilt the .deb and the .rpm byte for byte; the static analysis, Semgrep and the dependency scan. The signed installer then went through the installer smoke test on a clean Windows Server 2025: an upgrade from 6.3.4 passed 93 checks and a new installation 59, none failed.

No ARM64 Windows installer in this release

The pipeline has a job that builds the ARM64 installer, and it may fail without failing the pipeline. In 6.3.5 it fails: its toolchain check looks for Visual Studio's ARM64 C++ runtime by a path that finds it in no installation, so it stops on the Windows runner, which has the ARM64 tools, ATL and SDK libraries, and prints a command that changes nothing. The check is corrected for the next release. Even then, the ARM64 installer is a CI job artifact only, not signed and not in the release, and the ARM64 build has never been run on ARM64 hardware (WindowsOnArm.md).

What 6.3.5 does not carry

• No ARM64 Windows installer (above).
• No AArch64 .deb or .rpm, no AppImage and no SLSA provenance. The pipeline builds the AArch64 packages and the AppImages as CI job artifacts only, and the provenance generator the releases up to 6.3.3 used is GitHub's. 6.3.3's AArch64 packages and AppImages are still the newest published. 6.3.6 is to carry all three.
• No container image. registry.gitlab.com/progressiverobot/hmailserver is empty: the pipeline pushes and signs the image only once the project has moved to the group hmailserver and the owner has switched it on.
• No apt or dnf repository yet: the job that makes them publishes nothing until the repository's signing key exists (PackageManagers.md).
• Not in winget or Chocolatey yet: the first submission to each is made by hand, and has not been made.

Downloads, and how to check them

The release carries nine files, each with its Sigstore bundle, <file>.cosign.bundle, beside it:

• hMailServer-6.3.5-x64.exe, the Windows x64 installer; hmailserver_6.3.5_amd64.deb for Ubuntu 26.04 and 24.04, and hmailserver-6.3.5-1.x86_64.rpm for Fedora 43 and 44 and Enterprise Linux 10. Their dependencies are 6.3.4's: the .deb asks for glibc 2.38 or later, so it does not install on Debian 12, and the .rpm does not install on Enterprise Linux 9.
• An SBOM for each of those three, <file>.cdx.json (CycloneDX 1.6), whose subject is that file by its SHA-256 and SHA-512; and the source tree's SBOMs, hmailserver.spdx.json and hmailserver.cyclonedx.json.
• hmailserver-linux-6.3.5-SHA256SUMS.txt, the SHA-256 of the two Linux packages.

There is no SSH-signed sums file this time: the pipeline cannot hold the key that signs the release tags, so every file is signed with Sigstore instead.

https://updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hmailserver_amd64.deb and /download/hmailserver.x86_64.rpm always lead to that file of the newest stable release, never a pre-release's; add .cosign.bundle for its bundle. https://updates.progressiverobot.com/download/ leads to that release's page.

To check a download with cosign, with the file and its bundle beside you:

cosign verify-blob --bundle hMailServer-6.3.5-x64.exe.cosign.bundle \
  --certificate-identity 'https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.5' \
  --certificate-oidc-issuer https://gitlab.com hMailServer-6.3.5-x64.exe

It must succeed (exit status 0). The identity names the tag, so a file signed for another release does not pass. If your cosign has the --new-bundle-format option and does not use it by default, add it: the release's own signing job passes it wherever cosign offers it.

On Linux, a server from 6.3.4 on makes the same check its live update makes:

hmailserver --verify-update hmailserver_6.3.5_amd64.deb

with hmailserver_6.3.5_amd64.deb.cosign.bundle beside the file. It takes any file of the release; the release's pipeline ran it on every one before publishing. It answers hmailserver_6.3.5_amd64.deb verifies: signed by https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.5, recorded by the transparency log at ... and exits 0, and exits 1 for a file that does not verify. It does not check which release the file belongs to, so read the identity it prints: it must end in @refs/tags/v6.3.5.

Then:

• sha256sum -c hmailserver-linux-6.3.5-SHA256SUMS.txt must say OK for each package (add --ignore-missing when you downloaded only one).
• On Windows, Get-AuthenticodeSignature .\hMailServer-6.3.5-x64.exe must answer Valid, with a signer certificate for CN=Progressive Robot Ltd.
• In a clone, git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.5 must say Good "git" signature for [email protected].

The release's own notes, under Verification, give each file's SHA-256 and the certificate the pipeline was given. SECURITY.md, "Verifying a release" and "Software bills of materials", has the rest, including how to check that an SBOM describes your file.

Reporting a vulnerability

Not in a thread here, and not in a public issue. Report it privately, as SECURITY.md says: a confidential issue on GitLab - check that it is still marked confidential before you submit it, and choose the Security template - or an email to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue, so no GitLab account is needed.

Release notes, checksums and downloads · Newest stable release