Recently Active Topics

Start here: hMailServer 6 is maintained, and this is its community forum

Progressiverobot — Wed, 23 Sep 2026 06:41:51 GMT

hMailServer is a free, open-source (AGPL-3.0) mail server for Windows and Linux, and this is its community support forum, run by Progressive Robot Ltd, which maintains the hMailServer 6 line. The current release is hMailServer 6.3.3, released on 15 September 2026. What changed in hMailServer 6 hMailServer was created by Martin Knafve. The original project went quiet for years, and in 2026 Progressive Robot Ltd forked it and released hMailServer 6.0.0 on 12 June 2026. The original project has since resumed development separately. Platforms: Windows 10 version 1607 or later, Windows 11 and Windows Server 2016 or newer, x64 only. Linux on x86-64 and AArch64 since hMailServer 6.3.0, released on 10 September 2026. Upgrades: the hMailServer 6.3.3 Windows installer upgrades 5.3, 5.4, 5.5, 5.6, 5.7, 6.0, 6.1 and 6.2 in place, keeping mail, accounts, domains and settings. An installation older than 6.3.1 should go straight to 6.3.3, because 6.3.2 could not upgrade an older database. Security: TLS 1.2 and 1.3 only, with MTA-STS, DANE and DNSSEC validation enforced on outbound mail by default, and a built-in ACME v2 client for Let's Encrypt. Off by default: the REST API, the browser Control Deck and the webmail at /portal stay off until RestApiPort is set in hMailServer.ini. Windows is the more complete platform: Linux has no Control Panel, no COM API and no event scripts, and per-domain DKIM cannot be configured there yet. Moving a Windows installation to Linux is not a supported migration: treat it as a new installation plus a mailbox-level migration. Where things are Downloads and release notes: hMailServer downloads, with SHA-256 checksums and Sigstore signatures. The pinned release history topic in Announcements summarises every version. Documentation: hMailServer documentation, 37 chapters. Source code and issues: GitLab. Forum pages: about, FAQ, rules and how to ask. Categories: Announcements & releases, General support, Installation, migration & upgrades, Linux, Webmail, portal & Control Deck, TLS, certificates & deliverability, REST API & integrations and Bug reports. Commercial support: Managed hMailServer, the managed hMailServer page, support plans and contact. hMailServer has no per-mailbox fees and no paid tiers, and no answer on this forum depends on buying anything. Asking for help Post in General support or the matching category, using the template in how to ask: the exact version, the platform, the database and a log excerpt with credentials redacted, because the forum is public and indexed. Give the full build stamp on Windows (6.3.3.42 for hMailServer 6.3.3) or the exact package version on Linux. Never post a suspected security vulnerability in a thread or public issue: email info@progressiverobot.com with the version, the platform and enough detail to reproduce it.

hMailServer release history: every 6.x version, with dates

Progressiverobot — Wed, 23 Sep 2026 06:17:01 GMT

