Mail

Ce document vise à répertorier le debug des technos du mail, pas à être exhaustif.

Pour les éléments de compréhensions, on pourra se référer à ce document pour le mail et ce document pour SPF/DKIM/DMARC/ARC.

Contexte

origan → /etc/sympa → sympa.conf : défauts qui peuvent être écrasés par X/robot.conf (X = nom de domaine de la mailing)

Là il y a des paramètres DKIM par exemple pour viecoop.lanef.com.

Il y a plusieurs cas :

• mails vers une ML : passage par Sympa puis relai-smtp
• mails vers viecoop.lanef.com qui n'est pas une mailing liste : envoi vers Galae.

Se posent plusieurs questions autour des méthodes d'authentification des mails.

SPF

En général on fait attention à SPF quand on relaie un message au nom d'un domain qu'on ne contrôle pas; or avec Sympa l'intégralité des mails qui sortent du serveur ont un domaine que l'on contrôle, avec un enregistrement SPF qui nous autorise à émettre pour eux.

Il n'y a donc pas d'intérêt à faire du SRS et il ne devrait pas avoir de soucis.

DKIM

Relai-Smtp, quand il est utilisé, agit comme un serveur de soumission, et signe lui-même les mails avec la clé DKIM configurée.

Pour les domaines pouvant sortir ailleurs, on active DKIM sur Sympa au niveau du domaine.

💡 Relai-Smtp écrase les signatures DKIM de Sympa, donc ce n'est pas un problème s'il y a de l'overlap.

⚠️ Les paramètres ne sont pas homogènes d'une version à l'autre, et configurer DKIM même en le désactivant explicitement l'activera quand même.

DMARC

DMARC, en plus de faire le point sur SPF et DKIM, ne fait que valider l'alignement du domaine entre l'enveloppe, le domaine de la signature et le header.

Peu importe qui émis la signature DKIM, donc, pourvu qu'il ait une clé privée valide.

ARC

ARC peut être activé via Sympa, et de façon plus intéressante dans une future version où il pourra également faire la vérification entrante ARC/DKIM (et sera donc en mesure de construire de construire les headers d'authentification sans un outil tiers).

ARC permet en théorie de détecter les usurpations de façon plus robuste. En effet, il est aujourd'hui admis que rejeter un mail car SPF est cassé n'a aucun sens à cause du forwarding.

Pour autant, ARC retient l'authentification du mail sur toute la chaîne, donc :

• Si SPF est cassé lors de l'envoi du mail, mais forwardé quand même;
• Si la chaîne de headers ARC est valide et les intermédiaires de confiance;

Alors le serveur final peut avoir une grande confiance dans le fait qu'SPF était cassé dès le début, et rejeter le mail.

C'est ce semble faire Galae, intentionnellement ou non (?), cependant les RFC ARC ne recommendent de l'utiliser que lorsque DMARC ne passe pas, par exemple. Or pour nous, DMARC passe notamment via DKIM.

On désactive donc ARC.

Mais ça ne suffit pas car il suffit qu'une seule signature avant nous soit cassée pour que la vérification échoue en bout de chaîne.

On supprime donc l'intégralité des headers ARC avec Postfix.

/etc/postfix/header_checks:

/^ARC-Seal:/ IGNORE
/^ARC-Message-Signature:/ IGNORE
/^ARC-Authentication-Results:/ IGNORE

puis postmap, puis dans main.cf:

smtp_header_checks = regexp:/etc/postfix/header_checks

Ce qui aura pour effet de supprimer les lignes comportant ces headers.