hMailServer 6.3.4

Re-published on GitHub on 18 October 2026 from the GitLab release v6.3.4 of 2026-09-27. Each file below was checked against the SHA-256 that GitLab's package registry records for it before it was uploaded here.

hMailServer 6.3.4

The largest release this project has made: everything from 15 to 27 September 2026 - calendars, contacts and
passkeys in the webmail, administrator roles and an audit trail, eDiscovery and legal holds, PST import, mailbox
encryption at rest, storage compression and object storage, event scripts on Linux - with a fix for a password
that could run code on a Windows server with JScript event scripts, and fixes for the 52 defects an audit of the
server found before this release. Most of what is new is off until you switch it on. 6.3.4 is also the first
release built after GitHub suspended the project's account, and it has to be installed by hand.

Before you upgrade

• The database moves from schema 6040 to 6104, in 64 one-way steps. Back up the database and the data
  directory first (Upgrading.md, Backup.md).
  Step 6101 adds two columns to the table that has a row for every stored message, which on a large store is not
  instant on every backend. On MySQL and MariaDB, step 6102 rebuilds every table as utf8mb4, which takes time on a
  large database. Steps 6041, 6101 and 6102 need MySQL 5.7.9 or MariaDB 10.2.2 or later and the ALTER privilege
  on the database; on an older server the upgrade stops at step 6041 with error 1071, having changed nothing. Two
  rows the old collation told apart and the new one does not - on MySQL 8.4, two names that differ only in an
  emoji; on MariaDB 11.8, two names in one address book that differ only where one has a German sharp s and the
  other an s - stop step 6102 with error 1062 until one of them is removed, and a step stopped part of the way is
  finished by running it again.

• Change hMailServer.ini's [Settings] after the upgrade, not to prepare it. From 6.3.4 the settings the
  database holds win over the file: at the first start, a line changed since the old server last started is taken
  for an edit and put back (HM5804).

• Install 6.3.4 by hand, on every server. Its installer carries an Authenticode signature but no Sigstore
  bundle: it was built and signed by hand, off GitHub, before the GitLab pipeline's release jobs have run. That
  pipeline is to sign the releases from 6.3.5. A server's live update, of any version, that is offered 6.3.4 says
  it "carries no Sigstore bundle for its installer, so it cannot be verified", and downloads nothing. On Windows run
  hMailServer-6.3.4-x64.exe. On Linux (x86-64 only) install the .deb with apt on Ubuntu 26.04, where it is
  built, or Ubuntu 24.04, or the .rpm with dnf on Fedora 43 or 44 or Enterprise Linux 10. The .deb asks for
  glibc 2.38 or later, so it does not install on Debian 12; the .rpm does not install on Enterprise Linux 9,
  whose glibc and libstdc++ are older than it asks for.

