¿Cómo debo configurar DMARC (o DKIM) para lidiar con el reenvío de OWA que cambian los cuerpos de correo electrónico?

0

Para mi propio dominio ( mydomain.com , alojado con una G Suite gratuita), he configurado DMARC en modo de prueba:

v=DMARC1; p=none; sp=reject; aspf=s; adkim=s; rua=mailto:[email protected]

He enviado correos electrónicos de prueba a un grupo de direcciones de correo electrónico para tener una idea de si está funcionando bien o no, incluida mi cuenta de Gmail personal y dos direcciones de correo electrónico de lugares de trabajo ( workplace.com y otherworkplace.com ) que usan Exchange / Outlook / OWA que redirijo a mi cuenta personal de Gmail.

DMARC valida para todas excepto una de las dos direcciones del lugar de trabajo, pero solo después de enviarlas a mi cuenta personal de Gmail. Es decir, así es como se ven los encabezados cuando se reciben en mi lugar de trabajo (los saltos de línea cambiados por mí):

Authentication-Results: mx-ext2.workplace.com (amavisd-new);
    dkim=pass (2048-bit key) header.d=mydomain.com
...
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16
    (mx-ext2.workplace.com [IP]); Mon, 22 Jan 2018 21:59:22 +0100 (CET)

Cuando ese mismo correo llega a Gmail, este es el resultado de la autenticación:

ARC-Authentication-Results: i=1; mx.google.com;
   dkim=neutral (body hash did not verify) [email protected]
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of [email protected] designates WorkPlaceIP as
       permitted sender) [email protected];
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com
...
Received-SPF: pass (google.com: domain of [email protected] designates
    WorkPlaceIP as permitted sender) client-ip=WorkPlaceIP;
Authentication-Results: mx.google.com;
   dkim=neutral (body hash did not verify) [email protected]
       header.s=google header.b=PbtXBzel;
   spf=pass (google.com: domain of [email protected] designates WorkPlaceIP as 
       permitted sender) [email protected];
   dmarc=fail (p=NONE sp=REJECT dis=NONE) header.from=mydomain.com

Nota body hash did not verify y dmarc=fail .

El cuerpo del correo electrónico está vacío, excepto por algunas etiquetas HTML. Según lo recibido por Gmail directamente:

Content-Type: multipart/alternative; boundary="94eb2c0d242e6d935c056363b612"

--94eb2c0d242e6d935c056363b612
Content-Type: text/plain; charset="UTF-8"



--94eb2c0d242e6d935c056363b612
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--94eb2c0d242e6d935c056363b612--

Recibido por Gmail a través de otro correo electrónico del lugar de trabajo:

Content-Type: multipart/alternative; boundary="f403045f58c6ca3863056363b147"
X-MS-Exchange-Inbox-Rules-Loop: [email protected]

--f403045f58c6ca3863056363b147
Content-Type: text/plain; charset="UTF-8"



--f403045f58c6ca3863056363b147
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><br></div>

--f403045f58c6ca3863056363b147--

Recibido por Gmail a través del correo electrónico que no es de trabajo:

Content-Type: multipart/alternative;
    boundary="_000_3b36ca239c7e4763redacted_"
MIME-Version: 1.0

--_000_3b36ca239c7e4763redacted_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



--_000_3b36ca239c7e4763redacted_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <[email protected]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body>
<div dir=3D"ltr"><br>
</div>
</body>
</html>

--_000_3b36ca239c7e4763redacted_--

Entonces, workplace.com está cambiando no solo el charset , que no debería ser un gran problema debido a la normalización antes del cálculo de la firma DKIM; pero también el cuerpo mediante la introducción de etiquetas HTML adicionales en los archivos adjuntos. otherworkplace.com no parece estar haciendo eso.

workplace.com parece estar usando OWA 2013 (y, por lo tanto, Exchange Server 2013), mientras que otherworkplace.com parece estar usando una versión más nueva, a juzgar por la interfaz de usuario.

Mi comida para llevar es que

  • Podría pedirle a mi propio personal de TI del lugar de trabajo que vea qué puede estar haciendo su servidor de Exchange (y tal vez haga que lo detengan), pero
  • No puedo controlar todos los servidores de Exchange en el mundo, y hacer que uno haga algo como esto en mi muestra muy pequeña hace que este sea un problema probable en otros lugares, tan pronto como la gente reenvíe un correo electrónico desde la dirección de correo electrónico de Exchange / OWA.

Entonces, ¿cómo debo volver a configurar mis configuraciones de DMARC para obtener la máxima seguridad mientras mantengo una compatibilidad razonablemente alta?

    
pregunta bers 03.02.2018 - 11:11
fuente

1 respuesta

1

TL; DR: Este no es un problema de una configuración DMARC insegura. El fallo de DMARC que ves es debido a una firma DKIM rota. La firma DKIM se rompió debido a un servidor de correo en la ruta que no admite 8BITMIME. La solución es asegurarse de que tiene un correo solo ASCII antes de aplicar la firma DKIM en su servidor. He descrito el problema con más detalle en Rompiendo DKIM por casualidad .

DMARC pasa si pasa SPF o DKIM. Los medios de paso para SPF en el contexto de DMARC de que la dirección IP de origen es la esperada y que el remitente según el sobre SMTP coincide con el remitente según el sobre Rfc822 (es decir, desde el encabezado en el correo). Para DKIM, pasar significa que la firma DKIM es correcta y que el dominio en la firma DKIM coincide con el dominio del encabezado De en el correo.

Si envía los correos directamente desde su dominio, SPF pasará y, por lo tanto, el resultado de DKIM no importa. Si, en cambio, redirige el correo a través de otro servidor, SPF ya no pasará y el resultado de DMARC depende solo de DKIM.

La firma DKIM incluye un hash en el cuerpo del correo. Este hash se crea a partir del código fuente del cuerpo como lo ve el servidor de firmas. Cualquier cambio en el cuerpo durante el transporte invalidará la firma.

Desafortunadamente, dichos cambios pueden ocurrir si un servidor de correo admite la entrada de 8 bits (extensión SMTP 8BITMIME) pero el servidor de correo del siguiente salto no lo admite. En este caso, cualquier dato de 8 bits en el cuerpo debe ser recodificado para que el cuerpo sea solo ASCII. Y esto es lo que sucede en su caso: un servidor de correo en la ruta no es compatible con 8BITMIME y, por lo tanto, el servidor de correo emisor recodificará el correo con Content-Transfer-Encoding: quoted-printable . Pero, esto rompe las firmas DKIM existentes y, por lo tanto, DKIM fallará.

Ya que normalmente no puede controlar qué ruta toma su correo a través de Internet y si todos los servidores de correo en la ruta son compatibles con 8BITMIME, debe asegurarse de que el correo sea ASCII solo antes de que se cree la firma DKIM. Solo de esta manera puede asegurarse de que no se rompa la firma DKIM debido a la recodificación más adelante. La forma más fácil de hacer esto podría ser configurar su propio servidor de correo para que no acepte 8BITMIME y, por lo tanto, obligar a cualquier remitente a recodificar el correo a ASCII solo antes de que sea enviado a su servidor. Para el servidor de correo postfix, la opción relevante es el smtputf8_enable parámetro .

Para obtener más información, consulte Rompiendo DKIM por casualidad donde Describo este problema con más detalle.

    
respondido por el Steffen Ullrich 03.02.2018 - 11:47
fuente

Lea otras preguntas en las etiquetas