Resumen

  • RFC 9698 conecta el descubrimiento de JMAP con una sesión IMAP autenticada y exige equivalencia completa del conjunto de mensajes e identidad de objetos.
  • El servidor anuncia JMAPACCESS cuando puede inferir que las credenciales utilizadas bastan para JMAP; la autenticación posterior sigue siendo un hecho separado.
  • La extensión no congela los mensajes ni iguala por sí sola sus campos y estados. Una migración requiere reconciliar esas diferencias antes de retirar el acceso anterior.

Un cliente lee un mensaje por IMAP. Medio segundo después intenta obtenerlo por JMAP y no lo encuentra. La explicación puede ser perfectamente ordinaria: alguien lo eliminó durante ese intervalo. Antes de declarar rota la migración, hace falta reconstruir el tiempo.

La advertencia está en RFC 9698. Es reveladora porque limita una promesa que, leída deprisa, parece total: el mismo correo está disponible por los dos protocolos. «El mismo» identifica la correspondencia; no convierte dos lecturas sucesivas en una instantánea indivisible.

Publicado en enero de 2025 y registrado como Proposed Standard, el documento define JMAPACCESS para facilitar migraciones graduales y utilizar extensiones JMAP dentro de clientes IMAP. El punto de partida es valioso: aprovechar una relación ya autenticada para descubrir otra vía. No hay aquí una medición de ahorro ni una constatación de despliegue por un proveedor.

Una capacidad ligada al modo de entrar

Tras completar LOGIN o AUTHENTICATE, el servidor evalúa el procedimiento empleado. Cuando puede deducir que las credenciales son suficientes para JMAP, debe incluir JMAPACCESS en las listas de capacidades posteriores. Compartir un sistema OAuth o una base de contraseñas son ejemplos del RFC que permiten esa deducción.

También aparece el caso contrario: IMAP mantiene temporalmente contraseñas para clientes antiguos, mientras JMAP deja de aceptarlas. El usuario entra en IMAP, pero no recibe la capacidad. La ausencia no demuestra que JMAP no exista. Muestra por qué una estadística de compatibilidad que ignore el método de autenticación puede inducir a error.

La capacidad incluye otras dos condiciones. El conjunto de mensajes ha de ser completamente equivalente; una selección parcial no basta. Y una carpeta o mensaje identificado como objeto en un protocolo debe ser accesible como el mismo objeto, con el mismo identificador, en el otro. El servidor debe anunciar además OBJECTID, cuya base es RFC 8474.

No se trata de reutilizar sin contexto un UID de IMAP. Tampoco de convertir una cadena coincidente en identidad global. RFC 8620 limita la unicidad de los identificadores de registros JMAP al tipo de datos y a la cuenta. Ambos deben acompañar al identificador cuando se comprueba la correspondencia.

Lo que entrega GETJMAPACCESS

El cliente solicita el destino mediante GETJMAPACCESS. Si el servidor conoce el servicio correspondiente, devuelve una respuesta sin etiqueta JMAPACCESS, con una única URL de la sesión, seguida de un OK etiquetado. Si no lo conoce, responde BAD y no debe anunciar la capacidad.

La errata técnica 8635, verificada el 21 de noviembre de 2025, corrige el ejemplo 2: allí figuraba erróneamente JMAPACCESS como comando. La sustitución por GETJMAPACCESS no es un informe sobre una vulnerabilidad ni un rediseño de la autenticación.

La URL identifica el recurso Session. El GET autenticado posterior produce el objeto que describe cuentas y capacidades disponibles para esas credenciales. Haber recibido la dirección no prueba que esa operación ya haya funcionado. La extensión no entrega credenciales nuevas ni elimina la necesidad de autenticarse.

RFC 9698 considera limitada la divulgación adicional porque el cliente ya dispone de credenciales válidas y puede localizar la dirección mediante el descubrimiento propio de JMAP. Esa justificación no verifica la seguridad de cada instalación. Los requisitos de transporte y autenticación de JMAP conservan su función.

Identificar no equivale a igualar cada campo

El documento anima a mantener iguales los indicadores y otros datos, en la medida de lo posible. No impone por sí mismo nombres de carpetas idénticos. Eso no autoriza cualquier divergencia: RFC 8621 regula nombres, roles y pertenencia a carpetas. Su modelo permite que el identificador de un correo sobreviva a un traslado y que un mensaje pertenezca a varias carpetas.

La comparación correcta depende del campo. EMAILID, en RFC 8474, corresponde al contenido inmutable; distintas instancias con ese identificador pueden tener palabras clave diferentes. Una acción pendiente sobre estado mutable necesita más contexto que la identidad del contenido.

Las direcciones internacionalizadas aportan otro límite. En las condiciones de IMAP antiguo contempladas por RFC 9698, no activar UTF8=ACCEPT puede dejar al cliente con campos degradados mientras JMAP devuelve los correctos. RFC 6855 explica que esas representaciones sustitutivas pueden afectar respuestas y comprobaciones de firmas. Ni una cadena de identidad compartida ni una captura de pantalla prueban equivalencia semántica.

La lectura de Lu Heng sobre especificación inicial mínima ayuda a valorar la modestia del mecanismo. La primacía del código en ejecución y la separación de capas de realidad exigen comprobar qué ocurrió después de la declaración. Se utilizan aquí como criterio editorial, no como evidencia sustitutiva del estándar.

La secuencia propuesta es concreta: capacidad, dirección, autenticación efectiva, cuenta y objeto, estado actual, resultado de la acción. Este informe no ha probado servicios, incidentes ni rendimiento. Sí permite definir qué evidencia falta cuando un programa de migración se declara terminado demasiado pronto.