Summary

  • RFC 5235 normaliza verificações locais de spam e vírus, mas o zero de spamtest :percent reúne três estados: testado e limpo, não testado e execução indeterminada.
  • Decisões relevantes precisam de um recibo próprio para execução e proveniência, sem confundir o valor, o ramo Sieve, a ação escolhida e o efeito final.

O que desaparece antes do painel

Duas mensagens chegam ao mesmo campo. Uma atravessou um scanner atualizado; a outra passou por um caminho em que a análise estava desligada. Uma terceira foi tratada por uma implementação que não conhece o estado do teste. O modo percentual admite zero para todas.

O objetivo do RFC é permitir comparações entre mecanismos específicos de cada implementação. A normalização resolve o idioma da saída. Ela não reconstrói a identidade do processo, a cobertura da inspeção ou a razão de uma ausência.

Quando a organização guarda apenas o número, “sem evidência” pode adquirir a aparência de “comprovadamente limpo”.

Uma escala comum é um resumo

A implementação fornece uma cadeia normalizada. Texto próprio do mecanismo pode existir, mas depender dele elimina a portabilidade. O preço da regra reutilizável é reduzir detalhes locais.

O valor comum não costuma registrar scanner, versão, atualização das regras, perfil, representação inspecionada, anexos excluídos, falhas ou tempo esgotado. Ele é uma projeção para automação, não o prontuário do exame.

Automação e auditoria têm necessidades diferentes. A primeira quer poucas categorias estáveis; a segunda precisa de identidade, tempo e exceções. Manter um recibo de origem ao lado do valor preserva as duas funções.

O mesmo zero muda de sentido

Sem :percent, spamtest usa zero para não testado ou desconhecido e um para testado e definitivamente limpo. Com percentagem, zero também representa testado e limpo.

Salvar o dígito sem salvar a escala destrói sua proposição. Uma migração pode manter a aparência do painel e alterar o significado do histórico.

O teste relacional :count faz uma pergunta separada. Um significa que a verificação foi realizada; zero significa que não foi ou que o Sieve não consegue determinar. Isso prova uma fronteira de execução, mas não identifica o motor, sua atualidade, o conteúdo examinado ou a autenticidade do canal.

O campo que decide precisa de proteção

Resultados podem ser transportados em cabeçalhos privados. RFC 5235 exige que somente o processo legítimo de verificação os forneça e que remetentes ou intermediários não consigam falsificá-los.

Quem escreve um campo que direciona a regra possui influência operacional. Por isso, proveniência não é decoração. Ainda assim, autenticidade não garante qualidade: o RFC recomenda manter os scanners atuais e reconhece que a detecção de vírus não é perfeita. Um resultado legítimo e obsoleto continua obsoleto.

Não existe um único sucesso

O valor pertence ao teste. A comparação decide um ramo. O script escolhe uma ação. O sistema tenta executá-la; armazenamento, transferência ou rejeição geram outros recibos; a experiência do destinatário vem depois.

Zero não comprova varredura. Ramo selecionado não comprova ação concluída. Mensagem armazenada não comprova que uma pessoa a leu em segurança. Cada afirmação deve conservar evidência sobre o próprio objeto.

O mecanismo singular de RFC 5235 está antes da ação: é a perda de contexto quando um exame local vira resultado portátil.

Limites do registro

As fontes não apresentam fornecedor atual, implantação, taxa de erro, campanha ou incidente. O registro da IANA demonstra registro das extensões, não adoção. Nem todo zero precisa levar a bloqueio: um fluxo de baixo impacto pode aceitar incerteza. Essa escolha, porém, deve ser registrada como aceitação de risco, não como prova de limpeza.

A escala de virustest distingue desconhecido, limpo, neutralizado, possível e definitivo. Mesmo assim, cada estado depende de um processo cuja cobertura e atualidade vivem fora da escala.

Dois recibos antes da ação

O recibo de resultado deve conter extensão, escala, valor, comparação, ramo e versão do script. O recibo de execução deve conter se o teste ocorreu, scanner, regras, atualização, objeto inspecionado, exclusões, erros, canal confiável e responsável pela política.

Depois, registre ação e desfecho separadamente. Não testado, desconhecido, parcial e tempo esgotado devem permanecer estados legítimos. Convertê-los em “limpo” para preencher um campo numérico destrói a prova necessária para uma revisão.

A doutrina de realidade operacional de Lu Heng exige também um principal atribuível. O nome do protocolo não decide quanto de ambiguidade é aceitável; uma pessoa responsável deve fazê-lo.

Sources

Registro normativo adicional

  1. Texto do RFC 5235
  2. Página informativa
  3. RFC 5235 no Datatracker
  4. Histórico do RFC 5235
  5. Errata do RFC 5235
  6. Documentos que citam RFC 5235