Resumo

  • A RFC 10022 permite obter intervalos descendentes de UID próximos de uma quantidade solicitada de mensagens. Eles delimitam operações futuras, inclusive em UIDONLY; não congelam a caixa nem se tornam resultados de busca salvos.
  • As pontas do intervalo podem não corresponder a mensagens. O lote pode vir menor, encolher após exclusões e ter custo muito diferente em bytes, tempo e processamento, embora a contagem seja semelhante.
  • Daniel Eggert editou o documento de consenso da IETF. O mecanismo mantém a coordenação estreita: servidor, cliente e operadora continuam responsáveis por algoritmo, planejamento, consistência e resultado.

Imagine um painel que avança de 39 para 40 lotes concluídos. O quadragésimo intervalo foi calculado, mas nenhum FETCH terminou; centenas de mensagens já haviam sido expurgadas e o cliente precisou refazer o checkpoint. A barra está tecnicamente ligada a uma resposta real e, ainda assim, descreve a coisa errada.

A RFC 10022, IMAP UIDBATCHES Extension, publicada em julho de 2026 no Standards Track da IETF, foi editada por Daniel Eggert, da Apple Inc. Ela permite que o cliente predetermine intervalos de UID que limitam a quantidade de mensagens de operações posteriores. Isso ajuda principalmente quando UIDONLY proíbe números de sequência.

O ganho é operacional: dividir antes de executar. Mas o intervalo não atesta que o trabalho foi feito e não oferece a estabilidade típica de uma página baseada em snapshot.

Preparar não é executar

O servidor anuncia UIDBATCHES, o cliente seleciona uma caixa e informa mensagens por lote, com um intervalo opcional de índices. A resposta vem dos UIDs mais altos para os mais baixos. O primeiro lote cobre a região mais recente.

Depois disso, o cliente ainda decide o que fazer. Pode buscar cabeçalhos, baixar corpos, procurar uma condição ou alterar flags. Cada comando tem custo e resultado próprios. UIDBATCHES não é SEARCH nem UID SEARCH, e SEARCHRES não deve guardar o resultado em $.

Essa regra impede que uma conveniência de implementação mude o tipo da evidência. Uma partição não é um conjunto de mensagens encontradas. O produto pode dizer “40 intervalos preparados”; só as respostas posteriores autorizam “mensagens obtidas” ou “sincronização concluída”.

PARTIAL também não é sinônimo. Ele oferece SEARCH e FETCH paginados. UIDBATCHES entrega limites antecipados para que o cliente escolha a operação. Estratégias podem ser parecidas, mas a semântica do checkpoint continua diferente.

A faixa numérica contém buracos

Os UIDs inicial e final devolvidos podem não existir. Exclusões deixam lacunas, e o servidor pode escolher limites eficientes que atravessam essas lacunas enquanto abrangem aproximadamente a quantidade pedida de mensagens existentes.

Na última faixa, terminar em UID 1 é permitido mesmo se a mensagem mais antiga tiver UID 302. O número 1 marca que aquela é a faixa final; não declara uma mensagem inexistente.

Logo, subtrair as pontas não conta mensagens. E um UID situado matematicamente dentro da faixa não prova presença. O cliente precisa conservar o intervalo original e, em separado, os UIDs efetivamente encontrados pela operação posterior.

Esse desenho evita que o servidor tenha de produzir uma enumeração completa apenas para dividir trabalho. A economia é útil, desde que a aplicação não recoloque a enumeração por suposição.

Quantidade parecida não significa custo parecido

O pedido mínimo é de 500 mensagens. O servidor não pode incluir mais mensagens do que o valor solicitado. Deve buscar o valor exato e, quando possível, pelo menos 90%; pode retornar menos por uma simplificação ou eficiência substancial, ou porque a caixa mudou durante o cálculo. O lote final normalmente contém o restante.

Nada disso fixa octetos. Quinhentas mensagens automáticas pequenas e quinhentas com anexos de vídeo são lotes semelhantes apenas na contagem. FETCH de cabeçalho e de corpo têm perfis distintos. Uma busca sem índice pode dominar o tempo do servidor; um STORE pode desencadear atualização adicional.

A RFC descreve uma otimização que pode reduzir trabalho, memória e volume retornado. Não promete uma duração uniforme. O controle adaptativo deve observar mensagens reais, bytes, tempo de servidor e cliente, operação, falhas e repetição.

Também precisa nomear o objetivo. Se o limite serve para proteger memória, medir apenas latência pode enganar. Se serve para dar progresso rápido ao usuário, throughput médio pode esconder uma cauda longa. O número do lote é uma entrada da política, não seu indicador de sucesso.

Exclusões fazem o lote encolher

