Resumo

  • Cada agente Netnews acrescentava sua identidade à esquerda do Path; por isso, o passo mais recente aparecia primeiro e a trilha crescia no sentido contrário ao da leitura.
  • Um relé podia excluir um vizinho já citado antes de enviar o artigo. O histórico local baseado em Message-ID continuava responsável por rejeitar a duplicata que chegasse por outra direção.
  • !! registrava uma verificação entre vizinhos, um único ! não fazia essa afirmação, e POSTED, MISMATCH, SEEN e not-for-mail tinham escopos próprios.

O sistema podia convergir desperdiçando cada enlace

Quando B recebe um artigo de A, o algoritmo de inundação manda B oferecê-lo aos demais vizinhos interessados. Se A também estiver nessa lista e B devolver o artigo, A consultará seu histórico, reconhecerá o Message-ID e descartará a cópia. O ciclo termina, mas os bytes atravessaram o enlace sem qualquer possibilidade de produzir um artigo novo.

O problema exigia duas memórias. A base local de histórico respondia se aquele servidor já conhecia a identidade lógica. O Path respondia, antes do próximo envio, se o candidato a receber já figurava na viagem. A primeira mantinha a convergência; a segunda evitava o retorno óbvio.

RFC 1036 apresenta exatamente essa divisão. O histórico por Message-ID é suficiente para encerrar loops. O Path reduz transmissões redundantes, sobretudo a devolução imediata de B para A. Assim, a pauta não repete a história da identidade de mensagens: ela trata da decisão de vizinhança tomada antes de a duplicata existir no fio.

O último relé entrava no começo da linha

Se B recebesse A!X!Y!Z, acrescentaria o próprio nome e produziria B!A!X!Y!Z. O presente ficava à esquerda e a origem distante, à direita. O campo mudava no caminho sem transformar o conteúdo em outro artigo.

O RFC 850, de 1983, já definiu essa inclusão pela esquerda. A sintaxe aceitava várias pontuações e ainda se parecia com os antigos caminhos de correio UUCP. Por isso o documento também avisou: Path não servia para respostas e não deveria ser interpretado como endereço de e-mail.

Uma sequência conhecida por relés de notícias não precisava ser reconhecida pelo correio. A rota do artigo e a rota de uma mensagem de resposta podiam divergir. Compatibilidade ocasional em software antigo não conferia ao campo uma obrigação de entrega reversa.

O RFC 1849 preserva a etapa de transição. Publicado em 2010 como documento histórico a partir de um rascunho amplamente adotado no início dos anos 1990, ele não deve orientar implementações atuais. Ainda assim, registra a prática: nomes de relés separados por !, uma parte local na cauda e a regra de não passar o artigo a um vizinho já incluído.

Esse documento expõe a economia da solução. Mesmo que o histórico rejeitasse cada cópia devolvida, uma confusão de nomes podia duplicar o tráfego de todos os artigos naquele feed. O sistema permanecia logicamente correto enquanto a operação pagava por uma configuração errada.

A cauda não era o último servidor visitado

Na forma histórica, o componente da extrema direita podia ser uma parte local ligada ao remetente. Ele não integrava a lista de relés. Tratar todo fragmento separado por ! como servidor visitado pode bloquear um destino real que use por coincidência a mesma cadeia.

O RFC 5536 separa formalmente path-list de tail-entry. A cauda pode conter not-for-mail. A expressão não representa falha nem máquina; ela encerra a ambiguidade criada pelo antigo formato parecido com endereço.

Portanto, posição e tipo importam mais do que uma busca textual. Uma identidade na lista pode justificar a exclusão de um par. Uma fonte situada depois de POSTED e a entrada final não carregam a mesma autoridade.

NNTP era um transporte, não o mapa do campo

O RFC 977 levou em 1986 a distribuição, consulta e postagem de notícias para um protocolo sobre fluxo confiável, como TCP. O RFC 3977 substituiu esse contrato em 2006. Ambos organizam comandos e respostas; não definem Path como sequência de conexões TCP.

A arquitetura de RFC 5537 é independente do transporte subjacente. O artigo pode sobreviver ao fechamento da sessão, atravessar componentes diferentes de um servidor ou passar por gateways. O Path nomeia agentes da aplicação Netnews, não roteadores IP.

Também não escolhe a próxima rota. O operador já configurou feeds, grupos, Distribution, confiança e critérios de aceitação. A presença de uma identidade oferece uma razão negativa para não usar uma relação existente; sua ausência não cria relação nem autorização.

A especificação registrou graus de certeza

Os documentos de 2009 exigem que cada componente que processa notícias acrescente uma path identity. Prefere-se um nome de domínio completo, mas pode haver outro nome cuja unicidade seja garantida no conjunto de relés pertinente. Vizinhos precisam concordar com o nome e seus aliases para que o teste funcione.

Dois sinais consecutivos, !!, dizem que o agente à esquerda verificou, de maneira satisfatória para ele, a identidade imediatamente à direita. Um único ! não contém essa alegação. Normalizar os dois formatos como iguais fabrica uma garantia que não existia.

POSTED marca a injeção. MISMATCH registra que a identidade esperada a partir da conexão não coincide com a identidade apresentada à esquerda. SEEN preserva a fonte observada quando o receptor não quer ou não consegue validá-la como a identidade alegada. A expectativa pode vir da autenticação do par ou do endereço IP da conexão.

Cada diagnóstico é a declaração de um observador adjacente. Um MISMATCH pode sinalizar falsificação, mas também migração, proxy, alias antigo ou diferença de caixa. Mesmo uma cadeia de !! não vira assinatura de ponta a ponta: cada marca cobre uma relação local e não protege criptograficamente a linha inteira.

RFC 5537 recomenda que relés aceitem artigos apenas de agentes confiáveis para reduzir falsificação de Path e Injection-Info. A confiança operacional continua fora do campo.

Não constar da lista não era autorização

Um artigo não deve ser relayed a um receptor cuja identidade ou alias conhecido já esteja na path list válida. A cauda e certas identidades diagnósticas ficam fora da comparação. Porém, a ausência do nome não obriga o envio.

Correspondência de grupos e Distribution, validade, capacidade, confiança e política local continuam independentes. O histórico de Message-ID continua necessário para cópias vindas por outra direção. Gateways precisam de proteção extra porque uma transformação pode apagar as propriedades de identidade e trace, depois reinjetar o objeto.

O Path durou porque reivindicava pouco. Ele carregava a porção mínima de história compartilhada que o próximo operador precisava para evitar uma volta evidente. Não provava autoria, armazenamento, leitura, caminho de pacotes ou custódia global.

Os RFCs estabelecem essa semântica, não a implantação atual. Não comprovam quais serviços usam os diagnósticos, se uma identidade específica está correta nem se o artigo chegou a um leitor. Essas respostas pertencem aos registros de conexão, transferência, histórico e armazenamento.