Resumo

  • Depois da ativação explícita, UIDONLY proíbe números de sequência e usa UIDFETCH e VANISHED com UIDs. O que desaparece é uma tabela volátil de tradução, não a obrigação de comprovar o estado da caixa.
  • A referência durável combina nome da caixa, UIDVALIDITY e UID. Anúncio, ativação da conexão, conclusão do comando, gravação no cache e reconciliação do aplicativo são recibos distintos.

Uma caixa com dezenas de milhares de mensagens perde um item perto do início. Todos os números de sequência posteriores mudam, e o cliente precisa corrigir o mapa entre posição relativa e UID enquanto novas notificações chegam. O UIDONLY ataca exatamente esse custo: a posição deixa de participar dos comandos sobre mensagens.

Mas ver UIDONLY no CAPABILITY não altera a sessão. O cliente precisa enviar ENABLE UIDONLY. Só então FETCH, STORE, SEARCH, COPY e MOVE sem o prefixo UID ficam inválidos; o servidor responde UIDREQUIRED ao formato proibido. Alterações chegam em UIDFETCH e remoções, em VANISHED. Capacidade oferecida e modo efetivamente ativo são fatos diferentes.

A simplificação é concreta. O número de sequência é apenas uma posição corrente, redistribuída quando ocorre um EXPUNGE. Ao retirar essa referência, o protocolo reduz a chance de uma resposta atrasada ser aplicada à mensagem errada e evita que o cliente mantenha duas identidades em movimento.

O UID restante, porém, não é global. O RFC 9051 o delimita pela caixa e pela geração indicada por UIDVALIDITY. Se o servidor não consegue preservar o espaço anterior, muda essa geração, e os UIDs antigos deixam de ter autoridade atual. Um UID isolado em um log de auditoria é uma referência incompleta.

UIDNEXT tampouco promete o próximo objeto. Ele estabelece um limite inferior para atribuições futuras, sem garantir que aquele valor exato será usado. Lacunas são válidas, mensagens podem ser expurgadas e atributos mutáveis continuam mudando. Identidade estável e estado encerrado são propriedades diferentes.

UIDONLY não mexe em EXISTS nem em RECENT. Pode coexistir com CONDSTORE e QRESYNC, com MODSEQ em UIDFETCH, mas não exige esses mecanismos. O parâmetro opcional de correspondência por sequência do QRESYNC é proibido para não reintroduzir o espaço descartado. Endereçar com clareza não entrega, por si, um histórico completo.

COPY e MOVE mostram o mesmo limite. COPYUID pode ligar o UID de origem ao UID e ao UIDVALIDITY do destino; a resposta etiquetada encerra o comando IMAP. Nenhum desses recibos prova que um índice, um arquivo, uma busca ou um cache móvel confirmou o novo objeto. O efeito posterior pertence a outra camada.

A alternativa rejeitada do zero é um aviso útil. Uma versão anterior preservava o formato comum de FETCH, preenchendo com zero o campo do número. Ela foi abandonada porque clientes que confiassem nesse marcador poderiam corromper o cache. Compatibilidade de aparência esconderia uma ruptura de significado; uma resposta diferente torna a troca de autoridade observável.

A cadeia operacional precisa registrar: oferta do recurso, ativação nesta conexão, caixa selecionada com este UIDVALIDITY, UIDs e estados observados, chegadas e desaparecimentos, resultado etiquetado, commit local durável e reconciliação no consumidor. Um único indicador verde não representa o conjunto.

Fontes