Un mensaje puede tener una validez. firma DKIM mientras que sus campos para cancelar la suscripción no están firmados. Se trata de una brecha significativa: un receptor que verifica el mensaje no necesariamente ha verificado la acción de exclusión anunciada. Inspeccionar la cobertura de la firma, no solo un genérico DKIM etiqueta de paso.
Localiza la firma que protege la operación
RFC 8058 requiere al menos una firma DKIM válida que cubra List-Unsubscribe y List-Unsubscribe-Post . Ambos campos deben aparecer en la etiqueta h= de esa firma válida. La falta de una firma requerida es una razón para que el receptor no ofrezca cancelar la suscripción con un solo clic según la especificación. RFC 8058 sección 4.
Un mensaje puede llevar varias firmas. No combine la validez de uno con la cobertura del encabezado de otro y considere que el par es suficiente. Identifique una única firma válida que cubra los campos requeridos y luego conserve a su firmante. selector y resultado de la verificación. Esto es independiente de comprobar qué firma contribuye a DMARC alineación.
Coloque los encabezados antes del paso de firma correspondiente.
Mapee la canalización de construcción de mensajes: plantilla de aplicación, procesamiento de listas, transformaciones de puerta de enlace, firmante y ruta de salida final. Si un servicio agrega los campos para cancelar la suscripción después de firmar, una firma anterior puede seguir siendo válida sin cubrirlos. La solución es colocar los campos antes de la firma adecuada o asegurarse de que una firma válida posterior los cubra.
Lea el mensaje final emitido. RFC 6376 define la lista h= y las reglas de selección de encabezados, incluida cómo se manejan los nombres de campos repetidos. Una búsqueda de cadena de “lista-cancelar suscripción” en cualquier parte del mensaje no es una prueba de cobertura. Los campos duplicados y las transformaciones requieren una inspección cuidadosa de la entrada de firma real. RFC 6376 secciones 3.5 y 5.4.
Distinguir cambios firmados y sin firmar
Imagine un mensaje de prueba controlado cuya firma, que de otro modo sería válida, cubre ambos campos de cancelación de suscripción. Cambiar el URI firmado a un valor diferente cambia la entrada firmada; bajo verificación DKIM normal, la firma original ya no valida esa entrada alterada. Por el contrario, una firma que omite ambos campos puede seguir siendo válida después de que cambien esos valores sin firmar. Esto explica por qué un pase genérico no puede autenticar todos los campos.
Estas son expectativas basadas en protocolos, no un dispositivo criptográfico ejecutado. Una prueba de mutación autorizada real necesita bytes originales exactos, la firma seleccionada y la clave de verificación correcta. Una clave de prueba inyectada demuestra solo la relación criptográfica de esa prueba, no la procedencia DNS público ni el resultado histórico de recepción. Conservar el original y mutar una copia separada.
Consulta todo el camino señalizado.
Después de arreglar la cobertura, reenvíe un mensaje de prueba autorizado a través de la ruta prevista y verifique en el lado receptor. La reescritura de enlaces, las ediciones de la puerta de enlace o un procesador de listas posterior pueden cambiar un campo cubierto. Preservar las muestras previas a la transformación y finales cuando sea posible para que el propietario pueda ubicar la primera etapa donde diverge la verificación.
Evite resolver el problema simplemente eliminando los campos de h=. Esto puede hacer que la firma sea más fácil de preservar sin cumplir con el requisito RFC 8058 . Si una puerta de enlace debe transformar la acción, coordine el límite de firma final y asegúrese de que el URI transformado aún se asigne al destinatario y la lista correctos.
Completar la verificación operativa.
La cobertura de firma autentica los campos anunciados; no prueba que el punto final realice la supresión solicitada. Utilice una suscripción controlada para probar la POST y la exclusión del siguiente envío descendente por separado. Por el contrario, un punto final que funcione no repara la cobertura de firma faltante.
El registro de cierre debe identificar la firma de cobertura válida, el mensaje final exacto, el alcance del punto final y el resultado de la supresión observado. Mantenga la visualización de la interfaz de usuario del proveedor como una observación separada en lugar de una consecuencia prometida de la firma correcta.
Conservar un registro de cierre específico de la firma
Registre el mensaje final, el firmante, el seleccionador, los dos campos cubiertos y el resultado de la verificación para esa firma en particular. Registre los resultados de los puntos finales y de la supresión por separado. Si una puerta de enlace posterior modifica los campos, repare el límite de firma en lugar de eliminar la cobertura requerida.