Mensagens novas recebem UIDs superiores e não entram numa faixa já devolvida. O lote não cresce. Mensagens expurgadas saem dele, por isso ele pode encolher.

O cliente pode acompanhar EXPUNGE, VANISHED e EXISTS. A RFC considera apropriado recalcular quando outra caixa é selecionada, quando mais de metade do tamanho do lote foi expurgada ou quando chegaram mais de meia leva de mensagens novas. Fora dessas condições, o cliente não deve repetir UIDBATCHES.

O motivo é proteção de recursos. Calcular lotes pode ser caro, e o servidor deve impor limites em vez de confiar somente no cliente. Uma atualização automática sem contador de mudanças pode se transformar em ataque acidental.

O recibo deve guardar o tamanho original, os eventos acumulados, o momento em que o limiar foi cruzado e o código de resposta. LIMIT, TOOFEW e TOOMANY não são falhas genéricas. Eles informam frequência, granularidade ou escala que a próxima decisão precisa corrigir.

Caixa selecionada e UIDVALIDITY formam o limite de identidade. Levar uma faixa em cache para outra caixa ou outra validade não produz apenas dados antigos; produz UIDs sem referência confiável.

Janelas consecutivas precisam de uma costura

Uma caixa grande pode exigir pedidos parciais: 1:100 e depois 101:200. Como as quantidades são aproximadas e o estado muda, a RFC sugere sobrepor a borda: 1:100, 100:200, 200:300.

O lote repetido permite comparar os cálculos. Uma diferença sinaliza possível inconsistência. O cliente decide se refaz, aumenta a sobreposição, bloqueia uma exportação ou continua registrando incerteza. A sobreposição não cria snapshot nem corrige sozinha a divergência.

Se o pipeline remove duplicatas antes da comparação, destrói a costura que poderia explicar uma lacuna. A evidência deve ser mantida até a decisão, com algoritmo e resultado da comparação.

Pedidos com faixa não podem abranger mais de 100 mil mensagens. O servidor precisa suportar pelo menos esse alcance, mas pode rejeitar mais com TOOMANY. Em caixas enormes, até um pedido sem faixa para todos os lotes pode ser recusado. MESSAGELIMIT fornece outro teto que o cliente deve considerar.

O mínimo de 500 também evita usar lotes minúsculos para reconstruir informação posicional que UIDONLY retirou. Eficiência e arquitetura de privacidade caminham juntas nessa restrição.

Vazio pode ser caixa ou janela

Uma caixa vazia recebe resposta UIDBATCHES sem faixas e conclusão OK. Uma caixa com mensagens responde da mesma forma quando os índices pedidos não existem. A diferença depende do tag, do intervalo solicitado e de EXISTS.

Uma interface que mostra somente “nenhum lote” mistura causas opostas. No primeiro caso, não há conteúdo. No segundo, a janela ficou além do fim. A recuperação pode ser encerrar com sucesso ou corrigir o checkpoint; não são a mesma ação.

Guardar a pergunta é parte de guardar a resposta. Tags parecem detalhe de protocolo, mas são a chave para associar uma resposta assíncrona ao pedido certo. O mesmo vale para código, capacidades e identidade da caixa.

Daniel Eggert dentro do limite das fontes

Na captura de 1º de setembro de 2026, o perfil oficial de Daniel Eggert no IETF Datatracker listava as RFCs 10022 e 9979. Uma publicação de 2022 do Swift.org sobre SwiftNIO IMAP o identificava como integrante da equipe da Apple que trabalha no Mail para iOS e macOS e ligava seu perfil público no GitHub.

Esse contexto não comprova que um produto Apple específico implementa UIDBATCHES, nem que Eggert controla o comportamento de servidores ou o consenso da IETF. Editor, implementador e operador são papéis distintos.

A contribuição registrada é mais precisa: um mecanismo comum que permite divisão eficiente sem centralizar a função de custo do cliente ou o algoritmo do servidor. A Minimum Initial Specification de Heng Lu ajuda a ler essa escolha. O padrão fixa o mínimo necessário; decisões futuras permanecem locais. Running-Code Primacy exige que o resultado venha das operações observadas.

O recibo que a barra de progresso não mostra

Registrar servidor, fronteira da conta, caixa, UIDVALIDITY e capacidades. Para cada comando, guardar tag, quantidade, índices, código e faixas. Juntar EXISTS, EXPUNGE, VANISHED, condição de recálculo e comparação de sobreposição.

Em seguida, acompanhar comando posterior, UIDs reais, ausências, bytes, tempos, erros, repetição, checkpoint local e resultado visível. Conteúdo e credenciais não precisam ser expostos; contagens, hashes, identificadores limitados e horários sustentam auditoria suficiente.

Assim, um lote continua sendo uma boa unidade de coordenação sem ser promovido prematuramente a página ou conclusão.

Fontes