Resumen

  • RFC 10022 permite pedir intervalos descendentes de UID próximos a una cantidad de mensajes. Esos intervalos sirven para preparar operaciones posteriores; no congelan el buzón ni forman un conjunto de búsqueda guardado.
  • Los extremos del intervalo pueden no existir como mensajes, el lote puede contener menos elementos de los solicitados y las expulsiones pueden reducirlo. El recuento tampoco garantiza bytes, tiempo o coste uniforme.
  • Daniel Eggert editó el documento de consenso de IETF. La especificación coordina una partición mínima y conserva separadas la libertad de implementación, la política del cliente y la prueba de servicio.

Supongamos un buzón con cuatro lotes. El cliente pregunta por los lotes 6 a 8. El servidor responde con UIDBATCHES, sin intervalos, y termina con OK. Si la aplicación conserva solo «cero resultados», puede enseñar al usuario que el buzón está vacío. El protocolo no dijo eso. Dijo que la petición válida no encontró esos índices.

Ese ejemplo resume el problema editorial de RFC 10022. Publicado en julio de 2026 como Proposed Standard, IMAP UIDBATCHES Extension fue editado por Daniel Eggert, de Apple Inc. Su función es proporcionar intervalos de UID que dividan los mensajes del buzón seleccionado en grupos cercanos a una cantidad deseada.

El mecanismo facilita el trabajo por partes, sobre todo en modo UIDONLY, donde el cliente no puede apoyarse en números de secuencia. Pero una parte manejable no equivale a una página estable. Para conocer el resultado hay que conservar la petición, el estado del buzón y la operación realizada después.

La respuesta no contiene toda su interpretación

Cada respuesta incluye el tag de la orden que la originó. Ese detalle permite relacionar un mensaje sin intervalos con la petición correcta. El cliente también conoce el rango opcional de índices y el EXISTS recibido al seleccionar el buzón.

Juntos, esos datos distinguen dos vacíos. Un buzón realmente vacío no tiene mensajes. Una ventana inexistente está fuera del conjunto de lotes calculado, aunque el buzón sí tenga contenido. La interfaz no debe convertir ambos estados en una sola insignia verde o gris.

El mismo principio se aplica a los errores. TOOFEW indica que la cantidad solicitada está por debajo del mínimo admitido. TOOMANY puede señalar que el rango pedido abarca demasiado trabajo. LIMIT puede proteger al servidor frente a recálculos excesivos. Guardar solo «falló» elimina la condición necesaria para corregir la orden.

Por eso el recibo comienza antes de la respuesta: servidor, cuenta, buzón seleccionado, UIDVALIDITY, capacidades, tag, tamaño e índices pedidos. El cuerpo aislado nunca fue una unidad probatoria completa.

Los extremos del intervalo no son mensajes prometidos

El servidor devuelve los intervalos desde los UID más altos hacia los más bajos. El lote 1 empieza por la zona más reciente. Sin embargo, RFC 10022 permite que el UID inicial y el final no correspondan a mensajes existentes.

Las eliminaciones dejan huecos. Un intervalo amplio puede cruzar miles de números y contener aproximadamente la cantidad solicitada de mensajes reales. En el último lote, terminar en UID 1 puede servir para señalar que se llegó al fondo aunque el mensaje más antiguo tenga UID 302.

Esta decisión da flexibilidad a la implementación. También impide dos atajos. Restar los extremos no revela el número de mensajes. Y encontrar un UID dentro del intervalo aritmético no demuestra que ese mensaje estuviera presente.

La operación posterior tiene la última palabra. FETCH mostrará qué elementos devolvió el servidor. SEARCH mostrará qué mensajes cumplieron el criterio. STORE mostrará cuáles aceptaron el cambio. UIDBATCHES únicamente preparó el terreno.

RFC 10022 refuerza la separación al decir que UIDBATCHES no es SEARCH ni UID SEARCH. Si existe SEARCHRES, su resultado no debe guardarse en $. Un intervalo de trabajo no puede convertirse por comodidad en un conjunto de búsqueda persistente.

La igualdad tiene una sola dimensión

El cliente solicita un número de mensajes, nunca menos de 500. El servidor no debe devolver más mensajes por intervalo que los pedidos. Debería aproximarse al valor exacto y procurar al menos el 90 % cuando sea posible, aunque puede devolver menos por eficiencia sustancial o porque el buzón cambió durante el cálculo. El último lote suele contener el resto.

La cantidad no define el peso de los mensajes. Quinientos correos de texto y quinientos con adjuntos no consumen el mismo ancho de banda. Una búsqueda indexada y otra que obliga a examinar cuerpos tampoco cuestan igual. El método STORE tiene consecuencias distintas de FETCH.

