BadgeApp

Basics

General

What is the human-readable name of the project?
Note that other projects may use the same name.

What is a brief description of the project?

hMailServer is a free, open source email server for Microsoft Windows, implementing SMTP, IMAP and POP3. This is a maintained fork brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

What is the URL for the project (as a whole)?
https://www.progressiverobot.com/hmailserver-services

What is the URL for the version control repository (it may be the same as the project URL)?
https://github.com/Progressiverobot/hmailserver

What license(s) is the project released under?
Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.

What programming language(s) are used to implement the project?
If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".

What is the Common Platform Enumeration (CPE) name for the project (if it has one)?
The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.

Other general comments about the project:

Controls 22/24 ●

Controls

Criterion [OSPS-AC-01.01]
Met

Unmet

N/A

?

When a user attempts to read or modify a sensitive resource in the project's authoritative repository, the system MUST require the user to complete a multi-factor authentication process. ^{[OSPS-AC-01.01]}
Enforce multi-factor authentication for the project's version control system, requiring collaborators to provide a second form of authentication when accessing sensitive data or modifying repository settings. Passkeys are acceptable for this control.

The only account able to modify the repository or read sensitive data is the maintainer (chrisholloway5, repository admin); the one other collaborator holds read-only access. The maintainer confirms a cryptographic second factor (authenticator app / passkey) is enabled on that account, and GitHub enforces the MFA challenge at authentication time. GitHub has additionally required 2FA for active code contributors platform-wide since 2023. Enabling the org-wide 2FA requirement is planned so the policy is enforced by setting rather than by practice. See https://github.com/Progressiverobot/hmailserver/settings/access

Criterion [OSPS-AC-02.01]
Met

Unmet

N/A

?

When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default. ^{[OSPS-AC-02.01]}
Most public version control systems are configured in this manner. Ensure the project's version control system always assigns the lowest available permissions to collaborators by default when added, granting additional permissions only when necessary.

The project uses GitHub, which never grants write access automatically: adding a collaborator requires a manual invitation with an explicitly chosen permission level. The Progressiverobot organization's default repository permission for members is 'read' (verified via the GitHub API on 2026-08-21), so any new member receives the lowest available privilege unless a maintainer manually grants more. The repository currently has a single human committer (chrisholloway5) plus dependabot[bot]; no collaborator holds unreviewed elevated access. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-AC-03.01]
Met

Unmet

N/A

?

When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied. ^{[OSPS-AC-03.01]}
If the VCS is centralized, set branch protection on the primary branch in the project's VCS. Alternatively, use a decentralized approach, like the Linux kernel's, where changes are first proposed in another repository, and merging changes into the primary repository requires a specific separate act.

An active branch ruleset ('Protect master: changes arrive by pull request') now enforces that changes to master arrive via pull request, and additionally blocks branch deletion and force pushes. Repository administrators hold a logged bypass — every bypass is recorded and visible in the ruleset insights — so the enforcement mechanism exists for all contributors while the sole maintainer's release workflow continues. Release tags are protected by a second, separate ruleset. See https://github.com/Progressiverobot/hmailserver/rules

Criterion [OSPS-AC-03.02]
Met

Unmet

N/A

?

When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent. ^{[OSPS-AC-03.02]}
Set branch protection on the primary branch in the project's version control system to prevent deletion.

master is the repository's default branch (verified via the GitHub API), and GitHub refuses deletion of the default branch outright: a push deleting it is rejected server-side ('refusing to delete the current branch'), the web UI offers no delete control for it, and the REST API returns an error. Deleting master would first require an administrator to deliberately change the default branch in repository settings — an explicit, separate confirmation of intent for a sensitive activity, satisfying this control. See https://github.com/Progressiverobot/hmailserver/branches

Criterion [OSPS-BR-01.01]
Met

Unmet

N/A

?

When a CI/CD pipeline operates on untrusted metadata, those parameters MUST be sanitized and validated prior to use in the pipeline. ^{[OSPS-BR-01.01]}
CI/CD pipelines should sanitize (quote, escape or exit on expected values) all metadata inputs which correspond to untrusted sources. This includes data such as branch names, commit messages, tags, pull request titles, and author information.

