hMailServer 6.3.8 hMailServer 6.3.8 is a security release: it fixes vulnerabilities the project found in its own code, which between them reach every earlier version, back to 6.0.0's first beta. It was published on 2 November 2026, built and signed by the project's GitLab CI pipeline from the tag v6.3.8, 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 each, and, new in 6.3.8, the provenance's signed envelope alone as one line of JSON; a container image is pushed from the same pipeline once the release is published. Each vulnerability is a work item with a CVE request, among them the four narrower cases of work item 78 that 6.3.7's notes left open. 6.3.8 was first decided, while releases pause, because the published Helm charts of 6.3.6 and 6.3.7 did not start a server, which only a release puts right; it also puts right the container image, which could not reach a MariaDB database, and the Windows installer, which ran over an installation of the original hMailServer's 5.7, and it carries everything that landed on master after 6.3.7. Its Windows installers carry the .NET Desktop Runtime 10.0.13, as 6.3.7's did, and its x64 installer MariaDB Connector/C 3.4.11. 6.3.8 requires schema 6108, as 6.3.6 and 6.3.7 do, and adds no upgrade step: from 6.3.6 or 6.3.7 the upgrade changes no table. The 6.3 line receives security fixes until 30 September 2027. Read this first: upgrade every server running 6.3.7 or earlier. The security section below says why, and the notices after this one say what an upgraded server does differently. Every file of 6.3.8 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.8, with the project's id, 86730559, in the certificate, as 6.3.6 and 6.3.7 were; every server from 6.3.4 on has that signer compiled in and requires the id for it. From 6.3.7 or 6.3.6 the live update installs 6.3.8, with the running version'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 the installed version's 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. A server installed from one of 6.3.6's or 6.3.7's per-distribution packages is offered the generic package, which apt refuses on Debian 12 and dnf on Enterprise Linux 9: upgrade it with its package manager and its own release's package of 6.3.8. No live update was known to have installed a release signed at the group's path when the release notes were 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.7's notes said of those two versions still holds. A Windows service running as LocalSystem installs 6.3.8 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 leaves the install to an administrator, whose Install update on those versions cannot do it: download hMailServer-6.3.8-x64.exe from the release, check that Get-AuthenticodeSignature reports it Valid and signed by CN=Progressive Robot Ltd, and run it as an administrator, once, keeping the service account on the installer's Service account page. 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.8 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, or turn the apply off first 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.8. A server whose UpdateSigningIdentity, UpdateSigningIssuer and UpdateSourceRepository still name the path the project began at refuses every release signed after the project moved, 6.3.8 included: clear the three first, as UpdateFeed.md says, 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; 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. After the backup Upgrading.md describes, on Windows run hMailServer-6.3.8-x64.exe over the existing installation; on Linux install the package with apt or dnf, or replace the AppImage with 6.3.8's (UpdateFeed.md, "A server from 6.2.28 to 6.3.3"). 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 version of this fork, and from the original hMailServer up to 5.6 and its 5.7 development builds up to schema 5708, and not from the original's 5.7 releases, which 6.3.8's installer refuses. Read this too: back up the database and the data directory first, each with its own tools (Upgrading.md). 6.3.8 adds no schema step, so an upgrade from 6.3.7 or 6.3.6 changes no table, and the live update's rollback, should 6.3.8 not start, meets no newer schema. From 6.3.5 or older the upgrade runs 6.3.6's three steps to 6108, which are one-way, and the backup is the only way back; from 6.3.3 or older 6.3.4's steps come first. A server upgraded from 6.3.6 or earlier meets as well what 6.3.7's notes say under "Before you upgrade" and in their list, and one from 6.3.5 or earlier what 6.3.6's list says. Read this too: a Helm release of the 6.3.6 or 6.3.7 chart is moved by hand. Its pod never started: those charts stopped at "container has runAsNonRoot and image has non-numeric user (hmailserver)", and, given the user by number, at an empty configuration volume that hid the image's settings file. Run helm repo update, then helm upgrade hmailserver/hmailserver --reset-then-reuse-values (Helm 3.14 or later), then kubectl delete pod -hmailserver-0, since the StatefulSet replaces no pod while one is not Running and Ready, and so never replaces the stuck one by itself. With --reuse-values instead the release keeps the old chart's fsGroup 1000 and database.port 5432; the pod still runs as 999. In a cluster whose policy refuses every sysctl, set unprivilegedPortsSysctl: false. A Compose deployment made from an earlier Compose file keeps its HM_REST_CERTIFICATE_FILE, HM_REST_PRIVATE_KEY_FILE and ./certs mount in the new file, the key readable by 999, or its REST API, and with it the Control Deck, the webmail and hmctl, does not start (ContainerImage.md, "Updates"). Read this too: the container image now reaches a MariaDB database, and keeps its passwords out of the server's environment. The images of 6.3.7 and earlier carried PostgreSQL's client alone, so a container told HM_DB_TYPE=MySQL stopped at its first start; 6.3.8's carries MariaDB Connector/C (libmariadb3), and the chart passes a database port only when one is set, so a chart told MySQL no longer dials MariaDB on PostgreSQL's port. The image's entrypoint secures a new installation by itself, whatever the container's command, and takes HM_DB_PASSWORD, HM_ADMIN_PASSWORD, their _FILE forms and HMAILSERVER_RECOVERY_PASSPHRASE out of the environment before it runs any program. The Compose file's and the Helm chart's commands are shell command lines and still pass the settings' variables (HM_SETTING_*, HM_PROPERTY_* and the rest) to the server, so a setting that is a secret belongs in a _FILE variable there, as their examples give it, and HMAILSERVER_RECOVERY_PASSPHRASE only in the environment of a container started to run hmailserver --decrypt-store. Read this too: on Windows, never run this fork's installer of 6.3.7 or earlier over the original hMailServer's 5.7. Both projects' installers register as hMailServer_is1, so those of 6.3.7 and earlier took an installation of the original's 5.7 builds of August and September 2026 (5.7.0 and its pre-release builds 2788 and 2843, 5.7.1 and 5.7.2: schema 5709 to 5711, which this fork's upgrade chain has no step from) for their own and replaced its programs. 6.3.8's setup asks first, before a page is shown or anything is installed or stopped, and refuses such an installation with a message that says nothing has been changed; silent, it ends with exit code 1 and writes the reason to its log (/LOG) and to hMailServer-setup-refused.txt in %TEMP%. Move such a server's mail over IMAP instead (Migration.md, "From the original hMailServer"). An installation of this fork, or of the original up to 5.6 and its 5.7 development builds up to schema 5708, is upgraded as before. Read this too: TlsMode=verify-full on MySQL or MariaDB without TlsCaFile, to a database server on this machine, is now refused. Through MariaDB Connector/C, the client the Windows installer bundles and the one the Linux server loads (libmariadb.so.3), such a connection (to 127.0.0.1, ::1, localhost, an empty Server=, the name "." for a named pipe on Windows, a Unix socket, or a Server= list that holds one) was made, from Connector/C 3.4.1 on, with neither the certificate's issuer nor its name checked; 6.3.8 refuses it before anything is attempted, with HM7535 (new) in the error log. Before upgrading, name in TlsCaFile a CA that issues nothing but the database's certificates, the one that issued its certificate, or set TlsMode=require (DatabaseTls.md). On Linux the client is the distribution's, which should be MariaDB Connector/C 3.4.11 or later; where it is older and not patched, name the CA in TlsCaFile. Read this too: on Windows, a file whose path holds characters outside ASCII may be refused. A TlsCaFile (with TlsMode=verify-full) or a PostgreSQLSslRootCert whose name the client cannot be handed as it is named is refused with HM7534 (new), and the database is then not reached; a TLS certificate or private key file, dh2048.pem, a client-certificate CA file, MessageStoreObjectCaFile, OAuth2PublicKeyFile or a file in AcmeCertificateDirectory is refused with HM7536 (new), and then what the file is for does not work: a port whose certificate or key it names does not start. OAuth2PublicKeyFile was handed over in UTF-8 up to 6.3.7, so a name outside the code page that worked then is refused now. Give each such file, and the folders above it, an ASCII name before upgrading (DatabaseTls.md). Read this too: on Linux, file names outside ASCII are UTF-8 whatever LANG says. A server that ran under a LANG that is not UTF-8 named such files in that locale's bytes and no longer finds them: where its data directory, a domain or account folder, LogFolder, TlsCaFile or a TLS certificate or key file is named outside ASCII, rename each to its UTF-8 name before upgrading, for example with convmv -f iso-8859-1 -t utf-8 -r --notest . Under a UTF-8 LANG, the packages', nothing changes. A LANG, LC_ALL or LC_CTYPE naming a locale the machine does not have no longer stops the server at its start, and the values --set-setting, --apply-profile, --account and --domain take, and --config, are read as UTF-8 and refused with exit 2 when they are not. Read this too: on Windows, setup makes or hardens the program folder, Bin and ControlPanel before it copies a file or runs a program of the installation, and refuses what another account controls. A program folder, Bin or ControlPanel, a folder or a link on the way to them, or a program, library, script or settings file in them, that another account than SYSTEM, the Administrators and TrustedInstaller controls, and a program folder on a share or on a volume that keeps no permissions (FAT, exFAT), end the installation with exit code 7, each named with the icacls that deals with it and, where the refusal says so, a restart of Windows before setup runs again, and setup refuses to run again until that restart. The folders and links on the way are looked at before setup stops the service, so that such a refusal leaves a running server running. Anything not as setup left it after the files ends the installation with exit code 12 and sets the service not to start until setup runs again (ServiceAccount.md, "Before the files"). Read this too: sign-in names, IP ranges and REST request bodies are held more strictly. A mail client that signs in with another spelling of the account's address than the stored one, in more than the case of the letters A to Z, or with white space at either end, may no longer sign in: correct the name in the client. IP ranges of your own that allow some addresses none of SMTP, POP3 and IMAP, with the web services listener on, now close that listener to those addresses too, and with it ACME's http-01 validation when this listener answers it, MTA-STS, CalDAV, CardDAV, Autodiscover, autoconfiguration and the Web Key Directory: check that the certificate authority, the sending MTAs and these services' clients do not come from one. A REST client of your own that sends a body that is not one JSON object, names a member twice, holds an escaped U+0000 or passes the bounds (100,000 values, 32 levels deep), or that writes a member whose absence is the wider setting as another type than its route reads, is answered 400. Read this too: ACME, Chocolatey, monitoring and the .NET runtime change too. A server whose AcmeDomains lists a host its certificate does not name orders a certificate for every host at the first check after the upgrade; a host the CA cannot validate fails the whole order, at most three times an hour, and holds the renewal for the other hosts with it: take such a host off the list before upgrading. When installing with Chocolatey, give the administrator password in HM_ADMIN_PASSWORD, set in the elevated prompt, not with /adminpassword in --install-arguments: the install now passes the installer /LOG, and the log records setup's command line. A stop's interruption is now a line in the debug log, not the error log, and runs no OnError script; an event script's call that meets a stop fails with "The server is stopping. The request was not completed." The .NET 10 Desktop Runtime, on which the Control Panel and the setup tools run, is installed only where none is, so an upgraded server keeps the one it had: bring it up to date through Microsoft Update, or with Microsoft's installer from https://dotnet.microsoft.com/download/dotnet/10.0. Security Each of these was found by the hMailServer project (Progressive Robot Ltd) and, but for the last, is fixed in 6.3.8; each work item is public now, and each has a CVE request through GitLab's CNA. Between them they reach back to 6.0.0's first beta. The 6.3.8 section of CHANGELOG.md at the tag gives each, with how it is tested. Upgrade every server running 6.3.7 or earlier. - CVE requested (work item 112): TlsMode=verify-full on MySQL and MariaDB checks the database server's certificate against the file TlsCaFile names when that name holds a character outside ASCII (on Linux any, on Windows one above U+00FF), where the client was given no CA file at all and checked the certificate against the system's trust store, with some versions of MariaDB Connector/C less than that, while the log and the diagnostics said it had been checked; 6.3.4 to 6.3.7. Its entry corrects what 6.3.7's notes said of a named TlsCaFile as the mitigation for CVE-2026-107819, MariaDB Connector/C's own flaw: it did not hold for such a name. - CVE requested (work item 113): TlsMode=verify-full without TlsCaFile, on a connection that MariaDB Connector/C 3.4.1 or later takes as one to this machine, checked neither the database server's certificate's issuer nor its name; 6.3.4 to 6.3.7. It is now refused, with HM7535 (the notices above). Connector/C 3.3 and 3.4.0 and Oracle's MySQL client were not affected. - CVE requested (work item 114): on Windows, a root certificate's name (PostgreSQLSslRootCert, or TlsCaFile with TlsMode=verify-full) whose bytes in the ANSI code page outside ASCII also read as UTF-8 could make the database's client check the server's certificate against another file than the one named; 6.2.25 to 6.3.7. Such a name is now refused with HM7534. The bundled MariaDB Connector/C and the Linux builds were not affected. - CVE requested (work item 115): on Windows, the files the server hands to OpenSSL by name (the TLS certificates' certificate and private key files, dh2048.pem, a port's client-certificate CA file, MessageStoreObjectCaFile and the files in AcmeCertificateDirectory) could, under a name with some characters outside ASCII, be read from another file than the one configured; every release up to and including 6.3.7. Each is now read from the file configured, or refused with HM7536. - CVE requested (work item 116): on Windows, the bundled MySQL and MariaDB client, MariaDB Connector/C, loads its authentication plugins from the installation's own plugin folder, one that only administrators control, or from none. - CVE requested (work item 100): the database layer's test for the marker that lets a statement's error be ignored, and the log's and the trace's redaction of a statement's literals, read a literal as each engine does. - CVE requested (work item 102): the auto-ban saves the IP range it adds under a name of its own, so that it bans the address. Up to 6.3.7 a later ban for a long user name could take a range name in use, be refused (HM6099) and leave the address unbanned, its counted failures cleared all the same, so that it was given a whole new set of attempts. - CVE requested (work item 104): a sign-in's name is matched to its account as the per-name lockout (from 6.2.22-pre2) and the compromised-account hold (from 6.3.4) count it. Up to 6.3.7 every spelling of a name that the database's own comparison took for the account signed in to it, each with a lockout threshold of its own, and an account held for review could be signed into under another spelling of its name with its password. - CVE requested (work item 105): the web services listener (CardDAV, CalDAV, Autodiscover; off by default) did not refuse an address an auto-ban or an administrator's IP range banned, which could go on guessing passwords at its sign-in; it now closes such a connection with no answer, before the TLS handshake. - CVE requested (work item 106): a failed sign-in at the web services listener through a proxy is no longer charged to the proxy's address, whose ban could shut the proxy, and every client behind it, out of the SMTP, POP3, IMAP and ManageSieve listeners; since 6.3.3 for CardDAV and 6.3.4 for CalDAV and Autodiscover. - CVE requested (work item 107): a failed account sign-in at the REST listener through a reverse proxy on the same machine is no longer charged to 127.0.0.1, whose ban then refused loopback at the mail listeners; since 6.2.28. Until the upgrade, on 6.3.2 to 6.3.7, listing 127.0.0.1 and ::1 in AutoBanNeverBan avoids it. - CVE requested (work items 110 and 111): the REST API, and the reader of a report mailed to a domain's report address, read a JSON body in time and memory that follow its bytes. From 6.3.2 an account's own password was enough to send the REST API a body that took far more time and memory to read than its size, in the service that also serves SMTP, IMAP and POP3, and from 6.3.4 the same was true of the reply to a password-protected message. A body of more than 100,000 values, an object of more than 10,000 members or more than 32 levels is now answered 400, the reply is held to 2 MB, and a TLS-RPT report is read through the bounded parse. - CVE requested, one for each case (work item 78): on Windows, setup makes or hardens the program folder, Bin and ControlPanel before it copies a file or runs a program of the installation, and refuses a folder or a link on the way to them, or a program, library or script in them, that another account controls. These are the four narrower cases that 6.3.7's notes listed as still open: a new folder, a folder already there, a link on the way to them, and a program, library or script in them. In 6.3.7 an upgrade had the three hardened only at the end of setup, by /ProtectFolders, and setup installed through any link. - CVE requested (work item 103): published with 6.3.8, the advisory for a flaw in the auto-ban on MySQL and MariaDB that 6.3.4 fixed. The release notes' Security section has more beside these. The container image secures a new installation by itself, whatever the container's command, where a docker run of the image with its own command took passwords in the clear on every port, and its two passwords no longer reach the server's environment, nor that of anything it starts, nor does HMAILSERVER_RECOVERY_PASSPHRASE when the container runs the image's own command (hardening, not a flaw). A mailbox's recovery address can no longer be sent more password-reset links than the per-address limit allows by other spellings of the address, as it could from 6.3.4. On Linux a command run as root examines and opens the folders it will work in by the names the server uses for them, and hMailServer.exe /ProtectFolders says a key or certificate file that inherits a group of every user's Read as inheriting it. One of these fixes, work item 100's, was public on GitLab from 19 October 2026 and on master from 20 October 2026, a week before it was judged a vulnerability, longer than the day SECURITY.md allows; the others were pushed with the release. The rule, that a security fix becomes public about a day before the release that ships it, holds again after 6.3.8 (SECURITY.md, "What gets a release"). What changes without a switch The full list is the 6.3.8 section of CHANGELOG.md, under "What changes on upgrade without a switch", in 29 items. Beside the notices above, in short: - Stops: work that outlasted a stop of the servers, a reinitialise among them, writes a line to the debug log where it wrote HM5136 or another code to the error log, so the error log of a server that reinitialises may be quieter; a database connection such a call held goes back to the pool; and on Linux a session or a task that went on after a stop no longer ends the process. - ACME: a name no certificate can carry (a wildcard, an IP address, a name past ASCII not in its xn-- form) is left out of the check and the order and named in the application log, where it failed every order; a CA's rateLimited answer holds every order until its Retry-After; an ACME URL that is not https is refused unless it is to this machine; and the certificate a CA sends is installed only when it is for the request's key, names every host asked for and has not expired. - The auto-ban's ranges: a ban for a long user name is named with the user name cut so that the name and its suffix fit the column, and POST /api/v1/ipranges reads a name in UTF-8, as PUT does. - Failed sign-ins through a proxy: from loopback or an address in WebServicesTrustedProxies at the web services listener, and from loopback at the REST listener, a failed sign-in is counted against the name alone (AccountLockoutThreshold, off by default, is then the limit on the guesses at one account), never towards a ban of the address. - Sign-in names: the IMAP master user's own hold, country policy and lockout are asked of its own address as well; the account.locked webhook is raised only for a locked name that is an account's own; and POST /api/v1/password-reset counts its per-address limit under the address as a sign-in compares it. - The logs: the slow-query line and the trace's db.statement read a literal as the configured database does, so a line may differ from before, and --check-database's settings line and the connection lines say what the database client checks. - spamd and Blowfish: spamd's User: header carries a name outside ASCII, where it was left out, and a name it cannot carry is sent as no header with HM5514 (new); the legacy Blowfish scheme refuses a secret it cannot carry (HM7278, new), where it wrote an empty one, and a backup's XML leaves such a secret out and names it (HM7280, new), to be entered again after a restore. - Argon2id: GET /api/v1/status's argon2id and post_quantum_key_exchange say what the library the server runs with does, and an app password raised to Argon2id where that library has none is made with scrypt and said once (HM5607), where it was an empty hash the store refused. - On Linux, hmailserver --create-database asks first whether the schema's version table is there, so a new installation no longer logs HM5033 as its first error; on Alpine a log line holding a character outside ASCII is written, where it came out empty. - The Control Panel's Logging page shows a destination never chosen as Files on disk, its Anti-spam page opens and saves a refuse threshold at or below the mark threshold, the Anti-spam overview reads the quarantine switch, and the ACME page and the Setup checklist read AcmeDomains as the server does. The PowerShell module says why a call got no answer, and hmctl takes a file that begins with a byte order mark and refuses a body holding NaN or Infinity. What is new - A host added to AcmeDomains no longer waits for the renewal, some sixty days, and a check can be asked for (work item 98). A certificate that does not name every host on the list is now due at once, a save of AcmeDomains in the running server starts the check, and GET /api/v1/acme and POST /api/v1/acme/run (COM Utilities.GetAcmeStatus and Utilities.RunAcmeCheck, and a card on the Control Deck's Certificates page) give the certificate's state and ask for a check, with the CA's rate limits and a pause after a failed attempt kept (Acme.md). - An event after an IMAP move, for scripts (work item 109): OnIMAPMessageMoved is called once for each message an IMAP MOVE or UID MOVE moved between two folders of the account signed in, after the command and off the IMAP thread. Off as shipped: IMAPMessageMovedEvents switches it on. - Rspamd learns from the Junk folder, beside SpamAssassin (work item 108). A message a user moves into Junk is taught as spam, and one moved out as ham, to the filter MoveLearningBackend names, SpamAssassin by default; nothing is sent to Rspamd until it is chosen and its controller and classifier are set (JunkFolderLearning.md). - The Linux server reaches clamd over its Unix socket: ClamAVHost takes the absolute path of clamd's LocalSocket in place of a host name (ClamAV.md). - New ways to install: an Ansible collection, progressiverobot.hmailserver (Ansible.md); a Kubernetes operator for Operator Lifecycle Manager and OperatorHub.io; and a container on Proxmox VE with one command on the host (Proxmox.md). Known issues, below, says where each stood when 6.3.8 was published. - The release's provenance is held to the pipeline that publishes it and to what GitLab certified of the run, and the documents say its SLSA level, Build L1 and no higher. - Who made what: the packages, the image, the chart, the snap and the command-line clients say that they are Progressive Robot's fork of hMailServer and credit the original's author, Martin Knafve, and the tree is REUSE-compliant, with a CI job that holds it. Reported from outside and answered besides: on-demand ACME issuance (work item 98), Rspamd learning from the Junk folder (work item 108) and an event after an IMAP move (work item 109), each asked for by ThiagoES84. Thank you. 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, the provenance and the provenance's envelope, 161 files. - Windows: hMailServer-6.3.8-x64.exe, and hMailServer-6.3.8-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). - Linux, x86-64 and AArch64: the generic hmailserver_6.3.8_amd64.deb, hmailserver_6.3.8_arm64.deb, hmailserver-6.3.8-1.x86_64.rpm and hmailserver-6.3.8-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.8-1~_.deb or hmailserver-6.3.8-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.8-x86_64.AppImage and hMailServer-6.3.8-aarch64.AppImage, and beside them the source of the libraries they carry and of those their runtime links, hmailserver-6.3.8-appimage-bundled-sources.tar.gz and hmailserver-6.3.8-appimage-runtime-sources.tar.gz. - The source tarball, hmailserver-6.3.8.tar.gz; the Helm chart, hmailserver-chart-6.3.8.tgz, the first published chart that starts a server; 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.8-SHA256SUMS.txt, the SHA-256 of every Linux file; and, beside the 62, hmailserver-6.3.8.intoto.sigstore.json, SLSA v1 build provenance that names each of them by its SHA-256. - New in 6.3.8, hmailserver-6.3.8.intoto.jsonl: the DSSE envelope inside the provenance's Sigstore bundle, the statement and its one signature byte for byte as the bundle has them, written alone as one line of JSON. It is not a second signature, and it carries neither the certificate nor the transparency log's entry, which only the bundle carries: the bundle is the file to verify with. The container image, registry.gitlab.com/hmailserver/hmailserver:6.3.8, 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 and 6.3.7's were; it carries MariaDB Connector/C beside PostgreSQL's client. 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. The chart is also in the project's Helm repository, https://updates.progressiverobot.com/helm/. The channels are sent 6.3.8 by jobs started by hand on master once the release is published, each verified against the release's bundles: the Ubuntu PPA, Fedora Copr, Docker Hub, Chocolatey (a version is listed once its moderators have approved it), PyPI and the PowerShell Gallery; the openSUSE Build Service once its package holds this release's new _service, keeping 6.3.7 until then; and the snaps, to the Snap Store's edge and candidate channels, stable being promoted by hand. 6.3.8's snaps are the first there, since 6.3.7's were never uploaded (Channels.md). https://updates.progressiverobot.com/download/ leads to the newest stable release's page, and updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hmailserver_amd64.deb, /download/hmailserver.x86_64.rpm and the rest of the download links UpdateFeed.md lists to that file of it, never to a pre-release; add .cosign.bundle for the bundle. Verification Every file is signed with Sigstore by the project's GitLab CI pipeline for the tag v6.3.8, and was checked before publication with hmailserver --verify-update, built from the same commit, 3a2fc29b7fb52a27e7c1a6b8e25c99d94a4756ba. The certificate's identity is https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.8, 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 or deleted: cosign verify-blob --bundle hMailServer-6.3.8-x64.exe.cosign.bundle \ --certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.8' \ --certificate-oidc-issuer https://gitlab.com hMailServer-6.3.8-x64.exe jq -r .verificationMaterial.certificate.rawBytes hMailServer-6.3.8-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. From the source tarball, python3 build/ci/sigstore-certificate.py repository-id .cosign.bundle reads the id as the server does and prints id=86730559. 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.8.intoto.sigstore.json --type slsaprovenance1 \ --certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.8' \ --certificate-oidc-issuer https://gitlab.com hmailserver_6.3.8_amd64.deb That check takes the bundle, hmailserver-6.3.8.intoto.sigstore.json, not hmailserver-6.3.8.intoto.jsonl, which holds the same envelope without the certificate. Then sha256sum -c --ignore-missing hmailserver-linux-6.3.8-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 4b9b9c3102cbed743f6c826289c54cec25c395d02208e55cdd3219187fbf8654 and the ARM64 installer's e5ce357b9ca4e013529898c5208d43895fec3a397b1a4defa4cd905ee9b7f27a. 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.8 must report a good signature by the key that file lists. The release's own notes, at https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 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/3016341592, ran every gate before anything was published: the Windows suite, in two halves on the project's two Windows benches, 4,569 tests, 4,489 passed, 0 failed, 80 skipped; the Linux suite on one of the project's Linux runners, 2,749 tests, 2,374 passed, 0 failed, 375 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 start of the generic x86-64 .deb and of the generic AArch64 .deb and .rpm against a database; the REUSE check; 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.7 passed 105 checks and a new installation 65, none failed. The published chart, installed from the project's Helm repository into a one-node cluster, started its pod with 6.3.8's image and answered SMTP with STARTTLS and the REST API over TLS. Known issues - The ARM64 installer has never run on ARM64 hardware: it is cross-compiled on the project's x64 Windows runner and remains a preview (WindowsOnArm.md). The AArch64 Linux files are cross-compiled, and installed, the generic .deb and .rpm started as well, in the release's pipeline under emulation: no AArch64 machine has run them. If you install either, please say how it went, working or not, in an issue on GitLab. - The channels are sent 6.3.8 by jobs started by hand (Downloads, above). The Ansible collection was not on Ansible Galaxy when 6.3.8 was published, and the one in 6.3.8's tree installs 6.3.7 unless it is given another release's SHA-256; the operator's pull request to OperatorHub.io is made by hand. - The Proxmox VE scripts have not run on a Proxmox VE host, only as a dry run, with stand-ins of its commands, and in a container made from its own debian-13-standard template. If you run them, please say how it went in an issue. - The image's OpenSSL, Ubuntu 24.04's 3.0.13, has neither the hybrid post-quantum key exchange groups nor Argon2id: its server logs HM5720 and takes the classical groups and scrypt, and GET /api/v1/status says false for both. - 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. 6.3.8 was first decided on 24 October 2026, under the owner's delegation, because the published Helm charts of 6.3.6 and 6.3.7 start no server, and neither the chart nor the image of a release can be put right but by a release; the project's own work since found the vulnerabilities above, and 6.3.8 is made as a security release, that reason standing beside them. 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.7, 6.2 or anything older is upgraded in place to the newest release. To hear of a 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 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. Open an issue at https://gitlab.com/hmailserver/hmailserver/-/issues/new; the work items, 6.3.8's among them, are listed at https://gitlab.com/hmailserver/hmailserver/-/work_items. The release is also mirrored on GitHub, at https://github.com/RainbowWizard-coder/hMailServer/releases/tag/v6.3.8; GitLab stays canonical and the one place the project is worked on, and the repository on GitHub takes no issues. Questions go to the forum, https://www.hmailserver.co.uk/, where 6.3.8 is announced at https://www.hmailserver.co.uk/topic/28278; give the full build stamp on Windows, 6.3.8.47 for 6.3.8, or the exact package version on Linux. Report a vulnerability privately, as SECURITY.md says: 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.