Resumen

  • En RFC 10022, el tamaño solicitado es el máximo de mensajes que puede contener cada intervalo, no una promesa de tamaño exacto. Los UID de los extremos incluso pueden no corresponder a mensajes almacenados.
  • La respuesta OK certifica que terminó el cálculo de rangos. Para cerrar un trabajo hay que unir buzón y UIDVALIDITY, época del plan, eventos de cambio, mensajes realmente abordados y resultados terminales, sin perder los desaparecidos, recién llegados o pendientes.

El error empezó después del OK

La orden no falló. El servidor anunció la capacidad. El cliente seleccionó el buzón, envió UIDBATCHES 2000, recibió cuatro intervalos descendentes y cerró el intercambio con OK. Todos los elementos de protocolo parecían impecables.

El error llegó una pantalla más tarde. El sistema de control convirtió cada intervalo en una tarea y llamó “mensajes completados” a la suma de sus tamaños previstos. Cuando un mensaje desapareció antes del tercer FETCH y otros llegaron por encima del máximo anterior, el porcentaje siguió en cien. El denominador pertenecía al mapa; el numerador pretendía describir efectos.

RFC 10022 evita precisamente la necesidad de tratar un buzón como un vector inmóvil. El servidor puede calcular fronteras eficientes sobre el espacio de UID. El cliente puede aplicar esas fronteras a diferentes órdenes futuras. Esto resulta especialmente útil en el modo UIDONLY, donde los números de secuencia ya no están disponibles.

Pero el mapa no contiene recibos. No indica qué cuerpos se leyeron, qué flags se cambiaron, qué mensajes se copiaron, cuáles se movieron o cuáles ya no estaban. La extensión ofrece una unidad de planificación. La organización decide si conserva las pruebas necesarias para convertirla en un resultado.

El contrato es desigual a propósito

Si el cliente pide 2.000 mensajes por lote, el servidor no puede devolver un intervalo que contenga más de 2.000 mensajes existentes. Ese lado del contrato es absoluto.

El lado inferior es flexible. El servidor debería aproximarse al tamaño pedido y procurar al menos el 90 % cuando sea posible. Puede entregar menos si así obtiene una implementación sustancialmente más sencilla o eficiente, o si el buzón cambia mientras calcula, sobre todo por expulsiones.

Por eso dos rangos de una misma respuesta pueden representar 1.990 y 1.977 mensajes, aunque ambos nazcan de una petición de 2.000. El cliente debe estar preparado. La diferencia no demuestra incumplimiento; tampoco autoriza a registrar 2.000 como cifra observada.

Esta asimetría convierte el parámetro en una herramienta de capacidad. El cliente sabe cuánto trabajo no superará cada unidad. El servidor conserva libertad interna para dibujar una frontera válida. El resultado sirve para memoria, concurrencia y reparto, no para contabilidad exacta.

La cifra mínima de 500 introduce otra frontera. Por debajo, el servidor responde TOOFEW. Pedir lotes diminutos no solo puede sobrecargar el cálculo; también permitiría reconstruir posiciones finas que UIDONLY elimina deliberadamente. El diseño protege una separación arquitectónica: UIDBATCHES agrupa, no reabre los números de secuencia bajo otro nombre.

Los extremos son coordenadas, no objetos

En muchos sistemas, un identificador situado en un informe se interpreta como prueba de existencia. Aquí esa intuición falla. RFC 10022 permite que el primer o último UID de un intervalo no exista en el servidor.

Los UID crecen dentro de una generación de buzón, pero las eliminaciones dejan huecos. Además, un servidor puede escoger extremos convenientes alrededor de una población aproximada. Así, el intervalo 163886:99703 puede ser válido aunque ninguno de esos dos UID corresponda a un mensaje presente.

La orden posterior seleccionará los mensajes existentes cuyo UID caiga dentro del espacio. No creará los extremos ni rellenará los huecos. En el lote más antiguo, terminar en UID 1 puede indicar con claridad que no hay una banda anterior, aunque el mensaje real más antiguo tenga UID 302.

