Resumen

  • MESSAGELIMIT limita los mensajes procesados por una sola orden, no el tamaño del buzón; en SEARCH cuenta los mensajes examinados, no únicamente las coincidencias devueltas.
  • FETCH, SEARCH, STORE, MOVE y UID EXPUNGE pueden completar una franja real y responder OK aunque quede trabajo anterior, mientras COPY y MULTIAPPEND rechazan el conjunto excesivo sin efecto parcial.
  • La cobertura completa exige conservar intención, generación del buzón, UID más bajo procesado, efectos observados y todas las continuaciones; una respuesta válida no basta.

Imaginemos una consulta que busca mensajes no eliminados dentro de un intervalo de tres mil UID. El servidor examina los mil más altos, encuentra 214 coincidencias y responde con esas 214. Nada en ese conjunto es inventado. El error comienza cuando un sistema superior escribe «214 mensajes no eliminados» sin conservar que dos mil candidatos quedaron fuera del examen.

RFC 9738 convierte esa omisión potencial en un dato de protocolo. La respuesta MESSAGELIMIT N LastUID dice cuántos mensajes como máximo fueron procesados y señala el UID más bajo alcanzado. La invocación puede acabar en OK. El estado de la invocación y la cobertura de la intención original son dos preguntas distintas.

El número limita trabajo, no contenido

Un servidor anuncia MESSAGELIMIT=<límite> en CAPABILITY cuando aplica la cota a SEARCH, FETCH, STORE, COPY, MOVE, sus variantes UID, APPEND y UID EXPUNGE. Si solo limita las familias que guardan —COPY y APPEND— puede anunciar SAVELIMIT. El valor recomendado no debe ser inferior a mil.

La definición evita varias interpretaciones cómodas. N no es el número de mensajes del buzón. Tampoco es una cuota de almacenamiento, un plazo de retención o el máximo tamaño de un mensaje. Es la cantidad que una orden puede procesar en una pasada.

En SEARCH, el detalle es decisivo: se cuentan los mensajes buscados, no los que satisfacen el criterio. El servidor puede devolver pocos UID y, aun así, haber consumido toda la ventana de mil. El cliente debe continuar por debajo de LastUID si necesita un resultado exhaustivo.

Siempre que devuelve ese código, el servidor está obligado a avanzar del UID más alto al más bajo. Por ello, LastUID funciona como marca inferior de la franja terminada. No enumera la franja pendiente. Entre una petición y otra pueden llegar mensajes nuevos, desaparecer otros o cambiar por completo la generación del buzón. La marca solo conserva su sentido junto a la carpeta seleccionada y su UIDVALIDITY.

Un OK puede ser un recibo parcial correcto

La respuesta etiquetada confirma el resultado de esa orden concreta. Un FETCH puede entregar datos de mil mensajes y cerrar con OK [MESSAGELIMIT …]. Un STORE puede haber cambiado realmente las banderas de esos mil. Un MOVE puede haberlos copiado al destino y expulsado del origen. UID EXPUNGE puede haber borrado una franja de mensajes que ya tenían \Deleted.

Llamar a esos casos «fallo» también sería falso. El trabajo parcial existe y debe entrar en la reconciliación. Pero llamarlos «terminados» oculta la parte no ejecutada.

Cada familia exige una continuación distinta. UID STORE debe reducir el intervalo para excluir el UID inferior ya procesado. UID MOVE puede repetir el mismo conjunto porque los UID movidos han desaparecido de la carpeta fuente. MOVE basado en números de secuencia debe recalcular el conjunto tras cada expulsión: las posiciones cambiaron. UID EXPUNGE puede repetir su conjunto UID hasta que deje de aparecer el código o llegue un NO o BAD.

Esa variedad impide implementar la recuperación como un bucle ciego. El registro debe conservar qué mensajes se observaron, qué efecto se produjo, cuál fue la respuesta completa y por qué la siguiente orden no duplica ni salta trabajo.

También debe leer respuestas no etiquetadas. Si el servidor necesita comunicar EXPUNGEISSUED, ese código ocupa el OK final y MESSAGELIMIT se entrega dentro de un NO no etiquetado. Un parser que solo mira la última línea perderá precisamente la señal que protege el denominador.

La atomicidad decide si hubo efecto

COPY y UID COPY conservan una promesa distinta. Cuando el conjunto supera el límite, la orden falla con NO [MESSAGELIMIT …] y no se copia ningún mensaje. MULTIAPPEND es igualmente atómico: una lista excesiva no añade una primera parte.

MOVE no necesita ser atómico y puede dejar una franja ya trasladada. STORE y UID EXPUNGE también pueden dejar cambios. La misma cifra N produce, por tanto, dos tipos de evidencia: rechazo total sin efecto o éxito parcial con efecto. La familia de la orden es parte del recibo.

