Resumo

  • Um servidor podia recusar a exclusão de uma caixa em uso, manter uma cópia fantasma para sessões existentes ou concluir a exclusão e desconectar os demais clientes.
  • O cliente precisava reconciliar notificações EXPUNGE atrasadas, respostas parciais e números de sequência móveis; o comportamento de um único servidor não era o contrato do protocolo.

DELETE podia remover o endereço sem remover o lugar

Dois clientes já selecionaram FOO. O primeiro envia DELETE FOO e recebe OK. Um terceiro cliente não encontra mais FOO e não consegue recriar o mesmo nome. Ainda assim, o segundo pode continuar executando FETCH ou STORE na caixa selecionada.

RFC 2180 descreve essa retenção por referência como uma estratégia permitida. O nome desaparece para novas operações; o conteúdo só é removido quando a última sessão encerra o acesso. Alternativamente, o servidor pode negar DELETE enquanto houver usuários ou aceitar e enviar BYE a todos os demais.

Cada escolha sacrifica algo. Negar protege sessões, mas uma caixa compartilhada muito movimentada pode nunca ter uma janela de exclusão. Manter a caixa fantasma preserva continuidade, porém adia a remoção de dados sensíveis e o reuso do nome. Desconectar fortalece a exclusão, mas interrompe trabalho legítimo.

RENAME separa ainda mais os planos. Uma sessão já selecionada pode continuar com comandos que não mencionam o nome antigo. Ao tentar APPEND FOO, descobre a mudança, talvez por um código NEWNAME. O diretório já mudou; a sessão selecionada ainda opera sobre o mesmo conteúdo.

A lista mudava antes que o cliente pudesse receber o aviso

Em RFC 2060, números de sequência são posições atuais. Quando uma mensagem é expurgada, as posições seguintes diminuem. Mas respostas EXPUNGE não podem interromper a resposta a FETCH, STORE ou SEARCH. Há um intervalo em que o servidor conhece a mudança e o cliente ainda trabalha com o mapa anterior.

RFC 2180 registra várias saídas válidas. O servidor pode guardar mensagens fantasma até concluir o FETCH. Pode retornar somente as mensagens existentes e terminar com NO. Pode devolver valores normais para as existentes, estruturas NIL para as removidas e concluir com OK. Ou pode recusar o expunge enquanto a caixa estiver sendo acessada por vários clientes.

NIL não resolve sozinho a verdade. Uma lista de flags vazia pode ser realmente vazia ou representar uma mensagem já removida. Quando isso muda a decisão, o cliente envia NOOP, recebe os EXPUNGE pendentes, corrige o mapa e então repete ou abandona o comando.

O mesmo cuidado vale para STORE.SILENT. Se todos os itens que ainda existem forem alterados, o servidor pode retornar OK mesmo que parte do intervalo solicitado já tenha desaparecido. O recibo confirma a parte executável; não confirma a permanência do conjunto original.

COPY recebeu uma garantia limitada ao início do comando

No COPY, os números são interpretados no começo. Mesmo que um EXPUNGE altere as posições antes do fim, uma cópia bem-sucedida deve levar ao destino as mensagens identificadas no início. Se falhar, o destino volta ao estado anterior.

Essa regra congela uma referência, não a caixa inteira. Ela dá determinismo a uma operação sem alegar que outras sessões ou o comando seguinte veem o mesmo estado.

Documento informativo, não inventário de implementações

O registro do RFC Editor classifica o RFC 2180 como Informational. O próprio texto diz que não define conformidade nem esgota comportamentos válidos; RFC 2060 continua sendo a referência. O documento registra práticas de alguns servidores e consenso considerado razoável na lista IMAP.

Por isso, ele não comprova a conduta de um serviço atual, a prevalência de cada estratégia ou a eliminação física de dados. Sua contribuição histórica é identificar a responsabilidade do cliente: implementar o espaço de comportamentos permitido pelo protocolo, em vez de codificar a preferência de um servidor conhecido.

RFC 2177 tornou atualizações mais imediatas com IDLE. RFC 7162 usou mod-sequences, VANISHED e QRESYNC para tornar a reconciliação mais eficiente. Nenhum deles transforma um tagged OK em prova de consenso instantâneo entre sessões.

Comando concluído, nome removido, acesso das sessões encerrado e bytes destruídos são quatro afirmações. RFC 2180 ensina a não trocar uma pela outra.