All 10 CI/CD workflows on master were reviewed. No workflow uses pull_request_target, and no workflow interpolates untrusted metadata into shell 'run:' steps: no reference to PR titles/bodies, commit messages (head_commit/commits), branch names (github.head_ref/github.ref_name), or author/actor info appears anywhere. In PR-triggered CI the only github.event reference is github.event.pull_request.head.repo.full_name, used solely in 'if:' expression equality checks (ci.yml) — GitHub expression context, not a shell surface. The one pipeline that consumes genuinely untrusted third-party metadata, upstream-watch.yml, treats upstream commit subjects strictly as data: written to a file, emitted via a GITHUB_OUTPUT heredoc whose lines are SHA-prefixed, and passed as an env variable into a quoted gh argument. Maintainer-created release tags are consumed via env variables (sign-release.yml RELEASE_TAG/INPUT_TAG, sbom.yml TAG). Trusted-collaborator workflow_dispatch inputs (in scope for OSPS-BR-01.04 rather than this control) are passed via env (codeql.yml BUILD_CONFIGURATION, upstream-watch.yml UPSTREAM/SINCE_DAYS) or constrained by GitHub-validated choice enums (server-build.yml configuration: Release/Debug, inlined but limited to those two values); installer-smoke.yml inlines a free-form dispatch input (release_tag) into a run: step, but that input is only settable by collaborators with write access, not an untrusted source. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows

Criterion [OSPS-BR-01.03]
Met

Unmet

N/A

?

When a CI/CD pipeline operates on untrusted code snapshots, it MUST prevent access to privileged CI/CD credentials and assets. ^{[OSPS-BR-01.03]}
CI/CD pipelines should isolate untrusted code snapshots from privileged credentials and assets. In particular, projects should be careful to ensure that workflows which build or execute code prior to review by a collaborator do not have access to CI/CD credentials.

