Skip to content
hMailServer Community Forum
hMailServer 6.3.3 — signed 15 September 2026, Windows and Linux, database schema 6040, and a drop-in upgrade from any 5.x install.Download 6.3.3 Documentation
  • P

    hMailServer 6.2.25: ACME issuance and renewal terminated the server process

    Announcements & releases release bugfix tls schema upgrade
    1
    0 Votes
    1 Posts
    0 Views
    P
    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". Before you upgrade 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
  • P

    hMailServer 6.2.22-pre1: the built-in ACME client never worked with Let's Encrypt

    Pre-release builds release prerelease tls imap schema
    1
    0 Votes
    1 Posts
    0 Views
    P
    The built-in ACME client has never completed an order against a real Let's Encrypt. If you issued certificates through hMailServer rather than an external client, it failed every time. That is fixed here (#34). Before you upgrade This is a pre-release. Take a backup before installing it. Databases upgrade automatically from schema 6012 to 6014 via the bundled DBUpdater. ACME (#34) Boulder, the software behind Let's Encrypt staging and production, pretty-prints its JSON: "type": "http-01", with a space after the colon. The challenge locator searched for the compact form, "type":"http-01", which can never match a real response. Every issuance failed at the first authorization with "Authorization offers no http-01 challenge". The locator now tolerates any whitespace and checks that the string is genuinely a type key's value, and the real CA response shape is pinned by self-tests. Failure messages now name the domain they concern, and the no-challenge refusal includes the CA's actual response. Log lines going missing (#33) With Keep log files open enabled, each line sat in a ~4 KB write buffer until later lines pushed it out. On a quiet server the tail of a session stayed invisible; the reporter measured forty minutes. The logger now hands every line to the operating system as it is written. Installations without the setting were never affected. Microsoft 365 Microsoft shuts off Basic authentication for SMTP relay in December 2026. XOAUTH2 bearer login is implemented for outbound relay and for POP3 collection from external accounts. Tokens use the client-credentials flow and are cached to 80% of their lifetime. Bearer auth applies only to destinations on the configured OAuth host list; unlisted relays keep password login unchanged. POP3 collection has no password fallback, deliberately. Sieve and IMAP Sieve now implements variables (RFC 5229), editheader (5293), duplicate (7352), reject/ereject (5429), include (6609), enotify (5435), date/currentdate (5260), spamtest (5235), mailboxexists and :regex. ManageSieve gains RENAMESCRIPT and machine-readable response codes. Eleven IMAP extensions, including APPENDLIMIT (7889), LITERAL- (7888), LIST-STATUS (5819), UNAUTHENTICATE (8437), QUOTA=RES-STORAGE (9208), PREVIEW (8970), MULTIAPPEND (3502), REPLACE (8508), SAVEDATE (8514, schema 6013) and METADATA (5464, schema 6014). The delivery client now opens with EHLO on every delivery, not just routes needing TLS or authentication, and declares SIZE (RFC 1870). Still unimplemented: BINARYMIME, IMAP BINARY, CATENATE/URLAUTH, COMPRESS=DEFLATE, OBJECTID and outbound PIPELINING/CHUNKING. Equal-preference MX records are still not randomised (RFC 5321 5.1). Full release notes, checksums and signatures
  • P

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

    Pinned TLS, certificates & deliverability acme lets-encrypt tls certificates
    1
    0 Votes
    1 Posts
    0 Views
    P
    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 [email protected] 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.<domain>, autoconfig.<domain> and autodiscover.<domain> 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 <DataFolder>/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
  • P

    hMailServer 6.0.0: the modernised baseline, and the build 4 installer fix

    Announcements & releases release installer tls dns windows
    1
    0 Votes
    1 Posts
    0 Views
    P
    6.0.0 is the first modernised release of the fork: 64-bit only, built with the VS2026 toolchain, with OpenSSL 4 and TLS 1.2 and 1.3 underneath. Build 4 is the production build, and it fixes the installer defect that made build 3 unusable on fresh installations. What the upgrade involved 6.0 was 64-bit only. The installer dropped the obsolete 2015-era UCRT, which had been included in Windows since Server 2016 / Windows 10. Upgrade notes and the full feature list are in the README. The installer fix Build 3 bundled VS2019-era VC++ runtime DLLs. The service loaded those instead of the current ones and crashed at startup with an access violation in msvcp140.dll on fresh installations. Build 4 ships the matching v145 (14.51) runtimes. Build 3 also fixed MySQL/MariaDB database creation, which was a script line-ending problem, and bundles libmysql.dll. What 6.0 brought OpenSSL 4, TLS 1.2 and 1.3 MTA-STS and DANE, with in-process DNSSEC validation ARC sealing and Ed25519 DKIM ACME (Let's Encrypt) built in REST admin API and Prometheus metrics IMAP MOVE, ID and SPECIAL-USE PBKDF2 password hashing The release was validated by the full regression suite: 898 of 898 tests passing, zero failures, run against a MariaDB (MySQL backend) instance, including live SpamAssassin, ClamAV with real EICAR detection, DMARC against live DNS, and TLS 1.2 and 1.3 end to end. Full release notes, checksums and signatures
  • P

    hMailServer 6.0.0-B1: first regression-validated build of the modernised 6.0 line

    Pre-release builds prerelease schema tls windows upgrade
    1
    0 Votes
    1 Posts
    0 Views
    P
    This is the first build of the modernised 6.0 line to clear the full regression suite: 898 tests, 895 passed, 0 code failures. What the upgrade involved Database version was 6001. Upgrade from 5.7 was supported via DBUpdater. Toolchain for this build: VS2026 (v145), OpenSSL 4.0.1, Boost 1.91, PostgreSQL 18.3 libpq, .NET Framework 4.8.1. What 6.0 brings in: MTA-STS and DANE/DNSSEC outbound TLS policy, TLS-RPT reporting, TLS 1.2/1.3 defaults. ARC sealing, DMARC, Ed25519 DKIM. ACME (Let's Encrypt) with auto-apply. REST admin API, and an Administrator dashboard with TOTP 2FA. MTA-STS, autoconfig and autodiscover hosting. Prometheus metrics and JSON logging. PBKDF2 password hashing with transparent rehash. IMAP MOVE, ID and SPECIAL-USE, plus 8BITMIME. Fixed in this build: a latent CStdStr::FormatV buffer-count bug that crashed the service. Validation ran with live SpamAssassin (JAM Windows build), ClamAV 1.5.2 and all optional features enabled. The three non-passing tests are environment-bound rather than code defects. Two require an unfiltered DNS resolver for SURBL test queries, and one requires the service-based SpamAssassin variant. Installation is via the installer, against the internal database (SQL CE 4.0) or an external MySQL, MSSQL or PostgreSQL instance. IMPLEMENTATION-NOTES.md carries the feature and INI reference. Licensed AGPLv3. Based on hMailServer by Martin Knafve. Full release notes, checksums and signatures