This release is superseded by hMailServer 6.3.7, published on 17 October 2026, which fixes security flaws in every earlier version, 6.3.6 included. Read its announcement before upgrading.
hMailServer 6.3.6 was published on 6 October 2026. It fixes the security flaws the project's own reviews of the code found, those listed under Security below with their CVE identifiers among them, and takes OpenSSL 4.0.3 into the Windows installers. It also fixes what 6.3.5's release and the first live updates from 6.3.4 found, replaces with the project's own code the last code in the server whose licence a distribution would have had to settle, and carries every file its pipeline makes, the ARM64 Windows installer (a preview) and the AArch64 Linux packages among them. The schema moves from 6105 to 6108 in three one-way steps. 6.3.6 is the last release for the time being: after it the project makes security releases only (below).
Who is affected, and what to do
Every server running 6.3.5 or earlier: upgrade. The security section below says why.
Before upgrading, read "Before you upgrade". Some changes alter what an upgraded server does without anything being switched on - above all for a server whose DNS resolver strips DNSSEC, for external accounts, for scripts that use COM, for programs that read a Windows server's logs or mail as an ordinary account, and for administrators who run the store commands or install by script.
On 6.3.4 or 6.3.5: the live update installs 6.3.6, with the exceptions under "Upgrading".
On 6.2.28 to 6.3.3, or on a Linux server from an AArch64 package or an AppImage: upgrade by hand, once. Those versions trust only the GitHub workflow that signed the releases up to 6.3.3.
Older than 6.2.28: run the installer, as always; the upgrade chain runs from every earlier hMailServer version.
Before you upgrade
Back up the database and the data directory. The three schema steps are one-way: 6106 gives external accounts' days to keep messages one meaning (below); 6107 finishes the greylisting key - a sender whose old row it deletes is greylisted once more, and on a large hm_greylisting_triplets it keys the old rows before its transaction, committing as it goes; 6108 adds the never-ban list by reverse name and each SMTP listener's choice of what it does with AUTH. From 6.3.3 or older the upgrade runs 6.3.4's steps first, and 6.3.4's notes apply.
Mail can stop flowing if your DNS resolver strips DNSSEC. With DANE on, as it is by default, an MX or TLSA lookup that does not come back whole - no answer, SERVFAIL, a signed zone's answer without its signatures or without its proof that no records exist - no longer counts as "unsigned": the host is not used, and a delivery with no host left is deferred with 4.7.0. A server whose resolver cannot answer DNSSEC queries, or behind a firewall that drops DNS answers longer than 512 octets, now defers its mail to most domains, and says so in each deferral and in the application log ("DNSSEC: the root zone's keys did not validate"). Make the resolver answer DNSSEC queries (any current public or ISP resolver does), or set DaneEnforcementEnabled to 0. A private name under a signed public domain, answered by an internal DNS server, needs a route.
Outbound TLS defers more. A host that the destination's TLSA records or MTA-STS policy require TLS of, and that offers no STARTTLS, is deferred with 450 4.7.0 where the message bounced; a host with only DANE-TA records whose certificate does not meet them is deferred where it was delivered to as if no record were published.
External accounts: days to keep messages means one thing now. -1 deletes each message on the remote server once collected, 0 leaves every message there, N deletes it N days after collection - for POP3 and IMAP alike. From 6.2.25 to 6.3.5 the IMAP fetcher read 0 and -1 the other way round, and the Control Panel, the Deck, the webmail and the REST API described that reversed meaning. The upgrade keeps every account doing what it did or stops it deleting. Afterwards, look at your IMAP external accounts (one that was emptying its remote INBOX now shows -1 and goes on until you set 0) and your POP3 accounts at -1 (they go on deleting until you set 0). A script that writes the value, or an OnExternalAccountDownload script that answers 1 for an IMAP account, follows the one meaning from now on. A webmail or Deck page left open across the upgrade has a change with a negative number refused (409, reload the page) until it is reloaded.
A script outside the service that uses COM, on a server with an administrator password. Utilities.BlowfishEncrypt, BlowfishDecrypt, ResolveMXRecords, GetMailServer, IsLocalHost, CheckSieveSyntax, EvaluateSieveScript and CriteriaMatch answer only a caller that has signed in: create hMailServer.Application, call Authenticate, and use that object's Utilities. A message or fetch account the script creates itself works only while the same program holds an Application it signed in on; or make the message with the new Application.CreateMessage() after Authenticate. Attachments.Add and Attachment.SaveAs are the server administrator's alone, and mail a script signed in as an account sends must be from an address that account may send as. Event scripts in the service, the Control Panel and the shipped DecryptBlowfish.vbs need no change.
Windows: the data, log, temp, database and event folders and hMailServer.INI become private to SYSTEM, the Administrators and the service, at every installation and upgrade, whatever account the service runs as; on a large message store the first run takes minutes. A script, a backup program or a monitoring agent that read the logs or the message store as an ordinary account, or an administrator's own program not run as administrator, needs an entry of its own (icacls "<folder>" /grant "<account>:(OI)(CI)RX"), which later runs keep. The Control Panel not run as administrator says Could not read the file on its live log page and its message-store check. An editor that saves hMailServer.INI by replacing the file gives it Bin's permissions again: run hMailServer.exe /ProtectFolders as an administrator after it (ServiceAccount.md, "What the other users of the computer may read").
The administrator's commands. hMailServer.exe's command lines (all but the service's own) no longer write to the error log or the Application log: what they did and why they failed is on their own output, so a script that read the error log after one reads the output instead. The store commands (--compress-store, --encrypt-store, --recount-store, --measure-store and the rest) and the object-store copies stop, naming it, when the data folder holds a junction, mount point or symbolic link that the administrators do not alone control: a junction made in the data folder, or at a drive's root, is refused until it is given permissions only the administrators may change (ServiceAccount.md, "What an administrator's command writes"). The grant Setup makes again at each upgrade of a service running as NT SERVICE\hMailServer goes through a junction on the way to Data, Logs or Database on the same terms, where it refused every one, and still refuses one the administrators do not alone control, naming who may change it, which fails the upgrade: give such a junction to the administrators first. On Linux such a command run as root first becomes the service's account, and refuses (exit 2), naming why, when the way to the data directory is not root's and its owner's alone; over a data directory root owns it runs on as root only where no other account could have put a link where it goes.
Installing by script. The installer now exits 10 when a step after its files did not complete and the database is as the earlier version left it, and 11 once its database step has changed the database; it exited 0. /GrantServiceAccess that cannot read the database ends in 7 unless an administrator confirmed.
The live update's trust is read from hMailServer.ini alone. UpdateSigningIdentity, UpdateSigningIssuer, UpdateSourceRepository, UpdateTrustRootsFile and UpdateLogPublicKeyFile are read from the file's [Settings] section, and COM and the REST API (409) refuse a change to them. Most servers set none of the five. One that set a signer of its own over REST, the Deck or the Control Panel puts it in the file and restarts the service; where several servers share a database, put it in every server's file before the first is upgraded.
Three settings left from 6.3.5's by-hand route. A server whose UpdateSigningIdentity, UpdateSigningIssuer and UpdateSourceRepository still name the project's first path refuses 6.3.6. Clear the three first, in the Control Panel, with DELETE /api/v1/settings/ini/<name> or on Linux with hmailserver --set-setting <name>=, not in the file, which 6.3.4 and 6.3.5 put back.
Behind a reverse proxy. The REST listener's loopback port now answers only localhost, an IP address, the server's host name and the host of each configured outside address of the webmail, and refuses any other Host with 421. If your proxy forwards the browser's own Host, set that name as the webmail's outside address (for example confidential_base_url) or as the server's host name before upgrading. The proxy must pass the Control Deck's page through unchanged.
Port 25. An upgraded server's SMTP listeners stay On and still take AUTH on port 25, so nobody is banned on the morning of the upgrade. The setup checklist's new item No password on port 25 says so: move clients that sign in on 25 to 587, then set port 25 to Honeypot or Off, on which the first AUTH bans the address. A new installation's port 25 is a Honeypot.
URI block lists. The SURBL test now asks each list about every domain a message links to, up to 200 - up to 256 DNS queries per list for a message with many links, where it was 16 - and a message whose links name more than 200 domains scores the new setting SurblTooManyDomainsScore, 5 by default, which is the stock mark threshold. A list's error answers are never a listing: a list of your own that answers 127.0.0.1 for a listing no longer tags anything - have it answer another address, such as 127.0.0.2. A sender list's URL entry written as a reversed address (1.2.0.192 for 192.0.2.1) no longer matches: write the address itself.
ManageSieve (off by default) is held to deadlines: a command line within 30 seconds, sign-in within 60, a literal 300. Before signing in an address has one connection served at a time, and a connection that runs out of time before signing in counts as a failed logon for the auto-ban (never from the loopback address). A signed-in session ends after ten idle lines in a row or two minutes of waiting in all, and an account has at most four sessions.
IP addresses written in text are read the same way on Windows as on Linux: four decimal parts, or IPv6 as RFC 4291 writes it. A value kept in an older form (192.168.1, 010.0.0.1, an address with a port) is read the new way from the first start: an API key's source restriction so written refuses the key from every address, a REST, web-services or SNMP bind address so written leaves that listener stopped, and an AutoBanNeverBan entry so written protects nothing (HM6524).
Webmail S/MIME. A correspondent's certificate is kept for encrypting replies only when its chain is trusted, under the message's From address, and a different one only when the reader chooses Keep this certificate. Certificates kept before the upgrade stay: review them on the webmail's Security page.
Windows, account retention. From 6.2.25 to 6.3.5 an account saved through a webmail's password or out-of-office plugin could have its retention overwritten: after upgrading, check the retention of the accounts whose holders use such a plugin.
The packaging Compose file runs PostgreSQL 18. If you take the new docker-compose.yml, move the PostgreSQL 16 data once, with a dump and a load (ContainerImage.md, "PostgreSQL 16 to 18, in the Compose file"); a deployment that keeps its own copy of the file keeps PostgreSQL 16.
A monitor that matches "The response carried no HTTP headers." needs the new sentence, which says who ended the connection, after how many bytes and seconds.
Security
Each of these was found by the project's own review, and each is fixed in 6.3.6 unless it says otherwise. Each links its work item, which gives the details, and the Security section of CHANGELOG.md says what changed; that file, as tagged for 6.3.6, names only the two Blowfish identifiers, and says "CVE requested" for the others; for the string replacement, the Sieve filter, the JSON reader and the Linux commands' error reports it gives other affected versions, and for the header unfolding, the SPF expansion and the Linux network waits it leaves out a way in, and there the entries here follow the corrections filed on their CVE requests after the tag was made.
CVE-2026-103011 (work item #49) - a heap buffer overflow in the encryption routine of the legacy Blowfish code of stored secrets, inherited from the original hMailServer, in every version up to 6.3.5. 6.3.6 replaces that code with the project's own.
CVE-2026-103010 (work item #49) - a heap buffer overflow in the decryption routine of the same code, in every version up to 6.3.3, fixed in 6.3.4, whose notes did not say so.
CVE-2026-104660 (work item #59) - on Windows, COM objects that carry no credential - a message, its attachments or a fetch account that a program creates itself, and the objects an Application handed out once a later Authenticate on it failed - were not refused what only a signed-in caller may do, so with an administrator password set a local Windows user with no hMailServer credential could queue mail, read and write files as the service's account, and attach a fetch account to any account; every version up to 6.3.5.
CVE-2026-104658 (work item #58) - on Linux, the live update's apply step, which runs as root, took the unit to stop and, for an AppImage, the verifying program from the request the service account writes, and once it had started the server again it wrote its log and its outcome by names through which a symbolic link that account planted could lead them elsewhere; 6.3.4 and 6.3.5.
CVE-2026-107578 (work item #71) - the commands an administrator runs elevated on Windows wrote by path into folders the service's account can change, and on Linux the store commands run as root followed links that account planted and every command run as root wrote its error reports into that account's log directory by name, so a program already running as the service's account could lead an administrator's process to a file of its choosing; on Windows 6.3.4 and 6.3.5, on Linux every version from 6.3.0 to 6.3.5.
CVE-2026-107573 (work item #77) - on Windows, the installer left the Data, Logs, Temp, Database and Events folders and hMailServer.INI with the permissions Program Files hands down, so every account that could sign in to the computer could read the mail, the logs, the event scripts and the database's password, which any account on the machine can unseal; every version from 6.0.0 to 6.3.5. The installer now makes them private to SYSTEM, the Administrators and the service, and on Linux the AppImage makes its folders 0700.
CVE-2026-104659 (work item #57) - the REST administration listener's loopback port answered a request whatever its Host, so a web page could reach the console through a browser on the same machine, and a wrong administrator password over REST from the loopback address was not slowed down; earlier versions. Such a request is now refused with 421, and a wrong password costs a growing delay of up to ten seconds.
CVE-2026-103647 (work item #52) - the webmail handed the browser an attachment it had decrypted itself (S/MIME or OpenPGP) under the type the message named; 6.3.2 to 6.3.5. It is now always a file the browser only saves.
CVE-2026-104704 (work item #61) - outbound DANE used DANE-EE records alone, so a host whose validated TLSA records were of another kind was delivered to as if it published none; every version up to 6.3.5. DANE-TA is now verified too.
CVE-2026-107584 (work item #64) - outbound DANE read a DNS lookup that did not come back whole as "unsigned", so whoever could disturb a recipient domain's DNS could take it out of DANE; every version up to 6.3.5.
CVE-2026-107586 (work item #62) - the REST listener's table of browser sessions dropped its least recently used session whoever held it, so one account holder signing in over and over signed out every webmail tab and other browser on the server that sat idle for a minute; 6.2.28 to 6.3.5, and the Control Deck with them from 6.3.0.
CVE-2026-107585 (work item #63) - the pending halves of single sign-on and passkey sign-ins, which anybody may start, were held the same way, so a client asking for sign-in starts a few times a second made other people's OpenID Connect, SAML and passkey sign-ins fail; 6.3.4 and 6.3.5. The browser now carries a pending sign-in, sealed.
CVE-2026-107587 (work item #66) - the webmail kept a stranger's S/MIME certificate for encrypting replies without a trust check and under an address the certificate chose; 6.3.2 to 6.3.5.
CVE-2026-107583 (work item #65) - the webmail's view of a message's HTML put its embedded images back in time growing with the square of the references, so one message could hold a REST worker for minutes; 6.3.2 to 6.3.5.
CVE-2026-107582 (work item #67) - the server's string replacement took time growing with the square of what it replaced. A message with an HTML part and no text part, full of entities, held the REST worker that listed its folder, or an IMAP thread, for minutes (the message list from 6.3.3, the page of a message that expires from 6.3.4, IMAP PREVIEW from 6.2.22); and the DMARC test, on by default, verifying a received message's DKIM signature whose tags held a great many spaces, held the thread that accepts the message for seconds to tens of seconds before the server answered, with nobody opening anything, so a stream of such messages stopped the server accepting mail; every version from 6.0.0 up to 6.3.5.
CVE-2026-107581 (work item #68) - parsing one IMAP FETCH from a signed-in account could hold an IMAP worker thread, shared with SMTP and POP3, for minutes and longer, and the sections a FETCH named of one message were all read and held before any was sent; every version from 6.0.0 up to 6.3.5.
CVE-2026-107579 (work item #70) - with bounce or complaint processing on, or a list the list manager runs, a returned report begun by very many blank lines held a delivery thread for a minute and more; 6.3.4 and 6.3.5.
CVE-2026-107580 (work item #69) - a header field with very many line breaks, read as text, held the REST worker or IMAP thread that read it for minutes, and the DMARC test, on by default, reads each received message's From that way, so such a From held the thread that accepts the message for seconds with nobody opening anything; reading a message's header from its file took seconds for a large header at each read; every version from 6.0.0 up to 6.3.5.
CVE-2026-107577 (work item #72) - removing a MIME header parameter whose value is empty and directly followed by a ; never ended, holding a worker thread at full load until the service was restarted - reached from one received message when the attachment blocker (not on by default) renames a blocked attachment, or when a filename is set over the REST API - and decoding many encoded words of an encoding other than base64 or quoted-printable, removing a parameter of many continuations, or deleting many header fields of one name took time growing with the square of their number; every version from 6.0.0 up to 6.3.5.
CVE-2026-107576 (work item #73) - verifying a received message's DKIM or ARC signatures took time growing with the square of its header, so a message with very many fields, or a field folded over very many lines, held a thread that serves delivery and SMTP for tens of seconds; every version from 6.0.0 up to 6.3.5.
CVE-2026-107575 (work item #74) - expanding a macro in a sender's own SPF record into a name too long to look up took time growing with the square of its length, so the SPF check - the SPF test's, or the DMARC test's, which is on by default - took several seconds; 6.3.4 and 6.3.5.
CVE-2026-107574 (work item #76) - the JSON reader took time growing with the square of an object's members. It reads the REST API's bodies and, where domain reports are on, a TLS report of up to 16 MB that anyone may mail in, on the delivery queue: a 4 MB report took about 300 seconds, and a few such reports stopped all delivery for over an hour each; 6.3.2 to 6.3.5 (the REST API's bodies from 6.3.2, the reports from 6.3.4).
CVE-2026-107572 (work item #75) - an account holder's own Sieve filter could hold the delivery threads every account shares: a :matches test backtracked over every length of every *, and deleteheader erased its fields one at a time; 6.2.22 to 6.3.5.
CVE-2026-103649 (work item #53) - on Linux, some network waits had no timeout - the MTA-STS policy fetch, the DANE TLSA query, the OAuth2 token request, the ACME client and its http-01 responder, and the ManageSieve and metrics listeners, and in 6.3.0 to 6.3.2 the server's own DNS resolver; 6.3.0 to 6.3.5.
The same release fixes or hardens more, without a CVE request: more code that took time out of proportion to its input, in the calendar and IMAP LIST among others; calendar messages delivered by mail now change a stored event only from a sender the server verified (6.3.4 and 6.3.5 did not check); the Control Deck and the webmail are served under stricter page policies; attachments, files sent as links and contact photos keep their declared type only when no browser runs or renders it; ManageSieve serves its connections side by side and holds each to deadlines; a mailbox key and the stored-secrets key no longer stay whole in memory freed without being written over, as they could in 6.3.4 and 6.3.5; and more, listed in the release notes. The Windows installers carry OpenSSL 4.0.3 (CVE-2026-84783 and others) and libpq from PostgreSQL 18.6, and event scripts on Linux run in QuickJS 2026-06-04 (CVE-2025-62494, CVE-2025-62493, CVE-2025-62492). Upgrade every server running 6.3.5 or earlier.
Upgrading
By the live update, from 6.3.4 or 6.3.5. Every file of 6.3.6 is signed as this release's pipeline at the project's group path, https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.6, with the project's id, 86730559, in the certificate. Every server from 6.3.4 on has that signer compiled in, so one installed from the x64 installer or the release's x86-64 .deb or .rpm is built to install 6.3.6 by its live update: from 6.3.5 with 6.3.5's own file as its rollback image, and from 6.3.4, which carries no Sigstore bundle, without one. No live update had installed a release signed at the group's path when this was written. On the Control Panel's Status page: Check for updates, Download update, Install update.
The update is applied by the version already installed, so what 6.3.4 and 6.3.5 do still holds for it. On Windows, a service running as NT SERVICE\hMailServer downloads and verifies the installer, then leaves the install to an administrator (HM7463) - download hMailServer-6.3.6-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. From 6.3.6 on, Install update in the Control Panel on the server installs the next release with one Windows prompt.
On Linux, install 6.3.6 with your package manager rather than by the live update. The live update to 6.3.6 is applied by the apply step of the version it replaces, the one fixed above. Use apt, dnf or zypper, or turn the apply off until then with systemctl disable --now hmailserver-update.path (the check and the download go on). From 6.3.6 its own helper applies the next release. A backup destination inside /var/lib/hmailserver fails the backup an unattended apply takes on 6.3.4 and 6.3.5 (HM5014).
On Fedora and Enterprise Linux, every .rpm requires glibc's extra character-set converters, glibc-gconv-extra, which dnf installs with it; a server without them whose dnf has no repository enabled (an unregistered RHEL, say) has the update refused until glibc-gconv-extra is installed. On openSUSE they are recommended (glibc-gconv-modules-extra), and zypper installs them unless solver.onlyRequires is on. Without them the server converts no text in BIG5, ISO-2022-JP, Windows-1251 or ISO-8859-2, and from 6.3.6 it says so at its start.
By hand, from 6.2.28 to 6.3.3, and from 6.3.3's AArch64 packages or AppImages. On Windows run hMailServer-6.3.6-x64.exe over the existing installation; on Linux install the package with apt or dnf, or replace the AppImage with 6.3.6's. Until then keep UpdateAutoDownload off on such a server, or it downloads the installer at every check and refuses it.
A server from one of 6.3.6's per-distribution packages is offered the next release's 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 the next version.
What else changes on upgrade
The 6.3.6 section of CHANGELOG.md lists everything under "What changes on upgrade without a switch". The rest, in short:
Spam checks: the MX-record test and the SURBL test cut host names by the Public Suffix List compiled into the server, so a sender at a public suffix itself with no MX (github.io, co.uk) now fails the MX test; the SURBL test reads a link's host as a browser does; tlds.txt is removed.
Backups leave out the live update's Updates folder, and a destination inside the data directory works; up to 6.3.5 it failed every backup. A message deleted while a backup copies the data directory no longer fails the backup.
A full restore of messages, which failed on every installation made new with 6.3.4 or 6.3.5 and left the mail in the temp folder alone, copies the archive's store in first and removes what the archive does not hold only after. It keeps this installation's own self-signed certificate and key when the archive's key is not this installation's, so a mail client that accepted the other server's certificate asks again. If a restore failed this way, the archive is as it was: upgrade, restore again from it, then delete the staged copy its HM5014 line names. On Linux a full restore from 6.3.0 on also deleted the key the stored secrets are sealed under, which no archive carries (from 6.3.4 the server then says HM7495 at each start) - import the stored-secrets key from its export (Backup.md, "How a restore replaces the data directory").
More web requests go through HttpProxy when it is set: the OAuth2 token, the MTA-STS policy, ACME, brand logos, Web Key Directory, Web Push, one-click unsubscribe and an inbound webhook route held to public addresses. On Windows a listener whose port another program holds now fails to bind and says so.
Calendars: a cancellation of some occurrences of a series takes those out of a guest's calendar and leaves the rest.
The live update keeps its outcome after the start, tries a failed scheduled check again once ten minutes later, and keeps a verified installer across a restart instead of fetching it again.
What the auto-ban put below the server (the Linux firewall hook, AutoBanCommand) is lifted after a stop too, and Windows' uninstaller removes the auto-ban's firewall rules.
On Linux the backup and event logs are UTF-8, converted in place the first time; Windows keeps UTF-16LE. The .deb and .rpm require ca-certificates.
Sign-in limits: an account, or the administrator, holds at most fifty REST browser sessions, and a pending single sign-on or passkey sign-in is carried by the browser, sealed, so no number of starts can push anybody's out.
Text in the Control Panel can be selected and copied on every page and dialogue (work item 48); where the keyboard is shows in one violet in the Control Panel, the Deck and the webmail.
An error reported where the settings hold no scripting switch (UseScriptServer - a database without that row) is logged and fires no event; in every version up to 6.3.5 it reported the missing setting again and again until the reporting thread's stack ran out, taking the service with it.
Scripting off runs no script engine. The project's address is gitlab.com/hmailserver/hmailserver in the Control Panel's links, security.txt, the systemd units and the packages.
Also new
A never-ban list by reverse name (work item #56) - spare a provider whose outbound hosts share a reverse name from every auto-ban, checked forward and back.
Port 25 takes no password: each SMTP listener's AUTH is On, Off or Honeypot (work item #54).
An auto-ban can be widened to its reverse-name neighbours in the same /24, off by default (work item #55).
A HELO name or a sender's domain that is not a name can be refused, two settings, off by default (work item #51).
One-click install of an update from the Control Panel on a Windows server whose service is not an administrator.
What the release carries
62 files, each with its Sigstore bundle, <file>.cosign.bundle, beside it:
Windows: hMailServer-6.3.6-x64.exe, and hMailServer-6.3.6-arm64.exe for Windows on ARM, both Authenticode-signed. The ARM64 installer is a preview: it is cross-compiled on the project's x64 Windows runner and has never run on ARM64 hardware. SQL Server Compact has no ARM64 build, so a new ARM64 installation is set up against SQL Server or PostgreSQL, and a silent one is given its database on the command line (WindowsOnArm.md). If you install it on an ARM64 machine, please say how it went, working or not, in an issue - the project has no ARM64 machine of its own.
Linux, x86-64 and AArch64: the generic hmailserver_6.3.6_amd64.deb, hmailserver_6.3.6_arm64.deb, hmailserver-6.3.6-1.x86_64.rpm and hmailserver-6.3.6-1.aarch64.rpm, the names an installed server's update check asks for; and each Debian 12 and 13, Ubuntu 24.04, Fedora 44 and 43, Enterprise Linux 10 and 9, openSUSE Leap 16.0 and Tumbleweed release's own package for both architectures. The AArch64 files are cross-compiled and tested under emulation: no AArch64 machine has run them.
The AppImages, hMailServer-6.3.6-x86_64.AppImage and hMailServer-6.3.6-aarch64.AppImage, with the project's own AppImage runtime, and beside them the source of the libraries they carry and of those their runtime links, as their licences ask.
The source tarball, hmailserver-6.3.6.tar.gz, reproducible and with nothing non-free in it; the Helm chart, hmailserver-chart-6.3.6.tgz; and the PowerShell module, HmailServer.psd1 and HmailServer.psm1, Authenticode-signed.
An SBOM for each compiled file and the tarball, <file>.cdx.json, and the source tree's two; hmailserver-linux-6.3.6-SHA256SUMS.txt, the SHA-256 of every Linux file; and hmailserver-6.3.6.intoto.sigstore.json, SLSA v1 build provenance that names every file by its SHA-256.
The container image, the first at GitLab's registry: registry.gitlab.com/hmailserver/hmailserver:6.3.6, also tagged 6.3 and latest, one index over linux/amd64 and linux/arm64, each built from this release's .deb of its architecture and signed with cosign as this release's pipeline, with its SBOM attested to it. In the container the update check names the image to pull and installs nothing (ContainerImage.md).
Also in the tree, not yet published anywhere: a Nix flake of the project's own with a NixOS module, an APKBUILD and an OpenRC service for Alpine Linux, on whose musl the server now builds and runs, and a snap. They are built without the live update and name the command that updates them; none is in a distribution's archive or store yet.
https://updates.progressiverobot.com/download/ leads to the newest stable release's page, and /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 to that file of it; add .cosign.bundle for its bundle.
How to check a download
With cosign and OpenSSL, with the file and its bundle beside you:
cosign verify-blob --bundle hMailServer-6.3.6-x64.exe.cosign.bundle \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.6' \
--certificate-oidc-issuer https://gitlab.com hMailServer-6.3.6-x64.exe
jq -r .verificationMaterial.certificate.rawBytes hMailServer-6.3.6-x64.exe.cosign.bundle \
| base64 -d | openssl x509 -inform DER -noout -text | grep -A1 1.3.6.1.4.1.57264.1.15
The first must say Verified OK, and the second print ..86730559, the project's own id, which cosign does not check: the identity is a path, and a path could pass to another project were the group or the project renamed. 6.3.5, signed before the move, names https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.5 instead. If your cosign has the --new-bundle-format option and does not use it by default, add it. Each file but a compiled file's SBOM also has its bundle a second time as <file>.sigstore.json; either name verifies the same way.
To check that a file is one this release's pipeline built, against its build provenance:
cosign verify-blob-attestation --new-bundle-format \
--bundle hmailserver-6.3.6.intoto.sigstore.json --type slsaprovenance1 \
--certificate-identity 'https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.6' \
--certificate-oidc-issuer https://gitlab.com hmailserver_6.3.6_amd64.deb
It says Verified OK only when the file's SHA-256 is one the provenance names. Then:
sha256sum -c --ignore-missing hmailserver-linux-6.3.6-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 2f673913e5f127d688090e98f6001ca567cd45560d452aebc74421b5533cfe53.
In a clone, git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.6 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", "Build provenance" and "Software bills of materials", has the rest.
How it was checked
The tag's pipeline (https://gitlab.com/hmailserver/hmailserver/-/pipelines/2914690858) ran every gate before anything was published: the Windows suite on the project's Windows runner, 4,110 tests, 4,031 passed, 0 failed, 78 skipped and 1 inconclusive; the Linux suite on the project's Linux runner, 2,409 tests, 2,066 passed, 0 failed, 343 skipped; the rebuild of the x86-64 .deb and .rpm byte for byte; the install and start of every Linux package in a clean container of its release, the AArch64 ones under emulation; the static analysis, Semgrep and the dependency scan. It then checked every signature with the server's own verifier. The signed installer went through the installer smoke test: an upgrade from 6.3.5 passed 93 checks and a new installation 59, none failed.
Known issues
The ARM64 installer has never run on ARM64 hardware (above), and no ARM64 Windows server has a live update to 6.3.6, since no release before it carried the ARM64 installer; from 6.3.6 one finds its own installer by name, and an x64 server is never offered it.
No channel publishes it yet. The apt and dnf repositories, Docker Hub, Quay.io, the AUR, the Ubuntu PPA, Copr, the openSUSE Build Service, Chocolatey, the Snap Store, PyPI and the PowerShell Gallery publish from master once their keys and accounts exist; none is live as this release is made (Channels.md).
An AppImage on Fedora, Enterprise Linux or openSUSE runs on the host's glibc and cannot require its extra character-set converters: install glibc-gconv-extra (Fedora, EL) or glibc-gconv-modules-extra (openSUSE) by hand; the server says when they are missing.
Releases pause after this one
6.3.6 is the last release for the time being, by the owner's decision of 28 September 2026, and no feature release follows it until the maintainers say otherwise in SECURITY.md, "While releases pause". A confirmed vulnerability still ships, in a release of its own that is 6.3.6 with fixes - 6.3.7, 6.3.8 and so on: a critical or high one as soon as its fix has passed the gates, and none held past 90 days. 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 is written, it ends then. There are still no maintenance branches: an installation of 6.3.5, 6.2 or anything older is upgraded in place to the newest release. To hear of a security release, switch the server's update check on (UpdateCheckEnabled), or follow the releases' feed.
Reporting a vulnerability
Not in a thread here, and not in a public issue. Report it privately, as SECURITY.md says: a confidential issue on GitLab - check that it is still marked confidential before you submit it, and choose the Security template - or an email to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue, so no GitLab account is needed.
Release notes, checksums and downloads · Newest stable release
