Resumo

  • RFC 5182 permite que $ represente zero mensagens. FETCH pode não produzir nenhuma resposta de dados, e COPY pode copiar nada; ambos ainda podem terminar com OK.
  • Para fechar uma obrigação, é preciso comparar a população pretendida, o resultado instalado, as mudanças até o consumo e as mensagens realmente afetadas. O status IMAP responde apenas se o comando foi executado.

O relatório de migração mostrava cem por cento de sucesso: todas as operações COPY haviam terminado com OK. A contagem do destino, porém, não mudara. O painel media comandos aceitos, não mensagens transferidas.

RFC 5182 torna esse descompasso explícito. Seu exemplo envia uma busca SAVE que não encontra mensagens e, em seguida, COPY $. O servidor responde que a busca terminou e que a cópia terminou, mas nada foi copiado. Não há erro de protocolo para esconder. O erro surgiria ao transformar esse OK em prova de conclusão da migração.

O cenário aqui é analítico, não uma denúncia sobre um serviço. Ele revela uma regra mais ampla: resultado vazio, comando correto e objetivo não cumprido podem coexistir.

O atalho mantém o resultado no servidor

SEARCHRES evita uma operação redundante. Sem ele, o servidor manda a lista de mensagens encontradas; o cliente interpreta a lista, converte-a em message-set e a devolve para FETCH, STORE, COPY, outra SEARCH ou UID EXPUNGE. Com RETURN (SAVE), a lista fica numa variável interna e $ ocupa o lugar dos identificadores.

O servidor anuncia SEARCHRES e também precisa implementar ESEARCH. Se nenhuma outra opção de retorno for pedida, SAVE suprime a resposta SEARCH que normalmente mostraria a lista. O cliente ganha menos tráfego, menor latência e possibilidade de pipeline.

Em troca, precisa respeitar o contrato real. Há uma única variável sem nome atribuído pelo cliente. Um SAVE posterior substitui o anterior. O protocolo não promete guardar a consulta, a justificativa, um snapshot temporal ou várias versões.

Chamar isso de “pesquisa salva” numa interface cria uma camada local. Ela só é verdadeira se o produto armazenar por conta própria o texto da busca, o escopo, a identidade da operação, o autor e a população esperada.

Há muitos caminhos até zero

Uma pesquisa legítima pode não encontrar nada. Depois de SELECT ou EXAMINE bem-sucedido, a variável é reiniciada vazia. Um novo UIDVALIDITY enquanto a caixa está aberta também a limpa. Uma pesquisa com SAVE que retorna NO limpa o valor, e uma recusa NOTSAVED faz o mesmo. EXPUNGE pode remover o último membro.

Essas causas têm significados operacionais diferentes. Zero porque a política não tinha alvos pode ser um resultado esperado. Zero porque a seleção mudou indica perda de contexto. Zero após SAVE recusado indica falha de preparação. Zero após EXPUNGE pode mostrar concorrência legítima ou interferência relevante.

O comando consumidor não distingue essas histórias. Para ele, $ vazio é um message-set válido e sem correspondências. Por isso, a telemetria deve preservar a causa antes de resumir o resultado.

Um controle de retenção precisa de pelo menos quatro números: itens no escopo da regra, itens encontrados, itens presentes no conjunto no momento do consumo e itens efetivamente alterados. O estado apresentado ao usuário é uma quinta verificação. Taxa de OK não substitui nenhuma delas.

A falha de SAVE fecha o estado

RFC 5182 trata respostas diferentes de modo deliberado. SEARCH com BAD não altera a variável. SEARCH sem SAVE também não a altera, tanto no sucesso quanto num NO. Já SEARCH com SAVE e resposta NO define o conjunto como vazio.

Assim, uma tentativa fracassada de instalar um resultado novo não deixa o resultado antigo escondido sob o mesmo símbolo. É uma escolha de segurança. Um cliente que queira repetir com outro charset, por exemplo, deve refazer também a busca anterior da cadeia.

O servidor pode limitar resultados guardados entre conexões por causa do custo de estado e do risco de negação de serviço. Ao exceder o limite, devolve NO com NOTSAVED e esvazia a variável. A capability indica compreensão do mecanismo, não reserva recursos para todo SAVE.

Depois dessa resposta, executar STORE $ não aplica uma política ao conjunto anterior. Executa uma operação sobre nada. O retry deve reconstituir a intenção, não apenas reenviar o consumidor.

A caixa selecionada é parte do identificador

