Download hMailServer 6.3.3

The webmail

The self-service portal at /portal shipped in 6.3.0 with a mailbox page. Fifteen waves later it is a mail client. Everything it does is over /api/v1/me, answers to the account's own credentials and to nothing else, and is described in the OpenAPI document at /api/v1/openapi.json.

Reading. Conversations grouped by thread. Archive, Junk and Trash as one-key actions (e, !, #), with a move into or out of Junk taking the same path as an IMAP MOVE, so the spam filter learns from it. A search written the way a reader writes one: words that must all be found, quoted phrases, from:, to:, subject:, has:attachment, before:, after:, in:, is:unread, is:flagged and the rest, and label: for labels. Labels are IMAP keywords: the server stores them (schema 6036), STORE, FETCH, SEARCH, APPEND, COPY and a Sieve addflag all carry them, and every IMAP client sees the same labels the page shows in colour. Image attachments are shown under the message and a PDF is previewed in a frame of its own, from bytes the page fetched itself. A warning sits above a message whose link text names one site and goes to another, or whose sender is named like a contact but writes from another address. Shared and public folders appear under a heading naming their owner.

Writing. A formatting bar and an editor whose HTML is rebuilt from an allowed subset before it goes, so a message is sent as text beside HTML. A From picker offering exactly the addresses the server would accept from the account - its own, its aliases, and the accounts whose INBOX grants it the post right - checked by the same rule SMTP submission applies. A signature. Templates with {first_name}, {subject} and {date} filled in. Undo send, for up to thirty seconds. Read receipts asked for and answered (RFC 8098). One-click unsubscribe (RFC 8058), made only to a public address: the server resolves the list's host and refuses loopback, private, link-local and every other non-public address before it connects. Send later, and snooze until a time, both kept on the server (schema 6034) and run by a task every minute. To, Cc and Bcc complete from an address book (schema 6032) that collects every recipient the account writes to once. A file above the size the domain allows goes as a link that expires and can take a password, uploaded in chunks and served from /files/{token} (schema 6035); an administrator sets the threshold and the lifetime server-wide or per domain.

S/MIME, in the browser. The page signs, verifies, encrypts and decrypts with the Web Crypto API and nothing else. A certificate and its key come in from PEM, DER or a PKCS#12; the private key is wrapped in the browser under a key derived from the account password and stored on the server so wrapped (schema 6037) - the server cannot open it. The certificates of correspondents are kept from the signed messages they send. A signed message shows a badge beside the SPF, DKIM and DMARC ones; the chain is checked against the system's roots (the Windows ROOT and CA stores, the distribution's bundle on Linux). What the page signs is what arrives: the entity goes to the server byte for byte under the server's own headers. Proven against OpenSSL in both directions on every push. Not in this release, and said so where it is met: 3DES content, EC key agreement for encryption, legacy PKCS#12 encryption, OpenPGP.

The pages. Settings - name, signature, theme, density, notifications, and the language: the seventeen the Control Panel speaks, and Greek, Korean and European Portuguese besides, beside English. The keyboard map (?) lists every key the page answers, l for the Label menu included, and the keys and the search operators are documented on one page, hmailserver/docs/WebmailShortcuts.md; README shows the inbox, a message open, and the Control Panel's Welcome page. Away - out of office, forwarding, and what is waiting to be sent later or to come back from snooze. Filters - a rules editor that writes Sieve, or the script by hand, left alone when it was written by hand. Contacts. Storage - the quota, every folder's size, the largest messages, and a clean-up of Trash and Junk by age. Files - the links sent, their downloads, their expiry. Security - app passwords, made only after the account's own password is given again; browser sessions, ended one at a time or all but this one; support access an administrator may be allowed for a while, off unless the user turns it on, with every request of it logged as the administrator acting as the user; and the S/MIME key store.

The page itself. It installs as an app, keeps the inbox listing and the last thirty opened messages for reading without a connection, and queues a send that fails for want of one. An administrator gives it a name, a logo and an announcement, server-wide or per domain (PUT /api/v1/portal/branding). It imports .eml files and exports a folder as mbox. It is worked with a screen reader: landmarks, a skip link, focus that follows a change of address. It sends the password once, holds nothing in memory and allows no inline script.

Authentication

SASL GSSAPI (RFC 4752) on SMTP, IMAP and POP3, on Windows. A Kerberos client presents a ticket for this server's service principal, the server proves itself back, and the client's principal names the account - the one an administrator linked to that directory user, else the one addressed user@realm. Off unless GssapiEnabled=1 in [Settings]; the credentials are the process's own on a domain-joined host, or a service account named by GssapiServiceAccount and GssapiServicePassword. Proven end to end against a Windows Server domain controller: SMTP AUTH GSSAPI accepted and a message queued, IMAP AUTHENTICATE GSSAPI accepted and the message read back.

An auto-ban reaches the operating system's firewall. Until now a banned address was a row the listeners consulted at accept time: the operating system accepted the connection and the server dropped it. With AutoBanFirewall=1, Windows gets an inbound block rule per banned address in Windows Defender Firewall, in a rule group of its own; Linux gets a packaged hook that keeps an nftables set, and a fail2ban filter and jail. AutoBanCommand runs anything else, and AutoBanNeverBan lists the addresses that are never banned. All three are off as shipped.

Making an app password proves the person, not the request. The request carries the account's own password, and an app password is never accepted for it.

A SURBL server's answers are judged the way a DNSBL's are. Each SURBL server has an expected result (SURBLServer.ExpectedResult, the Control Panel's SURBL editor; schema 6038) in the DNSBL syntax - 127.0.1.0-255, 127.0.0.2*, ranges and wildcards - and only an answer it names is a listing. With none set, any answer counts except the codes in 127.255.255.0/24, with which the Spamhaus zones refuse a query - from a public resolver, or too many of them - and which were taken as listings until now: a server resolving through 8.8.8.8 tagged every message carrying a link as spam (discussion #167). The debug log says what the zone answered and what was made of it.

Linux

The packages install on the next distribution release. The 6.3.1 .deb depended on the builder's exact Boost sonames and would not install on Ubuntu 26.04. Boost is linked statically now (Boost.Regex header-only, so no ICU dependency comes with it), and the package-install job installs the .deb on Ubuntu 26.04 in a container on every run.

A container image on GHCR from every tag. The run's own .deb on ubuntu:24.04 pinned by digest, run as its own user with cap_net_bind_service on the binary. The entrypoint writes the database section, the REST listener and the administrator password from the environment (with _FILE variants for the two secrets), creates or upgrades the database, and starts the server. The image is smoke-tested beside a PostgreSQL over TLS before it is pushed.

The Linux build is green on every push again. Three functions the webmail waves used on Windows only - _wtoi, wide-path file streams, _mkgmtime - have POSIX counterparts now, and the translation-unit census runs before every wave's pull request.

Database

The 6029 to 6030 upgrade step sweeps parents before children. 6.3.1 named this as known and unfixed: on a database holding orphaned rows, the step could re-orphan rows it had already cleaned and then refuse its own foreign keys. It is fixed in all four backends, and the reason it could ship at all is gone: a gate now executes a schema upgrade on a seeded database on every push, winding a created database back to 6029 by undoing every later step and upgrading it forward again.

The fresh-schema create scripts drop dependent tables before hm_accounts in every dialect, so recreating a database that already holds them no longer fails on the foreign keys; and the contacts index is unique on (account, address), so two requests racing to collect the same address cannot store it twice.

Schema 6032 to 6037: contacts, account preferences, scheduled sends and snoozes, files sent as links, message keywords, S/MIME keys.

Every statement in a MySQL script is followed by a blank line, and a check keeps it so. The server's script parser splits a script into commands on a blank line and sends each command as one query; MySQL refuses a command holding two statements, where SQL Server and PostgreSQL take a batch. Two of this release's schema steps had written statements on consecutive lines, which the Linux build's database gate caught before any release carried them: a fresh MySQL installation would have had no database. build/check-sql-separators.py now applies the parser's rule to every MySQL script on every push.

Build and supply chain

Thirty-seven of the forty committed binaries left git. The manifest (hmailserver/docs/third-party-binaries.json) says how each is obtained; build/get-installer-binaries.ps1 fetches them from this repository's own build-inputs-1 release against the manifest's SHA-256, gathers the MSVC runtime from Visual Studio, and copies the ADO type libraries from Windows. The COM wrapper the .NET tools compile against is generated from the server's type library rather than committed. Fourteen relics went, and the installer's port check is fifteen lines of its own Pascal instead of a DLL of unknown origin.

Provenance. Beside every cosign bundle a .sigstore.json twin, and SLSA build provenance for the assets as attached, verified with slsa-verifier after upload. The MariaDB Connector/C files in the build inputs are recorded as byte-identical to the vendor's own server archive, with the vendor's checksum file; the LGPL-2.1 text its licence requires accompanies the distribution. A Windows job re-verifies every Authenticode signature the manifest records, on every push that touches it.

Workflows. Every job of the Linux build runs behind Harden-Runner in audit mode with its service images pinned by digest; the C++ CodeQL job places the Windows type libraries before it builds; Dependabot keeps the Actions and .NET dependencies current in one group each.

Quality and tests

Code Quality is back to zero findings, and stays there: the Linux test shims say what they mean.

Native coverage can now be measured. The /Debug console server can be reached over COM, so a coverage tool that launches and debugs it can drive it with the whole regression suite; until now a client's CreateObject started the service instead, which is why native coverage was never measured.

A server holding a database it refused answers COM with the refusal, not an access violation. When the database opens but its schema is not the one the build requires (HM5011), the process stays up so that DBUpdater can upgrade it through hMailServer.Database - but hMailServer.Application also handed out Settings, Domains, Rules and the rest over a configuration that was never loaded, and the first read through any of them was an access violation inside the COM call ("An error occurred processing the request" to the client, a record in the crash oracle). Those objects are now refused with the HM5011 text, which names DBUpdater, until the server is initialised; hMailServer.Database is untouched. Reproduced and proven on a domain controller with its database one step behind.

The test SMTP simulator reads a large message in linear time.

The regression suite can drive a console server. With HM_CONSOLE_SERVER=1 in the environment, a fixture or test that restarts the service is skipped with the reason instead of stopping a /Debug server that no service command can bring back - which is what the first coverage run did, and why everything after its first restart ran against nothing.

The pre-flight refuses to pass while WSL is running, because a Linux server or test run left alive there holds the suite's ports invisibly.

Documentation and governance

SECURITY.md states the vulnerability management policy the automation enforces - the thresholds, not just the tools - and an OpenVEX statement accompanies it. GOVERNANCE.md names two maintainers. The release checklist says what the 6.3.1 cut proved and that releases are immutable once published. The README describes the webmail as it is, offers the Linux packages on its download line, and carries the OpenSSF badges. The Control Panel's list pages enable a button only while there is a selection, and the settings search index knows the auto-ban firewall settings.

Verification

The full regression suite ran on the stamped binary: 2,219 tests, 2,211 passed, 0 failed, 8 skipped. hMailServer.exe 6.3.2.41, SHA-256 4C7D5A2C7FA6537E460EADD6DCC85D5AEDB3559FE349E2DEC9547FA99086D3E8.

The installer has two hashes, and both are given deliberately. hMailServer-6.3.2-x64.exe as built, 79,683,220 bytes: SHA-256 746F17303D219930AAED03D836F3C2C55E367BCD59620BA60E16EAE7EFB5F589. As published, after Authenticode signing: SHA-256 D10EB643C7D4717655DA19B8FACBD4916D393024BA7D18AC5CCDE492F2140DE9.

The assertion build, first. A separate build with HM_ASSERT on - every internal invariant checked and any failure fatal - ran the whole suite before the shipping binary was built: 2,219 tests, 2,211 passed, 0 failed, 8 skipped. Nothing asserted.

Reproducible. Three clean Release builds of the stamped tree - the first two compared for the purpose, the third the one that ships - produced the same hMailServer.exe, SHA-256 4C7D5A2C7FA6537E460EADD6DCC85D5AEDB3559FE349E2DEC9547FA99086D3E8, 13,755,904 bytes; anyone with the same toolchain can build the tag and compare.

Fuzzing. The three MIME harnesses ran thirty minutes each on this release's source on 13 September 2026: mime_message_fuzzer 106,581 executions, mime_header_fuzzer 120,063, mime_decode_fuzzer 3,199,620 - no crash, no hang, no violated assertion, and every input the earlier campaigns kept under fuzz/regression still survives. The harnesses are the 9 September builds, which is the same parser code: nothing under Common/Mime changed between 6.3.0 and this release. The parsers that did change - the S/MIME entity a page submits, IMAP keywords in STORE, SEARCH and APPEND, the search syntax - are covered by the regression suite and, for the entity path, by the OpenSSL round-trip check on every push, not by a fuzz harness yet.

Nothing in the server changes. The compiled server differs from 6.3.0 by its version stamp and one comment line; everything else in this release is the path a release travels - the workflows that sign and verify it, found wanting while preparing to use the certificate for the first time - and three documentation corrections.

The installer is signed

The installer is signed with Azure Artifact Signing, against a certificate profile issued to Progressive Robot Ltd after Microsoft's identity validation. The account, the validation and the profile were arranged on 10 September 2026, after 6.3.0 had shipped. A published release here is immutable, so 6.3.0 could not be signed retroactively and never will be.

What it changes. The elevation prompt reads the publisher's name. And for administrators on managed estates - a great many of this server's users - a policy that refuses unsigned binaries no longer refuses this one.

What it does not change, said plainly: SmartScreen still warns. Microsoft's own comparison puts a signed installer in the same row as an unsigned one, flagged as unrecognised until reputation accumulates, and reputation attaches to a file that does not change - which a new 80 MB installer every few weeks never is. An EV certificate would not help; Microsoft removed EV's SmartScreen bypass in 2024. Expect the same Windows protected your PC screen, now with the publisher's real name on it.

Only the Windows installer is Authenticode-signed. There is no Authenticode for a .deb, an .rpm or an AppImage. Sigstore is unchanged and remains the check that means something for every asset on the release: each carries a .cosign.bundle beside it, and cosign verify-blob against that bundle verifies it.

One setting becomes usable. UpdateRequireAuthenticode=1 has existed since 6.2.28 and, until now, made the server's own update path refuse every release of this project, because none carried a signature: the check is WinVerifyTrust on the downloaded installer, and an unsigned file is refused with the file carries no Authenticode signature. From 6.3.1 the installer it downloads carries one. The check is Windows-only: on Linux there is no Authenticode to verify, the server says so rather than reporting a pass, and updating is the package manager's job.

The release path

Releases here are immutable, so each of these could have put out a permanently wrong release.

The Authenticode gate was checking the wrong four of the six settings it guards. It asked for the three Azure secrets and ARTIFACT_SIGNING_ACCOUNT - the one input the signing action marks optional - and never asked about ARTIFACT_SIGNING_ENDPOINT or ARTIFACT_SIGNING_PROFILE, the two it marks required. Five half-configured states got through, each a state somebody passes through while filling in three repository variables one at a time; the action throws on an empty endpoint, and the cosign job declares a dependency on this one, so a release that tripped it would have got no Authenticode signature and no Sigstore bundle on any of its twenty assets. There are three outcomes now: none of the six set is the ordinary case and stays a silent no-op, all six signs, and anything in between stops and names what is missing while the release can still be fixed. The six values, and the tag, reach the shell through the environment rather than being pasted into the script text, because an expression pasted into a script is executed as syntax if it holds a quote. The release is verified as it is attached, not as it was signed. The old check looked only at the job's own copies. A draft stays mutable afterwards, and four things upload over it with --clobber: a re-run of the Linux publish job, the SBOM workflow, a second Authenticode run, and the hand-recovery commands the Linux job prints into its own log. The workflow now ends by re-downloading the release exactly as it stands and verifying every asset against its attached bundle, in both directions - an asset with no bundle, and a bundle whose asset has gone. What a release must carry is asserted before a certificate is spent on it. The only completeness check was "did we sign at least one thing", and the SBOMs were named nowhere but in comments - which is how 6.2.22-pre4 came to be published with an installer and no SBOM at all. Both SBOMs are a hard failure now, in the Authenticode job rather than the signing job, so an incomplete release stops before a code-signing certificate has been spent on it. The Linux sums file and the four package names stay warnings, deliberately: a Linux packaging failure must not hold back the Windows installer every server in the field is waiting for. An RFC3161 countersignature is required, and is checked. These certificates live about seventy-two hours. Get-AuthenticodeSignature answers Valid for a signature carrying no timestamp for as long as the certificate has not expired, which it never has seconds after signing - so an untimestamped installer would look perfect on the day and stop verifying on every machine in the field three days later, on a release that cannot be corrected. The countersignature is proved before the release asset is replaced, so a timestamping failure costs a re-dispatch and nothing else. Verification can no longer pass vacuously. A glob that matched nothing used to verify nothing and succeed. Both verification steps now refuse to pass having checked zero assets, and compare what they verified against what the signing step reported. Runs are serialised per tag. Two dispatches for one tag could interleave, and one run's bundle could end up describing bytes the other had already replaced. They queue now, and are not cancelled: a run stopped between signing and uploading would leave assets with no signature at all. The SBOM workflow refuses to overwrite an SBOM that has already been signed, because cosign signs the bytes attached when it runs and Syft writes a fresh document identifier every time, so a re-upload after signing leaves a signature that verifies against nothing. It also proves the tree it describes is the tag's own commit before Syft runs - a bill of materials describing a tree the release was not built from is the one thing an SBOM must never do. The installer smoke test can read a draft release, which is the only kind it is ever pointed at. It asked for contents: read, and GitHub shows an unpublished release only to a token with push access, so every dispatch against a draft answered "release not found" - which made the documented order, green before publication, impossible rather than merely awkward. It asks for contents: write now, and writes nothing. The Linux package-install check runs under sudo, like every other command in its step. The package makes /etc/hmailserver 0750 root:hmailserver on purpose, because the configuration holds credentials, so a bare stat answered "Permission denied" and under set -e took the job with it. That is why 6.3.0's tagged run attached no Linux packages and they had to be attached by hand.

All of the above was verified by executing the real run bodies against the live 6.3.0 asset list with gh and cosign stubbed - the twenty-asset release, a re-run over already-attached bundles, a Windows-only release, a pre-release tag, the hand-recovery shape, a release with no SBOMs, an orphaned bundle, an asset excluded from signing by design, and an empty download - and the gate across fifteen configurations, including whitespace-only values and five hostile ones, none of which executed anything. The Authenticode path itself was rehearsed end to end on a throwaway copy of the 6.3.0 installer before this tag was cut: a valid, countersigned signature naming Progressive Robot Ltd, attached to nothing.

Documentation

The README offers the Linux packages on its download line, where a reader looks for a download, rather than 140 lines further on in the Linux section. The headline of 6.3.0 was that this server runs on Linux at all. Two files named 6.2.29, a version that does not exist and never will: the [Directories] header comment in the server source, and the relocating guide's note about when a relative path began to resolve against the program folder. Both features shipped in 6.3.0 and both now say so. Comment and prose only. The release checklist gives ARTIFACT_SIGNING_ENDPOINT as a full URI rather than a bare host, which is the form the signing action documents and one of the two values that used to pass the old gate and then fail inside the action, and it says the six settings are required together.

Known, and not fixed here

The orphan sweep in the 6029 to 6030 upgrade step runs children before parents. Before that step adds seventeen foreign keys, it deletes rows whose parent is gone. Three of the parent tables are themselves pruned by those deletes, and each one's children are cleaned earlier, against a parent that has not yet lost its rows - so pruning an orphaned account, fetch account or distribution list re-orphans rows nothing revisits, and the constraint that follows is refused. It affects only an upgrade from a schema below 6030 on a database that already holds orphaned rows; a database without them upgrades correctly, a fresh installation is never on this path, and when it does fire it fails loudly with the engine's own words and rolls back rather than doing anything quietly. It is in all four database backends. No installation has reported hitting it. The fix is a reordering of seventeen delete statements and is held for 6.3.2, because a change to a database upgrade script belongs in a release whose gates can execute an upgrade - and this project's cannot yet, which is exactly how the defect was able to ship. That gate is being built first.

The report that led to this - a Compact Edition upgrade from schema 6011 refused at the same step (#93) - turned out to be #114, already fixed in 6.2.26: the upgrade had succeeded and the verification probe had crashed the database provider afterwards, and the tool then printed a cause it had no way to know. That installation upgrades on 6.3.0 and on this release.

Verification

The full regression suite ran on the stamped binary: 2,175 tests, 2,166 passed, 0 failed, 9 skipped (the seven explicit IMAP stress tests and two ignored), in 40 minutes, with no ERROR log written. hMailServer.exe 6.3.1.40, SHA-256 8b0ab1a2d1f3645f1e12c3bca1315023474bb3a63abf0efb44f60ba0b2d83235.

The installer has two hashes, and both are given deliberately. hMailServer-6.3.1-x64.exe as built, 79,408,192 bytes: SHA-256 3986fbcccda9e46fee29c1e538a79f2423ebc4d5e3f6e59306ffba4cc7bd8cba. As published, 79,423,896 bytes: SHA-256 68c72a60e7a8530bdd32d28b60eaadab5b9c90505e174c03196e5dfa58ac9b70. They are different, and this is the first release for which that is so: the signing job replaces the installer asset with the signed one before cosign runs, so the bytes on the release are not the bytes the build produced. The second is the one to check a download against. Verified after download with Get-AuthenticodeSignature: Valid, signer CN=Progressive Robot Ltd, O=Progressive Robot Ltd, L=Chester, S=Cheshire West and Chester, C=GB, issued by Microsoft ID Verified CS EOC CA 03 for three days from 10 September 2026 19:35 UTC, countersigned by Microsoft Public RSA Time Stamping Authority - which is what keeps the signature valid after the certificate itself has expired. The installer smoke test ran against this signed file on a throwaway runner and passed.

The assertion build, first. The same source compiled with every HM_ASSERT kept - a violated one is reported as HM6364 in the error log rather than compiled out - and the whole suite run on it: 2,175 tests, 0 failed, 9 skipped (the seven explicit IMAP stress tests and two ignored), no assertion violated anywhere in the run.

Reproducible. Two clean Release builds of the stamped source produced a byte-identical hMailServer.exe, SHA-256 8b0ab1a2d1f3645f1e12c3bca1315023474bb3a63abf0efb44f60ba0b2d83235.

Fuzzing. No parser changed between 6.3.0 and this release, so 6.3.0's run stands, as the release checklist allows for a patch release: the three MIME harnesses, thirty minutes each under libFuzzer and ASan, 8,296,354 executions, no crash, hang or assertion.

Two other things arrived with it, because a Linux server has no Control Panel and no COM: the REST API gained a large write surface, and the browser drives most of it.

The server runs on Linux

One tree, two platforms. Every core translation unit compiles on Linux, counted one file at a time by build/linux-tu-census.sh rather than estimated. The census is a step of the build job: it runs under clang on x86-64 and on AArch64 - a native runner, not a cross-build - and the job fails when a single file stops compiling. A third job builds and links the whole core with GCC on x86-64, which is what stops the port quietly becoming clang-only. The Windows build is the same MSVC project it was; nothing in this release changes what it compiles or how it behaves.

Installed the way a Linux service is installed. A .deb and an .rpm for both architectures, a PKGBUILD for Arch, and an AppImage: the binary, the schema scripts, a systemd unit that runs the server as its own user, a logrotate rule, the configuration under /etc/hmailserver, and the Control Deck. hmailserver --create-database builds the schema, --upgrade-database moves it forward on a package upgrade, --set-admin-password sets the credential, and --check-config reads the configuration back before anything starts.

Proven, not assumed. Against PostgreSQL 18 and MariaDB 11.8: the schema is created, a domain and an account are made over the API, a message is submitted over SMTP, delivered, and read back over IMAP. Directory authentication runs against a real slapd over StartTLS and LDAPS, including a refused bind and a self-signed certificate. Stored secrets are AES-256-GCM under a key file the installation owns, which is what DPAPI does on Windows. A crash is recorded before the process dies, as it is on Windows.

Reproducible on the runner image of the day. No absolute path reaches the binary and the clock every tool would otherwise stamp is the commit's own date, so the same commit built twice on the hosted runners gave byte-identical binaries for x86-64 clang, x86-64 GCC and AArch64 clang. What is not pinned is the image: ubuntu-latest moves, and a compiler or a Boost that moved between two runs changes the binary legitimately. The Windows claim under Verification is the stronger one, and RELEASE.md says why.

The REST API writes what only COM could write

PUT /api/v1/settings and its anti-spam and logging groups: 108 settings written, each through the same setter the Control Panel calls, applied only when every key in the request is accepted. The three groups describe 113 keys in all - five of the logging group's are read-only facts about where the log is written rather than settings, and the relayer password is written and never read back. Global rules with their criteria and actions. SMTP routes with their address lists. Aliases. Accounts, including the password and the administrator level. Certificates, and the listeners that bind them. And POST /api/v1/server/reinitialize, which is what the Control Panel's Reinitialize does, so a new listener takes effect without stopping the process.

Every one of them is refused to a read-only key, refused to a key issued for other domains, and scoped to its own domain where a domain owns it. The OpenAPI document describes all of it, and is now valid JSON - it never was before this release.

What it still does not write, said plainly: a domain's own properties beyond its active flag and its postmaster. DKIM signing above all - there is a read route and no write route - and with it the per-domain size limits, the domain signature and a per-domain relay host. On Windows the Control Panel sets those. On Linux nothing does yet, so a domain that must sign its outbound mail with DKIM is not one to run on this platform today.

The Control Deck writes, and signs in properly

The administration page at / gained editors for most of what the API now writes. Its settings forms are generated from the server's own OpenAPI document, so every setting the API accepts appears with its type, its permitted words, whether it is read-only, and whether it takes effect on restart. Rules, routes, certificates and listeners are created, edited and deleted; an account is created and deleted under a domain; and a button restarts the services in place. Three write surfaces the API has are not on the page yet: a domain, an alias, and changing an account that already exists.

It no longer keeps the administrator password. POST /api/v1/session exchanges it once for an HttpOnly, SameSite=Strict session cookie that ends when the administrator password changes; a write must carry X-Requested-With; an API key cannot mint a session.

Webmail

The self-service portal at /portal is a webmail now rather than a page that reads mail. It is still served by the same listener as the API and still comes out of the binary rather than out of files beside it, so it is there on a machine that has nothing else, and it fetches no font, no image and no stylesheet from anywhere. The markup and its script are two responses, /portal and /portal.js, precisely so that the page's Content-Security-Policy can allow no inline script at all.

It has addresses. #/f/<id>, #/m/<id>, #/search, #/compose: a folder and a message can be linked to, Back and Forward work, a reload lands where the reader was, and a half-written reply survives one.

It looks like the Control Deck, which is to say like the Control Panel - the same visual language, applied to a page that had none.

It notices new mail. GET /api/v1/me/changes hashes the per-folder message and unseen counts into an opaque token and answers changed against the one you hand back. The page polls it every six seconds, stops dead while the tab is hidden, and puts the reader's cursor back by message id rather than by row.

It manages folders. POST, PUT and DELETE /api/v1/me/folders create, rename and delete, judging a name exactly as IMAP's CREATE, RENAME and DELETE judge it and refusing in IMAP's own sentences. The page does not offer delete for the inbox or for a folder the server has designated for a special use: that route refuses those deliberately, because a page has no undo.

Inline images work, and the way they work is the interesting part. Attachment entries carry content_type and content_id. The obvious design - point the <img> at the attachment download route - cannot work, and that was measured rather than assumed: the message body is rendered in a frame sandboxed without allow-same-origin, so its document has an opaque origin, so the browser counts its subresource requests as cross-site, so the SameSite=Strict session cookie never travels and the route answers 401. The only thing that would fix that is the attribute the frame exists to withhold. So the page fetches the attachment itself, with its own credentials, and hands the frame the bytes as a data: URL. The frame's policy names no URL at all, and remote images stay off. What decides whether something is inlined is the server's own Content-Type on the download rather than the message's claim, so the types the download route deliberately neuters - HTML, SVG, XML, script, all served as application/octet-stream - are never inlined and stay in the attachment list.

And its script is executed in CI. build/check-portal-script.py extracts the page and the script out of the C++ literals and runs the script against a small DOM and a stubbed API: 88 checks. What stood there before was a test that asserted certain substrings appeared.

Under the surface

A message with a non-ASCII folder name is stored correctly on Linux. The modified UTF-7 encoding IMAP uses was broken in both directions there: the conversion handed iconv the string's terminator, which its UTF-7 decoder refuses, and never made the flush call that ends a stateful encoding. A command line with a non-ASCII byte arrives whole. CStdString converted narrow to wide through the C locale on Linux, which stops at the first byte above 127 - so an IMAP SEARCH CHARSET UTF-8 and a MAIL FROM under SMTPUTF8 were cut short. A TLS key-exchange group list that OpenSSL rejects is reported once, not once for every listener and every outbound delivery. On the OpenSSL that Debian and Ubuntu ship, which is older than the ML-KEM hybrids this server prefers, that was hundreds of medium errors an hour for a condition the fallback already handled. The administrator's user name is no longer translated in the Control Panel's sign-in box, which made a fresh installation in Chinese, German or Swedish refuse the credential it had just asked for. (#156, #177) The installation-paths diagnostic lists every directory the server was configured with and whether it exists. (#158)

Verification

The full regression suite ran on the stamped binary: 2,175 tests, 2,166 passed, 0 failed, 9 skipped (2 ignored, 7 explicit stress runs). hMailServer.exe 6.3.0.39, SHA-256 C9E8853B89883B02CF0BB3E5FBCA33E87CC6A6E8DD0666CE61B101F2EB95638B; installer hMailServer-6.3.0-x64.exe, SHA-256 D9F1217375DD70D523FFB27DBDCD668DD525EDC98EDF64F00B4F69D070434FCB.

The assertion build, first. The same source compiled with every HM_ASSERT kept - a violated one is reported as HM6364 in the error log rather than compiled out - and the whole suite run on it: 2,175 tests, 0 failed, the same 9 skipped, and no assertion violated anywhere in the run.

Reproducible. Two clean Release builds of the stamped source produced a byte-identical hMailServer.exe, SHA-256 C9E8853B89883B02CF0BB3E5FBCA33E87CC6A6E8DD0666CE61B101F2EB95638B. The Linux binaries keep the same promise by a different mechanism, described in RELEASE.md.

Fuzzed. Three libFuzzer targets over the MIME parser and its character handling, thirty minutes each on the release source: mime_message_fuzzer 241,817 executions, mime_header_fuzzer 261,618, mime_decode_fuzzer 7,792,919 - 8,296,354 in all, with no crash, no hang, no leak and no violated assertion. Required this release rather than carried over, because Mime.cpp, CodePages.cpp, Charset.cpp, ByteBuffer.cpp, StringParser.cpp and Unicode.cpp all changed.

And the suite ran against the Linux server. hmailserver/test/LinuxRegressionTests is a net10.0 project that compiles 260 of the suite's own files in place - not copies of them - under a REST-backed fixture layer standing where COM stands on Windows, and runs them against the Linux server on PostgreSQL: 756 passed, 0 failed, 649 skipped of 1,405, in 40 minutes. A test that passes there is the same test that passes here; no fixture is edited and no assertion is weakened. CI runs it on every push, against the binary the same workflow has just built.

The Linux packages install on a clean machine and the installed server answers.

Upgrading

No schema change: 6031, as 6.2.28. The installer's database upgrade runs as usual and has nothing to do on a 6.2.28 database.

Windows. Run the installer over the existing installation, as always. Nothing this release adds is on by default: the REST API needs RestApiPort, which is what the Control Deck and the portal are served on, and a server upgraded without touching its settings behaves exactly as 6.2.28 did.

Linux, first installation. apt install ./hmailserver_6.3.0_amd64.deb or dnf install ./hmailserver-6.3.0.x86_64.rpm, then hmailserver --create-database, hmailserver --set-admin-password, systemctl enable --now hmailserver. The configuration is /etc/hmailserver/hMailServer.ini, which carries a paragraph on every key it sets. The wiki's Installing on Linux page is the walk-through.

Moving a Windows installation to Linux is not a supported migration and this release does not claim it is. The database schema is the same and the message store's on-disk format is the same on both, so the pieces are there; what is missing is a tested path, and the roadmap says so rather than this page implying otherwise.

Known and unfixed

The installer is not Authenticode-signed. This project has no code-signing certificate, so Windows shows an unknown publisher and SmartScreen warns before it will run the installer, as it has for every release of this fork. What is signed is Sigstore: every asset on the release carries a .cosign.bundle beside it, and cosign verify-blob against that bundle is the check that means something here. It is also why the server's own updater refuses this project's releases when UpdateRequireAuthenticode=1; the default is 0 and the Sigstore verification cannot be turned off. Per-domain DKIM cannot be configured on Linux. As the API section says: there is a read route and no write route, and a PUT to it answers 404. On Windows the Control Panel sets it; on Linux nothing does. A domain that must sign its outbound mail with DKIM is not one to run on this platform today. The Linux regression run still skips, and the skips are the API's gaps rather than the server's. A fixture that reaches something no route can answer is ignored with a reason naming what is missing - hMailServer.ini itself, the administrator password, the event-handler scripting, the anti-spam address lists, the account groups, the incoming relays, an account's or the administrator's second factor, the directory-sync preview, the live log - rather than being weakened until it passes. Those are covered on Windows, where the suite drives COM, and the count above is what remains.

The server can update itself

A release is noticed, verified and applied - by a click, or inside a window you choose. UpdateCheckEnabled=0 is the default and nothing happens at all until it is set: no request, no identifier, no configuration, no counts. Turned on, a scheduled task reads this project's release feed every UpdateCheckHours (24 by default) and the Status page reports what it found. Fetching an installer and applying it are two further, equally opt-in steps.

What is applied is what this project signed. The installer is downloaded with the release's Sigstore bundle and verified before it is run: the certificate chains to Fulcio, the identity and issuer are this project's release workflow, the signature covers the file, and the entry is in the public transparency log. UpdateTrustRootsFile, UpdateSigningIdentity, UpdateSigningIssuer, UpdateSourceRepository and UpdateLogPublicKeyFile point that at a private Sigstore instance instead. This project's releases are not Authenticode-signed, so UpdateRequireAuthenticode=1 refuses every one of them; the Sigstore check is not optional and cannot be turned off.

The apply survives its own failure. hMailServer.Updater.exe runs the installer with the service stopped, waits UpdateServiceWaitSeconds (180) for it to come back, and reinstalls the previous version if it does not; the outcome is reported at the next start. The database upgrade authenticates with a single-use token, revoked at every service start, rather than with the administrator password. UpdateBackupBeforeApply=1 means an unattended apply does not happen at all without a configured backup destination and a backup that succeeded.

It works from behind a proxy. HttpProxy=host:port sends every web request this server makes as a client - the feed, its downloads, JWKS, token introspection - through a forward proxy: CONNECT for https with the TLS handshake inside the tunnel and the same certificate verification as a direct connection, the absolute URL for plain http. A proxy that refuses is reported by its own name and status line. No proxy credentials.

Only from 6.2.28 onwards. The version you are reading about is the first to carry any of this, so the upgrade to it is manual for everybody, as every upgrade has been. Its own Updates card in the Control Panel is where the next one is turned on.

An account can use its mailbox in a browser

/portal on the REST listener, and /api/v1/me behind it. It answers to an account's own credentials and to nothing else: no administrator password, no API key. Signing in exchanges the password for a session cookie the server keeps, so the password is sent once. A second factor is asked for where the account has one.

The page reads and writes the mailbox it belongs to: folders with their counts, a folder's messages with a cursor the keyboard moves, a message shown as it was sent - an HTML message inside a frame with an origin of its own, where nothing can reach the page around it - threads, flags, move, delete, marking in bulk, search over the account's own mail, attachments downloaded decoded under a type a browser will not execute, and shared and public folders alongside its own. It sends: a text or HTML message with attachments added the way the COM API adds one, every address put through the same checks a submitted message meets, drafts kept in the Drafts folder and replaced rather than duplicated, reply, reply-all, forward and Bcc.

It also carries what a person would otherwise ask an administrator for: the account's own quarantine, with release and delete; its name, forwarding, signature and vacation reply; its active Sieve script; and a password change - which is why the Control Panel's password-expiry text now says an expired password is renewed by an administrator or by the person themselves if they hold an app password.

A real HTTP server underneath

The REST API and the web services (autoconfiguration, autodiscover, the mobileconfig profile, CalDAV and CardDAV redirects) ran on a single-threaded HTTP/1.0 loop written for a handful of administrative requests. They now run on HttpServer: HTTP/1.1 on Boost.Asio with its own io_context and four workers, keep-alive, chunked bodies, header and body limits, and separate header and body deadlines. Every API answer carries Cache-Control: no-store. This is what a browser talking to the portal actually needs, and it is why the portal exists.

IMAP COMPRESS=DEFLATE (RFC 4978)

A session compresses both directions on request, so headers, bodies and the FETCH traffic of a large mailbox go over the wire deflated. It is advertised until compression is on and refused afterwards, as the RFC requires, and STARTTLS is refused once a session is compressed.

The Control Panel in seventeen languages

Czech, Danish, German, Spanish, Finnish, French, Italian, Japanese, Norwegian bokmål, Dutch, Polish, Brazilian Portuguese, Russian, Swedish, Turkish, Ukrainian and Simplified Chinese, beside English: every page, dialog, message, hint and verdict sentence - 3,376 texts, not a subset. The language is chosen in the connect card and remembered per user. Three checkers keep it honest in CI: a new English caption fails the build until it is marked and translated in all seventeen, the catalogues are checked against each other for the server's own words, numbers and page names, and every [Settings] key the server reads is checked to have an editor.

Administration in the browser

The Control Deck - the page the REST listener serves at / - reads the server's settings, the log files with any file's last 200 or 2,000 lines, the certificates by name and file, and the global rules with their criteria and actions in evaluation order. Writing is still the desktop Control Panel's and COM's; the roadmap row says so. The page is served as the bytes on disk with a Content-Security-Policy that allows its own inline script and style and nothing else, nosniff and no-referrer.

Fixed

A masked password was typed backwards from the second character (#156). In the Control Panel with the password hidden, 12345678 became 18765432; revealed text was fine. The masked box rebuilt its mask on every change and then restored the caret to the index it had read before the keystroke - correct on the ordinary keyboard path, wrong on an IME commit and on some layouts, which is what the reporter had. Every password box in the Control Panel now places the caret from the change itself.

Saving the SSL/TLS page dropped the post-quantum key exchange groups; saving the Scripting page took every COM object from every script. Two of the settings editors added for this release shipped without the server's absent-key default, and saving a page writes every field, so a blank was written where the server's own list belonged. Both now carry it, and both captions say what an empty value really does.

Five defects in the live update, found by reading it back against the tree before it had ever shipped: an unvalidated release tag and installer name from the feed, the apply token readable by any account on the machine, old downloads never swept, and the token not revoked at start.

The certificate renewal arithmetic that makes a 47-day certificate lifetime a non-event is pinned by tests rather than assumed.

Ten defects in the portal page, found the same way: attachments carried on forward and edit-draft, reply-all addressing, Bcc, thread indentation, the message list's cursor after a refresh, and a sign-in prompt instead of silence when a session expires.

Also in it

The four open code-scanning alerts closed on their merits, and the C# tree's LINQ notes rewritten rather than dismissed. The repository's own documents and all 51 wiki pages read against the tree and corrected: routes, settings keys, schema and release stamps, two false paragraphs about the listeners, and two pages that did not render. A roadmap section for Linux and AArch64, written from a measurement of the tree - 603 translation units through one ATL precompiled header, no CMake anywhere, but 466 of 1,237 server sources with no Windows token at all - rather than from hope.

Upgrading

No schema change: 6031, as 6.2.27. The installer's database upgrade runs as usual and has nothing to do on a 6.2.27 database.

Everything this release adds is off by default. UpdateCheckEnabled, RestApiPort (which the portal and the Control Deck need), IMAPCompressionEnabled and HttpProxy are all opt-in, and a server upgraded to 6.2.28 without touching its settings behaves exactly as it did on 6.2.27.

Verification

The full regression suite ran on the stamped binary: 2,127 tests, 2,119 passed, 0 failed, 8 skipped (7 explicit stress tests, 1 ignored where STARTTLS is not offered on the plain IMAP port of this bench). hMailServer.exe 6.2.28.38, SHA-256 9E89C1E3ABF4DD36560B0B5F3515BDA3DAB8B96F00EF35DA5376A9B60176BD15; installer hMailServer-6.2.28-x64.exe, SHA-256 FCC791855E9C1C4F3B2D3B8592B4D9CCBAC000DA866BBF8617561415078D5054. The database scripts build a 6031 database from the create script with all 65 schema probes passing, and the upgrade chain is contiguous and forward-only.

Known and unfixed

The Control Deck reads but does not write; a browser session for the administrator is still owed, so it holds the administrator password in sessionStorage while it is open. The regression suite runs on Windows only. The Linux and AArch64 section of the roadmap says what that would take.

Security

A missing DS is proved missing, not assumed (RFC 4035 §5.2, RFC 5155 §8). The DNSSEC validator that guards DANE and the SPF, DKIM and DMARC lookups treated a DS query answered with nothing as an unsigned delegation - which is exactly what an attacker who strips the DS from the answer on the way shows a resolver, and a signed zone quietly became an unsigned one, DANE and validated TXT gone with it. The resolver now keeps the authority section of a negative answer and requires the parent's proof there: an NSEC at the delegation name with NS set and DS clear, an NSEC3 whose hashed owner matches with the same bits, or an Opt-Out NSEC3 covering the hash, each signed by the parent's key. A proof that fails to verify, has expired, claims a DS exists, or belongs to another name is no proof, and a delegation without one under a signed parent is Bogus - blocked, as a forged chain is - rather than Insecure. An unsigned parent still makes everything below it Insecure, as it should, and a resolver that cannot be reached still degrades to Insecure rather than lying. Twelve tests run the resolver against a chain the suite signs itself, through the new Diagnostics.DnssecChainStatus.

Mail flow

An external IMAP account can mirror every folder (FetchAccount.MirrorFolders, schema 6031; in the Control Panel, Mirror every folder on an IMAP external account). With it on, the server lists the remote mailboxes and collects each into the local folder of the same name: every message byte for byte, its \Seen \Flagged \Answered \Draft \Deleted flags, its internal date, the remote hierarchy delimiter mapped to the local one. Nothing is delivered - no header, rule, anti-spam or anti-virus touches a copy - because it is mail the other server had already accepted. Each folder keeps its own record of what has been collected, so a second poll takes only what is new, and days to keep messages 0 makes it a move, folder by folder. This is the imapsync shape: the way to bring a mailbox from another IMAP server, or from a hosted service that is switching Basic authentication off, into this one.

The Import Tool reads a Maildir. A second button takes a Maildir - the directory with cur, new and tmp - and imports the INBOX and every Maildir++ folder beside it, with the flags the file names carry (;2, and !2, accepted as well as :2,, since a colon cannot be in a Windows file name) and line endings made CRLF.

Migration.md is the guide the roadmap asked for: from another IMAP server, from mbox, from a Maildir, from Outlook (through IMAP - PST is deliberately not parsed, and the page says why), from the upstream hMailServer in place, and accounts in bulk; what each route keeps and what it does not.

A message imported into a folder a client has open appears at once. The Import Tool's import told nobody that the folder had changed, so a session with the folder's message list cached saw the copy only after a restart. The folder is now refreshed, as it is after a delivery.

Also in it

Four roadmap rows brought up to date after 6.2.26, and the create-script check and the DBUpdater's message record what #114 taught.

Upgrading

Schema 6030 → 6031: one column on hm_fetchaccounts, added by the installer's database upgrade on every backend; the SQL Server Compact verification that 6.2.25 got wrong was fixed in 6.2.26 and is proved on a fresh database before every release. From 6.2.25 or 6.2.26: run the installer. From earlier: the 6.2.25 and 6.2.24 notes describe what changes on the way.

Verification

Three clean Release builds of the stamped source produced a byte-identical hMailServer.exe 6.2.27.37 (SHA-256 8CD745C49657A2E02989A8A86E9290C0AA49D317466B860C3749C757C129410F). The full regression suite ran on the assertion-enabled build of this source and again on the shipping binary: 2024 tests, 2017 passed, 0 failed, the 7 explicit skips, both times. The Control Panel's tests passed. hMailServer-6.2.27-x64.exe is 77,237,885 bytes, SHA-256 F60D3C30F27AF9EDC18BEE295DA231C666E826C1436E2214593B33499227C1A6; its Sigstore bundle and the two SBOMs are attached below, signed by this repository's sign-release workflow.

The fix

Every SQL Server Compact upgrade through schema 6030 was reported as failed after it had succeeded (#114). After each upgrade script, the database updater proves the schema changed by running a probe statement, and reads a failed probe as a missing object. The four probes for schema 6030, the foreign keys, were written with case when exists (subquery) in the SET expression - valid on SQL Server, MySQL and PostgreSQL, and on SQL Server Compact an access violation inside the OLE DB provider, on a correct database with every constraint present. The server caught the fault and reported it as HM10045 Unknown error, the updater declared that Upgrade6029to6030MSSQLCE.sql had not created fk_hm_accounts_domain and blamed an [IGNORE-ERRORS] marker the statement does not carry, and the installer said the database could not be upgraded. Two seconds after answering the probe, the server's crash oracle - which treats a memory-safety fault as fatal - ended the service, and service recovery started it again.

Reproduced from a Compact Edition database created at schema 6011 and upgraded with the shipped scripts: it reaches 6030 with all seventeen foreign keys, and the probe then faults the provider. The probes now read update hm_dbversion set value = value / (value - value) where not exists (select 1 from information_schema.table_constraints where constraint_name = '...' and constraint_type = 'FOREIGN KEY'): with the constraint present no row matches and nothing is evaluated; with it absent the one row matches and the division by zero fails the statement on every backend, leaving hm_dbversion untouched. The updater's message no longer asserts a cause it cannot see; it gives the backend's own words and says how to read them.

So that a probe the backend cannot run is caught before a release: build/check-db-scripts.ps1 now executes every probe against the database it builds from the create script, through the provider the server uses, with a negative control that must fail; and a regression fixture runs them through the same COM path the updater takes, against the bench database, which is Compact Edition. Both fail on the 6.2.25 statement.

If the 6.2.25 installer failed on your database, it is at schema 6030 with its foreign keys in place, and this installer finds nothing left to upgrade. If you restored a backup from before, the whole chain runs and the verification passes.

Also in it

Two roadmap rows closed on what 6.2.25 did (the fuzz run and the assertion-build gate a release records, and the accessibility audit), and the native-coverage rows now say why they are blocked rather than merely open.

Upgrading

From 6.2.25: run the installer. From 6.2.24 or earlier: the 6.2.25 notes and, before them, the 6.2.24 notes describe what changes on the way; everything there still applies.

Verification

Two clean Release builds of the stamped tree produced the same hMailServer.exe byte for byte (SHA-256 89E72B5B143FD0B9AFD20A4A7848AB1F746E58582BF015238147B74F352A5329); the full regression suite ran on the assertion build (every HM_ASSERT live: 2004 tests, 1997 passed, 0 failed, the 7 explicit skips, no assertion violated) and again on the shipping binary (2004, 1997 passed, 0 failed, 7 skipped), with the three new probe tests in both runs; the Control Panel's own tests passed; the database checks ran all 64 schema probes against a freshly created database with the negative control failing as it must. Installer hMailServer-6.2.26-x64.exe SHA-256 BFB1E5D606D3FB18B2BBBE26A8704A29033C807E293988265F47E75891905F1E; the SBOM and the cosign signatures attached to this release were produced and verified by the workflows after the tag.

If you are on 6.2.21 or a 6.2.22/6.2.23 pre-release, read the 6.2.24 notes first; everything there still applies, and the upgrade section below starts from 6.2.24.

The fix to upgrade for

ACME issuance and renewal ended the process (#93). Two calls in the ACME client handed the OpenSSL DLL a FILE* opened by the server's own C runtime: the one that computes the DANE TLSA line logged straight after a certificate has been issued, and the one that re-reads the existing private key at the start of every renewal (the default, AcmeReuseKey). On Windows the OpenSSL DLL does not read such a FILE* itself; it routes every stdio call back into the executable through an OPENSSL_Applink export the executable has to provide, and this executable never has. OpenSSL's answer to the missing export is not an error return: it writes "OPENSSL_Uplink(...): no OPENSSL_Applink" to the Windows Application log under the source "OpenSSL" and calls TerminateProcess. That is the whole picture the reporter saw - an OpenSSL event with a message that looks blank, a 7031 from the service control manager in the same second, no crash dump, and no "ACME (automatic)" certificate record because the TLSA line ran before the deployment.

Both calls now go through OpenSSL's own file I/O, as every other file the ACME client touches already did. The deployment runs before the TLSA line, so nothing optional stands between a renewal and the restart it exists for. A class test in the server's self-test computes the TLSA of a fixture certificate the way the old code would have, so the crash cannot come back unnoticed.

If 6.2.24 issued you a certificate before it died, the files under Data\ACME are valid, and 6.2.25 deploys them at its first ACME check after start-up: a certificate pair on disk that no "ACME (automatic)" record names is deployed once, the way a fresh issuance is - the record, the assignment to TLS ports that have none, the restart. The application log says "issued but never deployed" when that happens.

Found on the way, and fixed in the same release: two restarts of the servers at once - one asked for over COM, one started by an ACME deployment or a backup restore - tore down and rebuilt the same queues under each other and could end in an access violation. Restarts now run one after the other.

What is in it since 6.2.24

Mail flow

External accounts over IMAP. FetchAccount.ServerType 1 collects a remote INBOX once by UID - LOGIN or XOAUTH2, STARTTLS or TLS as the account says - and leaves it on the server unless DaysToKeepMessages says otherwise. Everything after the download is the POP3 fetcher's code. The INBOX only; folders are not mirrored. Message retention (schema 6027). Domain.MessageRetentionDays and Account.MessageRetentionDays remove delivered mail older than the policy, in every folder, through the same deletion an EXPUNGE performs, by stored creation time and never by the sender's Date header. Off everywhere until a number is set. The archive has an index (schema 6029): one row per copy, searched over COM and GET /api/v1/archive, a legal hold that survives the retention sweep and an address erasure. ArchiveDomains scopes the archive to the domains it is kept for. Outbound delivery pipelines the envelope and sends the message as one BDAT chunk when the remote advertises PIPELINING and CHUNKING (OutboundPipelining, OutboundChunking, both on; either can be turned off). A binary message is now relayed as it is to a remote that accepts BINARYMIME. Delivery hard links (DeliveryHardLinks, off): a message to several local recipients can be one file with a name in each folder, and every rewrite of a message file is a temporary file renamed into place. SEARCH BODY and TEXT read the text-bearing attachments, and the full-text index tokenises them, so a phrase that lives only inside an attached text, HTML or CSV file is found - the same with the index on and off. ManageSieve advertises envelope, which had shipped without its capability line. A Message-ID is added only for submissions (upstream #552): the client authenticated, or sending as one of our domains from a range that does not require it to. Relayed mail keeps its headers as they are, so SpamAssassin's MISSING_MID and a rule looking for the header see the truth. A stranded fetch account (upstream #603): a fetch that threw, or a database error recording the next try, left the account locked and silently skipped until a restart. The task owns the lock now.

IMAP

Every session numbers its selected folder for itself (upstream #602). Another session's expunge no longer renumbers a client's messages under it; a message found gone is answered NO [EXPUNGEISSUED], and QRESYNC sessions hear VANISHED. Sessions stop sharing unguarded state (upstream #580, #566): one lock on the connection, serialised lazy collections, snapshots for cross-thread readers. One strand per connection. A write from another thread - a notification to an idling IMAPS session - can no longer run inside the SSL engine while that connection's own read is mid-decrypt. Default special-use folders at account creation (CreateDefaultSpecialUseFoldersEnabled, off; schema 6026): Drafts, Sent, Trash and Junk with their RFC 6154 designation stored on the row. One authorisation choke point. Every "may this account do this to that folder" is one decision, delivery and rules included, and a CI guard fails any second decision-maker.

Security and authentication

SASL EXTERNAL. A client certificate that verified against the port's CA logs on as the mailbox it names - through the addresses the certificate carries and nothing else - on SMTP, IMAP and POP3. Found on the way: the AUTH line limit was 500 octets on POP3 and 510 on SMTP, so a real RS256 bearer token had never fitted; it is 12288 now, RFC 5034's figure. OAuth2: the provider's JWK Set as the signing-key source (OAuth2JwksUrl, rotation handled) and token introspection for revocation (OAuth2IntrospectionUrl). Both off unless configured. scrypt (PreferredHashAlgorithm=7, OWASP parameters), and schemes compared by strength rather than by number, so a preference for scrypt leaves Argon2id accounts alone and a minimum of either accepts both. The password-hash work factor is a setting (PasswordHashIterations, PasswordHashMemoryKB, PasswordHashTimeCost; upstream #554), and a hash derived under a cheaper one is re-derived at the next logon. Upward only. Tarpitting on failed logons and on stranger recipients (LogonTarpitSeconds; SmtpTarpitCount and SmtpTarpitDelaySeconds; all off), as a pause on the connection's own timer, never a thread asleep - which is why the two old COM properties were stubs for years. The administrator's second factor is the server's now. With a TOTP secret enrolled (Settings.EnrolAdministratorTOTP), COM needs AuthenticateWithCode and the REST API needs an X-hMailServer-OTP header; a stolen administrator password is no longer a complete credential. An authenticated session may only send as an address its account owns or has been granted (SmtpAuthenticatedSenderCheck, off), and the post right on a mailbox's INBOX is the Send-As grant. Event scripts can create only the COM classes ScriptAllowedObjects names. The default is *, which is what every earlier version did; set it to a list and CreateObject of anything else fails inside the script with error 429. The Apple configuration profile is served over HTTPS only (see the upgrade section).

Anti-spam and anti-virus

spamd is told whose preferences to apply (SpamAssassinUser, SpamAssassinUserFromRecipient; off), and moving a message into the Junk folder teaches SpamAssassin it is spam, out of it teaches ham (SpamAssassinLearnOnMove, off) through spamc's TELL. The ClamAV connection test asks PING and VERSION first, names the daemon it reached, and streams its EICAR sample from memory - the button had failed on every Windows with real-time protection on, because Defender removed the sample file before clamd saw it.

Administration

The REST API reaches what was COM-only: IP ranges, distribution lists, certificates (never the private-key password), DKIM, the global rules, the logs, the backup and a settings snapshot, each decided at the same authorisation choke point. Writing settings, rules, certificates and DKIM stays COM-only, on purpose. The server remembers its metrics (schema 6028): one row per metric per minute, kept a week (MetricsHistoryDays), read back over COM and GET /api/v1/metrics/history, shown on the dashboard for a day, a week or a month. Every backup proves its mail can be got back out (BackupVerifyRestore, on): the archive's message store is extracted to a scratch directory through the same code a restore runs, before the backup is called complete. Control Panel: follows Windows High Contrast for every control; every static caption carries an Alt-key mnemonic, checked in CI; page titles are headings and status text is a live region; the Welcome page starts from what you want to do; the stalled-mail diagnosis guide is a page; the status palette is held apart for colour-blind eyes by a test; "Advanced & scripting" is "Advanced". The data directory synchronizer walks the public folders (upstream #601), and the importer refuses a file under #Public the database does not reference rather than guessing where it belongs.

Databases

TLS to PostgreSQL and MS SQL is a line in hMailServer.ini: PostgreSQLSslMode and PostgreSQLSslRootCert under [Database], ConnectionStringOptions appended to the OLE DB connection string. An unknown sslmode refuses the connection with the reason rather than falling back to "prefer". A plaintext MySQL is an ini choice rather than a silent downgrade (upstream #559): AllowUnencryptedConnection=1 lets the client fall back from TLS; the default still refuses a server without it. The schema enforces its own parent-child relationships (schema 6030): seventeen FOREIGN KEYs with ON DELETE CASCADE, so a crash mid-delete can no longer leave rows behind.

Platform and hardening

OpenSSL 4.0.2 (a security patch release: eleven CVEs, the most severe Moderate) and Boost 1.92.0, built with the tree's own scripts. The fourteen open CodeQL C++ findings are dealt with, each on its merits: a byte buffer copied rather than reinterpreted, the Windows 2000 address workaround retired, the SPF address copy a memcpy, the Apple profile served over HTTPS only and its handler no longer named in a way the private-data heuristic reads as a phone number; and the ten boost::asio TLS-settings findings dismissed as false positives with the reason on record - the query wants every set_options call reachable from a context's constructor to carry the protocol flags as a constant, and Boost's own constructor makes such a call with no_compression, so no program built against a real Boost can satisfy it (verified with the query's own predicates against this tree). Every context is nonetheless built with one constant floor - SSLv2, SSLv3, TLS 1.0 and TLS 1.1 off - and the administrator's protocol toggles act on the mail listeners and the mail client afterwards. The static-analysis backlog is triaged: a repeatable /analyze build, 632 findings read, the defect-class ones in the project's own code fixed - among them a service-dependency buffer sized in bytes for a function that counts characters - and the rest named with the reason they stay. A Release build that keeps its assertions (build.ps1 -Asserts) is the dynamic-analysis build the suite runs against before a release; a violated assertion is reported as HM6364 naming the expression, file and line. It is never the binary that ships. A timed fuzz run is a release step, and the C++ tree is spaces, checked. The fuzz harness had not built since 13 August (the MIME parser had gained two dependencies the harness shim did not supply, and the harness's MSVC-environment check was fooled by Git for Windows' link.exe); it builds again, and this release's run is below.

Build, scanning and supply chain

The C++ server is compiled on a GitHub-hosted runner on every push and pull request, with OpenSSL, Boost and libpq built from pinned, digest-verified sources and cached - and the weekly C++ CodeQL analysis runs, which closes the second known limitation of 6.2.24. The Scorecard result is published to the OpenSSF API, so the badge and the viewer it links to answer; the Code Quality page grades the C# tree Excellent; NuGet lock files hold every restore. Twelve upstream ports in all (#550, #552, #554, #559, #566, #580, #592, #601, #602, #603 and two smaller ones).

Upgrading from 6.2.24

The database schema moves from 6025 to 6030 in five steps, one way. DBUpdater runs them in order and resumes from wherever a partial upgrade stopped. There is no downgrade.

Behaviour that changes on upgrade, without a switch

The Apple .mobileconfig profile is served over HTTPS only. It tells a device which servers to trust with the user's password, and a profile fetched over plain HTTP can be rewritten on the way by anyone on the path. A TLS-terminating proxy in front of the web-services listener says so with X-Forwarded-Proto: https; without that, a plain-HTTP request is answered with a 301 to the same URL on the WebServicesHttpsPort listener when one is configured, and with a 403 that says why when none is. The Thunderbird autoconfig and Outlook autodiscover documents are unchanged. A Message-ID is no longer added to relayed mail, only to submissions (authenticated, or from a local domain on a range that does not require authentication). Nothing in the server needed the header to be there; a downstream filter that counts on every message having one will now see the ones that arrived without. With IMAP ACL enforcement off, a rule or a delivery into a public folder is allowed - as every IMAP command already allowed it. It used to be refused for want of ACL rows nobody was enforcing. The four HTTPS clients - the ACME client, the OAuth2 token client, the MTA-STS policy fetch and the introspection/JWKS client - require TLS 1.2 or later whatever the mail protocol toggles allow. Mail delivery and the listeners follow the toggles as before. The AUTH command and the SASL responses that follow it accept lines of up to 12288 octets on SMTP and POP3 (they were 510 and 500). Every other line keeps its limit. IMAP sequence numbers are stable within a session (upstream #602). A client that relied on the old behaviour - a message expunged by another session shifting its numbers at once - was relying on a violation of RFC 3501. Account.DeleteMessages empties a designated special-use folder and keeps it, the way it has always kept the inbox; IMAP DELETE and IMAPFolder.Delete still delete one. A DANE TLSA line that cannot be computed after an ACME issuance is logged as such rather than being silently absent; the certificate is deployed first either way.

New settings, every one of them off or inert until you set it (all in hMailServer.ini unless named otherwise; the Control Panel carries each): DeliveryHardLinks, SpamAssassinLearnOnMove, SpamAssassinUser, SpamAssassinUserFromRecipient, SmtpAuthenticatedSenderCheck, LogonTarpitSeconds, SmtpTarpitCount, SmtpTarpitDelaySeconds, PasswordHashIterations, PasswordHashMemoryKB, PasswordHashTimeCost, OAuth2JwksUrl and its cache seconds, OAuth2IntrospectionUrl and its client credentials, cache seconds and fail-open switch, ArchiveDomains, PostgreSQLSslMode, PostgreSQLSslRootCert, ConnectionStringOptions, AllowUnencryptedConnection, [Security] AdministratorTotpSecret (written by enrolment, cleared to recover), Settings.CreateDefaultSpecialUseFoldersEnabled, Domain.MessageRetentionDays, Account.MessageRetentionDays, FetchAccount.ServerType. Three ship on: OutboundPipelining, OutboundChunking (each used only when the remote advertises the extension) and BackupVerifyRestore. MetricsHistoryDays defaults to 7 and ScriptAllowedObjects to *, which is what earlier versions did without a setting.

COM clients. The type library gained members (Utilities.SearchArchive, SetArchiveHold, GetMetricHistory, SampleMetricsNow, RunMessageRetention; Settings.EnrolAdministratorTOTP and DisableAdministratorTOTP; Application.AdministratorTOTPEnabled; COMAuthentication.AuthenticateWithCode; Domain and Account MessageRetentionDays; Diagnostics.AssertionsEnabled). Clients compiled against the 6.2.24 type library keep working; recompile to reach the new members. FetchAccount.ServerType was always there; 1 now means something.

Known limitations

Verified by reading, not on a live server: the PostgreSQL and MS SQL TLS keys, and AllowUnencryptedConnection for MySQL. The regression bench runs SQL Server Compact. IMAP external accounts collect the INBOX only. Other folders are not mirrored; a message that leaves the remote INBOX by other means is forgotten, not deleted locally. Statement timeouts were built for PostgreSQL and MySQL and have been exercised only against SQL Server Compact (carried from 6.2.24). SCRAM-SHA-1 is not offered (#49, with the reason); clients without SCRAM-SHA-256 use PLAIN or LOGIN over TLS (carried from 6.2.24). The fuzz harnesses cover the MIME parser and its codecs. The IMAP command parser, the SPF evaluator and the Sieve parser are exercised by the regression suite, not by a fuzzer.

The second known limitation of 6.2.24 - the weekly C++ CodeQL analysis not running - is resolved: it runs on a GitHub-hosted runner, and the code-scanning page is clear. Downloads and verification

Verify the tag, from any clone

git -c gpg.ssh.allowedSignersFile=.github/allowed_signers verify-tag v6.2.25

Verify an asset with cosign

cosign verify-blob --bundle hMailServer-6.2.25-x64.exe.cosign.bundle \ --certificate-identity-regexp '^https://github\.com/Progressiverobot/hmailserver/' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ hMailServer-6.2.25-x64.exe

The server binary is reproducible: two clean Release builds of this tag produce a byte-identical hMailServer.exe, SHA-256 4bfae5c7d9721cc4b2408f2512723369c0156ab445848620b854357a439b3345 (three clean builds, one before and one after the assertion build, all identical), with the v145 toolset (MSVC 14.51), Windows SDK 10.0.26100 and the library layout in README.md. The regression suite on that binary: 2001 tests, 1994 passed, 0 failed, the 7 explicit skips, 34 minutes. The same suite on the assertion build (build.ps1 -Asserts, every HM_ASSERT live and reported): 2001 tests, 1994 passed, 0 failed, the 7 explicit skips, no HM6364. Control Panel unit suite: 667/667. Fuzzing on this source (libFuzzer with ASan, LLVM 22.1.8, harnesses rebuilt from this tree): mime_message_fuzzer 265,770 executions, mime_header_fuzzer 274,986, mime_decode_fuzzer 4,793,507, thirty minutes each, no crash, no hang, no out-of-memory, no assertion.

If you are on 6.2.21, everything the two pre-release lines introduced arrives at once. The section after next is written for you.

What is in it since 6.2.21

Two pre-release lines, 6.2.22 (pre1 to pre6) and 6.2.23 (Alpha 1 and 2), carried the work. Their notes are the detailed record - 6.2.22 pre-releases, Alpha 1, Alpha 2 - and this is the shape of it:

Mail that was silently lost is not any more. A delegated APPEND, COPY or MOVE filed bytes under the wrong account; a MOVE destroyed the only readable copy. Thunderbird's every Sent copy was refused once UTF8=ACCEPT was enabled (#53). A kept-open log was never flushed (#33). The ACME client had never worked against real Let's Encrypt (#34). Anti-spam bypasses closed. A sender could steer a per-account spam override into un-marking their own mail by forging a header; a sender could choose which address the DNSBL, SPF and HELO tests ran against through the HELO literal in the Received header; RSET before EHLO or STARTTLS without a fresh EHLO opened a transaction with the HELO host empty, skipping the HELO-host test and the script events. Features. Shared and delegated IMAP mailboxes, full-text search, RFC 3464 machine-readable bounces, BINARYMIME, per-account spam thresholds, a sender blacklist, domain-wide out-of-office, distribution-list moderation, Windows Event Log integration, OTLP metrics and logs, a reverse-proxy PROXY-protocol front for SMTP, an external HTTP filter hook, eleven IMAP extensions (APPENDLIMIT, LITERAL-, LIST-STATUS, UNAUTHENTICATE, QUOTA, PREVIEW, MULTIAPPEND, REPLACE, SAVEDATE, METADATA, BINARY), Microsoft 365 XOAUTH2 in both directions, app passwords, TOTP for the Control Panel, a quarantine, password history, message trace, per-domain outbound relay, a disk-space floor, and a substantial Control Panel overhaul. Hardening. Control Flow Guard on the server; a reproducible build (two clean builds give the same bytes); signed release tags; SBOMs and Sigstore bundles on every release; a COM vtable layout repaired to be binary-compatible with 6.2.21; an unattended install that fails its database step now exits non-zero; an unattended upgrade can no longer hang on a password dialog.

Upgrading from 6.2.21

The database schema moves from 6011 to 6025 in fourteen steps, one way. DBUpdater runs them in order and resumes from wherever a partial upgrade stopped. There is no downgrade: an older server refuses a newer database rather than misreading it, so take a database backup and a data-directory backup before you install, with your backend's own tools. Rollback is only as good as that snapshot.

Two of the steps are worth planning for:

Behaviour that changes on upgrade, without a switch

A client that sends MAIL FROM or AUTH straight after the STARTTLS handshake, without saying EHLO again, now receives 503 Bad sequence of commands. RFC 3207 has required the second EHLO all along and every mainstream client sends it; a home-grown submission script that skips it will find out here. For mail arriving through an incoming relay or fetched from an external account, the anti-spam tests run against the address the relay actually observed, not the first bracketed value in the Received header (which was the client's HELO literal). If you tuned scores around the old behaviour, expect verdicts to move. Mail is refused with a temporary error when the data volume falls below 100 MB free (MinimumFreeDiskSpaceMB, Control Panel: Server settings). Set it to 0 to restore the old behaviour of writing until the disk is full. Critical and high-severity errors also go to the Windows Event Log (source hMailServer, throttled). A service account that cannot create the event source logs a single line saying so and continues. Existing per-account out-of-office replies now honour the RFC 3834 suppressions (no reply to bulk, list, auto-submitted or bounce mail) that previously applied only to the domain-wide one. A bulk prune of old hm_imapexpunged rows runs once at first start (IMAPExpungeRetentionRecords, default 5000; set 0 to defer). Early-bound COM clients compiled against a 6.2.22 pre-release interop assembly must be recompiled against this release's type library; the pre-release layout was the broken one. Late-bound scripts (VBScript, PowerShell, PHP) are unaffected, and so is anything compiled against 6.2.21.

Everything else keeps its previous default. The full list of the 23 new INI settings, all shipped off or inert, is in the Alpha 1 notes and in README.md.

What changed since Alpha 2

NuGet lock files beside all nine .NET tool projects, and every restore in CI held to them (--locked-mode, RestoreLockedMode), so a package bump without its lock-file update fails the build rather than building against a graph nobody reviewed. This was the last OpenSSF Scorecard finding that code could fix; the other four are dismissed on the security page with the reason on each, and eight required status checks were added to the master branch ruleset. The version stamp. Nothing compiled into the server, the tools or the installer changed otherwise.

Known limitations

The Alpha 1 and Alpha 2 lists still apply. The three worth repeating for a stable release:

Statement timeouts were built for PostgreSQL and MySQL and have been exercised only against SQL Server Compact, the bench backend. The weekly C++ CodeQL analysis is not running: it targets a self-hosted runner that is no longer registered. The C# analysis runs on every push and pull request. SCRAM-SHA-1 is not offered (#49, with the reason); clients without SCRAM-SHA-256 use PLAIN or LOGIN over TLS.

Downloads and verification

Verify the tag, from any clone

git -c gpg.ssh.allowedSignersFile=.github/allowed_signers verify-tag v6.2.24

Verify an asset with cosign

cosign verify-blob --bundle hMailServer-6.2.24-x64.exe.cosign.bundle \ --certificate-identity-regexp '^https://github\.com/Progressiverobot/hmailserver/' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ hMailServer-6.2.24-x64.exe

The server binary is reproducible: two clean Release builds of this tag produce a byte-identical hMailServer.exe, SHA-256 64406163b1a3a8a865e34d74883b5e2a05a5a1c476b500b26745cde67d8a989b, with the v145 toolset (MSVC 14.51), Windows SDK 10.0.26100 and the library layout in README.md. The regression suite on that binary: 1838/1838, nothing skipped, 31 minutes. Control Panel unit suite: 645/645.

Everything in the 6.2.20 notes is in this release too.

The Postfix hang, found by running a real Postfix

Discussion #18 reported inbound mail from a Proxmox Mail Gateway never being received: the data arrives, the log stops dead after 354 OK, send., and the sending server eventually gives up with "timed out while sending end of data", leaving a zero-byte file in the Data folder. Three previous releases claimed to fix it. The reporter tested each one and was right every time that it was not fixed.

What settled it was standing up an actual Postfix 3.10 against this server and reading the bytes on the wire. Two facts came out of that:

When Postfix has nothing further for a connection, it sends the end of the body, the terminating dot and QUIT in one TCP segment — ...\r\n.\r\nQUIT\r\n. With more mail queued it pipelines the next MAIL FROM there instead. Every end-of-data check this server has ever shipped — including the one added in 6.2.18 for this very report — examined only the end of the received buffer.

With QUIT sitting behind the dot, the terminator is in the middle of the buffer, no tail check can match, and the session waits forever for something that already arrived. This also explains the two things that never added up: disabling PIPELINING "fixed" it because Postfix then waits for the 250 before sending QUIT, putting the terminator back at the end of the buffer; and whether any given sender triggers it is TCP segmentation luck, which a same-host relay wins essentially every time while internet senders almost never do.

The receive path now searches for the standard <CRLF>.<CRLF> anywhere in what has arrived and hands anything behind it back to the command parser, so a pipelined QUIT or a whole following transaction is executed rather than lost. Verified against the real Postfix: four deliveries that hung before now complete in under 20 ms with the QUIT answered and the message byte-identical.

The bare-LF spellings of the terminator, which this server accepts only when Allow incorrect line endings is on, are deliberately still recognised only at the very end of the buffer, and anything behind one is discarded — that is the CVE-2023-51764 SMTP-smuggling rule, and it is pinned by its own test.

A correction to the 6.2.18 notes: the bare-LF work that release described was real and is retained, but it was not this reporter's defect. Stock Postfix normalises bare LFs to CRLF before transmitting, so a bare-LF terminator cannot reach this server through Postfix at all — and that normalisation is also why their log showed 7,984 bytes against a declared SIZE=7975.

The Postfix test rig is now part of the repository (hmailserver/test/PostfixBench), so future builds are checked against a real MTA rather than only against a test helper that writes well-formed bytes.

SMTP dot transparency across buffer boundaries

A body line beginning with a dot is sent doubled and must be stored singled (RFC 5321 4.5.2). The test for "does this dot start a line" could not see across a buffer boundary, so a line-leading dot landing one or two bytes into a chunk was sent unprotected. The receiving server then un-stuffs a dot that was never stuffed: .X silently becomes X, and a body line consisting of a single . becomes <CRLF>.<CRLF> — the end-of-data marker — truncating the message there and handing whatever followed to the receiver's command parser. The receive path had the mirror-image defect, and after a forced mid-line split both could act on a dot that did not start a line at all.

Both directions now carry the line-start context across the boundary. Because this class of defect depends on exactly where a chunk boundary falls — something a socket cannot be made to do on demand — it is covered by in-process tests that drive the transform with exact boundaries, plus a black-box test that sends every dot shape through SMTP and reads it back over POP3.

Sieve scripts were left behind by renames and deletes

Sieve filters live in their own directory tree, separate from the mailbox. Nothing moved or removed them:

Renaming a domain moved every mailbox and left every account's filter behind. Delivery then found no script and delivered to INBOX everything the user had arranged to file, discard or redirect — with no error and no log line. Renaming an account did the same for that user. Deleting a domain or an account left the scripts on disk. Recreating that address later — a returning customer, a rebuilt test domain — silently reactivated the previous holder's filter for the new owner's mail, including any redirect it contained.

Renames now move the Sieve tree with the mailbox, and deletes remove it.

Related, in the Control Panel: the account editor wrote the Sieve script before asking the server to accept a rename. Because that property is written to disk immediately and keyed on the address, a rename the server then refused — a duplicate address, or an installation that still needs Data Directory Synchronizer — had already overwritten (or, with an empty editor, deleted) the script belonging to whoever holds the target address. The dialog only reported that the account could not be saved. The script is now written after the save succeeds, and only when it actually changed. Sieve filters can now read the message, not just its headers

The body test (RFC 5173) is implemented and advertised over ManageSieve, with all three transforms:

:text (the default) — the decoded text of every text part, which is what "if the message mentions X" means. Transfer encoding and charset are decoded before matching, so a filter written against plain text keeps working when the sender's client base64-encodes the part. :content "type" — the decoded parts of the named MIME types, so a rule can look inside the HTML alternative without matching the plain-text one. A bare top-level type such as image matches every subtype. :raw — the body exactly as it arrived, no decoding, MIME structure ignored.

Seven end-to-end tests assert where a delivered message was actually filed — never what the evaluator reported — including one whose search phrase appears nowhere in the transmitted bytes and can only match if the base64 part was decoded first.

While confirming what this section could claim, six roadmap rows were found describing the opposite of the current behaviour: they said unimplemented Sieve constructs such as reject parse as valid and silently do nothing, so "the author believes mail is being refused while it is in fact being kept". That was true once and is not now — anything this server does not implement is refused when the script is uploaded, with an error naming the construct — and a sweep test now pins that refusal for every unimplemented command and test by name, so none of them can quietly slip back to being accepted-and-ignored. An IMAP command that could hang a connection thread for good

SORT () US-ASCII ALL, and a bare SORT (REVERSE) ..., produce an empty sort-criteria list. The code that skipped to the last criterion then walked an iterator past the end of an empty vector, which in a release build is not a crash but an infinite loop: the connection thread spins at 100% of a core, never answers, and is never returned to the pool. Any authenticated user could send it, and SORT is advertised by default. The command is now rejected as the protocol error it is (RFC 5256 requires at least one criterion), with a guard inside the sort itself as well. The message cache could never evict, and only counted upwards

Folder message-lists are cached with a 512 MB ceiling. Entries are added before their first load, so each was recorded as occupying nothing — and the eviction routine stopped at the first zero-sized entry, which was always the oldest. The ceiling therefore never evicted anything; memory was bounded only by the 30-minute expiry, so folders never revisited stayed cached for the life of the process. Separately, every removal subtracted a stale figure (or, on expiry, nothing at all), so the running total only ever grew.

Eviction now measures entries as they are, and the total is recomputed from the entries themselves before any eviction decision rather than trusted from a running tally — necessary because expunges, moves and folder deletes shrink a cached list without telling the cache. A guard was also added where the cache reads a collection's length concurrently with another session appending to it.

DNS: a malformed answer no longer ends the lookup

A user reported DKIM validation failing against a local DNS server that 5.7 handled without complaint, always on the large multi-string TXT record that carries a DKIM public key. Reproduced against a deliberately misbehaving server: exactly two malformations — a record length that runs past the end of the packet, and a compression pointer that points outside it — make Windows reject the whole response as unparseable, and both are answered correctly by the same server over TCP. Such a lookup is now retried once over TCP. A timeout is deliberately not retried.

The Control Panel's MX-query tool (#29) asked the operating system's resolver via nslookup, so on any server with a custom DNS server configured it disagreed with the server about where mail goes. It now asks the server itself, through the same resolver SMTP delivery uses, via a new Utilities.ResolveMXRecords COM method. A failed lookup is reported as a failed lookup rather than as "this domain has no mail servers" — the distinction that matters when it is your own DNS server that is unreachable.

Control Panel

Seven things the retired Administrator could do, restored: pause and resume the server engine, restore default TCP/IP ports, restore default IP ranges, delete a domain, rename a domain, rename an account, and see at a glance which domains and accounts are inactive. Also fixed: creating a duplicate domain reported the error instead of closing the window; the search boxes no longer match rows on the text of their enabled/disabled flag; the brand colour now follows the light theme; and two settings descriptions were corrected — the DNS cache option described an in-process cache that has never existed (it controls whether Windows' resolver cache may answer), and the mailer-daemon domain setting misdescribed what an empty value does.

And the Welcome page (#30): each tile centred its icon over the width of its own caption, so the six icons sat at six different offsets — none of them chosen. They are now centred on the tile, uniformly. Thanks to @helptiger for the report and the screenshot.

Known issues

Equal-preference MX records are not randomised (RFC 5321 5.1); the server always tries them in the order the resolver returned. A comment and a COM help string previously claimed otherwise and have been corrected. One-click unsubscribe (RFC 8058) is not implemented. It requires a per-recipient token in the message headers, and this server stores one message file shared by every recipient, so it needs the same groundwork as list moderation. RFC 2369 List-* headers, including a List-Unsubscribe that reaches the list owner, are emitted for distribution-list postings.

The fresh-install failure in 6.2.19

Two defects stacked, and each is worth a sentence because each is a class.

The database creation failed. The SQL script runner splits a script into commands on blank lines, and SQL Server Compact — the embedded database a fresh install uses — executes one statement per command and refuses a batch. A recent change added settings to the create scripts with a single newline between inserts: three statements, one command. Full SQL Server accepts that batch, so the development database and the 1,490-test regression suite saw nothing wrong; only a fresh install runs the create script against SQL CE. The same adjacency was in the MySQL script (whose client refuses multi-statements by default too) and the PostgreSQL script. All three are fixed, and a mechanical sweep of all 199 SQL scripts confirms no multi-statement command remains in any create script or any SQL CE script. (Five upgrade scripts from the hMailServer 5.x era carry batches for the full-server backends that accept them; they have a decade of successful upgrades behind them and are deliberately left untouched.)

The failure hung instead of failing. The error raised a plain message box, and /VERYSILENT /SUPPRESSMSGBOXES suppresses only the suppressible kind — so a silent install did not report the failure, it waited on a dialog with nobody at the keyboard. In CI that was ninety minutes until a person cancelled it; on a real unattended deployment it would have been forever. Every dialog in the installer (28 of them — any one was a potential silent-install hang) now takes its default button under /SUPPRESSMSGBOXES, and the installer proceeds to an exit code a deployment script can actually read. Interactive installs see exactly the dialogs they always saw.

Who was affected: fresh installations of 6.2.19 using the built-in database (the default), and most likely fresh installations onto MySQL. Who was not: every upgrade of an existing installation — upgrades run the upgrade scripts, which were clean — and existing servers, whose databases already exist.

How it was caught

By the installer smoke test, which installs every release on a throwaway machine — and which has itself been fixed to be worth more: the silent-install step is now bounded at ten minutes instead of hanging with the job, writes and keeps the installer's own log, and on a database failure re-runs the setup tool and prints the stderr the real error had been going to all along. The 6.2.19 hang produced no evidence in ninety minutes; the instrumented re-run named the failing dialog and its exit code in ten.

Also in this release (since 6.2.19)

IMAP THREAD (RFC 5256), both algorithms — THREAD=ORDEREDSUBJECT THREAD=REFERENCES — with real References-chain threading: conversation trees for the clients that ask for them, bounded by the same per-command ceilings as SEARCH and SORT. An adversarial review of the new code found and fixed a stack overflow reachable through a deep reply chain, an uninterruptible header pass, and a malformed-Date sort inversion, before any of it shipped. The release-signing workflow could not name its own repository and failed on its first run; fixed, and 6.2.19's assets were signed by the re-run. This release's assets are signed the same way.

Validated by the full regression suite against this binary, and by the installer smoke test against this exact installer before the release was promoted from pre-release.

The DNS regression (#25)

6.2.16 rewrote name resolution onto the asynchronous DnsQueryEx so that a lookup could be bounded and cancelled instead of holding a pooled thread. In doing so it gave the custom-DNS-server entry a destination port of 53.

A DNS_ADDR carries a full SOCKADDR, so setting the port looks like the obviously correct thing to do. It is not. The DNS client supplies the port itself; with port 53 every query returns status 87 and no records, and with port 0 it works. The classic DnsQuery this replaced took a PIP4_ARRAY — a bare list of addresses with no port field at all — which is why the mistake was easy to make and impossible to see.

The effect was not limited to the feature that reported it. Every lookup that went through a configured custom DNS server failed — MX records for outbound delivery, DNSBL, SPF, SURBL — for as long as one was configured. It announced itself loudest through SpamAssassin, as HM5507 The IP address for SpamAssassin could not be resolved, which is how #25 was reported. Installations with no custom DNS server were never affected: the server list is only built when one is set.

Fixed, with the reasoning written into the source so it is not "corrected" back, and pinned by a regression test built as a negative control: it points DNSServer at TEST-NET-1 (192.0.2.1), which answers nothing, and requires the lookup to TIME OUT. A timeout is the proof that a packet actually left the machine - the broken build returned status 87 in the same millisecond, without sending anything - and the test fails naming that status if it ever comes back.

The directory as an account source

Until now an account could be linked to Active Directory but nothing could create one from it. Settings.PreviewDirectorySync and Settings.ApplyDirectorySync now read an LDAP directory and, on request, create and update the mailboxes it says should exist. There is a Control Panel page for it, and an optional unattended schedule.

The preview is the point. Planning and applying are one piece of code — the planner decides and writes nothing, the applier writes and decides nothing — so a preview cannot describe an action the apply would not take. The Apply button stays disabled until a preview of the same options has been run, and is re-checked after the confirmation dialog.

What it refuses to do is as important as what it does:

A domain takes part only if its Active Directory domain name is set. That makes provisioning opt-in per domain, so a search base pointed one level too high cannot provision into unrelated hosted domains. It also guarantees every created account carries a non-empty AD domain — which matters, because LogonUser with an empty domain validates against the local machine's own Windows accounts. Nothing is ever deleted. The most it does is clear Active, and only when asked. Not on a truncated enumeration, not on an empty one, and not for a domain in which nothing was seen — in each of those an account that still exists is indistinguishable from one that was removed. An account that is not directory-linked, or is linked to a different AD domain, is reported rather than taken over. Either would move who decides that mailbox's password.

The enumeration pages, because Active Directory caps a search at MaxPageSize and answers a larger directory with the first page and a success status. The service bind honours BindMethod, so Negotiate works where no LDAPS certificate exists — the unjoined-DMZ case the feature exists for. A multi-valued attribute is reduced deterministically, because LDAP guarantees no ordering and taking whichever value arrived first let a re-run pick a different address for the same person.

Verified end to end against a live Windows Server 2025 domain controller.

Sieve imap4flags now reaches the message

setflag, addflag, removeflag and the :flags tag were parsed, accepted by require, evaluated — and then discarded at delivery. A script that marked its own automated mail \Seen was accepted, ran, reported success, and changed nothing.

The flags are now applied to the stored message, and imap4flags has moved into the ManageSieve capability line. Only the five system flags can be stored (\Seen \Answered \Flagged \Deleted \Draft); a keyword is reported in the application log rather than dropped in silence.

Also fixed

GetUniqueMessageID could hand out the same UID twice, which makes a client show one message in place of another. A colon in an account address was accepted and could never work: the local part becomes a directory name in the message store, and Windows cannot create a directory containing one. Such an account saved, appeared in every list, accepted mail at RCPT TO, and failed when the message was filed. A session could outlive its io_context, and shutdown waited in the wrong place. A status card could announce failing backups on a healthy server, because an interval read from the INI was doubled as an integer and could overflow negative. A certificate handle leaked on every visit to the certificates page whenever a key file threw.

Administration

The settings that had no interface now have one, and the pages that showed what was configured now also show what is happening — including where a configuration looks enabled and is inert. The [Settings] INI values move into the database so they can be administered remotely, with the file still winning where both carry a value, so nothing changes for an installation that edits the INI by hand.

Upgrading

The database schema moves from 6005 to 6011. DBUpdater applies it; take a backup first, as always. Settings are preserved.

Known issues

#26 — partial FETCH BODY[]<offset.length> reported against 6.2.18 — does not reproduce here, and this release adds tests that walk a whole message in chunks over both FETCH and UID FETCH and compare the reassembly byte for byte, including the short final chunk. That is not the same as saying the reporter is wrong: the report is against a build this release is well ahead of, so "already fixed" and "never broken here" cannot be told apart without more detail. An IMAP protocol log showing the exact command sequence would settle it.

Validated by the full regression suite against this binary.

The database-unavailable fix

The most consequential change here is not a timeout. It is that a recipient lookup which fails because the database did not answer now returns 451 rather than 550.

The two cases were indistinguishable inside the server: a lookup that failed and a lookup that found nothing were reported identically. So a database briefly locked by a backup told the sending server that a perfectly valid mailbox did not exist, and the mail was bounced instead of retried. That is mail loss with a delivery receipt.

It is implemented as a thread-local marker set at the two points where the connection pool gives up, read at both RCPT TO decision points. One detail worth recording because it is easy to get wrong: the marker is set after the pool lock is released and before ReportError, because the error handler can re-enter the pool on the same thread and deadlock against it.

This is also what made it safe to turn the pool deadline on: DBConnectionAcquireTimeout now defaults to 60 seconds rather than 0. It shipped disabled in 6.2.17 precisely because timing out an acquisition turned a slow database into a bounce. It no longer does.

Bounded waits (#23, #24)

Every remaining wait that could occupy a thread from a shared pool now has a ceiling, and the log names which one was hit.

Outbound delivery sessions have an absolute ceiling (ClientSessionCeiling, 30 minutes) that is separate from the idle timeout. The idle timeout is re-armed on every byte received, so a peer dribbling one byte at a time held a delivery thread indefinitely — the idle timeout never fired because the peer was never idle. ClamAV on the delivery path (#23) is bounded and reports a timeout rather than holding the thread. DNS queries, event scripts and external scanner processes (#24) are bounded by DNSQueryTimeout (10s), ScriptTimeout (60s) and ExternalProcessTimeout (300s). Work queue saturation is reported on a schedule and names the task holding each thread, with its session and peer IP. Pre-authentication IMAP command buffering is capped at 11 MB. An unauthenticated peer could previously buffer without limit. Backup restore validates the source archive before deleting the target. It deleted first, so a corrupt archive destroyed the data it was restoring over.

Static analysis

First /analyze pass. The findings worth naming:

GetExecutableName and two MySQL path helpers allocated a byte count where a character count was needed — a buffer overrun on long paths. Logger::WriteLogFile shadowed fileExists, so rotation tested an uninitialised value and could corrupt the log it was rotating. Every read of the virus-scanner counter is now interlocked, and the compare-and-swap uses the value it compared against rather than a fresh non-atomic read.

Roadmap

Roadmap.md is rewritten after a comparison against Postfix + Dovecot, Stalwart, iRedMail, Mail-in-a-Box and Exchange Online.

It states plainly what this fork is ahead on, because a list of gaps misleads on its own: in-process MTA-STS (Postfix still has none native), DANE with in-process DNSSEC validation, ARC sealing, IMAP4rev2 advertised by default (Dovecot ships it compile-time experimental and off), SCRAM-SHA-256-PLUS with channel binding, and observability in the open tier that Stalwart charges for.

Then the gaps that actually cost users — full-text search, shared and delegated mailboxes, Sieve depth, per-account send limits, message trace — each with a note on what is already in the tree that a fix would reuse.

It adds a section on graphs and visual data, including three accessibility defects in the current Control Panel dashboard, and reasoned refusals for JMAP, CalDAV, webmail, active/active clustering, ActiveSync/EWS and mobile push — with the reason in each case rather than a bare no.

Also flagged as time-sensitive: hMailServer can only present a username and password when relaying out through, or collecting from, Microsoft 365. Basic auth for SMTP AUTH there is scheduled off by default at the end of December 2026, so OAuth 2.0 client support (XOAUTH2) is now dated work, not speculative.

Documentation

DiagnosingStalledMail.md gains the delivery half and the corrected DBConnectionAcquireTimeout default.

Verification

1049 regression tests pass against this exact binary, up from 1038. New coverage for recipient verification (4), IMAP sequence sets (12) and aborted transfers (2).

The delivery ceiling was verified against a deliberately hostile peer rig — the kind that dribbles bytes to defeat an idle timeout. That rig is what caught a bad_weak_ptr crash from calling shared_from_this() in a constructor; the timer is now armed from Start().

Still open

Discussion #18 — the root cause is found, fixed and bounded, and the tracking issue for it is closed, but it has not been confirmed against the original reporter's Postfix/PMG setup. That confirmation is the one thing still missing. If you are affected, the per-stage timings described in the troubleshooting guide will name the culprit in a single log line; please post it on the discussion.

Correction (12 Aug 2026)

A follow-up audit of the source tree found that ARC sealing is narrower than described above and in the roadmap. Arc::Seal has a single caller, sitting after every early return in DKIMSigner::Sign, so a message is sealed only when the sender's domain is hosted on this server and has DKIM enabled and signing succeeds. Relayed third-party mail — the case ARC exists for — is never sealed.

Until that is fixed this should not be presented as an advantage over verify-only implementations, and the roadmap now says so. The same audit turned up fifteen other defects, all listed there.

No database change (schema version 6005).

What was actually happening

Postfix's error means the message body and the terminating dot were fully transmitted, and it was waiting for hMailServer's 250 — which never came. So the stall was never in reception; it was in the accept/save work that runs after end-of-data and before the reply.

Two things combine to produce it

For a trusted incoming relay — exactly what a Proxmox/Postfix front end is — hMailServer defers its whole spam battery to after end-of-data. For a direct or authenticated sender those same tests run earlier, during MAIL FROM/RCPT TO, on the connection thread. That is why this only ever happened to relayed mail, and why it never reproduced on a simple test server. That work runs on a bounded pool (15 threads by default) and holds the thread that sends the 250. SpamAssassin's wait had no overall ceiling: the connection's idle timeout is re-armed on every byte received, so a scanner that stalls, or dribbles, holds the thread indefinitely.

Reproduced deliberately, against a SpamAssassin endpoint that accepts connections and never answers:

The fixes

SpamAssassin's wait is now bounded. It was an untimed wait released only by an idle timer that any trickle of data re-arms. It now has a hard ceiling (SAMaxTimeout + 30 s) after which the message is accepted without a SpamAssassin verdict — the same outcome as when spamd is simply down. This also required sharing the completion flag properly with the connection, since the old code held a reference to the waiting function's stack.

Message acceptance is bounded overall. A new FinalizationTimeout (default 240 s, comfortably inside Postfix's 600 s data-done timeout; 0 disables it) makes the server answer 451 4.3.1 and let the sender retry, rather than leaving it waiting for a reply that will not arrive. The check runs on the accepting thread itself and only before anything is saved, so it cannot duplicate mail — a watchdog replying from outside would race the 250 and deliver the message twice.

The silence is now instrumented. Acceptance is timed per stage, and each spam test is timed individually. A slow stage is reported at APPLICATION level rather than only under debug logging, so the log now says:

Spam test: SpamTestSpamAssassin, Score: 0, Time: 120031 ms SMTPConnection - accept: done spam-protection in 120047 ms (session 5).

Where previously there was nothing at all between 354 and the reply. If acceptance waited on a saturated queue, that is logged too, with the wait in milliseconds.

If you are affected, upgrading is enough to convert silent stalls into either a completed delivery or a clean 451 retry. If you want to know why your server is slow, enable debug logging and the per-stage timings will name the scanner, DNS lookup or event script responsible.

Known related issues, not fixed here

The audit that found this also found other unbounded waits on the same and adjacent paths, deliberately left for a follow-up rather than rushed into this release: synchronous DNS lookups in the spam tests have no application-level timeout, the database connection pool has no acquisition deadline, event scripts have no execution limit, and on the delivery side the ClamAV read/write timeout is currently ineffective. None of these is the reported fault, and each needs its own fix and its own test.

Also in this release

The README has been rewritten around what the server does and what it is built on. Per-version change history now lives here on the Releases page, where it belongs. The regression suite gains coverage for clients that vanish mid-operation (aborted DATA, truncated BDAT, IMAP APPEND literals cut short, POP3 disconnects during RETR) — the class of defect that produced the two blockers found during 6.2.15. A new installer smoke test installs each release on a clean throwaway machine and verifies the service registers, starts and listens, so the installer is no longer validated only by the fact that it compiles.