Un analizador de encabezados puede no estar de acuerdo con el receptor original sin que se fabrique ninguna de las observaciones. Es posible que hayan evaluado diferentes bytes de mensajes, diferentes estados de clave DNS o diferentes políticas de verificación en diferentes momentos. Conserve la evidencia original y compare las condiciones antes de decidir qué significa el desacuerdo.
Un resultado histórico mostrado y una nueva verificación criptográfica son operaciones diferentes. Algunas herramientas resumen Authentication-Results ya presente en la muestra. Otros recuperan claves y verifican la muestra actual. Establezca qué operación realiza el analizador antes de comparar su salida con el resultado del sistema receptor.
Preservar el original e identificar el límite.
Exporte el mensaje sin formato utilizando un método que conserve la representación del mensaje. Mantenga un original sin editar y calcule un hash de archivo para compararlo más adelante. Registre el método de recolección, el tiempo de entrega y el buzón de origen. Un hash de archivo puede mostrar que dos archivos exportados difieren; no explica por sí mismo qué diferencia le importa DKIM.
Identifique los Authentication-Results generados por el receptor y su ID de servidor de confianza. Los encabezados proporcionados por un remitente que no es de confianza no son evidencia autorizada del receptor. RFC 8601 §7.1 describe este límite de confianza. Determine también si el receptor evaluó el mensaje antes de que una puerta de enlace posterior o un proceso de exportación lo cambiara.
Comparar las entradas reales del analizador
Para una firma ordinaria de cuerpo completo, un bloque de encabezado copiado omite el cuerpo necesario para volver a calcular su DKIM hash corporal. El caso especial l=0 codifica cero octetos de cuerpo y no proporciona protección de integridad del cuerpo; no renuncia al encabezado, clave u otras verificaciones de verificación. Ver RFC 6376 §3.5, §3.7 y §5.4.1. Pegar texto también puede cambiar el plegado o los finales de línea. Si el analizador carece del mensaje completo, es posible que esté interpretando los resultados informados en lugar de verificar de forma independiente la firma completa. Su etiqueta de interfaz por sí sola no resuelve esa cuestión.
Compare las muestras completas cuando estén disponibles. DKIM canonicalización en RFC 6376 §3.4 tolera transformaciones específicas, no equivalencias arbitrarias del contenido renderizado. Un hash de archivo diferente no significa automáticamente una falla DKIM , ya que algunos cambios de bytes pueden normalizarse; un hash de archivo idéntico establece solo bytes proporcionados idénticos, no DNS o un contexto de política idénticos.
Compruebe qué cambió en DNS y hora
Lea d y s para cada firma y registre las respuestas clave observadas durante la verificación posterior. Es posible que la clave original haya sido retirada, revocada o reemplazada desde la entrega. RFC 6376 §6.1.2 la verificación se basa en la recuperación del material de verificación apropiado, por lo que un pase histórico puede coexistir con un resultado posterior sin clave.
También inspeccione cualquier valor x de vencimiento de la firma y el manejo del tiempo por parte del verificador. Una herramienta posterior podrá evaluarla después de la expiración de la firma. RFC 6376 §6.1.1 permite a los verificadores ignorar las firmas caducadas; el comportamiento de una herramienta específica debe comprobarse en lugar de asumirse. No etiquete ese resultado como prueba de que la firma había caducado cuando el destinatario la procesó originalmente. Cuando la antigua respuesta DNS no esté disponible, indique que el cálculo criptográfico histórico no se puede reproducir completamente a partir de la evidencia actual.
Trabaja a través de dos ejemplos contrastantes
Ejemplo ilustrativo uno: los informes del receptor pasan por selector old1 el lunes y el remitente retira old1 el viernes. Una nueva verificación del sábado informa que no hay clave. Ese resultado posterior no borra la observación confiable del lunes, aunque reproducir independientemente la verificación del lunes requiere los aportes históricos relevantes.
Ejemplo ilustrativo dos: el archivo original recibido se verifica, mientras que una copia pegada falla después de que cambia un pie de página o una serialización MIME . Compare la representación cubierta y el punto donde ocurrió el cambio. El problema puede radicar en el manejo de la muestra y no en la firma original del remitente. Estos son accesorios de comparación, no afirmaciones sobre un analizador o inquilino real.
Informar el desacuerdo con precisión
Cree un registro de comparación que contenga hashes de muestra, métodos de recopilación, tiempos de observación, d y s, respuestas clave, versiones de verificadores, resultados informados y diferencias de políticas conocidas. Inspeccione varias firmas por separado, ya que las herramientas pueden resaltar diferentes. Mantenga la validez DKIM distinta de DMARC alineación y entrega final.
Concluya solo lo que respalda la evidencia: bytes diferentes, DNS modificado, validez transcurrida, firma seleccionada diferente o contexto no resuelto. Preservar la incertidumbre cuando falten los datos originales. Un analizador posterior es una prueba de diagnóstico útil, pero no es una máquina del tiempo y no debería sobrescribir silenciosamente el resultado confiable del receptor original.
Evidencia necesaria para la próxima decisión
Utilice una fila de comparación para cada firma: hash/tiempo de muestra original, hash/tiempo de muestra posterior, d/s, clave observada, x si está presente, herramienta/versión, operación (análisis o verificación de informe), resultado y espacio restante. Los bytes de muestra idénticos con DNS históricos no disponibles dejan una brecha de estado clave, no prueba de que alguna de las herramientas sea incorrecta. Si las muestras difieren, compare la representación canónica cubierta antes de asignar causalidad.