hMailServer

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo na página do seu projeto! O status do selo se parece com isto: O nível do selo para o projeto 14949 é gold Aqui está como incorporá-lo:
Você pode mostrar o status do seu selo incorporando isto no seu arquivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14949/badge)](https://www.bestpractices.dev/projects/14949)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/badge"></a>


Estes são os critérios de nível Prata. Você também pode visualizar os critérios de nível Aprovação ou Ouro.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos 17/17 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    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.

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

    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.

  • Pré-requisitos


    Suficiente para um badge!

    O projeto DEVE alcançar um distintivo de nível aprovado. [achieve_passing]

  • Conteúdo básico do site do projeto


    Suficiente para um badge!

    As informações sobre como contribuir DEVEM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação obrigatório). (URL obrigatória) [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


  • Supervisão do projeto


    Suficiente para um badge!

    O projeto DEVERIA ter um mecanismo legal onde todos os desenvolvedores de quantidades não triviais de software do projeto afirmem que estão legalmente autorizados a fazer essas contribuições. A abordagem mais comum e facilmente implementada para fazer isso é usando um Developer Certificate of Origin (DCO), onde os usuários adicionam "signed-off-by" em seus commits e o projeto faz link para o site do DCO. No entanto, isso PODE ser implementado como um Contributor License Agreement (CLA) ou outro mecanismo legal. (URL obrigatória) [dco]
    O DCO é o mecanismo recomendado porque é fácil de implementar, rastreado no código-fonte e o git suporta diretamente um recurso "signed-off" usando "commit -s". Para ser mais eficaz, é melhor que a documentação do projeto explique o que "signed-off" significa para aquele projeto. Um CLA é um acordo legal que define os termos sob os quais obras intelectuais foram licenciadas para uma organização ou projeto. Um contributor assignment agreement (CAA) é um acordo legal que transfere direitos em uma obra intelectual para outra parte; os projetos não são obrigados a ter CAAs, já que ter CAA aumenta o risco de que contribuidores potenciais não contribuam, especialmente se o receptor for uma organização com fins lucrativos. Os CLAs da Apache Software Foundation (a licença de contribuidor individual e o CLA corporativo) são exemplos de CLAs, para projetos que determinam que os riscos desses tipos de CLAs para o projeto são menores do que seus benefícios.

    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


    Suficiente para um badge!

    O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave). (URL obrigatória) [governance]
    É necessário haver alguma forma bem estabelecida e documentada de tomar decisões e resolver disputas. Em projetos pequenos, isso pode ser tão simples quanto "o proprietário do projeto e líder toma todas as decisões finais". Existem vários modelos de governança, incluindo ditador benevolente e meritocracia formal; para mais detalhes, consulte Modelos de governança. Tanto abordagens centralizadas (por exemplo, mantenedor único) quanto descentralizadas (por exemplo, grupo de mantenedores) foram usadas com sucesso em projetos. As informações de governança não precisam documentar a possibilidade de criar um fork do projeto, já que isso é sempre possível para projetos FLOSS.

    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


    Suficiente para um badge!

    O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. (URL obrigatória) [code_of_conduct]
    Os projetos podem ser capazes de melhorar a civilidade de sua comunidade e estabelecer expectativas sobre conduta aceitável adotando um código de conduta. Isso pode ajudar a evitar problemas antes que ocorram e tornar o projeto um lugar mais acolhedor para encorajar contribuições. Isso deve se concentrar apenas no comportamento dentro da comunidade/local de trabalho do projeto. Exemplos de códigos de conduta são o código de conduta do kernel Linux, o Contributor Covenant Code of Conduct, o Código de Conduta Debian, o Código de Conduta Ubuntu, o Código de Conduta Fedora, o Código de Conduta GNOME, o Código de Conduta da Comunidade KDE, o Código de Conduta da Comunidade Python, A Diretriz de Conduta da Comunidade Ruby e O Código de Conduta do Rust.

    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


    Suficiente para um badge!

    O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma. (URL obrigatória) [roles_responsibilities]
    A documentação para governança e papéis e responsabilidades pode estar em um único lugar.

    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


    Suficiente para um badge!

    O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS). (URL obrigatória) [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


    Suficiente para um badge!

    O projeto DEVERIA ter um "bus factor" de 2 ou mais. (URL obrigatória) [bus_factor]
    Um "bus factor" (também conhecido como "truck factor") é o número mínimo de membros do projeto que precisam desaparecer repentinamente de um projeto ("ser atropelados por um ônibus") antes que o projeto pare devido à falta de pessoal conhecedor ou competente. A ferramenta truck-factor pode estimar isso para projetos no GitHub. Para mais informações, consulte Assessing the Bus Factor of Git Repositories de 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


  • Documentação


    Suficiente para um badge!

    O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano. (URL obrigatória) [documentation_roadmap]
    O projeto pode não alcançar o roadmap, e isso é aceitável; o objetivo do roadmap é ajudar usuários e contribuidores potenciais a entender a direção pretendida do projeto. Não precisa ser detalhado.

    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


    Suficiente para um badge!

    O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A). (URL obrigatória) [documentation_architecture]
    Uma arquitetura de software explica as estruturas fundamentais de um programa, ou seja, os principais componentes do programa, os relacionamentos entre eles e as principais propriedades desses componentes e relacionamentos.

    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


    Suficiente para um badge!

    O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança"). (URL obrigatória) [documentation_security]
    Estes são os requisitos de segurança que o software deve atender.

    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


    Suficiente para um badge!

    O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software. (URL obrigatória) [documentation_quick_start]
    A ideia é mostrar aos usuários como começar e fazer o software fazer qualquer coisa. Isso é extremamente importante para que potenciais usuários comecem.

    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


    Suficiente para um badge!

    O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume. [documentation_current]
    A documentação PODE incluir informações sobre diferenças ou mudanças entre versões do software e/ou link para versões antigas da documentação. A intenção deste critério é que um esforço seja feito para manter a documentação consistente, não que a documentação deva ser perfeita.

    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


    Suficiente para um badge!

    A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada. (URL obrigatória) [documentation_achievements]
    Uma conquista é qualquer conjunto de critérios externos que o projeto trabalhou especificamente para atender, incluindo alguns selos. Esta informação não precisa estar na página inicial do site do projeto. Um projeto usando o GitHub pode colocar conquistas na página inicial do repositório adicionando-as ao arquivo README.

    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


  • Acessibilidade e internacionalização


    Suficiente para um badge!

    O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo. [accessibility_best_practices]
    Para aplicações web, veja as Diretrizes de Acessibilidade para Conteúdo Web (WCAG 2.0) e seu documento de apoio Understanding WCAG 2.0; veja também informações de acessibilidade do W3C. Para aplicações GUI, considere usar as diretrizes de acessibilidade específicas do ambiente (como Gnome, KDE, XFCE, Android, iOS, Mac e Windows). Algumas aplicações TUI (por exemplo, programas `ncurses`) podem fazer certas coisas para se tornarem mais acessíveis (como a configuração `force-arrow-cursor` do `alpine`). A maioria das aplicações de linha de comando são bastante acessíveis como estão. Este critério é frequentemente N/A, por exemplo, para bibliotecas de programas. Aqui estão alguns exemplos de ações a tomar ou questões a considerar:
    • Forneça alternativas de texto para qualquer conteúdo não textual para que possa ser transformado em outras formas que as pessoas precisam, como letras grandes, braille, fala, símbolos ou linguagem mais simples (diretriz WCAG 2.0 1.1)
    • A cor não é usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. (diretriz WCAG 2.0 1.4.1)
    • A apresentação visual de texto e imagens de texto tem uma razão de contraste de pelo menos 4.5:1, exceto para texto grande, texto incidental e logotipos (diretriz WCAG 2.0 1.4.3)
    • Torne toda a funcionalidade disponível a partir de um teclado (diretriz WCAG 2.1)
    • Um projeto GUI ou baseado na web DEVERIA testar com pelo menos um leitor de tela nas plataformas de destino (por exemplo, NVDA, Jaws ou WindowEyes no Windows; VoiceOver no Mac & iOS; Orca no Linux/BSD; TalkBack no Android). Programas TUI PODEM trabalhar para reduzir o redesenho para evitar leitura redundante por leitores de tela.

    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


    Suficiente para um badge!

    O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A). [internationalization]
    Localização "refere-se à adaptação de um produto, aplicação ou conteúdo de documento para atender aos requisitos de idioma, cultura e outros de um mercado-alvo específico (um locale)". Internacionalização é o "projeto e desenvolvimento de um produto, aplicação ou conteúdo de documento que permite fácil localização para públicos-alvo que variam em cultura, região ou idioma". (Veja "Localization vs. Internationalization" do W3C.) O software atende a este critério simplesmente sendo internacionalizado. Nenhuma localização para outro idioma específico é necessária, pois uma vez que o software foi internacionalizado, é possível para outros trabalharem na localização.

    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


  • Outro


    Suficiente para um badge!

    Se os sites do projeto (site, repositório e URLs de download) armazenam senhas para autenticação de usuários externos, as senhas DEVEM ser armazenadas como hashes iterados com um salt por usuário usando um algoritmo de extensão de chave (iterado) (por exemplo, Argon2id, Bcrypt, Scrypt ou PBKDF2). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A). [sites_password_security]
    Observe que o uso do GitHub atende a este critério. Este critério aplica-se apenas a senhas usadas para autenticação de usuários externos nos sites do projeto (também conhecida como autenticação de entrada). Se os sites do projeto precisam fazer login em outros sites (também conhecida como autenticação de saída), eles podem precisar armazenar tokens de autorização para esse propósito de forma diferente (já que armazenar um hash seria inútil). Isso aplica o critério crypto_password_storage aos sites do projeto, semelhante a 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.


 Controle de Mudanças 1/1 ●

  • Versões anteriores


    Suficiente para um badge!

    O projeto DEVE manter as versões mais antigas do produto mais frequentemente usadas ou fornecer um caminho de atualização para versões mais recentes. Se o caminho de atualização for difícil, o projeto DEVE documentar como realizar a atualização (por exemplo, as interfaces que mudaram e etapas sugeridas detalhadas para ajudar na atualização). [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


 Relatórios 3/3 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE usar um rastreador de questões para rastrear questões individuais. [report_tracker]

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


  • Processo de relato de vulnerabilidades


    Suficiente para um badge!

    O projeto DEVE dar crédito ao(s) relator(es) de todos os relatórios de vulnerabilidade resolvidos nos últimos 12 meses, exceto para o(s) relator(es) que solicitarem anonimato. Se não houve vulnerabilidades resolvidas nos últimos 12 meses, selecione "não aplicável" (N/A). (URL obrigatória) [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


    Suficiente para um badge!

    O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades. (URL obrigatória) [vulnerability_response_process]
    Isso está fortemente relacionado a vulnerability_report_process, que exige que haja uma forma documentada de relatar vulnerabilidades. Também está relacionado a vulnerability_report_response, que exige resposta a relatos de vulnerabilidades dentro de um determinado prazo.

    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


 Qualidade 19/19 ●

  • Padrões de codificação


    Suficiente para um badge!

    O projeto DEVE identificar os guias de estilo de codificação específicos para as linguagens primárias que utiliza, e exigir que as contribuições geralmente estejam em conformidade com eles. (URL obrigatória) [coding_standards]
    Na maioria dos casos, isso é feito referenciando algum(ns) guia(s) de estilo existente(s), possivelmente listando diferenças. Esses guias de estilo podem incluir maneiras de melhorar a legibilidade e maneiras de reduzir a probabilidade de defeitos (incluindo vulnerabilidades). Muitas linguagens de programação têm um ou mais guias de estilo amplamente utilizados. Exemplos de guias de estilo incluem guias de estilo do Google e Padrões de Codificação SEI CERT.

    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


    Suficiente para um badge!

    O projeto DEVE aplicar automaticamente seu(s) estilo(s) de codificação selecionado(s) se houver pelo menos uma ferramenta FLOSS que possa fazer isso na(s) linguagem(ns) selecionada(s). [coding_standards_enforced]
    Isso PODE ser implementado usando ferramenta(s) de análise estática e/ou forçando o código através de reformatadores de código. Em muitos casos, a configuração da ferramenta está incluída no repositório do projeto (já que projetos diferentes podem escolher configurações diferentes). Os projetos PODEM permitir exceções de estilo (e normalmente permitirão); onde ocorrem exceções, elas DEVEM ser raras e documentadas no código em suas localizações, para que essas exceções possam ser revisadas e para que as ferramentas possam tratá-las automaticamente no futuro. Exemplos de tais ferramentas incluem ESLint (JavaScript), Rubocop (Ruby) e 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


  • Sistema de compilação funcional


    Suficiente para um badge!

    Os sistemas de compilação para binários nativos DEVEM honrar as variáveis de compilador e vinculador (ambiente) relevantes passadas para eles (por exemplo, CC, CFLAGS, CXX, CXXFLAGS e LDFLAGS) e passá-las para invocações de compilador e vinculador. Um sistema de compilação PODE estendê-las com flags adicionais; ele NÃO DEVE simplesmente substituir valores fornecidos pelos seus próprios. Se nenhum binário nativo estiver sendo gerado, selecione "não aplicável" (N/A). [build_standard_variables]
    Deve ser fácil habilitar recursos especiais de compilação como Address Sanitizer (ASAN), ou cumprir as melhores práticas de proteção de distribuição (por exemplo, ativando facilmente flags de compilador para fazê-lo).

    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


    Suficiente para um badge!

    O sistema de compilação e instalação DEVERIA preservar informações de depuração se elas forem solicitadas nas flags relevantes (por exemplo, "install -s" não é usado). Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_preserve_debug]
    Por exemplo, definir CFLAGS (C) ou CXXFLAGS (C++) deve criar as informações de depuração relevantes se essas linguagens forem usadas, e elas não devem ser removidas durante a instalação. Informações de depuração são necessárias para suporte e análise, e também úteis para medir a presença de recursos de proteção nos binários compilados.

    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


    Suficiente para um badge!

    O sistema de compilação do software produzido pelo projeto NÃO DEVE compilar recursivamente subdiretórios se houver dependências cruzadas nos subdiretórios. Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_non_recursive]
    As informações de dependência interna do sistema de compilação do projeto precisam ser precisas, caso contrário, mudanças no projeto podem não compilar corretamente. Compilações incorretas podem levar a defeitos (incluindo vulnerabilidades). Um erro comum em sistemas de compilação grandes é usar uma "compilação recursiva" ou "make recursivo", isto é, uma hierarquia de subdiretórios contendo arquivos fonte, onde cada subdiretório é compilado independentemente. A menos que cada subdiretório seja totalmente independente, isso é um erro, porque as informações de dependência estão incorretas.

    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


    Suficiente para um badge!

    O projeto DEVE ser capaz de repetir o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. Se nenhuma compilação ocorrer (por exemplo, linguagens de script onde o código fonte é usado diretamente em vez de ser compilado), selecione "não aplicável" (N/A). [build_repeatable]
    Usuários de GCC e clang podem achar útil a opção -frandom-seed; em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Mais sugestões podem ser encontradas no site reproducible build.

    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


  • Sistema de instalação


    Suficiente para um badge!

    O projeto DEVE fornecer uma maneira de instalar e desinstalar facilmente o software produzido pelo projeto usando uma convenção comumente utilizada. [installation_common]
    Exemplos incluem usar um gerenciador de pacotes (no nível do sistema ou da linguagem), "make install/uninstall" (suportando DESTDIR), um contêiner em formato padrão, ou uma imagem de máquina virtual em formato padrão. O processo de instalação e desinstalação (por exemplo, seu empacotamento) PODE ser implementado por terceiros, desde que seja FLOSS.

    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


    Suficiente para um badge!

    O sistema de instalação para usuários finais DEVE honrar convenções padrão para selecionar o local onde os artefatos compilados são escritos no momento da instalação. Por exemplo, se instalar arquivos em um sistema POSIX, ele DEVE honrar a variável de ambiente DESTDIR. Se não houver sistema de instalação ou convenção padrão, selecione "não aplicável" (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


    Suficiente para um badge!

    O projeto DEVE fornecer uma maneira para desenvolvedores em potencial instalarem rapidamente todos os resultados do projeto e ambiente de suporte necessário para fazer alterações, incluindo os testes e ambiente de teste. Isso DEVE ser realizado com uma convenção comumente utilizada. [installation_development_quick]
    Isso PODE ser implementado usando um contêiner gerado e/ou script(s) de instalação. Dependências externas normalmente seriam instaladas invocando gerenciador(es) de pacotes do sistema e/ou da linguagem, conforme external_dependencies.

    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


  • Componentes mantidos externamente


    Suficiente para um badge!

    O projeto DEVE listar dependências externas de uma forma processável por computador. (URL obrigatória) [external_dependencies]
    Tipicamente isso é feito usando as convenções do gerenciador de pacotes e/ou sistema de compilação. Note que isso ajuda a implementar installation_development_quick.

    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


    Suficiente para um badge!

    Os projetos DEVEM monitorar ou verificar periodicamente suas dependências externas (incluindo cópias de conveniência) para detectar vulnerabilidades conhecidas, e corrigir vulnerabilidades exploráveis ou verificá-las como não exploráveis. [dependency_monitoring]
    Isso pode ser feito usando uma ferramenta de análise de origem / ferramenta de verificação de dependências / ferramenta de análise de composição de software como OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis e Bundler-audit (para Ruby). Alguns gerenciadores de pacotes incluem mecanismos para fazer isso. É aceitável se a vulnerabilidade dos componentes não puder ser explorada, mas esta análise é difícil e às vezes é mais fácil simplesmente atualizar ou corrigir a parte.

    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


    Suficiente para um badge!

    "O projeto DEVE:
    1. facilitar a identificação e atualização de componentes mantidos externamente reutilizados; ou
    2. usar os componentes padrão fornecidos pelo sistema ou linguagem de programação.
    Então, se uma vulnerabilidade for encontrada em um componente reutilizado, será fácil atualizar esse componente." [updateable_reused_components]
    Uma maneira típica de atender a este critério é usar sistemas de gerenciamento de pacotes do sistema e da linguagem de programação. Muitos programas FLOSS são distribuídos com "bibliotecas de conveniência" que são cópias locais de bibliotecas padrão (possivelmente bifurcadas). Por si só, isso é bom. No entanto, se o programa *deve* usar essas cópias locais (bifurcadas), então atualizar as bibliotecas "padrão" como uma atualização de segurança deixará essas cópias adicionais ainda vulneráveis. Isso é especialmente um problema para sistemas baseados em nuvem; se o provedor de nuvem atualizar suas bibliotecas "padrão", mas o programa não as usar, então as atualizações na verdade não ajudam. Veja, por exemplo, "Chromium: Why it isn't in Fedora yet as a proper package" by 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


    Suficiente para um badge!

    O projeto DEVERIA evitar usar funções e APIs obsoletas ou desatualizadas onde alternativas FLOSS estejam disponíveis no conjunto de tecnologia que usa (sua "pilha de tecnologia") e para uma supermaioria dos usuários que o projeto suporta (para que os usuários tenham acesso pronto à alternativa). [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


  • Conjunto de testes automatizados


    Suficiente para um badge!

    Uma suíte de testes automatizada DEVE ser aplicada a cada check-in em um repositório compartilhado para pelo menos um branch. Esta suíte de testes DEVE produzir um relatório sobre sucesso ou falha do teste. [automated_integration_testing]
    Este requisito pode ser visto como um subconjunto de test_continuous_integration, mas focado apenas em testes, sem exigir integração contínua.

    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


    Suficiente para um badge!

    O projeto DEVE adicionar testes de regressão a uma suíte de testes automatizada para pelo menos 50% dos bugs corrigidos nos últimos seis meses. [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


    Suficiente para um badge!

    O projeto DEVE ter suíte(s) de teste automatizada(s) FLOSS que forneçam pelo menos 80% de cobertura de instruções se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. [test_statement_coverage80]
    Muitas ferramentas FLOSS estão disponíveis para medir cobertura de testes, incluindo gcov/lcov, Blanket.js, Istanbul, JCov e covr (R). Note que atender a este critério não é uma garantia de que a suíte de testes seja completa, em vez disso, falhar em atender a este critério é um forte indicador de uma suíte de testes pobre.

    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


  • Teste de novas funcionalidades


    Suficiente para um badge!

    O projeto DEVE ter uma política escrita formal de que, à medida que uma nova funcionalidade importante é adicionada, testes para a nova funcionalidade DEVEM ser adicionados a uma suíte de testes automatizada. [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


    Suficiente para um badge!

    O projeto DEVE incluir, em suas instruções documentadas para propostas de mudança, a política de que testes devem ser adicionados para novas funcionalidades importantes. [tests_documented_added]
    Contudo, mesmo uma regra informal é aceitável desde que os testes estejam sendo adicionados na prática.

    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


  • Sinalizadores de aviso


    Suficiente para um badge!

    Os projetos DEVEM ser maximamente rigorosos com avisos no software produzido pelo projeto, onde for prático. [warnings_strict]
    Alguns avisos não podem ser efetivamente habilitados em alguns projetos. O que é necessário é evidência de que o projeto está se esforçando para habilitar flags de avisos onde puder, de forma que erros sejam detectados cedo.

    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


 Segurança 13/13 ●

  • Conhecimento de desenvolvimento seguro


    Suficiente para um badge!

    O projeto DEVE implementar princípios de projeto seguro (de "know_secure_design"), quando aplicável. Se o projeto não está produzindo software, selecione "não aplicável" (N/A). [implement_secure_design]
    Por exemplo, os resultados do projeto devem ter padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão). Eles também devem ter mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável). Note que em alguns casos os princípios entrarão em conflito, caso em que uma escolha deve ser feita (por exemplo, muitos mecanismos podem tornar as coisas mais complexas, contrariando a "economia de mecanismo" / mantenha simples).

    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


  • Usar práticas criptográficas boas e básicas

    Observe que alguns softwares não precisam usar mecanismos criptográficos. Se o seu projeto produzir software que (1) inclui, ativa ou habilita funcionalidade de criptografia, e (2) pode ser liberado dos Estados Unidos (EUA) para fora dos EUA ou para um não cidadão dos EUA, você pode ser legalmente obrigado a tomar algumas etapas extras. Normalmente isso envolve apenas o envio de um e-mail. Para mais informações, consulte a seção de criptografia de Understanding Open Source Technology & US Export Controls.

    Suficiente para um badge!

    Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos ou modos com fraquezas sérias conhecidas (por exemplo, o algoritmo de hash criptográfico SHA-1 ou o modo CBC em SSH). [crypto_weaknesses]
    Preocupações sobre o modo CBC em SSH são discutidas em CERT: SSH CBC vulnerability.

    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


    Suficiente para um badge!

    O projeto DEVERIA suportar múltiplos algoritmos criptográficos, para que os usuários possam mudar rapidamente se um for quebrado. Algoritmos de chave simétrica comuns incluem AES, Twofish e Serpent. Alternativas comuns de algoritmos de hash criptográfico incluem SHA-2 (incluindo SHA-224, SHA-256, SHA-384 E SHA-512) e 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


    Suficiente para um badge!

    O projeto DEVE suportar o armazenamento de credenciais de autenticação (como senhas e tokens dinâmicos) e chaves criptográficas privadas em arquivos que são separados de outras informações (como arquivos de configuração, bancos de dados e logs), e permitir que os usuários as atualizem e substituam sem recompilação de código. Se o projeto nunca processar credenciais de autenticação e chaves criptográficas privadas, selecione "não aplicável" (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


    Suficiente para um badge!

    O software produzido pelo projeto DEVERIA suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVERIAM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (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


    Suficiente para um badge!

    O software produzido pelo projeto DEVERIA, se suportar ou usar TLS, suportar pelo menos a versão TLS 1.2. Observe que o predecessor do TLS era chamado SSL. Se o software não usar TLS, selecione "não aplicável" (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


    Suficiente para um badge!

    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado TLS por padrão ao usar TLS, incluindo em sub-recursos. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_certificate_verification]
    Observe que a verificação incorreta de certificado TLS é um erro comum. Para mais informações, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. e "Do you trust this application?" por 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


    Suficiente para um badge!

    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado antes de enviar cabeçalhos HTTP com informações privadas (como cookies seguros). Se o software não usar TLS, selecione "não aplicável" (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


  • Lançamento seguro


    Suficiente para um badge!

    O projeto DEVE assinar criptograficamente os lançamentos dos resultados do projeto destinados ao uso generalizado, e DEVE haver um processo documentado explicando aos usuários como eles podem obter as chaves públicas de assinatura e verificar a(s) assinatura(s). A chave privada para essa(s) assinatura(s) NÃO DEVE estar em site(s) usado(s) para distribuir diretamente o software ao público. Se os lançamentos não forem destinados ao uso generalizado, selecione "não aplicável" (N/A). [signed_releases]
    Os resultados do projeto incluem tanto o código-fonte quanto quaisquer entregáveis gerados quando aplicável (por exemplo, executáveis, pacotes e contêineres). Os entregáveis gerados PODEM ser assinados separadamente do código-fonte. Estes PODEM ser implementados como tags git assinadas (usando assinaturas digitais criptográficas). Os projetos PODEM fornecer resultados gerados separadamente de ferramentas como git, mas nesses casos, os resultados separados DEVEM ser assinados separadamente.

    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.


    Suficiente para um badge!

    É SUGERIDO que no sistema de controle de versão, cada tag de versão importante (uma tag que faz parte de um lançamento principal, lançamento menor ou corrige vulnerabilidades publicamente observadas) seja criptograficamente assinada e verificável conforme descrito em 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


  • Outras questões de segurança


    Suficiente para um badge!

    Os resultados do projeto DEVEM verificar todas as entradas de fontes potencialmente não confiáveis para garantir que sejam válidas (uma *lista de permissões*), e rejeitar entradas inválidas, se houver quaisquer restrições sobre os dados. [input_validation]
    Observe que comparar a entrada com uma lista de "formatos inválidos" (também conhecida como *lista de negação*) normalmente não é suficiente, porque os atacantes muitas vezes podem contornar uma lista de negação. Em particular, os números são convertidos em formatos internos e então verificados se estão entre o mínimo e o máximo (inclusive), e as strings de texto são verificadas para garantir que sejam padrões de texto válidos (por exemplo, UTF-8 válido, comprimento, sintaxe, etc.). Alguns dados podem precisar ser "qualquer coisa" (por exemplo, um carregador de arquivos), mas estes normalmente seriam raros.

    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


    Suficiente para um badge!

    Mecanismos de proteção DEVERIAM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. [hardening]
    Os mecanismos de proteção podem incluir cabeçalhos HTTP como Content Security Policy (CSP), flags de compilador para mitigar ataques (como -fstack-protector), ou flags de compilador para eliminar comportamento indefinido. Para nossos propósitos, o privilégio mínimo não é considerado um mecanismo de proteção (privilégio mínimo é importante, mas separado).

    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


    Suficiente para um badge!

    O projeto DEVE fornecer um caso de garantia que justifique por que seus requisitos de segurança são atendidos. O caso de garantia DEVE incluir: uma descrição do modelo de ameaças, identificação clara dos limites de confiança, um argumento de que os princípios de projeto seguro foram aplicados e um argumento de que fraquezas comuns de segurança na implementação foram combatidas. (URL obrigatória) [assurance_case]
    Um caso de garantia é "um corpo documentado de evidências que fornece um argumento convincente e válido de que um conjunto específico de reivindicações críticas sobre as propriedades de um sistema são adequadamente justificadas para uma dada aplicação em um dado ambiente" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Limites de confiança são fronteiras onde os dados ou a execução muda seu nível de confiança, por exemplo, os limites de um servidor em uma aplicação web típica. É comum listar princípios de projeto seguro (como Saltzer e Schroeer) e fraquezas comuns de segurança na implementação (como o OWASP top 10 ou CWE/SANS top 25), e mostrar como cada um é combatido. O caso de garantia do BadgeApp pode ser um exemplo útil. Isso está relacionado a documentation_security, documentation_architecture e 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


 Análise 2/2 ●

  • Análise estática de código


    Suficiente para um badge!

    O projeto DEVE usar pelo menos uma ferramenta de análise estática com regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. [static_analysis_common_vulnerabilities]
    Ferramentas de análise estática que são especificamente projetadas para procurar vulnerabilidades comuns são mais propensas a encontrá-las. Dito isso, usar quaisquer ferramentas estáticas normalmente ajudará a encontrar alguns problemas, então estamos sugerindo mas não exigindo isso para o nível de selo 'passing'.

    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


  • Análise dinâmica de código


    Suficiente para um badge!

    Se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) DEVE ser rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). [dynamic_analysis_unsafe]
    Exemplos de mecanismos para detectar problemas de segurança de memória incluem Address Sanitizer (ASAN) (disponível no GCC e LLVM), Memory Sanitizer e valgrind. Outras ferramentas potencialmente usadas incluem thread sanitizer e undefined behavior sanitizer. Assertivas generalizadas também funcionariam.

    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



Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/14949/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a christopher holloway e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: christopher holloway.
Entrada criada em 2026-09-26 05:28:20 UTC, última atualização em 2026-09-26 06:16:51 UTC. Selo de aprovação alcançado pela última vez em 2026-09-26 05:45:21 UTC.