Resumo

  • Desde o RFC 733, o host que gerava o identificador assumia a obrigação de torná-lo único. Uma revisão ganhava outro ID; campos de rastreamento acrescentados no transporte não mudavam necessariamente a identidade original.
  • In-Reply-To e References transformaram IDs em relações de conversa. Na Netnews, cada servidor guardava os IDs vistos e descartava repetições, encerrando localmente ciclos de distribuição.
  • O nome nunca foi assinatura nem impressão digital do conteúdo. A Netnews tratava corpos diferentes com o mesmo ID como um artigo só; um valor previsível podia ser ocupado primeiro e bloquear o artigo esperado.

Os bytes mudaram, a mensagem não

Ao entrar no transporte, uma mensagem recebe novos campos Received. A cópia armazenada deixa de ser idêntica à original, mas o relay não publicou uma revisão do pensamento do autor. O Message-ID permanece.

Quando o autor muda o que pretende comunicar e publica uma nova versão, outro identificador é apropriado mesmo que só uma frase tenha mudado. O RFC 733, de 1977, já definia o ID para uma única versão ou instanciação e atribuía ao host gerador a garantia de unicidade. Revisões posteriores deveriam receber novos IDs.

O RFC 822 preservou a regra em 1982. O valor era legível por máquinas, não precisava ser significativo para pessoas e não servia como resumo, autoria ou endereço. Era a referência estável de uma versão declarada.

Um nome mundial composto localmente

O RFC 5322 exige que o msg-id seja globalmente único e que o gerador garanta isso. Mesmo assim, não existe um balcão mundial distribuindo números por mensagem.

A recomendação divide o espaço: à direita de @, um identificador de domínio fornece escopo; à esquerda, o gerador cria um valor único nesse escopo, talvez combinando horário, sequência ou dado próprio do processo. Um âmbito reconhecível globalmente e uma contabilidade local formam um nome global sem transação global.

O formato parece endereço, mas não é caixa postal. O lado direito não precisa resolver agora e não prova domínio, autoria ou identidade. O lado esquerdo tampouco deve ser interpretado como informação comercial.

O RFC também diz que identidade depende do significado pretendido. Campos de rastreamento e reenvio podem alterar a sintaxe sem criar outra mensagem. É a decisão semântica do remetente, não uma diferença de bytes, que determina a troca de ID. Message-ID não é checksum nem identificador da transação SMTP.

Responder passou a criar uma aresta

In-Reply-To carrega o ID do pai. References herda a ancestralidade do pai e acrescenta o ID dele. Um leitor pode reconstruir uma conversa mesmo quando as peças percorrem rotas e horários diferentes.

O RFC 850, de 1983, já exigia que um follow-up da Usenet prolongasse References. O objetivo era agrupar artigos em conversas e permitir que o usuário ocultasse um diálogo inteiro sem sair do grupo. O RFC 1036 manteve o mecanismo.

Uma relação declarada não é prova. O RFC 5322 observa que muitos programas percorrem a lista presumindo um pai único; a construção com vários pais não é plenamente definida. References não autentica autores nem demonstra que a resposta compreendeu o precursor.

Cada servidor fez do ID uma memória

Na inundação entre pares da Usenet, o mesmo artigo podia voltar por vizinhos distintos. Reencaminhar toda chegada sustentaria um loop. O RFC 1036 descreve o histórico local: o host registra por Message-ID tudo o que já viu e descarta de imediato outra cópia com o mesmo valor. Path reduz tráfego inútil, mas a memória de IDs basta para romper ciclos.

Não há mestre declarando conclusão global. Cada site compara o nome com o próprio histórico e decide que já admitiu aquele artigo lógico. A referência de uma conversa humana virou também chave de convergência distribuída.

O nome igual prevaleceu sobre corpos diferentes

O RFC 5536 torna o preço explícito: artigos de mesmo Message-ID são tratados como o mesmo artigo ainda que cabeçalhos ou corpos difiram. A sintaxe e o tamanho são restringidos, e a caixa é preservada, para que uma comparação simples de octetos determine identidade. A unicidade atravessa e-mail e Netnews.

Isso dá poder à colisão. Se alguém prevê o ID de um futuro artigo e publica primeiro outro objeto com esse nome, o artigo legítimo pode ser recusado como já visto. Por isso o RFC 5536 recomenda IDs imprevisíveis. Não falhou um hash de conteúdo; nunca houve hash. O registro distribuído aceitou primeiro uma declaração errada.

O que o nome não provava

Message-ID resolve referência, não confiança. Não assina o corpo, autentica From, identifica o envelope SMTP, prova leitura nem garante bytes iguais. IDs iguais podem esconder colisão; IDs diferentes podem levar texto idêntico.

A durabilidade veio da modéstia: a origem nomeia; o transporte acrescenta custódia sem renomear; o cliente cria relações; cada servidor administra histórico e colisões. Prova criptográfica pertence a outra camada.

Fontes e limites

O conjunto fechado reúne RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 e RFC 5536. Eles não medem colisões atuais, algoritmos de provedores, implantação global ou retenção de históricos.