Resumo

  • MESSAGELIMIT=N informa quantas mensagens uma única operação pode processar; não limita o tamanho da caixa nem prova que o servidor já bloqueia estritamente toda chamada na cifra anunciada.
  • SEARCH, FETCH, STORE, MOVE e UID EXPUNGE podem produzir efeito parcial válido e terminar com OK, enquanto COPY e MULTIAPPEND preservam atomicidade e não fazem nada quando o conjunto é grande demais.
  • A migração segura mede quem respeita o limite, mantém separado o teto duro e exige reconciliação do conjunto original até que toda sobra tenha destino explicado.

O exemplo de mil e dez mil não é uma licença para o servidor dizer uma coisa e fazer outra indefinidamente. É uma estratégia de convivência descrita pela própria RFC 9738. O servidor anuncia mil como limite que clientes compatíveis devem observar. Por algum tempo, só aplica uma barreira dura em dez mil. Assim, software atualizado reduz consumo de memória e CPU, enquanto instalações antigas não quebram de uma vez.

O passo seguinte depende de observação. Tentativas acima de mil podem ser registradas. Quando a população de clientes tiver se adaptado, o operador endurece a aplicação. A sequência correta é anúncio, comportamento, telemetria e corte. A ordem inversa — publicar a capacidade e presumir adoção universal — transforma uma ferramenta de compatibilidade em fonte de mensagens perdidas.

Um limite por comando

MESSAGELIMIT cobre SEARCH, FETCH, STORE, COPY, MOVE, as variantes UID, APPEND e UID EXPUNGE. SAVELIMIT serve ao caso mais restrito em que apenas COPY e APPEND são limitados. A RFC recomenda que o valor anunciado não fique abaixo de mil mensagens.

N não é capacidade da caixa, quota, retenção ou tamanho máximo de uma mensagem. É o volume que uma invocação pode processar. Em SEARCH, conta-se o universo examinado, não só as correspondências devolvidas. Se mil mensagens forem avaliadas e vinte atenderem ao filtro, vinte é um resultado correto da faixa, não uma contagem completa da consulta original.

Quando o código aparece, o processamento deve avançar do UID mais alto para o mais baixo. O último parâmetro, quando fornecido, é o menor UID processado naquela rodada. Ele permite construir a continuação, mas não congela a caixa, não enumera o restante e não sobrevive sozinho a uma troca de UIDVALIDITY.

Chegadas novas podem surgir acima da marca. Expunges podem abrir lacunas abaixo dela. Um UID mencionado pode desaparecer antes da próxima chamada. O valor só é interpretável com caixa selecionada, geração, comando e instante.

OK não significa que nada ficou para trás

Uma resposta FETCH pode trazer os dados das mil mensagens mais recentes e terminar com OK [MESSAGELIMIT …]. SEARCH devolve as correspondências encontradas nessa faixa. STORE pode já ter alterado flags. MOVE pode ter copiado para o destino e expungido da origem. UID EXPUNGE pode ter removido permanentemente uma parte do conjunto marcado.

Não se trata de simulação. Houve trabalho e, em alguns casos, mudança destrutiva. Classificar tudo como falha apaga o efeito ocorrido. Classificar tudo como conclusão apaga a população ainda não tocada.

Cada operação continua de um jeito. UID STORE precisa reduzir a faixa para não incluir novamente o menor UID processado. UID MOVE pode repetir o conjunto original, pois as mensagens já movidas deixaram a origem. MOVE por números de sequência precisa recalcular a seleção depois dos expunges. UID EXPUNGE pode repetir o mesmo parâmetro UID até que o código desapareça ou uma falha explícita encerre a série.

Um mecanismo genérico de retry não preserva essas diferenças. Ele pode reaplicar flags, pular um intervalo ou atingir outra mensagem depois da renumeração. O cliente deve registrar UIDs observados, efeitos confirmados, marca inferior e regra usada para produzir a próxima chamada.

Também precisa ler respostas não etiquetadas. Se EXPUNGEISSUED ocupar o OK final, MESSAGELIMIT é enviado em um NO não etiquetado. Um parser que guarda só a última linha celebra sucesso e descarta a dívida de continuação.

A atomicidade muda a consequência

COPY e UID COPY são atômicos. Acima do limite, a resposta é NO [MESSAGELIMIT …] e nenhuma mensagem é copiada. MULTIAPPEND também é tudo ou nada; o servidor não pode anexar a primeira parte de um grupo grande demais.

