Pourquoi le transfert d'e-mails casse SPF : rôle de SRS et ARC

Le transfert d'e-mails casse SPF parce que SPF compare l'adresse IP qui se connecte avec l'enregistrement du domaine de l'expéditeur d'enveloppe, et qu'un relais de transfert ordinaire change la première sans toucher au second. Le destinataire final voit le serveur du relais livrer un message « de » example.com, ne trouve ce serveur nulle part dans l'enregistrement SPF de example.com, et renvoie fail. Rien n'est mal configuré, ni d'un côté ni de l'autre : SPF est conçu ainsi. Que le message réussisse malgré tout DMARC dépend presque entièrement de DKIM.

Ce guide suit un message à travers un relais de transfert et montre ce que SRS, DKIM et ARC changent chacun.

Ce que SPF vérifie réellement

Une livraison SMTP comporte deux identités d'expéditeur :

• l'expéditeur d'enveloppe, donné dans la commande MAIL FROM et consigné ensuite comme Return-Path. C'est là que vont les rebonds.
• l'en-tête From, que le client de messagerie du destinataire affiche.

SPF (RFC 7208) ne connaît que le premier. Le destinataire prend le domaine de l'expéditeur d'enveloppe (ou, à défaut, le nom HELO, par exemple quand l'expéditeur d'enveloppe est vide, comme dans les rebonds), récupère son enregistrement SPF et demande : l'adresse IP qui se connecte à moi en ce moment y figure-t-elle ?

Livraison directe :

alice@example.com  ->  mail server of example.com (192.0.2.10)  ->  receiver
MAIL FROM:<alice@example.com>      connecting IP 192.0.2.10      spf=pass

Ce que fait un relais de transfert ordinaire

Un relais de transfert ordinaire, c'est un alias, un fichier .forward, une règle « transférer tout le courrier vers », ou le transfert d'e-mails livré avec un domaine chez de nombreux bureaux d'enregistrement. Il accepte le message et le renvoie vers une autre adresse en conservant l'expéditeur d'enveloppe d'origine, pour que les rebonds reviennent à l'auteur.

alice@example.com  ->  forwarder (203.0.113.7)  ->  bob's real mailbox
MAIL FROM:<alice@example.com>      connecting IP 203.0.113.7     spf=fail

203.0.113.7 appartient au relais. example.com n'en a jamais entendu parler et ne devrait pas la lister : un expéditeur ne peut pas connaître toutes les adresses vers lesquelles ses destinataires transfèrent leur courrier.

SRS : réparer SPF pour le relais

Le Sender Rewriting Scheme réécrit l'expéditeur d'enveloppe en une adresse du propre domaine du relais avant de renvoyer le message :

MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.example>

HHH est un court hachage, TT un horodatage, et le domaine et la partie locale d'origine sont conservés pour qu'un rebond envoyé à cette adresse puisse être décodé et transmis à alice@example.com. Le hachage empêche des tiers d'abuser du relais comme relais de rebonds.

Le destinataire vérifie désormais l'enregistrement SPF de forwarder.example, qui, lui, liste bien 203.0.113.7. SPF passe.

Deux choses à savoir sur SRS :

• Ce n'est pas une norme de l'IETF. C'est une spécification communautaire issue du projet SPF, et les implémentations diffèrent dans le détail.
• Il répare SPF, pas DMARC. Après la réécriture, le domaine authentifié par SPF est forwarder.example, tandis que l'en-tête From indique toujours example.com. DMARC exige que le domaine authentifié soit aligné avec le domaine du From, donc la branche SPF de DMARC échoue toujours. Elle échoue seulement en silence plutôt que bruyamment.

DKIM : la partie qui survit

Une signature DKIM fait partie du message, pas de la connexion. Elle couvre le corps et un ensemble choisi d'en-têtes, et se vérifie avec une clé publique publiée dans le DNS du signataire. Un relais qui transmet le message sans le modifier laisse la signature valide, quelle que soit l'adresse IP depuis laquelle il se connecte. Si le domaine signataire (d=) est aligné avec le domaine du From, DMARC passe par la seule branche DKIM.

DKIM casse quand une partie signée change :

• une liste de diffusion ajoute [nom-de-la-liste] au sujet ou un pied de page au corps
• une passerelle réécrit le corps, par exemple en ajoutant une clause de non-responsabilité ou en réécrivant les liens
• un système ré-encode le message d'une façon que la canonicalisation de la signature ne tolère pas

Un transfert ordinaire ne fait rien de tout cela. Les listes de diffusion font la première chose en permanence.

Tableau des scénarios

Supposons que example.com publie SPF, signe avec d=example.com et a p=reject.

Scénario	Résultat SPF	Résultat DKIM	Résultat DMARC
Livraison directe	pass, aligné	pass, aligné	pass
Transfert ordinaire, message intact	fail	pass, aligné	pass (via DKIM)
Transfert ordinaire, expéditeur sans DKIM	fail	none	fail
Transfert avec SRS, message intact	pass pour le relais, non aligné	pass, aligné	pass (via DKIM)
Transfert avec SRS, expéditeur sans DKIM	pass pour le relais, non aligné	none	fail
Liste de diffusion qui modifie le sujet ou le corps	pass pour la liste, non aligné	fail (cassé)	fail, sauf si la liste réécrit le From
Idem, avec une chaîne ARC que le destinataire accepte	comme ci-dessus	comme ci-dessus	fail, mais le destinataire peut passer outre localement

Les deuxième et cinquième lignes sont celles qui comptent en pratique : SRS ne peut pas sauver un expéditeur sans DKIM aligné, et un expéditeur avec DKIM aligné n'a pas besoin de SRS pour que DMARC passe.

