hMailServer

The repository's GitHub Actions default workflow token permission is read-only (verified via API: gh api repos/Progressiverobot/hmailserver/actions/permissions/workflow returns default_workflow_permissions=read), so any CI/CD task with no permissions specified receives a read-only GITHUB_TOKEN — the lowest default. In addition, all 10 workflows on master declare an explicit top-level permissions block: nine are read-only or empty (contents: read; contents: read + actions: read; read-all; {}), and upstream-watch.yml adds issues: write at workflow level, needed by its single job to file upstream-tracking issues. Other write scopes are granted per job only where required: id-token: write and contents: write in sign-release.yml's signing job (keyless cosign signing and asset upload), security-events: write for CodeQL and Scorecard SARIF upload (Scorecard also id-token: write), contents: write in the SBOM job to attach release assets, and pull-requests: write in dependency-review. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows

Every release is assigned a unique SemVer-style tag: v6.2.2 through v6.2.21 for stable releases, with pre-releases distinguished by suffix (v6.2.22-pre1..pre6, v6.2.23-alpha1). 25+ releases enumerated via the GitHub API each carry a distinct tag_name, and an active 'Protect release tags' ruleset protects the tags after publication. See https://github.com/Progressiverobot/hmailserver/releases

Each GitHub Release carries thorough, human-written notes describing functional and security modifications. v6.2.21's body is ~11.8 KB; v6.2.23-alpha1's notes describe new features, breaking changes (database schema 6022->6025), security-relevant fixes (a path silently losing mail, a COM vtable compatibility break, an installer hang), and upgrade cautions with backup instructions. Release notes name CVEs where relevant (e.g. the CVE-2023-51764 SMTP-smuggling rule). The notes are not placed under a literal '## Changelog' header, which the criterion recommends but does not require. See https://github.com/Progressiverobot/hmailserver/releases

.NET dependencies are ingested with standard tooling: CI runs 'dotnet restore' (NuGet) on ControlPanel.csproj and the Tools solution (ci.yml), and Dependabot manages the nuget and github-actions ecosystems weekly (.github/dependabot.yml); GitHub Actions are pinned by commit SHA. The native C++ dependencies (OpenSSL, Boost, libpq) have no ecosystem package manager in this project's MSVC flow — they are built from pinned source versions per documented steps under %hMailServerLibs% — and every binary committed to the tree is SHA-256-inventoried in hmailserver/docs/third-party-binaries.json, enforced by the verify-binary-provenance workflow. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/dependabot.yml

Since v6.2.19, every release asset is signed at release time with Sigstore cosign (keyless): sign-release.yml runs 'cosign sign-blob --bundle' over each release asset, verifies each bundle with 'cosign verify-blob' pinning the signing workflow identity before upload, and attaches a .cosign.bundle per asset. The latest stable release v6.2.21 and latest prerelease v6.2.23-alpha1 each ship the installer plus SPDX and CycloneDX SBOMs, each asset with its own .cosign.bundle. User-facing verification commands are documented in the workflow header. Releases prior to v6.2.19 predate the signing process and are unsigned. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/sign-release.yml

Dependency handling is documented publicly: README's third-party libraries section explains how OpenSSL 4.0.x, Boost 1.91 and PostgreSQL 18 libpq are obtained and built at pinned versions under %hMailServerLibs%; .github/dependabot.yml states the tracking policy (NuGet and GitHub Actions updated weekly via Dependabot; native C++ libs tracked manually since Dependabot has no C++ ecosystem); and hmailserver/docs/ThirdPartyBinaries.md records, for each of the 40 committed binaries, what it is, where it came from, why it is present and whether it should be, with SHA-256s in third-party-binaries.json enforced by CI. SBOMs ship with each release. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/ThirdPartyBinaries.md

README.md has a contents-linked 'Building hMailServer' section covering prerequisites (Visual Studio 2026 / v145 toolset with the required workloads, Inno Setup 6, Perl, Python), step-by-step instructions for building the external libraries (OpenSSL via nmake, PostgreSQL libpq via meson, Boost via b2) under %hMailServerLibs%, and building the server, tools and installer via the build*.ps1 scripts or MSBuild, including a warning about build events on machines running a production instance. .github/CONTRIBUTING.md summarizes the same and points back to the README. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md#building-hmailserver

The project has exactly one member with access to sensitive resources, and he is documented by name and handle on master: README states the fork 'is maintained by Christopher Holloway / Progressive Robot Ltd'; .github/CODEOWNERS lists @chrisholloway5 as owner of every path, explicitly enumerating the sensitive ones (CI workflows, release/signing files, committed third-party binaries, TLS/crypto code); SECURITY.md states it is a single-maintainer project. PR #40's GOVERNANCE.md will restate this as a formal member list once merged. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CODEOWNERS

GOVERNANCE.md documents the project roles and their responsibilities: the Maintainer role (accepting changes, releasing per RELEASE.md, security response per SECURITY.md, direction via Roadmap.md, custody of critical credentials), the Contributor role (expectations set by CONTRIBUTING.md), and the Reporter role (SUPPORT.md / SECURITY.md paths). Who currently holds each role is stated by name. See https://github.com/Progressiverobot/hmailserver/blob/master/GOVERNANCE.md

