← RFC Reference

RFC 6377: DKIM y Listas de Correo

Por Qué Existe Esto

DKIM (RFC 6376) firma encabezados de correo electrónico y contenido del cuerpo con un hash criptográfico. Cualquier modificación después de la firma invalida la firma. Las listas de correo, por diseño, modifican mensajes en tránsito. Esto crea una tensión fundamental:

• DKIM quiere que los mensajes lleguen exactamente como se firmaron.
• Las listas de correo añaden pies de página, anteponen "[list-name]" a los asuntos, añaden encabezados List-*, reescriben direcciones From y envuelven mensajes en resúmenes.

Cuando DMARC entró en juego (requiriendo alineación DKIM o SPF), esta tensión se convirtió en una crisis de entregabilidad. Los mensajes enviados a listas de correo por dominios con políticas DMARC p=reject comenzaron a rebotar para todos los suscriptores de la lista. RFC 6377 fue publicada para documentar el problema y recomendar estrategias de mitigación.

Cómo Funciona

Lo Que Las Listas de Correo Hacen a los Mensajes

Un gestor de lista de correo típico (Mailman, Sympa, LISTSERV, Google Groups) puede realizar cualquier combinación de:

El Flujo de Verificación de Firma

; Paso 1: El autor envía mensaje firmado con DKIM a la lista
From: alice@example.com
To: dev-list@lists.example.org
Subject: Proposed API change
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Paso 2: El software de la lista modifica el mensaje
From: alice@example.com            ← sin cambios (o reescrito)
To: dev-list@lists.example.org
Subject: [dev] Proposed API change  ← modificado: prefijo añadido
List-Id: <dev-list.lists.example.org>  ← añadido
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Cuerpo original + pie de página añadido
The body text here...

--
To unsubscribe, visit https://lists.example.org/unsub  ← añadido

; Paso 3: El servidor del destinatario verifica DKIM
; Resultado: FAIL (Subject y cuerpo fueron modificados después de la firma)

Prácticas Recomendadas para Operadores de Listas

RFC 6377 recomienda que las listas de correo minimicen modificaciones para preservar firmas DKIM:

1. No modifique el encabezado Subject. Evite anteponer [list-name]. Use el encabezado List-Id en su lugar — los clientes de correo pueden filtrar por él.
2. No añada pies de página al cuerpo. Use encapsulación MIME si se requiere contenido de pie de página, o añada el pie de página como una parte MIME separada en lugar de añadirlo al cuerpo existente.
3. Añada una nueva firma DKIM. La lista debe firmar el mensaje modificado con su propia clave DKIM (d=lists.example.org). Esto no repara la firma original, pero proporciona una firma válida del dominio de la lista.
4. Considere la reescritura From para DMARC. Cuando el dominio del remitente original publica p=reject, reescriba el encabezado From al dominio de la lista y coloque el remitente original en Reply-To. Esto se implementa ampliamente como "From munging".

Prácticas Recomendadas para Remitentes

1. Use canonicalización relajada. Firme con c=relaxed/relaxed en lugar de c=simple/simple. La canonicalización relajada tolera cambios menores de espacios en blanco que algún software de lista introduce.
2. Firme solo encabezados esenciales. La etiqueta h= debe cubrir encabezados que le importan (From, Subject, Date, To, Message-ID) pero no encabezados que las listas comúnmente añaden (List-Id, List-Unsubscribe).
3. Use la etiqueta de longitud de cuerpo l= con cuidado. La etiqueta l= limita cuánto del cuerpo se firma, así que los pies de página añadidos no rompen la firma. Sin embargo, esto tiene implicaciones de seguridad — un atacante podría añadir contenido malicioso debajo de la porción firmada.

Detalles Técnicos Clave

La Complicación de DMARC

RFC 6377 antecede a DMARC (RFC 7489), pero los problemas que describe se volvieron mucho más severos una vez que DMARC fue desplegado. Con DMARC p=reject:

