Resumen

  • RFC 5257 conserva metadatos junto al mensaje mediante clases .priv y .shared y derechos distintos; estar al lado del correo no vuelve la nota parte de la declaración del remitente.
  • COPY transporta todas las anotaciones compartidas admisibles y solo las privadas del usuario actual, de modo que los mismos bytes pueden adquirir un perímetro de contexto diferente.

Una etiqueta heredó una confianza que nadie le había dado

El buzón de reclamaciones mostraba una palabra compartida: «autorizado». Un agente creyó que venía del cliente. Otro pensó que la había escrito finanzas. La aplicación solo sabía que alguien con permiso había almacenado el valor. La colocación visual había borrado la diferencia entre correo y comentario.

RFC 5257 crea una entrada separada, asociada al mensaje completo o a una parte. La anotación tiene nombre, atributos, clase de visibilidad y reglas propias. No modifica el cuerpo ni los encabezados que el remitente firmó o envió.

La frontera es económica y jurídica. Un metadato barato puede controlar una cola costosa. La cercanía ayuda a operar; no transfiere la autoridad de quien escribió el mensaje a quien escribió la etiqueta.

Privado y compartido son destinos, no veredictos

Cada atributo tiene variantes .priv y .shared. Leer o buscar sin sufijo puede abarcar ambas. Escribir exige escoger. Así se evita que un cliente deposite información sin saber a qué comunidad la expone.

.priv no promete cifrado ni secreto frente a toda administración. .shared no promete revisión, exactitud ni respaldo institucional. Una es información de usuario; la otra es información visible para actores autorizados del espacio común.

Una nota sensible en compartido puede revelarse a colegas. Un estado de entrega en privado puede desaparecer para el equipo. El peligro surge cuando exportaciones e interfaces ocultan el sufijo y presentan ambas como una sola voz.

Los derechos habilitan acciones, no representación

Sin ACL, la posibilidad de leer o cambiar depende del modo de selección del buzón. Con ACL, r controla lectura y escritura privadas y lectura compartida. El derecho n controla creación y cambio compartidos.

Esta separación es útil para delegar la gestión de un estado sin abrir otras operaciones. Pero el derecho n no autoriza a hablar en nombre del remitente, del cliente o de la dirección. Prueba que el servidor permitió una escritura, no que el negocio reconoció su contenido.

El registro debe conservar identidad del escritor, credencial y ACL. El valor final solo demuestra qué estaba almacenado. No demuestra quién podía obligar a quién.

Persistir no significa quedar congelado

El estándar exige almacenamiento permanente, no datos de sesión. Una nota debe sobrevivir la desconexión. Sin embargo, STORE puede crearla o sustituirla y escribir NIL la elimina.

Un valor inexistente se lee como NIL; su tamaño se lee como cero. Sin historial, la ausencia final no distingue nunca creado, borrado intencionalmente u omitido por una copia que no pudo conservarlo.

Para clientes desconectados se recomienda Conditional STORE. Detectar que otro actor cambió el estado evita sobrescrituras ciegas. No decide cuál nota es correcta ni si quien la escribió tenía autoridad sustantiva.

Cada buzón declara su capacidad efectiva

La capacidad experimental del servidor no basta. El buzón devuelve NONE, READ-ONLY, NOPRIVATE o un límite numérico. También puede imponer un máximo de anotaciones por mensaje.

Una migración que mira solo la capacidad general puede celebrar una copia incompleta. El mensaje llega, pero una nota privada no es compatible, un valor supera el tamaño o el destino no permite cambios. El resultado necesita dos estados: entrega del mensaje y entrega de su contexto.

COPY protege privacidad creando asimetría

Al copiar, viajan todas las anotaciones compartidas y únicamente las privadas del usuario actual, siempre que el destino las acepte. El servidor no debe copiar las notas privadas de otros usuarios.

La regla evita filtraciones, pero significa que dos copias del mismo correo pueden rodearse de información distinta. La investigación privada de quien copia sigue; la de su colega no. Los estados compartidos siguen; un valor demasiado grande puede quedarse atrás.

Además, una etiqueta compartida no hereda la autoridad del remitente. Pudo añadirse después, bajo otra ACL, y viajar a otra carpeta. La copia preserva contenido de anotación, no su mandato.

Buscar y ordenar convierte contexto en poder operativo

Las anotaciones pueden participar en búsquedas y ordenación. Un estado compartido puede decidir qué casos revisa un equipo; un asunto alternativo cambia la presentación; una etiqueta de proveedor activa automatización.

Esa influencia exige procedencia. Un valor puede ser válido según sintaxis, ACL y copia y seguir equivocado. Registrar el nombre de una entrada define cómo interpretarla; no certifica cada instancia.

RFC 5464 mantiene otro ámbito para metadatos de servidor y buzón. La separación confirma que «metadato» no es una autoridad única: objeto, escritor, permisos y reglas de movimiento importan.

El recibo debe envolver la anotación

Conserve buzón y UID, alcance de mensaje o parte, nombre, clase, escritor y credencial, ACL y capacidad, hashes anterior y nuevo, token de estado, resultado, borrado, cuota y tamaño. En una copia, añada origen, destino, actor e inventario de valores copiados u omitidos.

Muestre procedencia, hora y visibilidad. No dibuje la nota como si fuera texto del correo. «La anotación compartida decía “autorizado” tras esta operación» es comprobable. «El remitente autorizó» requiere otra evidencia.

Fuentes