hMailServer

The repository is git, a distributed version control system, hosted on GitLab: https://gitlab.com/Progressiverobot/hmailserver

Small, bounded tasks for new or casual contributors carry the 'good first issue' label on the GitLab tracker, and each says where to look, how to check it and what done means (CONTRIBUTING.md, 'Small tasks'). Two are open today, #18 and #26. https://gitlab.com/Progressiverobot/hmailserver/-/issues/?label_name%5B%5D=good%20first%20issue

The project requires two-factor authentication of every account that can change the central repository or read private vulnerability reports, and each has it on. Those accounts are the three members of the GitLab project: Progressiverobot, the Owner and the only account that may push master, batch* branches or v* tags; and zainulabidin1990 and chrisholloway5, Developers, who can push other branches and read confidential issues. GOVERNANCE.md names who holds each role: https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md

The project's accounts authenticate on GitLab, whose two-factor authentication offers only cryptographic mechanisms: a TOTP authenticator app or a WebAuthn device or passkey. SMS is not offered, so the 2FA in use cannot be SMS.

CONTRIBUTING.md (Merge requests, Change checklists) says how review is done: the maintainer reads the change, asks for changes on the merge request, and runs the full Windows regression gate before anything lands. The merge request template lists what a change must meet: a /WX build, a regression test (for a fix, one that fails before it), parameterised SQL, the schema and settings checklists, licence headers and regenerated files. RELEASE.md step 2 adds an adversarial review of the whole diff before each release. GitLab has no approval rule configured. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests

One active maintainer lands changes, and GitLab has no approval rule configured on the project (CONTRIBUTING.md, 'Merge requests'). Changes are reviewed adversarially by AI agents and held by fixture tests and the full regression gate before they land, but that is not review by a second person, so fewer than half of the changes are reviewed by someone other than the author. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests

Builds repeat on one machine (build_repeatable), but nobody has independently rebuilt a release to the same bytes. RELEASE.md step 8 says what that needs: the same toolchain (v145, Windows SDK 10.0.26100) and library layout. Release integrity rests on Authenticode signatures and, through 6.3.3, Sigstore bundles; 6.3.4 carries Authenticode only. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/RELEASE.md

The Linux suite and the .NET unit tests run with the language's standard command, dotnet test (for example dotnet test hmailserver/test/LinuxRegressionTests -c Release). The Windows suite, which needs the service registered on a bench, runs under NUnit's console runner through build\run-tests.ps1, as CONTRIBUTING.md's Testing section documents. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#testing

Changes are integrated on batch branches and fast-forwarded to master, and every batch lands only after the maintainer's own full regression gate on the result: the whole Windows suite split across two machines, plus the whole Linux suite. .gitlab-ci.yml defines the same builds and suites on the project's own runners (linix, bench150) for master, batch* and v* tags, but no full pipeline has run on GitLab yet (issue #21); until 18 September 2026 GitHub Actions ran them. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md

The only measured figure is 73.48% of the native server's lines over the whole Windows regression suite (OpenCppCoverage 0.9.9, 15 September 2026), below 90%. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md

Branch coverage is not measured. The native server's coverage was measured once, on 15 September 2026, with OpenCppCoverage 0.9.9, which has no branch mode, so only a line figure exists (73.48%); FLOSS tools that measure branches exist (clang's source-based coverage), so N/A does not apply. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md

SMTP, IMAP and POP3 support STARTTLS and implicit TLS. A new installation gets a certificate, offers STARTTLS on 25, 587, 110 and 143, and requires TLS for authentication from the Internet (SecureDefaults.md); a database that is upgraded or attached keeps its previous settings. The REST API (bound to 127.0.0.1) and the web-services listeners are off by default. The SNMP agent is off by default and speaks SNMPv3 authPriv, with v2c a separate opt-in. Outbound delivery supports DANE, MTA-STS and per-domain TLS policy. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/SecureDefaults.md

TLS 1.2 and 1.3 are the versions a new database enables (SslVersions 24). SSLv2 and SSLv3 cannot be enabled, and TLS 1.0 and 1.1 only by an explicit setting. The regression suite runs TLS 1.2 and 1.3 handshakes (RegressionTests/SSL/SslTlsVersionTests.cs). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/SslContextInitializer.cpp

The repository and download site, gitlab.com, sends Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff and X-Frame-Options: SAMEORIGIN. The project page https://www.progressiverobot.com/hmailserver-services/ sends all four, with HSTS preload and includeSubDomains; both were checked on 26 September 2026. https://gitlab.com/Progressiverobot/hmailserver

The maintainers reviewed the current codebase's security in 2026, and the review is documented in ASSURANCE-CASE.md, written in August 2026 and last revised on 25 September 2026. It covers the security requirements (claims C1-C7), the threat model and the security boundary (trust boundaries B1-B6), the design argument, a CWE-mapped weakness analysis and the residual risks. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md

The Windows server is built with the MSVC hardening defaults left on (/GS, DEP, ASLR) and with Control Flow Guard (/guard:cf) in every configuration of hMailServer.vcxproj. The web pages it serves send Content-Security-Policy and X-Frame-Options: DENY, and unsafe password-hash schemes are refused for new secrets. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/hMailServer/hMailServer.vcxproj

Before each minor release, RELEASE.md step 8c fuzzes every libFuzzer harness of the MIME parser, under AddressSanitizer, for 30 minutes on the release source, and the release notes record the run (6.3.0 and 6.3.2; a patch release with no parser change cites the previous run, as 6.3.1 did). Step 8b also runs the whole regression suite on the assertion build. https://gitlab.com/Progressiverobot/hmailserver/-/releases/v6.3.2

RELEASE.md step 8b runs the whole regression suite on the assertion build (build.ps1 -Configuration Release -Asserts), which keeps every HM_ASSERT; a violated assertion is logged as HM6364 and fails the test. That build is never shipped. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/RELEASE.md