Resumen

  • $unsubscribed registra que el usuario intentó darse de baja, incluso si todavía no existe confirmación de éxito. $canunsubscribe solo indica que el servidor considera ofrecible el mecanismo.
  • RFC 9979 distingue etiquetas asesoras, estados que pueden activar acciones, atributos de almacenamiento y afirmaciones del servidor. La interoperabilidad del nombre no demuestra la verdad ni el efecto de una instancia.

El usuario pulsó una vez. El cliente envió la solicitud, añadió $unsubscribed y sincronizó el cambio. El teléfono, el navegador y el portátil mostraron el mismo estado. Dos semanas después seguían llegando mensajes. En el informe de cumplimiento, la palabra “unsubscribed” se había convertido en una fecha de baja efectiva.

El registro no mentía. Decía que hubo un intento. El informe había inventado el resultado.

El ejemplo es hipotético; no describe una lista, proveedor o incidente reales. La distinción procede de RFC 9979, publicado por el IETF en mayo de 2026 con categoría Informational. El documento define 17 palabras clave de mensajes y tres atributos de nombre de buzón usados por distintas implementaciones. Su trabajo consiste en fijar nombres y significados para evitar colisiones, no en certificar cada mensaje.

El registro IANA de palabras clave IMAP y JMAP muestra nombre, tipo, uso, ámbito y referencia. El registro de atributos de buzón IMAP incorpora Memos, Scheduled y Snoozed. Esos asientos prueban coordinación del espacio de nombres. No prueban que una baja terminó, que un remitente es auténtico ni que un mensaje programado salió.

La arquitectura precedente ya separaba estas capas. RFC 5788 creó el registro. RFC 8457 registró una semántica compartida para la importancia. RFC 9051 define IMAP4rev2 y RFC 8621 JMAP Mail. RFC 9979 hace que un estado pueda viajar entre ellos, pero deja la decisión concreta en la implementación.

No todas las palabras clave tienen el mismo autor ni la misma fuerza. El servidor coloca algunas durante la entrega. El cliente coloca o retira otras a partir de una acción del usuario. Algunas son asesoras para la interfaz. Otras pueden activar tratamiento automático. Si una exportación conserva la etiqueta y descarta actor, regla y hora, conserva la conclusión visible y pierde su causa.

La diferencia entre ausencia y negativo explícito aparece en las etiquetas de adjuntos. $hasattachment y $hasnoattachment no pueden coexistir. Sin embargo, que falte la primera no demuestra la segunda: quizá ningún componente analizó aún la estructura. Un sistema honesto necesita “sí”, “no comprobado” y “desconocido”. Un icono binario no debe borrar la tercera posibilidad.

JMAP debe reflejar esa información en hasAttachment. La igualdad entre superficies demuestra coherencia de sincronización. No valida el parser, la versión del mensaje ni la vigencia del análisis. Dos clientes pueden coincidir porque ambos recibieron el mismo error.

Los memos exigen además una transición acoplada. $memo marca el mensaje-nota; $hasmemo marca el mensaje anotado. Al crear o borrar la nota hay que cambiar ambos extremos. RFC 8474 aporta identificadores estables de objeto y conversación. Si una operación queda a medias, una etiqueta aislada puede sobrevivir con sintaxis correcta y relación inexistente.

En el flujo de baja, $canunsubscribe es una evaluación previa. El servidor encontró una cabecera List-Unsubscribe conforme y aplicó controles de reputación propios. RFC 8058 describe la señalización de un clic. Eso permite ofrecer un botón con menos riesgo y coste. No demuestra que alguien lo pulsó ni que el sistema remoto aceptó la solicitud.

$unsubscribed aparece después del intento. RFC 9979 permite conservarlo aunque no haya confirmación de éxito y prohíbe ponerlo cuando el fallo es seguro. Por tanto, una implementación no debería modelar dos estados, suscrito/no suscrito, sino al menos cinco: acción disponible, intento iniciado, fallo confirmado, resultado desconocido y éxito confirmado. El recibo de la lista pertenece al último, no a la etiqueta intermedia.