Every hMailServer 6 release, newest first, with the date it was signed or built and a link to its announcement on this forum. Release notes, checksums, signatures and SBOMs for each one are on the downloads page. The current release is hMailServer 6.3.3, released 15 September 2026. Releases (33) Version Released What changed 6.3.3 15 September 2026 Outbound BDAT stalled every message over 60,000 bytes 6.3.2 13 September 2026 A public resolver made SURBL tag every message with a link as spam 6.3.1 11 September 2026 The installer is signed, and UpdateRequireAuthenticode works 6.3.0 10 September 2026 The server runs on Linux, but not with per-domain DKIM signing 6.2.28 8 September 2026 The server can verify and apply its own updates 6.2.27 7 September 2026 A stripped DS record turned a signed zone unsigned 6.2.26 6 September 2026 SQL Server Compact upgrades to schema 6030 reported as failed 6.2.25 6 September 2026 ACME issuance and renewal terminated the server process 6.2.24 4 September 2026 Delegated IMAP MOVE could destroy the only copy of a message 6.2.21 16 August 2026 Inbound mail from a Postfix relay could hang forever 6.2.20 15 August 2026 Fresh installs failed and silent installs hung on a dialog 6.2.19 15 August 2026 Custom DNS server broke every lookup since 6.2.16 6.2.18 12 August 2026 A stalled database bounced valid mail instead of retrying it 6.2.17 12 August 2026 Relayed mail could stall after end-of-data with no 250 6.2.16 11 August 2026 An error dialog on closing the Ctrl+K settings palette 6.2.15 11 August 2026 IMAP sequence sets, and a restore that could empty the data directory 6.2.14 11 August 2026 IMAP APPEND reported success for mail it never wrote 6.2.13 11 August 2026 A DATA stall on relayed mail 6.2.12 10 August 2026 Every C# component now targets .NET 8 6.2.11 7 August 2026 Two Control Panel lists read their class name to screen readers 6.2.10 7 August 2026 The COM API reported success on calls it refused 6.2.9 7 August 2026 The dashboard charts that rendered white 6.2.8 7 August 2026 Blank list editors and a Control Panel that died on restart 6.2.7 15 June 2026 File pickers and one-click DKIM in the Control Panel 6.2.6 15 June 2026 IMAP4rev2 as an opt-in mode, and a Control Panel redesign 6.2.5 15 June 2026 Default installs could not connect to their own database 6.2.4 15 June 2026 Active Directory account pickers in the Control Panel 6.2.3 15 June 2026 Sieve and ManageSieve filtering 6.2.2 14 June 2026 RFC 4013 SASLprep and a substantially upgraded Control Panel 6.2.1 14 June 2026 PIPELINING, SMTPUTF8, DSN and SRS 6.2.0 14 June 2026 The new Control Panel desktop administration app 6.1.0 12 June 2026 The Web Control Deck and a light/dark Administrator 6.0.0 12 June 2026 The modernised baseline, and the build 4 installer fix Pre-releases (8) These were test builds. Everything in them shipped in a later release, and none of them should be installed today. Version Released What changed 6.2.23-alpha2 4 September 2026 Thunderbird could not save a single Sent copy 6.2.23-alpha1 21 August 2026 Local delivery could lose a message after answering 250 6.2.22-pre6 20 August 2026 Pre4 was withdrawn, a fresh install listened on nothing 6.2.22-pre3 19 August 2026 The server now enforces per-account 2FA and app passwords 6.2.22-pre2 18 August 2026 DMARC aggregate reports (rua) are now sent, not just consumed 6.2.22-pre1 16 August 2026 The built-in ACME client never worked with Let's Encrypt 6.0.0-B4 12 June 2026 Fixes the startup crash from the bundled VC++ runtime 6.0.0-B1 12 June 2026 First regression-validated build of the modernised 6.0 line

Being trusted by the servers you send to

Progressiverobot — Wed, 23 Sep 2026 01:45:00 GMT

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 every outgoing message from that domain. Ed25519 DKIM (RFC 8463) is supported alongside RSA, for shorter keys. 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. 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 Settings → Security → 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. at the server, set MtaStsHostingEnabled=1 and WebServicesHttpsPort=443, and publish the _mta-sts. 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

Let's Encrypt certificates are automatic: the built-in ACME v2 client

Progressiverobot — Wed, 23 Sep 2026 01:40:00 GMT

