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 Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 14949 ist gold So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14949/badge)](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/badge"></a>


Dies sind die Kriterien das Level Silber. Sie können auch die Kriterien für die Level Passing oder Gold sehen.

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

        

 Grundlagen 17/17 ●

  • 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.

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    CONTRIBUTING.md and the merge request template state what an acceptable contribution needs: one logical change from the current master, a warning-free build (/WX, -warnaserror), a regression test for new behaviour, parameterised SQL only, the coding style and licence header, and a Signed-off-by (DCO) on every commit from an outside contributor. The Code of Conduct also applies. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md


  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]
    Die DCO ist der empfohlene Mechanismus, weil er einfach zu implementieren ist, im Quellcode verfolgt wird und git direkt eine "signed-off" Funktion mit "commit -s" unterstützt. Um am effektivsten zu sein, ist es am besten, wenn die Projektdokumentation erklärt, was "signed-off" für dieses Projekt bedeutet. Eine CLA ist eine rechtliche Vereinbarung, die die Bedingungen definiert, unter denen intellektuelle Werke an eine Organisation oder ein Projekt lizenziert wurden. Ein Contributor Assignment Agreement (CAA) ist eine gesetzliche Vereinbarung, die die Rechte an einer intellektuellen Arbeit an eine andere Person überträgt; Projekte müssen keine CAAs haben, da CAA das Risiko erhöht, dass potenzielle Mitwirkende nicht dazu beitragen werden, vor allem, wenn der Empfänger eine gewinnorientierte Organisation ist. Die Apache Software Foundation CLAs (die individuelle Contributor-Lizenz und die Corporate CLA) sind Beispiele für CLAs, für Projekte, die bestimmt haben, dass die Risiken dieser CLAs für das Projekt geringen sind als ihre Vorteile.

    CONTRIBUTING.md's Sign-off section links the Developer Certificate of Origin, says what the Signed-off-by trailer means, and requires it (git commit -s) on every commit of a merge request from outside the project; the maintainers' own commits are exempt, and there is no CLA. The sign-off job in .gitlab-ci.yml checks those merge requests; none has arrived yet, so it has not run. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#sign-off


    Genug für ein Badge!

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]
    Es muss einen gut dokumentierten, etablierten Weg geben, Entscheidungen zu treffen und Streitigkeiten zu lösen. In kleinen Projekten kann dies so einfach sein wie, "der Projektinhaber und -Leiter trifft alle endgültigen Entscheidungen". Es gibt verschiedene Führungs-Modelle, darunter wohlwollender Diktator und formale Meritokratie; Für weitere Details siehe Governance-Modelle . Sowohl zentralisierte (z.B. Single-Maintainer) als auch dezentrale (z.B. Gruppen-Maintainer) Ansätze wurden erfolgreich in Projekten verwendet. Die Governance-Informationen müssen nicht die Möglichkeit einer Projektspaltung dokumentieren, da dies für FLOSS-Projekte immer möglich ist.

    GOVERNANCE.md documents the model: two maintainers (Christopher Holloway and Zain Ul Abidin), stewarded by Progressive Robot Ltd, who decide in the open on the issue tracker. When they disagree, both positions are written on the issue and Christopher Holloway decides, giving his reason. The document also covers roles, how to become a maintainer, critical assets and continuity. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]
    Projekte können das Miteinander ihrer Gemeinschaft verbessern und Erwartungen in Bezug auf akzeptables Verhalten setzen, indem sie einen Verhaltenskodex verfassen. Dies kann helfen, Probleme zu vermeiden, bevor sie auftreten, und das Projekt zu einem einladenderen Ort zu machen. Dies sollte sich nur auf das Verhalten innerhalb der Gemeinschaft/ am Arbeitsplatz des Projekts konzentrieren. Beispielhafte Verhaltenskodizes sind der Linux Kernel Code of Conduct, der Contributor Covenant Code of Conduct, der Debian Code of Conduct, der Ubuntu Code of Conduct, der Fedora Code of Conduct, der GNOME Code Of Conduct, der KDE Community Code of Conduct, der Python Community Code of Conduct, die Ruby Community Conduct Guideline und der Rust Code of Conduct.

    The project adopts the Contributor Covenant 2.1, in the standard location CODE_OF_CONDUCT.md at the repository root and linked from CONTRIBUTING.md. It applies to the GitLab project and says how to report privately (a confidential issue, or the Service Desk address). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CODE_OF_CONDUCT.md


    Genug für ein Badge!

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]
    Die Dokumentation für Governance und Rollen und Verantwortlichkeiten können an einem Ort sein.

    GOVERNANCE.md defines the roles and their duties: Maintainer (accepting changes, releasing per RELEASE.md, security response per SECURITY.md, direction, infrastructure), Contributor and Reporter. A table says who holds which duty: Christopher Holloway (Progressiverobot on GitLab) holds all of them, and Zain Ul Abidin shares accepting changes and direction. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    GOVERNANCE.md (Critical assets, Continuity) lists the credentials whose loss would stop the project - project ownership, the release and code-signing path, and the build and test environment recipes - and says the owner keeps them in a managed arrangement that a trusted person can reach on confirmed unavailability, with the legal authority to use them, so issues, changes and releases can continue within days. The second maintainer is a Developer member of the GitLab project and can triage and close issues; RELEASE.md documents every release step. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#continuity


    Genug für ein Badge!

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    GOVERNANCE.md names two maintainers but says the record of knowing the codebase is still one person's. In the past year all but one human commit on master are Christopher Holloway's; the second maintainer, Zain Ul Abidin (a Developer on GitLab), has one. Only the owner's account can push master or create release tags. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/GOVERNANCE.md#continuity


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]
    Das Projekt könnte die Roadmap nicht umsetzen, das ist ok; Der Zweck der Roadmap ist es, potenziellen Nutzern/innen und Entwicklern/innen zu helfen, die beabsichtigte Richtung des Projekts zu verstehen. Sie muss nicht detailliert sein.

    Roadmap.md records what the project intends to do and deliberately will not do, with a status and reason for each item, and Roadmap2.md plans the current programme of work. Roadmap items are also tracked as issues with the roadmap label. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/Roadmap.md


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]
    Eine Softwarearchitektur erläutert die grundlegenden Strukturen eines Programms, d.h. die Hauptkomponenten des Programms, die Beziehungen zwischen ihnen und die Schlüsseleigenschaften dieser Komponenten und Beziehungen.

    ARCHITECTURE.md documents the high-level design: the repository's shape, the server's components (COM API as the management seam, Common, SMTP, IMAP/POP3, SQL persistence with parameterised queries), the tools, the tests, and the constraints between them. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ARCHITECTURE.md


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]
    Dies sind Sicherheitsanforderungen, die die Software erfüllen soll.

    SECURITY.md states what users can and cannot expect: the supported versions, the classes of issue treated as vulnerabilities, an explicit out-of-scope list (administrator-level access, deliberately unencrypted listeners, unsubstantiated scanner output), and how to verify a release. ASSURANCE-CASE.md argues why the security requirements are met. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]
    Die Idee ist, den Benutzern/innen zu zeigen, wie man anfängt und was die Software überhaupt macht. Dies ist entscheidend für potenzielle Benutzer/innen, um loszulegen.

    The README's Installing section and the wiki's Installing-hMailServer and Your-First-Domain-and-Mailbox pages take a new user from the single installer (or the .deb/.rpm) to a working domain and mailbox. The Control Deck's first-hour checklist can also create a sample domain to try things on. https://gitlab.com/Progressiverobot/hmailserver/-/wikis/Your-First-Domain-and-Mailbox


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]
    Die Dokumentation DARF Informationen über Unterschiede oder Änderungen zwischen Versionen der Software und/oder Links zu älteren Versionen der Dokumentation enthalten. Die Absicht dieses Kriteriums ist nicht, dass die Dokumentation perfekt sein muss, vielmehr soll Arbeit investiert, um die Dokumentation konsistent zu halten

    The documentation is revised with the code, and known defects in it are filed as GitLab issues with the documentation label (for example #15, documents that still name 6.3.3 as the latest release). Before 6.3.4, its CHANGELOG section was checked against the code and thirteen statements were corrected: https://gitlab.com/Progressiverobot/hmailserver/-/commit/40c7d3e0c


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]
    Eine Errungenschaft ist jegliche Form von externen Kriterien, auf die das Projekt speziell hingearbeitet hat, um diese zu erreichen, einschließlich einiger Abzeichen. Diese Informationen müssen nicht auf der ersten Seite der Website des Projekts einzusehen sein. Ein Projekt, das GitHub verwendet, kann Errungenschaften auf der Repository-Vorderseite setzen, indem man sie der README-Datei hinzufügt.

    The README opens with the OpenSSF Best Practices badge, hyperlinked to the project's entry on bestpractices.dev. It still points at the old entry (14187), so it must be changed to this entry's number when this entry reaches passing. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


  • Zugänglichkeit und Internationalisierung


    Genug für ein Badge!

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]
    Für Webanwendungen siehe Web Content Accessibility Guidelines (WCAG 2.0) und dessen unterstützendes Dokument Understanding WCAG 2.0; Siehe auch W3C accessibility information. Für GUI-Anwendungen sollten Sie die umweltbezogenen Barrierefreiheitsrichtlinien verwenden (z.B. Gnome, KDE, XFCE, Android, iOS , Mac und Windows). Einige TUI-Anwendungen (z.B. `ncurses`-Programme) können bestimmte Dinge ausführen, um sich selbst zugänglicher zu machen (z.B. `alpine`'s `force-arrow-cursor`-Einstellung). Die meisten Kommandozeilen-Anwendungen sind ziemlich unzugänglich. Dieses Kriterium ist oft N/A, z.B. für Programmbibliotheken. Hier sind einige Beispiele, welche Maßnahmen zu ergreifen oder Fragen zu berücksichtigen sind:
    • Stellen Sie Text Alternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass dieser in andere Formen umgewandelt werden kann, wie z.B. Großdruck, Blindenschrift, Sprache, Symbole oder einfachere Sprache ( WCAG 2.0-guideline 1.1)
    • Farbe ist nicht das einzige Mittel um Informationen zu übermitteln, die eine Aktion anzeigen, zu einer Eingabe auffordern oder visuelle Elemente unterscheiden. (WCAG 2.0 guideline 1.4.1)
    • Die visuelle Darstellung von Text und Textbildern hat einen Kontrast Verhältnis von mindestens 4,5:1, außer für großen Text, nebensächlichen Text, und Logos(WCAG 2.0 guideline 1.4.3)
    • Machen Sie alle Funktionalitäten von einer Tastatur aus erreichbar (WCAG guideline 2.1)
    • Ein GUI oder ein webbasiertes Projekt SOLLTE mit mindestens einen Screen-Reader auf der Zielplattform(en) testen (z.B. NVDA, Jaws oder WindowEyes auf Windows; VoiceOver auf Mac & iOS; Orca auf Linux/BSD; TalkBack auf Android). TUI-Programme DÜRFEN die Übermalung reduzieren, um eine redundante Lesung durch Screenreader zu verhindern.

    The Control Panel gives every control an accessible name and never carries a status by colour alone (hmailserver/docs/ControlPanelDesign.md); AccessibleNamesTests in ControlPanel.Tests checks the naming. The webmail is built to be used with a screen reader (landmarks, a skip link, focus that follows navigation; README). The project's documents are Markdown rendered by GitLab. https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/hmailserver/source/Tools/ControlPanel.Tests


    Genug für ein Badge!

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]
    Lokalisierung "bezieht sich auf die Anpassung eines Produkt-, Applikations- oder Dokumentinhalts, um die Sprache, kulturelle und andere Anforderungen eines bestimmten Zielmarktes zu erfüllen." Internationalisierung ist die "Gestaltung und Entwicklung eines Produkt-, Applikations- oder Dokumentinhaltes, die eine einfache Lokalisierung für Zielgruppen ermöglicht, die in Kultur, Region oder Sprache variieren." (Siehe W3Cs "Lokalisierung vs. Internationalisierung" .) Software erfüllt dieses Kriterium einfach dadurch, dass sie internationalisiert ist. Es ist keine Lokalisierung für eine andere Sprache erforderlich, denn sobald Software internationalisiert wurde, ist es möglich für andere, an der Lokalisierung zu arbeiten.

    User-facing text is served through language layers. The server has Languages.cpp and the COM Languages API, with per-language files that the installer's section_languages.iss offers. The Control Panel has resource files for 17 languages besides English (Resources/Strings.<lang>.resx). The self-service portal has 23 language files (Server/Common/Util/PortalLanguages). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/Util/Languages.cpp


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, müssen die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z. B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]
    Beachten Sie, dass die Verwendung von GitHub dieses Kriterium erfüllt. Dieses Kriterium gilt nur für Passwörter, die für die Authentifizierung von externen Benutzern in die Projektseiten verwendet werden (inbound authentication). Wenn sich die Projektseiten auf anderen Seiten anmelden müssen (outbound authentication), müssen sie eventuell Authorization-Tokens für diesen Zweck anders speichern (da das Speichern eines Hashes nutzlos wäre). Dies gilt für das Kriterium crypto_password_storage zu den Projektseiten, ähnlich wie sites_https.

    The repository, issue tracker and downloads are on GitLab, which stores users' passwords as salted bcrypt hashes. The project forum, https://www.hmailserver.co.uk/, runs NodeBB and has local accounts; NodeBB stores each password as a bcrypt hash with a per-user salt and a work factor.


 Verbesserungs-/Nacharbeits-Kontrolle 1/1 ●

  • Vorherige Versionen


    Genug für ein Badge!

    Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). [maintenance_or_update]

    An upgrade path is provided from every earlier hMailServer version. Installing over an existing deployment keeps the configuration and the mail, and the database upgrade chain is continuous: hmailserver/source/DBScripts, applied by the installer and by DBUpdater. SECURITY.md states that the 6.3 line is supported and that the answer for older versions is this in-place upgrade. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


 Berichterstattung 3/3 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. [report_tracker]

    GitLab issues is the project's issue tracker, with labels for area, type and workflow state: https://gitlab.com/Progressiverobot/hmailserver/-/issues


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [vulnerability_report_credit]

    The vulnerabilities resolved in the last 12 months (among them the REST settings routes in 6.3.3, the COM access checks in 6.2.10 and the JScript escaping flaw in 6.3.4) were all found by the project's own review or analysis, and none came from an outside report, so no reporter is uncredited; SECURITY.md commits to crediting reporters in the release notes unless they ask not to be named. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CHANGELOG.md


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_response_process]
    Dies steht im Zusammenhang mit vulnerability_report_process, welcher erfordert, dass es eine dokumentierte Möglichkeit gibt, Schwachstellen zu melden. Es bezieht sich auch auf vulnerability_report_response, welcher eine Antwort auf Schwachstellenberichte innerhalb eines bestimmten Zeitrahmens erfordert.

    SECURITY.md documents the response: private report by confidential issue or Service Desk email, acknowledgement within 5 working days, assessment within 10, a fix with a regression test within 90 days, coordinated disclosure at 90 days, credit in the release notes, and a CVE ID requested through GitLab, which is a CNA. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


 Qualität 19/19 ●

  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS die spezifischen Codierungsstilrichtlinien für die primären Programmierprachen, die es verwendet, einhalten, und erfordern, dass die Beiträge die Bedingungen generell erfüllen. (URL erforderlich) [coding_standards]
    In den meisten Fällen erfolgt dies durch Verweis auf einige vorhandene Stilrichtlinien, möglicherweise Auflistung Unterschiede. Diese Stilrichtlinien können Möglichkeiten zur Verbesserung der Lesbarkeit und zur Verringerung der Wahrscheinlichkeit von Mängeln (einschließlich Schwachstellen) enthalten. Viele Programmiersprachen haben eine oder mehrere weit verbreitete Stilrichtlinien. Beispiele für Style Guides sind Google-Style-Guides und SEI CERT Coding Standards .

    CONTRIBUTING.md (Code style and licence headers) sets the rules contributions must follow. .editorconfig requires spaces with three to an indent in C++ and C#, a final newline and no trailing whitespace. C++ builds at warning level 3 with /WX, and dotnet format formats C#. SQL is parameterised only, a new setting goes in the database, and every source file carries the licence header. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#code-style-and-licence-headers


    Genug für ein Badge!

    Das Projekt MUSS automatisch dafür sorgen, dass die ausgewählten Stilrichtlinien eingehalten werden, wenn mindestens ein FLOSS-Tool vorhanden ist, welches das in der gewählten Programmiersprache tun kann. [coding_standards_enforced]
    Dies kann mit Hilfe von statischen Analysewerkzeugen und/oder durch das Durchlaufen des Codes durch Code-Umformatierer erreicht werden. In vielen Fällen ist die Werkzeugkonfiguration im Projekt-Repository enthalten (da verschiedene Projekte unterschiedliche Konfigurationen wählen können). Projekte DÜRFEN Stil Ausnahmen erlauben (und werden es in der Regel); Wo Ausnahmen getroffen werden, MÜSSEN sie selten sein und MÜSSEN dokumentiert werden an der Stelle im Code, wo sie auftreten, so dass diese Ausnahmen überprüft werden können und so dass Werkzeuge sie automatisch in der Zukunft bearbeiten können. Beispiele für solche Werkzeuge sind ESLint (JavaScript), Rubocop (Ruby) und devtools check (R).

    The style is declared in .editorconfig, and the editorconfig job of .gitlab-ci.yml runs editorconfig-checker (FLOSS) over every text file, with a negative control. No GitLab pipeline has run that job yet. Until 18 September 2026, GitHub's style workflow ran the same check on every push. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


  • Produktivsystem


    Genug für ein Badge!

    Build-Systeme für native Binärdateien MÜSSEN die relevanten Compiler- und Linker- (Umgebungs-) Variablen, die an sie übergeben werden (z.B. CC, CFLAGS, CXX, CXXFLAGS und LDFLAGS), respektieren und an Compiler- und Linker-Aufrufe weiterleiten. Ein Build-System DARF sie mit zusätzlichen Flags erweitern; Es DARF NICHT einfach die mitgelieferten Werte ersetzen. Wenn keine nativen Binärdateien erzeugt werden, wählen Sie "nicht anwendbar" (N/A). [build_standard_variables]
    Es sollte einfach sein, spezielle Build-Features wie Address Sanitizer (ASAN) zu aktivieren, oder verteilte und bewährte Best Practices einzuhalten (z.B. durch einfaches Einschalten von Compiler-Flags).

    The Linux build is CMake, which takes CC, CXX, CFLAGS, CXXFLAGS and LDFLAGS from the environment and passes them to the compiler and linker. CMakeLists.txt only appends its own options (add_compile_options) and never replaces CMAKE_C_FLAGS or CMAKE_CXX_FLAGS; build/ci/linux-build.sh chooses the compiler through CC and CXX. The Windows MSBuild build has no such variables and takes Configuration, Platform and PlatformToolset instead. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/CMakeLists.txt


    Genug für ein Badge!

    Das Build- und Installationssystem SOLLTE Debugging-Informationen beibehalten, wenn sie in den entsprechenden Flags angefordert werden (z. B. "install -s" wird nicht verwendet). Wenn kein Build- oder Installationssystem vorhanden ist (z. B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_preserve_debug]
    Z. B., die Festlegung von CFLAGS (C) oder CXXFLAGS (C ++) sollte die relevanten Debugging-Informationen erstellen, wenn diese Sprachen verwendet werden, und sie sollten während der Installation nicht ignoriert werden. Debugging-Informationen werden für Unterstützung und Analyse benötigt und sind auch nützlich, um das Vorhandensein von Härtungsmerkmalen in den kompilierten Binärdateien zu messen.

    The Windows projects set DebugInformationFormat ProgramDatabase and GenerateDebugInformation true, so every Release build writes a .pdb beside the binary. The CMake build honours CMAKE_BUILD_TYPE (Debug, RelWithDebInfo) and -g in CXXFLAGS, and cmake --install does not strip. The .deb and .rpm that CPack makes are stripped (CPACK_STRIP_FILES). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/hMailServer/hMailServer.vcxproj


    Genug für ein Badge!

    Das Build-System für die Software, die durch das Projekt erzeugt wird, DARF NICHT rekursive Unterverzeichnisse aufbauen, wenn es Querverweise in den Unterverzeichnissen gibt. Wenn kein Build- oder Installationssystem vorhanden ist (z.B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_non_recursive]
    Die interne Abhängigkeitsinformationen des Build-Systems des Projektes müssen präzise sein, andernfalls können Änderungen an dem Projekt nicht korrekt erfolgen. Falsche Builds können zu Defekten (einschließlich Schwachstellen) führen. Ein häufiger Fehler bei großen Build-Systemen ist die Verwendung eines "rekursiven Builds" oder "rekursiven Make", d.h. einer Hierarchie von Unterverzeichnissen, die Quelldateien enthalten, wobei jedes Unterverzeichnis unabhängig aufgebaut ist. Es sei denn, jedes Unterverzeichnis ist völlig unabhängig, was ist ein Fehler ist, da die Abhängigkeitsinformationen nicht korrekt sind.

    No build is recursive. On Windows, one MSBuild solution (hMailServer.sln) resolves build order from the project references. On Linux, one CMakeLists.txt with no add_subdirectory builds the core library, the server and its test programs from a single dependency graph. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/CMakeLists.txt


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, den Prozess der Generierung von Informationen aus Quelldateien zu wiederholen und genau das gleiche Bit-für-Bit-Ergebnis zu erhalten. Wenn kein Build auftritt (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N / A). [build_repeatable]
    GCC- und Clang-Benutzer finden die Option -frandom-seed womöglich nützlich; In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. Weitere Vorschläge finden Sie auf der reproducible Build Seite.

    The Windows server compiles and links with /Brepro, /d1trimfile and /pdbaltpath, with OPENSSL_NO_FILENAMES defined. Two clean Release builds of the same tree on one machine gave a byte-identical hMailServer.exe (first on 22 August 2026, recorded in Roadmap.md), and RELEASE.md step 8 requires that check for every release. The Linux build uses -ffile-prefix-map and SOURCE_DATE_EPOCH. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/RELEASE.md


  • Installationssystem


    Genug für ein Badge!

    Das Projekt MUSS eine Möglichkeit zur einfachen Installation und Deinstallation der Software haben, unter Benutzung einer häufig verwendeten Methode. [installation_common]
    Beispiele hierfür sind die Verwendung eines Paketmanagers (auf dem System- oder Sprachniveaus), "make install/uninstall" (unterstützt DESTDIR), einem Container im Standardformat oder ein virtuelles Maschinenbild im Standardformat. Der Installations- und Deinstallationsvorgang (z.B. seine Verpackung) DARF von einem/einer Dritten implementiert werden, solange es FLOSS ist.

    On Windows, one Inno Setup installer (hMailServer-x.y.z-x64.exe) installs, upgrades in place and uninstalls from Apps and Features, and supports unattended install. On Linux, a .deb and an .rpm install and remove with the system package manager. The installer smoke test (install, upgrade, uninstall) is run by hand on a throwaway Windows Server 2025 VM, first on 25 September 2026, not in CI. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md#installing


    Genug für ein Badge!

    Das Installationssystem für den/die Endbenutzer/in MUSS Standardkonventionen zur Auswahl des Zielortes, in dem gebildete Artefakte zur Installationszeit geschrieben werden, folgen. Zum Beispiel, wenn es Dateien auf einem POSIX-System installiert, muss es die DESTDIR-Umgebungsvariable verwenden. Wenn es kein Installationssystem oder keine Standardkonvention gibt, wählen Sie "nicht anwendbar" (N/A). [installation_standard_variables]

    The Windows installer defaults to Program Files and honours Inno Setup's standard /DIR= switch (documented in the README's Unattended install table). The Linux install is CMake's install() with GNUInstallDirs, so it honours DESTDIR, and the .deb and .rpm are built through it. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md#unattended-install


    Genug für ein Badge!

    Das Projekt MUSS einen Weg für potenzielle Entwickler bereithalten, um schnell alle erforderlich Projektergebnisse und Support-Umgebungen zu installieren, um Änderungen vornehmen zu können, einschließlich der Tests und Test-Umgebung. Dies MUSS mit einer gängigen Methode durchgeführt werden können. [installation_development_quick]
    Dies DARF mit einem generierten Container- und/oder Installationsskript(en) implementiert werden. Externe Abhängigkeiten würden typischerweise durch das Aufrufen von System- und/oder Sprachpaketmanager(n), als external_dependencies, installiert.

    CONTRIBUTING.md lists every prerequisite with its pinned version and one command per component: scripts that download and build the external libraries with checked hashes, build.ps1, build-tools.ps1, build-tests.ps1, and the CMake/Ninja commands with the Debian/Ubuntu package list for Linux. The CI image build/ci/linux.Dockerfile is a ready-made Linux build and test environment. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#prerequisites


  • Externe gepflegte Komponenten


    Genug für ein Badge!

    Das Projekt MUSS externe Abhängigkeiten in computerlesbarer Form auflisten. (URL erforderlich) [external_dependencies]
    Dies geschieht in der Regel mit den Konventionen des Paketmanagers und / oder des Buildsystems. Dies hilft auch installation_development_quick zu erfüllen.

    Dependencies are listed in machine-readable form: the .NET projects' committed NuGet lock files (packages.lock.json), the native libraries' pinned versions in the project files, and every vendored or fetched binary with its version, origin and SHA-256 in hmailserver/docs/third-party-binaries.json. SPDX and CycloneDX SBOMs were attached to the releases up to 6.3.3. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/third-party-binaries.json


    Genug für ein Badge!

    Projekte MÜSSEN ihre externen Abhängigkeiten (einschließlich Bequemlichkeitskopien) überwachen oder regelmäßig überprüfen, um bekannte Schwachstellen zu erkennen und ausnutzbare Schwachstellen zu beheben oder sie als unausweichlich zu verifizieren. [dependency_monitoring]
    Dies kann mit einem Ursprungsanalysator / Abhängigkeitsüberprüfungswerkzeug / Softwarezusammensetzungsanalysator wie OWASPs Dependency-Check, Sonatypes Nexus Auditor, Synopsys' Black Duck Software Composition Analysis, und Bundler-Audit (für Ruby) erreicht werden. Einige Paketmanager beinhalten Mechanismen, um dies zu tun. Es ist akzeptabel, wenn die Anfälligkeit der Komponenten nicht ausgenutzt werden kann, aber diese Analyse ist schwierig und es ist manchmal einfacher, den Part einfach zu aktualisieren oder zu reparieren.

    The dependency-scan job in .gitlab-ci.yml (Trivy over the lock files and the CI image, OSV over the vendored libraries) was run by hand on the project's runner on 25 September 2026. What it found (zlib 1.3.1's CVE-2026-27171, and a 7-Zip 19.00 that OSV cannot match) was fixed the same day by moving to zlib 1.3.2 and 7-Zip 26.03; a finding that does not affect the project is dismissed with its reason in the VEX document. The job has not yet run in a GitLab pipeline; Renovate (renovate.json) waits for the owner's token and schedule, and Dependabot ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md#security-scanning


    Genug für ein Badge!

    Das Projekt MUSS entweder:
    1. Es einfach machen, wiederverwendbare extern gepflegte Komponenten zu identifizieren und zu aktualisieren;oder
    2. Die Standardkomponenten des Systems oder der Programmiersprache verwenden.
    Dann, wenn eine Schwachstelle in einer wiederverwendeten Komponente gefunden wird, wird es einfach sein diese Komponente zu aktualisieren. [updateable_reused_components]
    Ein typischer Weg, um dieses Kriterium zu erfüllen, ist die Verwendung von System- und Programmiersprachen-Paketverwaltungssystemen. Viele FLOSS-Programme werden mit "Convenience-Bibliotheken" ausgestattet, die lokale Kopien der Standardbibliotheken (ggf. geforkt) enthalten. Prinzipiell ist das gut. Wenn jedoch das Programm diese lokalen (geforkten) Kopien verwenden *muss*, dann wird die Aktualisierung der "Standard"-Bibliotheken, als Sicherheitsupdate, diese zusätzlichen Kopien immer noch verwundbar lassen. Dies ist vor allem ein Problem für Cloud-basierte Systeme; Wenn der Cloud-Provider seine "Standard"-Bibliotheken aktualisiert, aber das Programm sie nicht verwendt, dann helfen die Updates nicht wirklich. Siehe z.B. "Chromium: Why it isn't in Fedora yet as a proper package" von Tom Callaway .

    Reused components are named and pinned where they can be updated: the .NET packages in committed NuGet lock files restored with --locked-mode, OpenSSL, Boost and libpq by version and source hash in the libraries/ build scripts, and every third-party binary by SHA-256 in hmailserver/docs/third-party-binaries.json, inventoried in ThirdPartyBinaries.md. Renovate (renovate.json) is configured to propose updates but waits for the owner's token and schedule. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Genug für ein Badge!

    Das Projekt SOLLTE vermeiden veraltete oder obsolete Funktionen und APIs zu verwenden, für die FLOSS-Alternativen in der eingesetzten Technologie verfügbar sind (ihr "Technologie-Stack") und eine Supermajorität der Benutzer, die das Projekt unterstützt (so dass die Benutzer den Zugriff auf die Alternative haben ). [interfaces_current]

    The fork is built on current interfaces: Visual Studio 2026 (toolset v145), OpenSSL 4.0.x, Boost 1.92 and .NET 10 for the Control Panel and tools. The README's technology table records these versions, along with the plan to move OpenSSL to the next LTS. Deprecated protocol behaviour is kept only where a mail server must interoperate, and then behind a setting. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine automatisierte Test-Suite MUSS bei jedem Check-In auf ein gemeinsames Repository für mindestens einen Zweig angewendet werden. Diese Test-Suite muss einen Bericht über Erfolg oder Misserfolg des Testes produzieren. [automated_integration_testing]
    Diese Anforderung kann als Teilmenge von test_continuous_integration angesehen werden, konzentriert sich aber nur auf das Testen, ohne eine kontinuierliche Integration zu fordern.

    Every code change reaches master only after the maintainer's full regression gate has passed on the tree that lands: the whole Windows regression suite (NUnit), split across two machines, and the whole Linux suite, each reporting the tests that passed and failed (CONTRIBUTING.md, Merge requests); documentation-only commits may follow a gated tree. GitHub Actions ran the automated suites on every push until 18 September 2026; the GitLab CI that replaces them is defined in .gitlab-ci.yml but has not yet run a full pipeline. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Genug für ein Badge!

    Das Projekt MUSS Regressionstests zu einer automatisierten Test-Suite hinzufügen für mindestens 50% der, in den letzten sechs Monaten, gefixten Bugs. [regression_tests_added50]

    A bug is fixed with a regression test that fails against the build before the fix, as SECURITY.md and SUPPORT.md state. Examples: the 6.3.4 JScript escaping fix is pinned in RegressionTests/API/Events.cs, and the CVE-2023-51764 smuggling rule in SMTP/BareLineFeedEndOfData.cs. The automated NUnit suite has 495 C# files. Every change lands only after the maintainer runs the whole Windows suite, split across two machines, and the whole Linux suite. https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/hmailserver/test/RegressionTests


    Genug für ein Badge!

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) haben, die mindestens 80% Aussage Berichterstattung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache erfüllen kann. [test_statement_coverage80]
    Viele FLOSS-Tools stehen zur Verfügung, um die Test-Coverage zu beurteilen, einschließlich gcov/lcov, Blanket.js, Istanbul, JCov, und covr (R). Beachten Sie, dass das Erfüllen dieses Kriteriums keine Garantie dafür ist, dass die Test-Suite gründlich ist, hingegen ist das Verfehlen dieses Kriteriums ein starker Indikator für eine schlechte Test-Suite.

    The native server's coverage was measured once, on 15 September 2026: 73.48% of its lines (67,790 of 92,260 under hmailserver/source/Server) over the whole Windows regression suite, with OpenCppCoverage 0.9.9. That is below 80%. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

    Das Projekt MUSS eine formale schriftliche Richtlinie dazu haben, wie wichtige neue Funktionalität hinzugefügt werden. Tests für die neue Funktionalität MÜSSEN zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy_mandated]

    The policy is written in CONTRIBUTING.md: 'Add or update regression tests for a change of behaviour', and 'A fix ships with a test that fails against the build before it'; the merge-request template's checklist repeats it for new behaviour. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Genug für ein Badge!

    Das Projekt MUSS in seinen dokumentierten Anweisungen für Änderungsvorschläge die Richtlinien enthalten, die Tests für große neue Funktionalität hinzugefügt werden sollen. [tests_documented_added]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.

    The instructions for change proposals, CONTRIBUTING.md's 'Merge requests' section, say to add or update regression tests for a change of behaviour, and the merge-request template's checklist asks that new behaviour be covered by a regression test. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


  • Warnhinweise


    Genug für ein Badge!

    Projekte MÜSSEN praktischerweise sehr streng mit Warnungen in der Projektsoftware sein. [warnings_strict]
    Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

    The Windows build holds the server's own code to MSVC /W3 with /WX (vendored zlib alone is compiled at /W1), and the .NET projects are built with -warnaserror; moving a codebase of this age to /W4 would need mass suppression, and the Linux build adds no warning flags of its own. Beyond compiler warnings, cppcheck and clang-tidy (bugprone, cert, clang-analyzer and concurrency checks) were run over the sources on 25 September 2026 and their findings committed as a baseline, against which the CI job reports any new finding (allow_failure until the baseline is triaged). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#code-style-and-licence-headers


 Sicherheit 13/13 ●

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). [implement_secure_design]
    Beispielsweise sollten die Projektergebnisse fehlersichere Vorgaben haben (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation von Projekten sollte standardmäßig sicher sein). Die Projektergebnisse sollten auch eine vollständige Vermittlung haben (jeder Zugang, der begrenzt werden kann, muss auf Autorität überprüft werden und nicht umgangen werden können). Beachten Sie, dass in einigen Fällen Prinzipien in Konflikt geraten, in welchen eine Entscheidung getroffen werden muss (z.B. viele Mechanismen können die Dinge komplexer machen, gegen die "Wirtschaftlichkeit des Mechanismus" verstoßen / halten Sie es einfach).

    The server fails safe: a new installation is given a certificate, STARTTLS on every listener and TLS required for authentication from other hosts before it first listens. TLS peers are verified by default, and unsafe password-hash schemes are refused. Mediation is complete: all management goes through one API seam (COM, with REST on top), and SQL is parameterised by rule. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/SecureDefaults.md


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    The defaults do not depend on seriously weak algorithms. The default cipher list excludes DES, 3DES, MD5, export and null ciphers and lists ECDHE with AES-GCM first; TLS 1.3 is AEAD only; and the AEAD-ONLY preset removes the remaining CBC and SHA-1 HMAC suites. DKIM signs with SHA-256 by default and treats rsa-sha1 signatures as failing (RFC 8301) unless DkimAcceptSha1 is set. Passwords are hashed with PBKDF2 by default. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/AntiSpam/DKIM/DKIM.cpp


    Genug für ein Badge!

    Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. [crypto_algorithm_agility]

    Algorithms are settings, not constants. Password hashing is PBKDF2 (the default), Argon2id or scrypt through PreferredHashAlgorithm, with a minimum accepted scheme. The TLS 1.2 cipher list (SslCipherList, with an AEAD-ONLY preset), the TLS 1.3 suites (TlsCipherSuites13) and the key-exchange groups (TlsKeyExchangeGroups) are all configurable, and DKIM signs with RSA-SHA256 or Ed25519. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/Application/IniFileSettings.cpp


    Genug für ein Badge!

    Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). [crypto_credential_agility]

    TLS certificates and private keys, and DKIM private keys, are separate PEM files referenced by path from the configuration, and can be replaced without recompiling. Account passwords are stored only as hashes; credentials the server uses to sign in elsewhere (route relays, external accounts) are settings in the database, protected at rest, and changed without recompiling. No credential is compiled into the program. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/SslContextInitializer.cpp


    Genug für ein Badge!

    Die vom Projekt produzierte Software SOLLTE sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 SOLLTEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    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


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    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


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_certificate_verification]
    Beachten Sie, dass eine falsche TLS-Zertifikatsüberprüfung ein häufiger Fehler ist. Weitere Informationen finden Sie unter "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" von Martin Georgiev et al. und "Do you trust this application?" von Michael Catanzaro.

    Outbound TLS verifies certificates by default: a new database sets VerifyRemoteSslCertificate to 1. TCPConnection.cpp then sets verify_peer and verify_fail_if_no_peer_cert and installs a callback that checks the chain and the expected host name, with DANE-EE matching where TLSA records apply and MTA-STS forcing verification. Inbound client-certificate verification can be set per port. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/TCPConnection.cpp


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_verification_private]

    The verify mode and callback are set on the socket before the handshake, and a failed verification fails the handshake. So the server, as a client, sends SMTP AUTH credentials or any other private data only over a connection that has already been verified. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Server/Common/TCPIP/TCPConnection.cpp


  • Sicheres Release


    Genug für ein Badge!

    Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). [signed_releases]
    Die Projektergebnisse umfassen sowohl Quellcode als auch alle erzeugten Ergebnisse, falls zutreffend (z. B. ausführbare Dateien, Pakete und Container). Generierte Ergebnisse können separat vom Quellcode signiert werden. Diese DÜRFEN als signierte git-Tags (mit kryptographischen digitalen Signaturen) implementiert werden. Projekte DÜRFEN generierte Ergebnisse getrennt von Werkzeugen wie git behandeln, aber in diesen Fällen MÜSSEN die separaten Ergebnisse separat unterzeichnet werden.

    Every release published on GitLab is signed, and SECURITY.md documents how to get the public keys and verify each signature: https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release. Release tags are SSH-signed with the key listed in the repository's allowed_signers file (also on the maintainer's GitLab account). Every asset of the releases from 6.2.19 to 6.3.3 carries a keyless Sigstore bundle recorded in the public Rekor log. The Windows installer is Authenticode-signed (Progressive Robot Ltd) since 6.3.1. From 6.3.4, the release's SHA256SUMS file, which lists the hash of every asset, is signed with the same SSH key (ssh-keygen -Y sign, verified with ssh-keygen -Y verify against allowed_signers). No private key is on a distribution site: Sigstore signing is keyless, the tag key stays on the maintainer's own machine, and the Authenticode key is held in Azure Artifact Signing.


    Genug für ein Badge!

    Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. [version_tags_signed]

    Every release tag from v6.2.23-alpha2 on is an annotated tag signed with a maintainer's SSH key, and each verifies with git verify-tag against the allow list in the repository (.github/allowed_signers on master today, .gitlab/allowed_signers once the next batch lands); SECURITY.md's 'Verifying a release' gives the command. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md#verifying-a-release


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. [input_validation]
    Beachten Sie, dass der Vergleich der Eingabe mit einer Liste von "schlechten Formaten" (aka einer *Denylist*) normalerweise nicht ausreicht, weil Angreifer oft um eine Denyliste herumarbeiten können. Insbesondere werden Zahlen in interne Formate konvertiert und dann überprüft, ob sie zwischen ihrem Minimum und Maximum (inklusive) liegen und Textstrings werden überprüft, um sicherzustellen, dass sie gültige Textmuster haben (z.B. gültige UTF-8, Länge, Syntax, etc.). Einige Daten müssen möglicherweise "irgendetwas" (z. B. ein Datei-Uploader) sein, aber das ist typischerweise selten der Fall.

    Untrusted protocol input is checked at the boundary: SMTP, IMAP and POP3 commands are parsed against their grammar and anything else is refused. A bare LF before the end-of-data dot is refused (the SMTP smuggling rule, CVE-2023-51764), pinned by SMTP/BareLineFeedEndOfData.cs. SQL is parameterised by rule, and the MIME parser is fuzzed (fuzz/). https://gitlab.com/Progressiverobot/hmailserver/-/tree/master/fuzz


    Genug für ein Badge!

    Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. [hardening]
    Härtungsmechanismen können HTTP-Header enthalten wie Content Security Policy (CSP), oder Compiler-Flags (z.B. -fstack-protector), um Angriffe zu mildern, oder Compiler-Flags, um undefiniertes Verhalten zu eliminieren. Für unsere Zwecke wird das Prinzip des kleinsten Privilegs nicht als Verhärtungsmechanismus betrachtet (trotzdem ist es wichtig, aber an anderer Stelle).

    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


    Genug für ein Badge!

    Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. (URL erforderlich) [assurance_case]
    Ein "Assurance Case" ist ein dokumentierter Beweis, der ein überzeugendes und gültiges Argument enthällt, dass ein bestimmter Satz kritischer Ansprüche bezüglich der Eigenschaften eines Systems für eine gegebene Anwendung in einer gegebenen Umgebung hinreichend erfüllt ist ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al., NIST Interagency Report 7608 ). Vertrauensgrenzen sind Grenzen, in denen Daten oder Ausführung ihr Vertrauensniveau ändern, z.B. die Grenzen eines Servers in einer typischen Webanwendung. Es ist üblich, sichere Designprinzipien (wie Saltzer und Schroeer) und gemeinsame Implementierungssicherheitsschwächen (wie die OWASP Top 10 oder CWE/SANS Top 25) aufzurufen und zu zeigen, wie diesen entgegengewirkt wird. Die BadgeApp Assurance Case kann ein nützliches Beispiel sein. Dies bezieht sich auf documentation_security, documentation_architecture und implement_secure_design.

    ASSURANCE-CASE.md states the security requirements as seven claims (C1-C7). It covers the threat model (actors A1-A6, assets, attack surfaces) and the trust boundaries B1-B6 with a diagram, argues that secure design principles are applied, maps the countermeasures for common weaknesses to CWE classes (injection, memory corruption, smuggling, credential storage, randomness, certificate validation, resource exhaustion, supply chain), and gives evidence per claim and the residual risks. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/ASSURANCE-CASE.md


 Analyse 2/2 ●

  • Statische Codeanalyse


    Genug für ein Badge!

    Das Projekt MUSS mindestens ein statisches Analyse-Tool mit Regeln oder Ansätzen verwenden, um nach bekannten Schwachstellen in der analysierten Sprache oder Umgebung zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache implementieren kann. [static_analysis_common_vulnerabilities]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    clang-tidy runs the cert-, bugprone- and clang-analyzer-* check families (build/ci/clang-tidy.yaml), which look for common C and C++ weaknesses such as memory errors, unchecked conversions and unsafe functions, and Semgrep runs its open rule packs for C#, Python, JavaScript and shell, which include security rules. Until 18 September 2026 CodeQL's security queries also ran on GitHub. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/build/ci/clang-tidy.yaml


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Wenn die Projektsoftware Software mit einer speicherunsicheren Sprache (z.B. C oder C ++) enthält, MUSS mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Applikationsscanner) routinemäßig in Kombination mit einem Mechanismus verwendet werden, welche Speichersicherheitsproblemen wie Puffer-Cach Überschreibe erkennen. Wenn das Projekt keine Software verwendet, die in einer speicherunsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    The C++ MIME parser is fuzzed with libFuzzer under AddressSanitizer before every minor release (RELEASE.md step 8c; fuzz/, docs/Fuzzing.md). Before each release, the whole regression suite also runs on the assertion build, with a crash oracle that fails a test on any swallowed access violation. The nightly fuzz job (linux-fuzz) and an ASan/UBSan job over snmp-tests (linux-sanitize) are defined in .gitlab-ci.yml but have not yet run on GitLab; nightly fuzzing ran on GitHub until 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/Fuzzing.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.