La base de datos operativa debe conservar esta semántica. Un par de límites no es una pareja de mensajes. La anchura numérica no es una cardinalidad. Una visualización que dibuja los extremos como objetos encontrados fabrica una capa de realidad falsa.

La identidad de IMAP tampoco cambia: nombre de buzón, UIDVALIDITY y UID siguen delimitando la referencia persistente. La época de UIDBATCHES añade el contexto del plan. No autentica contenido ni sobrevive al renacimiento del buzón.

El intervalo conserva su forma mientras cambia su población

Los mensajes nuevos reciben UID superiores. No se insertan en medio de los intervalos ya devueltos. Esa monotonicidad permite reutilizar el mapa sin que las bandas antiguas crezcan desde dentro.

Las bandas sí pueden vaciarse. Una expulsión elimina miembros. Un intervalo que cubría una población cercana a 2.000 puede conducir después a 1.950 mensajes. El selector sigue bien formado; el inventario implícito ya no existe.

Los recién llegados forman una franja por encima del antiguo máximo. Para un proceso con corte temporal, pertenecen a la siguiente época. Para una sincronización continua, pueden activar un lote nuevo. La extensión no elige el objetivo empresarial y no debería hacerlo.

Tampoco permite recalcular a voluntad. El cliente no debe repetir UIDBATCHES salvo que seleccione otro buzón, se haya expulsado más de medio lote o haya llegado más de medio lote nuevo. El servidor debería vigilar el abuso y puede responder LIMIT.

Hay que distinguir la vigencia técnica de la suficiencia del negocio. Un mapa puede seguir siendo técnicamente utilizable y no cubrir la población que una migración prometió. El umbral de medio lote limita el coste de cálculo; no decide una obligación de archivo o conservación.

Vacío no significa siempre buzón vacío

El servidor debe enviar una respuesta UIDBATCHES incluso cuando no contiene ningún rango, e incluir el correlador con la etiqueta de la orden. Después puede responder OK.

Un buzón vacío produce ese patrón. También una ventana inexistente. Si solo hay cuatro lotes y el cliente solicita los lotes 6:8, la respuesta válida está vacía. No dice “cero mensajes en todo el buzón”; dice “cero intervalos dentro de la ventana solicitada”.

La interpretación depende del sobre de evidencia: cuenta, buzón seleccionado, UIDVALIDITY, etiqueta, tamaño, ventana e instante. Archivar solo el texto OK borra la pregunta a la que respondió.

Los rechazos también contienen decisiones. TOOFEW exige aumentar la granularidad. TOOMANY pide acotar la ventana o abandonar la solicitud global. LIMIT exige esperar o corregir la frecuencia. Un intervalo de índices escrito 4:1 puede recibir CLIENTBUG, porque los índices solicitados se expresan de menor a mayor aunque los UID devueltos vayan de mayor a menor.

La taxonomía no es decoración. Es el mecanismo por el cual equipos independientes pueden corregir la causa sin convertir cada rechazo en una investigación propietaria.

La ventana de cien mil protege ambos lados

Una solicitud con rango de lotes no puede abarcar más de 100.000 mensajes. El servidor debe soportar al menos esa escala, pero puede rechazar con TOOMANY una respuesta total para un buzón extremo.

La regla limita dos pretensiones. El servidor no puede anunciar una capacidad puramente simbólica incapaz de atender el mínimo común. El cliente tampoco puede exigir un cálculo global sin límite solo porque existe una palabra estándar.

El recurso para cajas mayores son ventanas sucesivas. Como el buzón puede cambiar entre ellas, RFC 10022 sugiere solapar el lote fronterizo: 1:100, después 100:200. Si la representación del lote 100 cambia, el operador obtiene una señal de inconsistencia.