Hay además operaciones que no admiten esta cota. RFC 9738 prohíbe imponerla a EXPUNGE, CLOSE y STATUS UNSEEN. Eso conserva su alcance completo dentro de IMAP. No demuestra que un sistema de almacenamiento haya persistido cada cambio, que un cliente posterior se haya sincronizado o que un usuario haya visto el resultado.

PARTIAL, definido en RFC 9394, muestra otra diferencia. Si el cliente solicita explícitamente una página PARTIAL de más de N elementos, el servidor rechaza la petición y no hace trabajo. Sin PARTIAL, un FETCH sobre la misma población puede devolver una franja implícita. Una ventana solicitada y un recorte impuesto tienen comportamientos distintos ante la misma capacidad.

El símbolo $ puede heredar una búsqueda incompleta

SEARCHRES permite guardar el resultado de SEARCH en $. RFC 9738 exige que, si la búsqueda llega al límite, el conjunto guardado también quede truncado. La variable representa exactamente las coincidencias encontradas en la franja examinada.

El peligro aparece más tarde. Un COPY o STORE sobre $ puede concluir sin MESSAGELIMIT porque el conjunto guardado ya es pequeño. El transcript parece limpio, pero la población de entrada arrastra la omisión de la búsqueda anterior. El éxito posterior no corrige el denominador perdido.

Por eso, un resultado guardado necesita linaje operativo: buzón, UIDVALIDITY, criterios, intervalo original, límite, UID inferior, hora y estado de cierre. Si el sistema reduce esa información a «search-id=42», convierte una abreviatura útil en una afirmación falsa de exhaustividad.

Los criterios UIDAFTER y UIDBEFORE facilitan expresar el siguiente tramo. No bloquean el buzón durante la serie. Tampoco garantizan que los extremos existan ni que el conjunto sea idéntico entre dos pasadas. Sirven para formular consultas; no crean una transacción.

La adopción admite una zona de convivencia

RFC 9738 reconoce que activar una cota estricta de un día para otro dañaría clientes existentes. En buzones mayores que N, un cliente que no comprende la extensión podría ver solo la parte reciente, calcular recuentos erróneos o fracasar al copiar. El protocolo sería formalmente coherente, pero la experiencia sería una ruptura.

La guía propone anunciar primero el límite sin aplicarlo. Los clientes compatibles empiezan a enviar órdenes más pequeñas y reducen carga; los antiguos siguen funcionando. En una fase posterior, el servidor puede anunciar mil como límite blando y aplicar una cota dura oculta de diez mil. Los intentos que superan la cifra anunciada permiten medir qué clientes todavía no se han adaptado.

Esa transición separa declaración y ejecución. Ver MESSAGELIMIT=1000 no prueba que el servidor corte hoy exactamente en mil. Prueba que el cliente informado debe diseñar sus órdenes dentro de esa cifra. El estado real de adopción requiere observar órdenes, respuestas y umbral aplicado.

No hay contradicción si ambas cifras se registran. La incompatibilidad aparece cuando un cuadro de mando las mezcla y presenta el valor anunciado como si fuera una medición del comportamiento. Una regla publicada puede guiar la migración antes de convertirse en restricción estricta; la telemetría decide cuándo endurecerla sin abandonar a los clientes que aún sostienen servicio real.

Cerrar el conjunto y no solo la conversación

Una automatización fiable empieza con una población intencional: qué mensajes pretendía leer, cambiar, mover o borrar. Después registra cada invocación con buzón, UIDVALIDITY, orden, conjunto solicitado, clase atómica, capacidad observada, datos devueltos, efectos, respuestas no etiquetadas, estado final, límite y UID inferior.

El cierre compara cuatro grupos: mensajes previstos al inicio; mensajes examinados o modificados; mensajes que desaparecieron durante el trabajo; mensajes que llegaron fuera del alcance inicial. La diferencia no explicada permanece como incertidumbre. Una última orden sin límite cierra esa cadena, pero no convierte el buzón dinámico en una fotografía retroactiva.

UIDBATCHES, PARTIAL, MESSAGELIMIT y SEARCHRES deben conservar funciones separadas. El primero ayuda a planificar intervalos. El segundo pide una página concreta. El tercero informa una cota encontrada durante la ejecución. El cuarto conserva una población. Llamar «batch» a todo ahorra vocabulario a costa de perder control.

La enseñanza de RFC 9738 es más amplia que el correo. Una respuesta exacta solo puede sostener la conclusión que corresponde al trabajo efectivamente realizado. Cuando el denominador está incompleto, la cifra no se vuelve completa porque termine en OK. El trabajo concluye al cerrar el conjunto, no al celebrar la respuesta.

Fuentes