Resumo

  • CLOSE levava a conexão de Selected para Authenticated e, numa caixa gravável, removia para sempre todas as mensagens com \Deleted, sem enviar uma resposta EXPUNGE para cada uma.
  • O RFC 3691 definiu UNSELECT: a mesma liberação do contexto selecionado, mas sem expunge. A mudança separou a entrega de um recurso da autorização para uma mutação irreversível.

Uma aplicação termina de sincronizar a caixa de entrada. Ela continuará ligada e autenticada, mas não precisa manter aquela caixa selecionada. O pedido operacional é pequeno: liberar o contexto atual.

Na caixa existem mensagens com a marca \Deleted. A marca pode ter sido colocada antes, talvez por outra sessão. Ela ainda não é a remoção física. Mesmo assim, a palavra aparentemente natural para sair — CLOSE — transforma todas essas marcas em exclusões permanentes antes de voltar a conexão ao estado Authenticated.

O nome escondia uma autorização adicional. O cliente pedia o fim de um estado de trabalho; o protocolo podia interpretar a mesma ação como a confirmação de todo um conjunto pendente.

Em 2004, o RFC 3691 criou UNSELECT. Sem argumentos, o comando libera os recursos da caixa selecionada e retorna à condição autenticada. A diferença é absoluta: nenhuma mensagem é removida permanentemente por essa saída.

Selected era uma relação mantida no servidor

No IMAP, autenticar-se não basta para manipular mensagens. O cliente seleciona uma caixa para buscar, ler, alterar flags, copiar e excluir. O servidor passa a manter uma visão relacionada àquela caixa e a comunicar seus movimentos.

Encerrar essa seleção não exige fechar o TCP ou abandonar a identidade autenticada. Um cliente pode alternar de Inbox para Drafts ou permanecer ocioso depois de devolver recursos. A transição de Selected para Authenticated tem, portanto, valor próprio.

CLOSE realizava a transição, mas também o expunge. Um diagrama que mostra apenas os dois estados faz os caminhos parecerem equivalentes. Os dados revelam o contrário: chegar ao mesmo estado não informa se mensagens sobreviveram.

\Deleted funciona como uma decisão ainda preparada. O expunge é que a torna definitiva. Separar marca e remoção permite revisar um grupo antes do commit. Também permite que um ator marque e outro, mais tarde, dispare a consequência. Quando a saída executa as duas coisas, o último ator herda as decisões acumuladas.

A resposta curta era uma otimização, não uma garantia

O EXPUNGE comum envia uma resposta não etiquetada para cada mensagem removida. Ela usa o message sequence number, posição que muda quando itens anteriores desaparecem. A sequência de respostas permite acompanhar o rearranjo da caixa aberta.

CLOSE evita essas mensagens. Como o cliente está saindo, provavelmente não utilizará as novas posições. Com muitas remoções, poupar respostas descartáveis reduz processamento e tráfego.

Mas o silêncio não reduz o efeito. O OK etiquetado afirma que CLOSE terminou; não afirma que zero mensagens foram apagadas nem fornece uma relação por UID. A otimização torna a operação menos visível exatamente quando o resultado é permanente.

O modo de seleção também altera a consequência. Se a caixa foi aberta por EXAMINE ou está somente para leitura, CLOSE não remove mensagens e não gera erro apenas porque não removeu. Para interpretar um sucesso, é indispensável conhecer caixa, modo, flags anteriores e comando escolhido.

O protocolo tinha atalhos sem expunge

O IMAP4rev1 permitia selecionar ou examinar outra caixa e também fazer LOGOUT sem CLOSE. Esses caminhos encerravam implicitamente a seleção atual sem expunge. Portanto, a saída não destrutiva já era possível, mas não havia um verbo direto para deixar de selecionar e continuar autenticado.

O RFC 3691 registra dois contornos. O cliente podia tentar selecionar uma caixa inexistente e usar a falha para regressar a Authenticated. Ou podia selecionar novamente a mesma caixa com EXAMINE.

No primeiro caso, um erro esperado virava fluxo normal. Registros e métricas confundiam intenção com defeito. No segundo, abria-se uma visão somente leitura para abandonar outra visão, apesar de o cliente não querer manter nenhuma. Ambos dependiam de efeitos laterais e escondiam o propósito do operador.

