En los avances para mejorar los correos eletrónicos y hacerlos más resistentes a ataques como spam, phishing, etc., se inventó una tecnología llamada DMARC, que en conjunto con SPF y DKIM permite cuando alguien envia un correo, se firme digitalmente tanto el contenido como los headers (From, Date, etc), para certificar su origen y evitar su modificacion, incluyendo esta firma digital en uno de los encabezados del correo. Ahora, esa firma digital tiene quer haber sido con la llave digital de la organización que está originando el correo, entonces es muy simple para cualquiera que recibe un correo detectar si alguien se quiere hacer pasar por un banco o Paypal, porque no va a poder firmarlo como corresponde.
DMARC además define la forma en que cada originador de correo desea que se manejen sus firmas, explicitando su política de uso. La más simple de todas (además de no usar DMARC para nada) es la “none”, que quiere decir que si una firma no valida no se tome ninguna acción especial, salvo guardar algún registro en un log. Esta política tiene sentido en un deployment inicial y parcial, cuando no se está seguro de que todos los correos originados desde todas partes van firmados correctamente. Pueden existir muchos subsistemas que originan correo en forma automática, usuarios de la organización que envían correos desde su casa usando relays externos, o bien servicios de webmail, etc.
La segunda política de DMARC es “quarantine”, que declara que los correos mal firmados se deben marcar y dejar en “spam”, además de reportarlo en el momento de su recepción SMTP.
Por último, la etapa más extrema es “reject”, en que se declara que al recibir un correo mal firmado se debe rechazar a nivel de SMTP, con un código de error al originador.
Toda esta tecnología parece la solución definitiva a los problemas de correo, diseñándose para ser retrocompatible con el correo antiguo, salvo un detalle: las listas de correo. Una lista de correo normalmente toma el correo enviado a la lista y lo redistribuye a todos los suscritos, modificando el correo original, pero manteniendo el remitente. Por ejemplo se modifica el Subject para poner un “prefijo de lista”, se ponen headers extra como List-Id, List-Archive y otros, cambiando el Reply-To, etc. Todas estas modificaciones ocasionan que se invaliden las firmas DMARC, y dependiendo de la política declarada por el originador del correo, un validador estaría en la obligación de rechazar un correo que fue modificado por una lista.
Desde hace unos meses los más grandes proveedores de correo como Gmail, Yahoo y empresas como PayPal empezaron a utilizar dmarc en modo reject, rompiendo el comportamiento de las listas de correo.
Hubo mucha discusión cuando esto empezó a pasar. No es una tecnología que a todos les guste y hubo un movimiento que llamó a “boicotear” a los proveedores que usaban DMARC impidiéndoles inscribirse en ciertas listas de correo y advirtiéndoles que si lo hacían dejarían de recibir correos, pero finalmente los creadores de software de listas comenzaron a implementar soluciones de fondo. Mailman a partir de la version 2.1.18 permiten que el administrador de una lista decida qué hacer. Una opción es no hacer nada, y que los integrantes de una lista que pertenecen a una organización validadora como @gmail o @yahoo correrán el riesgo de no recibir los correos si son originados desde otros correos con DMARC estricto en reject.
Una segunda opción que entrega Mailman es reescribir el From y Reply-to (“mungle”) como originada en la lista, eliminando los headers DMARC originales. Como el dominio de la lista no es necesario que utilice DMARC, entonces un validador ignorará la validación y será despachado.
Por último una tercera opción es re-empaquetar (“wrap”) el correo original como un adjunto dentro de un nuevo correo originado por la lista, que permite que no se invalide DMARC y que los lectores de correo o servicios puedan validar el DMARC interno del correo adjunto, manteniendo la protección contra modificaciones al correo original.
Si usted hospeda o administra listas de correo en Mailman, preocúpese de actualizarlo a la última versión y verificar en las opciones “Privacy” -> “Sender Filters” qué van a hacer con DMARC. Recomiendo usar el “wrap message” sobre el “mungle”, porque permite mantener el correo original íntegro y algún receptor podría igual validarlo desempaquetándolo. Mailman es suficientemente inteligente como para que los correos que no utilizan DMARC se siguen enviando como siempre, con el From del usuario, pero los que sí se adjuntan y se empaquetan con el From de la lista.