Resumo

  • Os estados y, n e m de LIST ACTIVE descreviam o tratamento habitual das postagens no grupo, não uma autorização personalizada.
  • Um cliente proibido ainda podia ser recusado em y; um cliente com privilégio especial podia, em tese, publicar em n.
  • Catálogo, identidade, autorização local, aceitação do artigo e disponibilidade ao leitor permaneciam fatos distintos.

A interface prometeu mais do que o servidor disse

Uma leitora consulta a lista, encontra y e recebe um editor habilitado. Só depois de concluir o texto o programa envia POST. A resposta é 440, antes da transmissão do corpo. A frustração nasce de uma tradução ruim entre protocolo e produto: “o grupo normalmente recebe postagens” virou “esta conta está autorizada”.

O contraste inverso também importa. RFC 3977 admite que um cliente com privilégios especiais possa publicar em um grupo marcado n. A especificação não cria esse privilégio; apenas impede que a política resumida no catálogo apague exceções locais legítimas.

Os dois casos demonstram que y/n/m não era falso nem completo. Era evidência de escopo estreito.

A independência já estava em 1986

RFC 977 definiu LIST como uma sequência de linhas contendo grupo, último número, primeiro número e uma bandeira y ou n. Era uma maneira econômica de descrever muitos grupos.

O próprio documento avisou que um cliente podia ser impedido de publicar mesmo quando a lista indicava permissão no grupo. A bandeira distinguia fluxos habituais, inclusive grupos moderados e digest, e era independente da permissão que o servidor concedia ao cliente.

A decisão aplicável aparecia em POST: 340 autorizava o envio do artigo; 440 o bloqueava por uma razão dependente da instalação. A política de quais clientes e hosts poderiam postar ficou fora da norma. O protocolo padronizou a fronteira observável, não a administração de todas as contas.

Essa arquitetura deixava a tabela do grupo relativamente estável e permitia que permissões mudassem por sessão sem redefinir o catálogo inteiro.

ACTIVE descrevia um servidor, não a Usenet inteira

RFC 3977 chamou a variante de LIST ACTIVE. Sem filtro, a resposta inclui os grupos que o cliente pode selecionar com GROUP. Portanto, ela já é uma visão local, oferecida por um servidor a uma conexão, e não um registro mundial do espaço de nomes.

Cada linha traz nome, marcas alta e baixa e estado atual naquele servidor. y significa postagem permitida, n não permitida e m encaminhamento ao moderador. Um valor desconhecido não deve ser interpretado como permissão ou proibição.

Em seguida vem o limite central: o estado mostra como as postagens são normalmente processadas e não precisa ser adaptado ao cliente específico. Uma restrição do cliente continua valendo em y; uma exceção privilegiada pode atravessar n.

“Normalmente” funciona como rótulo de escopo. Ele preserva a utilidade da lista sem transformá-la em ficha completa de identidades, endereços, proteção de transporte e exceções administrativas.

O corpo tinha dois portões

No fluxo de RFC 3977, POST recebe 340 ou 440 antes do corpo. Depois que o texto chega, o servidor encerra com 240 ou 441. Uma recusa inicial evita que o rascunho atravesse a conexão; uma falha final acontece depois que o conteúdo foi revelado ao servidor.

Mesmo 240 não prova que leitores já encontram o artigo. Moderação, processamento e transferência ainda podem ocorrer. A disponibilidade precisa ser verificada de forma própria.

Por isso, um único indicador “pode publicar” perde quatro fatos: política normal do grupo, autorização da sessão para submeter, aceitação do artigo e visibilidade. Em operações e privacidade, cada um precisa de seu evento.

Autenticação não resolvia toda autorização

RFC 4643 usa 480 para indicar que autenticação e/ou autorização é necessária antes de usar um comando ou recurso. AUTHINFO pode alterar as capacidades anunciadas porque a conexão passa a representar um principal reconhecido.

Ainda assim, a autenticação pode ser bem-sucedida e alguns ou todos os recursos continuarem negados com 502. Identidade aceita e direito concedido são afirmações diferentes.

Logo, LIST ACTIVE, AUTHINFO e a resposta ao comando não são substitutos. Um cache baseado apenas no nome do grupo e em y/n/m não percebe mudança de usuário, TLS, endpoint ou versão de política. Depois de cada transição de segurança ou identidade, o cliente deve atualizar capacidades e pedir uma decisão nova.

A letra m indicava o caminho

m informa que postagens serão encaminhadas ao moderador. Não autentica esse moderador nem promete aprovação. RFC 5537 separa agentes de postagem, injeção, retransmissão, serviço e leitura, além da moderação, porque cada etapa possui autoridade diferente.

A matéria anterior sobre Approved já cobre a autoridade do moderador. Aqui, m apenas confirma que a lista descreve o percurso habitual. Poder enviar não prova autoria; aceitação não garante retransmissão; retransmissão não garante leitura.

O vocabulário manteve funções separadas

O registro de parâmetros NNTP da IANA registra LIST, POST, AUTHINFO e READER separadamente. Ele não mede adoção atual, mas oferece nomes distintos para descoberta, envio, identidade e leitura.

O ensinamento permanece atual: um painel resumido deve continuar sendo resumo. O sinal verde dizia a verdade sobre a operação normal do grupo. A autorização que pertencia ao cliente só existia quando a sessão chegava ao seu próprio portão.

Fontes