UNSELECT transformou o propósito em ato de protocolo. O servidor não precisa deduzir, e quem examina a chamada não precisa saber que uma seleção impossível era na verdade uma saída planejada.

A capability criou entendimento antes da execução

Servidores IMAP4rev1 anunciavam UNSELECT quando suportavam a extensão. O cliente verificava esse vocabulário antes de usar o comando. Uma rejeição por sintaxe desconhecida não podia ser aceita como saída, pois a conexão talvez continuasse Selected.

A capability não autentica a pessoa, não valida conteúdo e não comprova uma política de retenção. Ela estabelece apenas que as duas pontas concordam com o significado do verbo. Esse limite é suficiente: a escolha é explícita antes da mutação.

O comando não limpa \Deleted, não restaura mensagens já removidas e não impede outra sessão de executar expunge. Ao selecionar a caixa novamente, as marcas podem continuar lá. UNSELECT preserva o momento de decidir; não promete conservar tudo para sempre.

IMAP4rev2 incorporou a distinção

O RFC 9051 incluiu UNSELECT entre os comandos básicos do IMAP4rev2. CLOSE e UNSELECT aparecem como rotas de Selected para Authenticated, mas suas definições continuam diferentes. Uma fecha com remoção dos marcados numa caixa gravável; a outra sai sem remover.

A passagem de extensão para protocolo base mostra uma correção compatível. O mecanismo antigo não foi apagado nem reinterpretado. Ganhou-se uma operação de primeira classe que corresponde ao pedido real e permite que código, registros e recuperação preservem a escolha.

O princípio vale além do correio. Fechar uma conexão depois de commit e depois de rollback produz o mesmo estado de conexão, mas não o mesmo banco. Liberar um arquivo depois de flush e depois de descartar um buffer não é equivalente. Se a observação conserva apenas o destino, perde o efeito exercido no caminho.

UNSELECT retirou uma permissão implícita. Entregar o contexto não bastava mais para autorizar uma remoção. O cliente que deseja atravessar o limite irreversível precisa escolher um comando que carregue essa decisão.

Uma confirmação perdida ampliava a diferença

O enlace pode cair depois de o servidor receber a ordem e antes de o cliente receber o resultado etiquetado. Nesse intervalo, o programa conhece o que pretendia enviar, mas não sabe com certeza qual estado o servidor alcançou. Com UNSELECT, a dúvida principal é se a seleção ainda está ativa. Com CLOSE, a dúvida inclui a possibilidade de mensagens já terem sido removidas para sempre.

Repetir mecanicamente a última chamada não resolve essa assimetria. Reconectar e observar pode restabelecer o contexto; não recria a única cópia de uma mensagem já expurgada. A recuperação precisa comparar o estado atual, os UID que ainda existem, as marcas conservadas e a evidência anterior, antes de decidir se alguma intenção humana continua pendente.

Essa diferença também alcança as bibliotecas. Uma função chamada closeMailbox() parece neutra para a aplicação. Se ela envia CLOSE por padrão, esconde uma política de commit dentro de uma rotina de limpeza. Uma interface responsável deve nomear separadamente “liberar seleção” e “confirmar remoções”, expor resultados diferentes e impedir que destrutores automáticos ou blocos de finalização escolham a segunda opção sem intenção explícita.

O benefício operacional de UNSELECT é, portanto, maior do que a comodidade sintática. Quanto menor o efeito autorizado por uma ordem, menor o campo de dano após confirmação perdida, retry ou failover. O comando não elimina toda incerteza, mas impede que a rotina comum de recuperar uma sessão repita também uma decisão permanente sobre conteúdo do usuário.

Um OK não era um inventário

O resultado tagged confirma a conclusão da ordem. Em CLOSE, ele não enumera por si só o conjunto removido; em UNSELECT, não afirma que os flags existentes foram limpos. Para prestação de contas é necessário juntar a intenção antes da chamada, o modo da caixa, o conjunto observável de mensagens e o estado visto depois.

A separação dos verbos torna possível classificar o efeito antes da execução. Isso é mais robusto do que inferir a intenção de uma resposta curta depois do fato. Quando a consequência pode ser irreversível, o protocolo deve tornar o mandato visível na entrada.

Fontes