• Set again every password with a character above U+00FF. Before 6.3.4 a password of Cyrillic, Greek or CJK
  letters, say, was hashed over NUL bytes (Windows) or question marks (Linux), so any other password of its length
  and shape opened the account. 6.3.4 hashes over UTF-8 and refuses such a stored hash, to its own password too, on
  every password sign-in; the application log names the account when its user tries ("its stored password hash
  was made before 6.3.4 from a password with a character above U+00FF"). Set those passwords again soon after the
  upgrade - in the Control Panel, over COM or REST, and the administrator's own with
  hMailServer.exe --set-admin-password (hmailserver --set-admin-password on Linux); the webmail's own
  password change asks for the old password and is refused as a sign-in is. Until then a SCRAM-SHA-256 client
  that derives its key from those NUL bytes or question marks still opens a PBKDF2 one, and on Linux the password
  with ? for each of those characters still opens it on any path. A password whose characters are all in
  Latin-1 but not all ASCII signs in as before by PLAIN, LOGIN and the other password sign-ins, and the first such
  sign-in makes its hash again over UTF-8; until then it does not serve SCRAM-SHA-256. ASCII passwords are unchanged
  (SecretsAtRest.md, "A password outside Latin-1").

• A server on 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, then 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 6.3.4: once a release signed on GitLab exists, it
  would download that installer at every check and refuse it. Once 6.3.4 is installed the server reads that feed
  without being told; the line can then go, cleared in the Control Panel, with
  DELETE /api/v1/settings/ini/UpdateFeedUrl or, on Linux, with hmailserver --set-setting UpdateFeedUrl=, not in
  the file. 6.3.4 trusts both the old GitHub signer (for releases up to 6.3.3) and this project's GitLab pipeline - at
  the project's present path, and at the group hmailserver/hmailserver it is to move to, where the certificate
  must carry the project's id whatever the settings say - so from 6.3.5 its live update can work again, before the
  move and after it; a server left on 6.3.3 or older cannot install a GitLab-signed release by its live update
  unless it is given the override, on Windows only, and its costs, that the feed's document describes
  (UpdateFeed.md).

What changes without a switch, in short (the full list is the first part of 6.3.4's section in
CHANGELOG.md):

• The database becomes the settings store: the [Settings] section of hMailServer.ini is taken in at the
  first start, and from then on a line edited in the file is put back (HM5804). Change settings in the
  Control Panel, over COM or REST, or with hmailserver --set-setting on Linux.
• SPF is RFC 7208: mail from 127.0.0.0/8 and ::1 no longer passes unconditionally, so a content filter that
  hands mail back to the server should authenticate, or connect from an IP range with anti-spam off.
• The audit trail and the alerts are on (nothing is mailed until a recipient is set); compromised-account
  detection runs in watch mode; a destination that asks the server to slow down is paused.
• MySQL and MariaDB connections use TLS whenever the database server offers it, and SQL Server sessions are
  encrypted through the Microsoft OLE DB Driver 18 or later (MSOLEDBSQL) and, beside a failover partner, SQL
  Server Native Client (SQLNCLI), both without checking the certificate unless [Database] TlsMode=verify-full;
  through the older SQLOLEDB, used where that driver is not installed and no failover partner is set, only the
  login is encrypted unless TlsMode is require or verify-full
  (DatabaseTls.md).
• The administrator password is hashed again as PBKDF2 at the first sign-in; the installer had written an
  unsalted MD5.
• A one-time code is taken once, over COM and REST. A script that sent the administrator's password and a code
  with every REST request now signs in once (POST /api/v1/session) or uses an API key; otherwise only its first
  request in each half minute is accepted.
• A route or the SMTP relay whose host is on OutboundOAuth2Hosts sends the server's token (AUTH XOAUTH2) over
  TLS only: without TLS the delivery fails with a temporary 450 4.7.0, and HM5912 says to require TLS or
  STARTTLS.
• A COM change to a route, relay, DNS black list, SURBL server, remote-domain policy, server message, blocked
  attachment, SSL certificate or group is in effect only after Save(). Scripts that relied on the old way
  must save.
• IMAP follows the RFCs 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; the installer's 7-Zip is 26.03.
• A rule's Run function action must name a plain function; ISO-8859-1 mail is decoded as windows-1252.
• Addresses collected from what a person sends are suggestions, under Other contacts in the webmail, and CardDAV
  serves only the contacts a person kept.
• A domain may no longer be named as one of the directories the server keeps its own files in (protected,
  confidential, recoverable, discovery, quarantine, files, lists, blobs and the rest); one that
  already is is reported at every start as HM7597 and on the setup checklist: rename it
  (SetupChecklist.md).
• Only a new installation gets STARTTLS on 25, 587, 110 and 143 with a self-signed certificate, TLS
  required for sign-in from outside, the Windows service as NT SERVICE\hMailServer, and a stored-secrets
  key. An upgrade keeps its listeners, its service account and its secrets as they were; sealing the stored
  secrets starts once an administrator runs --create-stored-secrets-key, which the setup checklist offers
  (SecureDefaults.md,
  ServiceAccount.md, SecretsAtRest.md).

Security

• A password could run code inside the server. On Windows, with event scripting on, the language JScript
  and an OnClientValidatePassword handler, any client that could reach a sign-in and name an existing, active
  account could run JScript inside hMailServer.exe before authenticating - with the shipped ScriptAllowedObjects=*,
  any command the service's account may run. A remote POP3 server's UID (OnExternalAccountDownload) and a
  remote mail server's error text (OnDeliveryFailed) reached the same flaw on servers with those handlers,
  and a rule's Run function name, which anyone who may edit rules sets, reached it in either language.
  VBScript servers were not open through a password, a UID or an error text, and the Linux builds had no
  script engine. The code was in every release from 6.0.0 to 6.3.3; 6.3.4 fixes it. It is
  CVE-2026-100741. Until you can upgrade a JScript server, switch event scripting off; or take those three handlers
  out of EventHandlers.js, reload the scripts, and let nobody but the server administrator make or edit a rule
  with a Run function action, which is open in VBScript too
  (EventScripts.md).
• 52 defects found by an audit before this release, fixed. The audit read SMTP and the sign-ins, IMAP,
  HTTP and the REST API, identity, cryptography, outbound connections, files and personal data, and the
  database, and confirmed 52 defects, 8 of them rated high. Many were in code new in this release, which no
  released version carried. Among those 6.3.3 had too: SCRAM-SHA-256 accepted the account's own password where a
  second factor or an expired password should have refused it; two IMAP sessions changing one message's keywords
  could corrupt the heap and end the service, and two changing its flags could lose one of the changes; an IMAP
  APPEND whose client went away before its last line left a message file no quota counted, which an
  authenticated user could repeat until the volume was full; and an app password could read the account's S/MIME
  keys, wrapped under the account password, and replace them. On a server that collects Microsoft 365 mail with
  its own OAuth2 app token, a domain administrator could, over COM since 6.2.23 Alpha 1, add a fetch account that
  copied - and could delete - any mailbox that token reaches. Each fix is under "Fixed" in the CHANGELOG; where one
  left a limit - journal rules and the mail the server queues itself, SCRAM-SHA-256 and the password script hook -
  it is under Known issues below.
• Seven defects GitLab's SAST analyzer found, fixed: the crash-dump helper loaded dbghelp.dll by name, so
  a copy put in Bin would have run under the service's account at the next crash; the Control Panel's elevated
  service restart started cmd.exe by name, which Windows looks for in the working directory first; the
  installer handed the administrator password to DBSetupQuick.exe, and it to DBUpdater.exe, unquoted on their
  command lines, where it is now handed on in the environment (HM_ADMIN_PASSWORD); a backup index cut short or
  altered was read past its end on restore, in two places; and a test of the MIME parser compared pointers into
  two different arrays. Found beside them and fixed too: a custom virus scanner whose command line holds a bare
  %FILE% was handed the message's path cut at its first space - the default data directory has one - so it
  scanned nothing and the message was delivered as clean. Every other High finding of the analyzer was read and is
  accepted, with the reason it is not exploitable, in .gitlab/security-exceptions.yml on master.
• This release was held by its security scans. It was published only once build/ci/security-gate.py had
  passed the scans of its commit - cppcheck and clang-tidy, Semgrep, GitLab's semgrep analyzer and the
  dependency scan (Trivy and OSV) - run by hand on the project's Linux machine, as the release job is to run them
  from 6.3.5 (SECURITY.md, "Before a release").

Highlights

• 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
  (SendGrid-style inbound parse).
• 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, OpenPGP in the browser, and a folder of a hundred thousand messages listed,
  searched and selected in bounded steps.
• Identity: administrator roles, passkeys, OpenID Connect and SAML sign-in, SCIM provisioning,
  self-service password reset, sessions and devices, 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, an erasure that
  reaches the stores beside the mailbox, settings at server, domain and account level, profiles, hmctl and a PowerShell module,
  a setup checklist, and help beside every page.
• Migration: resumable migrations from IMAP, Google Workspace and Microsoft 365, and PST import, whose
  reader runs in a process of its own.
• Operations: storage compression and attachment de-duplication, object storage (S3 or Azure Blob),
  encrypted backups, upgrades that apply the schema at start, event scripts on Linux in JavaScript, SNMPv3,
  syslog, webhooks and per-domain reports.

Everything is in CHANGELOG.md, with the operator document for each item.

The project, off GitHub

• The project's home is GitLab: https://gitlab.com/Progressiverobot/hmailserver, with issue templates for
  a bug, a feature, a question and a security report, and a Service Desk address for anyone without a GitLab
  account (README). Every release
  up to 6.3.3 is re-published there, with its files byte for byte but for 6.2.0 and 6.0.0-B4, whose files were not
  preserved. The releases are an Atom feed,
  https://gitlab.com/Progressiverobot/hmailserver/-/releases.atom.
• 6.3.4 was built and released by hand. From 6.3.5 a release is to be made by the project's GitLab pipeline,
  from a protected release tag that only the owner may create, signed with the one key in
  .gitlab/allowed_signers on master, and held while the security scans of the tagged commit find something
  the policy counts that is not accepted: the installer built on the project's Windows runner after the whole
  suite has passed there, Authenticode-signed through Azure Artifact Signing and given its own SBOM, every file
  signed with Sigstore, each signature checked with the server's own --verify-update, then, once the installer
  smoke test has passed and the owner has started the last job, the release published and the update feed
  refreshed. None of the release jobs has run yet
  (RELEASE.md).
• From the first landing after 6.3.4, changes reach master through GitLab merge requests, by fast-forward
  once the branch's pipeline has passed, with every commit signed off (Signed-off-by) and the merge approved by
  somebody other than its author, unless the owner overrides that for one landing, which is recorded
  (ContinuousIntegration.md, "Landing on master").
• An SBOM for every compiled file: from 6.3.4 each installer and package a release carries has its own
  CycloneDX document beside it (below), and the five GitLab releases before 6.2.3 that carry an installer -
  6.0.0-B1, 6.0.0, 6.1.0, 6.2.1 and 6.2.2 - carry one too since 26 September 2026, made from each installer
  (SECURITY.md, "Supply chain").
• The PKGBUILD, the Helm chart, the Compose file and the winget and Chocolatey templates point at GitLab
  (the winget and Chocolatey manifests are not in the public repositories yet), and the container image's name is
  registry.gitlab.com/progressiverobot/hmailserver (see Known issues).

Downloads

• hMailServer-6.3.4-x64.exe - the Windows x64 installer, Authenticode-signed by Progressive Robot Ltd through
  Azure Artifact Signing.
• The Linux packages for x86-64 only: hmailserver_6.3.4_amd64.deb and hmailserver-6.3.4-1.x86_64.rpm.
  This release has no AArch64 packages, since the project has no ARM machine to build them on, and no AppImage,
  which the pipeline does not build yet.
• Each of those three files with its own SBOM, <file>.cdx.json (CycloneDX 1.6), and the source tree's,
  hmailserver.spdx.json and hmailserver.cyclonedx.json.
• hmailserver-6.3.4-SHA256SUMS.txt, the SHA-256 of each file above, and its SSH signature,
  hmailserver-6.3.4-SHA256SUMS.txt.sig. There is no Sigstore bundle.

The newest stable release's files are also at fixed addresses that never lead to a pre-release:
https://updates.progressiverobot.com/download/hMailServer-x64.exe, /download/hmailserver_amd64.deb and
/download/hmailserver.x86_64.rpm, and /download/ for that release's page
(UpdateFeed.md).

File	Size	SHA-256
hMailServer-6.3.4-x64.exe	87,588,616	843cb07b753f8d3d764b3120029e47ea407aa6874468cb3351a06777e3f2310f
hMailServer-6.3.4-x64.exe.cdx.json	43,848	b5c2737783e1e043eeca4550b8ea43c1faa9e76ee0e969bc70b9bc92baad329e
hmailserver-6.3.4-1.x86_64.rpm	11,040,352	4a95ea10406a1379f755594d13e6c2b83dd7d629a737090894d32904ee9274d9
hmailserver-6.3.4-1.x86_64.rpm.cdx.json	20,926	7eaf06d20bef6c86bf47cb1c9c3eb98d7eb17d8f702b1a3b316df70f7959cbef
hmailserver-6.3.4-SHA256SUMS.txt	774	19d46c141216528fc1a3977a2112990757005671981a72b45b3931ad66d752dd
hmailserver-6.3.4-SHA256SUMS.txt.sig	294	446c6981071d288e4481d81ae70bf1051b7d1383d515cc80d8c23b2fe583fce9
hmailserver.cyclonedx.json	388,598	7b8720b256fe9eefe5f371fbcc8d1e2c4c572b29d7698e04cb7d959089517832
hmailserver.spdx.json	581,935	323e56c4f2963d32415d2121260b299e76f899d5da31e1543ef9d2c6c62b811b
hmailserver_6.3.4_amd64.deb	15,198,938	4a08461e536effbc991ddb081cf7601df47e3f079e2b3ed0a6fca09f8d9e16e6
hmailserver_6.3.4_amd64.deb.cdx.json	12,557	0be862311ff316be8fdcf3f40ca7f4e260cac2913d2a83fabc12289931c151ab

Every file is in this project's package registry, as hmailserver 6.3.4; hmailserver-6.3.4-SHA256SUMS.txt lists the SHA-256 of every file above but itself and its signature, hmailserver-6.3.4-SHA256SUMS.txt.sig.

Verification

On Windows, Get-AuthenticodeSignature .\hMailServer-6.3.4-x64.exe should answer Valid, signed by
CN=Progressive Robot Ltd. This release has no Sigstore bundle; compare each file's SHA-256 with the list
below. The list is also the file hmailserver-6.3.4-SHA256SUMS.txt, signed with the SSH key that signs the
release tags as hmailserver-6.3.4-SHA256SUMS.txt.sig. With OpenSSH 8.1 or later, and
.gitlab/allowed_signers
as the tag has it saved as allowed_signers:

ssh-keygen -Y verify -f allowed_signers -I christopher.j.holloway@outlook.com -n file \
  -s hmailserver-6.3.4-SHA256SUMS.txt.sig < hmailserver-6.3.4-SHA256SUMS.txt
sha256sum --ignore-missing -c hmailserver-6.3.4-SHA256SUMS.txt

The first must say Good "file" signature for christopher.j.holloway@outlook.com. In a clone, the tag itself
verifies against the same file: git -c gpg.ssh.allowedSignersFile=.gitlab/allowed_signers verify-tag v6.3.4.

The SHA-256 of every file, as hmailserver-6.3.4-SHA256SUMS.txt gives them:

843cb07b753f8d3d764b3120029e47ea407aa6874468cb3351a06777e3f2310f  hMailServer-6.3.4-x64.exe
b5c2737783e1e043eeca4550b8ea43c1faa9e76ee0e969bc70b9bc92baad329e  hMailServer-6.3.4-x64.exe.cdx.json
4a95ea10406a1379f755594d13e6c2b83dd7d629a737090894d32904ee9274d9  hmailserver-6.3.4-1.x86_64.rpm
7eaf06d20bef6c86bf47cb1c9c3eb98d7eb17d8f702b1a3b316df70f7959cbef  hmailserver-6.3.4-1.x86_64.rpm.cdx.json
7b8720b256fe9eefe5f371fbcc8d1e2c4c572b29d7698e04cb7d959089517832  hmailserver.cyclonedx.json
323e56c4f2963d32415d2121260b299e76f899d5da31e1543ef9d2c6c62b811b  hmailserver.spdx.json
4a08461e536effbc991ddb081cf7601df47e3f079e2b3ed0a6fca09f8d9e16e6  hmailserver_6.3.4_amd64.deb
0be862311ff316be8fdcf3f40ca7f4e260cac2913d2a83fabc12289931c151ab  hmailserver_6.3.4_amd64.deb.cdx.json

Reproducible build. hMailServer.exe was built twice from clean at v6.3.4 (commit 51e2dbda08d6aa7fcda5a48f1af05221809f78be), and the two builds were byte-identical: SHA-256 d18edf6f82b874e7e1d25dd9cbb4f4162956c106ac263dc4a92a991d1fb71b4c, 40,067,584 bytes, built with MSBuild 18.9.1+a81b4352504b9e097b512a9d615e8c56d013f595, MSVC tools 14.51.36231, the v145 toolset and Windows SDK 10.0.26100.0. The installer carries that file as built; only the installer itself is signed. Anyone with the same toolchain and library layout can build the tag and compare.

Linux. The .deb and the .rpm were built from the tag in the CI image hmailserver-ci/linux:26.04-dad0ab749505, with SOURCE_DATE_EPOCH set to the tag commit's own time (1790467550). The server binary as built, before CPack strips it for the packages, has SHA-256 e8a4d05590cf3434eec6a0b8e178a06efc53e46fee973a753e3e17561dea02b5.

Fuzzing. Fuzzed on 2026-09-27 in hmailserver-ci/linux:26.04-dad0ab749505 at v6.3.4: mime_message_fuzzer, mime_header_fuzzer and mime_decode_fuzzer, 30 minutes each with 2 workers, after replaying the committed reproducers in fuzz/regression and the seeds made from the test messages; 32524829 executions in all (mime_message_fuzzer 1161842, mime_header_fuzzer 1139248, mime_decode_fuzzer 30223739); nothing found.

Software bills of materials. Each compiled file has its own, in CycloneDX 1.6, named after it: hMailServer-6.3.4-x64.exe.cdx.json, hmailserver_6.3.4_amd64.deb.cdx.json and hmailserver-6.3.4-1.x86_64.rpm.cdx.json. Its subject (metadata.component) is that file by its SHA-256, and it lists what the file holds and needs: for the installer, the libraries the server is linked against, every third-party file it packs with its pinned SHA-256, and the tools' NuGet packages; for a package, the distribution libraries with the version it was built against, and what is linked into it. hmailserver.spdx.json and hmailserver.cyclonedx.json describe the source tree. To check that an SBOM describes your download, compare jq -r '.metadata.component.hashes[] | select(.alg == "SHA-256") | .content' <file>.cdx.json with sha256sum <file>; the SBOMs are in hmailserver-6.3.4-SHA256SUMS.txt with every other file.

Known issues

• No live update installs 6.3.4, as above. On a server whose service runs as NT SERVICE\hMailServer, the
  live update will not apply later releases either: an administrator runs the installer
  (ServiceAccount.md). The GitLab signers 6.3.4 trusts are compiled in:
  the present path's is proved only when 6.3.5 is signed, and the group's only after the project has moved.
• No container image of 6.3.4. The images on ghcr.io answer 404 since the suspension, and the Compose
  file and the Helm chart name registry.gitlab.com/progressiverobot/hmailserver, which is empty. The release
  pipeline pushes and signs the image from the first release after the project's move to the group
  hmailserver and the owner's switch, because GitLab.com cannot move a project whose registry holds an image.
• Linux is x86-64 only in this release: no AArch64 .deb or .rpm and no AppImage, as under Downloads.
  Both packages are built on Ubuntu 26.04 (above); there is no apt or dnf repository yet
  (PackageManagers.md).
• Windows on ARM is compiled but not run: the ARM64 build was first compiled on 26 September 2026, on an x64
  machine, and nothing of it has run, since the project has no ARM64 hardware; this release has no ARM64
  installer (WindowsOnArm.md).
• No published performance numbers yet: the load generator and the lab recipe are in the tree, and the
  tables in PublishedNumbers.md and
  Performance.md are still to be measured, as is the saving storage
  compression makes.
• imaptest: 4 of its 71 scripts still fail - \Recent in FETCH FLAGS, the zone of an APPEND's
  INTERNALDATE, \NonExistent, and MIME boundary padding.
• Mailbox encryption at rest has no webmail card and no Control Panel page, and a search in an encrypted
  mailbox reads every message. Object storage: Message.Filename over COM names the local path the message would have, where no file is once
  it has been moved into the store; read the message through the API.
• PST import refuses the 4K-page layout, files under Windows Information Protection and OSTs that cache an
  Exchange mailbox. eDiscovery exports EML and mbox, not PST, up to 4 GB, and downloads an export only up to 500 MB; a larger
  one is left on the server's disk.
• SCRAM-SHA-256 does not consult the OnClientValidatePassword script hook, which has no password to be
  given in SCRAM.
• Journal rules do not see mail the server queues itself: the webmail's, a send-later draft, an event
  script's, a rule's forward, copy or reply, an automatic reply, a Sieve redirect, an account's forwarding and a
  delivery report (Journaling.md).
• The installer's own /adminpassword= switch is on its command line, where anybody listing processes can read
  it, and cannot carry a double quote; an unattended install can give the installer the password in
  HM_ADMIN_PASSWORD instead, set in an elevated prompt
  (Upgrading.md).
• The SNMP agent's enterprise number is RFC 5612's documentation number, not one registered to this project.
• The security scans on the project's own CI runners hold a release, not a change: they do not stop a push's
  pipeline yet, and the static analysis still reports findings not yet read into its baseline. GitLab's secret
  detection, on its shared runners, is to fail a pipeline on a finding, but has not run there yet, since
  master is still pushed without a pipeline; a secret is refused before the push instead, by the maintainer's
  landing and by the repository's hooks in a clone that turns them on. Renovate waits for its token.