Resumo

  • Uma ACL de caixa postal contém pares de identificador e direitos. A mesma pessoa pode corresponder ao próprio login, a vários grupos e a anyone; cada entrada é apenas um insumo do cálculo.
  • GETACL mostra regras armazenadas, LISTRIGHTS o que pode ser concedido a um identificador e MYRIGHTS o resultado efetivo para a sessão atual.
  • DELETEACL remove um par; um identificador negativo subtrai direitos na avaliação. A RFC 4314 esclareceu a diferença sem centralizar todos os modelos locais de identidade.

A exclusão terminou antes do acesso

Uma grade de permissões promete uma operação direta: selecionar o nome, apagar a linha, salvar. Essa operação só revoga o acesso se a linha for o único caminho, se o servidor executor já tiver reavaliado as regras e se sessões existentes não conservarem a decisão anterior.

Caixas coletivas expuseram cedo esse problema. Uma fila de atendimento podia ser operada por uma equipe. Um agente recebia uma concessão pessoal, outra por grupo e talvez uma terceira por uma identidade geral. A lista registrava motivos; não era a conclusão.

A RFC 1730 havia transformado a caixa remota em um objeto manipulável por rede. Clientes selecionavam pastas, liam mensagens, alteravam sinalizadores e modificavam estado no servidor. Quando mais de uma pessoa trabalhava sobre o mesmo objeto, permissões escondidas no sistema local já não davam ao cliente uma visão suficiente do que poderia fazer.

Publicada no Standards Track em janeiro de 1997, a RFC 2086 acrescentou a capacidade ACL. Cada caixa passava a ter um conjunto de pares entre identificadores e cadeias de direitos. O cliente podia consultar e alterar esses pares sem importar toda a base de contas do servidor.

Uma sessão podia ter mais de um nome

anyone foi reservado para a identidade universal, inclusive autenticações anônimas. Nomes aceitos por LOGIN ou AUTHENTICATE correspondiam a usuários. Outros identificadores podiam representar grupos ou categorias cujo significado ficava a cargo da implementação.

Fred podia, portanto, corresponder simultaneamente a fred, equipe-suporte e anyone. O documento não fixou uma álgebra global. Um servidor podia reunir todos os direitos aplicáveis; outro podia escolher só o identificador mais específico.

A liberdade pertencia ao executor, não ao cliente. A interface via linhas, mas talvez não conhecesse a associação real a grupos, os direitos obrigatórios do proprietário ou a precedência. Listas visualmente semelhantes podiam produzir respostas diferentes em sistemas conformes.

O protocolo evitou inventar uma identidade central e criou uma pergunta ao servidor. MYRIGHTS retornava o conjunto efetivo do usuário conectado sobre a caixa. Quem decidiria o próximo comando revelava seu resultado atual.

Regra, capacidade e resultado

GETACL devolvia os pares armazenados. Respondia quais regras estavam declaradas, não quais se aplicavam à sessão nem como seriam combinadas.

LISTRIGHTS informava o que o servidor podia conceder a um identificador. Direitos obrigatórios e conjuntos inseparáveis mostravam limites do armazenamento ou da política local. A resposta descrevia mudanças representáveis, não a permissão atual.

MYRIGHTS mostrava a consequência depois da resolução de identidades. Era a melhor evidência protocolar sobre a autoridade efetiva daquela sessão, sem explicar necessariamente todos os caminhos que a compunham.

Persistência, cálculo e execução formavam degraus diferentes. Ler de volta a ACL provava uma alteração declarada. Ler MYRIGHTS provava um cálculo. Aceitar uma ação provava que o servidor a executou, mas ainda não identificava a pessoa por trás da credencial.

Apagar o par não apagava a herança

DELETEACL caixa fred retirava o par de Fred. Se um grupo ou anyone ainda fornecesse w, a operação cumpria exatamente seu contrato e deixava a escrita ativa.

A RFC 2086 também reservou identificadores iniciados por hífen para direitos negativos. A RFC 4314 explicitou a função: uma entrada -fred com w subtraía o direito de escrita de Fred mesmo quando outro identificador aplicável o concedesse. A entrada negativa participava do cálculo; DELETEACL apenas eliminava uma peça.

