Resumen

  • El literal original era una cadena delimitada por una cuenta dentro de una orden IMAP. Tras {n}, el cliente debía recibir una continuación + antes de enviar los octetos y el resto de la orden.
  • LITERAL+ permitió {n+} y suprimió ese viaje de red, pero trasladó al servidor el problema de drenar datos ya autorizados o cerrar la conexión cuando el literal resultaba inaceptable.
  • LITERAL- conservó el mismo marcador y limitó a 4096 octetos el envío sin permiso puntual. APPENDLIMIT comunicó aparte una política de subida global o por buzón; IMAP4rev2 incorporó la forma restringida.

El contador abría un paréntesis

Un literal no termina al encontrar CRLF. Puede contener retornos de carro y saltos de línea. Su frontera es aritmética: exactamente los octetos anunciados. Después del último, la gramática de la misma orden continúa. Puede venir un espacio, otro argumento u otro literal.

Por eso A001 LOGIN {11} era una línea física incompleta. RFC 2060 obligaba al cliente a esperar una solicitud de continuación antes de enviar los once octetos. Si el servidor encontraba un error en el prefijo, podía contestar BAD y evitar que más datos de esa orden contaminaran el flujo. RFC 3501 mantuvo el mecanismo.

La continuación no decía que LOGIN o APPEND hubieran triunfado. Sólo decía que el servidor estaba listo para la siguiente porción sintáctica. Hasta {0} debía esperar: la decisión existía aunque no hubiera carga que transportar.

TCP ofrecía otra clase de control. Su ventana regulaba bytes del flujo sin saber qué era un buzón. El + de IMAP era un veto de aplicación, colocado después de que el servidor conociera una parte útil de la orden y antes de que el cliente comprometiera la cadena.

Dos literales, dos esperas menos

RFC 2088, de enero de 1997, definió LITERAL+. Un servidor que lo anunciaba autorizaba la forma {n+}. El cliente enviaba la carga de inmediato y el servidor no generaba continuación.

La cuenta seguía mandando. El receptor debía reconocer el patrón al final de la línea, consumir el número exacto de octetos y reanudar el análisis de la orden. La mejora no separó la carga del comando; retiró una conversación dentro de él.

La negociación preservaba interoperabilidad y decisión local. Sin capability, el cliente seguía usando {n}. Con ella, el servidor delegaba por adelantado el permiso que antes concedía literal por literal. En una red con gran retardo, esa delegación podía evitar varios viajes en una sola orden.

El RFC de 1997 no conocía problemas de seguridad. La observación histórica importante no es desacreditar esa frase, sino ver qué cambió con el tiempo: se comprendió mejor el coste de rechazar después de delegar.

El rechazo llegaba después de los datos

RFC 7888 describe en 2016 el caso incómodo. Un cliente puede anunciar un literal enorme con {n+} y empezar a transmitir. El servidor descubre que no lo acepta. Para mantener sincronizado el flujo, lee y descarta n octetos antes de rechazar. O envía BYE y corta la conexión.

La primera opción gasta ancho de banda, memoria o CPU en una orden ya condenada. La segunda provoca reconexión y puede activar reintentos poco inteligentes. Mandar BAD o NO pronto comunica el veredicto, pero no revoca retroactivamente los bytes que la capability permitió.

APPEND convierte la abstracción en una factura. Puede incluir un mensaje completo y adjuntos; los servidores suelen necesitar límites contra agotamiento de recursos. LITERAL+ mejoró la latencia del emisor a costa de reducir el margen de rechazo barato del receptor.

El mismo más, dos contratos

RFC 7888 sustituyó RFC 2088 y normalizó LITERAL+ y LITERAL-. El primero conserva literales no sincronizados de cualquier tamaño dentro de la extensión. El segundo sólo los permite hasta 4096 octetos. Los mayores deben volver a {n} y esperar.

La forma en el cable sigue siendo {n+}. LITERAL- no introduce un signo menos en cada literal. La capability anunciada es la que limita el significado del más, y un servidor no puede anunciar ambas a la vez.

4096 no define cuánto correo cabe en un buzón. Define cuánto puede llegar sin una invitación específica bajo LITERAL-. Un APPEND más pequeño puede fracasar; uno mucho mayor puede ser válido después de sincronizar. Tampoco bloquea todo abuso: muchos literales pequeños pueden acumular trabajo.

La solución es sobria. Mantiene la optimización para cadenas pequeñas, conserva la antigua ruta para todo tamaño y recupera un punto de consentimiento antes de cargas grandes. No pretende imponer la política exacta de cada servidor.

APPENDLIMIT publicó la política local

RFC 7889 abordó en el mismo mes otra pregunta. APPENDLIMIT permite anunciar el tamaño máximo aceptado para una subida. Puede ser un valor global en CAPABILITY o un dato por buzón obtenido mediante STATUS o LIST-STATUS.

El cliente evita así enviar un mensaje que excede un límite conocido. Si el límite es desconocido, el RFC aconseja no usar literales no sincronizados para APPEND. Pero estar por debajo no garantiza aceptación: ACL, cuota y otras condiciones conservan su autoridad.

El umbral sintáctico y la política de buzón no deben fusionarse. LITERAL- fija una regla común para el permiso anticipado. APPENDLIMIT expone una decisión operativa variable. Separarlos permite cambiar cuotas sin reescribir la gramática y mantener la gramática sin fingir que conoce cada almacenamiento.

La espera sobrevivió en IMAP4rev2

RFC 9051 incorporó LITERAL- en 2021. IMAP4rev2 trata la forma sincronizada, la no sincronizada y la cadena entre comillas como formas ordinarias. Salvo extensión, más de 4096 octetos exige continuación.

El protocolo moderno no consideró el viaje un residuo. Lo conservó como mecanismo de admisión para cargas grandes. El registro de IANA mantiene LITERAL+, LITERAL- y APPENDLIMIT, pero no mide su despliegue.

La historia deja una regla más amplia. Reducir latencia adelantando trabajo también adelanta autoridad. Si el receptor no conserva un punto realista para decir no, la mejora de una parte se convierte en coste involuntario de la otra.

Fuentes y límites

Las fuentes no prueban adopción actual, rendimiento real ni frecuencia de ataques. La continuación no acepta la orden final, 4096 no es cuota y APPENDLIMIT no promete que una subida menor vaya a triunfar.