ARC : transmettre ce que l'intermédiaire a vu

Authenticated Received Chain (RFC 8617, statut expérimental) s'attaque aux lignes « liste de diffusion ». Un intermédiaire qui traite le message consigne les résultats d'authentification qu'il a observés à l'arrivée et signe ce relevé. Chaque saut ajoute un jeu de trois en-têtes avec un numéro d'instance :

ARC-Authentication-Results: i=1; lists.example.org;
   spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com;
   dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc1; …
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; …

Un second intermédiaire ajoute i=2, et ainsi de suite. Le destinataire final peut valider la chaîne et constater que le message réussissait DMARC à son arrivée chez lists.example.org, avant que la liste ne le modifie.

Le mot important est peut. ARC dit au destinataire ce qu'un scelleur affirme avoir vu. Croire ou non ce scelleur relève de la politique locale : les destinataires PEUVENT honorer une chaîne venant d'un intermédiaire en qui ils ont confiance, et sont libres de l'ignorer. ARC n'est pas une garantie de livraison.

À cause de cette incertitude, les listes de diffusion adoptent souvent une approche plus radicale pour les expéditeurs dont le domaine applique DMARC : elles réécrivent l'en-tête From en une adresse du domaine de la liste, pour que le message soit aligné avec le SPF et le DKIM de la liste elle-même.

Lire l'en-tête Authentication-Results

Envoyez un message à travers le relais vers une boîte que vous contrôlez, ouvrez la source du message et repérez l'en-tête Authentication-Results ajouté par le destinataire final (le plus haut) :

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=forwarder.example;
   dkim=pass header.d=example.com header.s=s2026;
   dmarc=pass header.from=example.com;
   arc=pass
Return-Path: <SRS0=a1b2=XY=example.com=alice@forwarder.example>

Champ	Ce qu'il vous apprend
smtp.mailfrom=	Le domaine contre lequel SPF a été vérifié. Si c'est celui du relais, SRS est en service.
spf=	Le résultat pour ce domaine et l'IP qui se connecte. fail avec le domaine d'origine signifie un relais ordinaire.
header.d=	Le domaine dont la signature DKIM a été validée. Comparez-le à header.from.
dmarc=	Le verdict après alignement. C'est celui qui décide.
arc=	Si une chaîne ARC était présente et a été validée.

Si vous préférez coller les en-têtes plutôt que les lire, l'analyseur d'en-têtes e-mail les décompose.

Conseils aux expéditeurs

1. Signez tout avec DKIM, aligné sur votre domaine From. Chaque service qui envoie en votre nom : fournisseur de messagerie, outil de newsletters, facturation, support. C'est ce qui permet à votre courrier de survivre au transfert. SPF seul n'y parviendra jamais.
2. N'ajoutez pas les adresses IP des relais à votre enregistrement SPF. Vous ne pouvez pas toutes les connaître, elles changent, et chaque include ajouté compte dans la limite des 10 requêtes.
3. Passez à p=reject seulement quand les rapports DMARC montrent un alignement DKIM pour toutes vos sources légitimes. Un domaine en p=reject qui ne compte que sur SPF verra son courrier transféré refusé.
4. Attendez-vous à un petit reliquat d'échecs venant des listes de diffusion. L'ordre de déploiement décrit dans MX, SPF, DKIM et DMARC expliqués en tient compte.

Conseils si vous transférez du courrier

• Utilisez un relais qui implémente SRS, et idéalement le scellement ARC. Sans SRS, chaque message venant d'un domaine en -all arrive avec spf=fail.
• Envisagez la relève plutôt que le transfert. Si la boîte de destination peut collecter le courrier de l'ancien compte en POP ou IMAP, aucun renvoi n'a lieu et aucune authentification n'est perturbée.
• Ne transférez pas le spam. Le destinataire final voit l'IP de votre relais le livrer et le retient contre le relais. Filtrez avant de transférer.
• Envisagez d'héberger la boîte au lieu de la transférer. Un domaine qui ne fait que transférer vers une boîte gratuite est la configuration fragile que l'on retrouve dans la plupart des signalements « mon courrier a disparu » : voir la liste de contrôle DNS pour les e-mails qui arrivent en spam.

Erreurs fréquentes

• Prendre spf=fail sur un message transféré pour une preuve d'usurpation. Regardez dkim= et dmarc= avant de trancher.
• Croire que SRS répare DMARC. Il répare SPF pour le domaine du relais ; l'alignement, lui, reste perdu.
• Ajouter des entrées include: pour les relais de vos destinataires dans votre propre enregistrement SPF.
• Passer à p=reject avec une authentification SPF seule parce que « SPF passe dans tous nos tests ». Les tests incluent rarement un relais.
• Supposer qu'ARC force le destinataire à accepter. C'est un élément de preuve offert à un destinataire qui peut faire confiance au scelleur, ou non.
• Ajouter une clause de non-responsabilité sur une passerelle sortante après la signature DKIM. Cela casse votre propre signature avant même que le message ne parte.

Vérifiez avec OrbitProbe

Le vérificateur SPF d'OrbitProbe affiche l'enregistrement SPF publié par un domaine et signale les problèmes structurels habituels : plusieurs enregistrements, +all, un mécanisme all manquant, trop de requêtes DNS. Pour un problème de transfert, vérifiez deux noms : le domaine de l'expéditeur d'origine (se termine-t-il par -all, ce qui fait échouer durement le transfert ordinaire ?) et le domaine du relais (a-t-il seulement un enregistrement valide, pour que le courrier réécrit par SRS puisse passer ?). Une vérification DNS lit la politique publiée. Ce qui est arrivé à un message précis n'est consigné que dans l'en-tête Authentication-Results de ce message, alors lisez les deux.