hMailServer has an ACME v2 client built in (RFC 8555). It obtains a free certificate, installs it, assigns it to your TLS ports, renews it before expiry and reloads it. No restart, no scheduled task, no external client. Configure it under Settings → Security → Certificates (ACME), or in hMailServer.INI: AcmeEnabled=1 AcmeContactEmail=you@yourcompany.com AcmeDomains=mail.yourcompany.com,mta-sts.yourcompany.com,autoconfig.yourcompany.com AcmeHttpPort=80 AcmeReuseKey=1 AcmeEnabled ships as 0. AcmeDirectoryUrl defaults to https://acme-v02.api.letsencrypt.org/directory. Two requirements. Port 80 must be reachable from the internet, because that is how the http-01 challenge proves you control the name. Every name in AcmeDomains must already resolve to this server before you switch it on. If you also host MTA-STS or client autoconfiguration, put mta-sts., autoconfig. and autodiscover. in AcmeDomains so one certificate covers them. After issuance. The server creates or updates a certificate record named ACME (automatic) and assigns it to every TLS-enabled listener that has none of its own, logging each assignment. A listener the assignment could not be saved for is reported as a High 6100 rather than logged as a success, because a port left without a certificate accepts no TLS at all. That is the error to alert on. Renewal. The renewal window is two thirds of the certificate lifetime, plus ARI. That is why there is nothing left to schedule. Files live in Data\ACME on Windows and /var/lib/hmailserver/ACME/ on Linux: the account key, fullchain.pem and privkey.pem. Back that directory up with the rest of Data\. If a restore misses it the client re-issues, but the new key invalidates any TLSA records you have published. Leave AcmeReuseKey=1. Keeping the same private key across renewals is what keeps published TLSA records valid. Linux. Port 80 works without root. CAP_NET_BIND_SERVICE on the unit is what allows the bind. The default certificate directory is /ACME, which is inside ReadWritePaths. Point AcmeCertificateDirectory elsewhere and you must add that path to ReadWritePaths with a drop-in, or issuance fails on a read-only filesystem. If it never worked for you. The built-in client had never once succeeded against real Let's Encrypt until 6.2.24 (#34). Boulder pretty-prints its JSON and the challenge locator searched for the compact spelling. 6.2.25 then fixed issuance and renewal ending the process (#93). If you gave up on this on an older build, it is worth another look. Another CA. Leave AcmeEnabled=0, add the PEM certificate and key under Settings → Security → SSL certificates, then assign it to ports under Settings → Network → TCP/IP ports. On Linux, an external client that replaces the PEM files in place needs POST /api/v1/server/reinitialize or a restart before the new files are served. Chapter 9, encryption and certificates: https://www.progressiverobot.com/hmailserver-documentation/#9-encryption-and-certificates Report problems: https://gitlab.com/Progressiverobot/hmailserver

The Control Deck: browser administration at /

Progressiverobot — Wed, 23 Sep 2026 01:35:00 GMT

The Control Deck is the administration page hMailServer serves at /, on the same listener as the API and the portal. On Linux it is the only administration front end there is, because that build has no Control Panel and no COM. On Windows it does not replace the Control Panel and it does less. Turning it on. One setting, RestApiPort, turns on the API, the Deck and the portal together. The default is 0, which leaves all three off, so a server upgraded without touching its settings serves none of them. The listener refuses to start rather than come up without a credential or without TLS, and logs which. Four messages begin RestApi: Refusing to start. The two you will meet are an unset administrator password and a non-loopback bind with no certificate. The TLS exemption applies only to a bind address that is exactly 127.0.0.1, localhost or ::1. 36.2 Signing in. The password goes once to POST /api/v1/session and is exchanged for an hmailsession cookie that is HttpOnly and SameSite=Strict. Two ceilings apply, 30 minutes idle and 12 hours absolute, neither configurable. Any cookie-authenticated request whose method is not GET or HEAD must carry X-Requested-With: hMailServer or it answers 403; HTTP Basic and bearer keys are exempt. An API key cannot mint a session. Sessions are process-local, so a service restart ends every one. 36.3 What it does. Dashboard, Domains, Delivery queue, DANE/TLSA, Settings, Rules, Routes, Certificates, Ports and Logs. 6.3.3 added full domain editing, the account editor in full, distribution lists and aliases, an IP-ranges view, fetch-account and backup views, the scripting, cache and indexing groups, and a CI harness of 292 checks. The settings forms are worth understanding. The Deck fetches GET /api/v1/openapi.json once per session and draws each form from the schema of that group's PUT. Nothing in the page lists a settings key by name, so a key added to the API appears on its own, with its type, its permitted words, and a badge when it is read-only, write-only, required, or takes effect only on restart. The Ports view carries a Restart the services now button, which posts to /api/v1/server/reinitialize. It drops connections in progress and ends your session with everyone else's. 36.4 A few write surfaces remain API-only. Measured, not asserted. build/check-deck-parity.py counts every field the desktop Control Panel writes against the REST API and the Deck, and reports in hmailserver/docs/DeckParity.md. Of 330 properties, 240 were writable over REST and 153 reachable from a Deck view when that work started; 328 and 322 by the end of it. The two still not writable over REST are groups and their members. The six between those figures are properties the API writes and the page has no control for. Use curl for those. 36.5 still describes the 6.3.1 gaps, which were far wider. The 6.3.3 entry in the release notes is the current statement until that chapter is rewritten. Check DeckParity.md in the source tree before assuming a route does not exist.