Esta precisión cambia decisiones empresariales. Un equipo de privacidad puede contar intentos; un equipo de entregabilidad necesita comprobar que cesó el flujo; un área legal debe saber qué obligación se mide. Si las tres leen el mismo participio como resultado, la métrica será coherente y falsa.

$istrusted tiene otra clase de poder. El servidor la coloca como indicación asesora de que verificó con alta confianza el nombre y la dirección del remitente. RFC 9979 advierte del daño si se usa mal y dice expresamente que no puede basarse solo en una aprobación SPF, DKIM o DMARC.

La razón está en el alcance. RFC 7208 autoriza hosts para una identidad de sobre. RFC 6376 verifica una firma de dominio sobre contenido seleccionado. RFC 9989 evalúa alineación con el dominio visible y una política solicitada. Son señales útiles, pero no prueban automáticamente el nombre humano mostrado, su función, la seguridad de una petición o la verdad del texto.

El RFC no normaliza qué significa cuantitativamente “alta confianza”. El operador conserva libertad para añadir conocimiento propio, pero también la responsabilidad de dejar una huella: servidor, algoritmo y versión, clases de evidencia, confianza, fecha, caducidad y motivo de revocación. Mostrar una marca intensa sin esa trazabilidad presta autoridad al símbolo.

La sección de seguridad lo hace explícito. Cliente y usuario deben confiar en el servidor IMAP; un servidor comprometido o malicioso puede manipular etiquetas para engañarlos. Replicar fielmente $istrusted en cinco dispositivos no crea cinco testimonios. Sigue siendo una sola afirmación de origen.

Las etiquetas de atención deben mantenerse fuera del eje temporal. $new puede resaltar un mensaje antiguo que despierta después de estar pospuesto. $notify solicita que el cliente muestre una notificación salvo preferencia contraria. Ninguna prueba cuándo nació el mensaje, si apareció en pantalla, si fue leído o si produjo respuesta.

Los atributos especiales tampoco ejecutan acciones. Snoozed identifica un almacén para mensajes temporalmente apartados y no define por sí mismo el mecanismo de despertar. Scheduled identifica dónde se guarda un mensaje con intención de envío futuro. Estar allí no equivale a haber sido sometido, aceptado por un relay o entregado. Hacen falta eventos separados para programación, intento, respuesta de transporte y disposición.

$followed y $muted son incompatibles; si coexisten, seguido prevalece. La regla produce un comportamiento interoperable, pero no explica el conflicto. RFC 9979 señala que quien compromete una cuenta puede silenciar conversaciones para ocultar respuestas y recomienda revisar esas acciones al recuperar acceso. Cambiar credenciales sin auditar el estado sincronizado deja viva una decisión del atacante.

La ficha del RFC y la consulta de erratas delimitan el texto aplicable. No informan de despliegues, algoritmos reales, buzones ni resultados. La afiliación de los autores tampoco prueba que una empresa haya adoptado cada función.

Las capas de realidad de Heng Lu separan registro, política local, afirmación, estado sincronizado, presentación, creencia, acción y resultado. Running-Code Primacy exige mirar el clasificador y el efecto ejecutados. Minimum Initial Specification permite compartir un vocabulario mínimo sin centralizar cada criterio operativo.

El recibo complementario debe identificar mensaje, hilo o buzón; palabra clave; actor autorizado; servidor y cliente; protocolo; estado previo y nuevo; regla o gesto; referencia de evidencia; confianza; tiempo y caducidad; sincronización; presentación; preferencia; acción; respuesta externa; y corrección. Los datos sensibles pueden permanecer protegidos, pero no puede desaparecer la existencia de su método.

La lección de RFC 9979 no es desconfiar de todas las etiquetas. Es dar a cada una exactamente el peso que su semántica y su procedencia permiten.

Fuentes