Pergunte o que a atualização proposta realmente muda
A alegação de que uma plataforma oferece um DMARCbis a atualização deve identificar o padrão atual, o comportamento de implementação que está sendo alterado e a evidência de que a mudança funciona. Não deve ser aceito como uma solicitação para mudar um registro DNS para um registro inventado. DMARC versão. A corrente retida RFC 9989 ainda especifica o valor da versão que diferencia maiúsculas de minúsculas DMARC1 . Um novo documento de padrões e uma nova versão de implementação não são a mesma coisa que um token de nova versão na política publicada.
Este artigo propõe uma revisão de prontidão vinculada a padrões. Não afirma que EmailAuth implementa RFC 9989 completamente, que todos os receptores o adotaram ou que uma atualização foi realizada. Nenhum registro DNS , analisador, receptor ou configuração de produção foi alterado. A revisão deve separar as alterações normativas, as reivindicações de implementação do fornecedor e a interoperabilidade observada antes que alguém aprove uma implementação.
Rejeitar o atalho de mudança de versão
A definição de registro de política da RFC 9989 afirma que o único valor possível da tag de versão é DMARC1 e que um valor de versão diferente faz com que o registro seja ignorado no processamento especificado. Uma proposta para publicar v=DMARC2 não é, portanto, uma instrução de migração baseada em padrões desta RFC. Peça ao proponente para identificar a seção exata que apoia qualquer alteração de registro recomendada, em vez de confiar no rótulo do produto.
O mesmo cuidado se aplica à renomeação de uma configuração do painel. Uma configuração chamada DMARCbis pode ativar um recurso de analisador, um algoritmo de descoberta de políticas ou interpretação de relatórios, mas seu significado é específico do produto até ser documentado. Registre o comportamento real suportado, a versão de lançamento e as limitações. Não infira que a alternância de uma configuração atualiza os receptores externos, reescreve todos os registros corretamente ou verifica todos os fluxos de trabalho de envio legítimos.
Faça um inventário das mudanças nos padrões relevantes
Use a discussão sobre mudanças e as seções normativas da RFC 9989 para construir uma lista de verificação focada. Uma área importante é a política baseada em DNS e a descoberta de domínios organizacionais, incluindo a Caminhada na árvore DNS. Esse é um comportamento de implementação, não simplesmente uma nova string para inserir em um registro existente. Um fornecedor que solicita apoio deve explicar qual descoberta e alinhamento casos que ele trata e fornece evidências de escopo para a versão real do produto.
Outra mudança explícita é a remoção da tag pct da especificação atual. O Apêndice A.6 explica o histórico e introduz a tag de teste t com valores y e n, descrita como análoga em aplicação aos antigos valores pct 0 e 100. Isso não justifica uma substituição mecânica geral de cada valor percentual histórico ou uma promessa de que cada receptor implementa o novo comportamento. Revise a semântica atual exata e a população de implantação relevante antes de propor uma diferença de política.
Mantenha os requisitos de protocolo separados das regras de elegibilidade do provedor
Um provedor pode publicar requisitos de elegibilidade de produtos referentes a convenções de implantação existentes. Esses requisitos precisam de sua própria revisão de origem atual e não devem ser reescritos silenciosamente porque um documento de protocolo foi alterado. Por outro lado, uma instrução histórica do provedor não redefine o conteúdo normativo da RFC 9989 . Registre a diferença aparente, as datas de origem e a questão de implementação que precisa ser resolvida, em vez de fingir que as duas camadas são idênticas.
Este manuscrito não reivindica suporte de receptor universal para tag de teste, comportamento de caminhada em árvores ou qualquer outro recurso revisado. A avaliação da prontidão deve identificar quais componentes a organização controla e quais são externos. Um remetente pode atualizar sua própria implementação ou política somente dentro do escopo suportado; ele não pode forçar a atualização de todos os sistemas receptores. As conclusões de compatibilidade necessitam, portanto, de provas demonstradas e limitadas, em vez de uma suposição de adoção global.
Padrões de relatórios separados e prontidão do analisador
RFC 9990 define o relatório agregado DMARC como uma especificação separada. O avaliador de políticas e o analisador de ingestão de relatórios de uma plataforma podem ter diferentes requisitos de atualização. Pergunte quais formatos de relatórios, campos e comportamentos de validação são suportados e como os relatórios retidos mais antigos permanecem interpretáveis. Não presuma que a alteração de uma implementação de descoberta de política atualiza automaticamente todos os fluxos de trabalho de relatórios ou análises históricas.
Afixe a versão do produto e as referências de padrões retidos usadas para a avaliação. Se um analisador encontrar um campo ou variante de relatório sem suporte, seu comportamento deverá ser documentado e testado, em vez de interpretado silenciosamente como atividade zero. Preserve a proveniência do relatório original e distinga as observações faltantes dos resultados da autenticação. Nenhum analisador de relatório foi exercitado para este artigo e nenhum dispositivo de teste é representado como um relatório receptor real.
Construa uma matriz de padrões para implementação
Crie uma linha por requisito relevante com seção RFC, comportamento normativo, comportamento atual do produto, mudança proposta, componente afetado, referência de evidência e limitação não resolvida. Publicação separada de políticas de remetentes, avaliação de destinatários, descoberta de domínio organizacional, geração de relatórios e ingestão de relatórios. Uma plataforma pode desempenhar apenas algumas dessas funções, portanto as funções não suportadas devem ser marcadas fora do escopo, em vez de serem contadas como implementadas implicitamente.
Adicione casos representativos para políticas válidas existentes, valores de versão inválidos, limites de descoberta, relacionamentos de alinhamento e compatibilidade de relatórios quando aplicável. Os acessórios exatos devem ser projetados por um revisor qualificado de acordo com o texto normativo e a função suportada pelo produto. Este rascunho não fornece um conjunto de conformidade de implementação nem afirma que um pequeno conjunto de exemplos comprova a conformidade completa. Cada resultado observado precisa da retenção da entrada, da versão do produto e do comportamento esperado.
Vincule qualquer alteração de registro à prontidão do remetente
Se a avaliação propor uma mudança na política DNS , prepare uma comparação exata, registro de propriedade, aprovação comercial, plano de verificação e critérios de reversão. Mantenha os fluxos de trabalho de envio legítimos visíveis por meio de uma matriz de prontidão remetente por remetente. Uma atualização de padrões não prova que todos os fornecedores tenham autenticação alinhada ou que todos os fluxos de trabalho críticos continuarão inalterados. Não use um novo rótulo de implementação como motivo para ignorar a prontidão operacional.
Registre o que a mudança pode ou não demonstrar. Evidências oficiais DNS podem mostrar a publicação em um determinado momento; evidências confiáveis de mensagens recebidas podem mostrar um resultado de autenticação com escopo definido; relatórios agregados podem mostrar padrões dentro de sua cobertura retida. Nenhum por si só estabelece a interoperabilidade universal. O planejamento da reversão deve levar em conta o estado do cache e as diferenças de implementação externa, não apenas a capacidade de restaurar um arquivo de configuração antigo.
Diagnóstico fictício: um registro DMARC2 solicitado
Um fornecedor fictício propõe uma atualização e diz ao comprador para alterar o valor da versão da política para DMARC2. O comprador solicita a referência dos padrões e descobre que RFC 9989 ainda especifica DMARC1 . A mudança de versão proposta é rejeitada como não suportada, enquanto a revisão mais ampla da implementação continua: o fornecedor pode ter alterações legítimas no comportamento de descoberta ou relatório que necessitam de evidências separadas.
A equipe solicitaria uma matriz de preparação com escopo definido e resultados demonstrados para o lançamento real do produto, em vez de aceitar ou rejeitar toda a atualização com base em seu nome comercial. Este é um exercício de revisão fictício, não uma instrução real do fornecedor ou um defeito de produção observado. Nenhum registro foi publicado e nenhum receptor foi testado. O exemplo mostra como uma questão precisa de padrões pode separar um falso atalho de um trabalho de implementação potencialmente útil.
Exigir escopo demonstrado antes de concluir a atualização
Uma conclusão útil identifica as alterações implementadas relacionadas com as normas, as funções abrangidas, as provas retidas e a compatibilidade externa ainda desconhecida. Não se deve dizer que a organização agora utiliza a versão dois ou que todos os receptores se comportam de maneira uniforme. A atualização é uma avaliação de implementação e prontidão, não uma mudança universal.
O catálogo exige uma avaliação de prontidão vinculada a padrões e resultados de implementação demonstrados e com escopo definido. Esses resultados originais permanecem abertos. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também permanecem em aberto. Este rascunho fornece um método de revisão e um exemplo fictício, não evidências de conformidade, uma migração implementada ou uma reivindicação de suporte completo EmailAuth .