Resumo

  • O número de sequência do IMAP é uma posição móvel: quando uma mensagem anterior é expurgada, as seguintes mudam de lugar. O UID persiste entre sessões, mas somente dentro de uma caixa e de uma geração UIDVALIDITY.
  • Ao mudar o UIDVALIDITY, o servidor retira a garantia de continuidade. O cliente precisa descartar o cache e as ações dirigidas aos UIDs antigos, mesmo que reconstruir tudo custe tempo e tráfego.

A ordem correta encontrou a mensagem errada

Um celular sincroniza a caixa de entrada e perde o sinal. No cache, UID 4821 é um recibo que o usuário decide apagar. Enquanto o aparelho está desconectado, o provedor restaura a caixa em outro armazenamento. Os e-mails permanecem, mas a tabela antiga de UIDs não. Na nova numeração, outra mensagem recebe 4821.

Não há invasor nessa história. A conta está autenticada, a conexão pode estar cifrada e o comando pode ser perfeito. O erro acontece se o servidor mantiver o UIDVALIDITY antigo e transformar coincidência numérica em falsa continuidade. A ação legítima passa a governar um objeto que o usuário nunca escolheu.

A resposta do IMAP é perder o cache para preservar a intenção. O servidor anuncia uma geração nova. O cliente não repete a exclusão, abandona as ações antigas e volta a sincronizar aquela caixa.

Posição serve para percorrer, não para lembrar

O IMAP usa números de sequência para representar a posição relativa das mensagens. Numa caixa com vinte itens, eles vão de 1 a 20. São ótimos para buscar intervalos e fazer contas durante uma sessão aberta.

Mas, se a mensagem 6 for expurgada, a antiga 7 vira 6 e todas as posteriores recuam. O mesmo número pode pertencer a mensagens diferentes. RFC 2060 descreveu essa propriedade no IMAP4rev1 de 1996; RFC 9051 a mantém no IMAP4rev2.

Enquanto o cliente está conectado, as respostas do servidor permitem corrigir o mapa. Um cliente offline perde a sequência de eventos. Quando volta, “mensagem 6” é apenas a sexta posição de agora, não uma prova sobre o objeto visto ontem.

O UID separou identidade de ordenação

RFC 1730, de dezembro de 1994, definiu o IMAP4 para manipular caixas remotas e resincronizar clientes desconectados. O UID era um valor de 32 bits, estritamente crescente dentro da caixa, não necessariamente contínuo e persistente entre sessões.

Isso permitiu que um programa associasse estado local e ações pendentes a uma mensagem sem comparar todos os corpos após cada reconexão. Só que persistência depende do armazenamento. Sistemas antigos talvez não tivessem onde guardar o UID; um agente externo podia reordenar arquivos; uma caixa podia ser removida e recriada com o mesmo nome; uma migração podia conservar mensagens e perder metadados.

O padrão não fingiu que esses casos não existiam. Também não autorizou a reutilização silenciosa. Criou uma fronteira de geração que o cliente pudesse observar.

UIDVALIDITY limita a validade; não batiza a caixa

Cada caixa anuncia um UIDVALIDITY. Se os UIDs anteriores deixarem de persistir, o valor novo deve ser maior. Data de criação e contador monotônico aparecem como opções de implementação. O contrato público é o sinal, não um algoritmo universal.

RFC 2683 corrige um equívoco recorrente: UIDVALIDITY não é identificador de caixa. Caixas distintas podem compartilhar o mesmo valor, e o UID só é único dentro de uma caixa. A referência durável inclui nome da caixa, UIDVALIDITY e UID.

RFC 3501 e RFC 9051 exigem que essa trinca continue associada a uma única mensagem imutável no servidor. Corpo, envelope, data interna, tamanho e estrutura não podem virar os de outro e-mail sob a mesma trinca. Flags são mutáveis por definição. Depois de um expunge, o UID não pode ser reaproveitado na mesma geração.

Assim, a unicidade não nasce do tamanho do número. Nasce do escopo, da proibição de reutilização e de uma forma verificável de encerrar a validade.

Uma limitação real precisava aparecer no protocolo

Alterar UIDVALIDITY força reconstruções de cache, por isso os RFCs incentivam fortemente a persistência. Ainda assim, RFC 4315 define UIDNOTSTICKY para armazenamentos legados incapazes de manter UIDs, e recomenda evitar essa condição em projetos novos.

