--- title: "hMailServer 6.3.8: security fixes for every earlier version, read before upgrading, and a Helm chart that starts a server" url: https://www.hmailserver.co.uk/topic/28278/hmailserver-6.3.8-security-fixes-for-every-earlier-version-read-before-upgrading-and-a-helm-chart-that-starts-a-server author: "chris" published: 2026-11-02T17:38:36.759Z updated: 2026-11-02T17:38:36.759Z category: "Announcements & releases" tags: [] site: hMailServer Community Forum --- # hMailServer 6.3.8: security fixes for every earlier version, read before upgrading, and a Helm chart that starts a server hMailServer 6.3.8, Progressive Robot's fork of hMailServer, was published on 2 November 2026. It is a security release: it fixes vulnerabilities the project found in its own code, each a work item with a CVE request through GitLab's CNA, and the four narrower cases of work item 78 that 6.3.7's notes left open. Between them they reach back to 6.0.0's first beta: **upgrade every server running 6.3.7 or earlier.** It 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, and that reason stands beside the fixes; 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. The schema stays at 6108: from 6.3.6 or 6.3.7 the upgrade changes no table. **Who is affected, and what to do** - **Every server running 6.3.7 or earlier: upgrade.** "What 6.3.8 fixes" lists the vulnerabilities, each with its work item and CVE request; "Upgrading" says how each version upgrades. - **Read "Before you upgrade" first.** Some fixes change what an upgraded server does, above all for `TlsMode=verify-full` without `TlsCaFile` to a MySQL or MariaDB server on the same machine, for file names outside ASCII, and for sign-in names spelt otherwise than the stored address. - **Anyone who installed the Helm chart of 6.3.6 or 6.3.7:** its pod never started. Move the release to 6.3.8's chart as "Before you upgrade" says. - **Anyone running the container image against MariaDB:** the images of 6.3.7 and earlier could not reach it; 6.3.8's carries MariaDB's client library, and the release's pipeline starts each platform's image beside MariaDB and asks it for SMTP, the REST API and the schema it laid out. - **Windows, on the original hMailServer's 5.7 - 5.7.0 and its pre-release builds 2788 and 2843, 5.7.1 or 5.7.2:** this fork's installers of 6.3.7 and earlier must never be run over it; 6.3.8's refuses it before it changes anything. Move such a server's mail over IMAP instead ([Migration.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/Migration.md), "From the original hMailServer"). **Before you upgrade** The 6.3.8 section of [CHANGELOG.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/CHANGELOG.md), "What changes on upgrade without a switch", lists what an upgraded server does differently with no setting turned. These are the most likely to need something done: - **Back up the database and the data directory**, each with its own tools ([Upgrading.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/Upgrading.md)). 6.3.8 adds no schema step; from 6.3.5 or older the upgrade runs 6.3.6's three one-way steps to 6108, and the backup is the only way back. From 6.3.6 or earlier, 6.3.7's "Before you upgrade" and its list hold as well, and from 6.3.5 or earlier 6.3.6's list. - **A Helm release of the 6.3.6 or 6.3.7 chart:** `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 never replaces the stuck pod by itself; `--reuse-values` instead keeps the old chart's `fsGroup` 1000 and `database.port` 5432. Where a cluster's policy refuses every sysctl, set `unprivilegedPortsSysctl: false`. - **A Compose deployment made from an earlier Compose file:** keep 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 does not start. - **ACME: `AcmeDomains` listing a host the certificate lacks.** The first check orders a certificate for every host on the list; a host the CA cannot validate fails the whole order, at most three times an hour, and holds the renewal for the other hosts: take it off the list first. - **`TlsMode=verify-full` on MySQL or MariaDB without `TlsCaFile`, to a database server on this machine:** through MariaDB Connector/C, the client the Windows installer bundles and the Linux server loads, 6.3.8 refuses the connection with HM7535. Name in `TlsCaFile` a CA that issues nothing but the database's certificates, the one that issued its certificate, or set `TlsMode=require`, before upgrading ([DatabaseTls.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/DatabaseTls.md)). - **On Windows, a file whose path holds characters outside ASCII** - the database's `TlsCaFile` or `PostgreSQLSslRootCert`, a TLS certificate or private key file, `dh2048.pem`, a client-certificate CA file, `MessageStoreObjectCaFile`, `OAuth2PublicKeyFile` or `AcmeCertificateDirectory`: 6.3.8 may refuse its name, with HM7534 or HM7536, and then the database is not reached, or what the file is for does not work. Give each such file, and the folders above it, an ASCII name before upgrading. - **A Linux server that ran under a `LANG` that is not UTF-8**, with files or folders named outside ASCII: 6.3.8 names files in UTF-8 whatever `LANG` says, so rename each to its UTF-8 name before upgrading, for example with `convmv -f iso-8859-1 -t utf-8 -r --notest `. - **IP ranges of your own that allow some addresses none of SMTP, POP3 and IMAP**, with the web services listener on: such a range now closes that listener to those addresses too, and with it ACME's http-01 validation there, MTA-STS, CalDAV, CardDAV, Autodiscover, autoconfiguration and the Web Key Directory, so 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 writes a member whose absence is the wider setting as another type than its route reads: the server answers it with 400. - **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: it may no longer sign in. Correct the name in the client. - **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. - **On Windows, a program folder, `Bin` or `ControlPanel`, or a folder or a link on the way to them, that another account than SYSTEM, the Administrators and TrustedInstaller controls:** setup refuses it with exit code 7, naming the `icacls` that deals with it, and asks for a restart of Windows before it runs again ([ServiceAccount.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/ServiceAccount.md)). - **Monitoring that counts the error log, or an OnError script, during a stop:** a stop's interruption is now a line in the debug log, and 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** is installed only where none is, so an upgraded server keeps the one it had: bring it up to date through Microsoft Update. **What 6.3.8 fixes** The vulnerabilities first, each found by the hMailServer project (Progressive Robot Ltd), each work item public now and each with a CVE request through GitLab's CNA; the 6.3.8 section of `CHANGELOG.md`, linked above, gives each, with how it is tested. - **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** ([work item 100](https://gitlab.com/hmailserver/hmailserver/-/work_items/100), CVE requested). - **The auto-ban saves the IP range it adds under a name of its own, so that it bans the address** ([work item 102](https://gitlab.com/hmailserver/hmailserver/-/work_items/102), CVE requested). - **A sign-in's name is matched to its account as the per-name lockout and the compromised-account hold count it** ([work item 104](https://gitlab.com/hmailserver/hmailserver/-/work_items/104), CVE requested). - **The web services listener (CardDAV, CalDAV, Autodiscover) refuses an address an auto-ban or an IP range bans** ([work item 105](https://gitlab.com/hmailserver/hmailserver/-/work_items/105), CVE requested). - **A failed sign-in at the web services listener through a proxy is no longer charged to the proxy's address** ([work item 106](https://gitlab.com/hmailserver/hmailserver/-/work_items/106), CVE requested). - **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** ([work item 107](https://gitlab.com/hmailserver/hmailserver/-/work_items/107), CVE requested). - **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** ([work item 110](https://gitlab.com/hmailserver/hmailserver/-/work_items/110), CVE requested; [work item 111](https://gitlab.com/hmailserver/hmailserver/-/work_items/111), CVE requested). - **`TlsMode=verify-full` on MySQL and MariaDB checks the database server's certificate against the CA file `TlsCaFile` names** ([work item 112](https://gitlab.com/hmailserver/hmailserver/-/work_items/112), CVE requested). 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. On Linux the client is the distribution's, which should be Connector/C 3.4.11 or later; where it is older and not patched, name the CA in `TlsCaFile`. - **The database client's `TlsMode=verify-full` check of a database server on this machine, on MySQL and MariaDB** ([work item 113](https://gitlab.com/hmailserver/hmailserver/-/work_items/113), CVE requested). - **On Windows the database clients check the database server's certificate against the root certificate file named, or refuse its name** ([work item 114](https://gitlab.com/hmailserver/hmailserver/-/work_items/114), CVE requested). - **On Windows the files the server hands to OpenSSL by name are read from the file configured, or refused** ([work item 115](https://gitlab.com/hmailserver/hmailserver/-/work_items/115), CVE requested). - **On Windows the bundled MySQL and MariaDB client, MariaDB Connector/C, loads its authentication plugins from the installation's own plugin folder, or from none** ([work item 116](https://gitlab.com/hmailserver/hmailserver/-/work_items/116), CVE requested). - **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** - the four narrower cases of [work item 78](https://gitlab.com/hmailserver/hmailserver/-/work_items/78) that 6.3.7's notes listed as still open, each with a request of its own: a new folder (CVE requested), a folder already there (CVE requested), a link on the way to them (CVE requested), and a program, library or script in them (CVE requested). - **Published with it: the advisory for a flaw in the auto-ban on MySQL and MariaDB that 6.3.4 fixed** ([work item 103](https://gitlab.com/hmailserver/hmailserver/-/work_items/103), CVE requested). The other fixes and changes an administrator meets: - **The Helm chart starts a server.** The charts of 6.3.6 and 6.3.7 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. 6.3.8's chart runs the pod as the image's user by number, 999:999, fills new volumes in an init container and secures a new installation at its first start, as the packaged systemd unit does; so does the Compose file. - **The container image reaches a MariaDB database.** It carries MariaDB Connector/C now, and the release's pipeline starts each platform's image beside PostgreSQL and beside MariaDB and asks each for SMTP, the REST API and the schema it laid out; a chart told `MySQL` no longer dials MariaDB on PostgreSQL's port. Found by the project's own audit of its listings. Its entrypoint also secures a new installation by itself, whatever the container's command, and takes the database and administrator passwords out of the environment before it runs any program. - **The Windows installer refuses an installation of the original hMailServer's 5.7.** Both projects' installers register as `hMailServer_is1`, so those of 6.3.7 and earlier took the original's 5.7 builds of August and September 2026 (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 refuses such an installation before it changes anything; silent, it ends with exit code 1 and writes the reason to its log and to `hMailServer-setup-refused.txt` in `%TEMP%`. Installations of this fork, and of the original up to 5.6 and its 5.7 development builds up to schema 5708, are upgraded as before. - **A host added to `AcmeDomains` no longer waits for the renewal, and a check can be asked for** ([work item 98](https://gitlab.com/hmailserver/hmailserver/-/work_items/98), `ThiagoES84`). A certificate that does not name every host on the list is now due at once, and `GET /api/v1/acme`, `POST /api/v1/acme/run`, COM and the Control Deck's *Certificates* page give its state and ask for a check, with the CA's rate limits kept ([Acme.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/Acme.md)). - **An event after an IMAP move, for scripts** ([work item 109](https://gitlab.com/hmailserver/hmailserver/-/work_items/109), `ThiagoES84`). `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](https://gitlab.com/hmailserver/hmailserver/-/work_items/108), `ThiagoES84`). 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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/JunkFolderLearning.md)). - **A stop of the servers is no longer reported as errors of their own.** Work that outlasted a stop wrote its interruption to the error log as a failure and ran an installed OnError script; it now writes a line to the debug log and ends as the stop asked, a database connection it 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. - **Also:** a REST request body meant to be JSON must be one JSON object; on Linux a file's name outside ASCII is one name, UTF-8, whatever `LANG` says; the Linux server reaches clamd over its Unix socket; and the command-line clients and the Control Panel have fixes of their own. - **New ways to install:** an Ansible collection, a Kubernetes operator for Operator Lifecycle Manager, and a container on Proxmox VE ([Proxmox.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/Proxmox.md)), whose scripts have not yet run on a Proxmox VE host. 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. **Upgrading** - **By the live update, from 6.3.7 or 6.3.6.** 6.3.8 is signed with Sigstore as its own pipeline at the project's group path, with the project's id, 86730559, in the certificate, a signer every server from 6.3.4 on has compiled in; the running version's own file is its rollback image. A Windows service running as LocalSystem installs it itself; for one running 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 Linux the installed version's update helper applies it to the generic `.deb` and `.rpm` and both AppImages. - **From 6.3.4 or 6.3.5**, as 6.3.7's notes said: a service running as LocalSystem installs 6.3.8 by its live update; for one running as `NT SERVICE\hMailServer`, download `hMailServer-6.3.8-x64.exe`, check that `Get-AuthenticodeSignature` says `Valid` for `CN=Progressive Robot Ltd`, and run it as an administrator, once, keeping the service account on the installer's *Service account* page (SmartScreen's *More info* names Progressive Robot Ltd, and *Run anyway* installs it). On Linux, install it with `apt`, `dnf` or `zypper` rather than by the live update, or turn the live update's apply off first with `systemctl disable --now hmailserver-update.path`. - **A server 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 release's own package of 6.3.8. - **A server whose `UpdateSigningIdentity`, `UpdateSigningIssuer` and `UpdateSourceRepository` still name the path the project began at** refuses 6.3.8: clear the three first ([UpdateFeed.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/UpdateFeed.md)). - **By hand, from 6.2.28 to 6.3.3, or on Linux from 6.3.3's AArch64 packages or AppImages:** those versions trust only the GitHub workflow that signed the releases up to 6.3.3, so run `hMailServer-6.3.8-x64.exe` over the installation, install the package with `apt` or `dnf`, or replace the AppImage, once; keep `UpdateAutoDownload` off there until then. - **Older than 6.2.28:** run 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. - **The container image**, `registry.gitlab.com/hmailserver/hmailserver:6.3.8`, also tagged `6.3` and `latest`, for linux/amd64 and linux/arm64. In the container the update check names the image to pull and installs nothing ([ContainerImage.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/ContainerImage.md)). **What the release carries** 62 files, each with its Sigstore bundle, `.cosign.bundle`, beside it: the x64 and ARM64 Windows installers, Authenticode-signed; the generic `.deb` and `.rpm` and each supported distribution's own package, for x86-64 and AArch64; both AppImages, and beside them the source of the libraries they carry and of those their runtime links; the source tarball; the Helm chart; the PowerShell module; an SBOM for each compiled file and the tarball, and the source tree's two; and `hmailserver-linux-6.3.8-SHA256SUMS.txt`. Beside them, `hmailserver-6.3.8.intoto.sigstore.json` is SLSA v1 build provenance that names each of them by its SHA-256, and `hmailserver-6.3.8.intoto.jsonl` the same as one line of JSON. `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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/UpdateFeed.md#the-download-links) to that file of it. **How to check a download** With [cosign](https://docs.sigstore.dev/cosign/) and OpenSSL, with the file and its bundle beside you: ``` 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 ``` The first must say `Verified OK`, and the second print `..86730559`, the project's own id, which cosign does not check. `sha256sum -c --ignore-missing hmailserver-linux-6.3.8-SHA256SUMS.txt` must say `OK` for each Linux file; on Windows, `Get-AuthenticodeSignature` on either installer must answer `Valid`, signed by `CN=Progressive Robot Ltd`, and the x64 installer's published SHA-256 is `4b9b9c3102cbed743f6c826289c54cec25c395d02208e55cdd3219187fbf8654`. [SECURITY.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/SECURITY.md#verifying-a-release), "Verifying a release", gives the other checks - the tag's signature and a file against the build provenance among them - and [ContainerImage.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/ContainerImage.md) the image's and the chart's. **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](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/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](https://gitlab.com/hmailserver/hmailserver/-/issues/new). - **The channels are sent 6.3.8 by jobs started by hand** once the release is published: the Ubuntu PPA, Fedora Copr, Docker Hub, Chocolatey (listed once its moderators approve it), PyPI and the PowerShell Gallery; the openSUSE Build Service once its package holds this release's new `_service`, until then keeping 6.3.7; and the snaps on the Snap Store's `edge` and `candidate` channels, `stable` being promoted by hand. The Ansible collection is not on Ansible Galaxy yet, and the one in the 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 ([Channels.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.8/hmailserver/docs/Channels.md)). - **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](https://gitlab.com/hmailserver/hmailserver/-/issues/new). - **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. **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 it holds then, until the maintainers say otherwise in [SECURITY.md](https://gitlab.com/hmailserver/hmailserver/-/blob/master/SECURITY.md#while-releases-pause), "While releases pause". A confirmed vulnerability still ships: a critical or high one as soon as its fix has passed the gates, and none held past 90 days from its acknowledgement. 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, which only a release can put right; 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. One of its 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 6.3 line receives security fixes until 30 September 2027. To hear of a release, switch the server's update check on (`UpdateCheckEnabled`), or follow [the releases' feed](https://updates.progressiverobot.com/releases.atom). **Reporting a vulnerability** Not in a thread here, and not in a public issue. Report it privately, as [SECURITY.md](https://gitlab.com/hmailserver/hmailserver/-/blob/master/SECURITY.md#reporting-a-vulnerability) says: a [confidential issue on GitLab](https://gitlab.com/hmailserver/hmailserver/-/issues/new?issue[confidential]=true) - check that it is still marked confidential before you submit it, and choose the **Security** template - or an email to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue, so no GitLab account is needed. [Release notes, checksums and downloads](https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8) · [Mirror on GitHub](https://github.com/RainbowWizard-coder/hMailServer/releases/tag/v6.3.8) · [Newest stable release](https://updates.progressiverobot.com/download/)