El solapamiento no decide cuál de las dos versiones es verdadera para el objetivo del trabajo. Tampoco impide una expulsión posterior. Compra observabilidad, no inmovilidad. Su utilidad desaparece si el cliente elimina el duplicado antes de comparar su población y su época.

Un diseño maduro trata esa repetición como recibo de continuidad. Conserva las dos respuestas, la marca temporal, los cambios observados y la resolución adoptada.

Capacidad no significa composición automática

UIDBATCHES convive con extensiones que responden preguntas distintas.

UIDONLY obliga a trabajar con UID y elimina los números de secuencia de órdenes y respuestas. VANISHED reemplaza señales basadas en posición. UIDBATCHES da zonas gruesas, pero no restaura la posición mensaje por mensaje.

PARTIAL devuelve páginas de un SEARCH real o limita un UID FETCH real. Su resultado representa una fracción de una consulta ejecutada. UIDBATCHES prepara límites que todavía deben aplicarse. Confundirlos adelanta la prueba de ejecución.

SEARCHRES permite guardar en $ el resultado de una búsqueda. RFC 10022 prohíbe que UIDBATCHES ocupe ese espacio porque no es SEARCH. Un mapa aproximado no debe convertirse implícitamente en conjunto de mensajes.

QRESYNC y CONDSTORE ayudan a observar cambios y mensajes VANISHED. Permiten detectar que la realidad se apartó del plan. No reescriben el instante original.

MESSAGELIMIT restringe el número de mensajes que una orden posterior puede procesar. Si el servidor anuncia 1.000, el cliente debería pedir lotes de como máximo 1.000 aunque UIDBATCHES admita un valor mayor. La validez de una frontera no anula el límite del verbo que debe producir el efecto.

La respuesta CAPABILITY es una lista de contratos, no una autorización general. La unidad ejecutable aparece al intersectar todos ellos con el estado actual del buzón.

Siete conjuntos cuentan mejor que un porcentaje

Para cerrar una operación conviene mantener poblaciones separadas:

Conjunto Pregunta
P ¿Qué mensajes pertenecen a la política y generación del trabajo?
B ¿Qué mensajes existentes eran alcanzables por los intervalos al planificar?
A ¿Qué mensajes recibieron realmente una orden posterior?
C ¿Qué mensajes obtuvieron un resultado terminal aceptado?
X ¿Qué mensajes previstos aparecieron como expulsados o desaparecidos?
N ¿Qué mensajes nuevos superaron el máximo del plan?
U ¿Qué resultados permanecen desconocidos o reintentables?

Un archivo con corte puede exigir P = C ∪ X, U vacío y una razón individual para X; N pasa al siguiente corte. Una migración continua puede incorporar N antes de cerrar. Un índice puede aceptar X como final sin tratarlo como defecto.

No basta con igualar números. Una expulsión y una llegada pueden compensarse y mantener el total, mientras cambia la identidad. La clave de conciliación incluye buzón, UIDVALIDITY, UID y época.

La especificación común sigue siendo mínima: identifica, limita y permite verificar transacciones. Las decisiones posteriores permanecen cerca del operador. Eso evita que la coordinación técnica se convierta en una autoridad ficticia sobre el objetivo del negocio.

Lo que las fuentes no pueden afirmar

El estándar no demuestra adopción por un servicio concreto ni conformidad de un producto. La meta del 90 % no es una medición de producción. Los ejemplos de huecos, expulsiones y límites son escenarios operativos permitidos, no incidentes atribuidos.

IANA registra los nombres y códigos de respuesta. No observa servidores. CAPABILITY declara una posibilidad; UIDBATCHES devuelve estado de planificación; la orden posterior produce —o no— el efecto. Mantener estas capas separadas evita que una etiqueta normativa se convierta en una afirmación sobre la realidad.

La primacía del código en funcionamiento, en el sentido defendido por Heng Lu, no elimina las reglas. Hace que una síntesis deba responder ante la ejecución. Si el tablero dice “completo” y los recibos dejan U, el tablero pierde, aunque el plan sea perfectamente conforme.

Fuentes