Resumo

  • JMAPACCESS anuncia acesso por IMAP e JMAP ao mesmo conjunto completo de mensagens, com os mesmos identificadores para os mesmos objetos.
  • A inferência sobre credenciais depende da forma usada para autenticar no IMAP. O acesso JMAP posterior ainda precisa ocorrer.
  • Um programa de migração deve separar descoberta, autenticação, identidade, estado e efeito; a extensão não congela a caixa postal.

Uma equipe pode atingir cem por cento de cobertura de uma capacidade sem ter concluído a mudança que interessa ao usuário. O anúncio foi habilitado em todos os caminhos previstos. Ainda falta demonstrar que os clientes chegam à conta certa, reconhecem os objetos e tratam suas operações pendentes corretamente. Essa é uma possibilidade de gestão, não um resultado medido em algum provedor.

RFC 9698 permite nomear a diferença. O documento de janeiro de 2025, classificado pelo RFC Editor como Proposed Standard, define JMAPACCESS para migração gradual e uso de extensões JMAP em clientes IMAP. Aproveitar uma sessão autenticada evita parte da descoberta repetida. Não transforma anúncio em comprovante de execução.

O que pertence ao contrato comum

A cobertura é integral: a extensão admite equivalência completa do conjunto de mensagens nos dois protocolos. Oferecer apenas uma parte conveniente pelo novo caminho não satisfaz essa descrição. A identidade também tem uma condição: uma caixa ou mensagem com determinado object ID em um protocolo deve ser acessível como o mesmo objeto, com o mesmo ID, no outro.

Por isso, o servidor precisa anunciar OBJECTID, definido em RFC 8474. Não basta transportar um UID comum de IMAP e presumir que ganhou significado universal. No JMAP, RFC 8620 limita a unicidade dos IDs de registros ao tipo de dados dentro de uma conta. Conta e tipo fazem parte da evidência de correspondência.

A capacidade depende também do modo de autenticação. Quando LOGIN ou AUTHENTICATE termina com sucesso, o servidor considera as credenciais usadas. Se puder inferir que elas bastam para JMAP, deve incluir JMAPACCESS nas listas de capacidades seguintes. Um backend OAuth compartilhado ou uma base comum de senhas são exemplos do texto, não afirmações sobre produtos atuais.

O caso de transição é especialmente útil: IMAP continua aceitando senha para clientes antigos, mas JMAP já não aceita. O primeiro login pode funcionar sem JMAPACCESS. A ausência da capacidade, isoladamente, não demonstra ausência de serviço JMAP; o caminho de credenciais explica a diferença.

A descoberta tem uma resposta própria

O cliente envia GETJMAPACCESS. Conhecendo o serviço equivalente, o servidor retorna uma resposta não etiquetada JMAPACCESS, com uma única URL de Session, seguida de OK etiquetado. Sem conhecimento desse serviço, deve retornar BAD e não anunciar a capacidade.

Há uma correção relevante para quem usa os exemplos como roteiro. A errata técnica 8635, verificada em 21 de novembro de 2025, troca JMAPACCESS por GETJMAPACCESS no comando do exemplo 2. Ela corrige o exemplo; não relata incidente, vulnerabilidade explorada ou novo desenho de autenticação.

O destino é o recurso Session de JMAP. Um GET autenticado bem-sucedido ali entrega o objeto com contas e capacidades disponíveis para aquelas credenciais. Receber a URL não constitui esse sucesso. JMAPACCESS não emite uma credencial e não dispensa o cliente de autenticar pelo novo protocolo.

O argumento de segurança do RFC permanece estreito: o cliente já possui credenciais válidas e pode localizar o destino pelos mecanismos existentes de descoberta JMAP; por isso, os autores consideram pequeno o benefício adicional da revelação para um atacante. A avaliação não certifica a configuração de um ambiente real nem suspende os requisitos de transporte e autenticação.

Identidade não conserva o instante

A mensagem lida por IMAP pode ser apagada antes de uma consulta JMAP meio segundo depois. RFC 9698 não altera sua duração de vida. Para atribuir uma falha à correspondência, é preciso primeiro distinguir o objeto que desapareceu do objeto que continua presente e recebeu uma identidade incompatível.

O mesmo cuidado vale para os campos. O RFC incentiva alinhamento de flags e outros dados, mas não exige, por si, nomes de caixas iguais. RFC 8621 tem regras próprias para nomes, papéis e associações. Um Email ID permanece após mudança de caixa, e o modelo pode permitir várias associações simultâneas. Comparar telas ou nomes sem considerar essas regras produz um teste fácil de passar ou reprovar pelos motivos errados.

Em RFC 8474, EMAILID identifica conteúdo imutável; instâncias com o mesmo EMAILID podem ter palavras-chave distintas. Tampouco a representação de endereços é sempre idêntica. Nas condições de IMAP legado descritas por RFC 9698, a falta de ativação de UTF8=ACCEPT pode resultar em campos rebaixados, enquanto JMAP entrega os exatos. RFC 6855 explica por que substitutos assim não equivalem ao original para todos os usos, incluindo resposta e verificação de assinatura.

Essa divisão conversa com a especificação inicial mínima de Lu Heng: manter pequeno o acordo comum. Sua primazia do código em execução e análise das camadas de realidade servem aqui de lente editorial para separar declaração e efeito. Os fatos técnicos continuam apoiados nos RFCs.

Não foram testados provedores, medidos ganhos ou identificados incidentes neste trabalho. A recomendação é registrar etapas distintas: capacidade, endereço, autenticação, conta e objeto, estado reconciliado, resultado da ação. São critérios operacionais propostos, não obrigações adicionais inventadas para o protocolo.