MOVE não possui essa atomicidade global. Uma faixa pode mudar de caixa antes do retorno. STORE e UID EXPUNGE também deixam efeito parcial. Logo, o mesmo código de limite pode descrever recusa sem efeito ou sucesso com efeito. O tipo da operação precisa viajar com o evento.

EXPUNGE, CLOSE e STATUS UNSEEN ficam fora desse teto. O servidor não pode impor MESSAGELIMIT a eles. Isso preserva o alcance IMAP dessas operações, mas não transforma o OK em prova de persistência no armazenamento, sincronização em outro cliente ou visualização humana.

A extensão PARTIAL da RFC 9394 cria mais uma distinção. Se o cliente pedir explicitamente uma janela PARTIAL maior que N, o servidor recusa e não trabalha. Sem PARTIAL, um FETCH parecido pode entregar uma faixa implícita e OK. Janela solicitada e truncamento imposto não têm a mesma consequência.

Uma busca salva pode carregar a lacuna

Com SEARCHRES, o resultado de SEARCH pode ser guardado em $. Quando a busca chega ao limite, a RFC 9738 manda truncar também o resultado salvo. $ contém as correspondências válidas da faixa examinada, não as correspondências de toda a intenção.

Depois, uma operação sobre $ pode ser menor que N e terminar sem novo aviso. Seu transcript parece completo, mas a entrada já nasceu incompleta. Sucesso posterior não amplia retroativamente o denominador da primeira busca.

Por isso, o resultado salvo precisa de contexto: caixa, UIDVALIDITY, consulta, faixa inicial, limite, menor UID processado, horário e indicação de continuação. Um identificador de cache sem essa origem vira um atalho para conclusões erradas.

UIDAFTER e UIDBEFORE ajudam a expressar a próxima busca. Não impedem chegada, não restauram UID removido e não atravessam mudança de geração. São critérios, não bloqueios transacionais.

Compatibilidade é um estado mensurável

A RFC descreve o efeito em clientes que não entendem a extensão. Em caixas maiores que N, COPY pode falhar sempre. FETCH, SEARCH e MOVE podem ficar presos às N mensagens mais recentes. Contagens sem extensão podem ser incorretas. Um usuário que volta depois de uma semana pode não saber que parte da caixa sumiu da visão.

Por isso a aplicação gradual tem valor. Anunciar sem bloquear dá tempo para clientes novos demonstrarem comportamento. Um soft limit menor que o hard limit preserva serviço para clientes antigos enquanto produz evidência sobre sua presença. O operador pode endurecer quando o risco de ruptura estiver compreendido.

Mas a telemetria precisa manter as categorias. Um comando acima de mil pode ser legado tolerado, software novo que ignorou a capacidade ou tráfego anterior ao corte rigoroso. Chamar todos de “não conformes” não melhora interoperabilidade; apenas esconde a fase real da migração.

A presença de MESSAGELIMIT=1000 no CAPABILITY prova o valor anunciado naquela sessão. Para provar enforcement, é preciso observar respostas no limiar. Para provar adoção do cliente, é preciso observar tamanhos e continuações. Para provar resultado completo, é preciso reconciliar o conjunto final. Cada afirmação tem evidência própria.

A reconciliação fecha o trabalho

Uma tarefa de caixa inteira começa definindo a população pretendida. Em cada rodada registra caixa, UIDVALIDITY, comando, conjunto pedido, classe atômica, capacidade vista, UIDs devolvidos, efeitos, respostas não etiquetadas, status final, limite e menor UID.

No fechamento, separa mensagens previstas no início, mensagens examinadas ou alteradas, mensagens que desapareceram no caminho e chegadas novas fora do escopo. Qualquer diferença não explicada continua pendente. A última chamada sem código de limite encerra aquela cadeia, não produz uma fotografia retroativa da caixa dinâmica.

UIDBATCHES planeja intervalos. PARTIAL pede uma página. MESSAGELIMIT relata a barreira encontrada durante execução. SEARCHRES mantém uma população. QRESYNC ajuda a acompanhar mudança. Reduzir tudo a “processamento em lote” elimina exatamente as fronteiras necessárias à auditoria.

O servidor pode anunciar mil e tolerar dez mil durante a transição. Essa flexibilidade é segura quando anúncio, aplicação e conclusão permanecem separados. A telemetria deve ser ponte entre versões, não certificado automático de adesão. E o OK deve ser recibo do trabalho executado, não desculpa para esquecer o que restou.

Fontes