hMailServer

Miradi inayofuata mazoea bora hapa chini inaweza kujihakikisha kwa hiari na kuonyesha kuwa wamepata nishani ya mazoea bora ya Open Source Security Foundation (OpenSSF).

Hakuna seti ya mazoea yawezayo kuhakikisha kuwa programu haitakuwa na kasoro au udhaifu; hata mbinu rasmi zinaweza kushindwa ikiwa vipimo au dhana ni sahihi. Wala hakuna seti ya mazoea yawezayo kuhakikisha kuwa mradi utaendelea kuwa na jamii ya maendeleo yenye afya na inayofanya kazi vizuri. Hata hivyo, kufuata mazoea bora kunaweza kusaidia kuboresha matokeo ya miradi. Kwa mfano, baadhi ya mazoea huwezesha ukaguzi wa watu wengi kabla ya kutolewa, ambayo inaweza kusaidia kupata udhaifu wa kiufundi ambao vinginevyo ni vigumu kupata na kusaidia kujenga uaminifu na hamu ya mwingiliano wa kurudia kati ya wasanidi programu kutoka makampuni tofauti. Ili kupata nishani, vigezo vyote vya LAZIMA na LAZIMA WALA USIWAHI lazima vifuatwe, vigezo vyote vya INAPASWA lazima vifuatwe AU visivyo fufufutiliana na thibitisho, na vigezo vyote vya PENDEKEZA lazima vifuatwe AU visivyo fufufutiliana (tunataka vifikiwe angalau). Ikiwa unataka kuingiza maandishi ya thibitisho kama maoni ya jumla, badala ya kuwa maelezo ya busara kwamba hali ni inakubaliwa, anza kifungu cha maandishi na '//' ikifuatiwa na nafasi. Maoni ni karibu kupitia tovuti ya GitHub kama masuala au maombi ya kuvuta Kuna pia orodha ya barua pepe kwa majadiliano ya jumla.