The webmail portal at /portal

Progressiverobot — Wed, 23 Sep 2026 01:30:00 GMT

/portal is the self-service webmail hMailServer serves out of its REST listener. A mailbox owner signs in with their own address and password and gets folders, search, compose, drafts, flags and inline images. It is not a calendar and not a groupware suite. 6.3.3 added CardDAV for the account's address book, but that is served on the web services HTTPS listener, not this one. It is compiled into the binary. There is no web root to deploy and no file to lose. At 6.3.3 the page is Portal.html and Portal.js, embedded at build time. So if the Control Deck answers and the portal does not, an absent file is not the cause. Check you are asking for /portal exactly, because the server answers that path and nothing below it, and check no proxy is rewriting it. 36.14 has the rest of the symptom table. It fetches nothing externally. No font, no image, no stylesheet, no script from a CDN. Its Content-Security-Policy is default-src 'none'; script-src 'self'; style-src 'unsafe-inline'; img-src data:; connect-src 'self'; frame-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'none'. Note img-src data:, which permits no image from any host, including this one. A sender's HTML is never merged into the page. It goes into an iframe sandboxed without allow-scripts and without allow-same-origin, under its own policy of img-src data:, so a remote tracking pixel stays in the markup and is blocked. Opening a message tells its sender nothing, and there is no setting that changes that. 36.10 explains why the obvious design cannot work. It is not an administration interface. Everything the portal does is under /api/v1/me/, and those routes answer to an account's own credentials and to nothing else. The administrator password is refused on every one of them, and so is an API key. Administration is the other page, the Control Deck at /. Both sit on one listener behind one switch, RestApiPort, so exposing one exposes the other. If mailbox owners reach /portal from the internet, split the surfaces at a reverse proxy: /portal, /portal.js and /api/v1/me/* public, /api/v1/session public because both pages sign in through it, and / plus everything else under /api/v1/ on the internal network. 36.13 IMAP clients are unaffected. The portal is another client against the same store. A flag change requires the rights STORE requires, and every IMAP session on the folder is told. A move is IMAP MOVE: a copy with a new UID, then the original expunged. Folder create, rename and delete run IMAP's checks in IMAP's order and refuse with IMAP's own sentences. The new-mail probe reads the cached per-folder collection that IMAP, POP3 and delivery already share, so polling opens no message file. Outlook, Thunderbird, Apple Mail and phones carry on unchanged, and Roundcube pointed at the IMAP port remains a reasonable choice. Full reference: 36.6 The portal: what a user gets.

First install on Linux: the order of operations, Debian to openSUSE

Progressiverobot — Wed, 23 Sep 2026 01:25:00 GMT

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 ./.deb on Debian and Ubuntu, sudo dnf install ./.rpm on Fedora and RHEL, sudo zypper install ./.rpm on openSUSE. The RPM is the same file. 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. 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 with connection security set to none. Those are database rows, not INI keys, so you change them over the API or the Control Deck's Ports view before this faces the internet. 9. Turn on administration. Set RestApiPort, leave RestApiBindAddress on loopback, and reload. 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.

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

Progressiverobot — Wed, 23 Sep 2026 01:20:00 GMT

