Resumo

  • No RFC 5293, testes e ações comuns usam o cabeçalho corrente; notificações de disposição e o keep implícito causado por erro usam o cabeçalho original intacto.
  • Mesmo com bytes diferentes, original e editado são a mesma mensagem para eliminar duplicatas; a evidência precisa identificar visão, ação e resultado.

O incidente era uma perda de contexto

Um gateway removia marcas de aprovação recebidas, acrescentava sua classificação e encaminhava a mensagem. O painel registrava sucesso. Quando uma fraude foi contestada, o time encontrou três registros diferentes e chamou isso de corrupção.

addheader e deleteheader explicam o desvio. A primeira ação acrescenta no início por padrão ou no fim com :last. A segunda pode remover todas as ocorrências ou a posição escolhida por :index. A contagem ocorre antes da comparação do valor, e cada remoção muda os índices seguintes. O cabeçalho é um estado em movimento, não uma fotografia única.

Cada ação tem sua visão autorizada

Testes como exists e header, a ação vacation e operações de armazenar, enviar ou alterar veem o estado corrente. Mudanças também atravessam scripts incluídos. Já MDN, DSN e avisos semelhantes devem usar o original não modificado. Se um erro interrompe o script, o keep implícito obrigatório volta ao original; o keep implícito normal ocorre depois das edições, se não tiver sido cancelado.

Logo, “keep executado” não basta. A causa seleciona a representação.

Uma identidade pode conter bytes diferentes

Para deduplicar, a versão editada continua sendo a mesma mensagem. Keeps redundantes não podem gerar duas cópias na mesma pasta, embora a implementação escolha qual ação redundante cumprir. A regra resolve quantidade, não prova qual cabeçalho foi arquivado.

É preciso separar chave de identidade, hash da representação e observação de destino.

Sucesso também inclui mudanças ignoradas

A política local pode proibir edições, que são ignoradas em silêncio. Received e Auto-Submitted nunca podem ser apagados; Subject deve poder ser editado. A proteção de Received preserva o rastro de prevenção de loops SMTP.

Sem uma exceção, ainda não se sabe se a mudança ocorreu. O log deve guardar pedido, decisão de política e diferença efetiva.

A assinatura pertence a uma camada

Uma alteração pode invalidar DKIM, inclusive uma assinatura que garantia a ausência de um campo. Em S/MIME e OpenPGP/MIME, a cópia interna assinada pode permanecer intacta enquanto o cabeçalho externo muda. O resultado depende da camada examinada.

Um campo válido também pode ser falso em origem. O remetente pode inserir sua própria marca de aprovação. O fluxo confiável congela e verifica a entrada, isola selos não confiáveis e só depois emite uma afirmação local rastreável.

O recibo operacional

Preserve hash do original, ordem de todas as ocorrências, revisão do script, capacidades e um registro por ação. Inclua seletor, comparador, política, hash corrente antes e depois e visão consumida. Guarde verificações de assinatura, chave de deduplicação, escolha entre ações redundantes, confirmações de armazenamento ou submissão e observação independente do destino.

Escolher redirect prova uma decisão do script; não prova aceite, armazenamento ou leitura pelo destinatário.

Fontes