Resumo

  • O UIDPLUS anexou UIDVALIDITY e os UIDs recém-atribuídos às respostas de sucesso de APPEND e COPY, permitindo reconciliar uma mutação com seu resultado no destino sem uma busca posterior.
  • O protocolo recusou transformar esse recibo em promessa universal: permissões e UIDNOTSTICKY podiam justificar sua ausência, COPYUID era local à operação e UID EXPUNGE atingia apenas UIDs explicitamente listados que já tivessem \Deleted.

Um nome que talvez não durasse

Clientes desconectados dependem de memória. Guardam uma ação local, perdem a conexão e mais tarde precisam saber se o servidor criou exatamente o estado esperado. O UID é útil porque, dentro de uma geração de caixa postal, identifica uma mensagem de modo mais estável que o número de sequência visível.

Nem todo armazenamento histórico conseguia conservar esses UIDs entre sessões. RFC 4315 deu a essa limitação um nome: UIDNOTSTICKY. A indicação informa que os identificadores não têm a persistência que um cliente normalmente espera. A especificação diz que novos armazenamentos não deveriam ter essa propriedade, mas não apaga os sistemas que tinham.

Quando o destino é UIDNOTSTICKY, o servidor pode omitir APPENDUID e COPYUID. A omissão protege o significado do recibo. Um número recém-criado, se apresentado sem ressalva a um cliente desconectado, pareceria uma referência para uso futuro. Se o número puder mudar na próxima abertura, o dado exato no presente induziria uma conclusão falsa sobre o futuro.

APPENDUID conciliou a fila local

APPEND envia uma mensagem para uma caixa, e o servidor escolhe seu UID. Um OK confirma que a operação terminou, mas a confirmação simples não diz qual identificador foi criado. O cliente teria de selecionar o destino e localizar a mensagem por conteúdo ou por uma marca única adicionada antes do envio.

APPENDUID incluiu na resposta etiquetada o UIDVALIDITY do destino e o UID atribuído. A fila local pode trocar o estado “aguardando inclusão” por uma referência remota concreta. A operação não fica mais dependente de uma segunda descoberta para saber qual registro é seu resultado.

O UIDVALIDITY é indispensável. UID 3955 não significa a mesma mensagem em todas as caixas nem para sempre. Servidor, nome da caixa, UIDVALIDITY e UID formam o contexto. Se a geração muda, o cliente precisa descartar o sentido anterior dos números, não reaproveitá-los por coincidência.

Para uma inclusão de várias mensagens, APPENDUID pode trazer um conjunto ordenado. O primeiro UID corresponde à primeira mensagem fornecida, e assim por diante. O conjunto não aceita * nem identificadores alheios ao comando. Dessa forma, quantidade e posição podem ser conferidas contra a entrada.

COPYUID registrou a troca de namespace

COPY não preserva o UID de origem. O destino tem sua própria sequência de identificadores e atribui novos nomes. COPYUID retorna o UIDVALIDITY dessa caixa, o conjunto de origem e o conjunto de destino.

Os dois conjuntos têm o mesmo número de itens. A associação é posicional. Não é necessário que os valores sejam iguais ou consecutivos; é a resposta do servidor que declara qual novo UID resultou de cada UID solicitado.

Essa regra também evita depender de números de sequência. Uma remoção feita por outra sessão pode renumerar a visão da caixa durante o comando. Os UIDs permanecem como escopo da operação, e a resposta não pode incluir mensagens estranhas. O recibo continua inteligível mesmo quando a posição visual muda.

Sua autoridade, porém, pertence ao cliente que recebeu a resposta. RFC 8474 observa que outro cliente não consegue deduzir depois a mesma relação entre caixas apenas examinando UIDs comuns. Identificadores de objeto foram propostos para esse problema mais amplo. COPYUID não é identidade global; é rastreabilidade de uma mutação.

O apagamento passou a exigir uma interseção

EXPUNGE remove definitivamente todas as mensagens marcadas \Deleted na caixa selecionada. Em uma caixa compartilhada, a marca pode ter sido colocada por outra pessoa que ainda não pretendia concluir a remoção.

UID EXPUNGE acrescenta um conjunto de UIDs ao comando. Só é removida a mensagem que está nesse conjunto e possui a marca. Um UID listado sem \Deleted permanece; uma mensagem marcada fora do conjunto também permanece. A intenção destrutiva ganha dois limites independentes.

Sem UIDPLUS, o caminho de compatibilidade era retirar temporariamente a marca das mensagens que deveriam sobreviver, executar EXPUNGE e restaurá-la. O procedimento pode ser necessário, mas toca mais estado compartilhado. UID EXPUNGE descreve diretamente quais decisões o cliente pretende tornar irreversíveis.

Privacidade também justificava silêncio

Um usuário pode ter permissão para depositar ou copiar uma mensagem em uma caixa sem poder selecioná-la ou examiná-la. Informar UIDVALIDITY e um novo UID revelaria características de uma área que o usuário não está autorizado a observar. Nessa condição, o servidor não deveria enviar APPENDUID ou COPYUID.

A ausência do código não desfaz o sucesso. Ela indica que a operação e a visibilidade de seu resultado pertencem a domínios de autorização diferentes. Se o cliente obtiver acesso de leitura, ainda pode buscar uma marca única; se não obtiver, precisa aceitar que pode criar sem inspecionar o nome criado.

Essa distinção impede um erro comum de desenho: exigir um recibo de identidade em toda mutação e, assim, pressionar o servidor a violar permissões ou fingir persistência. Compatibilidade segura precisa tratar a ausência prevista como estado próprio, não como exceção impossível.

MOVE mostrou quando entregar a correspondência

MOVE cria a mensagem no destino e remove a de origem. Para UID MOVE, um servidor com UIDPLUS deve fornecer COPYUID nas condições aplicáveis. Se as respostas EXPUNGE vierem primeiro, a numeração visível da origem muda antes de o cliente receber o mapa.

RFC 6851 recomendou que COPYUID fosse enviado em um OK não etiquetado antes das remoções. RFC 9051 integrou essa ordem ao IMAP4rev2. O recibo precisa chegar enquanto o estado necessário para interpretá-lo ainda está organizado.

Da otimização à disciplina de evidência

RFC 2359 introduziu o UIDPLUS em 1998 como otimização para operações, especialmente em uso desconectado. RFC 4315 o substituiu em 2005 e definiu melhor conjuntos, omissões e UIDNOTSTICKY. O registro da IANA continua associando a capacidade ao RFC 4315, e o IMAP4rev2 incorporou seus mecanismos.

O que amadureceu foi uma regra de alcance. Uma resposta pode dizer qual nome o servidor acabou de criar sem prometer que o nome vale fora daquela caixa, geração ou permissão. UID EXPUNGE pode limitar um ato irreversível sem transformar toda a caixa em transação serializada. A evidência é útil porque declara seus próprios limites.

Fontes e limites

A definição original está no RFC 2359, substituído pelo RFC 4315. O contexto base vem do RFC 3501; MOVE, do RFC 6851; a limitação entre clientes, do RFC 8474; e a integração ao IMAP4rev2, do RFC 9051. O registro da IANA lista UIDPLUS. As fontes não medem adoção nem transformam o mapping em prova criptográfica, autenticação ou entrega de correio.