Resumen

  • RFC 9755 separa lo que anuncia el servidor de lo que habilita un cliente autenticado; ninguno de esos hechos valida por sí solo identidad, almacén, índice y presentación.
  • La aceptación termina cuando un mensaje controlado puede listarse, buscarse, recuperarse, interpretarse y usarse por la persona prevista.

El fallo más revelador ocurre después de un éxito. El sistema deposita un mensaje con cabeceras internacionalizadas y recibe OK. Sin embargo, el destinatario no lo localiza por el remitente, no abre el mensaje adjunto o no lo ve en uno de los clientes admitidos. El APPEND fue verdadero. La conclusión construida sobre él era demasiado grande.

RFC 9755 es una norma de marzo de 2025 que sustituye RFC 6855 para IMAP4rev1; IMAP4rev2 ya incorpora capacidades parecidas. UTF8=ACCEPT anuncia acceso a buzones con mensajes internacionalizados y nombres de buzón UTF-8. UTF8=ONLY incluye esa capacidad y deja atrás la convención UTF-7 modificada.

La sesión debe aceptar de forma explícita

El cliente se autentica y luego envía ENABLE UTF8=ACCEPT. También lo hace ante UTF8=ONLY; no existe ENABLE UTF8=ONLY. RFC 5161 reserva ENABLED para lo activado realmente. CAPABILITY no cambia y no funciona como recibo de la sesión.

Por eso se necesitan el build y el modo de protocolo del servidor, más el comando y la respuesta de cada cliente. Una pantalla de configuración sin vínculo con la conexión observada no demuestra la activación.

Transportar una identidad no es aprovisionarla

LOGIN no gana credenciales UTF-8. El cliente debe usar AUTHENTICATE. RFC 9755 advierte que esa validez sintáctica no obliga al sistema de identidades a permitir el usuario. La prueba separada confirma el alta en la fuente autorizada, la autenticación real, la asignación al buzón correcto y las autorizaciones por cada acceso compatible.

El almacenamiento empieza después de APPEND

Tras ENABLE, el servidor acepta cabeceras UTF-8 en APPEND; antes debe rechazar un mensaje con cabeceras de 8 bits. Conviene conservar ambas pruebas. El éxito positivo no certifica indexación ni lectura.

La revisión elimina el antiguo elemento APPEND UTF8 y señala que IMAP4rev1, IMAP4rev2 y JMAP no ofrecen un indicador fiable por mensaje sobre su uso previo. El comprobante útil conserva el mensaje de prueba y su hash, la respuesta, el UID asignado cuando exista y una recuperación posterior del mismo objeto.

Los nombres de buzón cumplen Net-Unicode y excluyen controles concretos. RFC 5198 explica NFC como forma canónica; RFC 6532 la recomienda para cabeceras y desaconseja NFKC cuando borra diferencias ortográficas. Parecer igual, tener los mismos octetos y producir el mismo resultado de búsqueda son propiedades distintas.

La documentación de Dovecot muestra una consecuencia práctica: almacenar nombres de buzón en UTF-8 es una opción específica y cambiarla puede romper nombres no ASCII existentes. Es un ejemplo de implementación, no una medición del mercado. Demuestra que actualizar el protocolo no migra automáticamente el mailstore.

BODYSTRUCTURE tiene más de una respuesta correcta

message/global puede aparecer como adjunto desconocido en software no preparado. Con IMAP4rev1 habilitado, RFC 9755 permite dos representaciones BODYSTRUCTURE y obliga al cliente a aceptar ambas; IMAP4rev2 sigue RFC 9051. El erratum 8697 corrige el término a message/rfc822.

El corpus necesita ambas formas rev1, la forma rev2, cabeceras UTF-8 anidadas y recuperación de la parte sin interpretar. Que la interfaz muestre una miniatura no prueba que haya entendido la estructura almacenada.

Encontrar exige su propio ensayo

Después de ENABLE, SEARCH no lleva parámetro charset; SORT y THREAD deben usar UTF-8. Un cliente antiguo puede listar bien y buscar mal. Registre consulta y UIDs para formas compuestas y descompuestas, remitentes, destinatarios, nombres de buzón y cuerpos.

RFC 9755 reconoce además el acceso al mismo mailstore mediante IMAP, POP, webmail u otros clientes. Rechazar, avisar, ocultar o entregar un sustituto estandarizado son políticas diferentes. No se repite aquí la cuestión ya publicada sobre la custodia del original de un sustituto: esta prueba pregunta si cada ruta admitida produce el resultado declarado para el mismo mensaje.

La última evidencia es la del usuario: ve el buzón, encuentra el mensaje, identifica a las partes, abre su contenido y puede responder o reenviar cuando corresponda. Las fuentes prueban semántica de estándares y una decisión de implementación, no adopción ni calidad de un proveedor. Con la distinción de Heng Lu entre representación y realidad ejecutable, el token es la representación; el correo utilizable es la realidad. La cadena normativa también incluye la internacionalización de SMTP, la transformación de degradación, su conducta POP simplificada y la base IMAP4rev2. Acotan la interoperabilidad; no convierten una ruta correcta en visibilidad universal.