SELECT e EXAMINE zeram o estado porque números de sequência só têm sentido na caixa selecionada. UID também depende da combinação entre nome da caixa e UIDVALIDITY. Uma nova geração não herda a autoridade da anterior.

EXPUNGE altera o conjunto sem nova busca. O membro expurgado sai, e os números de sequência restantes podem mudar. Portanto, $ não é um snapshot imutável; é estado de sessão que acompanha eventos específicos.

Além disso, o consumidor define o espaço de números. Um resultado de SEARCH pode alimentar UID FETCH e ser resolvido como UIDs. Um resultado de UID SEARCH pode alimentar FETCH e ser resolvido como sequências. Registrar apenas a forma da busca produtora não basta.

A evidência mínima liga conexão, caixa, UIDVALIDITY, critérios, opções, tag produtora, ordem recebida, expunges e comando consumidor. Sem esse encadeamento, o símbolo não identifica a população.

Pipeline não cria resultados paralelos

SAVE seguido de um comando com $ estabelece dependência direta; o servidor respeita a ordem recebida, mesmo que otimize internamente. Um SAVE pode alimentar vários consumidores claros, como COPY e STORE.

Dois SAVE não geram dois handles. O segundo substitui o primeiro. Tags correlacionam respostas, mas não nomeiam variáveis separadas. Um executor assíncrono que acompanha apenas respostas pode associar a ação ao mandato errado.

Cada consumidor deve apontar, no registro local, para o SAVE vigente na sua posição da sequência. A chegada de um segundo SAVE fecha a disponibilidade futura do primeiro conjunto. A ordem de recebimento é evidência; o tempo de chegada das respostas é insuficiente.

RFC 5267 oferece CONTEXT para outra necessidade: contextos identificados por tag, atualizações e cancelamento. SEARCHRES é o último resultado, não uma coleção de contextos. Escolher o mecanismo certo evita transformar convenção local em falsa interoperabilidade.

As opções definem o tamanho salvo

Mesmo sem falha, SAVE não significa sempre todos os resultados. SAVE MIN guarda apenas o menor; SAVE MAX, apenas o maior; os dois juntos guardam uma ou duas mensagens. Com ALL ou COUNT, RFC 5182 exige guardar todos os encontrados.

RFC 9394 combina SAVE com PARTIAL e conserva a janela parcial, mais extremos aplicáveis quando declarados. RFC 9738 exige que uma busca limitada por MESSAGELIMIT grave apenas o trecho truncado; esse limite de completude já tem análise própria no BTW. Aqui, a fronteira é que a opção de retorno define o conjunto, mesmo quando a execução foi perfeita.

“Copiar o resultado da busca” é, portanto, uma instrução incompleta. O recibo precisa dizer se o resultado era total, extremo, página ou subconjunto limitado.

Fechar pelo efeito

IANA registra SEARCHRES e RFC 9051 incorpora sua máquina de estados em IMAP4rev2. Isso prova uma linguagem comum, não adoção, conformidade de produto, disponibilidade de memória ou conclusão de uma política.

Trabalho sensível precisa de um objeto local durável: ID da intenção, consulta e opções, caixa e UIDVALIDITY, produtor e consumidores, ordem, resets, expunges, cardinalidade e efeito. Só então $ pode ser usado como caminho rápido sem virar o registro oficial.

A liderança deveria perguntar: quantas mensagens deveriam ter sido tratadas, quantas entraram no conjunto, quantas restavam no consumo e quantas mudaram? Se a resposta for apenas “todas as chamadas deram OK”, a operação mediu o mensageiro e perdeu a entrega.

Fontes

  1. RFC 5182 — HTML
  2. RFC 5182 — texto simples
  3. Página de informações do RFC Editor
  4. Documento no IETF Datatracker
  5. Histórico no IETF Datatracker
  6. Referências no IETF Datatracker
  7. Errata do RFC 5182
  8. RFC 9051 — IMAP4rev2
  9. Página de informações do RFC 9051
  10. RFC 4731 — ESEARCH
  11. RFC 4466 — ABNF consolidada do IMAP
  12. RFC 4315 — UIDPLUS
  13. RFC 3501 — IMAP4rev1
  14. RFC 5267 — IMAP CONTEXT
  15. RFC 9738 — MESSAGELIMIT
  16. RFC 9394 — PARTIAL
  17. Registro de capacidades IMAP da IANA
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação inicial mínima e adoção voluntária
  20. Heng Lu — prioridade do código em execução