O suporte a direitos negativos não era obrigatório. Nenhum cliente podia prometer um botão universal de “negação vence concessão”. Era preciso descobrir a capacidade e conferir o resultado.

O hífen também tinha dois usos. No argumento de direitos de SETACL, -w removia w do par escolhido. Na posição de identificador, -fred denominava uma entrada negativa. O primeiro editava uma linha; o segundo podia neutralizar autoridade herdada. Pontuação igual não dava alcance igual às operações.

Um vocabulário mais fino com uma ponte para o passado

A primeira versão usava letras para visibilidade, leitura, estado visto, outros sinalizadores, inserção, postagem, criação, exclusão e administração. Ambiguidades em c e d misturaram marcar uma mensagem, expurgá-la e apagar a caixa inteira.

Em dezembro de 2005, a RFC 4314 substituiu a RFC 2086. k passou a governar a criação de caixas filhas; x, a exclusão ou mudança da caixa; t, a marca de mensagem excluída; e, o expurgo. Os antigos c e d continuaram como direitos virtuais para compatibilidade. Servidores novos aplicavam distinções estreitas; clientes antigos recebiam uma projeção definida.

A capacidade RIGHTS= anunciava direitos adicionais. Se a implementação só pudesse conceder certas operações em bloco, LISTRIGHTS expunha o vínculo. A norma não fingia que todo sistema local oferecia a mesma granularidade.

Ela também obrigou editores a preservar direitos desconhecidos que não deixavam o usuário alterar. Um cliente antigo que lesse uma entrada moderna e gravasse apenas as letras familiares removeria silenciosamente a autorização nova. Compatibilidade passou a exigir humildade diante do desconhecido.

A revogação tinha estado temporal

A RFC 4314 permitiu que direitos fossem armazenados em cache quando a caixa era selecionada. Depois de SETACL ou DELETEACL, uma sessão já selecionada podia executar STORE ou EXPUNGE com o cálculo anterior até selecionar novamente.

Servidores que verificassem cada comando podiam atualizar sinalizadores, recusar a ação ou fechar a conexão se a leitura desaparecesse. A especificação não inventou um instante universal para todas as sessões; mostrou o limite que o operador precisava testar.

Na mesma conexão, a ordem era controlável. Mesmo enviados em pipeline, SETACL deveria terminar antes de MYRIGHTS ser calculado. Essa garantia local não revelava o cache de outra sessão.

A lista de autoridade também precisava ser protegida

Uma ACL podia revelar a existência da caixa, nomes de contas, grupos e administradores. A RFC 2086 já exigia que GETACL sem permissão não expusesse uma caixa restrita. A RFC 4314 determinou que, sem direito de listagem, a resposta fosse igual à de uma caixa inexistente.

Ler mensagens também não bastava para enxergar a ACL, pois os identificadores eram informação de segurança. E a extensão não fornecia sigilo por si mesma. Sem STARTTLS, proteção de privacidade negociada na autenticação ou outra camada, os dados trafegavam em claro.

Acertar a autorização e proteger o transporte da resposta eram trabalhos separados.

O padrão declarou o que permaneceu local

A RFC 4314 enumerou limitações: a combinação de direitos continuava definida pela implementação; usuários, grupos e identificadores especiais dividiam o mesmo espaço; uma interface amigável não conseguia explicar tudo; faltavam operações gerais semelhantes à troca de proprietário em sistemas de arquivos.

Ainda assim, a revisão compatível era valiosa porque a RFC 2086 já existia em múltiplas implementações. A RFC 9051 definiu depois o IMAP4rev2 e manteve, em geral, extensões registradas do IMAP4rev1. Isso mostra continuidade do contrato, não implantação universal de ACL ou direitos negativos.

O resultado duradouro foi uma camada comum pequena. O IMAP não declarou uma tabela soberana sobre todos os servidores. Padronizou perguntas suficientes para distinguir regra registrada, mudança possível e autoridade calculada pelo código que realmente executava o correio.

Fontes