Since 6.3.0 the same source tree builds, installs and delivers mail on x86-64 and AArch64 Linux, as a systemd service, from a .deb, an .rpm or an Arch PKGBUILD. That is why the release is numbered 6.3 and not 6.2.29. Read §35.1 before you install anything. Finding out about a missing capability after the mailboxes are populated is the wrong order. What crossed The SMTP, POP3 and IMAP engines, delivery, routing, rules, anti-spam, anti-virus, ACME, the backup manager, the REST API, the Control Deck and the self-service portal. The on-disk message format is unchanged: one directory per domain and per mailbox, one file per message. The database schema is the same version the Windows build of the same release needs. The packages A .deb for Debian, Ubuntu and derivatives. An .rpm for Fedora, RHEL and derivatives, which openSUSE also consumes, though not separately exercised in CI. Arch is a PKGBUILD in the tree, built with makepkg -si from the git tag. Both architectures are built natively in CI. Nothing else is packaged. The AppImage is not for running mail. It runs as whoever started it, with no hmailserver user, no unit and none of the systemd hardening, it puts its store under the invoking user's home directory, and it cannot bind port 25. Use it to see the thing work on a laptop. §35.2. Where things live Configuration is /etc/hmailserver/hMailServer.ini at 0640 root:hmailserver. The store is /var/lib/hmailserver, the logs /var/log/hmailserver, the unit /usr/lib/systemd/system/hmailserver.service. The service runs as hmailserver:hmailserver and never as root. Full table: §35.6. The backends are PostgreSQL through libpq, a link-time dependency, and MySQL or MariaDB through a client loaded with dlopen at run time, which nothing pulls in for you. SQL Server and SQL Server Compact are refused by name, so an INI carried across from Windows is repointed or it does not start. The gaps, stated plainly No Control Panel and no COM API. Both are Windows-only and are not compiled here. Every third-party COM script stops at that boundary. No event scripts. There is no script engine, and a non-empty script file is reported as uncompilable. Domain properties were not writable when Linux arrived, and are now. At 6.3.0 per-domain DKIM, per-domain size limits and the domain signature were readable over REST and not writable. 6.3.3 added nine more domain fields to PUT /api/v1/domains/{domain} and full domain editing to the Control Deck. Of the 330 properties the Windows Control Panel writes, 328 are writable over REST and 322 reachable from a Deck view; the two exceptions are groups and their members. The same gap takes per-domain size limits, the domain signature and a per-domain relay host with it. No self-update. The update checker names the package your machine would install, and the apply step refuses. You upgrade with apt, dnf or pacman. No tested path from Windows. The schema and the store format are shared, so the pieces are there. Nobody has run a Windows installation onto Linux and verified the result. §35.14 says what is known. Administration is therefore the Control Deck at / on the REST listener, and the REST API behind it. §35.10 covers the daily jobs.

Moving to new hardware, and why Windows to Linux is a rebuild

Progressiverobot — Wed, 23 Sep 2026 01:15:00 GMT

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. The database records absolute paths to message files, so a different version or directory is where these go wrong. 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\ and your DKIM keys. 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 Utilities, 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. Linux to Linux is easier: secrets sit under /.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.3 needs 6040 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. Neither exists on Linux. 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.

Upgrading to 6.3.3: any 5.3 or later goes straight there

Progressiverobot — Wed, 23 Sep 2026 01:10:00 GMT

