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, so 400,000 entities held the delivery for about a minute, and on a server with such a rule anybody could send one; and 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.
- A server older than 6.3.4 gets everything 6.3.4 brought as well, including the fix for CVE-2026-100741. All of 6.3.4's "Before you upgrade" applies.
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. 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 service running as NT SERVICE\hMailServer, which is how a new 6.3.4 installation runs, 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. There is no rollback image for 6.3.4, which carries no Sigstore bundle, so if 6.3.5 did not start it would need a manual reinstall: take the backup first. The test found three defects in code 6.3.4 and 6.3.5 share, fixed in 6.3.6: the outcome of an update was dropped by the check that runs one second after start-up, a first check on a new machine could fail with "The response carried no HTTP headers", and a service that cannot install downloaded the installer again after every restart.
What changes 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 first, then a new group, Set up this server, with the Setup checklist (it was External setup), 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.
- The quarantine shows the HELO name, and groups held messages by the sender's domain unless told otherwise. Messages held before the upgrade have no HELO name recorded. The Deck asks before a delete with a Yes or No of its own whose default is No.
- The webmail's keyboard: the message list is one Tab stop, Enter on a button in the mail view presses the button, Escape closes every modal dialogue, and the compose window's Plain is Remove formatting.
- GET
/api/v1/me/messages/{id} answers "invitation": true for the Outlook-shaped invitation above, where it answered false. - 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; no existing member or dispid changes.
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.
- 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.
- 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; in 6.3.5 only the files below are in the release, the others being CI job artifacts.
- 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.
What 6.3.5 does not carry
- No ARM64 Windows installer: its build job's toolchain check stopped on the Windows runner. 6.3.6 carries it, as a preview.
- No AArch64 .deb or .rpm, no AppImage and no SLSA provenance; 6.3.3's AArch64 packages and AppImages were still the newest published. 6.3.6 carries all three.
- No container image: the pipeline pushes and signs the image only once the project has moved to the group hmailserver and the owner has switched it on. 6.3.6's is the first.
- No apt or dnf repository yet, and not in winget or Chocolatey.
Downloads
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, Authenticode-signed by Progressive Robot Ltd; 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, whose 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; the source tree's SBOMs, hmailserver.spdx.json and hmailserver.cyclonedx.json; and 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.
Verification
Every file is signed with Sigstore by the project's GitLab CI pipeline for the tag v6.3.5, at the path the project had before it moved into the group hmailserver on 29 September 2026. With cosign and the file and its bundle beside you, this must succeed:
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
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. 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 the bundle beside the file; read the identity it prints, which 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), and 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.
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; the rebuild of 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.
Reporting a vulnerability
Not in a forum thread, and not in a public issue. Report it privately, as SECURITY.md says: a confidential issue on GitLab, at gitlab.com/hmailserver/hmailserver, with 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.
