Resumen

  • La compatibilidad con IMAP2bis era voluntaria y combinaba sustituciones útiles, aproximaciones y funciones sin equivalente; no ofrecía continuidad transparente. RFC 2061.
  • Compensar un cambio de \Seen no equivale a evitarlo, y el éxito de COPY no acredita la conservación de sus metadatos. RFC 2060 y RFC 2061.

Una vista previa puede obtener el contenido y después intentar deshacer el cambio que su lectura produjo en el buzón. Haber recuperado los bytes no demuestra que el estado haya permanecido intacto. Esa diferencia permite leer el RFC 2061 como una propuesta de compatibilidad limitada, no de transparencia.

Una memoria para convivir con lo que ya existía

En diciembre de 1996, Mark Crispin, de University of Washington, publicó esa memoria informativa, no un estándar. Describía IMAP2bis como muy común y ampliamente distribuido con Pine, aunque sin una descripción definitiva. Reconocía conocimientos incompletos y saber informal acumulado; no aportaba una cuota de mercado ni cubría todas las variantes. RFC 2061.

El texto debía leerse junto al IMAP2 del RFC 1176, de agosto de 1990, y al IMAP4rev1 del RFC 2060, de diciembre de 1996. Este último era distinto del IMAP4 del RFC 1730, de diciembre de 1994: atender a ambos exigía consultar ambos. El RFC 1732, también de 1994, ofrecía orientaciones más amplias sobre variantes antiguas, no el mismo alcance acotado de la memoria posterior.

Reconocer no era certificar

Ante CAPABILITY, un resultado OK permite conocer las variantes IMAP4 anunciadas. Si el cliente no reconoce ninguna, la memoria aconseja tratar el servidor como IMAP2bis; BAD apunta a IMAP2bis o algo anterior. Es una heurística para escoger una ruta, no una identificación concluyente: un tiempo de espera agotado u otro fallo, incluido uno de seguridad, no son BAD. Esa clasificación tampoco demuestra que las órdenes posteriores funcionen. Ninguna de estas adaptaciones era obligatoria en IMAP4. RFC 2061.

Conviene distinguir tres clases analíticas, no categorías formales del RFC:

Clase Adaptación y límite
Operación útil o casi equivalente para una tarea acotada LIST pasa a FIND ALL.MAILBOXES, con sintaxis y respuesta parecidas a FIND MAILBOXES del RFC 1176; esta última probablemente no resulte útil. El * de una secuencia se reemplaza por el recuento recibido en una respuesta no solicitada EXISTS: eso no congela el buzón. RFC 2061.
Aproximación o compensación Las extensiones de SEARCH se reformulan con sintaxis del RFC 1176, quizá mediante varias búsquedas, sin prometer iguales criterios o juegos de caracteres. BODYSTRUCTURE pasa a BODY no extensible; HEADER, TEXT, MIME, HEADER.FIELDS y HEADER.FIELDS.NOT se reducen a números de sección. Cambiar la petición no fabrica la semántica ausente. RFC 2061.
Sin equivalente El elemento de recuperación UID, las órdenes UID y CLOSE carecen de equivalente funcional. LSUB, SUBSCRIBE y UNSUBSCRIBE no tienen equivalente directo. Los antiguos bboards eran otro concepto: la memoria desaconsejaba implementar sus órdenes en software nuevo, incluso en servidores para clientes antiguos. RFC 2061.

Deshacer un cambio no significa haberlo evitado

Para BODY.PEEK[section], el RFC 2061 propone BODY[section] y retirar manualmente \Seen cuando sea necesario. El RFC 2060 distingue la lectura que activa implícitamente ese indicador de PEEK, que no lo activa; también contempla cambios por otros agentes y recomienda notificaciones automáticas de indicadores.

Si la lectura activa \Seen, retirarlo después supone otra modificación, no una lectura sin efectos. Con estado compartido y mutable, otro actor podría observar o alterar el indicador entre ambos pasos. No debe retirarse un \Seen preexistente ni borrarse a ciegas un cambio concurrente. Esta inferencia no describe un incidente documentado ni una carrera universal; la memoria no ofrece restauración atómica. RFC 2061 y RFC 2060.

También FLAGS.SILENT, +FLAGS.SILENT y -FLAGS.SILENT pasan a sus correspondientes variantes de STORE sin .SILENT: el cliente ignora las respuestas FETCH sin etiqueta. Ignorarlas localmente no impide su emisión ni elimina los efectos observables fuera del cliente. RFC 2061.

Una copia aceptada no certificaba la conservación

La compatibilidad descrita en el RFC 2061 no permite saber si COPY conservará indicadores y fechas internas: IMAP2bis es ambiguo al respecto. El SHOULD de conservación del RFC 2060 no se aplica retrospectivamente. Un OK de COPY no es un recibo de preservación; probar un servidor documenta ese caso, no crea un contrato universal.

Además, en IMAP2bis, TRYCREATE aparece en un OK no solicitado separado, no dentro de NO. Hay que interpretar esa respuesta conservando el contexto del fallo: el aviso no convierte una copia fallida en exitosa. RFC 2061.

Dos precauciones históricas

En sentido inverso, entre un servidor IMAP4 y un cliente IMAP2bis bien escrito, la memoria solo señala la incompatibilidad de la barra inversa en cadenas entrecomilladas: aconseja literales cuando contienen \ o ". Esa afirmación depende de la calidad del cliente y del conocimiento declarado; no abarca cualquier software antiguo. RFC 2061.

La sustitución de AUTHENTICATE por LOGIN también era consejo histórico; la memoria excluía expresamente la seguridad. No autoriza hoy texto claro ni rebajas de protección. El RFC 8314 de la IETF, de enero de 2018, aporta el límite posterior sobre TLS para envío y acceso al correo, no pruebas de su despliegue en 1996.

Elegir un servicio reducido

Lu Heng escribe en su ensayo de 2026 sobre adopción voluntaria: “Non-adoption is not a violation.” La conexión editorial es limitada: el cliente escoge qué compatibilidad acepta. En su ensayo de 2025 sobre realidad y poder simbólico, afirma: “Most conflicts persist because participants mix these layers.” Aplicado aquí, distinguir el nombre de una capacidad de sus efectos ejecutables permite delimitar una promesa de servicio reducido. Son marcos posteriores, no fuentes históricas sobre IMAP ni pruebas de las intenciones de Mark Crispin.

Fuentes y alcance

Fuente Qué permite establecer
RFC 2061 Memoria informativa de diciembre de 1996: sustituciones voluntarias, límites e incertidumbres.
RFC 2060 IMAP4rev1, diciembre de 1996: PEEK, indicadores y recomendación de conservación en COPY.
RFC 1176 IMAP2, agosto de 1990: sintaxis antigua, no especificación definitiva de IMAP2bis.
RFC 1730 IMAP4, diciembre de 1994: versión distinta de la revisión de 1996.
RFC 1732 Compatibilidad con IMAP2, IMAP2bis y variantes menos comunes, diciembre de 1994.
RFC 8314 TLS, enero de 2018: límite posterior de seguridad, no descripción de instalaciones de 1996.
Lu Heng: especificación mínima y adopción voluntaria Marco interpretativo de 2026; no evidencia histórica de implementación de IMAP.
Lu Heng: realidad y poder simbólico Marco interpretativo de 2025; no prueba de la intención del autor del RFC.