This release is superseded by hMailServer 6.3.8, a security release published on 2 November 2026. Upgrade every server running 6.3.7 or earlier, and read its announcement before upgrading.
hMailServer 6.3.7 was published on 17 October 2026. It is a security release: it fixes the security flaws listed under Security below, in every earlier version, among them a way for any account that could sign in to a Windows computer to replace the programs of an hMailServer installed at the root of a drive, the DKIM signing of mail from outside in a hosted domain's name, and any sender's way past the rule loop limit; and its Windows installers carry the .NET Desktop Runtime 10.0.13, and its x64 installer MariaDB Connector/C 3.4.11. The schema stays at 6108: from 6.3.6 the upgrade changes no table. It is the first release since 6.3.6 and the first security release made while releases pause, and it carries more than fixes: the work that was under way on 13 October 2026, which the owner decided that day to finish and fold into one batch, and, by his decision of 15 October 2026, the work already done for a later release - the first step of the Control Deck's and the webmail's rebuild planned for 6.4: the framework decision, the threat model of the web surface and the authorisation matrix with its check, with no product code.
Who is affected, and what to do
- Every server running 6.3.6 or earlier: upgrade. The security section below says why.
- Before upgrading, read "Before you upgrade". Some changes alter what an upgraded server does without anything being switched on - above all for accounts that send as another hosted domain's addresses, for rules and Sieve scripts that rewrite who a message is from, for an account given the
serveradmin role with a list of domains that administers the whole server over COM, and for a database account that signs in with MySQL Enterprise's Windows authentication.
- On 6.3.6: the live update installs 6.3.7, with the exceptions under "Upgrading". On a Windows server whose service runs as
NT SERVICE\hMailServer, an administrator presses Install update on the Control Panel's Server status page, on the server, and Windows asks once.
- On 6.3.4 or 6.3.5: the live update installs 6.3.7 too, with the exceptions under "Upgrading".
- On 6.2.28 to 6.3.3, or on a Linux server from 6.3.3's AArch64 packages or AppImages: upgrade by hand, once. Those versions trust only the GitHub workflow that signed the releases up to 6.3.3.
- Older than 6.2.28: run the installer, as always; the upgrade chain runs from every earlier hMailServer version.
Before you upgrade
- Back up the database and the data directory, each with its own tools (Upgrading.md). 6.3.7 adds no schema step, so the live update's rollback to 6.3.6, should 6.3.7 not start, meets no newer schema. From 6.3.5 or older the upgrade runs 6.3.6's three one-way steps to 6108, 6.3.6's announcement applies, and the backup is the only way back; from 6.3.3 or older 6.3.4's steps come first, and 6.3.4's notes apply as well.
- Accounts that send as another hosted domain. An authenticated submission is now signed as another domain hosted here only when its account may send as the address its
From names - its own, an alias pointing at it, a mailbox that granted it the post right, an address it proved, or a masked address of its own. Otherwise the mail is still accepted and sent, unsigned as that domain. Give such an account the alias or the grant before upgrading.
- Rules and Sieve scripts that rewrite who a message is from. A domain's or an account's rule may no longer set
From, Sender, Resent-From, Resent-Sender or DKIM-Signature, or the loop count, and its Reply goes only from an address its owner may send as; a Sieve script may no longer add or delete those fields, Auto-Submitted or the loop count, and its notify goes from the account's own address unless its :from reaches the account. One stored before the upgrade still runs, without that action or edit, and the application log names it. To set From on a domain's mail, make the rule a server rule with a condition on the domain.
RuleLoopLimit 0 now stops out-of-office replies, as it stopped every other generated message.- The
serveradmin role with a list of domains. An account given the serveradmin role with a list of domains is, over COM as over REST, confined to those domains and no longer the server's administrator: give the role with no list to an account that is to administer the whole server, a script's or a Control Panel's account among them.
- Event scripts that use a transaction. A script that goes on in a transaction after
Database.ExecuteSQL has failed is refused every statement after it once the database has ended the transaction, and Database.CommitTransaction then fails: call Database.RollbackTransaction and run the whole transaction again, or stop.
- The x64 installer's MySQL and MariaDB client is MariaDB Connector/C 3.4.11, built from MariaDB's source, with seven authentication plugins where 6.3.6's had nine. A database account that signs in with MySQL Enterprise's Windows authentication can no longer sign in, and the server then cannot open its database. No such setup is known to the project; ThirdPartyBinaries.md says what one would have to do before upgrading.
- The .NET 10 Desktop Runtime is not replaced. The Control Panel and the setup tools run on it; the mail server itself does not. The installers carry 10.0.13, Microsoft's security release of 13 October 2026, but install it only where no .NET 10 Desktop Runtime is installed at all: an upgraded server keeps the one it had - 10.0.12 where 6.3.4, 6.3.5 or 6.3.6 installed it - against which Microsoft published advisories that day, several of them rated High; whether hMailServer's own tools reach the code they concern has not been established. Bring it to 10.0.13 or later through Microsoft Update (on Windows Server, WSUS or the Microsoft Update Catalog, or Automatic Updates where the server has been opted in), or with Microsoft's installer from https://dotnet.microsoft.com/download/dotnet/10.0;
dotnet --list-runtimes lists what a machine has.
- Windows: the program folder,
Bin and ControlPanel. At every installation and upgrade /ProtectFolders now hardens the three: they keep no entry that lets another user change them, a file's own entry aside, which a CHECK line names, and under Program Files the first run makes their inherited entries their own. An installation at the root of a drive is hardened by the upgrade itself; to have it hardened before the upgrade runs anything from it, follow the steps "Before upgrading an installation at a drive's root" in ServiceAccount.md first. Reinstall the programs from the release into a new folder that only the administrators may change, not over the installation, where accounts that are not administrators could sign in to the computer while it was installed so, where anybody but SYSTEM, the Administrators or TrustedInstaller owned one of the three folders, a file directly in the program folder, or Events, WebAdmin, DBScripts, Addons or Languages or anything in them or in Bin or ControlPanel, or where one of the three had an entry of its own that let anybody else change it, or one the steps could not take away: setup leaves in place every file it does not ship, and puts the event script in Events, which the service runs, and the scripts in Addons only where none is there. The documentation says how: nothing run from the old folder, its uninstaller included; the mail, the built-in database and the settings file copied into the new folder before setup runs, since setup run into a folder without a settings file sets up a new, empty server; the settings file - its [Directories] and administrator password - and the event script read first; and setup given the new folder with /DIR=, since over an installation it installs into the folder it finds, once a 32-bit installation's uninstall entry, which overrides /DIR=, is taken away.
- Sign-in and relaying. SMTP, POP3 and ManageSieve refuse a SASL PLAIN sign-in that asks to act as another account. With SRS on, mail to an SRS address this server handed out is held to the relay rules unless it is a bounce.
- The anti-virus action Remove all attachments and deliver the text (Delete infected attachments only in 6.3.6's Control Panel) now delivers a message that is one attachment as the note alone, and deletes a message the server cannot read, telling its recipients.
- Forwards of mail from outside. A forward, a redirect or a rule's forward of mail from outside whose
From names the forwarding domain's own organisation, and that did not pass DMARC for it when it arrived, keeps the envelope sender it came with, with no SRS address or rewritten sender; a copy of it with an empty envelope sender is not sent to an outside address under this server's host name where that name is in the same organisation; a copy whose own envelope sender is at this server's host name, or at a hosted domain or a subdomain of one, in the organisation its From names is not sent to an outside address at all - the message stays in the mailbox, and the application log names each recipient - nor is such a message sent where an alias or a distribution list expands to an outside address; and a managed list does not distribute a posting whose From names the list domain's organisation unless it passed. No pass is recorded for a message the DMARC check did not judge - with ASDMARCEnabled off, from a sender on the anti-spam white list or an IP range with spam protection off, larger than antispammaxsize (1024 KB as shipped), already scored by the tests before it at the higher of the spam thresholds, imported from a file or downloaded - nor for a From whose domain publishes no DMARC record.
Security
Each of these was found by the project's own review, and each is fixed in 6.3.7, unless it says otherwise. Each links its work item, which gives the details, and the Security section of CHANGELOG.md says what changed.
- CVE-2026-107571, work item #78 - on Windows, where hMailServer was installed in a folder that took its permissions from the root of a drive, any account that could sign in to the computer could replace the programs the service runs; every version from 6.0.0 to 6.3.6. The default folder under Program Files was never affected. Four narrower cases are not fixed in 6.3.7 (Known issues, below).
- CVE-2026-107567, work item #84 - mail from outside whose
From named a domain hosted here was signed with that domain's DKIM key, and so was every forward and copy of it, so that it passed DMARC for that domain elsewhere; and an authenticated submission was signed as whatever hosted domain its From named, which 6.3.7 does only where the account may send as that address; every version from 6.0.0 to 6.3.6 that signs. An upgrade stops the signing; only rotating a domain's key ends the signatures already made.
- CVE-2026-114478 and CVE-2026-114474, work item #90 and work item #91 - a forward, a redirect, a list's copy or an alias's copy of mail from outside, a forward of a message downloaded from an external account among them, was given an envelope sender, or for a null one was sent under a host name, in the organisation of a domain its
From names, so that it could pass that domain's DMARC policy through SPF; every version from 6.0.0 to 6.3.6. 6.3.7 does so only when the message passed DMARC for it on arrival.
- CVE-2026-107568, work item #82 - an account's Sieve
notify was sent from whatever its :from said, and signed as that address's domain where the server signs for it; 6.2.22 to 6.3.6.
- CVE-2026-107566, work item #83 - an account's Sieve
editheader could rewrite From, Sender or DKIM-Signature ahead of a redirect, which the server then sent and signed in that name; 6.2.22 to 6.3.6. A domain's or an account's rule had the same gap, in every version - a Reply from an address its owner may not send as, a Set header value of From, Sender, the Resent- pair or DKIM-Signature - and is held the same way, under work items #82 and #83.
- CVE-2026-107569, work item #81 - any sender could lift the rule loop limit off a message, an account's own Sieve script or rule could reset it, and a Sieve
notify did not consult it, so that a loop of generated mail could run without bound; every version from 6.0.0 to 6.3.6.
- CVE-2026-114489, work item #86 - on a server with several tenants, a credential confined to named domains - a domain administrator, an account or API key given another role that manages accounts in named domains, or a full-scope API key issued for named domains - could rename a domain, create a domain alias, set on a domain's or an account's rule an action that reaches the server's own addresses, a configured route's stored credentials or a function of the event script, and point its domain's relay host at the server's own network, over the REST and the COM APIs; every version from 6.0.0 to 6.3.6.
- CVE-2026-114475, work item #89 - such a credential, a full-scope API key issued for named domains or the
serveradmin role given with a list of domains, could rewrite over the REST API a custom role that accounts in other domains hold, and create custom roles or delete one that no account holds; 6.3.4 to 6.3.6.
- CVE-2026-114477, work item #96 - a credential confined to named domains that may read their configuration, such as a domain administrator, the
auditor role given a list of domains or an API key issued for named domains, could read the server-wide metric history over the REST API; 6.2.25 to 6.3.6.
- CVE-2026-114490, work item #87 - over COM, an account given the
serveradmin role with a list of domains was the server's administrator, its list aside, and one given domainadmin with a list that leaves out its own domain administered that domain's ordinary accounts, where the REST API refused both; 6.3.4 to 6.3.6, on Windows.
- CVE-2026-114476, work item #88 - over the REST API, a credential that holds
manage_roles in named domains could take a role away from an account in those domains whose admin level is the server administrator's, and so hand that account the server administrator's authority; 6.3.4 to 6.3.6.
- CVE-2026-114470, work item #93 - a page on another site could make a browser that held a REST API credential from HTTP Basic send a state-changing request to the server, a cross-site request forgery; every version from 6.0.0 to 6.3.6.
- CVE-2026-114472, work item #97 - the ACME HTTP-01 challenge responder served one connection at a time, so idle clients could make a certificate's issuance or renewal fail; every version from 6.0.0 to 6.3.6. It now serves up to 64 connections at once and closes one past that; a client that holds 64 idle connections open through a whole validation can still make it fail (the work item says what remains).
- CVE-2026-114479, work item #92 - with the anti-virus action that removes attachments (
AVAction 1: Delete infected attachments only in 6.3.6's Control Panel, Remove all attachments and deliver the text in 6.3.7's), a message whose one part is an attachment, and an S/MIME message signed as one part, were delivered as they arrived, with what the scanner had found in them; every version from 6.0.0 to 6.3.6. The default action, which deletes the message, was never affected.
- CVE-2026-114473, work item #94 - with SRS on, which it is not by default, mail to an SRS address this server had handed out was not held to the relay rules; 6.2.1 to 6.3.6. Found by upstream hMailServer's review of its own SRS (upstream PR 649).
- CVE-2026-114471, work item #95 - with SMTP logging on, which it is not by default, the SMTP log wrote some credentials in the clear - an
AUTH PLAIN sent before EHLO or not in its one exact form, the bearer token of AUTH XOAUTH2 and AUTH OAUTHBEARER, and the lines of SCRAM-SHA-256, OAUTHBEARER and GSSAPI; every version from 6.0.0 to 6.3.6, each mechanism from the version that brought it. Found by upstream hMailServer (upstream issue 654).
The same release fixes or hardens more without a CVE request: the ARC seals this server makes attest its own SPF result, are made by the domain that relayed the message and name the domains their results are for; the stored-secrets key is no longer left in memory freed without being written over, nor a mailbox key encrypted at rest open past its idle minutes (both from 6.3.4); and, found by upstream hMailServer in code this project shares with it, an SRS address or a BATV tag almost a whole cycle old is no longer taken for fresh (upstream PR 649), and a SASL PLAIN client that asks SMTP, POP3 or ManageSieve to act as another account is refused, where it was signed in as itself (upstream issue 652). The Windows installers carry the .NET Desktop Runtime 10.0.13 (Microsoft's security release of 13 October 2026, where 6.3.4 to 6.3.6 carried 10.0.12), and the x64 installer MariaDB Connector/C 3.4.11, the first release of Connector/C with the fix of CVE-2026-107819, a flaw of the Connector/C 3.4.9 that 6.2.3 to 6.3.6 carried; the ARM64 installer carries no MySQL or MariaDB client. Upgrade every server running 6.3.6 or earlier.
Five of these fixes, those of work items 78 and 81 to 84, and their descriptions in CHANGELOG.md, were public in the project's repository before this release - on GitLab from 6 and 7 October 2026, and on master from 7 and 9 October 2026. That was the owner's decision, and an exception: the rule, which holds again after 6.3.7, is that a security fix becomes public about a day before the release that ships it (SECURITY.md, "What gets a release").
Upgrading
- By the live update, from 6.3.6. Every file of 6.3.7 is signed with Sigstore as this release's own pipeline at the project's group path,
https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7, with the project's id, 86730559, in the certificate; every server from 6.3.4 on has that signer compiled in and requires the id for it. From 6.3.6 the live update installs 6.3.7, with 6.3.6's own file as its rollback image. On Windows a service running as LocalSystem installs it itself; one running as NT SERVICE\hMailServer downloads and verifies it, and an administrator installs it with Install update on the Server status page of the Control Panel on the server - one Windows prompt, and the installer is checked again, elevated, before it runs. On Linux 6.3.6's own update helper applies it, for the generic .deb and .rpm of either architecture and for both AppImages; an ARM64 Windows server finds the ARM64 installer by name. No live update had installed a release signed at the group's path when this was written.
- From 6.3.4 or 6.3.5, what 6.3.6's notes said of those two versions still holds, since the update is applied by the version already installed. A Windows service running as LocalSystem installs 6.3.7 by its live update, from 6.3.5 with 6.3.5's file as its rollback image and from 6.3.4 without one; that image is no way back once the upgrade's schema steps have run, and the backup taken before the upgrade is. One running as
NT SERVICE\hMailServer downloads and verifies it, then leaves the install to an administrator (HM7463), whose Install update on 6.3.4 and 6.3.5 cannot do it: download hMailServer-6.3.7-x64.exe from the release, check that Get-AuthenticodeSignature says Valid for CN=Progressive Robot Ltd, and run it as an administrator, keeping the service account on the installer's Service account page - once, since every release after it installs with one click. On a machine that has not seen the file before, Windows SmartScreen may say that it "prevented an unrecognized app from starting": More info names the publisher, Progressive Robot Ltd, and with the signature checked, Run anyway installs it. On Linux, install 6.3.7 with apt, dnf or zypper rather than by the live update, whose apply step on 6.3.4 and 6.3.5 is the one 6.3.6 fixed (CVE-2026-104658), or turn the apply off until then with systemctl disable --now hmailserver-update.path.
- Three settings left from 6.3.5's by-hand route. A server whose
UpdateSigningIdentity, UpdateSigningIssuer and UpdateSourceRepository still name the path the project began at refuses 6.3.7. Clear the three first: on 6.3.4 and 6.3.5 in the Control Panel, with DELETE /api/v1/settings/ini/<name> or on Linux with hmailserver --set-setting <name>=, not in the file, which those versions put back; on 6.3.6, which reads them from hMailServer.ini alone, by deleting their lines from [Settings] with an editor run as an administrator, or on Linux with sudo hmailserver --set-setting <name>=, and restarting the service.
- By hand, from 6.2.28 to 6.3.3, and from 6.3.3's AArch64 packages or AppImages. On Windows run
hMailServer-6.3.7-x64.exe over the existing installation; on Linux install the package with apt or dnf, or replace the AppImage with 6.3.7's. Those versions refuse a release signed on GitLab, and one pointed at this project's feed with UpdateFeedUrl downloads the installer at every check and refuses it: keep UpdateAutoDownload off there until then.
- A server from one of 6.3.6's per-distribution packages is offered the generic package by its live update, which apt refuses on Debian 12 and dnf on Enterprise Linux 9. There, upgrade with the package manager and your release's own package of 6.3.7.
- The container image,
registry.gitlab.com/hmailserver/hmailserver:6.3.7, also tagged 6.3 and latest. In the container the update check names the image to pull and installs nothing (ContainerImage.md).
What else changes on upgrade
The 6.3.7 section of CHANGELOG.md lists everything under "What changes on upgrade without a switch". The rest, in short:
- Database errors: on MySQL, MariaDB, SQL Server and SQL Server Compact an insert that forgives a duplicate key forgives that alone, and any other failure is reported (
HM5032), where it was taken as done with no row written; on MySQL and MariaDB a lost connection is reconnected and the statement run again, so the statement after a database restart, a failover or wait_timeout no longer fails. An error log that was quiet may now name failures that were hidden.
- IMAP:
COPY and MOVE by message number read their set in the client's numbering, and a set that names a message another session has just expunged is refused, NO [EXPUNGEISSUED], for the client to send again; a COPY or MOVE that fails part way leaves the destination as it was; SEARCH, SORT and THREAD ask a criterion named again beside itself once; FETCH BODY[N.MIME], and BODY[N] of a multipart, are the stored octets.
- POP3: classic Outlook for Windows, Outlook 2016 to 2024, downloads its mail again: the server accepts the
UTF8 it sends after the login, until the session's first STAT, LIST, UIDL, RETR, TOP, DELE or RSET.
- DNS: a DNS lookup that fails is a failure, not a name with no addresses (upstream PR 640). The HELO and PTR tests no longer score a name they could not look up, a DNS blacklist and SURBL no longer read a failed lookup as "not listed", and delivery whose mail servers' lookup failed tells the sender that the DNS query failed (
4.4.4) and retries.
- Anti-spam: a link's host that is not ASCII is read by UTS 46, and an HTML part's character references as a browser reads them, for the SURBL test and the sender lists' URL entries; and SpamAssassin is sent a collected message's own
Return-Path, so its SPF and envelope rules may score such mail differently.
- Large messages: a message over 80 MB goes through the rules, the forwards, a bounce and the spam headers by its header alone, where it went through them as if it had no header; the rule conditions that need the body do not match, each with a line in the application log.
- Stops: setup, the live update's silent install and the uninstaller wait
ShutdownDrainSeconds plus 90 seconds for the service's stop, where they waited plus 30; and on Windows a stop no longer waits past a work queue's ten seconds for a thread held by a host or a database that has stopped answering.
- Rules: a rule's Run function is refused when it is saved unless it names a plain function, for a rule of every owner, over COM and REST.
- The quarantine: a quarantined copy's file name carries where the message came from, its SPF result and the relaying domain (
<GUID>.spf-fail.outside.eml, .relay-<id>); a tool that reads the quarantine folder by name meets the longer names.
- The Control Panel: Updates is a page of its own under Maintenance; the sidebar has Compliance and Virus scanning groups; API & monitoring is Monitoring & alerts; the PROXY protocol and XCLIENT are a card on Incoming relays; and Ctrl+K takes every old title and route to its page. A Control Panel signed in to a server on another computer shows and saves the server's
hMailServer.ini [Settings] values.
Reported from outside and fixed besides: the Control Panel's IP ranges page, which could show no list of ranges at all (work item #79, ThiagoES84); mail to a DNSSEC-signed domain whose MX answer came compressed, live.com among them, which DANE enforcement deferred (work item #80, ThiagoES84); and classic Outlook's POP3 downloads, which stopped at the UTF8 it sends after the login (work item #85, ciprianbalus). Thank you.
Also new
- The IMAP and POP3 listeners take the client's address from a PROXY protocol header, as the SMTP listener does, each from the peers on a list of its own; both are off by default.
- The first units of the active-active work, which is still not built (ActiveActive.md).
- The first step of the Control Deck's and the webmail's rebuild, with no product code: ControlDeckFramework.md, WebThreatModel.md and WebAuthorisationMatrix.md, the matrix written from the code by
build/generate-auth-matrix.py and held to it in CI.
What the release carries
62 files, each with its Sigstore bundle, <file>.cosign.bundle, beside it:
- Windows:
hMailServer-6.3.7-x64.exe, and hMailServer-6.3.7-arm64.exe for Windows on ARM, both Authenticode-signed. The ARM64 installer is a preview: it is cross-compiled on the project's x64 Windows runner and has never run on ARM64 hardware. SQL Server Compact has no ARM64 build, so a new ARM64 installation is set up against SQL Server or PostgreSQL (WindowsOnArm.md).
- Linux, x86-64 and AArch64: the generic
hmailserver_6.3.7_amd64.deb, hmailserver_6.3.7_arm64.deb, hmailserver-6.3.7-1.x86_64.rpm and hmailserver-6.3.7-1.aarch64.rpm, the names an installed server's update check asks for; and each Debian 12 and 13, Ubuntu 24.04, Fedora 44 and 43, Enterprise Linux 10 and 9, openSUSE Leap 16.0 and Tumbleweed release's own package for both architectures. The AArch64 files are cross-compiled and tested under emulation: no AArch64 machine has run them.
- The AppImages,
hMailServer-6.3.7-x86_64.AppImage and hMailServer-6.3.7-aarch64.AppImage, and beside them the source of the libraries they carry and of those their runtime links.
- The source tarball,
hmailserver-6.3.7.tar.gz; the Helm chart, hmailserver-chart-6.3.7.tgz; and the PowerShell module, HmailServer.psd1 and HmailServer.psm1, Authenticode-signed.
- An SBOM for each compiled file and the tarball,
<file>.cdx.json, and the source tree's two; hmailserver-linux-6.3.7-SHA256SUMS.txt, the SHA-256 of every Linux file; and, beside the 62, hmailserver-6.3.7.intoto.sigstore.json, SLSA v1 build provenance that names each of them by its SHA-256.
https://updates.progressiverobot.com/download/ leads to the newest stable release's page, and /download/hMailServer-x64.exe, /download/hmailserver_amd64.deb, /download/hmailserver.x86_64.rpm and the rest of the download links to that file of it.
How to check a download
With cosign and OpenSSL, with the file and its bundle beside you:
cosign verify-blob --bundle hMailServer-6.3.7-x64.exe.cosign.bundle \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7' \
--certificate-oidc-issuer https://gitlab.com hMailServer-6.3.7-x64.exe
jq -r .verificationMaterial.certificate.rawBytes hMailServer-6.3.7-x64.exe.cosign.bundle \
| base64 -d | openssl x509 -inform DER -noout -text | grep -A1 1.3.6.1.4.1.57264.1.15
The first must say Verified OK, and the second print ..86730559, the project's own id, which cosign does not check: the identity is a path, and a path could pass to another project were the group or the project renamed. Each file but a <file>.cdx.json SBOM also has its bundle a second time as <file>.sigstore.json; either name verifies the same way.
To check that a file is one this release's pipeline built, against its build provenance:
cosign verify-blob-attestation --new-bundle-format \
--bundle hmailserver-6.3.7.intoto.sigstore.json --type slsaprovenance1 \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7' \
--certificate-oidc-issuer https://gitlab.com hmailserver_6.3.7_amd64.deb
It says Verified OK only when the file's SHA-256 is one the provenance names. Then:
sha256sum -c --ignore-missing hmailserver-linux-6.3.7-SHA256SUMS.txt must say OK for each Linux file you downloaded.- On Windows,
Get-AuthenticodeSignature on either installer must answer Valid, with a signer certificate for CN=Progressive Robot Ltd. The x64 installer's published SHA-256 is dcae96bd75d6cae8e5a910d15940567067539ed99db5aeed40a815added4d85f.
- In a clone,
git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.7 must report a good signature by the one key that file lists.
- For the image, ContainerImage.md, "Checking an image", gives the
cosign verify command and the check of the project's id.
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", has the rest.
How it was checked
The tag's pipeline (https://gitlab.com/hmailserver/hmailserver/-/pipelines/2958958332) ran every gate before anything was published: the Windows suite, in two halves on the project's two Windows benches, 4,446 tests, 4,366 passed, 0 failed, 80 skipped; the Linux suite on one of the project's Linux runners, 2,652 tests, 2,284 passed, 0 failed, 368 skipped; the rebuild of the x86-64 server, .deb and .rpm byte for byte; the install of every Linux package in a clean container of its release, by that release's own package manager, the AArch64 ones under emulation, but for the generic x86-64 .rpm, which is built on Ubuntu and was installed on Fedora 44 with rpm --nodeps, its dependencies not resolved; the generic x86-64 .deb configured and started against a database; the static analysis, Semgrep and the dependency scan. It then checked every signature with the server's own verifier, hmailserver --verify-update, built from the same commit. The signed installer went through the installer smoke test: an upgrade from 6.3.6 passed 98 checks and a new installation 64, none failed.
Known issues
- Four narrower cases of work item #78 are not fixed in 6.3.7, by the owner's decision, and stay open: setup hardens a program folder before it copies anything into it only when setup makes the folder, and then just after making it; a folder that is already there is hardened in place, before the copy, only for an installation of the Control Panel alone, while for a server installation, and at every upgrade, the program folder,
Bin and ControlPanel are hardened by /ProtectFolders at the end of setup; a link or a junction in the program folder's path is named in setup's log as not hardened, and not refused; and the files in Bin and ControlPanel are not listed by their owners. None of them reaches an installation in a folder only the administrators may change - the default under Program Files is one - unless a link that another account controls is on its path. Before upgrading an installation at the root of a drive, follow ServiceAccount.md's steps (Before you upgrade, above).
- The ARM64 installer has never run on ARM64 hardware, and no AArch64 machine has run the AArch64 Linux files. If you install either, please say how it went, working or not, in an issue.
- No channel publishes it yet. The apt and dnf repositories, Docker Hub, Quay.io, the AUR, the Ubuntu PPA, Copr, the openSUSE Build Service, Chocolatey, PyPI and the PowerShell Gallery publish from
master once their keys and accounts exist; none is live as this release is made (Channels.md). The Snap Store's name is registered, and the job that would have put 6.3.7 on its edge and candidate channels once the release was published failed on 18 October 2026, on a tool missing from its image, with the two snaps built and checked: 6.3.7 is not on the Snap Store (Snap.md).
- An AppImage on Fedora, Enterprise Linux or openSUSE runs on the host's glibc and cannot require its extra character-set converters: install
glibc-gconv-extra (Fedora, EL) or glibc-gconv-modules-extra (openSUSE) by hand; the server says when they are missing.
- An upgraded server keeps the .NET 10 Desktop Runtime it had (Before you upgrade, above).
While releases pause
6.3.6 was the last release planned by date, by the owner's decision of 28 September 2026; the releases since are security releases, each cut from master with whatever finished work master holds then, until the maintainers say otherwise in SECURITY.md, "While releases pause". A confirmed vulnerability still ships in a release: a critical or high one as soon as its fix has passed the gates, and none held past 90 days from its acknowledgement. Other defects are fixed on master and ship with the next security release, or when releases resume. The 6.3 line receives security fixes until 30 September 2027; before that date the maintainers write in SECURITY.md whether support continues, and if nothing has been written, the 6.3 line is not supported from 1 October 2027. Nothing is back-ported: an installation of 6.3.6, 6.2 or anything older is upgraded in place to the newest release. To hear of a security release, switch the server's update check on (UpdateCheckEnabled), or follow the releases' feed.
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 · Mirror on GitHub · Newest stable release
change settings in the Control Panel, over COM or REST, or on Linux with