El objetivo de lotes «iguales» es limitar cuántos mensajes toca una orden. No promete una respuesta del mismo tamaño, una duración fija ni una cuota uniforme de CPU o memoria. La sección operativa de la RFC habla de reducciones probables de trabajo y memoria, no de una garantía cuantificada.

Una política de adaptación necesita observaciones: número real procesado, octetos, duración del servidor, tiempo del cliente, comando, errores y reintentos. Si se pretende limitar la latencia visible, esa latencia debe medirse. Ajustar el lote con un simple recuento confunde el mando con el resultado.

Cada borrado cambia el futuro, no reescribe el pasado

Los mensajes nuevos reciben UID superiores. Por eso no se incorporan a un intervalo ya devuelto. En cambio, una expulsión puede quitar mensajes que estaban dentro, de modo que el lote disminuye.

El cliente puede contar EXPUNGE o VANISHED y observar EXISTS. RFC 10022 considera apropiado recalcular después de seleccionar otro buzón, cuando se ha expulsado más de la mitad de un lote o cuando ha llegado más de media tanda de mensajes nuevos. Fuera de esas condiciones, el cliente no debe repetir UIDBATCHES.

La restricción no es decorativa. Calcular las particiones puede resultar costoso. Un cliente defectuoso que actualiza continuamente puede agotar recursos, por lo que se aconseja al servidor imponer la limitación.

La monitorización necesita saber por qué se recalculó. Debe guardar el contador acumulado, la cantidad del lote y el momento en que se cruzó el umbral. Así puede distinguir un ajuste legítimo de un bucle que trata el comando como si fuera un refresco gratuito.

UIDVALIDITY protege otro límite. Un UID solo tiene significado dentro de un buzón y su generación de validez. Reutilizar una partición bajo otra UIDVALIDITY no produce una página antigua; produce una referencia sin identidad fiable.

Solapar ventanas es una comprobación, no una cura

Los clientes pueden pedir solo ciertos índices. En un buzón grande, quizá recuperen 1:100 y después 101:200. Como el tamaño es aproximado y el buzón cambia, la RFC sugiere solapar la frontera: 1:100, 100:200, 200:300.

Comparar el lote repetido ayuda a detectar una posible incoherencia entre peticiones. El cliente decide qué hacer con ella. Puede repetir, ampliar el solape, detener una exportación sensible o continuar dejando visible la incertidumbre.

El solape tampoco crea un snapshot. Confirma que dos cálculos comparten una referencia que se puede comparar. Si una aplicación elimina el lote repetido antes de conservar la comparación, pierde el instrumento que justificaba el diseño.

Una petición con rango no debe abarcar más de 100.000 mensajes. El servidor debe soportar al menos esa extensión, pero puede rechazar más trabajo. En buzones enormes también puede negarse a devolver todas las particiones de una vez. Con MESSAGELIMIT, el cliente debería respetar el máximo anunciado para una orden.

UIDONLY explica parte de estas defensas. El mínimo de 500 impide usar lotes diminutos para reconstruir posiciones finas similares a números de secuencia. PARTIAL ofrece paginación de SEARCH y FETCH, mientras UIDBATCHES permite decidir intervalos antes de elegir la operación. Parecidos de implementación no borran la diferencia semántica.

El papel de Daniel Eggert tiene límites documentados

En la captura del 1 de septiembre de 2026, el perfil oficial de Daniel Eggert en IETF Datatracker incluía RFC 10022 y RFC 9979. Swift.org lo había identificado en 2022 como miembro del equipo de Apple que trabaja en Mail para iOS y macOS, con un enlace a su cuenta pública de GitHub.

Es un contexto profesional fechado, no una afirmación sobre un producto actual. Ninguna fuente demuestra que un servicio concreto implemente la extensión, que Eggert controle la conducta de un servidor o que sea dueño del consenso. Editar el documento y operar un sistema son responsabilidades distintas.

Su contribución ayuda a mantener esa distinción. La RFC fija el mínimo común para repartir trabajo y deja al servidor libertad de cálculo, al cliente la estrategia y al operador la aceptación. Es una aplicación práctica de la especificación inicial mínima de Heng Lu. La primacía del código en ejecución añade la prueba final: solo las operaciones realizadas y sus efectos muestran si la sincronización terminó.

Un recibo que permita investigar

Registrar servidor, cuenta, buzón, UIDVALIDITY y capacidades. Añadir tag, cantidad, índices, código y todos los intervalos. Conservar EXISTS, EXPUNGE y VANISHED, junto con el motivo autorizado de recálculo y la comparación de solapes.

Después unir cada intervalo con el comando aplicado, los UID reales, ausencias, octetos, tiempos, errores, reintentos y el estado local confirmado. No hace falta publicar credenciales ni contenido de mensajes. Contadores, hashes, identificadores limitados y tiempos bastan para reconstruir una decisión sin exponer la correspondencia.

Así, el lote puede ser eficiente sin fingir que el buzón dejó de moverse.

Fuentes