Tunafuraha kutoa habari katika lugha nyingi, hata hivyo, ikiwa kuna mgongano au kutokuwa na usawa kati ya tafsiri, toleo la Kiingereza ni toleo lenye mamlaka.
Ikiwa huu ni mradi wako, tafadhali onyesha hali ya nishani yako ya msingi kwenye ukurasa wa mradi wako! Hali ya nishani ya msingi inaonekana kama hii: Kiwango cha nishani ya msingi kwa mradi 14187 ni in_progress Huu ndiyo jinsi ya kuweka nishani ya msingi:
Unaweza kuonyesha hali ya nishani yako ya msingi kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14187/baseline)](https://www.bestpractices.dev/projects/14187)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/14187"><img src="https://www.bestpractices.dev/projects/14187/baseline"></a>


Hizi ni vigezo vya Kiwango cha Msingi 2. Hizi ni vigezo vya toleo v2026.08.28.

Baseline Series: Kiwango cha Msingi 1 Kiwango cha Msingi 2 Kiwango cha Msingi 3

        

 Misingi

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

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

    Tafadhali tumia muundo wa maneno ya leseni ya SPDX; mifano ni pamoja na "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", na "(BSD-2-Clause OR Ruby)". Usitumie alama za nukuu za moja au mbili.
    Ikiwa kuna lugha zaidi ya moja, ziorodhe kama thamani zilizotengwa kwa koma (nafasi ni za hiari) na ziorodhe kuanzia iliyotumiwa zaidi hadi iliyotumiwa kidogo. Ikiwa kuna orodha ndefu, tafadhali orodhesha angalau tatu za kawaida zaidi. Ikiwa hakuna lugha (k.m., huu ni mradi wa nyaraka tu au wa majaribio tu), tumia herufi moja "-". Tafadhali tumia herufi kubwa za kawaida kwa kila lugha, k.m., "JavaScript".
    Common Platform Enumeration (CPE) ni mpango wa kuweka majina yenye muundo kwa mifumo ya teknolojia ya habari, programu, na vifurushi. Inatumika katika mifumo na hifadhidata nyingi wakati wa kuripoti udhaifu.

 Udhibiti 18/19 ●

  • Udhibiti


    Ya kutosha kwa nishani!

    Wakati kazi ya CI/CD inatekelezwa bila ruhusa zilizobainishwa, mfumo wa CI/CD LAZIMA uweke chaguomsingi ruhusa za kazi kuwa ruhusa za chini kabisa zinazotolewa katika mfumo wa kuendeshea. [OSPS-AC-04.01]
    Sanidi mipangilio ya mradi ili kupeana ruhusa za chini zaidi zinazopatikana kwa mifumo mipya ya kuendeshea kwa chaguomsingi, ukitoa ruhusa za ziada tu zinapohitajika kwa kazi maalum.

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


    Ya kutosha kwa nishani!

    Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA lipatiwe kitambulisho cha pekee cha toleo. [OSPS-BR-02.01]
    Peana kitambulisho cha pekee cha toleo kwa kila toleo linalozalishwa na mradi, ukifuata mkondo thabiti wa kutaja au mpango wa nambari. Mifano ni pamoja na SemVer, CalVer, au kitambulisho cha kuwasilisha cha git.

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


    Ya kutosha kwa nishani!

    Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA liwe na kumbukumbu ya maelezo ya marekebisho ya utendakazi na usalama. [OSPS-BR-04.01]
    Hakikisha kuwa matoleo yote yanajumuisha kumbukumbu ya mabadiliko ya maelezo. Inashauriwa kuhakikisha kuwa kumbukumbu ya mabadiliko inaweza kusomwa na binadamu na inajumuisha maelezo zaidi ya ujumbe wa ahadi, kama vile maelezo ya athari za usalama au uhusiano na matumizi tofauti. Ili kuhakikisha kusomwa kwa mashine, weka maudhui chini ya kichwa cha markdown kama "## Changelog".

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


    Ya kutosha kwa nishani!

    Wakati mfululizo wa ujenzi na toleo unaingia utegemezi, LAZIMA utumie zana zilizowekwa viwango ambapo zinapatikana. [OSPS-BR-05.01]
    Tumia zana za kawaida kwa ikolojia yako, kama vile wasimamizi wa vifurushi au zana za usimamizi wa utegemezi kuingia utegemezi wakati wa ujenzi. Hii inaweza kujumuisha kutumia faili ya utegemezi, faili ya kufuli, au orodha ya kudhibitisha utegemezi unaohitajika, ambayo kisha unavutwa na mfumo wa ujenzi.

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


    Ya kutosha kwa nishani!

    Wakati toleo rasmi linapotengenezwa, toleo hilo LAZIMA liwe na saini au kuhesabiwa kwenye orodha iliyosainiwa ikiwa ni pamoja na hashes za usimbuaji za mali kila moja. [OSPS-BR-06.01]
    Saini mali zote za programu zilizotolewa wakati wa ujenzi kwa saini ya usimbuaji au uthibitisho, kama vile saini ya GPG au PGP, saini za Sigstore, utokeo wa SLSA, au SLSA VSAs. Jumuisha hashes za usimbuaji za mali kila moja katika orodha iliyosainiwa au faili ya metadata.

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


    Ya kutosha kwa nishani!

    Wakati mradi umefanya toleo, nyaraka za mradi LAZIMA zijumuishe maelezo ya jinsi mradi unavyochagua, kupata, na kufuatilia utegemezi wake. [OSPS-DO-06.01]
    Inashauriwa kuchapisha habari hii pamoja na nyaraka za kiufundi na muundo wa mradi kwenye rasilimali inayoweza kuonwa hadharani kama vile hifadhi ya msimbo wa chanzo, tovuti ya mradi, au kituo kingine.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zijumuishe maelekezo ya jinsi ya kujenga programu, ikiwa ni pamoja na maktaba zinazohitajika, mifumo, SDK, na utegemezi. [OSPS-DO-07.01]
    Inashauriwa kuchapisha taarifa hii pamoja na nyaraka za wachangiaji wa mradi, kama vile katika CONTRIBUTING.md au nyaraka nyingine za kazi za msanidi. Hii inaweza pia kuandikwa kwa kutumia malengo ya Makefile au hati nyingine za uendeshaji.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zijumuishe orodha ya wanachama wa mradi wenye ufikiaji wa rasilimali nyeti. [OSPS-GV-01.01]
    Andika washiriki wa mradi na majukumu yao kupitia vitu kama members.md, governance.md, maintainers.md, au faili sawa ndani ya hifadhi ya msimbo wa chanzo wa mradi. Hii inaweza kuwa rahisi kama kujumuisha majina au alama za akaunti katika orodha ya watunzaji, au changamano zaidi kulingana na utawala wa mradi.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zijumuishe maelezo ya majukumu na wajibu wa wanachama wa mradi [OSPS-GV-01.02]
    Andika washiriki wa mradi na majukumu yao kupitia vitu kama members.md, governance.md, maintainers.md, au faili sawa ndani ya hifadhi ya msimbo wa chanzo wa mradi.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zijumuishe mwongozo kwa wachangiaji wa msimbo unaojumuisha mahitaji ya michango inayokubalika. [OSPS-GV-03.02]
    Panua yaliyomo ya CONTRIBUTING.md au CONTRIBUTING/ katika nyaraka za mradi ili kuorodhesha mahitaji ya michango inayokubalika, ikiwa ni pamoja na viwango vya kuandika msimbo, mahitaji ya majaribio, na miongozo ya kuwasilisha kwa wachangiaji wa msimbo. Inashauriwa kuwa mwongozo huu ni chanzo cha ukweli kwa wachangiaji na waidhinishaji.

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


    Ya kutosha kwa nishani!

    Mfumo wa kudhibiti matoleo LAZIMA uwahitaji wachangiaji wote wa msimbo kuthibitisha kwamba wana ruhusa kisheria ya kufanya michango husika kwenye kila commit. [OSPS-LE-01.01]
    Jumuisha DCO katika hifadhi ya mradi, kuhitaji wachangiaji wa msimbo kudai kuwa wanaruhusiwa kisheria kuwasilisha michango husika kwenye ahadi kila moja. Tumia ukaguzi wa hali kuhakikisha dai linafanywa. CLA pia inakidhi mahitaji haya. Mifumo fulani ya kudhibiti toleo, kama vile GitHub, inaweza kujumuisha hii katika masharti ya huduma ya jukwaa.

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


    Si ya kutosha kwa nishani.

    Wakati ahadi inafanywa kwenye tawi kuu, ukaguzi wowote wa kiotomatiki wa hali za ahadi LAZIMA upite au upuuzwe kwa mikono. [OSPS-QA-03.01]
    Sanidi mfumo wa kudhibiti toleo wa mradi kuhitaji kuwa ukaguzi wote wa kiotomatiki wa hali upite au kuhitaji thibitisho la mikono kabla ya ahadi kuweza kuunganishwa kwenye tawi kuu. Inashauriwa kuwa ukaguzi wowote wa hiari HAUPASWI kusanidiwa kama mahitaji ya kupita au kushindwa ambayo waidhinishaji wanaweza kuwa na msukumo wa kupuuza.

    master has no branch protection (GitHub API returns 404 'Branch not protected') and no branch ruleset applies to it (rules/branches/master returns an empty list; the only active ruleset protects release tags). CI, CodeQL and dependency-review workflows run on pushes and PRs, but nothing requires their status checks to pass before a commit lands: the sole maintainer pushes directly to master as the normal workflow, so a failing check cannot block a change. Adding required status checks on master would close this gap. See https://github.com/Progressiverobot/hmailserver/blob/master/.github/workflows/ci.yml


    Ya kutosha kwa nishani!

    Kabla ya ahadi kukubalika, mifululizo ya CI/CD ya mradi LAZIMA iendeshe angalau seti moja ya majaribio ya kiotomatiki kuhakikisha mabadiliko yanakidhi matarajio. [OSPS-QA-06.01]
    Majaribio ya kiotomatiki yanapaswa kuendeshwa kabla ya kuunganisha kila moja kwenye tawi kuu. Seti ya majaribio inapaswa kuendeshwa katika mfululizo wa CI/CD na matokeo yanapaswa kuonekana kwa wachangiaji wote. Seti ya majaribio inapaswa kuendeshwa katika mazingira thabiti na inapaswa kuendeshwa kwa njia inayoruhusu wachangiaji kuendesha majaribio kienyeji. Mifano ya seti za majaribio ni pamoja na majaribio ya kitengo, majaribio ya uunganishaji, na majaribio ya mwisho-hadi-mwisho.

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


    Ya kutosha kwa nishani!

    Mradi ulipotoa toleo, nyaraka za mradi LAZIMA zijumuishe nyaraka za muundo zinazoonyesha matendo yote na watendaji ndani ya mfumo. [OSPS-SA-01.01]
    Jumuisha miundo katika nyaraka za mradi inayoeleza matendo na watendaji. Watendaji ni pamoja na mfumo wowote mdogo au kipengele ambacho kinaweza kuathiri sehemu nyingine katika mfumo. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

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


    Ya kutosha kwa nishani!

    Mradi ulipotoa toleo, nyaraka za mradi LAZIMA zijumuishe maelezo ya kiolesura vyote vya nje vya programu vya mali za programu zilizotolewa. [OSPS-SA-02.01]
    Eleza kiolesura vyote vya programu (APIs) vya mali za programu zilizotolewa, ukieleza jinsi watumiaji wanaweza kuingiliana na programu na data gani inatarajiwa au inazalishwa. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

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


    Ya kutosha kwa nishani!

    Mradi ulipotoa toleo, mradi LAZIMA ufanye tathmini ya usalama ili kuelewa matatizo ya uwezekano wa usalama ambayo ni ya uwezekano zaidi na yenye athari kubwa ambayo yangeweza kutokea ndani ya programu. [OSPS-SA-03.01]
    Kufanya tathmini ya usalama huwaelimisha wajumbe wa mradi na pia watumiaji wa chini kwamba mradi unaelewa matatizo ambayo yangeweza kutokea ndani ya programu. Kuelewa vitisho ambavyo vingeweza kutambuliwa husaidia mradi kudhibiti na kushughulikia hatari. Habari hii ni muhimu kwa watumiaji wa chini ili kuonyesha ujuzi wa usalama na mazoea ya mradi. Hakikisha hii inasasishwa kwa vipengele vipya au mabadiliko ya kuvunja.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zijumuishe sera ya ufichuzi ulioratibiwa wa udhaifu (coordinated vulnerability disclosure, CVD), yenye muda maalum wa kujibu. [OSPS-VM-01.01]
    Unda faili ya SECURITY.md mzizini mwa saraka, ikielezea sera ya mradi ya ufichuaji wa udhaifu wa pamoja. Jumuisha njia ya kuripoti udhaifu. Weka matarajio ya jinsi mradi utajibu na kushughulikia masuala yaliyoripotiwa.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zitoe njia ya kuripoti udhaifu kwa faragha moja kwa moja kwa anwani za mawasiliano za usalama ndani ya mradi. [OSPS-VM-03.01]
    Toa njia kwa watafiti wa usalama kuripoti udhaifu kwa faragha kwa mradi. Hii inaweza kuwa anwani ya barua pepe mahususi, fomu ya wavuti, zana maalum za VCS, anwani za barua pepe kwa mawasiliano ya usalama, au mbinu nyingine.

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


    Ya kutosha kwa nishani!

    Nyaraka za mradi LAZIMA zichapishe hadharani takwimu kuhusu udhaifu uliogunduliwa. [OSPS-VM-04.01]
    Toa habari kuhusu udhaifu unaojulikana katika kituo cha hadharani kinachoweza kutabirika, kama vile ingizo la CVE, chapisho la blogi, au njia nyingine. Kwa kiwango kinachowezekana, habari hii inapaswa kujumuisha toleo(matoleo) lililoathirika, jinsi mtumiaji anavyoweza kubaini kama wanaathirika, na maelekezo ya kuzuia au kurekebisha.

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



Unaweza kutumia zana na mifumo ya AI kupendekeza mabadiliko kupitia URL rahisi, kama vile https://www.bestpractices.dev/sw/projects/14187/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Angalia mfumo wetu wa mapendekezo ya otomatiki kwa jinsi ya kufanya hivyo. Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua Progressive Robot na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Progressive Robot.
Ingizo liliundwa siku 2026-08-21 05:37:27 UTC, iliyosasishwa mara ya mwisho siku 2026-09-12 02:50:23 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-08-21 17:17:16 UTC.