Summary

  • El borrador principal de Structured Email define contenido interpretable por máquinas mediante application/ld+json. La revisión 02 del borrador de confianza aborda cuándo mostrarlo o procesarlo.
  • La sección 4.1 propone siete condiciones alternativas para mostrar datos estructurados. Entre ellas figuran un firmante considerado fiable, una conversación previa fiable y la relación con un mensaje anterior fiable.
  • DKIM puede cubrir el mensaje entero y JWS la parte estructurada. La aplicación receptora determina si confía en quien firma.

El texto visible de un correo puede decir «salida a las ocho». El HTML puede presentar una tarjeta de viaje. Una tercera parte puede describir la reserva con datos que una aplicación transforma en una acción. El borrador central del IETF especifica esa parte estructurada; el borrador de confianza del 2 de noviembre pregunta quién permite llevarla a la pantalla. Ahí aparece una autoridad que suele quedar oculta bajo la palabra «verificado».

La clasificación propuesta distingue spam, correo ordinario y correo fiable. En ese modelo, los datos estructurados se procesan para la última clase. La firma establece una relación técnica con un firmante; la aplicación decide si esa relación merece un control activo. El lector puede ver un botón y atribuirle a la firma un aval que en realidad procede de una regla local del producto.

Las siete condiciones de la sección 4.1 muestran cuántas reglas caben bajo ese botón. Puede bastar que los datos no añadan superficie de ataque respecto del HTML, o que el mensaje reciba un tratamiento equivalente al de una invitación de calendario.

También aparecen un remitente fiable con firma personal o de dominio, un remitente fiable con DKIM, un firmante JWS fiable, una conversación activa con un remitente fiable y la conexión con un mensaje antiguo fiable.

Son rutas alternativas del borrador.

Dos aplicaciones pueden leer el mismo MIME y conceder interfaces distintas porque conservan historiales y políticas diferentes.

La memoria del buzón entra en la decisión

El historial de conversación es el punto más incómodo. Un mensaje nuevo puede apoyarse en una relación anterior. Si alguien controla una cuenta que ya participaba en el hilo, la puerta hacia una acción destacada puede ser más corta. La aplicación necesita explicar qué vínculo encontró y cuánto duró su confianza. Un simple «firma válida» omite esa parte de la operación.

El borrador separa además los ámbitos de firma. DKIM firma el correo, mientras JWS puede firmar solo los datos estructurados. Siguen abiertas cuestiones sobre cargas JWS separadas y sobre la comparación por bytes frente al JSON canónico. Esas decisiones inciden en el caso en que el filtro antispam interpreta una representación y la aplicación dibuja otra. Texto, HTML y datos pueden describir reservas diferentes. La acción visible debe examinarse junto al contenido que efectivamente quedó cubierto por la firma.

Hay otra salida del buzón: las referencias externas. Al consultar una URL para completar la presentación, el cliente puede revelar que el lector abrió el mensaje y traer información nueva. La sección 4.3 recomienda datos autocontenidos cuando la interacción significativa requeriría una consulta Web.

Falta un ensayo público con el mismo MIME firmado, un hilo vinculado y una referencia externa en varios clientes; sus controles renderizados y tráfico de red cambiarían la evaluación operativa.

Revisión y estado del borrador · Structured Email · DKIM · JWS