---
title: "hMailServer 6.3.5: the first release built and signed by its GitLab pipeline, and the quarantine grouped by domain and HELO"
url: https://www.hmailserver.co.uk/topic/28275/hmailserver-6.3.5-the-first-release-built-and-signed-by-its-gitlab-pipeline-and-the-quarantine-grouped-by-domain-and-helo
author: "chris"
published: 2026-09-29T12:07:11.381Z
updated: 2026-09-29T12:07:11.381Z
category: "Announcements & releases"
tags: ["release","schema","upgrade"]
site: hMailServer Community Forum
---

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

**This release is superseded** by [hMailServer 6.3.6](/topic/28276/hmailserver-6.3.6-security-fixes-for-every-earlier-version-read-before-upgrading-and-the-last-release-for-the-time-being), 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](/topic/28218/hmailserver-6.3.4-a-password-could-run-code-on-windows-servers-with-jscript-scripting) 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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/hmailserver/docs/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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/hmailserver/docs/SenderListsAndDigests.md#reviewing-the-quarantine)).
- **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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/hmailserver/docs/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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/hmailserver/docs/PackageManagers.md#apt-and-dnf)).
- 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](https://docs.sigstore.dev/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 christopher.j.holloway@outlook.com`.

The release's own notes, under Verification, give each file's SHA-256 and the certificate the pipeline was given. [SECURITY.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/SECURITY.md#verifying-a-release), "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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.5/SECURITY.md#reporting-a-vulnerability) says: a [confidential issue on GitLab](https://gitlab.com/hmailserver/hmailserver/-/issues/new?issue[confidential]=true) - 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](https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.5) · [Newest stable release](https://updates.progressiverobot.com/download/)