Resumo

  • A RFC 9991 define relatórios DMARC detalhados sobre uma mensagem que falhou ou um grupo de falhas semelhantes, normalmente mais rápidos e potencialmente mais sensíveis do que um relatório agregado.
  • Os parâmetros ruf e fo expressam um pedido do proprietário do domínio. O receptor de correio ainda escolhe quais relatórios, se houver algum, enviará segundo sua política, a falha observada e suas obrigações de privacidade e segurança.
  • Daniel Kade propõe um recibo de divulgação com finalidade limitada: ele registra seleção, redação, agrupamento, limitação, transporte, acesso e descarte, mas não guarda corpo, endereços, credenciais nem carga maliciosa.

O arquivo que resolve a falha e cria outra

Uma equipe vê assinaturas DKIM deixarem de alinhar depois de uma alteração operacional. A linha agregada confirma a anomalia, mas não revela se o motivo é um seletor errado, uma transformação em trânsito, um remetente não autorizado ou uma falha momentânea de verificação. Um bloco de cabeçalho original pode encerrar a investigação em minutos.

O mesmo bloco pode expor destinatário, servidor interno, rota de encaminhamento, participação em lista ou uma relação que o domínio remetente desconhecia. Se o corpo acompanha o relato, entram ainda decisões de pessoal, agendas, planos de produto, credenciais, links de rastreamento e anexos perigosos. O dado de maior utilidade diagnóstica pode ser exatamente o de maior custo de divulgação.

Seria cômodo concluir que o proprietário pediu, portanto o receptor deve entregar. A RFC 9991 evita essa conversão. O padrão coordena um pedido e um formato; não concede posse sobre correspondência que o solicitante talvez nem tenha enviado ou soubesse que existia.

Publicar um pedido não conclui a decisão

A RFC 9991 é uma especificação Standards Track de maio de 2026. Ao lado do novo núcleo do DMARC e do documento de relatórios agregados, ela substitui as partes pertinentes da RFC 7489 e atualiza as regras anteriores para relatos de falha de autenticação.

No registro de política DMARC, o proprietário publica destinos ruf e opções fo. Essas opções indicam onde se deseja receber relatórios e quais condições interessam. Elas não são um canal de comando. A organização receptora determina, conforme a falha, a opção solicitada e a própria política, quais tipos de relatório transmitirá — inclusive nenhum.

Há, assim, três decisões independentes. O proprietário decide pedir e apontar um destino. O receptor decide se divulga e até onde. O consumidor decide quem vê, como analisa, por quanto tempo conserva e se transfere adiante. Uma verificação bem-sucedida em uma etapa não assina pelas etapas seguintes.

Um relatório de falha pode retratar uma mensagem ou reunir incidentes com causa parecida; também pode chegar quase imediatamente e conter muito mais detalhe que um agregado. A velocidade reduz o tempo de diagnóstico e, simultaneamente, o intervalo disponível para avaliar privacidade, confirmar destino e conter material perigoso. A automação responsável preserva as fronteiras entre essas decisões.

Mais detalhe pertence a outra classe de evidência

O Abuse Reporting Format separa explicação legível, campos de retorno processáveis e material da mensagem original em partes MIME distintas. A RFC 9991 acrescenta significado próprio do DMARC, como Identity-Alignment, informações de DKIM, dados DNS de SPF e um tipo de falha de autenticação.

O alcance de Identity-Alignment é estreito. Ele indica os mecanismos que não autenticaram uma identidade alinhada, ou none quando os mecanismos tentados tiveram êxito. Não explica a causa da quebra de assinatura, não prova que o autor aparente enviou a mensagem, não determina que o conteúdo é malicioso, não valida uma disposição posterior e não autoriza a divulgação.

Cabeçalhos ou corpo originais podem responder ao que os campos derivados não respondem. Também introduzem fatos fora da finalidade inicial. Ao serem copiados para um relatório, ganham novo custodiante, nova população com acesso e novo prazo de retenção. Chamar o fluxo de “forense” descreve uma finalidade; não transforma qualquer conteúdo em categoria ilimitada de dados.

Autorização externa prova disposição, não direito ao conteúdo

Um registro de política pode encaminhar relatórios para fora do Domínio Organizacional. A RFC 9991 reutiliza o procedimento de autorização externa dos relatórios agregados: o destino publica informação DNS para demonstrar que aceita receber relatos pelo domínio solicitante. Assim, um proprietário não pode unilateralmente direcionar tráfego a um terceiro alheio.

O controle é indispensável e limitado. Ele não demonstra que cada relato está correto, que todo campo é necessário, que o consumidor dispõe de base jurídica ou contratual, nem que o encaminhamento seguinte está controlado. A especificação observa que um endereço aparentemente interno também pode reenviar dados para fora. A leitura do destino anunciado não garante o ponto final real.

Por isso, a governança precisa separar a elegibilidade do destino da proporcionalidade de uma divulgação concreta. Aceitar certo tipo de relatório não equivale a obter tudo que o gerador possui. Quando esses dois recibos se confundem, a disponibilidade técnica vira uma alegação indevida de autoridade.

Minimizar é preservar a resposta, não todos os dados

A RFC 9991 recomenda limitar objetivo e duração, controlar cuidadosamente as URIs, redigir corpo e cabeçalhos e usar transporte seguro. Ela reconhece ainda que muitos grandes provedores restringem ou desativam relatos de falha porque o custo de privacidade é substantivo.

