Trate el historial de modificaciones como evidencia, no como permiso
Una lista de correo puede agregar un pie de página o revisar un campo Asunto por un motivo legítimo. Un intermediario hostil también puede cambiar un mensaje. La pregunta importante no es simplemente si algo cambió, sino si el receptor puede reconstruir la historia relevante, verificar los dominios responsables y decidir qué significa esa historia. DKIM2 propone maquinaria para las dos primeras tareas; no responde automáticamente al tercero.
Esta explicación está fijada en draft-ietf-dkim-dkim2-spec-09, de fecha 1 de noviembre de 2026 y actualmente un borrador de Internet activo. Los estados de verificación propuestos se refieren a modificaciones no declaradas y a la coherencia del camino de entrega. La Sección 14.1 separa explícitamente esas comprobaciones del valor de un mensaje o de la benignidad de los cambios declarados. Una cadena verificada no es una recomendación de confianza general.
Construye un camino original pero claramente ficticio.
Considere tres sistemas inventados: author.larch.example , list.fir.example y inbox.birch.example . El primero crea un mensaje cuyo cuerpo consta de dos líneas, “Agenda” y “Viernes al mediodía”. La lista agrega una tercera línea, "Pie de página de la lista", sin cambiar el cuerpo de otra manera. Supongamos que los dominios, las direcciones de los sobres, los relojes y las claves cumplirían las comprobaciones pertinentes. Estos son aportes didácticos estipulados, no un mensaje capturado o evidencia que cualquier firma verifique.
En el origen, la representación propuesta incluye Message-Instance m=1 con los hashes de encabezado y cuerpo originales y DKIM2-Signature i=1 que hace referencia a esa instancia. Después del cambio de la lista, una segunda instancia registra los hashes actuales y la información necesaria para reconstruir el formulario anterior. La lista agrega su propia firma con la secuencia apropiada y la referencia de instancia. Los valores hash y los bytes de firma no se inventan intencionalmente en este ejemplo.
Explica por qué las recetas van al revés.
Secciones 5 y 12.1 describir recetas para recrear el contenido de mensajes anteriores. En el caso del cuerpo ficticio, reconstruir el original significa conservar las dos primeras líneas actuales y excluir el pie de página adjunto. La receta explica cómo recuperar el estado antiguo del nuevo; no es simplemente una instrucción que dice "agregar un pie de página". Un dispositivo real necesitaría contenido con precisión de bytes y las reglas de codificación precisas del borrador.
Una variante de cambio de cabecera necesita su propia evidencia de reconstrucción. Si una lista antepone el Asunto, el valor original debe ser recuperable para la verificación anterior del hash del encabezado. Registre el campo original, el campo modificado y la receta juntos para que un revisor pueda determinar si el cambio se representó fielmente. No confíe en una captura de pantalla renderizada del cliente de correo, que puede ocultar detalles de plegado, codificación y campos duplicados relevantes para un verificador.
Verificar más que la firma más reciente
Bajo sección 13, la verificación completa verifica las instancias de mensajes anteriores reconstruidas aplicando recetas posteriores en orden descendente, así como la cadena de firmas. Verificar sólo el cuerpo final mostrado y la firma más reciente es una operación diferente y más limitada. El proyecto define por separado la verificación provisional para la evaluación inicial limitada; los dos resultados no deberían compartir una insignia verde no calificada.
El receptor también necesita el contexto de entrega. La sección 14.4 compara la información del último sobre firmado con la transacción SMTP real, mientras que los saltos anteriores deben cumplir las reglas de la cadena. La Sección 14.8 verifica los campos De actual e histórico relevantes con las identidades de firma apropiadas. Un archivo de sólo contenido no puede establecer todas esas condiciones si ha perdido el sobre original y la evidencia del tiempo de aceptación.
Por lo tanto, para la ruta ficticia, la secuencia de revisión esperada es: inspeccionar la sintaxis y el orden, conservar el contexto SMTP , verificar las marcas de tiempo, validar la cadena y las claves, verificar las firmas, reconstruir cada instancia relevante, comparar hashes y evaluar la autenticidad. Este es un rastro de razonamiento propuesto. No es una afirmación de que un paquete de software en particular haya ejecutado esos pasos o haya devuelto PASS.
Mantener visibles las recetas nulas y la redacción
El borrador permite una receta de cuerpo nulo para indicar que no se puede reconstruir un cuerpo anterior. No permite recetas nulas para cambios de encabezado. Esa distinción es importante para una puerta de enlace que elimina material confidencial: una receta reversible podría retener el mismo contenido que la puerta de enlace pretendía eliminar. Una revisión de privacidad debe examinar la carga útil de la receta, no solo el cuerpo final visible para el destinatario.
La sección 13 de Core -09 dice que los hash del cuerpo anteriores debajo de una receta nula no se pueden verificar y el mensaje no está completamente verificado. No obstante, la política local podrá aceptarlo, por ejemplo bajo una relación adecuada. Eso no equivale a restaurar criptográficamente la evidencia faltante. El laboratorio debe informar la verificación del cuerpo histórico no disponible y la decisión de aceptación local por separado en lugar de cambiar el nombre del resultado a verificación completa.
No confunda solicitudes con confianza ejecutable
el separado CanModify -00 borrador explora las solicitudes de los originadores sobre modificaciones. Se publicó el 2 de noviembre como borrador individual de Internet. Su tratamiento es una política local, y alguna discusión sobre la benignidad permanece explícitamente inconclusa. No debe fusionarse con core -09 como un sistema de permisos implementado universalmente.
Esto crea una distinción práctica para los operadores. Una receta puede admitir la atribución, una solicitud del autor puede expresar una preferencia y un receptor puede decidir si acepta el mensaje resultante. Ninguno demuestra por sí solo que el mensaje modificado sea seguro. Las notas de los revisores deben identificar cuál de esas preguntas responde realmente un resultado observado, especialmente cuando un informe de producto utiliza la palabra "confiable" sin definirla.
Conserve la evidencia de verificación exacta que falta
La comisión exacta es: rastrear un mensaje original, modificado y verificado a través del modelo de borrador fijado en la versión. El seguimiento ficticio original proporciona la estructura y las comprobaciones esperadas, pero en este paquete no existe ningún mensaje firmado, hash calculado, salida de verificador compatible ni resultado verificado real. La puerta de la prueba de puesta en servicio permanece abierta en lugar de estar cerrada por una ilustración.
Un futuro experimento autorizado debería preservar tanto los formularios de los mensajes como los datos de reconstrucción, los metadatos de los sobres, las instantáneas clave, las versiones de software y los diagnósticos completos del verificador. Incluya un control de cambios no declarados y una variante de receta nula. Los especialistas técnicos y de privacidad deben revisar la interpretación y exposición antes de cualquier uso real. La aplicabilidad de la producción, la revisión visual y la aprobación de la publicación del propietario también son sobresalientes; Aquí no se hace ningún reclamo de migración o confianza universal.