hMailServer on Linux: what you get and what you do not

Written for 6.3.4. hMailServer 6.3.8 (2 November 2026) is the current release, a security release: its Linux packages are, as 6.3.7's (17 October 2026) were, the generic .deb and .rpm for x86-64 and AArch64, a package for each of Debian 12 and 13, Ubuntu 24.04, Fedora 43 and 44, Enterprise Linux 9 and 10 and openSUSE Leap 16.0 and Tumbleweed, and both AppImages, and its container image is registry.gitlab.com/hmailserver/hmailserver:6.3.8; the AArch64 files are cross-compiled and tested under emulation, and the Ubuntu PPA and Fedora Copr, which have published 6.3.7 since 21 October 2026, are sent it by a job started by hand. From 6.3.6 or 6.3.7 the live update installs it through the root helper, for the generic packages and the AppImages; a server from one of 6.3.6's or 6.3.7's per-distribution packages upgrades with its package manager and its release's own package, and from 6.3.4 or 6.3.5 install it with apt, dnf or zypper. 6.3.8 names files in UTF-8 whatever LANG says, so on a server that ran under a LANG that is not UTF-8, rename each file and folder named outside ASCII to its UTF-8 name before upgrading. See the 6.3.8 announcement.

Since 6.3.0 the same source tree builds, installs and delivers mail on Linux, as a systemd service, from a .deb, an .rpm or an Arch PKGBUILD: on x86-64 and AArch64 up to 6.3.3, and on x86-64 only in 6.3.4's packages. That is why the release is numbered 6.3 and not 6.2.29. Read §35.1 before you install anything. Finding out about a missing capability after the mailboxes are populated is the wrong order.

What crossed

The SMTP, POP3 and IMAP engines, delivery, routing, rules, anti-spam, anti-virus, ACME, the backup manager, the REST API, the Control Deck and the self-service portal. The on-disk message format is unchanged: one directory per domain and per mailbox, one file per message. The database schema is the same version the Windows build of the same release needs.

The packages

6.3.4's .deb installs with apt on Ubuntu 26.04, where it is built, and on Ubuntu 24.04. It needs glibc 2.38 or later, so it does not install on Debian 12. Its .rpm installs with dnf on Fedora 43 and 44 and Enterprise Linux 10, not on Enterprise Linux 9, whose glibc and libstdc++ are older than it asks for, and nothing has been tried with openSUSE's zypper. There is no apt or dnf repository yet. Arch is a PKGBUILD in the tree, built with makepkg -si from the git tag, which it clones from https://gitlab.com/hmailserver/hmailserver. 6.3.4's packages are x86-64 only: the AArch64 packages were last published with 6.3.3, built natively on the CI the project lost with its GitHub account. Nothing else is packaged.

The AppImage is not for running mail. It runs as whoever started it, with no hmailserver user, no unit and none of the systemd hardening, it puts its store under the invoking user's home directory, and it cannot bind port 25. Use it to see the thing work on a laptop. 6.3.4 has none; the last AppImage is 6.3.3's. §35.2.

Where things live

Configuration is /etc/hmailserver/hMailServer.ini at 0640 root:hmailserver. The store is /var/lib/hmailserver, the logs /var/log/hmailserver, the unit /usr/lib/systemd/system/hmailserver.service. The service runs as hmailserver:hmailserver and never as root. Full table: §35.6.

The backends are PostgreSQL through libpq, a link-time dependency, and MySQL or MariaDB through a client loaded with dlopen at run time, which nothing pulls in for you. SQL Server and SQL Server Compact are refused by name, so an INI carried across from Windows is repointed or it does not start.

The gaps, stated plainly

• No Control Panel and no COM API. Both are Windows-only and are not compiled here. Every third-party COM script stops at that boundary.
• Event scripts in JavaScript only, since 6.3.4. EventHandlers.js runs in an embedded QuickJS engine, for the same events under the same function names; the scripting language must be set to JavaScript (hmctl settings set scripting --set-string language=JavaScript), and VBScript and JScript are refused. Scripting is off until you turn it on. A script has no file, process or network access and cannot create COM objects, so a Windows script is ported, not copied (EventScripts.md).
• Domain properties were not writable when Linux arrived, and are now. At 6.3.0 per-domain DKIM, per-domain size limits and the domain signature were readable over REST and not writable. 6.3.3 made PUT /api/v1/domains/{domain} take the whole domain - its DKIM signing, its limits, its signature and its relay host among the rest - and gave the Control Deck full domain editing. At 6.3.4 the project's census finds 458 of the 466 properties the Windows Control Panel writes writable over REST and reachable from a Deck view, and the eight it lists as missing, an account's directory fields, are written on a route of their own, PUT /api/v1/accounts/{address}/directory, which the Deck's account editor uses (DeckParity.md).
• Self-update from 6.3.4, but not to it. The packages now install hmailserver-update, a root helper outside the server's unit, and the live update, when an administrator asks it to install, applies a .deb, an .rpm or an AppImage through it, rolling back when the server does not come back. The update check is off until you turn it on. 6.3.4 itself carries no Sigstore bundle, so no live update installs it: every server reaches 6.3.4 with apt or dnf, and the helper has nothing to apply before a release signed on the project's GitLab CI. Arch upgrades with pacman.
• No tested path from Windows. The schema and the store format are shared, so the pieces are there. Nobody has run a Windows installation onto Linux and verified the result. §35.14 says what is known.

Administration is therefore the Control Deck at / on the REST listener, and the REST API behind it. §35.10 covers the daily jobs.