Written for 6.3.4. hMailServer 6.3.7 (17 October 2026) adds reasons a message stays where it is. A forward, a redirect or a rule's forward of mail from outside whose From names the forwarding domain's own organisation, and that did not pass DMARC for it when it arrived, keeps the envelope sender it came with, with no SRS address or rewritten sender; where the copy would still carry an identity of that organisation (an empty envelope sender under this server's host name, or an envelope sender at this server's host name or at a hosted domain in that organisation) it is not sent to an outside address at all: the message stays in the mailbox, and the application log names each recipient. RuleLoopLimit 0 now stops out-of-office replies, as it stopped every other generated message. A delivery whose mail servers' DNS lookup failed tells the sender that the DNS query failed (4.4.4) and retries, where a failed lookup was read as a name with no addresses. On MySQL and MariaDB a lost database connection is reconnected and the statement run again, and an error log that was quiet may now name database failures that were hidden (HM5032). See the 6.3.7 announcement. This topic covers the case where mail is not moving and the server looks healthy: no crash, no error, the service running, and a log that seems to stop mid-transaction. The server used to be silent about it; it is no longer, and the answer is usually in one line of the log. The one thing to establish first is which half is stuck: the server accepting a message from a sender, or delivering one it has already accepted. The two fail differently, for different causes, under different settings. Which half is stuck? Accepting. The sending server connects, sends the message, and then waits. From its side there is a timeout after the message body was transmitted; Postfix reports it as timed out while sending end of data. The message never appears in your queue. Delivering. The message was accepted (the sender got a 250), is visible in the delivery queue, and never leaves. Monitoring & troubleshooting → Delivery queue in the Control Panel tells the two apart in one look, and so does hmailserver_delivery_queue_messages on the metrics endpoint once it has a port (see Commands). The Control Panel is Windows-only; on Linux the queue is GET /api/v1/queue, hmctl queue list (since 6.3.4) and the Control Deck's queue page. Turn on debug logging first Control Panel → Logging → tick Debug messages, and make sure logging is enabled; then reproduce the problem once. The stage lines below are written at debug level. The slow ones (ten seconds or more, for a whole stage or for any single spam test) are also written at application level, so a server with only application logging still records the important half. Turn debug logging off again afterwards on a busy server. Reading the logs covers where the logging keys live on each platform. Accepting: the sender times out after sending the message Between the 354 and the 250 the server runs the accept pipeline: spam tests, message modifications, archiving, the OnAcceptMessage script and the database save. All of it runs on a bounded pool of threads, and the reply is sent only when it finishes. The log times each stage: SMTPConnection - accept: start spam-protection. Spam test: SpamTestDNSBlackLists, Score: 0, Time: 12 ms Spam test: SpamTestSpamAssassin, Score: 0, Time: 120000 ms SMTPConnection - accept: done spam-protection in 120047 ms (session 5). SMTPConnection - accept: done message-modifications in 0 ms (session 5). SMTPConnection - accept: start script/save. SMTPConnection - accept: done script/save in 3 ms (session 5). How to read it. Read it as a sequence and look for the last line written; the stage that is stuck is the one after it. Two stages announce themselves with a start line (spam-protection and script/save), so for those a start with no matching done is the whole diagnosis. The middle stage, message modifications, has no start line, so a stall there shows as done spam-protection followed by silence. If every stage completes but one took a long time, the Time: or done ... in value names the culprit. What the log shows Cause SpamTestSpamAssassin with a large Time: spamd is unreachable, overloaded, or accepting connections without answering SpamTestDNSBlackLists, SpamTestSURBL or SpamTestSPF slow The resolver is not answering. Look in the TCP/IP log for DNS - Query timed out and DNS - Query failure. Do not reach for DNSServer as the fix (below) done spam-protection, then silence Message modifications: the spam headers, the signature, the List-* headers, or the write of the modified message back to disk script/save slow An OnAcceptMessage event script, or the database Nothing between 354 and silence A version older than 6.2.17, which added these lines. Upgrade The DNSServer setting. It was broken in 6.2.17 and 6.2.18 (CHANGELOG's 6.2.19 section names 6.2.16 as well) and fixed in 6.2.19: on the affected versions every lookup through a configured custom server failed, and DNSBL, SURBL, SPF, DKIM and MX lookups failed in silence, so such a server had quietly stopped most of its spam filtering while still accepting mail. One caveat survives the fix: a custom server list is only honoured together with DNS_QUERY_BYPASS_CACHE, so every lookup pays full price. Leave DNSServer empty unless you need a specific resolver. SPF, and SPF on Linux. In 6.3.3 and earlier the SPF evaluator resolved names through the Windows DNS client rather than through the server's resolver. On Windows an SPF check therefore went to the system resolvers whatever DNSServer said; on Linux every SPF check returned a temporary error, reported once per process as HM6406, and because SpamTestDMARC evaluates SPF, DMARC there lost its SPF half. The RFC 7208 evaluator that replaced it in 6.3.4 resolves through the same resolver as every other lookup. If you run 6.3.3 or earlier on Linux, an SPF or DMARC verdict from it is not a verdict. The deadline. Since 6.2.17 acceptance is bounded: if the pipeline exceeds FinalizationTimeout (240 seconds by default) the server answers 451 4.3.1 Server temporarily overloaded while accepting the message; please retry. and the sender retries rather than waiting for a reply that never comes. The accompanying error entry names the deadline that was hit, and the stage timings above it name what consumed the time. If every message stalls, not just one Look for these two lines: Task SMTP-accept session=42 ip=203.0.113.9 waited 8 seconds for a thread in work queue Asynchronous task queue. 14 task(s) are still queued. All 15 threads in work queue Asynchronous task queue have been busy for at least 120 seconds, so no further task on this queue can start. 14 task(s) are queued. Running: SMTP-accept session=42 ip=203.0.113.9 (thread 4120, 168s), ... Every worker is occupied, and one slow dependency does this to the whole server. The task names say which sessions are stuck; the stage timings say what they are stuck on. AsyncQueueStallThreshold (120 seconds by default) is how long every worker may be busy before the second report is written; 0 turns the report off. Delivering: how the queue works There is no in-memory queue to inspect. The delivery queue is the set of rows in hm_messages whose type is delivering, and the delivery manager is a loop that polls for them. Three properties of that loop explain most of what a stuck queue looks like: The selection is where messagetype = 1 and messagelocked = 0 and messagenexttrytime <= now, ordered by size, then try count, then id. Small and new goes first. The delivery pool is separate and smaller than the accept pool: maxdelivertythreads, 10 by default, on the work queue named SMTP delivery queue. It is not the Asynchronous task queue that finalises inbound mail, so a saturated delivery pool does not stop mail being accepted; it stops it leaving. The manager wakes on demand, or once a minute otherwise. A message whose next-try time has just passed is picked up within a minute, not instantly. At startup every message in the queue is unlocked (update hm_messages set messagelocked = 0), because locks held by a server that crashed would otherwise strand those messages for ever. That is also why exactly one hMailServer service may run against one database. The retry schedule, and when a message gives up Setting Where Default Effect Number of retries Mail flow & delivery → Delivery of e-mail (smtpnoofretries) 4 How many further attempts after the first Minutes between every retry The same page (smtpminutesbetweenretries) 60 The gap between them QuickRetries [Settings] 0 (off) The first N retries use the short gap below instead, for greylisting QuickRetriesMinutes [Settings] 6 That short gap QueueRandomnessMinutes [Settings] 0 (off) Adds a random 1..N minutes to every gap, so a burst does not retry in lockstep Route number of tries and minutes between tries Mail flow & delivery → Routes — Overrides both, per matching route; where several routes match, the largest of each wins With the shipped defaults that is five attempts an hour apart: a destination that is refusing temporarily holds a message for roughly four hours and then bounces it. The try count in the queue is the same messagecurnooftries the arithmetic uses. Two things do not advance that counter: Deliver now resets the next-try time without touching the count, and a message held because the virus scanner could not examine it is held on its own budget (below). Reading a stuck queue What the queue looks like What it means Where to look next Depth climbing, oldest message seconds old A busy server draining normally. Not a fault — Depth flat, oldest message hours old, try counts climbing The far end is deferring you The SMTP log for that destination; your IP's reputation and PTR Every stuck message shares one recipient domain That destination, not your server The route settings for it, and its MX Try counts stuck at 0, next-try times in the past, nothing moving Delivery threads are not running the tasks hmailserver_workqueue_depth{queue="SMTP delivery queue"}, and the saturation report above Messages appear and vanish without arriving Delivered to the wrong place, or discarded by a rule Mail flow & delivery → Rules; enable MessageTraceEnabled and read the trace Try count 1 and a next-try time of 1901-01-01 An ETRN hold: the one route these recipients match is an ETRN route Mail flow & delivery → Routes; the log line is SMTPDeliverer - Route Message: HOLD for later delivery.. Queue empty, but the sender got a 250 and nobody received it Delivered locally into a folder you are not looking at, or the row was removed The account's folders; the message trace Message N could not be delivered since the data file does not exist The row and the store disagree: a restore that missed files, or a store on a share that vanished Turn on MessageStoreConsistencyCheck and read the report When the virus scanner cannot examine a message. With AVFailAction=1 such a message is not delivered. It is held on its own schedule rather than on the SMTP retry budget: AVFailRetryMinutes apart (15 by default), at most AVFailMaxHolds times (16), and then returned to the sender. The log says where in that budget each hold is (... this was hold 3 of 16 before it is returned to the sender.). Each hold counts as a deferral in hmailserver_messages_deferred_total, so a scanner that has stopped answering shows as a deferral rate with no matching delivery rate. The usual causes of a genuinely stuck delivery A virus scanner that stops responding. ClamAV is contacted after the message is accepted, so a wedged clamd shows up as accepted but never delivered. Each socket operation is bounded by ClamMinTimeout / ClamMaxTimeout, but that is a deadline on one read or write, armed fresh each time, and the message is streamed in chunks, so one large message can take considerably longer than ClamMaxTimeout in total. A remote server that answers extremely slowly. The idle timeout is re-armed on every byte received, so a host that sends one byte occasionally used to hold a delivery thread indefinitely. Since 6.2.18 there is an absolute ceiling, ClientSessionCeiling (30 minutes by default), armed once and never re-armed. A custom virus scanner or external tool that hangs, bounded by ExternalProcessTimeout. A message held for a sandbox's verdict (since 6.3.4). With SandboxEnabled on, a message none of your own signed-in users submitted, whose attachment is of a submitted type, waits for the sandbox you named to open the file, up to SandboxTimeoutMinutes (15 by default). While it waits it is in no mailbox, not in the quarantine and not the queue's to retry: its Retry and Delete answer 409. It is listed by GET /api/v1/sandbox/held, by GET /api/v1/queue marked held: sandbox (the held column of hmctl queue list), and in the Deck's queue page under Held for a sandbox, where it can be delivered without the verdict or discarded. The database. Check for errors mentioning the connection pool. Since 6.3.4 a message can also wait in other places, each on purpose: held for review by compromised-account detection in enforce (/api/v1/review); in a destination's back-off window, with the last error Delivery deferred by this server's own shaping, not by a remote server. (GET /api/v1/queue/shaping; such a deferral does not spend the message's retries); under an IP warm-up ceiling; or behind a drain, when /readyz says draining. Section 19.11a of the Troubleshooting page lists each with what to do. Settings that bound each stage All are in seconds. On 6.3.3 and earlier they are [Settings] keys in hMailServer.ini. Since 6.3.4 they are stored in the database and changed in the Control Panel, over the REST API at /api/v1/settings/ini/<name> or with hmctl, and the save applies them. They still appear in the file's [Settings] section, but the database's value is the one used: where the service can write the file, an edit made there is reported (HM5804) and put back at the next start. Setting Default Bounds 0 means FinalizationTimeout 240 The whole accept pipeline, after which the sender gets a 451 no bound SAMaxTimeout 90 SpamAssassin: idle timeout, and a session ceiling of this plus 30s not "no bound" ClamMaxTimeout 90 ClamAV: idle timeout per socket operation not "no bound" DNSQueryTimeout 10 A single DNS query no bound ScriptTimeout 60 One event script invocation no bound ExternalProcessTimeout 300 An external scanner process no bound ClientSessionCeiling 1800 An entire outbound delivery session no bound AsyncQueueStallThreshold 120 How long every worker may be busy before the saturation report reporting off DBConnectionAcquireTimeout 60 Waiting for a pooled database connection no bound The two exceptions matter, because 0 tightens them instead of removing them. SAMaxTimeout and ClamMaxTimeout are not passed straight through: they go to a calculator that returns the minimum whenever the maximum is lower than it. So SAMaxTimeout=0 gives a 30-second idle timeout (SAMinTimeout) and a 30-second session ceiling, and ClamMaxTimeout=0 gives 15 seconds (ClamMinTimeout). To lengthen either, raise the value; to lengthen it a long way, raise the matching ...MinTimeout too. There is no way to make either unbounded. When the pool deadline expires, a recipient lookup answers 451 4.3.2 rather than 550: the server can tell "the database did not answer" from "no such address", so a database locked by a backup defers the mail instead of bouncing it. Commands The COM examples below are Windows-only. The metrics endpoint and the REST routes work on both platforms. Is it accepting, or is it delivering? The metrics listener is off until MetricsServerPort is set (9100 here; since 6.3.4 the port, the bind address and the listener's other settings, its credentials included, wait for a reinitialise). Once it is on, the endpoint needs no credential on a loopback bind: (Invoke-RestMethod http://127.0.0.1:9100/metrics) -split "`n" | Select-String '^hmailserver_delivery_queue_(messages|oldest_message_age_seconds) |^hmailserver_workqueue_depth|^hmailserver_messages_(delivered|deferred|bounced)_total ' A rising oldest_message_age_seconds with a flat delivered_total is the delivering half. A rising hmailserver_workqueue_depth{queue="Asynchronous task queue"} is the accepting half. The COM examples start from a signed-in $app: $app = New-Object -ComObject hMailServer.Application $app.Authenticate("Administrator", "<password>") | Out-Null Push one message to the front of the queue (resets its next-try time, leaves the try count alone, and releases an ETRN hold): $q = $app.GlobalObjects.DeliveryQueue $q.ResetDeliveryTime(4711) $q.StartDelivery() Wake the delivery manager without touching any message: $app.GlobalObjects.DeliveryQueue.StartDelivery() Remove one message from the queue (it is locked first, so a message a thread already has is not pulled from under it): $app.GlobalObjects.DeliveryQueue.Remove(4711) Follow the log while you reproduce it by tailing the day's file and filtering on accept: |Spam test:|waited .* for a thread|have been busy|SMTPDeliverer; Reading the logs has the tail command for each platform. Turn the message trace on (MessageTraceEnabled, off by default) to see what was done with one message. It has no acceptance, spam or virus event, so an empty trace does not show that the server never had the message; Troubleshooting by symptom says how to turn it on and what a row says. What to include in a report If none of the above identifies it, post in General support or open an issue with: the log from the 354 (or from the delivery attempt) onwards, including the stage timing lines; the ERROR_hmailserver_<date>.log for the same window; which scanners and event scripts are enabled; and whether the message eventually arrives, arrives twice, or never arrives. Say which half you have. Read this before you post covers the rest. Without a GitLab account, email the report to the project's Service Desk address, contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue; the maintainers answer by email. Where to read more Wiki: Diagnosing Stalled Mail and Troubleshooting, sections 19.7 and 19.11a. Repository: DiagnosingStalledMail.md; SettingsApply.md; Sandbox.md; SUPPORT.md. The public documentation: The delivery queue and the retry schedule and Troubleshooting. On this forum: Being trusted by the servers you send to, for when the far end is deferring you; Outbound shaping and IP warm-up, for when your own server is holding mail back; Monitoring and health, for turning the metrics listener on.

A password could run code inside the server (CVE-2026-100741, assigned through GitLab's CNA; the CVE record was not yet published when this was posted). On Windows, with event scripting switched on, the script language set to JScript and an OnClientValidatePassword handler in EventHandlers.js, any client that could reach a sign-in - SMTP AUTH, POP3, IMAP or anything else that checks an account's password - and name an existing, active account could have JScript of its own run inside hMailServer.exe, with the rights of the service's account, before it had authenticated. Before 6.2.25 that script could create any COM object, and from 6.2.25 it could with ScriptAllowedObjects at its shipped *, WScript.Shell among them, and so run any command the service's account may run. 6.3.4 fixes it. The flaw is in every release from 6.0.0 to 6.3.3: the escaping was checked at every one of those tags (GitLab issue 27). Treat any server older than 6.3.4 with event scripting on and JScript as its language as affected. Who is affected Only a Windows server whose administrator switched event scripting on. Scripting is off as shipped, the shipped language is VBScript, and no EventHandlers.js is installed. Through a password, a server whose script language is JScript and whose EventHandlers.js has an OnClientValidatePassword handler. The same flaw was open to a remote POP3 server through the UID it answers, on a JScript server with an OnExternalAccountDownload handler, and to a remote mail server through the error text it refuses a delivery with and the failed recipient's address, on a JScript server with an OnDeliveryFailed handler. A rule's Run function action wrote its function name into the call unescaped, in either language, so VBScript servers too. On a server with scripting on, whoever may edit a rule, a domain's own administrator included, could run code in the server's process. VBScript servers were not open through a password, a UID or an error text. The Linux builds before 6.3.4 had no script engine. The server built each handler call as source text and escaped the apostrophe but not the backslash before it. Every JScript value is now escaped in one helper, and a rule's function name must be a plain identifier: ASCII letters, digits, _ and $, not starting with a digit. On Windows any other name is refused as HM5018 each time the rule fires; on Linux, whose JavaScript engine looks a handler up by name instead of building a call, such a name finds no function and nothing is run (EventScripts.md). Until you can upgrade, switch event scripting off. A server that cannot do without its scripts should take the OnClientValidatePassword, OnExternalAccountDownload and OnDeliveryFailed handlers out of a JScript EventHandlers.js and reload the scripts, and, in either language, let nobody but the server administrator make or edit a rule with a Run function action. Before you upgrade Install 6.3.4 by hand, on every server. The Windows installer is Authenticode-signed by Progressive Robot Ltd through Azure Artifact Signing, but the release carries no Sigstore bundle, so a server's live update, of any version, that is offered 6.3.4 says it cannot be verified and downloads nothing. On Windows run hMailServer-6.3.4-x64.exe over the existing installation; on Linux install the .deb with apt on Ubuntu 26.04 or 24.04, or the .rpm with dnf on Fedora 43 or 44 or Enterprise Linux 10. The .deb needs glibc 2.38 or later, so it does not install on Debian 12, and the .rpm does not install on Enterprise Linux 9. A silent upgrade of a server with an administrator password needs it, as before: /adminpassword=<password>, or, new in 6.3.4, the environment variable HM_ADMIN_PASSWORD, set in an elevated prompt, because it does not cross the UAC prompt. A password with a double quote goes in the variable: Inno Setup drops every double quote from its command line. The installer now hands the password to the database tools in that variable too. It used to put it on their command lines unquoted, so a password with a space, a double quote or backslashes before one failed the database step with exit code 3. Back up the database and the data directory first. The schema goes from 6040 to 6104 in 64 one-way steps. On MySQL and MariaDB, step 6102 converts every table to utf8mb4 and rebuilds each one, which takes time on a large database. It needs MySQL 5.7.9 or MariaDB 10.2.2 or later - on an older server the upgrade stops at step 6041 with error 1071 and changes nothing - and the ALTER privilege on the database. Two rows the new collation no longer tells apart stop it with error 1062 until one of them is removed; a step stopped part of the way is finished by running it again. Step 6101 adds two columns to hm_messages, which has a row for every stored message, and on a large store is not instant on every backend. The database becomes the settings store. At the first start the [Settings] section of hMailServer.ini is taken into the database. A line edited after the old server last started, including one edited to prepare the upgrade, is put back, so make such a change after upgrading. From then on a line edited in the file is ignored and put back (HM5804 change settings in the Control Panel, over COM or REST, or on Linux with hmailserver --set-setting NAME=VALUE. A server from 6.2.28 to 6.3.3 still looks for updates at GitHub, which has answered 404 since 18 September 2026. For as long as it stays on that version, add this under [Settings] in its hMailServer.ini and restart the service, and its update check works again: UpdateFeedUrl=https://updates.progressiverobot.com/releases.json Keep UpdateAutoDownload off on such a server until it has been upgraded by hand. Once 6.3.4 is installed the server reads https://updates.progressiverobot.com without being told (the stable channel at /releases/latest), and the line can then be cleared in the Control Panel or over REST, not in the file. Linux packages for 6.3.4 are x86-64 only: a .deb and an .rpm. The AArch64 packages and the AppImages were last published with 6.3.3. Windows on ARM compiles but has never run, and there is no ARM64 installer. What changes on upgrade without a switch The 6.3.4 section of CHANGELOG.md lists 24 such changes. These are the ones most servers meet. SPF follows RFC 7208: mail from 127.0.0.0/8 and ::1 no longer passes unconditionally. The audit trail and the alerts are on, though nothing is mailed until AlertRecipient and AlertSenderAddress are set. Compromised-account detection runs in watch mode and holds nothing. A destination that answers 421 or a rate-limit code is paused, for 2 minutes at first and up to an hour (OutboundBackoffMinutes, OutboundBackoffMaxMinutes). MySQL and MariaDB connections use TLS whenever the database server offers it, without checking the certificate, and connect without it when it offers none. SQL Server sessions through MSOLEDBSQL 18 or SQL Native Client are encrypted whole, and tried once more without encryption when the failure reads as TLS unless TlsMode is require or verify-full; through SQLOLEDB, which the server uses where MSOLEDBSQL 18 or later is not installed and no failover partner is set, only the login is encrypted unless [Database] TlsMode is require or verify-full. verify-full checks the certificate. PostgreSQL is unchanged. The application log says at every start what the connection got (DatabaseTls.md). The administrator password is hashed again as PBKDF2 at the first administrator sign-in, and a browser session made under the old hash ends once. Where the service cannot write hMailServer.ini (the Linux packages, or a Windows service moved to NT SERVICE\hMailServer), the old value stays, HM7494 is logged once, and you set the password again with --set-admin-password. The Windows installer now writes it as PBKDF2 itself. A password hash stored before 6.3.4 of a password with a character above U+00FF is refused, and the application log names the account: that hash was made of NUL bytes on Windows or question marks on Linux, and any other password of that form opened it. Set such a password again, and soon: until then a SCRAM-SHA-256 client that derives its key from those NUL bytes or question marks still opens the PBKDF2 hash, and on Linux the password with ? in place of each such character still opens the account. ASCII and Latin-1 passwords sign in as before. A one-time code is taken once. A script that sent the administrator's password and a code with every REST request should sign in once (POST /api/v1/session) or use an API key; otherwise only its first request in each half minute is accepted. The outbound relay sends its OAuth2 token over TLS only. A route or the SMTP relay whose host is on OutboundOAuth2Hosts and whose connection security is none, or STARTTLS optional against a server that does not offer it, now sends nothing: the delivery fails with a temporary 450 4.7.0 and waits for its retries, and HM5912 says to set the security to TLS or STARTTLS required. A domain can no longer be named as a directory the server keeps its own files in, such as protected, quarantine or files. One that already is can still be saved, and is named as HM7597 at every start and on the setup checklist: rename it before you rely on a backup of it. A COM change to a route, relay, DNS black list, SURBL server, remote-domain policy, server message, blocked attachment, SSL certificate or group takes effect only at Save(). Scripts that relied on the old way must save. IMAP answers as the RFCs say where Dovecot's imaptest found it did not: some answers change from BAD to NO, and an APPEND stores the literal byte for byte. A restore refuses an archive with an absolute path, a .. or a link in it, and the installer's 7-Zip is 26.03. Mail labelled ISO-8859-1 is decoded as windows-1252. Only a new installation is made secure before anyone configures it: a self-signed certificate, STARTTLS on 25, 587, 110 and 143, and TLS required for sign-in from the Internet IP range. The Windows installer does it; on Linux the service's first start under systemd within a day of --create-database does it, and with an AppImage or a container image, neither of which 6.3.4 ships, an administrator runs --apply-new-install-defaults by hand. A new Windows installation also runs the service as NT SERVICE\hMailServer, and a new installation gets a stored-secrets key, made by the Windows installer, and on Linux by the container's --create-database only; a new .deb or .rpm installation gets its key when an administrator runs sudo hmailserver --create-stored-secrets-key, which the setup checklist offers. An upgrade keeps its listeners, its service account and its secrets as they were: nothing is sealed until an administrator runs --create-stored-secrets-key, which the setup checklist offers. Fixed before release 6.3.4 was audited area by area before it was cut, and its code was scanned by GitLab's SAST. The defects they found are fixed in this release. Several of these were in 6.3.3 as well. Passwords outside Latin-1. Every password hash was made over a conversion that turned the first character above U+00FF and everything after it into NUL bytes on Windows, and each such character into ? on Linux, so a password of Cyrillic, Greek or CJK letters could be opened by any other password of its length and shape. Hashes are now made over UTF-8 (see the upgrade note above). Sign-in. SCRAM-SHA-256 accepted the account's own password for an account with a second factor, and a password past its maximum age (6.3.3 had both). A sign-in under a domain alias, or with a token, a certificate or a Kerberos ticket, escaped the country policy. One-time codes could be used again within their window, and at several places a wrong one was not counted. Single sign-on and passkeys. A single sign-on ticket could be redeemed in another person's browser. With a parent-domain relying party, a page on any sibling host could sign somebody in with their passkey (passkey_allowed_origins now names the origins). A switched-off domain still let its people in by passkey or single sign-on. Delegated administration. Where the server administrator's own mailbox is in a domain somebody else administers, that domain's administrator could become the server administrator through an app password on it, delete or rename it, or repoint its fetch account, over REST and COM. A credential confined to one domain could set another domain's webmail branding and declare spam traps in any domain. Keys. An app password or an administrator's support session could read the account's wrapped S/MIME, OpenPGP and zero-access keys. An app password could also replace the account's own S/MIME key and publish an OpenPGP key for the address, and a support session could change any of the account's keys or switch zero access off. Collecting mail. On a server that collects Microsoft 365 mail with its own OAuth2 token, any person could collect any mailbox the token reaches (a domain administrator over COM since 6.2.23 Alpha 1). A CR or LF in a fetch account's user name or password added commands, and a fetch account's host could be pointed inside the network through DNS after it was saved. Schema 6104 marks the fetch accounts made or changed from now on: one a person makes connects only to public addresses, unless the administrator allows private ones, and one made without the server's authority is never given the server's token. Accounts from before 6104, and an administrator's, are not marked, so review existing fetch accounts for hosts on FetchOAuth2Hosts after upgrading. IMAP. A heap-corruption abort when two sessions met on one message's keywords, flag changes lost when two arrived at once, an abandoned APPEND that left its file for good, an unbounded LIST pattern, and ENVELOPE and BODYSTRUCTURE values that broke the response. 6.3.3 had all of them. The REST listener and the webmail. Request headers were read from the body, which allowed a forged sign-in. One person could stall the webmail and the Control Deck for everybody. A Web Push endpoint could point inside the network. Large downloads were cut off and held whole in memory, and a request head that never ended could hold 16 MB. GitLab's SAST (Semgrep). Seven of its High findings were real, and are fixed: the crash-dump helper would load a dbghelp.dll put in Bin; the Control Panel's elevated service restart would run a cmd.exe left in its working directory; the installer handed the administrator password to DBSetupQuick.exe, and it to DBUpdater.exe, unquoted on their command lines; a malformed backup index was read past its end (two); and a test of the MIME parser compared pointers into two different arrays. 169 others were read and judged not exploitable, each with its reason in .gitlab/security-exceptions.yml (188 entries there, 19 of them re-reads of lines the fixes moved). Found beside them and fixed too: the MySQL client's DLLs were looked for in the current directory and along PATH, and a custom virus scanner whose command line holds a bare %FILE% was handed the path cut at its first space, scanned no file, and the message was delivered as clean. The first security scans. The installer's 7-Zip is 26.03 in place of 19.00, which predates the fixes for CVE-2023-31102 and CVE-2025-55188; a restore refuses an unsafe archive; MIME boundaries come from a generator seeded by the operating system; zlib is 1.3.2. The two static-analysis findings that were defects are fixed: on Linux the service account's name is read with getpwuid_r, and an inbound webhook's URL must be printable ASCII on both platforms. Also in this release Most of what is new is off until an administrator turns it on. Mail flow: remote-domain policies, per-destination throttling and IP warm-up, a send API for applications, DKIM key rotation, journaling, restricted delivery, message recall, and mail in to a webhook. Anti-spam: hardened greylisting, SMTP policy rules, allow and block lists with quarantine digests, mail flow rules with an outbound content policy, impersonation protection, attachment sandboxing, spam traps and country blocking. Webmail and clients: CalDAV and calendars with invitations, free-busy and delegation, rooms and equipment that answer bookings, contact groups and a directory, recover deleted items, expiring messages, offline mail, Web Push and OpenPGP in the browser. Identity: administrator roles, passkeys, OpenID Connect and SAML sign-in, SCIM provisioning, self-service password reset, sessions and devices, and breached-password checks. Encryption: zero-access mailboxes, mailbox encryption at rest, gateway encryption to partner domains, an organisation CA for S/MIME, Web Key Directory, and sealed stored secrets. Compliance and administration: eDiscovery with legal holds and verifiable exports, settings at server, domain and account level, profiles, hmctl and a PowerShell module, and a setup checklist. Migration: resumable migrations from IMAP, Google Workspace and Microsoft 365, and PST import with a reader of the project's own. No PST job runs until an administrator names PstImportDirectory, copies the file there and starts the job. Operations: storage compression and attachment de-duplication; object storage on an S3-compatible store or Azure Blob Storage, off until an administrator names a store (MessageStoreBackend is file as shipped); encrypted backups; event scripts on Linux in JavaScript (QuickJS); a read-only SNMPv3 agent, off, and answering nobody until a manager's address is in SnmpAllowedAddresses; and syslog. The full list, with the operator document for each item, is the 6.3.4 section of CHANGELOG.md. What 6.3.4 does not carry No Sigstore bundle, so no server's live update installs it. From 6.3.5 the GitLab pipeline is to sign every file with Sigstore; none of its release jobs has run yet. No AArch64 .deb or .rpm, no AppImage, and no ARM64 Windows installer. No container image. The Dockerfile, the Compose file and the Helm chart are in the tree, nothing is published at registry.gitlab.com/progressiverobot/hmailserver yet, and the images published on ghcr.io before the suspension answer 404. No apt or dnf repository, and no winget or Chocolatey package of this project's in the public repositories (the hmailserver package on the Chocolatey feed is the upstream 5.6.8, unlisted). Downloads, and how to check them The release carries ten files: hMailServer-6.3.4-x64.exe, the Windows x64 installer; hmailserver_6.3.4_amd64.deb and hmailserver-6.3.4-1.x86_64.rpm for x86-64 Linux. An SBOM for each of those three, <file>.cdx.json (CycloneDX 1.6), whose subject is that file by its SHA-256 and SHA-512; and the source tree's SBOMs, hmailserver.spdx.json and hmailserver.cyclonedx.json. hmailserver-6.3.4-SHA256SUMS.txt, which names the other eight with their SHA-256, and hmailserver-6.3.4-SHA256SUMS.txt.sig, its signature, made with the SSH key that signs the release tags. https://updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hmailserver_amd64.deb and /download/hmailserver.x86_64.rpm always lead to that file of the newest stable release, never a pre-release's, and https://updates.progressiverobot.com/download/ to that release's page. To check a download, with OpenSSH 8.1 or later, in a clone of the repository (for .gitlab/allowed_signers) and with the downloads beside you: ssh-keygen -Y verify -f .gitlab/allowed_signers -I [email protected] -n file -s hmailserver-6.3.4-SHA256SUMS.txt.sig < hmailserver-6.3.4-SHA256SUMS.txt sha256sum -c hmailserver-6.3.4-SHA256SUMS.txt The first must say Good "file" signature for [email protected], and the second OK for every file (add --ignore-missing when you downloaded only some). On Windows, Get-AuthenticodeSignature .\hMailServer-6.3.4-x64.exe should also answer Valid, with a signer certificate for CN=Progressive Robot Ltd. The tag is signed with the same key: git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.4. SECURITY.md, "Verifying a release" and "Software bills of materials", has the rest, including how to check that an SBOM describes your file. Reporting a vulnerability Not in a thread here, and not in a public issue. Report it privately, as SECURITY.md says: a confidential issue on GitLab - check that it is still marked confidential before you submit it, and choose the Security template - or an email to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, which GitLab files as a confidential issue, so no GitLab account is needed. Release notes, checksums and downloads · Newest stable release

Written for 6.3.4. hMailServer 6.3.7 (17 October 2026) signs a message as a hosted domain only when the server is entitled to: mail from outside whose From names a domain hosted here is no longer signed with that domain's DKIM key, and an authenticated submission is signed as another hosted domain only when its account may send as the address its From names (CVE-2026-107567); the upgrade stops the signing, and only rotating the domain's key ends the signatures already made. A forward of outside mail whose From names the forwarding domain's own organisation is given an SRS or rewritten envelope sender only when the message passed DMARC for it on arrival; with SRS on, mail to an SRS address this server handed out is held to the relay rules unless it is a bounce; and an ARC seal this server makes attests its own SPF result and names the domains its results are for. See the 6.3.7 announcement. Getting mail accepted is mostly DNS. hMailServer does the cryptography and the protocol work. It cannot publish records for you. This is the split. What the server does on its own DKIM signing. Open the domain's DKIM tab in the Control Panel and click Generate key. It creates an RSA-2048 key, saves the private key, fills in the path and shows the exact TXT record with a Copy button. Once the record is published it signs the domain's outgoing mail - a signed-in account's submission and every copy of it, a message the server makes itself, and mail an IP range lets in as one of this server's domains - but since 6.3.7 not mail from outside whose From names the domain: such mail leaves with the signature it came with. Since 6.3.7 an authenticated submission is signed as another hosted domain only when its account may send as the address its From names (CVE-2026-107567). Ed25519 DKIM (RFC 8463) is supported alongside RSA, for shorter keys. Since 6.3.4 a domain's DKIM keys can also rotate on a policy, off by default. DkimOversignHeaders over-signs the header fields you name. DkimAcceptSha1=0 refuses rsa-sha1 signatures on inbound mail. SPF and DMARC inbound. SPF is checked as part of anti-spam scoring, with SpfVoidLookupLimit=2. Since 6.3.4 it follows RFC 7208: mail from 127.0.0.0/8 and ::1 no longer passes unconditionally, so a content filter that hands mail back should authenticate, or connect from an IP range with anti-spam off. DMARC policy is evaluated on inbound mail and the DMARCbis tree walk is on by default (DmarcTreeWalkEnabled=1). Aggregate reporting stays off until you set DmarcRptFromAddress. Outbound transport security. MtaStsEnabled=1, DaneEnforcementEnabled=1 and DnssecValidationEnabled=1 are all on by default, under TLS & certificates → Transport security. A recipient whose DNSSEC chain is bogus does not receive your mail rather than receiving it unencrypted. That is the point of enforcement, so read the logs before you reach for the switch. TLS-RPT. Off until you set TlsRptFromAddress. After that the server sends daily reports to recipient domains about TLS failures it hit delivering to them. SRS and BATV. Off by default. If you forward mail, set SRSEnabled=1 and a SRSSecret to keep forwarded mail SPF-aligned. The secret must be stable. Outstanding SRS addresses remain valid for 21 days, so changing it loses bounces for mail you forwarded recently. BATV (prvs) signs your envelope sender so you can recognise and drop backscatter. Neither ever became an RFC. Both follow the widely deployed drafts, as does everything that interoperates with them. What you must publish yourself PTR, and your ISP sets that one, not you. Missing PTR is the single biggest cause of spam-foldering. Then SPF, the DKIM TXT record, and DMARC. For MTA-STS on the inbound side, point mta-sts.<domain> at the server, set MtaStsHostingEnabled=1 and WebServicesHttpsPort=443, and publish the _mta-sts.<domain> TXT record. If you publish TLSA records for inbound DANE, keep AcmeReuseKey=1 so renewals do not invalidate them. Start DMARC at p=none. Read the reports for a few weeks and confirm all your legitimate mail passes SPF and DKIM before moving to p=quarantine, then p=reject. Starting at p=reject silently loses mail from the sender you had forgotten about. Still incomplete ARC sealing (RFC 8617) covers mail from hosted DKIM-enabled domains. Relayed third-party mail is not sealed yet. Chapter 8, the DNS records with example syntax: https://www.progressiverobot.com/hmailserver-documentation/#8-making-the-internet-trust-you-dns Chapter 9.4, outbound transport security: https://www.progressiverobot.com/hmailserver-documentation/#94-outbound-transport-security Chapter 17.6, SRS and BATV: https://www.progressiverobot.com/hmailserver-documentation/#176-srs-and-batv

Written for 6.3.4. hMailServer 6.3.8 (2 November 2026), a security release, is the release to install: as 6.3.7 (17 October 2026) did, beside the generic .deb and .rpm for x86-64 and AArch64 it carries a package for each of Debian 12 and 13, Ubuntu 24.04, Fedora 43 and 44, Enterprise Linux 9 and 10 and openSUSE Leap 16.0 and Tumbleweed, each installed in a clean container of its release by that release's own package manager before publication, so step 1 is apt, dnf or zypper with your release's own package; the AArch64 files are cross-compiled and tested under emulation. Check a download with sha256sum -c --ignore-missing hmailserver-linux-6.3.8-SHA256SUMS.txt first. See the 6.3.8 announcement. The order matters more than the commands. The package installs the server enabled and stopped, on purpose: it has no database yet, and nothing in a package can know which backend you have or its credentials. The full sequence, with the output each step prints, is §35.3. Take the exact file names from the downloads page, and note the RPM carries a -1 release field in its name. 1. Install the package. sudo apt install ./<file>.deb on Ubuntu 26.04 or 24.04, sudo dnf install ./<file>.rpm on Fedora 43 or 44 or Enterprise Linux 10. 6.3.4's .deb needs glibc 2.38 or later, so it does not install on Debian 12; its .rpm does not install on Enterprise Linux 9, and nothing has been tried with zypper on openSUSE. The maintainer script creates the hmailserver system user and group, creates the directories, and enables the unit without starting it. It deliberately does not walk or chown an existing store. 2. If your backend is MySQL or MariaDB, install the client library now. The server opens it at run time and no package manager will pull it in: libmariadb3 on Debian and Ubuntu, mariadb-connector-c on Fedora and RHEL, mariadb-libs on Arch. PostgreSQL needs nothing extra. 3. Create the database role. Either let the role create its own database, or create an empty one yourself and leave the role without CREATEDB. §35.4 has both, and the SSL keys for a database on another host. 4. Edit /etc/hmailserver/hMailServer.ini. Fill in [Database]. Two rules catch people. Only ; starts a comment, and only at the start of a line. Text after a value on the same line is part of the value, so Type=PostgreSQL ; the backend matches no backend name. Write the port out: PostgreSQL wants 5432, MySQL and MariaDB want 3306. Leave AdministratorPassword alone. 5. Set the administrator password. sudo hmailserver --set-admin-password reads it from standard input with echo off and writes the hash into the file. This is the one step that runs as root, because the file is 0640 root:hmailserver. 6. Create the schema. sudo -u hmailserver hmailserver --create-database. Then, as root, make the stored-secrets key that second factors and the [Settings] secrets are sealed under, and export it at once: sudo hmailserver --create-stored-secrets-key, then sudo hmailserver --export-stored-secrets-key /root/hmailserver-stored-secrets.key. Keep that file with the database backups, stored apart from them. Without a key those secrets are stored as written, as before 6.3.4. 7. Check it before starting anything. sudo -u hmailserver hmailserver --check-config, as the service user and without --config, so the server has to find the configuration on its own. Database type: 0 means the Type key did not take. It is a report and not a validator: it returns 0 unconditionally, so read the output rather than its exit status. 8. Start it. sudo systemctl start hmailserver, then journalctl -u hmailserver -f. A freshly created database already holds four listeners: SMTP on 25 and 587, POP3 on 110 and IMAP on 143, bound to every address. Since 6.3.4 the unit's first start, if it comes within a day of --create-database, gives them a self-signed certificate and optional STARTTLS, and makes the Internet IP range require TLS for authentication (SecureDefaults.md). Mail clients warn about a self-signed certificate, so replace it with ACME or your own before this faces the internet. The listeners and the certificate are database rows, not INI keys, so you change them over the API or the Control Deck's Ports and Certificates views. 9. Turn on administration. sudo hmailserver --set-setting RestApiPort=8080 (or another free port), leave RestApiBindAddress on loopback, and sudo systemctl restart hmailserver. Not by editing the file: since 6.3.4 the database is the settings store, and a [Settings] line edited after the first start is reported as HM5804 and not applied: the service cannot write the packaged file, so the line stays as you left it and the stored value is used. TLS is required unless the bind address is exactly 127.0.0.1, localhost or ::1, so tunnel over SSH rather than exposing it. §35.9 and §35.10 are the rest. Post what --check-config printed and the last lines of journalctl -u hmailserver if a step stops. §35.16 lists the Linux-specific failures by symptom.

Moving to new hardware is a restore onto fresh metal. Chapter 15 is the prerequisite, and the first time, rehearse onto a test machine. The plan (§33.2) Check the new machine against the chapter 3 checklist. Size the disk for the mail store you have now, not the one you had at installation. Install the same version, in the same path: a different version or directory is where these moves go wrong. Since hMailServer 5.4 a message row holds a bare file name and the path is rebuilt from the data directory; a database from before 5.4 can still hold full paths. Back up the old server. The built-in backup does not include messages unless you tick the option. For a large store, stop the service, copy Data\, dump the database natively, and take hMailServer.INI, Events\, your DKIM keys and, if one was made, an export of the stored-secrets key (--export-stored-secrets-key). Stop the old service for good and set it to Disabled. Anything it accepts after the backup is stranded. Restore the data directory, the database and hMailServer.INI, in chapter 15's order. Re-enter the protected secrets. Keep the host name if you can. Update the A record with a lowered TTL, get a PTR on the new IP, re-run the firewall rules, repoint your port forwards, and run Monitoring & troubleshooting, Diagnostics last. Leave the old machine powered off but intact for a week or two. It is the rollback. Budget for step 6. With ProtectStoredSecretsWithDPAPI=1, the default, stored passwords are encrypted with machine-scoped Windows DPAPI and cannot be decrypted on the new machine. Re-enter the database connection password with Bin\DBSetup.exe, then route, smart-host relayer and external-account passwords in the Control Panel. Forget this and you get a server that cannot reach its own database. Since 6.3.4 the stored-secrets key that seals second factors and the [Settings] secrets is kept in hMailServer.INI under the same DPAPI, so a copied INI does not carry it: import the exported file on the new machine with hMailServer.exe --import-stored-secrets-key <file> and restart the service. An upgraded server has no such key until an administrator makes one. Linux to Linux is easier: secrets sit under <DataFolder>/.hmailserver-secret-key, so copy that file too, preserving mode 0600 and its ownership. Windows to Linux is not a migration It is not supported and the project does not claim it is. The schema is the same on both, 6.3.4 needs 6104 either way, and the message store's on-disk format is the same. What is missing is a tested path: nobody has run a Windows installation onto Linux and verified the result (§35.14). What is known to break: SQL Server. An INI with Type=MSSQL or Type=MSSQLCE is refused by name. Move to PostgreSQL or MySQL on Windows first. Every DPAPI secret. Route, fetch-account and per-domain relay passwords, private-key passphrases and the administrator's TOTP secret. Each is reported once as HM6414 and answers empty. Event scripts and COM integrations. COM does not exist on Linux, and since 6.3.4 event scripts run there in JavaScript only: a VBScript file is rewritten and a JScript one ported, without COM objects. DKIM key paths. The per-domain key-file setting holds a Windows path such as C:\keys\mail.pem, which resolves to nothing on Linux. Copy the keys and re-point every signing domain. Directory case. The Linux build lower-cases directory names derived from an address; Windows leaves them as found. A store carrying Test.com is one this server looks for under test.com, and everything under it must end up owned by hmailserver. So treat it as a rebuild and a cutover. A new installation on Linux, accounts and mail brought over at mailbox level by mirroring folders over IMAP from the running Windows server. The Import Tool is not an option here: it is a Windows .NET program that drives the COM API, and Linux has neither (§33.8), verified against a still-running Windows server, DNS moved last.

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 (GitHub 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. What the upgrade involved 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

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 (GitHub 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

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

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. (GitHub issue 156, #177) Full release notes, checksums and signatures

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 (GitHub issue 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

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