O mecanismo não esconde a exceção. Se o servidor não sustenta a promessa, deve informar. RFC 2683 registra o pior efeito de ignorar essa regra: um cliente pode excluir a mensagem errada usando um UID obsoleto. Também pode mover, copiar, marcar ou buscar o item errado.

O custo de admitir a descontinuidade é imediato. O custo de escondê-la se distribui por dispositivos e só aparece quando o dano já ocorreu.

O cliente perde dados locais para não inventar autoridade

RFC 4549 organiza a sincronização de clientes desconectados. Ao abrir uma caixa, o programa compara o UIDVALIDITY recebido com o salvo. Se forem diferentes, deve esvaziar o cache daquela caixa, remover as ações que citavam UIDs antigos e tratá-las como falhas.

Assunto, data e tamanho semelhantes não recuperam a autorização original. Podem ajudar uma busca, mas não provam que uma ordem preparada para um e-mail vale para outro. A mudança de geração revoga tanto a referência quanto o direito de repetir a operação associada a ela.

O alcance é local. RFC 2683 desaconselha um único contador de UID para todo o servidor porque ele gastaria os 32 bits mais rapidamente e poderia transformar uma exaustão em invalidação de todas as caixas. Escopo menor contém o impacto.

Links e sincronização rápida continuaram subordinados à geração

RFC 2192 permitiu, em 1997, que uma URL IMAP levasse caixa, UIDVALIDITY e UID. O programa deveria comparar a geração guardada com a atual para saber se o link ficou obsoleto. UIDVALIDITY não é prazo de validade do e-mail nem prova criptográfica; é um teste de continuidade da referência.

Depois, RFC 7162 combinou CONDSTORE e QRESYNC. Sequências de modificação e a resposta VANISHED tornaram possível buscar apenas mudanças e expurgos, muitas vezes em uma ida e volta. Mesmo assim, o primeiro estado enviado ao QRESYNC é o UIDVALIDITY conhecido. Se não coincidir, o servidor ignora as informações de delta restantes.

Antes de perguntar “o que mudou?”, é preciso responder “ainda são os mesmos objetos?”. Uma otimização precisa nunca conserta uma geração errada.

UIDONLY reduziu a dependência de posições, não do contexto

Em maio de 2024, o Experimental RFC 9586 definiu UIDONLY. Após habilitá-lo, o cliente não pode usar números de sequência e o servidor não os devolve. Formas baseadas em UID e VANISHED substituem o mapa entre posições móveis e UIDs, poupando recursos.

O documento não obriga adoção nem mede implantação. Ele revela, porém, uma direção persistente: trinta anos depois do IMAP4, o protocolo ainda procura reduzir a ambiguidade das coordenadas relativas.

UIDONLY não torna o UID global ou eterno. O número continua limitado pela caixa e pelo UIDVALIDITY. Tirar a posição não remove a geração.

Um identificador durou porque podia morrer de forma honesta

O IMAP dividiu responsabilidades. O servidor controla o armazenamento e declara se preservou os UIDs. O cliente controla seu cache e suas intenções adiadas e deve revogá-los quando a geração muda. Nenhum dos dois pode transformar conveniência em evidência.

A camada comum permanece fina: não escolhe um banco de dados, um método de restauração ou o formato do cache. Define o invariante, o sinal de ruptura e a reação segura. Sistemas diferentes continuam livres para funcionar, mas um número antigo não ganha, em silêncio, autoridade sobre uma mensagem nova.

O UID atravessa sessões justamente porque o UIDVALIDITY consegue dizer quando ele não atravessou o renascimento da caixa.

Fontes e limites

RFC 1730 fornece o desenho de 1994; RFC 2060, RFC 3501 e RFC 9051 explicam sequências, UIDs e a trinca de identidade. RFC 2683 traz experiência de implementação, RFC 2192 o teste de links, RFC 4315 UIDNOTSTICKY, RFC 4549 a disciplina offline, RFC 7162 QRESYNC e RFC 9586 o UIDONLY Experimental. Eles não demonstram adoção atual, comportamento de produtos específicos, autenticidade de mensagens, integridade criptográfica ou um único método de gerar UIDVALIDITY.