Redação não é sinônimo de apagamento. A RFC 6590 descreve uma transformação estável e resistente a colisões que permite saber se dois valores ocultos eram iguais, sem revelar o original. A correlação ajuda a agrupar incidentes; também cria vinculabilidade. Se o mesmo segredo e a mesma transformação atravessam finalidades e anos, o pseudônimo se torna um índice persistente de relações.

Uma implementação prudente registra versão e escopo da transformação, separa ou gira chaves conforme a finalidade e impede que valores crus e redigidos se acumulem no mesmo ambiente amplo de logs. Quando a investigação não exige correlação, não deve produzir um token estável por hábito. Uma classe de falha, um identificador descartável ou a ausência de relato podem ser suficientes.

O teste de minimização deve partir da pergunta diagnóstica. Retirar pouco demais transporta correspondência privada sem necessidade. Retirar demais cria um relatório inútil que ainda custa receber, analisar e proteger. A resposta é uma escolha documentada e expirável, não uma lista universal de campos.

Limites de volume tornam o silêncio ambíguo

Relatórios de falha podem servir de vetor de negação de serviço. Um atacante envia grandes volumes aparentando usar o domínio da vítima e induz receptores participantes a dirigir relatos à vítima ou ao seu prestador. A RFC 9991 exige limitação de saída e permite agrupar incidentes semelhantes ou descartar o excesso. A finalidade é mostrar condições diferentes, não contar cada mensagem fracassada.

Logo, o consumidor não pode interpretar o fluxo como livro completo de eventos. Silêncio pode significar ausência de falha qualificada, não participação, decisão de privacidade, agrupamento, descarte por limite, falha de transporte ou expiração da janela. Um pico pode representar nova condição, mudança na política de relato ou uma inundação induzida.

Antes de inferir tendências de volume, o consumidor precisa do contexto declarado de amostragem, agrupamento e limites do gerador. Este, por sua vez, pode registrar contagens por razão e janela curta sem recriar um arquivo sensível por mensagem. Explicar a ausência não exige preservar aquilo que se decidiu não divulgar.

O relatório também é entrada não confiável

Como reproduz material de uma mensagem que falhou, o relatório pode conter spam, phishing, malware, links enganosos e anexos. O padrão recomenda isolamento, sandbox, segmentação e acesso apenas por pessoal treinado e autorizado. Encaminhar esse conteúdo a caixas comuns, prévias de tíquete ou indexadores gerais amplia o incidente que se pretendia investigar.

Alinhar o próprio fluxo de relatórios ao DMARC ajuda a vincular a identidade de transporte ao domínio esperado. Não torna seguro o conteúdo incorporado, não prova todas as afirmações dos campos estruturados e não autoriza qualquer analista a ler a mensagem original. Autenticação, segurança de conteúdo, legitimidade do acesso e permissão operacional continuam controles distintos.

Parte da melhor automação é negativa: remover conteúdo ativo, rejeitar estruturas MIME não suportadas, pôr anexos em quarentena, limitar descompressão e processamento e impedir busca geral. Um parser que termina sem erro apenas inicia a custódia controlada.

Um recibo de divulgação limitado à finalidade

Proponho um recibo compacto para cada política de divulgação e para cada liberação excepcional. Trata-se de orientação editorial de governança, não de novo requisito do IETF.

O recibo começa com domínio de política DMARC, horário e resultado da consulta DNS, destinos ruf, condição fo, resultado da autorização externa, versão da política do receptor, finalidade e data de expiração. Em seguida, indica classe de falha e se o caso é individual ou agrupado.

Ele enumera categorias selecionadas — não os valores — como campos derivados de autenticação, subconjunto de cabeçalhos de percurso, token de endereço redigido ou trecho limitado. Guarda método e versão de redação, escopo de correlação, regra de agrupamento, resultado do limite de volume, transporte seguro e erro de geração. No consumo, associa papel, fronteira de acesso, isolamento, prazo de retenção e evento de exclusão ou substituição a uma decisão responsável.

O recibo não pode virar caixa postal paralela. Corpo, partes locais de endereços, destinatários, credenciais, URLs maliciosas ativas e anexos ficam fora. Impressões digitais de conteúdo só cabem quando risco e finalidade as justificam, com escopo e validade explícitos.

Quando alguém perguntar depois por que aqueles bytes cruzaram a fronteira, a resposta deixará de ser “porque o DNS pediu”. Haverá uma cadeia visível de escolhas locais e limitadas.

Fontes

  1. Lu Heng — Soberania de dados: realidade técnica e prática
  2. Lu Heng — Por que a BTW Media existe
  3. Lu Heng — The Policy Mirror
  4. IANA — Parâmetros do Messaging Abuse Reporting Format
  5. Página informativa da RFC 9991
  6. RFC 5322 — Formato de mensagens da Internet
  7. RFC 5965 — Formato extensível de relatórios de abuso
  8. RFC 6590 — Redação de dados sensíveis em relatos de abuso
  9. RFC 6591 — Relato de falha de autenticação com ARF
  10. RFC 6650 — Criação e uso de relatos de retorno
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — Relatórios agregados DMARC
  14. RFC 9991 — Relatórios de falha DMARC