; El dominio del autor publica DMARC estricto
_dmarc.example.com TXT "v=DMARC1; p=reject; ..."

; El mensaje va a través de la lista de correo, DKIM se rompe
; El servidor del destinatario verifica DMARC:
;   - SPF: FAIL (remitente de envoltura es lista, no example.com)
;   - DKIM: FAIL (firma rota por modificaciones de la lista)
;   - DMARC: FAIL → REJECT
; Resultado: mensaje rechazado para todos los suscriptores de la lista

Por eso se desarrolló ARC (RFC 8617) — para preservar resultados de autenticación a través de intermediarios como listas de correo.

ARC como la Solución Moderna

El protocolo Authenticated Received Chain (ARC) permite que intermediarios como listas de correo registren los resultados de autenticación original antes de modificar el mensaje. El servidor del destinatario puede entonces usar la cadena ARC para recuperar el pase original de DKIM/SPF, incluso después de que la lista ha roto la firma original.

Estrategias de Reescritura From

La mitigación DMARC más común para listas de correo es la reescritura From:

; Mensaje original
From: Alice Smith <alice@strict-dmarc.com>

; Después de reescritura From de lista
From: Alice Smith via Dev List <dev-list@lists.example.org>
Reply-To: Alice Smith <alice@strict-dmarc.com>

Esto preserva la identidad del remitente original en el texto de visualización y Reply-To mientras hace que el dominio From coincida con la firma DKIM de la lista.

Errores Comunes

• Usar canonicalización c=simple/simple. La canonicalización simple falla en incluso cambios triviales de espacios en blanco. Siempre use c=relaxed/relaxed si sus mensajes pueden pasar a través de listas de correo u otros intermediarios.
• Firmar demasiados encabezados. Incluir encabezados como List-Id o List-Unsubscribe en la etiqueta DKIM h= garantiza fallo cuando una lista añade esos encabezados. Firme solo los encabezados que genera.
• Publicar DMARC p=reject sin considerar listas. Si sus usuarios envían a listas de correo, una política DMARC de rechazo estricta causará que sus mensajes de lista reboten para todos los suscriptores. Considere p=quarantine o asegúrese de que sus usuarios entiendan las implicaciones.
• Operadores de listas que no añaden su propia firma DKIM. Después de modificar un mensaje, la lista debe firmarlo con su propia clave. Sin esto, el mensaje llega sin firma DKIM válida en absoluto.
• Confiar únicamente en longitud de cuerpo l=. Aunque puede preservar firmas más allá de pies de página añadidos, l= ha sido deprecado por muchas guías de mejores prácticas porque permite inyección de contenido debajo del límite firmado.
• No implementar ARC. El software de lista moderno debe implementar ARC para preservar la cadena de autenticación original. Sin ARC, los destinatarios no tienen forma de saber que el mensaje fue autenticado originalmente.

Impacto en la Entregabilidad

• DKIM roto en correo de lista causa rechazos. Con DMARC p=reject, DKIM roto significa mensajes rechazados. Los suscriptores de la lista dejan de recibir correo, y el operador de la lista se inunda de rebotes.
• La reescritura From preserva la entregabilidad pero cambia la identidad del remitente. Los destinatarios ven la dirección de la lista en From, no el remitente original. Esto puede confundir a los usuarios pero es la forma más confiable de asegurar la entrega.
• ARC mejora la entrega para correo de lista. Los principales proveedores (Gmail, Microsoft, Yahoo) honran cadenas ARC. Un sello ARC válido de una lista de renombre puede anular una firma DKIM original rota.
• La reputación de la lista importa. Los servidores receptores evalúan la reputación del dominio de la lista. Una lista bien mantenida con buenas prácticas de envío, firma DKIM apropiada e implementación ARC verá mejores tasas de entrega que una lista mal dirigida.
• Monitoree sus tasas de rebote del tráfico de lista. Si ve picos de rebotes para mensajes enviados a listas de correo, verifique si la lista está modificando mensajes de formas que rompan su firma DKIM, y si implementan ARC.

Related RFCs