hMailServer upgrades in place. The installer stops the service, replaces the program files in Bin, upgrades the schema if needed, and restarts. Your data directory and hMailServer.INI are untouched. Any 5.3 through 6.2 goes straight to 6.3.3. There are no intermediate steps. The upgrade chain is continuous on MySQL/MariaDB, MS SQL, PostgreSQL and SQL Server Compact, and DBUpdater walks whichever steps your database still needs. 6.3.3 needs schema 6040. A 6.2.27 or 6.2.28 database sits at 6031 and is walked through 6.3.2's seven steps and 6.3.3's two. Older ones are walked the whole way. Path table: §18.2. Nothing 6.3.0 added is on by default. The REST API, the Control Deck and the portal all need RestApiPort set. A server upgraded without touching its settings behaves as 6.2.28 did, apart from the 6.3.3 delivery fix and the rebuilt webmail. Before you start Back up the database, the data directory and hMailServer.INI (chapter 15). Record your current version. Pick a quiet window; the service is down for a minute or two and senders retry. That backup is the rollback. The upgrade is one way: an older server refuses a newer database rather than misreading it. Rolling back means uninstalling 6.3.3, reinstalling your previous version and restoring the database from backup (§18.6). The step that can fail Two schema steps want a maintenance window on a large database. 6024 to 6025 rewrites hm_messages.messageflags from tinyint to smallint: a locking table rewrite on your largest table, on every backend except PostgreSQL. 6029 to 6030 adds seventeen FOREIGN KEY constraints with ON DELETE CASCADE and reads every child table once. 6029 to 6030 is the one place an upgrade stops. It sweeps orphaned rows before adding those constraints, and that sweep ran children before parents, so pruning an orphaned account, fetch account or distribution list could re-orphan rows nothing revisits, and the constraint that followed was refused. The reordering fix shipped in 6.3.2 and is in 6.3.3. It fires only from a schema below 6030, only against a database that already holds orphaned rows, on all four backends. No installation has reported hitting it. When that step fails it fails loudly, in the database engine's own words, and rolls back rather than doing anything quietly. The database is where it was, the error names the constraint it could not add, and those orphaned rows have to go before the upgrade will pass. On 6.3.1 or 6.3.2 6.3.2 could not upgrade a database older than its own schema; those attempts stopped with The server has not loaded its configuration and changed nothing. The Control Panel's live update to 6.3.2 failed with installer exit code 5, because the Control Panel that started it held its files open. Both are fixed in 6.3.3, but the live-update helper is the one already installed. Close the Control Panel and run the installer by hand once. On Linux the package replaces the binary and its post-install step runs hmailserver --upgrade-database. Downloads and release notes · Chapter 18, upgrading

Where to post what: a map of the forum categories

Progressiverobot — Wed, 23 Sep 2026 01:05:00 GMT

The category tree is small on purpose, but a few boundaries are not obvious. This is where each thing goes. If you get it wrong, a moderator moves the topic rather than closing it. Running hMailServer General support. The catch-all. If none of the categories below is clearly right, post here. Installation, migration and upgrades. Installer failures, moving an install to new hardware, changing database backend, and anything that went wrong during an upgrade. Read §18 of the documentation first. Linux. Packaging, systemd, file permissions, and anything specific to the .deb, .rpm or AppImage builds. Linux support arrived in 6.3.0. A protocol question that would be identical on Windows goes to General support. Webmail, portal and Control Deck. The web interfaces themselves. Mail that never arrived is a delivery problem, not a webmail problem. TLS certificates and deliverability. Certificate chains and renewal, TLS on the mail ports, SPF, DKIM, DMARC and reverse DNS. Anything ending in "the recipient rejected it" starts here. Documentation §8 and §9. Anti-spam and message filtering. Scoring, blocklists, false positives, virus scanning. Documentation §10 and §11. Guides and tutorials. Finished, tested write-ups. Not questions. If you are still asking, ask elsewhere and write the guide afterwards. Automation and integration Scripting and the COM API. Server-side scripts and anything driving hMailServer through COM. REST API and integrations. The HTTP API, and third-party systems talking to it. Rules, Sieve and routing. Server and account rules, Sieve scripts, routes and relays. Documentation §12 and §14. Monitoring, metrics and logs. Reading the logs, JsonLogging=1 output going into Elasticsearch, Loki or Splunk, health checks and alerting. Documentation §16. A log line you cannot interpret that turns out to be a delivery fault still belongs in the relevant support category. Development and roadmap Bug reports. Reproducible defects only. Version including build stamp, platform, database backend, and the steps that reproduce it. Confirmed bugs are tracked at https://gitlab.com/Progressiverobot/hmailserver. Pre-release builds. Anything that is not a signed release. Keep pre-release findings out of the support categories, because the answers there assume a released build. Feature requests. One request per topic, so each can be discussed and closed on its own. Community Off-topic. Everything else. Forum feedback and help. Problems with this forum: accounts, formatting, moderation, categories. Managed hMailServer For customers of the managed service. Do not post account or billing details in public. Whichever category you pick, the checklist in the pinned posting guide still applies. Version with build stamp, platform, database backend, upgrade or fresh install, logs with credentials redacted.