Every workflow that operates on untrusted PR snapshots (ci.yml, codeql.yml's C# job, dependency-review.yml, and verify-binary-provenance.yml — all triggered on pull_request to master) runs on ephemeral GitHub-hosted runners with top-level 'permissions: contents: read', and the repository's default workflow token permission is read-only. No workflow references any secret (zero 'secrets.' occurrences across all workflows on master), the repository has zero Actions or Dependabot secrets configured, and no workflow uses pull_request_target, so untrusted PR code has no credentials to reach. The privileged asset — the single self-hosted Windows runner — is used only by server-build.yml (workflow_dispatch only) and by codeql.yml's C++ job, which is explicitly gated by "if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'", so fork PR code never executes on it. Workflows holding write permissions run only on trusted triggers: sign-release.yml (top-level permissions: {}; job-level id-token/contents write; release-created or maintainer dispatch), sbom.yml (job-level contents: write; push to master, release-created, or dispatch), and upstream-watch.yml/scorecard.yml (schedule, push to master, or dispatch). ci.yml additionally gates its coverage-upload job to same-repo PRs via a head.repo.full_name check. See https://github.com/Progressiverobot/hmailserver/tree/master/.github/workflows

Criterion [OSPS-BR-03.01]
Met

Unmet

N/A

?

When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels. ^{[OSPS-BR-03.01]}
Configure the project's websites and version control systems to use encrypted channels such as SSH or HTTPS for data transmission. Ensure all tools and domains referenced in project documentation can only be accessed via encrypted channels.

Every official project channel is HTTPS-only: the repository, Releases, Issues, and Discussions at https://github.com/Progressiverobot/hmailserver (GitHub also serves git over SSH/HTTPS only), the maintainer's site https://www.progressiverobot.com, and the upstream forum linked from SUPPORT.md (https://www.hmailserver.com/forum/). A scan of all markdown documentation found no project channel offered over plain HTTP. Two third-party dependency download links in the build instructions (openssl.org, boost.org) are written as http:// — both hosts redirect to HTTPS and neither is a project channel, but updating them is recommended. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md

Criterion [OSPS-BR-03.02]
Met

Unmet

N/A

?

When the project lists a URI as an official distribution channel, that channel MUST be protected from adversary-in-the-middle attacks using cryptographically authenticated channels. ^{[OSPS-BR-03.02]}
Artifacts distributed by the project should be distributed through channels which ensure integrity and authenticity. Use of HTTPS for downloads, signed releases, or distribution through trusted package managers are all acceptable methods to protect against adversary-in-the-middle attacks.

The only official distribution channel is GitHub Releases at https://github.com/Progressiverobot/hmailserver/releases, delivered exclusively over HTTPS (TLS-authenticated). In addition, every release asset is signed: sign-release.yml signs each asset with Sigstore cosign keyless and verifies each signature before uploading it, so releases (e.g. v6.2.21) ship the installer plus .cosign.bundle files and signed CycloneDX/SPDX SBOMs. Release tags are protected by an active 'Protect release tags' ruleset. Together these provide cryptographic authentication of the channel and the artifacts. See https://github.com/Progressiverobot/hmailserver/releases

Criterion [OSPS-BR-07.01]
Met

Unmet

N/A

?

The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system. ^{[OSPS-BR-07.01]}
Configure .gitignore or equivalent to exclude files that may contain sensitive information. Use pre-commit hooks and automated scanning tools to detect and prevent the inclusion of sensitive data in commits.

GitHub secret scanning is enabled and secret scanning push protection is enabled for the repository (verified via the GitHub API on 2026-08-21: secret_scanning=enabled, secret_scanning_push_protection=enabled), so a push containing a detected credential is blocked before it lands in version control. A root .gitignore additionally excludes logs (.log), user-specific files (.user, *.suo), and build outputs. Dependabot security updates are also enabled. See https://github.com/Progressiverobot/hmailserver/blob/master/.gitignore

Criterion [OSPS-DO-01.01]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST include user guides for all basic functionality. ^{[OSPS-DO-01.01]}
Create user guides or documentation for all basic functionality of the project, explaining how to install, configure, and use the project's features. If there are any known dangerous or destructive actions available, include highly-visible warnings.

The project releases frequently (20+ releases in Aug 2026) and its documentation covers all basic functionality: the 544-line README documents capabilities, installing (including unattended install and supported platforms), administration (Control Panel GUI, REST admin API, client autoconfiguration), an extensive Configuration reference (~170 lines of settings with defaults and explanations), building, and running tests. Operator runbooks in hmailserver/docs cover diagnosing stalled mail, upgrading, migrating database backends, and high availability. All of this is on master and linked from the README's contents section. See https://github.com/Progressiverobot/hmailserver/blob/master/README.md

Criterion [OSPS-DO-02.01]
Met

Unmet

N/A

?

When the project has made a release, the project documentation MUST include a guide for reporting defects. ^{[OSPS-DO-02.01]}
It is recommended that projects use their VCS default issue tracker. If an external source is used, ensure that the project documentation and contributing guide clearly and visibly explain how to use the reporting system. It is recommended that project documentation also sets expectations for how defects will be triaged and resolved.

The project has a clear defect-reporting guide on master: .github/SUPPORT.md directs defect reports to GitHub Issues and specifies exactly what a useful report contains (debug log excerpt, ERROR log, version, Windows version, database backend, expected behavior, reproducibility), redirects suspected security problems to private reporting via SECURITY.md, routes questions to Discussions, and sets triage expectations ('What to expect': reports are read, no response-time guarantee, fixes claimed only with a reproducing test). A structured bug_report.yml issue template with required fields (version, OS, database) enforces this at filing time, and the README links to both. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SUPPORT.md

Criterion [OSPS-GV-02.01]
Met

Unmet

N/A

?

The project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles. ^{[OSPS-GV-02.01]}
Establish one or more mechanisms for public discussions within the project, such as mailing lists, instant messaging, or issue trackers, to facilitate open communication and feedback.

Public discussion happens on the GitHub issue tracker, which is enabled and actively used (34 issues, 32 closed, answered by the maintainer), with structured bug-report and feature-request issue templates and a pull-request template for proposed changes; GitHub Discussions is also enabled on the repository (API-verified: has_issues and has_discussions both true). See https://github.com/Progressiverobot/hmailserver/issues

Criterion [OSPS-GV-03.01]
Met

Unmet

N/A

?

The project documentation MUST include an explanation of the contribution process, or clearly state that public contributions are not accepted ^{[OSPS-GV-03.01]}
Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the contribution process including the steps for submitting changes, and engaging with the project maintainers.

.github/CONTRIBUTING.md on master explains the contribution process end to end: build instructions (toolchain, external libs, solutions, helper scripts), testing policy (keep the regression suite green, add tests for behavior changes), pull-request guidelines (branch from master, one logical change per PR, parameterised SQL only, INI-settings pattern for new features), an architecture orientation, and AGPLv3 licensing of contributions. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/CONTRIBUTING.md

Criterion [OSPS-LE-02.01]
Met

Unmet

N/A

?

The license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. ^{[OSPS-LE-02.01]}
Add a LICENSE file to the project's repo with a license that is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Releasing to the public domain meets this control if there are no other encumbrances such as patents.

The source code is licensed AGPL-3.0, which is both OSI-approved and an FSF free software license. The LICENSE file at the repository root contains the full GNU Affero General Public License v3 text (verified by reading the file on master). See https://github.com/Progressiverobot/hmailserver/blob/master/LICENSE

Criterion [OSPS-LE-02.02]
Met

Unmet

N/A

?

The license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition. ^{[OSPS-LE-02.02]}
If a different license is included with released software assets, ensure it is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Note that the license for the released software assets may be different than the source code.

Released assets (Windows installer + SPDX/CycloneDX SBOMs, all cosign-signed) distribute the same AGPL-3.0 software as the source; no separate proprietary license is applied to releases. The installer displays the AGPL-3.0 text at install time (LicenseFile=license.rtf in section_setup.iss; hmailserver/installation/License.rtf verified to contain the GNU AGPL text). AGPL-3.0 is OSI-approved and FSF-free. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/installation/License.rtf

Criterion [OSPS-LE-03.01]
Met

Unmet

N/A

?

The license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory. ^{[OSPS-LE-03.01]}
Include the project's source code license in the project's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.

The AGPL-3.0 license text is maintained in the LICENSE file at the root of the project's single authoritative repository; verified present on the master branch. See https://github.com/Progressiverobot/hmailserver/blob/master/LICENSE

Criterion [OSPS-LE-03.02]
Met

Unmet

N/A

?

The license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets. ^{[OSPS-LE-03.02]}
Include the project's released software assets license in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.

Every GitHub release automatically includes the source archives, which contain the root LICENSE (AGPL-3.0). In addition, the installer asset itself embeds the license: section_setup.iss sets LicenseFile=license.rtf and hmailserver/installation/License.rtf (verified to be the GNU AGPL text) is shown to the user during setup, so the license accompanies the released software assets. See https://github.com/Progressiverobot/hmailserver/releases/latest

Criterion [OSPS-QA-01.01]
Met

Unmet

N/A

?

The project's source code repository MUST be publicly readable at a static URL. ^{[OSPS-QA-01.01]}
Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the repository is publicly readable. Avoid duplication or mirroring of repositories unless highly visible documentation clarifies the primary source. Avoid frequent changes to the repository that would impact the repository URL. Ensure the repository is public.

The project's source code is publicly readable at the static URL https://github.com/Progressiverobot/hmailserver (API-verified: visibility public, not archived, default branch master). This is the single authoritative repository; the README identifies it as the maintained fork of the discontinued upstream project, so there is no ambiguity about the primary source. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-QA-01.02]
Met

Unmet

N/A

?

The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made. ^{[OSPS-QA-01.02]}
Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a publicly readable commit history. Avoid squashing or rewriting commits in a way that would obscure the author of any commits.

The repository keeps a publicly readable git history on GitHub recording what changed, who changed it, and when: every commit carries author name, email, and timestamp (verified in the clone: commits authored by chrisholloway5 with full dates). History totals 494 commits by the maintainer plus 4 by dependabot[bot], with no history rewriting that obscures authorship. See https://github.com/Progressiverobot/hmailserver/commits/master

Criterion [OSPS-QA-02.01]
Met

Unmet

N/A

?

When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies. ^{[OSPS-QA-02.01]}
This may take the form of a package manager or language dependency file that enumerates all direct dependencies such as package.json, Gemfile, or go.mod.

NuGet is the package manager for the .NET code, and the repository enumerates direct language dependencies in-tree: 26 .csproj files declare pinned PackageReference entries (e.g. hmailserver/source/Tools/ControlPanel/ControlPanel.csproj lists WPF-UI 4.3.0, LiveChartsCore.SkiaSharpView.WPF 2.0.5, QRCoder 1.8.0, System.Management 10.0.11, System.ServiceProcess.ServiceController 10.0.11), plus three packages.config files under hmailserver/test/. Dependabot monitors the nuget and github-actions ecosystems (.github/dependabot.yml). The native C++ server has no package management system (the criterion applies "when the package management system supports it"); its vendored dependencies are kept under libraries/ with per-library license files and a README, and Boost is built via libraries/build-dependencies.ps1. https://github.com/Progressiverobot/hmailserver/blob/master/.github/dependabot.yml

Criterion [OSPS-QA-04.01]
Met

Unmet

N/A

?

Projects with multiple repositories MUST document a list of codebases that are part of the project. ^{[OSPS-QA-04.01]}
Document any additional subproject code repositories produced by the project and compiled into a release. This documentation should include the status and intent of the respective codebase.

This criterion applies to projects with multiple repositories. hMailServer is a single-repository project: the C++ server, .NET Control Panel and tools, tests, fuzz harnesses, installer scripts, and documentation all live in the one authoritative repo, and releases are built entirely from it. There are no additional project codebases to list. See https://github.com/Progressiverobot/hmailserver

Criterion [OSPS-QA-05.01]
Met

Unmet

N/A

?

The version control system MUST NOT contain generated executable artifacts. ^{[OSPS-QA-05.01]}
Remove generated executable artifacts in the project's version control system. It is recommended that any scenario where a generated executable artifact appears critical to a process such as testing, it should be instead be generated at build time or stored separately and fetched during a specific well-documented pipeline step.

The repo tracks a generated executable: hmailserver/source/Tools/Interop/Interop.hMailServer.dll, the COM interop wrapper generated from the project's own type library, deliberately committed (disposition "retain-generated" in the binary inventory) so the .NET tools build without a registered typelib. The Baseline expects such artifacts to be produced at build time or fetched in a documented pipeline step. Compensating control: every committed binary is SHA-256-inventoried and verify-binary-provenance fails CI on any unlisted or changed binary — but the artifact remains in VCS. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/third-party-binaries.json

Criterion [OSPS-QA-05.02]
Met

Unmet

N/A

?

The version control system MUST NOT contain unreviewable binary artifacts. ^{[OSPS-QA-05.02]}
Do not add any unreviewable binary artifacts to the project's version control system. This includes executable application binaries, library files, and similar artifacts. It does not include assets such as graphical images, sound or music files, and similar content typically stored in a binary format.

master tracks ~40 unreviewable binaries: vendored third-party DLLs/EXE/MSIs (7za.exe, MariaDB Connector/C libmysql.dll and plugins, MSVC CRT redistributables, SQL CE MSIs, atl70.dll, isxdl.dll, ISC.dll) shipped by the installer. Compensating control: each is inventoried with SHA-256, version, publisher, license, upstream URL and disposition, and verify-binary-provenance fails CI on any unlisted or changed binary. Several are marked remove-duplicate/retain-review for cleanup, but the binaries remain in version control today, so this MUST is not met. See https://github.com/Progressiverobot/hmailserver/blob/master/hmailserver/docs/third-party-binaries.json

Criterion [OSPS-VM-02.01]
Met

Unmet

N/A

?

The project documentation MUST contain security contacts. ^{[OSPS-VM-02.01]}
Create a security.md (or similarly-named) file that contains security contacts for the project.

.github/SECURITY.md on master (surfaced on the repository's Security tab) provides the project's security contact: private reporting via GitHub Security Advisories at https://github.com/Progressiverobot/hmailserver/security/advisories/new (private vulnerability reporting API-verified as enabled), with a documented fallback channel for reporters who cannot use GHSA, plus response-time targets and a coordinated disclosure policy. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/SECURITY.md

You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. See our automation proposals system for how to do that. This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Progressive Robot and the OpenSSF Best Practices badge contributors.

hMailServer

Basics

General

Controls 22/24 ●

Controls