Resumen

  • draft-gondwana-dkim2-debug-header-01 normaliza una pista X-DKIM2-Info para las primeras pruebas de DKIM2; no añade un resultado de autenticación.
  • El campo está deliberadamente fuera de hashes y firmas. Puede conducir a una persona hasta la evidencia, pero no autentica quién lo emitió, qué acción ocurrió, qué instantánea se usó ni si falta algún tramo.

El correo que falla llega con una narración casi irresistible. Una cabecera declara la revisión de DKIM2 que ejecutaba el filtro de entrada, el repositorio y el programa. Otra atribuye al gestor de la lista la creación de Message-Instance m=2, enumera las cabeceras incluidas en el hash y señala una copia anterior. Al final, el filtro de salida afirma que no firmó porque la cadena estaba rota.

Para una persona que compara dos laboratorios, ese nivel de detalle puede ahorrar horas. Para una máquina que decide si entrega, pone en cuarentena o atribuye una acción, no vale como prueba. Todo el relato puede insertarse, editarse, reordenarse o desaparecer sin alterar las partes del mensaje que DKIM2 sí protege.

Esa separación define A Diagnostic Header Field for DKIM2 Implementations. La revisión 01 apareció el 30 de septiembre de 2026 en horario del Pacífico, ya 1 de octubre en Shanghái y UTC. Es un Internet-Draft individual con estado previsto Informational y figura como I-D Exists. No ha sido adoptado por el grupo DKIM, no es un RFC, no registra nada en IANA y DKIM2 no depende normativamente de él. El propio texto lo sitúa en las pruebas tempranas y dice que probablemente no se publique.

Un mapa compartido de pistas, no de hechos

DKIM2 intenta conservar una cadena verificable cuando una lista de correo u otro intermediario transforma el mensaje. Message-Instance contiene hashes y Recipes para reconstruir estados anteriores; DKIM2-Signature encadena esos registros protegidos. Cuando dos prototipos discrepan, un resultado final puede ser demasiado tosco para localizar el primer desvío.

X-DKIM2-Info establece un lugar y una gramática comunes. Cada campo incluye cinco etiquetas obligatorias y ordenadas: draft, repo, date, sw y action. draft identifica la revisión de DKIM2 implementada. El repositorio y el programa ayudan a distinguir un componente o una bifurcación. La fecha funciona como versión de comportamiento y debería cambiar cuando cambie la conducta DKIM2 del emisor. Cada campo describe una acción; varias acciones requieren varios campos.

Las acciones previstas cubren una verificación, una nueva Message-Instance, una firma y la negativa a firmar. verify=pass o verify=fail puede llevar una explicación libre. mi-m=<N> puede añadir el recuento y el orden de las cabeceras incluidas en el hash, además de los identificadores de la instantánea recuperada y de la guardada. sign nombra dominio y algoritmo. not-signed lleva una razón elegida por la implementación, como broken-mi-chain.

La revisión 01 reduce ruido entre implementaciones: adopta la sintaxis exacta de etiquetas de extensión de DKIM2, exige punto y coma tras todas las etiquetas y cambia mi-m<N> por mi-m=<N>. Así evita que una diferencia puramente gramatical oculte el desacuerdo sustantivo. No convierte el rastro en evidencia autenticada.

La prueba ignora el campo para que el campo pueda moverse

La especificación base de DKIM2 excluye del hash de Message-Instance las cabeceras cuyo nombre empieza por X-. El borrador de diagnóstico también impide que el emisor incluya X-DKIM2-Info en lo que firma o resume. Por eso puede insertar una nota junto al elemento que describe sin modificar la Message-Instance ni romper una firma DKIM2.

Esa ventaja contiene su propia limitación. El documento dice que el campo no es un resultado de verificación; el resultado autorizado corresponde a Authentication-Results. Solo registra lo que el emisor afirma haber hecho, y ningún software debe tomar una decisión sobre el mensaje basándose en esa afirmación. Cualquier manipulador puede añadir, alterar o eliminar una línea sin que el cambio sea detectable.

