Por qué jmail.com.es va más rápido — JMAP

jmail.com.es habla JMAP nativo, no solo IMAP. JMAP es el sucesor moderno de IMAP (RFC 8620 + 8621, 2019) y es el protocolo que hace que tu buzón abra al instante, sincronice sin tirar de la batería, y notifique al móvil sin tener que sondear cada minuto.

Esta página explica qué es y, sobre todo, qué te cambia en la práctica si pasas de IMAP a JMAP.

En una imagen: la diferencia que importa

Abrir el correo por primera vez en un cliente nuevo.
Tres carpetas: Inbox, Sent, Trash.
Pedimos: "dame la lista de correos de cada carpeta y márcame qué hay".

IMAP                                JMAP
────────────────────────────────    ─────────────────────────────────
1.  CAPABILITY                      1.  Una sola petición HTTP
2.  LOGIN                               (un JSON con 3 sub-llamadas
3.  SELECT Inbox                         encadenadas: Mailbox/get,
4.  FETCH 1:* (FLAGS ENVELOPE)           Email/query, Email/get)
5.  SELECT Sent                     ────────────────────────────────
6.  FETCH 1:* …                     ➜ 1 viaje de red
7.  SELECT Trash
8.  FETCH 1:* …
────────────────────────────────
➜ 7 viajes de red

Cada “viaje de red” es ida + vuelta del cliente al servidor. En una red WiFi local da igual. En una conexión móvil con 80 ms de latencia, 7 viajes = ~600 ms de espera real antes de ver nada. Con JMAP la misma operación son ~80 ms.

Esto se nota cada vez que arrancas el cliente, cambias de cuenta o haces “Sincronizar todo”.

Las cuatro propiedades concretas

1. Una petición, muchas operaciones

JMAP es HTTP+JSON. Mandas un único POST con un array de “method calls”. El servidor las procesa en orden y referenciando los resultados anteriores:

{
  "methodCalls": [
    ["Mailbox/get",  {...},                         "a"],
    ["Email/query",  {"filter":{"inMailboxes":["#a/list/0/id"]}},
                                                    "b"],
    ["Email/get",    {"#ids":{"resultOf":"b", "name":"Email/query", "path":"/ids"}},
                                                    "c"]
  ]
}

Ese #ids resuelve “los ids que devolvió la llamada b”. El servidor encadena solo. Un viaje, todo respondido.

En IMAP cada FETCH/SELECT es un viaje independiente. Para hacer lo mismo el cliente tiene que esperar la respuesta de uno para construir el siguiente.

2. Sincronización por estado, no por escaneo

Cada cuenta tiene un state (un string opaco). Cuando quieres comprobar si hay cambios, le mandas tu último state y el servidor te devuelve:

• “el state actual es X, no ha cambiado nada” — fin, una sola pregunta.
• “el state actual es Y, estos son los IDs nuevos / modificados / borrados” — recibes solo el delta.

En IMAP el cliente repite STATUS por carpeta o tira de extensiones opcionales (CONDSTORE/QRESYNC) que los servidores no siempre soportan. Con JMAP el delta-sync es obligatorio del protocolo, no una extensión.

3. IDs inmutables

Cuando JMAP te da un mensaje, su id es estable para siempre. Mueves el mensaje a otra carpeta, lo renombras la carpeta entera, le pones flags — el id no cambia.

En IMAP el identificador único es el UID, que es por carpeta. Si mueves un mensaje a Sent, deja de existir ese UID y aparece otro nuevo en Sent. Los clientes IMAP tienen que reconciliar “¿es el mismo correo que tenía antes?” mirando Message-ID del header, comparando tamaños, etc. Es frágil y caro.

Con JMAP esto desaparece. Los IDs no mienten.

4. Adjuntos por separado, no embebidos en cada operación

Mandas un email de 50 MB a tres destinatarios → en IMAP el cliente sube el MIME completo tres veces (una por carpeta destino: Sent, copia en otro folder, etc.). JMAP sube el adjunto una sola vez (a /jmap/upload, te devuelve un blobId) y luego se referencia por ese blobId en cada mensaje. Ese blob se deduplica también lado servidor.

Resultado: subir un PDF gordo desde el móvil deja de ser un drama.

Lo que esto significa para tu día a día

Y el bonus: contactos y calendario en el mismo protocolo

JMAP no es solo email. La especificación cubre también:

• JMAP for Contacts (RFC 9610, 2024) — sustituye a CardDAV
• JMAP for Calendars (RFC en draft) — sustituye a CalDAV

Hoy en jmail.com.es los tres están operativos a nivel protocolo: si tu cliente lo soporta, hablas un único endpoint para todo. Webmail, contactos, calendario, archivos personales — una sola sesión, un solo state.

Compatibilidad: pero quiero usar mi Thunderbird de siempre

Sigue funcionando. IMAP no desaparece en jmail.com.es — está expuesto en mail.jmail.com.es:993 (TLS) y :143 (STARTTLS), y cualquier cliente IMAP estándar de los últimos 20 años conecta sin problema.

La diferencia es que con IMAP te pierdes lo bueno:

• Sondeo en vez de push (batería + retraso en avisos)
• Sincronización completa cada vez que arrancas
• Sin delta nativo

Si vas a usar el correo mucho, vale la pena cambiar a un cliente JMAP. Mira la página de clientes recomendados — hay opciones para escritorio y móvil.

Detrás de las bambalinas

jmail.com.es corre sobre Stalwart Mail Server, uno de los pocos servidores en producción con JMAP completo a día de hoy. El catálogo de servidores JMAP “de verdad” en 2026 es corto:

La escasez de servidores y clientes JMAP es la razón de que el protocolo no se haya popularizado masivamente todavía. Pero está pasando: lo nuevo se construye encima de JMAP, lo legacy se queda en IMAP. Apostamos por estar en el lado nuevo.

Referencias técnicas

• RFC 8620 — JMAP core protocol
• RFC 8621 — JMAP for Mail
• RFC 9610 — JMAP for Contacts
• Por qué JMAP es más rápido — el blog de Mailtemi que cubre esto desde el lado cliente
• jmap.io — sitio oficial del protocolo