hMailServer 6.3.7 hMailServer 6.3.7 is a security release: it fixes security flaws in every earlier version, and is the first security release made while releases pause. It was published on 17 October 2026, built and signed by the project's GitLab CI pipeline from the tag v6.3.7, and it carries every file that pipeline makes: the x64 and ARM64 Windows installers, .deb and .rpm packages for x86-64 and AArch64 with one package for each of the distribution releases named under Downloads, both AppImages, the source tarball, the Helm chart, the PowerShell module, an SBOM for each compiled file and SLSA build provenance, with a Sigstore bundle beside every file; a container image is pushed from the same pipeline once the release is published. Its Windows installers carry the .NET Desktop Runtime 10.0.13, and its x64 installer MariaDB Connector/C 3.4.11. 6.3.7 requires schema 6108, as 6.3.6 does, and adds no upgrade step: from 6.3.6 the upgrade changes no table. 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). The 6.3 line receives security fixes until 30 September 2027. Read this first: upgrade every server running 6.3.6 or earlier. The security section below says why. 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, and one running as NT SERVICE\hMailServer downloads and verifies it, then an administrator presses 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. Read this too: from 6.3.4 or 6.3.5 the update is applied by the version already installed, so what 6.3.6's notes said of those two versions still holds. 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 from 6.3.4 or 6.3.5, install 6.3.7 with apt, dnf or zypper rather than by the live update, whose apply step on those two versions is the one 6.3.6 fixed (CVE-2026-104658), or turn the apply off until then with systemctl disable --now hmailserver-update.path. Read this too: a server still carrying the three settings of 6.3.5's by-hand route refuses 6.3.7. A server whose UpdateSigningIdentity, UpdateSigningIssuer and UpdateSourceRepository still name the path the project began at, set so that a server from 6.2.28 to 6.3.3 could install 6.3.5, 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/ or on Linux with hmailserver --set-setting =, not in the file, which those versions put back, and 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 =, and restarting the service. Read this too: a server from 6.2.28 to 6.3.3, or one installed from 6.3.3's AArch64 packages or AppImages, upgrades by hand, once. Those versions trust only the GitHub workflow that signed the releases up to 6.3.3, and refuse a release signed on GitLab. 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. 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 older than 6.2.28 runs the installer, as always: the upgrade chain runs from every earlier hMailServer version. A server installed 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. Read this too: back up the database and the data directory first, 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 notes apply, 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. Read this too: mail is signed as a hosted domain only where the server is entitled to. 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. 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. Read this too: forwards of mail from outside are held to DMARC. 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. 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. Read this too: on Windows, the program folder, Bin and ControlPanel are hardened. 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, in any of these cases. Accounts that are not administrators could sign in to the computer while it was installed so; 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 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. Read this too: 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. 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. Read this too: roles, event scripts, sign-in and the anti-virus action change too. 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. An event 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. 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. Security Each of these was found by the project's own review, and each is fixed in 6.3.7, unless it says otherwise. Among them are 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. The Security section of CHANGELOG.md at the tag says what changed, and the work items it names give the details; several identifiers were still requested when 6.3.7 was published. Upgrade every server running 6.3.6 or earlier. - 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. hMailServer.exe /ProtectFolders, which setup runs at every installation and upgrade, now hardens the program folder, Bin and ControlPanel. 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 requested (work items 90 and 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 requested (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 requested (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 requested (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 requested (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 requested (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 requested (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 requested (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 requested (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 requested (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 requested (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. 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"). What changes without a switch The full list is the 6.3.7 section of CHANGELOG.md, under "What changes on upgrade without a switch". Beside the notices above, 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; 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; and scheduled tasks run in the second they are due, and no longer wait an hour when the clocks go back. - 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 (.spf-fail.outside.eml, .relay-); 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. What is 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. Downloads The release carries 62 files, each with its Sigstore bundle, .cosign.bundle, beside it, and each file but a .cdx.json SBOM has that bundle a second time as .sigstore.json, the name Sigstore's own clients look for; with the bundles and the provenance, 160 files. - Windows: hMailServer-6.3.7-x64.exe, and hMailServer-6.3.7-arm64.exe for Windows on ARM, both Authenticode-signed by Progressive Robot Ltd. 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). If you install it on an ARM64 machine, please say how it went, working or not, in an issue on GitLab. - 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, named hmailserver_6.3.7-1~_.deb or hmailserver-6.3.7-1...rpm. The generic .deb does not install on Debian 12, nor the generic .rpm on Enterprise Linux 9: each takes its own release's package. 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, hmailserver-6.3.7-appimage-bundled-sources.tar.gz and hmailserver-6.3.7-appimage-runtime-sources.tar.gz. - 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, .cdx.json, and the source tree's two, hmailserver.spdx.json and hmailserver.cyclonedx.json; 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. The container image, registry.gitlab.com/hmailserver/hmailserver:6.3.7, also tagged 6.3 and latest, for linux/amd64 and linux/arm64, is pushed from this release's own pipeline once the release is published, by a job started by hand, as 6.3.6's was. In the container the update check names the image to pull and installs nothing. ContainerImage.md, "Checking an image", gives the cosign verify command and the check of the project's id. No channel publishes 6.3.7 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, and 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). The newest stable release's files are also at fixed addresses that never lead to a pre-release: updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hMailServer-arm64.exe, /download/hmailserver_amd64.deb, /download/hmailserver_arm64.deb, /download/hmailserver.x86_64.rpm, /download/hmailserver.aarch64.rpm, /download/hMailServer-x86_64.AppImage and /download/hMailServer-aarch64.AppImage; add .cosign.bundle for the bundle. https://updates.progressiverobot.com/download/ leads to that release's page. Verification Every file is signed with Sigstore by the project's GitLab CI pipeline for the tag v6.3.7, and was checked before publication with hmailserver --verify-update, built from the same commit. The certificate's identity is https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7, its issuer https://gitlab.com, and it carries the project's id, 86730559. With cosign and OpenSSL, and the file and its bundle beside you, the first command must say Verified OK, and the second must print ..86730559, the project's own id, which cosign does not check, since the identity is a path and a path could pass to another project were the group or the project renamed: 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 If your cosign has the --new-bundle-format option and does not use it by default, add it. Each file but a .cdx.json SBOM also has its bundle a second time as .sigstore.json; either name verifies the same way. 6.3.5, signed before the project moved into the group hmailserver on 29 September 2026, names https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.5 instead. To check that a file is one this release's pipeline built, against its build provenance, which says Verified OK only when the file's SHA-256 is one the provenance names: 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 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 and the ARM64 installer's 56a5425bd4e50e6dc79a02c6b79ff0f6bcc4e88ef59d457652efcaaac67601dd. On Linux a server from 6.3.4 on makes the same check its live update makes, hmailserver --verify-update , with the bundle beside the file. 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 (the notices 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 the release yet (above); none is live as this release is made, and 6.3.7 is not on the Snap Store. - 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 (the notices 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 at updates.progressiverobot.com/releases.atom. The project, and reporting a vulnerability The project's home is GitLab, at gitlab.com/hmailserver/hmailserver, where it moved from gitlab.com/Progressiverobot/hmailserver on 29 September 2026, with issue templates for a bug, a feature, a question and a security report, and a Service Desk address for anyone without a GitLab account: a bug report or a question for the maintainers emailed to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com becomes a confidential issue, which only the maintainers see. The release is also mirrored on GitHub, at https://github.com/RainbowWizard-coder/hMailServer, re-published on 18 October 2026 from the GitLab release with each file checked against the SHA-256 GitLab's package registry records for it, where the per-release Debian packages are named with a dot in place of the tilde; issues and merge requests stay on GitLab. Report a vulnerability privately, by one of the two routes in SECURITY.md: a confidential GitLab issue with the Security template (check that it is still marked confidential before you submit it), or an email to that Service Desk address, which GitLab files as a confidential issue. Never in a forum thread or a public issue.