Resumo

  • O RFC 2076 era um catálogo informativo, não uma aprovação geral: correio, Usenet, gateways X.400 e práticas não padronizadas mantinham contextos distintos.
  • Atributos de envelope SMTP, UUCP e NNTP e campos internos de PEM ou MOSS ficaram de fora. O bloco de cabeçalhos não representava toda a transação.
  • A prova deve ligar ocorrência, definição, protocolo, status, decisão local e resultado observado, sem usar uma etapa como substituta da seguinte.

Publicado em 1997, o RFC 2076 organizou nomes que já apareciam em sistemas reais. A uniformidade de “nome: valor” escondia categorias muito diferentes: padronizado, experimental, controverso, desencorajado, exclusivo de notícias, próprio de gateway ou apenas comum sem padrão.

Um vocabulário podia atravessar várias jurisdições

O catálogo recorria ao RFC 822, ao RFC 1036 e ao mapeamento X.400 do RFC 1327. Um campo de Usenet encontrado em email não se tornava padrão de correio. X400-Received e Alternate-Recipient carregavam a finalidade de conversão.

O RFC 3864 transformou depois essa cautela em registros permanente e provisório, admitindo entradas do mesmo nome para protocolos diferentes. Registro provisório não é endosso. O RFC 4021 e o registro atual da IANA continuaram separando protocolo, status e referência.

As exclusões protegiam os limites operacionais

Envelope de transporte, campos internos de segurança e cabeçalhos exclusivos de HTTP não faziam parte do inventário. Assim, uma linha visível não substituía o remetente ou destinatário do envelope nem uma afirmação inserida no corpo.

Uma investigação precisa preservar mensagem bruta, envelope, relés, transformações e decisões do cliente. Juntá-los cedo demais num objeto normalizado elimina autoria e responsabilidade.

Apparently-To tornou uma inferência em vazamento

Algumas versões de sendmail inseriam o campo a partir dos destinatários do envelope quando não havia To. O RFC 2076 o classificava como não padrão e desencorajado: destinatários em cópia oculta podiam ser revelados. O fato de o parser reconhecer a linha não autorizava sua criação ou divulgação.

Reply-To possuía definição padrão, mas continuava controverso porque resposta pessoal, coletiva e política de lista não expressam a mesma intenção. Errors-To e Return-Receipt-To eram não padrão e desencorajados; pedir um aviso não comprovava entrega, leitura ou consequência.

A cadeia segura é: ocorrência → referência → protocolo → status → tratamento → resultado.

Fontes