hMailServer Team group

Progressiverobot

Every message over 60,000 bytes sent to a server advertising CHUNKING has stalled since outbound BDAT arrived in 6.2.25. Every release from 6.2.25 to 6.3.2 is affected. If your smart host or the destination offers CHUNKING, large mail has been failing, and OutboundChunking=0 is the workaround on any of them. 6.3.3 fixes it (issue #261).

The SMTP client armed the read for the reply as soon as the BDAT command, or with PIPELINING the envelope, had been queued, and the chunk's second 60,000-byte buffer was queued behind that read in the operation queue, which starts only the operation at its head. The read could not complete while the remote waited for the bytes behind it, so nothing sent them, and the remote gave up on its own timeout. iCloud returned 421 after five minutes in the report. DATA never met it, because its body streams only after the 354. The queue now runs once more after a read has started. If you cannot upgrade yet, OutboundChunking=0 in hMailServer.ini is the workaround.

Before you upgrade

Two schema changes, both upgrade in place. Schema 6039 widens a domain's relay-password column: it held 255 characters and a DPAPI envelope is 314, so a relay password could not be saved on any Windows installation. Schema 6040 adds the CardDAV tables.

On PostgreSQL the escaper doubled backslashes unconditionally, which is correct only while standard_conforming_strings is off, and that has been on by default since PostgreSQL 9.1. DKIM key-file paths, signatures, vacation messages and rules were stored doubled. Values already stored that way stay as they are. Edit and save them once.

Also in this release

The four [Settings] ini routes over REST answered to any api key. A read-only key could read the OAuth2 HMAC secret, the password pepper and the service account password, and a write key could set AutoBanCommand, which the firewall reconciliation runs as the service. They take the administrator password only now. A domain-scoped key is refused the eleven administrator-only fields on PUT /api/v1/domains/{domain} with 403.
CardDAV (RFC 6352) for the account's address book, one book named Contacts, vCard 3.0 and 4.0, HTTP Basic over HTTPS only. The web services HTTPS listener has to be on (WebServicesHttpsPort).
The webmail is rebuilt: inbox tabs, mute, pinning as $Pinned, follow-up dates as $FollowUp and $Due-YYYY-MM-DD, fourteen more search operators, twenty languages.
The full-text indexer no longer reports an error for a message deleted before its terms were saved.

Full release notes, checksums and signatures

Progressiverobot

A SURBL lookup that failed was being read as a hit. The Spamhaus zones answer a query they refuse with a code in 127.255.255.0/24, and until now any answer at all counted as a listing. A server resolving through a public resolver such as 8.8.8.8, or sending too many queries, tagged every message carrying a link as spam (discussion #167).

What the upgrade involved

The database goes to schema 6038: steps 6032 to 6037 add contacts, account preferences, scheduled sends and snoozes, files sent as links, message keywords and S/MIME keys, and 6038 the SURBL expected result.

6.3.1 listed the 6029 to 6030 upgrade step as known and unfixed: on a database holding orphaned rows it could re-orphan rows it had already cleaned, then refuse its own foreign keys. It is fixed in all four backends.

Changes

Each SURBL server now has an expected result (SURBLServer.ExpectedResult, in the Control Panel's SURBL editor) in DNSBL syntax: 127.0.1.0-255, 127.0.0.2*, ranges and wildcards. With none set, any answer counts except the codes in 127.255.255.0/24. The debug log records what the zone answered and what was made of it.
The portal at /portal is now a mail client, over /api/v1/me and the account's own credentials. Conversations by thread, search operators (from:, subject:, has:attachment, is:unread, label:), labels stored as IMAP keywords so every IMAP client sees them, undo send for up to thirty seconds, send later and snooze held on the server, oversize attachments sent as expiring links from /files/{token}, read receipts (RFC 8098) and one-click unsubscribe (RFC 8058). S/MIME runs in the browser on the Web Crypto API, the private key wrapped under a key derived from the account password. Not in this release: 3DES content, EC key agreement for encryption, legacy PKCS#12 encryption, OpenPGP.
SASL GSSAPI (RFC 4752) on SMTP, IMAP and POP3, on Windows. Off unless GssapiEnabled=1 in [Settings].
Auto-ban can reach the firewall. AutoBanFirewall=1 writes an inbound block rule per banned address in Windows Defender Firewall, or keeps an nftables set on Linux. AutoBanCommand and AutoBanNeverBan go with it. All three are off as shipped.
Making an app password now takes the account's own password, and an app password is never accepted for it.
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.

Full release notes, checksums and signatures

Progressiverobot

Nothing in the server changes. The compiled server differs from 6.3.0 by its version stamp and one comment line. What changes is the installer: the Windows installer is now Authenticode-signed with Azure Artifact Signing, against a certificate profile issued to Progressive Robot Ltd. If you run with UpdateRequireAuthenticode=1, which has existed since 6.2.28, the server's own update path has been refusing every release of this project, because none carried a signature. From 6.3.1 the installer it downloads carries one.

What the upgrade involved

The orphan sweep in the 6029 to 6030 upgrade step runs children before parents. Before it adds seventeen foreign keys it deletes rows whose parent is gone, and three of those parent tables are pruned by the same deletes, 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, in all four database backends. No installation has reported hitting it, and when it fires it fails loudly with the engine's own words and rolls back. The fix is held for 6.3.2.

The rest

Only the Windows installer is signed. There is no Authenticode for a .deb, an .rpm or an AppImage. The elevation prompt now reads the publisher's name.
SmartScreen still warns. Microsoft flags a signed installer as unrecognised until reputation accumulates. An EV certificate would not help; Microsoft removed EV's SmartScreen bypass in 2024.
The UpdateRequireAuthenticode check is WinVerifyTrust on the downloaded installer, and it is Windows-only. On Linux the server says so rather than reporting a pass, and updating is the package manager's job.
The signing gate asked for four of the six settings it guards and never asked about ARTIFACT_SIGNING_ENDPOINT or ARTIFACT_SIGNING_PROFILE. Three outcomes now: none of the six set is a silent no-op, all six signs, anything in between stops and names what is missing.
6.3.0's tagged run attached no Linux packages because the package-install check ran without sudo against /etc/hmailserver, which the package makes 0750 root:hmailserver. It runs under sudo now.
Documentation: the README offers the Linux packages on its download line, and two files that named 6.2.29, a version that does not exist, now say 6.3.0.

Full suite on the stamped binary: 2,175 tests, 2,166 passed, 0 failed, 9 skipped.

Full release notes, checksums and signatures

Progressiverobot

hMailServer 6.3.0 runs on Linux. Every core translation unit compiles there, counted file by file by build/linux-tu-census.sh under clang on x86-64 and AArch64, with a separate job linking the core with GCC. The Windows build is the same MSVC project it was and behaves as it did.

What the upgrade involved

No schema change. The schema is 6031, as in 6.2.28, so the installer's database upgrade has nothing to do.
On Windows, run the installer over the existing installation. Nothing this release adds is on by default: the REST API needs RestApiPort, and a server upgraded without touching its settings behaves exactly as 6.2.28 did.
Per-domain DKIM cannot be configured on Linux. There is a read route and no write route, and a PUT answers 404. A domain that must sign its outbound mail with DKIM is not one to run on Linux today.

Packaging. A .deb and an .rpm for both architectures, a PKGBUILD for Arch, and an AppImage: a systemd unit running the server as its own user, the configuration under /etc/hmailserver, and --create-database, --upgrade-database and --set-admin-password. Proven against PostgreSQL 18 and MariaDB 11.8, and against a real slapd over StartTLS and LDAPS.

REST API. PUT /api/v1/settings and its anti-spam and logging groups write 108 settings, each through the same setter the Control Panel calls, applied only when every key in the request is accepted. Global rules, SMTP routes, aliases, accounts, certificates and listeners too, plus POST /api/v1/server/reinitialize, so a new listener takes effect without stopping the process.

Control Deck and /portal. The administration page no longer stores the administrator password: POST /api/v1/session exchanges it once for an HttpOnly, SameSite=Strict cookie that ends when that password changes. /portal is a webmail now, polling GET /api/v1/me/changes every six seconds.

Fixes. On Linux, IMAP's modified UTF-7 was broken in both directions, so non-ASCII folder names were not stored correctly, and CStdString stopped converting at the first byte above 127, cutting short IMAP SEARCH CHARSET UTF-8 and MAIL FROM under SMTPUTF8. A TLS key-exchange group list OpenSSL rejects is now reported once, not once per listener and per delivery: on the OpenSSL Debian and Ubuntu ship, hundreds of errors an hour. The Control Panel sign-in box no longer translates the administrator user name, which made a fresh installation in Chinese, German or Swedish refuse the credential it had just asked for. (#156, #177)

Full release notes, checksums and signatures

Progressiverobot

6.2.28 is the first release that can update itself. A scheduled task reads this project's release feed and the Status page reports what it found; fetching an installer and applying it are two further, equally opt-in steps. The upgrade to 6.2.28 itself is manual.

What the upgrade involved

No schema change: 6031, as 6.2.27. The installer's database upgrade 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. A server upgraded without touching its settings behaves exactly as 6.2.27 did.

Known and unfixed: the Control Deck reads but does not write, and holds the administrator password in sessionStorage while it is open. The regression suite runs on Windows only.

What is in it

Updates. UpdateCheckEnabled=0 is the default and nothing happens until it is set: no request, no identifier, no counts. Turned on, the feed is read every UpdateCheckHours (24 by default). An installer is verified against its Sigstore bundle before it runs: the certificate chains to Fulcio, the identity and issuer are this project's release workflow, and the entry is in the public transparency log. These releases are not Authenticode-signed, so UpdateRequireAuthenticode=1 refuses every one of them, and the Sigstore check cannot be turned off. hMailServer.Updater.exe stops the service, waits UpdateServiceWaitSeconds (180) for it to come back, and reinstalls the previous version if it does not.
Webmail. /portal on the REST listener, with /api/v1/me behind it. It answers to the account's own credentials only: no administrator password, no API key. Read, send, search, attachments, the account's own quarantine, Sieve script and password change.
A real HTTP server. The REST API and web services move off a single-threaded HTTP/1.0 loop onto HttpServer: HTTP/1.1 on Boost.Asio with keep-alive, chunked bodies, and header and body deadlines.
IMAP COMPRESS=DEFLATE (RFC 4978). Advertised until compression is on and refused afterwards, as the RFC requires. STARTTLS is refused once a session is compressed.
HttpProxy=host:port sends every web request the server makes as a client through a forward proxy. CONNECT for https, with the same certificate verification as a direct connection. No proxy credentials.
Fixed (#156). A masked password in the Control Panel was typed backwards from the second character: 12345678 became 18765432. It hit IME commits and some keyboard layouts.

Full release notes, checksums and signatures

Progressiverobot

The DNSSEC validator that guards DANE and the SPF, DKIM and DMARC lookups treated a DS query answered with nothing as an unsigned delegation. That is exactly what an attacker stripping the DS in transit shows a resolver: a signed zone quietly became unsigned, and DANE and validated TXT went with it. Anyone relying on DANE or on DNSSEC-validated SPF, DKIM or DMARC was affected.

What the upgrade involved

Schema 6030 to 6031: one column on hm_fetchaccounts, added by the installer's database upgrade on every backend. From 6.2.25 or 6.2.26, run the installer. From earlier, read the 6.2.25 and 6.2.24 notes first.

Security

A missing DS is now proved missing (RFC 4035 §5.2, RFC 5155 §8). The resolver 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 now Bogus and blocked rather than Insecure. An unsigned parent, or a resolver that cannot be reached, still yields Insecure. The chain result is exposed as Diagnostics.DnssecChainStatus.

Mail flow

FetchAccount.MirrorFolders (schema 6031; "Mirror every folder" on an IMAP external account in the Control Panel) collects each remote mailbox into the local folder of the same name: every message byte for byte, with its \Seen \Flagged \Answered \Draft \Deleted flags, its internal date, and the remote hierarchy delimiter mapped to the local one. Nothing is delivered, so no rule, anti-spam or anti-virus touches a copy. Each folder records what it has collected, so a second poll takes only what is new. Days to keep messages 0 makes it a move.
The Import Tool reads a Maildir: the INBOX and every Maildir++ folder beside it, with the flags the file names carry (;2, and !2, as well as :2,) and line endings made CRLF.
An import into a folder a client has open now refreshes it, as a delivery does.
Migration.md documents each route in and what it keeps: IMAP, mbox, Maildir, Outlook through IMAP (PST is deliberately not parsed), and bulk accounts.

Full release notes, checksums and signatures

Progressiverobot

If you run hMailServer on SQL Server Compact, the 6.2.25 installer told you the database could not be upgraded. It had been upgraded. Every Compact Edition upgrade through schema 6030 was reported as failed after it had succeeded (#114), and two seconds later the service ended and service recovery started it again.

What the upgrade involved

If the 6.2.25 installer failed on your database, that database 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 attempt, the whole chain runs and the verification passes. From 6.2.24 or earlier, the 6.2.25 notes and the 6.2.24 notes before them describe what changes on the way, and everything there still applies.

What was wrong

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, used case when exists (subquery) in the SET expression. That is valid on SQL Server, MySQL and PostgreSQL. On SQL Server Compact it is an access violation inside the OLE DB provider, on a correct database with every constraint present. The server reported 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.

The fix

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.

This was 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. build/check-db-scripts.ps1 now runs every probe 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. Both fail on the 6.2.25 statement.

Full release notes, checksums and signatures

Progressiverobot

ACME issuance and renewal ended the hMailServer process (#93). Anyone running automatic certificates on 6.2.24 lost the service on every issuance and every renewal.

Two calls in the ACME client handed the OpenSSL DLL a FILE* opened by the server's own C runtime: the DANE TLSA line logged straight after issuance, and the re-read of the existing private key at the start of every renewal (the default, AcmeReuseKey). With no OPENSSL_Applink export in the executable, OpenSSL does not return an error. It writes OPENSSL_Uplink(...): no OPENSSL_Applink to the Windows Application log under the source "OpenSSL" and calls TerminateProcess. The symptoms: an OpenSSL event whose message looks blank, a 7031 from the service control manager in the same second, no crash dump, and no "ACME (automatic)" certificate record. Both calls now go through OpenSSL's own file I/O, and the deployment runs before the TLSA line.

If 6.2.24 issued you a certificate before it died, the files under Data\ACME are valid. 6.2.25 deploys them at its first ACME check after start-up and logs "issued but never deployed".

What the upgrade involved

The schema moves from 6025 to 6030 in five steps, one way. DBUpdater runs them in order and resumes from a partial upgrade; there is no downgrade. The 6029 to 6030 step adds seventeen FOREIGN KEY constraints with ON DELETE CASCADE and removes the orphan rows they would refuse. On a large database it reads every child table once, so plan for it like an index build.

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.

Behaviour that changes without a switch

The Apple .mobileconfig profile is served over HTTPS only. Plain HTTP gets a 301 to the WebServicesHttpsPort listener, or a 403 when none is configured. A TLS-terminating proxy must send X-Forwarded-Proto: https.
A Message-ID is added only to submissions (upstream #552). Relayed mail keeps its headers, so a filter counting on the header will now see messages without one.
IMAP sequence numbers are stable within a session (upstream #602). Another session's expunge no longer renumbers a client's messages under it.

Also fixed: two restarts at once, one over COM and one from an ACME deployment or backup restore, rebuilt the same queues under each other and could end in an access violation. Restarts now run in sequence.

Full release notes, checksums and signatures

Progressiverobot

6.2.24 is the stable release of the work carried by the 6.2.22 pre-releases and the 6.2.23 alphas. If you are on 6.2.21, all of it arrives at once.

The headline is mail that was being lost silently. A delegated IMAP APPEND, COPY or MOVE filed the bytes under the wrong account, and a delegated MOVE destroyed the only readable copy. Anyone using shared or delegated mailboxes was exposed. Thunderbird also had every Sent copy refused once UTF8=ACCEPT was enabled (#53).

What the upgrade involved

The schema moves from 6011 to 6025 in fourteen one-way steps. 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. Take a database backup and a data-directory backup with your backend's own tools first.

Step 6024 to 6025 rewrites hm_messages.messageflags from tinyint to smallint on MS SQL, SQL Server Compact and MySQL/MariaDB. That is a table rewrite on the largest table you have, holding locks for its duration, so size the maintenance window by your message count. PostgreSQL is already smallint and unaffected.

Changes that take effect without a switch

MAIL FROM or AUTH straight after the STARTTLS handshake, with no second EHLO, now gets 503 Bad sequence of commands. RFC 3207 has always required that EHLO. A home-grown submission script will find out here.
For mail arriving through a relay or fetched from an external account, the DNSBL, SPF and HELO tests now run against the address the relay observed, not the first bracketed value in the Received header, which the sender could set. If you tuned scores around the old behaviour, expect verdicts to move.
Mail is refused with a temporary error when free space falls below 100 MB (MinimumFreeDiskSpaceMB, Server settings). Set it to 0 for the old behaviour.
Per-account out-of-office now honours the RFC 3834 suppressions that previously applied only to the domain-wide reply.
Early-bound COM clients built against a 6.2.22 pre-release interop assembly must be recompiled. Anything built against 6.2.21, and all late-bound scripts, are unaffected.

Two further anti-spam bypasses are closed. A forged header could steer a per-account spam override into un-marking the sender's own mail. RSET before EHLO, or STARTTLS without a fresh EHLO, opened a transaction with an empty HELO host, skipping the HELO-host test and the script events.

Full release notes, checksums and signatures

Progressiverobot

This was an alpha. Everything in it shipped in 6.2.24. Nothing here should be installed today.

Thunderbird 128 and later could not save a single Sent copy. Every message went out over SMTP and nothing was ever stored, with only a per-machine client setting as a workaround (#53). Two ways a sender could steer the anti-spam tests are also closed here.

What the upgrade involved

This is an alpha because one of the fixes changes what a non-conforming client sees.

Relayed and fetched mail is now tested against a different address. The Received parser takes the last observed address before by, ignores values marked as HELO-supplied, and keeps a header whose host name is not a valid domain name. If you sit behind an incoming relay and have tuned scores around the old behaviour, expect verdicts to move.
MAIL FROM straight after a STARTTLS handshake with no fresh EHLO now gets 503 Bad sequence of commands, as RFC 3207 section 4.2 requires. If you have a home-grown submission script that skips the second EHLO, this is the release that tells you.

Changes

IMAP APPEND: once a client enables UTF8=ACCEPT, RFC 6855 lets it wrap the message as UTF8 (~{n} plus a closing ). The parser counted parentheses across the whole line and refused with BAD APPEND Command requires at least 2 parameter before reading a byte. The wrapper is now stripped ahead of the parser, including the non-synchronizing ~{n+} form and later messages of a MULTIAPPEND.
Anti-spam bypass: the parser took the first bracketed value after from, which is the HELO literal the client chose, and skipped any header whose host name was not a valid domain (my_pc). DNSBL, SPF and the HELO-host test could be skipped entirely. Two assert(0) on sender-reachable input are gone with it.
RSET before EHLO no longer opens a transaction on its own. That had let MAIL FROM through with an empty HELO host, skipping the OnHELO/OnEHLO events.
A PTR answer carrying the trailing dot (1.0.0.127.in-addr.arpa.) no longer empties the result. That had been failing open in the HELO and reverse-DNS spam tests.
hMailServer.exe is built with /guard:cf in both configurations (#45).
An unattended install whose database step fails now fails, rather than showing a suppressible message box and exiting 0.

Known limitation: the weekly C++ CodeQL analysis has not run since late August. It targets a self-hosted runner that is no longer registered.

Full release notes, checksums and signatures

hMailServer Team

Posts

Member List