.github/CONTRIBUTING.md on master sets requirements for acceptable contributions: coding standards (code must build warning-free under /WX; parameterised SQL exclusively, never manually built SQL strings; new optional server features follow the INI-settings pattern), testing requirements (all changes must keep the regression suite green; add or update regression tests for behavior changes), submission guidelines (branch from master, one logical change per PR), architectural guidance on the BO/Persistence/COM layering, and licensing terms (contributions licensed under AGPLv3). See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md

There is no DCO status check or CLA. The repository is hosted on GitHub, and this criterion's guidance explicitly accepts the platform's terms of service: GitHub's Terms of Service (section D) require every user, on every contribution, to represent that they have the right to post the content, and license inbound contributions under the repository's license. All contributions arrive through GitHub (a sole maintainer plus Dependabot). CONTRIBUTING.md additionally states 'By contributing you agree that your contributions are licensed under the AGPLv3'. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md

The CI workflow (.github/workflows/ci.yml) triggers on every push and pull request to master and runs an automated test suite: 'dotnet test' on ControlPanel.Tests with cobertura coverage, plus a generated-code drift check and -warnaserror builds. Results are publicly visible in the Actions tab, and contributors can run the same tests locally (dotnet test; build/build-tests.ps1 and build/run-tests.ps1 are documented in CONTRIBUTING.md). Pull requests are tested before merge; every commit reaching master is tested by the same pipeline. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/ci.yml

ARCHITECTURE.md at the repo root is a maintained 218-line design document describing the system's components and how they interact: the C++ server modules (SMTP/IMAP/POP3, delivery queue, anti-spam/anti-virus, persistence layering BO->Persistence->SQL with caches over four database backends), the COM/IDispatch API as the management seam used by the Control Panel, the test suite and third-party scripts, the optional listeners (REST, metrics, web services, ManageSieve) with their threading and TLS behavior, the scheduler, and external actors such as ClamAV, SpamAssassin, DNS and the databases. It records interaction constraints and is kept current. See https://github.com/Progressiverobot/hmailserver/blob/master/ARCHITECTURE.md

README.md documents all external interfaces of the released software: SMTP, IMAP and POP3 with per-extension RFC citations; SASL mechanisms (SCRAM-SHA-256/-PLUS); Sieve plus the ManageSieve (RFC 5804) listener with its command set; the REST administration API with its complete endpoint list (/api/v1/status, domains, accounts, queue, apikeys, tlsa) and authentication model (administrator password or scoped API keys); the Prometheus /metrics endpoint with metric names and the /livez, /readyz, /healthz probes; OTLP trace/metrics/logs endpoints; the COM/IDispatch API; and the hMailServer.ini configuration surface. ARCHITECTURE.md describes the COM API's role as the management seam. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md

ASSURANCE-CASE.md is the project's documented security assessment: a threat model with actors and principal attack surfaces, trust boundaries B1-B6, security claims C1-C7 argued with evidence, CWE-mapped analysis of how common implementation weaknesses are countered, and a residual-risk list. It is supported by continuous tooling on master: CodeQL on every push and pull request, OpenSSF Scorecard, and a libFuzzer harness suite under fuzz/. See https://github.com/Progressiverobot/hmailserver/blob/master/ASSURANCE-CASE.md

SECURITY.md (in .github/, shown on the repo's Security tab) is a full coordinated vulnerability disclosure policy with explicit timeframes: acknowledgement within 5 working days, initial assessment (reproduction or request for more information) within 10 working days, and a fix for a confirmed vulnerability within 90 days of acknowledgement. It commits to coordinated disclosure on a 90-day timetable (advisory published when the fix ships or at 90 days, whichever is first), asks reporters to flag earlier disclosure intentions, states the credit policy, and defines in-scope and out-of-scope report classes. Verified on master. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md

Private vulnerability reporting is enabled on the repository (verified via the GitHub API), and SECURITY.md directs reporters to the private channel with a direct link to https://github.com/Progressiverobot/hmailserver/security/advisories/new, explicitly instructs against public issues, discussions, PRs or forum posts for security problems, and provides a fallback: a reporter who cannot use GitHub Security Advisories may open an issue containing no technical detail asking for a private channel, and the maintainer will open an advisory and invite them. Reports go directly to the maintainer, who is the security contact. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md

The project publishes vulnerability data through GitHub Security Advisories and release notes. SECURITY.md commits that once a fix is available it ships as a new build and the advisory is published with a CVE requested through GitHub, on a 90-day coordinated-disclosure timetable. To date no vulnerability has been discovered in this fork, so the public advisory list is empty (verified via the GitHub API: zero published advisories, none withheld); where upstream CVEs are relevant the release notes name them explicitly (e.g. CVE-2023-51764 SMTP smuggling, whose mitigation is enforced and pinned by a regression test). See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md