hMailServer

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Baseline-Badge-Status auf Ihrer Projektseite! Der Baseline-Badge-Status sieht so aus: Baseline-Badge-Level für Projekt 14949 ist in_progress So betten Sie das Baseline-Badge ein:
Sie können Ihren Baseline-Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14949/baseline)](https://www.bestpractices.dev/projects/14949)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/baseline"></a>


Dies sind die Baseline Niveau 1 Kriterien. Dies sind Kriterienversion v2026.08.28.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    hMailServer is a free, open-source mail server for Windows and Linux, implementing SMTP, IMAP and POP3, with webmail, a REST API and a Control Panel. It is a maintained fork of Martin Knafve's hMailServer, brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

    This entry replaces https://www.bestpractices.dev/en/projects/14187, which was made through a GitHub login. GitHub suspended the project account on 18 September 2026, so that entry can no longer be edited. The project has lived on GitLab since 22 September 2026: https://gitlab.com/Progressiverobot/hmailserver. Every answer here was checked again against the project on 26 September 2026.

 Steuerelemente 22/24 ●

  • Steuerelemente


    Genug für ein Badge!

    Wenn ein Benutzer versucht, eine sensible Ressource im autoritativen Repository des Projekts zu lesen oder zu ändern, MUSS das System vom Benutzer verlangen, einen Multi-Faktor-Authentifizierungsprozess abzuschließen. [OSPS-AC-01.01]
    Erzwingen Sie Multi-Faktor-Authentifizierung für das Versionskontrollsystem des Projekts und verlangen Sie von Mitarbeitern, eine zweite Form der Authentifizierung bereitzustellen, wenn sie auf sensible Daten zugreifen oder Repository-Einstellungen ändern. Passkeys sind für diese Kontrolle akzeptabel.

    Only the Owner account, Progressiverobot, can change project settings, CI/CD variables, protected branches and tags, or push master and v* tags, and it signs in with two-factor authentication. The two other members, zainulabidin1990 and chrisholloway5 (Developer), can read confidential issues, where security reports arrive, and also sign in with two-factor authentication. The project is in a personal namespace, so GitLab has no setting that enforces this for them. See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    Genug für ein Badge!

    Wenn ein neuer Mitarbeiter hinzugefügt wird, MUSS das Versionskontrollsystem eine manuelle Berechtigungszuweisung erfordern oder die Mitarbeiterberechtigungen standardmäßig auf die niedrigsten verfügbaren Privilegien beschränken. [OSPS-AC-02.01]
    Die meisten öffentlichen Versionskontrollsysteme sind auf diese Weise konfiguriert. Stellen Sie sicher, dass das Versionskontrollsystem des Projekts Mitarbeitern beim Hinzufügen immer standardmäßig die niedrigsten verfügbaren Berechtigungen zuweist und zusätzliche Berechtigungen nur bei Bedarf gewährt.

    GitLab never grants project access by itself: a member is added only by an Owner or Maintainer inviting them with an explicitly chosen role, and access requests are turned off for this project. Today there are three members: Progressiverobot (Owner) and zainulabidin1990 and chrisholloway5 (Developer). See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    Nicht genug für ein Badge.

    Wenn ein direktes Commit auf den primären Branch des Projekts versucht wird, MUSS ein Durchsetzungsmechanismus verhindern, dass die Änderung angewendet wird. [OSPS-AC-03.01]
    Wenn das VCS zentralisiert ist, setzen Sie Branch-Schutz auf den primären Branch im VCS des Projekts. Alternativ verwenden Sie einen dezentralisierten Ansatz, wie beim Linux-Kernel, wo Änderungen zuerst in einem anderen Repository vorgeschlagen werden und das Zusammenführen von Änderungen in das primäre Repository einen spezifischen separaten Akt erfordert.

    master is a protected branch: force pushes are refused and only the Maintainer role or above may push or merge. Only the Owner account, Progressiverobot, holds that role, so every other account is refused a direct commit. But the maintainer lands changes by pushing master directly (a fast-forward after the full regression gate), and nothing prevents a direct commit from that account. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Genug für ein Badge!

    Wenn versucht wird, den primären Branch des Projekts zu löschen, MUSS das Versionskontrollsystem dies als sensible Aktivität behandeln und eine explizite Bestätigung der Absicht erfordern. [OSPS-AC-03.02]
    Setzen Sie Branch-Schutz auf den primären Branch im Versionskontrollsystem des Projekts, um das Löschen zu verhindern.

    master is the default branch, and GitLab refuses to delete the default branch. master is also protected: a git push cannot delete it, and only the Maintainer role or above can unprotect it, which only the Owner account holds. See https://gitlab.com/Progressiverobot/hmailserver/-/branches


    Genug für ein Badge!

    Wenn eine CI/CD-Pipeline mit nicht vertrauenswürdigen Metadaten arbeitet, MÜSSEN diese Parameter vor der Verwendung in der Pipeline bereinigt und validiert werden. [OSPS-BR-01.01]
    CI/CD-Pipelines sollten alle Metadaten-Eingaben, die nicht vertrauenswürdigen Quellen entsprechen, bereinigen (in Anführungszeichen setzen, escapen oder bei erwarteten Werten beenden). Dazu gehören Daten wie Branch-Namen, Commit-Nachrichten, Tags, Titel von Pull Requests und Autoreninformationen.

    The only CI job that handles metadata from outside the project is sign-off, which runs on a merge request from a fork. It reads commit authors, subjects and trailers into quoted shell variables, compares them as data and only prints them. Branch and tag names are compared in rules: and passed to scripts only as environment variables, never written into a command (SECURITY.md, "Branch and tag names in the pipelines"). See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Genug für ein Badge!

    Wenn eine CI/CD-Pipeline mit nicht vertrauenswürdigen Code-Snapshots arbeitet, MUSS sie den Zugriff auf privilegierte CI/CD-Anmeldeinformationen und -Ressourcen verhindern. [OSPS-BR-01.03]
    CI/CD-Pipelines sollten nicht vertrauenswürdige Code-Snapshots von privilegierten Anmeldeinformationen und Ressourcen isolieren. Insbesondere sollten Projekte sorgfältig darauf achten, dass Workflows, die Code vor der Überprüfung durch einen Mitarbeiter erstellen oder ausführen, keinen Zugriff auf CI/CD-Anmeldeinformationen haben.

    The project's two runners, linix and bench150, are registered ref_protected and locked, and do not run untagged jobs. The jobs that use them run only for protected refs (master, batch*, v*), never for a merge request. A merge request from a fork runs its pipeline in the fork, or on GitLab's shared runners when a maintainer runs it here, and either way sees no protected variable. No job on master declares an ID token; in the next batch only the release jobs for protected v* tags do. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Genug für ein Badge!

    Wenn das Projekt eine URI als offiziellen Projektkanal auflistet, MUSS diese URI ausschließlich über verschlüsselte Kanäle bereitgestellt werden. [OSPS-BR-03.01]
    Konfigurieren Sie die Websites und Versionskontrollsysteme des Projekts so, dass sie verschlüsselte Kanäle wie SSH oder HTTPS für die Datenübertragung verwenden. Stellen Sie sicher, dass alle Tools und Domains, die in der Projektdokumentation referenziert werden, nur über verschlüsselte Kanäle zugänglich sind.

    The project's channels are HTTPS only: the GitLab project, issues, wiki and releases, the update feed https://updates.progressiverobot.com and https://www.progressiverobot.com. The forums SUPPORT.md names are also HTTPS only: https://www.hmailserver.com/forum/ on master, and https://www.hmailserver.co.uk/ from the next batch. Each of those four sites redirects plain HTTP to HTTPS (checked 26 September 2026), and Git is served over HTTPS and SSH only. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SUPPORT.md


    Genug für ein Badge!

    Wenn das Projekt eine URI als offiziellen Distributionskanal angibt, MUSS dieser Kanal durch kryptografisch authentifizierte Kanäle vor Adversary-in-the-Middle-Angriffen geschützt werden. [OSPS-BR-03.02]
    Vom Projekt verteilte Artefakte sollten über Kanäle verteilt werden, die Integrität und Authentizität gewährleisten. Die Verwendung von HTTPS für Downloads, signierten Releases oder die Verteilung über vertrauenswürdige Paketmanager sind allesamt akzeptable Methoden, um sich vor Adversary-in-the-Middle-Angriffen zu schützen.

    Releases are distributed only over HTTPS, from GitLab's release pages and package registry (https://gitlab.com/Progressiverobot/hmailserver/-/releases) and the HTTPS update feed. Assets are also signed: Sigstore bundles for every asset up to 6.3.3, and Authenticode on the Windows installer from 6.3.1.


    Nicht genug für ein Badge.

    Das Projekt MUSS die unbeabsichtigte Speicherung unverschlüsselter sensibler Daten, wie Geheimnisse und Anmeldeinformationen, im Versionskontrollsystem verhindern. [OSPS-BR-07.01]
    Konfigurieren Sie .gitignore oder Äquivalent, um Dateien auszuschließen, die sensible Informationen enthalten könnten. Verwenden Sie Pre-Commit-Hooks und automatisierte Scan-Tools, um die Einbeziehung sensibler Daten in Commits zu erkennen und zu verhindern.

    The repository holds no credential, but nothing on GitLab stops one from being committed today. GitLab's secret push protection needs Ultimate, and .gitignore excludes build output and logs but no secret-file patterns. A secret_detection job (GitLab's template, failing on any finding not listed in .gitleaksignore) comes in the next batch and has not run on GitLab yet. On 26 September 2026 a scan of the whole history with that job's image found no real secret. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Genug für ein Badge!

    Wenn das Projekt ein Release erstellt hat, MUSS die Projektdokumentation Benutzerhandbücher für alle grundlegenden Funktionen enthalten. [OSPS-DO-01.01]
    Erstellen Sie Benutzerhandbücher oder Dokumentationen für alle grundlegenden Funktionen des Projekts, die erklären, wie das Projekt installiert, konfiguriert und verwendet wird. Wenn es bekannte gefährliche oder destruktive Aktionen gibt, fügen Sie gut sichtbare Warnungen hinzu.

    README.md covers installation (Windows installer, Linux packages, unattended install), administration (Control Panel, REST API), and building, with a configuration reference. The 104 documents under hmailserver/docs cover operation, upgrade, migration and security, and the GitLab wiki (https://gitlab.com/Progressiverobot/hmailserver/-/wikis/home) has 63 pages of user guides. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


    Genug für ein Badge!

    Wenn das Projekt ein Release erstellt hat, MUSS die Projektdokumentation eine Anleitung zum Melden von Fehlern enthalten. [OSPS-DO-02.01]
    Es wird empfohlen, dass Projekte ihren Standard-Issue-Tracker des VCS verwenden. Wenn eine externe Quelle verwendet wird, stellen Sie sicher, dass die Projektdokumentation und der Beitragsleitfaden klar und sichtbar erklären, wie das Meldesystem verwendet wird. Es wird empfohlen, dass die Projektdokumentation auch Erwartungen daran setzt, wie Fehler priorisiert und behoben werden.

    SUPPORT.md explains how to report a defect: a GitLab issue with the Bug template, and what to include (the log, the ERROR log, version, platform, database). It says what to expect and sends security problems to SECURITY.md. CONTRIBUTING.md, 'Reporting, asking and proposing', repeats the routes. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SUPPORT.md


    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Mechanismen für öffentliche Diskussionen über vorgeschlagene Änderungen und Nutzungshindernisse haben. [OSPS-GV-02.01]
    Richten Sie einen oder mehrere Mechanismen für öffentliche Diskussionen innerhalb des Projekts ein, wie Mailinglisten, Instant Messaging oder Issue-Tracker, um offene Kommunikation und Feedback zu ermöglichen.

    The GitLab issue tracker is public. Proposed changes and questions are discussed there, and a Question template adds the question label. Merge requests are open to forks. SUPPORT.md also points usage questions to the hMailServer forum. See https://gitlab.com/Progressiverobot/hmailserver/-/work_items


    Genug für ein Badge!

    Die Projektdokumentation MUSS eine Erklärung des Beitragsprozesses enthalten oder deutlich angeben, dass öffentliche Beiträge nicht akzeptiert werden [OSPS-GV-03.01]
    Erstellen Sie eine CONTRIBUTING.md oder ein CONTRIBUTING/ Verzeichnis, um den Beitragsprozess zu skizzieren, einschließlich der Schritte zum Einreichen von Änderungen und zur Interaktion mit den Projektbetreuern.

    CONTRIBUTING.md explains the contribution process: how to report, ask and propose, then build, test, sign off, and open a merge request from a fork against master. It also explains how the maintainer reviews and lands the change. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md


    Genug für ein Badge!

    Die Lizenz für den Quellcode MUSS der OSI Open Source Definition oder der FSF Free Software Definition entsprechen. [OSPS-LE-02.01]
    Fügen Sie eine LICENSE-Datei zum Repository des Projekts mit einer Lizenz hinzu, die eine genehmigte Lizenz der Open Source Initiative (OSI) oder eine freie Lizenz ist, wie sie von der Free Software Foundation (FSF) genehmigt wurde. Beispiele für solche Lizenzen sind MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL). Eine Veröffentlichung in die Public Domain erfüllt diese Kontrolle, wenn es keine anderen Belastungen wie Patente gibt.

    The source is licensed AGPL-3.0-or-later, which is OSI-approved and FSF-free. The full text is in LICENSE, the source headers carry SPDX-License-Identifier: AGPL-3.0-or-later, and GitLab detects the licence. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/LICENSE


    Genug für ein Badge!

    Die Lizenz für die veröffentlichten Software-Assets MUSS der OSI Open Source Definition oder der FSF Free Software Definition entsprechen. [OSPS-LE-02.02]
    Wenn eine andere Lizenz mit veröffentlichten Software-Assets enthalten ist, stellen Sie sicher, dass es eine genehmigte Lizenz der Open Source Initiative (OSI) oder eine freie Lizenz ist, wie sie von der Free Software Foundation (FSF) genehmigt wurde. Beispiele für solche Lizenzen sind MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL). Beachten Sie, dass die Lizenz für die veröffentlichten Software-Assets von der des Quellcodes abweichen kann.

    The released assets are the same AGPL-3.0-or-later software. The Windows installer shows the AGPL text at install time (LicenseFile=license.rtf, hmailserver/installation/License.rtf), and the .rpm declares License: AGPL-3.0-or-later. No other licence is applied to releases. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/installation/License.rtf


    Genug für ein Badge!

    Die Lizenz für den Quellcode MUSS in der LICENSE-Datei, der COPYING-Datei, dem LICENSES/-Verzeichnis oder dem LICENSE/-Verzeichnis des entsprechenden Repositorys gepflegt werden. [OSPS-LE-03.01]
    Fügen Sie die Quellcode-Lizenz des Projekts in der LICENSE-Datei, der COPYING-Datei, dem LICENSES/-Verzeichnis oder dem LICENSE/-Verzeichnis des Projekts ein, um Transparenz und Klarheit über die Lizenzbedingungen zu schaffen. Der Dateiname DARF eine Erweiterung haben. Wenn das Projekt mehrere Repositorys hat, stellen Sie sicher, dass jedes Repository die Lizenzdatei enthält.

    The licence text is in the LICENSE file at the root of the project's only repository. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/LICENSE


    Genug für ein Badge!

    Die Lizenz für die veröffentlichten Software-Assets MUSS im veröffentlichten Quellcode oder in einer LICENSE-Datei, COPYING-Datei oder einem LICENSE/-Verzeichnis neben den entsprechenden Release-Assets enthalten sein. [OSPS-LE-03.02]
    Fügen Sie die Lizenz für die veröffentlichten Software-Assets des Projekts in den veröffentlichten Quellcode oder in eine LICENSE-Datei, COPYING-Datei oder ein LICENSE/ Verzeichnis neben den entsprechenden Release-Assets ein, um Sichtbarkeit und Klarheit über die Lizenzbedingungen zu schaffen. Der Dateiname KANN eine Erweiterung haben. Wenn das Projekt mehrere Repositorys hat, stellen Sie sicher, dass jedes Repository die Lizenzdatei enthält.

    Each GitLab release includes the source archives of its tag, which contain the root LICENSE (AGPL-3.0-or-later), and the Windows installer shows the licence text during setup. See https://gitlab.com/Progressiverobot/hmailserver/-/releases


    Genug für ein Badge!

    Das Quellcode-Repository des Projekts MUSS unter einer statischen URL öffentlich lesbar sein. [OSPS-QA-01.01]
    Verwenden Sie ein gängiges VCS wie GitHub, GitLab oder Bitbucket. Stellen Sie sicher, dass das Repository öffentlich lesbar ist. Vermeiden Sie Duplizierung oder Spiegelung von Repositorys, es sei denn, eine gut sichtbare Dokumentation verdeutlicht die primäre Quelle. Vermeiden Sie häufige Änderungen am Repository, die sich auf die Repository-URL auswirken würden. Stellen Sie sicher, dass das Repository öffentlich ist.

    The source code is publicly readable at the static URL https://gitlab.com/Progressiverobot/hmailserver (a public GitLab project, default branch master), the project's home since 22 September 2026, as the first lines of README.md say. The former GitHub copy has been unavailable since 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver


    Genug für ein Badge!

    Das Versionskontrollsystem MUSS eine öffentlich lesbare Aufzeichnung aller vorgenommenen Änderungen, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden, enthalten. [OSPS-QA-01.02]
    Verwenden Sie ein gängiges VCS wie GitHub, GitLab oder Bitbucket, um eine öffentlich lesbare Commit-Historie zu pflegen. Vermeiden Sie das Zusammenfassen oder Umschreiben von Commits auf eine Weise, die den Autor von Commits verschleiern würde.

    The git history on GitLab is publicly readable and records the author, committer and date of every commit: master's 1,425 commits are the whole history carried over from GitHub plus every commit since, kept linear by fast-forward, and force-push is refused on the protected master branch. https://gitlab.com/Progressiverobot/hmailserver/-/commits/master


    Genug für ein Badge!

    Wenn das Paketverwaltungssystem dies unterstützt, MUSS das Quellcode-Repository eine Abhängigkeitsliste enthalten, die die direkten Sprachabhängigkeiten berücksichtigt. [OSPS-QA-02.01]
    Dies kann in Form einer Paketverwaltungs- oder Sprachabhängigkeitsdatei erfolgen, die alle direkten Abhängigkeiten auflistet, wie package.json, Gemfile oder go.mod.

    Every .NET project with a PackageReference has a committed NuGet lock file (packages.lock.json), and three legacy test tools list theirs in packages.config; the Python tooling's requirements are pinned with hashes (build/requirements-dev.txt). The C++ server has no package manager: OpenSSL, Boost and libpq are pinned by version and source-archive hash in the libraries/build-*.ps1 scripts, and every binary build input is listed in hmailserver/docs/third-party-binaries.json (checked by SHA-256, by version for the MSVC runtime, and for presence for two of Windows' own type libraries). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Genug für ein Badge!

    Projekte mit mehreren Repositorys MÜSSEN eine Liste der Codebasen dokumentieren, die Teil des Projekts sind. [OSPS-QA-04.01]
    Dokumentieren Sie alle zusätzlichen Unterprojekt-Code-Repositorys, die vom Projekt produziert und in ein Release kompiliert werden. Diese Dokumentation sollte den Status und die Absicht der jeweiligen Codebasis enthalten.

    hMailServer is a single-repository project: the C++ server, the .NET tools, the Control Deck and webmail, the tests, fuzz harnesses, installer, packaging and documentation are all built into releases from https://gitlab.com/Progressiverobot/hmailserver alone. The wiki belongs to the same GitLab project and is compiled into nothing.


    Genug für ein Badge!

    Das Versionskontrollsystem DARF KEINE generierten ausführbaren Artefakte enthalten. [OSPS-QA-05.01]
    Entfernen Sie generierte ausführbare Artefakte aus dem Versionskontrollsystem des Projekts. Es wird empfohlen, dass in jedem Szenario, in dem ein generiertes ausführbares Artefakt für einen Prozess wie Tests kritisch erscheint, es stattdessen zur Build-Zeit generiert oder separat gespeichert und während eines spezifischen gut dokumentierten Pipeline-Schritts abgerufen werden sollte.

    No generated executable is in version control. The one there was, the COM interop wrapper Interop.hMailServer.dll, has been generated at build time by build/generate-com-wrapper.ps1 since 11 September 2026. None of master's 6,983 tracked files has a PE, ELF or Mach-O header (checked 26 September 2026); the CI's Binary-Artifacts check (build/ci/repo-hygiene.py) tests the same. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Tools/Interop/README.md


    Genug für ein Badge!

    Das Versionskontrollsystem DARF KEINE nicht überprüfbaren Binärartefakte enthalten. [OSPS-QA-05.02]
    Fügen Sie keine nicht überprüfbaren Binärartefakte zum Versionskontrollsystem des Projekts hinzu. Dies umfasst ausführbare Anwendungsbinärdateien, Bibliotheksdateien und ähnliche Artefakte. Dies schließt keine Assets wie Grafikbilder, Ton- oder Musikdateien und ähnliche Inhalte ein, die typischerweise in einem Binärformat gespeichert werden.

    Since 11 September 2026 the repository holds no executable or library binary: the forty third-party DLLs, MSIs and EXEs were removed, and the build fetches or gathers each one it still needs, checked against hmailserver/docs/third-party-binaries.json (SHA-256 for the fetched ones, version for the MSVC runtime, presence for two of Windows' own type libraries). What remains binary is images (icons, the Fat Cow icon archive, installer bitmaps), licence texts (RTF) and test fixtures (PST files, certificates, OpenPGP samples, fuzz regression inputs). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Genug für ein Badge!

    Die Projektdokumentation MUSS Sicherheitskontakte enthalten. [OSPS-VM-02.01]
    Erstellen Sie eine security.md (oder ähnlich benannte) Datei, die Sicherheitskontakte für das Projekt enthält.

    SECURITY.md at the repository root gives the security contacts: a confidential GitLab issue (Security template) or email to the project's Service Desk address, contact-project+progressiverobot-hmailserver-86730559-issue-@incoming.gitlab.com, both reaching the maintainers, whom GOVERNANCE.md names. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie christopher holloway und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: christopher holloway.
Eintrag erstellt: 2026-09-26 05:28:20 UTC, zuletzt aktualisiert: 2026-09-26 06:16:51 UTC. Letztes erreichtes Badge: 2026-09-26 05:45:21 UTC.