☰

Exim falso negativo en la verificación DKIM

tag-icon • tag-icon exim dkim
Exim falso negativo en la verificación DKIM

Mi servidor de correo que usa exim4 tiene una ACL para verificar las firmas DKIM. Acepta todo pero registra los fallos y escribe un encabezado con los resultados.

Estoy enviando correo desde otro servidor que creo que está agregando firmas DKIM correctamente. (Por ejemplo, envié correo a direcciones de Gmail y Outlook, inspeccioné los encabezados y ambos sistemas aprobaron el DKIM). Pero mi servidor de correo dice bodyhash_mismatch.

Mi servidor de correo no siempre dice que DKIM es un error.

Aquí tienes un correo electrónico. He cambiado los dominios:

  • ejemplo.orgEste es el dominio de la organización principal; se usa en elDe:encabezado y es el dominio firmante. La clave pública se publica en el DNS.
  • remitente.ejemplo.orgEste es el servidor que envía el correo electrónico, crea el encabezado DKIM. Es elVía de retornoencabezamiento.
  • receptor.ejemplo.orgEste es el dominio de mi servidor de correo, donde se verifica el DKIM. Aquí es donde X-dkim-checkse agrega el encabezado y el texto siguiente domain=proviene de$dkim_cur_signer
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail.receiver.example.org
    by mail.receiver.example.org with LMTP
    id t8rHGepc52SOVA8ADCPZSA
    (envelope-from <[email protected]>)
    for <[email protected]>; Thu, 24 Aug 2023 14:36:42 +0100
Received: from sender-rdns.example.org ([1.2.3.4] helo=sender.example.org)
    by mail.receiver.example.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    (Exim 4.94.2)
    (envelope-from <[email protected]>)
    id 1qZAVv-004DMU-00
    for [email protected]; Thu, 24 Aug 2023 14:36:42 +0100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
    d=example.org; s=220151210; h=Sender:Message-Id:Subject:From:To:Date:
    Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
    Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
    :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
    List-Subscribe:List-Post:List-Owner:List-Archive;
    bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; b=GTY2HZVje81tRJ0/xKFNUk5d7/
    9wE7CGtwmz2APM5VTDKY6q+qIbwhCRNzc6IWZ4j0Y9FOtnuVBeNR1I5xbOuqPaf62MYQZJFjLQ3/J
    PNpOpS3i1Yd3NCZUs1iB/Q8N+ii73FrvD5k1AA8F5yzJhVeaposgbkvU5vv1s/KgqTIA=;
Received: from localhost ([127.0.0.1] helo=sender.example.org)
    by sender.example.org with esmtp (Exim 4.96)
    (envelope-from <[email protected]>)
    id 1qZAVt-001EhO-2k
    for [email protected];
    Thu, 24 Aug 2023 14:36:41 +0100
Date: Thu, 24 Aug 2023 14:36:41 +0100
To: [email protected]
From: [email protected]
Subject: test Thu, 24 Aug 2023 14:36:41 +0100
Message-Id: <[email protected]>
X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/
Sender: [email protected]
X-dkim-check: DKIM test failed: (domain=example.org), signature is bad.

This is a test mailing

¿Cómo puedo depurar por qué exim on receiver.example.orgcree que la firma es mala?

(Observo que la firma DKIM incluye muchos encabezados que no existen. ¿Podría ser esa una razón?)

EDITAR: agregando detalles:

  • Firma exim: 4.96-15+deb12u1.
  • Recibiendo exim: 4.94.2-7~bpo10+1

Respuesta1

No creo que el mensaje "es malo" exprese ningún motivo particular por el cual no se pudo validar una firma. Configure los encabezados de resultados de autenticación adecuados: esa retransmisióntodo lo que te dice exima través de $dkim_verify_reason.

Intenta identificarcuallos mensajes fallan, recuerdo ejemplos de otros verificadores que fallaron solo en ciertos mensajes o tamaños de partes del mensaje (alineados en bloques, <=16KiB, >=16MiB... su mensaje de prueba parece pequeño) o longitud de línea (su mensaje de prueba se ve bien, aunque inusualmente doblado).

Además, compare la fuente del mensaje tal como se envió (idealmente, tal como se cargó por separado en el Sentbuzón). Puede que haya tenido algún problema de sintaxis que se ha descartado al recibirlo, pero había sido significativo para la firma.

Ideas:

  • Veo un punto y coma al final de la firma, y ​​ningún pliegue antes de la etiqueta b= final, lo cual es algo poco común: menos probado y posiblemente no se vea como se veía el mensaje cuando se firmó.
  • También veo una versión TLS moderna utilizada con una versión exim antigua ("Todas las versiones de Eximanteriores a la versión 4.96 ahora están obsoletos".). Me pregunto si está utilizando la compilación de sus distribuidores a la que le faltan correcciones relevantes ya aplicadas en sentido ascendente.

Sospecho que esto último está causando su problema, segúneste parcheno siendo aplicado por Debianviejo establehasta ahora. Si es así, debería afectar principalmente a los mensajes pequeños transmitidos vía BDAT sobre TLS.

  1. Actualice a una versión más reciente de exim, lo que posiblemente requiera una actualización de Debian, ya que ya está en backports.o
  2. Leer o presentar informes de errores de Debian, la solución que falta (el enlace va aversión seleccionada lista para ser aplicada en 4.94.2) Sospecho que la culpa puede ser considerada digna de ser retirada, si es que es la culpa aquí -o
  3. deshabilite la compatibilidad con fragmentación (RFC 3030) por completo, si está bien para su caso de uso:vacío chunking_advertise_hosts =no anunciará la disponibilidad de BDAT a nadie, eso debería funcionar, con un costo de rendimiento potencialmente significativo para mensajes grandes.

información relacionada