Resumen

  • RFC 3516 permitía que un servidor IMAP eliminara el Content-Transfer-Encoding de una sección MIME y entregara sus octetos descodificados mediante BINARY, incluso con NUL dentro de literal8. Esa salida no era la serialización original del mensaje.
  • El tamaño y los desplazamientos se medían sobre la vista descodificada. El almacenamiento, FETCH BODY, los finales CRLF, las cabeceras codificadas y las operaciones criptográficas conservaban fronteras propias.

Base64 permitió que datos arbitrarios atravesaran sistemas de correo incapaces de transportar cualquier octeto. Al recuperar un mensaje, sin embargo, un cliente podía descargar esa representación ampliada para deshacerla inmediatamente. RFC 3516 señaló que el coste era visible en enlaces de radio lentos y contenidos multimedia continuos.

La solución de abril de 2003 trasladó la descodificación al servidor. Si CAPABILITY anunciaba BINARY, el cliente podía pedir FETCH BINARY; el servidor quitaba la codificación de transferencia de la sección indicada y devolvía el resultado. La respuesta era más eficiente. No era una copia de los bytes con los que el mensaje había llegado al buzón.

Cada sección de cuerpo en IMAP tiene un Content-Transfer-Encoding, explícito o implícitamente 7bit. En el modelo MIME, el CTE nombra una operación de descodificación y también el dominio de los datos recuperados. Base64 y quoted-printable cambian la representación. Otros CTE pueden usar una transformación identidad y aun así producir datos que el literal del IMAP original no puede transportar, por ejemplo debido a un NUL.

Por eso el RFC separó dos decisiones. Primero se ejecuta la descodificación asociada al CTE. Después se determina el dominio de los octetos resultantes. Obtener bytes no decide automáticamente qué elemento del protocolo puede contenerlos.

literal8 amplió ese elemento. Un tilde y una longitud introducen una secuencia de octetos sin la restricción anterior, incluido NUL. Si los datos sólo necesitan el dominio de ocho bits y no contienen cero, el servidor debería responder con una cadena ordinaria. Así el cliente conoce la propiedad sin inspeccionar todo el flujo.

La longitud del literal es una afirmación exacta sobre esa respuesta, no una confesión sobre el disco. No revela si el servidor guarda el contenido sin codificar, si acaba de reconstruirlo desde base64, si adaptó finales de línea o si mantiene otra forma interna compatible.

BINARY.PEEK añadió una distinción de estado. Solicita la misma vista sin activar implícitamente la marca \\Seen. Que el mensaje permanezca no leído no convierte la respuesta en un original: el estado del buzón y la procedencia de los octetos son pruebas diferentes.

BINARY.SIZE daba la longitud tras retirar el CTE, es decir, lo que debía medir el resultado de FETCH BINARY. No expresaba el tamaño codificado, el espacio físico del buzón ni la longitud total del mensaje. El documento avisó de que la consulta podía ser cara cuando había que descodificar sólo para contar.

Los rangos parciales tenían el sistema de coordenadas de la sección descodificada. Un desplazamiento dentro del texto base64 o de FETCH BODY no apunta necesariamente al mismo contenido. Reanudar una descarga BINARY con un contador de BODY puede devolver una porción bien formada que empieza en un lugar equivocado.

Ante un CTE desconocido, el servidor no podía improvisar. BINARY y BINARY.SIZE debían fallar con NO [UNKNOWN-CTE]. El código era una prueba de incapacidad para aplicar esa transformación, no una sentencia automática de corrupción del mensaje.

RFC 4466 modificó después el marco de códigos de respuesta, mientras RFC 9051 incorporó el mecanismo binario a IMAP4rev2. Una implementación actual debe interpretar esas capas históricas. Ninguna actualización igualó la forma codificada, la sección descodificada y la representación guardada.

Las cabeceras imponían otro límite. Los encoded-words de RFC 2047 permiten texto no ASCII en ciertos campos, pero no son el CTE del cuerpo. RFC 3516 prohibió convertirlos como efecto de BINARY FETCH o APPEND. La orden de descodificar una sección no se extendía a todo texto con apariencia codificada.

Los cuerpos textuales tenían una transformación controlada adicional. El servidor debía transmitir secciones orientadas a líneas con terminadores CRLF de IMAP, aunque usara otra forma internamente. La regla garantizaba interoperabilidad, pero impedía usar la respuesta como prueba forense de los bytes locales de fin de línea.

La separación respecto del almacenamiento era explícita. Un servidor podía guardar contenido binario sin codificación. Aun así, BODYSTRUCTURE debía describirlo como si empleara un CTE admitido por IMAP base, y FETCH BODY debía producir exactamente esa vista. La interfaz publicaba un contrato coherente, no una lectura directa de memoria.

APPEND recorría la transformación en sentido inverso. El cliente podía enviar un literal8 con NUL. Un buzón sin soporte de almacenamiento binario tenía que rechazarlo con UNKNOWN-CTE. Un servidor capaz podía cambiar el CTE, siempre que la operación no perdiera datos de la carga útil.

La equivalencia de carga útil no implica identidad de mensaje. Base64, quoted-printable y una forma directa pueden contener los mismos datos con octetos distintos. El nombre del CTE, el plegado de cabeceras y los finales de línea forman parte de la serialización. Una transformación sin pérdida puede romper una firma o un resumen calculado sobre esa serialización.

El propio RFC advirtió que cambiar gratuitamente la codificación inutilizaría la mayoría de las operaciones criptográficas efectuadas sobre el mensaje. No hay contradicción: recuperar el contenido y conservar los bytes cubiertos por una prueba son compromisos distintos. «Sin pérdida» no documenta cuál fue la entrada del verificador.

Tampoco debía el cliente abandonar su descodificador MIME. BINARY era una optimización para situaciones concretas, no un formato de almacenamiento universal ni una garantía para todos los CTE. El cliente debía poder volver al camino ordinario y descodificar por sí mismo.

La distinción de Heng Lu entre realidad simbólica y operativa organiza el rastro. BINARY en CAPABILITY declara una capacidad. BINARY.SIZE promete la longitud de una vista. El literal contado es una observación en una conexión. Los bytes almacenados, el mensaje RFC 5322, la carga MIME, el resultado visual y la entrada criptográfica viven en capas relacionadas pero no sustituibles.

Un recibo útil conserva identificador y contexto, BODYSTRUCTURE, sección, CTE, comando, marca \\Seen, respuesta, dominio, longitud, desplazamiento y hash de los bytes entregados. Si importa la identidad del mensaje, guarda aparte una recuperación en bruto y su hash. Si importa una firma, registra la canonicalización y la secuencia exacta que recibió el verificador.

Entonces dejan de parecer incompatibles dos observaciones verdaderas: el servidor entregó correctamente el cuerpo descodificado y el archivo no coincide en hash con el mensaje serializado. RFC 3516 describió el paso entre ambos, no prometió borrarlo.

Su logro fue práctico: evitar que cada lectura IMAP pagara la sobrecarga de una codificación pensada para otro transporte. Su enseñanza fue probatoria: el servidor descodificó el cuerpo y el cliente recibió octetos útiles; el mensaje original todavía necesitaba una recuperación y una prueba distintas.

Fuentes