Read this before you post: what a support request needs

Progressiverobot — Wed, 23 Sep 2026 01:00:00 GMT

Most threads here stall for the same reason. The report describes the symptom but not the system, and the first three replies get spent asking for things that should have been in the first post. Include all of the following. Version, with the build stamp. Not "6.3" and not "the latest". The full four-part number as the downloads page gives it. 6.3.3 ships as build 6.3.3.42 on Windows. Point releases days apart change behaviour, so the build matters. Platform and package. Windows 10 (1607 or later), Windows 11, or Windows Server 2016 or newer. 64-bit only. On Linux, x86-64 or AArch64 with systemd, supported since 6.3.0. Say which package you installed: hMailServer-6.3.3-x64.exe, a .deb, an .rpm, or the AppImage. Behaviour differs between them. Database backend. Built-in (SQL Server Compact), MySQL or MariaDB, Microsoft SQL Server, or PostgreSQL. On Linux only PostgreSQL and MySQL/MariaDB are accepted. The built-in database and SQL Server are refused by name there. Give the database server version too, not just the product. Upgrade or fresh install. If it was an upgrade, say what it was upgraded from. Upgrades are in place and do not require stepping through intermediate versions, so if yours behaved otherwise that is itself the report. If you upgraded from 6.3.1 or 6.3.2, say whether the Control Panel was closed first. If the install is fresh, say so. It rules out half the causes immediately. Diagnostics output. Run Utilities → Diagnostics before posting and paste the result. It self-tests DNS resolution, database connectivity, port bindings and disk access, and it often answers the question on its own. See §16.4 of the documentation. The relevant log lines. Logs live in the Logs directory on Windows and /var/log/hmailserver on Linux. Settings → Logging controls what is written. Turn debug logging on only long enough to reproduce the fault, then turn it off. It is verbose and it will fill the disk. Paste the lines around the failure in a fenced code block. Not a screenshot. Ten lines of context beats a 40 MB attachment. What you already tried, and what changed before it broke. Redact before you paste. SMTP AUTH exchanges and database connection strings both land in the logs verbatim. AUTH PLAIN and AUTH LOGIN arguments are base64, which is an encoding, not encryption, and anyone reading the thread can decode them. Replace passwords, API keys and connection strings with placeholders. Keep hostnames and IP addresses where you can, because they are usually the useful part. This forum is public and indexed. Downloads and release notes: https://www.progressiverobot.com/hmailserver-downloads/

hMailServer 6.3.3: outbound BDAT stalled every message over 60,000 bytes

Progressiverobot — Tue, 15 Sep 2026 00:59:03 GMT

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

hMailServer 6.3.2: a public resolver made SURBL tag every message with a link as spam

Progressiverobot — Sun, 13 Sep 2026 08:18:41 GMT

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

hMailServer 6.3.1: the installer is signed, and UpdateRequireAuthenticode works

Progressiverobot — Fri, 11 Sep 2026 03:40:03 GMT

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: the server runs on Linux, but not with per-domain DKIM signing

Progressiverobot — Thu, 10 Sep 2026 08:15:08 GMT

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

hMailServer 6.2.28: the server can verify and apply its own updates

Progressiverobot — Tue, 08 Sep 2026 07:30:02 GMT

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

hMailServer 6.2.27: a stripped DS record turned a signed zone unsigned

Progressiverobot — Mon, 07 Sep 2026 01:11:31 GMT

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

hMailServer 6.2.26: SQL Server Compact upgrades to schema 6030 reported as failed

Progressiverobot — Sun, 06 Sep 2026 19:48:24 GMT

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

hMailServer 6.2.25: ACME issuance and renewal terminated the server process

Progressiverobot — Sun, 06 Sep 2026 09:59:30 GMT

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