Resumo

  • A RFC 1036 exigia uma linha Approved: para artigos enviados a grupos moderados e dizia que o moderador deveria acrescentar seu endereço de e-mail.
  • Era um sinal de encaminhamento e admissão, não uma credencial criptográfica: um texto histórico posterior afirmou que a aprovação declarada não podia ser autenticada.

A decisão precisava acompanhar o artigo

O Usenet não era um servidor central que recebia cada texto e aprovava a cópia final em nome de toda a rede. Os artigos circulavam entre sites que trocavam grupos selecionados e mantinham cópias locais. Para a moderação funcionar ao longo desse percurso, o artigo precisava trazer uma indicação que o software pudesse ler: já podia seguir para a distribuição normal ou ainda precisava ser encaminhado para revisão?

Publicada em dezembro de 1987, a RFC 1036, norma para a troca de mensagens do Usenet, deu a essa indicação um nome curto: Approved. O campo aparecia entre os cabeçalhos geralmente opcionais, mas era obrigatório em qualquer postagem para um grupo moderado. O moderador deveria inseri-lo com seu endereço postal. Esse endereço oferecia um contato prático e permitia aos programas reconhecer um estado declarado. A norma não especificava assinatura digital, chave nem diretório confiável para que o site receptor confirmasse a identidade do moderador.

Duas coisas distintas podiam parecer uma só. A regra pressupunha uma decisão humana; o cabeçalho permitia que o software visse que o artigo afirmava ter recebido essa decisão. Ele não mostrava a revisão, os critérios usados ou quem a realizou. Approved designava um estado, enquanto o endereço apontava um contato. Nenhum dos dois era um recibo autenticado da aprovação.

O mesmo campo acompanhava comandos sobre os grupos

O exemplo da RFC 1036 mostra a forma concreta do cabeçalho. Um relatório de audiência datado de 1º de outubro de 1986 aparece cruzado em news.lists e news.groups, com um campo Approved que indica o endereço do moderador. O Xref registra também os números locais no host seismo. O exemplo mostra um endereço acompanhando um artigo comum em circulação; não mede a frequência do mecanismo nem como cada site verificava o campo.

A marca também aparecia num contexto de maior impacto. A RFC descreve a mensagem de controle newgroup, que solicitava a criação de um grupo e podia especificá-lo como moderado. Os sites deveriam ignorar a mensagem se o cabeçalho não contivesse Approved. A instrução rmgroup, que pedia a remoção de um grupo de todos os hosts, tinha a mesma exigência. O documento recomendava cuidado porque a remoção alcançava toda a rede. Assim, o campo ajudava o software a diferenciar um comando comum de outro que trazia uma alegação de aprovação, mas não autenticava a autoridade invocada.

Esse uso duplo expõe uma tensão de sistemas distribuídos: o protocolo consegue tornar uma decisão visível em muitos lugares sem verificar automaticamente sua origem. Cada site podia testar se o campo estava presente, mas a presença não demonstrava que a caixa postal pertencia ao moderador ou administrador autorizado. A norma criou um ponto comum de controle; a confiança ainda dependia de acordos locais.

O texto histórico nomeou a lacuna de confiança

A cronologia de “Son of 1036” importa. A RFC 1849 foi publicada como documento Histórico em março de 2010 para preservar um rascunho que, segundo seu autor, circulou amplamente no início dos anos 1990 e se tornou uma referência de fato para implementadores de software de notícias. O documento avisa que oferece contexto histórico, não instruções atuais de implementação.

Ele separa melhor as funções dos programas. Um agente de postagem atende a contribuição do usuário local: pode prepará-la, verificar se está em conformidade e encaminhá-la para distribuição. Um relayer recebe artigos já preparados de outros relayers e os repassa. Num grupo moderado, a falta de Approved indicava ao agente de postagem que a contribuição do leitor deveria ser enviada ao moderador. O relayer deveria descartar um artigo sem aprovação, em vez de convertê-lo em pedido por e-mail. Um programa podia executar as duas funções, mas as responsabilidades eram diferentes.

O documento histórico afirma diretamente que não havia como autenticar Approved para confirmar que a aprovação declarada realmente ocorreu, nem um mecanismo mantido para identificar os aprovadores legítimos e atualizados. A autenticação criptográfica aparece como uma extensão desejável, com a ressalva de que muitos sistemas de notícias não acessavam servidores de chaves em tempo real. Isso registra um limite de desenho; não comprova uma fraude específica nem que todo site aceitava cabeçalhos falsos.

A RFC 5537, posterior, formalizou o caminho de injeção: um agente de injeção encaminha o artigo ainda não aprovado ao moderador do primeiro grupo moderado listado, normalmente por e-mail. Aprovação e injeção permanecem separadas do relaying habitual. Essa especificação posterior explicita a divisão de trabalho, mas não deve ser aplicada automaticamente a toda instalação dos anos 1980.

O que a linha fazia — e o que deixava em aberto

Approved: tinha utilidade mesmo sem prova criptográfica. Oferecia aos programas de notícias uma condição compartilhada de processamento e um endereço prático para a moderação. A decisão editorial podia viajar com um sistema distribuído de publicação. Mas essa portabilidade terminava nos limites dos acordos de confiança que cercavam o cabeçalho.

A rede podia transportar uma declaração de aprovação; o texto sozinho não demonstrava a autoridade por trás dela. Revisão humana, administração de endereços, política local e tratamento pelo software continuavam sendo etapas diferentes. A norma reservou um lugar visível para a decisão, mas não criou uma forma universal de provar quem a tomou.

Fontes