El artículo BTW anterior sobre Authentication-Results estudió una frontera distinta: cuándo un consumidor puede confiar localmente en un authserv-id dentro de un dominio administrativo y una transacción SMTP. Esta nueva cabecera se encuentra un nivel más abajo. Ni siquiera pretende ser un veredicto local: su papel es dar a una persona una pregunta mejor para la investigación.

Estar al lado no significa haber causado

El borrador indica que el emisor añada primero la cabecera operativa o protegida y sitúe inmediatamente encima la nota de depuración. También prohíbe a un emisor conforme modificar o borrar notas previas. El bloque adquiere así una secuencia visual fácil de seguir.

Pero la adyacencia no está autenticada. Un procesador posterior puede anteponer un action=sign verosímil, mover una nota junto a otra Message-Instance o borrar la explicación del fallo. Un repositorio y un nombre de programa son descripciones hechas por el propio emisor, no una atestación del binario. La fecha no equivale a un commit. Faltan identidad de instancia, identificador de evento, secuencia, acuse del receptor y declaración de completitud que unan las líneas en un registro a prueba de cambios.

También es imposible interpretar el silencio. Cuando la Message-Instance superior sigue coincidiendo y el emisor no añade nada, el formato no registra una acción. La ausencia de mi-m=<N> no demuestra que se haya ejecutado la comprobación, que no haya habido transformación ni que la traza haya llegado íntegra.

El localizador no transporta la instantánea

snapf y snaps parecen las etiquetas más concretas. La primera identifica la copia previa usada para calcular una Recipe; la segunda identifica la copia actual conservada para una comparación posterior. Sin embargo, el borrador aclara que solo tienen significado para el emisor. Uno de sus ejemplos se parece a una clave de base de datos o una ruta.

Ese dato puede ser excelente para una llamada operativa: permite pedir al responsable los bytes, registros y política de retención asociados. Fuera de su sistema no acredita el contenido, la custodia, la disponibilidad ni el tiempo de conservación. Sin un hash de contenido y un recibo de recuperación separados, un identificador copiado no es una evidencia portátil.

La utilidad diagnóstica introduce además una superficie de revelación. El campo puede exponer repositorios, programas, revisiones, estructura de almacenamiento e inventario de cabeceras. Una explicación libre puede delatar comportamientos del parser. Un operador puede retirar esas líneas en el límite de salida sin afectar DKIM2, protegiendo detalles internos a costa de borrar la pista que esperaba el laboratorio remoto. La política de retención interna y la de divulgación deben diseñarse juntas.

Hay una arista sintáctica: RFC 5322 permite el punto y coma en el nombre de una cabecera, mientras que la nueva gramática usa ese carácter para cerrar etiquetas y no dispone de comillas. El borrador pide omitir de hn los nombres inseguros, limitar su longitud y sustituir o quitar puntos y coma en valores incorporados. Son defensas de normalización, no una garantía sobre la conducta de todos los prototipos.

RFC 6648 documenta el riesgo general de los prefijos X-: lo experimental escapa, se consolida como interfaz de facto y complica la migración. Aquí el prefijo es una decisión consciente que mantiene el diagnóstico fuera de la semántica y de la cobertura criptográfica de DKIM2. Una separación protocolaria clara no garantiza que el dato permanezca dentro de la organización.

La pista debe terminar en una evidencia reproducible

Una investigación responsable distingue la identidad de software declarada, la acción declarada, el campo que realmente llegó, el límite que lo conservó o retiró, la verificación DKIM2 real, el Authentication-Results local, el build, los logs y las instantáneas, el juicio sobre la causa, la reparación y el resultado de entrega observado. Saltar un peldaño convierte una comodidad de soporte en una conclusión que no puede sostener.

La idea de especificación mínima de Heng Lu favorece esta disciplina. Un formato pequeño y compartido puede acelerar las pruebas independientes sin reclamar la verdad del entorno local. La primacía del código en ejecución exige después observar el software, recuperar la copia, reproducir el fallo y comprobar el resultado posterior.

El valor de X-DKIM2-Info reside en dejar huellas legibles cerca de la avería. El peligro aparece cuando esas huellas pasan a ser procedencia, política o veredicto. La automatización sensata no decide con la pista; la usa para encontrar la evidencia que sí puede comprobar.

Fuentes