Resumen

  • IMAP define \Seen como «el mensaje ha sido leído», pero lo que el servidor observa es estado mutable: BODY[...] puede activarlo, BODY.PEEK[...] recupera contenido sin hacerlo y un cliente autorizado puede añadirlo o quitarlo.
  • Una afirmación sobre lectura humana debe unir principal, cliente, encarnación del buzón, UID, comando, banderas antes y después, respuesta y evento de interfaz. La marca aislada no prueba atención, comprensión, consentimiento ni respuesta.

Una palabra humana en una máquina de estados

Mark Crispin concibió IMAP para que el correo permaneciera en el servidor mientras distintas aplicaciones lo consultaban desde lugares diferentes. El memorial de Stanford señala que inventó el protocolo durante su etapa como programador de sistemas, entre 1977 y 1988. Su perfil del IETF reúne 25 RFC, incluida la RFC 3501, referencia de IMAP4rev1. El Consorcio Unicode, al que contribuyó durante años, lo recuerda como experto en correo y padre de IMAP.

La RFC 3501 define \Seen con una frase rotunda: el mensaje ha sido leído. La RFC 9051 conserva la misma semántica en IMAP4rev2. La etiqueta sirve para que servidores y clientes compartan un estado. No significa que el servidor observe ojos, atención o comprensión.

Los propios documentos separan al «usuario» humano del «cliente» de software. El servidor recibe comandos, entrega datos y modifica atributos. Por tanto, la lectura probatoria más segura es estrecha: en ese momento, el buzón contiene la bandera estándar de leído. Para decir algo sobre una persona hay que reconstruir cómo llegó allí.

FETCH puede escribir; PEEK evita esa escritura implícita

Cuando un cliente pide una sección del cuerpo con BODY[...], las RFC 3501 y 9051 establecen que \Seen se activa de forma implícita. Si la bandera cambia, el servidor informa del nuevo estado. Recuperar datos y escribir metadatos son efectos de la misma orden.

BODY.PEEK[...] recupera la sección sin activar implícitamente \Seen. Así, el protocolo admite hechos distintos: cuerpo obtenido y bandera cambiada; cuerpo obtenido sin cambio; bandera añadida con STORE sin recuperar el cuerpo; bandera eliminada después de una recuperación.

Esas opciones permiten previsualizaciones, sincronización y listas para releer. También impiden tratar el bit como sensor humano. Un indexador, filtro, caché o generador de vista previa puede realizar una recuperación; es una posibilidad operativa, no una descripción de todos los productos. En sentido inverso, una aplicación puede mostrar datos obtenidos con PEEK y conservar el estado no leído. La evidencia del servidor llega hasta el comando y su efecto.

El mensaje puede nacer visto dentro del buzón

APPEND permite suministrar banderas iniciales. Las especificaciones incluyen ejemplos que guardan una copia con \Seen. La marca describe entonces el estado con el que entró la copia, no una lectura humana posterior al almacenamiento.

STORE puede añadir o retirar la bandera. «Marcar como leído» puede afectar un lote sin mostrar sus cuerpos; «marcar como no leído» puede borrar el bit tras una lectura cuidadosa. En un buzón delegado o utilizado desde varios clientes, otro actor autorizado puede producir el estado que alguien observa después.

Por eso «no leído» no equivale a «ninguna persona lo leyó». Solo afirma que la bandera no está presente ahora. La historia puede contener una recuperación, un borrado deliberado, una carrera de sincronización o un estado inicial que el valor actual ya no revela.

Los permisos cambian la huella

La RFC 4314 reserva el derecho s para modificar \Seen. Un FETCH que normalmente lo activaría no debe hacerlo si el usuario actual carece de ese permiso. STORE comprueba el mismo derecho al cambiarlo.

Dos identidades pueden obtener el mismo cuerpo y dejar evidencias persistentes diferentes. En una sesión el bit cambia; en otra, la política impide escribirlo. Su ausencia puede indicar una frontera de autorización, no falta de visualización.

Las implementaciones también pueden manejar banderas compartidas o no compartidas. La pregunta completa es: ¿estado de quién, bajo qué modelo de buzón y con qué derecho? Un buzón personal, uno de soporte compartido y una delegación ejecutiva no producen pruebas equivalentes aunque usen el mismo nombre.

Ordenar cambios no identifica su causa humana

La RFC 7162 añade CONDSTORE y QRESYNC. Las secuencias de modificación ayudan a detectar metadatos nuevos, actualizar cachés y condicionar STORE con UNCHANGEDSINCE. Una escritura obsoleta puede fallar explícitamente en vez de borrar un cambio concurrente.

Pero la secuencia acredita orden, no autor ni motivo. Por sí sola no distingue FETCH implícito, STORE explícito, otro cliente o agente externo. Tampoco muestra qué apareció en pantalla o si alguien prestó atención.

La RFC 8621 lleva el concepto a JMAP como $seen, palabra clave que un usuario con permiso puede añadir o quitar. Una sincronización perfecta prueba que varios sistemas comparten el mismo estado; no amplía lo que ese estado observó.

Una cadena de recibos, no un solo adjetivo

El registro defendible identifica principal autenticado, delegación, instancia cliente y sesión. Une la encarnación del buzón mediante UIDVALIDITY y el UID estable del mensaje. Conserva causa, sección pedida, banderas previas y resultantes, respuesta, hora y secuencia de modificación cuando exista.

El evento de pantalla pertenece a otro recibo. El acuse de una persona requiere uno adicional. El resultado puede decir: «cliente recuperó el cuerpo; Seen se activó implícitamente; visualización desconocida; sin acuse». Es menos cómodo que «leído», pero permite decidir sin inventar observaciones.

Crispin hizo interoperable el estado del buzón. La obligación posterior es no convertir ese logro en testimonio sobre una mente que el protocolo nunca vio.

Fuentes