path: root/RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt

Titre: RFC 7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
Auteur: 
Date: Tue 11 Oct 2016 02:00:00 +0200
Lien: https://www.bortzmeyer.org/7960.html

Le mécanisme DMARC permet d'indiquer dans le DNS la politique d'un domaine 
concernant l'authentification du courrier. Si je reçois un message prétendant 
venir de ma-banque.example, et qu'il n'est pas authentifié (ni SPF, ni DKIM, ni
autre chose), comment savoir si c'est parce que ma banque est nulle en sécurité
du courrier, ou bien parce que le message est un faux ? DMARC (normalisé dans 
le RFC 7489) permet de répondre à cette question en publiant un enregistrement 
qui indique si le courrier est censé être authentifié ou pas. Comme toutes les 
techniques de sécurité, ce mécanisme est imparfait et il pose notamment des 
problèmes avec les messages indirects. Par exemple, si vous avez une adresse à 
votre ancienne université, alice@univ.example et que le courrier qui lui est 
adressé est automatiquement transmis à votre adresse professionnelle, 
alice@evilcorp.example, comment DMARC va-t-il réagir avec cette indirection ? 
C'est ce qu'explore ce RFC.

Voici la politique DMARC de Gmail. Elle est tolérante (p=none, accepter les 
messages non authentifiés) : 

    
% dig TXT _dmarc.gmail.com
...
;; ->>HEADER<><>- opcode: QUERY, status: NOERROR, id: 59294
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
_dmarc.gmail.com.	600 IN TXT "v=DMARC1; p=none; rua=mailto:mailauth-reports@google.com"
...
Paypal est plus violent, demandant qu'un récepteur rejette les messages 
prétendant venir de Paypal mais pas authentifiés : 

_dmarc.paypal.com.	300 IN TXT "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"

La question de départ de l'administrateur système est « si je mets une 
politique DMARC restrictive (genre p=reject), vais-je perdre des courriers 
légitimes, à cause d'indirections comme les listes de diffusion ? » (section 1 
du RFC). Il est d'autant plus difficile de répondre à cette question que 
l'architecture du courrier électronique est complexe et mal spécifiée (RFC 
5598). Bien des logiciels ne suivent pas les règles, d'autant plus que beaucoup
de ces règles n'ont pas été explicites dès le début. (Un bon exemple : avec un 
.forward, le serveur de courrier doit-il garder l'expéditeur indiqué dans l'
enveloppe du message ? Essayez de trouver un RFC qui spécifie cela !)

La section 2 de notre RFC décrit les causes des problèmes DMARC. Si un message 
est légitime (le destinataire veut le recevoir), et qu'il est en outre 
techniquement correct, un problème, au sens de ce RFC, est quand la politique 
de DMARC (qui peut être de rejet) est appliquée à ce message, parce qu'il a été
transmis indirectement. C'est injuste. Évidemment, si la politique DMARC est 
p=none (ne rien faire), ce n'est pas un vrai problème. Mais un p=reject peut 
être très ennuyeux.

Première cause de problèmes, des différences entre les identificateurs 
utilisés. DMARC n'authentifie pas directement, il dépend de SPF (RFC 7208) et 
DKIM (RFC 6376) pour cela. Ce qui intéresse l'utilisateur, évidemment, c'est le
nom dans le champ From: (RFC 5322) du message. Pour lui, c'est ça l'expéditeur.
Mais DKIM, et surtout SPF, n'ont pas la même conception : ils peuvent utiliser 
d'autres identificateurs. DMARC considère que l'accord (alignment, cf. RFC 
7489, section 3.1) entre les identificateurs authentifiés par SPF et DKIM, et 
le champ From: du message peut être strict ou laxiste. « Strict » indique une 
correspondance parfaite, laxiste se limite à vérifier que le nom de domaine est
le même.

Le principal identificateur utilisé par SPF est celui donné par la commande 
MAIL FROM dans la session SMTP (RFC 5321). C'est la principale cause de 
désaccord : si SPF authentifie cet identificateur et qu'il est différent de 
l'adresse utilisée dans le champ From: de l'en-tête du message, que faire ?

Deuxième cause de problème, le relayage d'un message. Si Bob bob@isp.example 
écrit à alice@univ.example, et qu'elle (ou son administrateur système) a 
demandé un relayage automatique vers alice@evilcorp.example, les serveurs de 
courrier de evilcorp.example verront un message prétendant être de isp.example,
mais transmis par les serveurs de univ.example... SPF sera content ou pas, 
selon la façon exacte dont a été fait le relayage (en préservant le MAIL FROM 
ou pas). DMARC ne sera jamais content car, si le MAIL FROM a été changé 
(reflétant le relais), SPF authentifiera mais il n'y aura plus d'accord entre 
les identificateurs.

Évidemment, si le message est modifié en cours de route, c'est encore pire. SPF
ne protège pas l'intégrité du message, mais DKIM le fait. Mais qui diantre se 
permet de modifier les messages ? Hélas, pas mal de gestionnaires de listes de 
diffusion le font. DKIM a une option (déconseillée... voir la section 8.2 du 
RFC 6376) pour ne signer que le début du message, évitant ainsi que la 
signature soit invalidée par l'ajout, par exemple, d'un paragraphe final. Cela 
ne couvre que le cas des messages simples, sans MIME, où la modification est un
simple ajout à la fin. Autre possibilité de DKIM pour éviter d'invalider les 
signatures en cas de modification du message, le mode relaxed de 
canonicalisation du contenu, qui permet de supporter des modifications 
triviales comme la transformation de N espaces consécutifs en un seul.

Reprenant le vocabulaire du RFC 5598 (relisez-le d'abord !), la section 3 de 
notre RFC liste les différents composants de la messagerie qui peuvent jouer un
rôle dans les transmissions indirectes, et les problèmes qu'elles posent. 
D'abord, le MSA (Message Submission Agent.) C'est la première ligne de 
vérification : il fait respecter les règles d'une organisation (ADMD, 
ADministrative Management Domain). S'il accepte un message où le champ From: du
RFC 5322 n'est pas dans un domaine contrôlé par l'ADMD, il y a des chances que 
DMARC râle par la suite. Le RFC cite plusieurs cas d'usage où cela se produit :
la fonction « envoyer cet article à un ami » de certains sites Web, par 
exemple, puisque le message va partir avec le domaine du lecteur de l'article, 
pas avec celui du site Web. On peut trouver de nombreux autres exemples, comme 
un service de gestion d'agenda qui envoie des courriers de rappel, en utilisant
comme expéditeur l'adresse de l'utilisateur, ce qui est plutôt une bonne chose 
(pour des messages du genre « l'heure de la réunion a changé ») mais peut gêner
DMARC. (Mon exemple préféré est le cas où on a une adresse de courrier mais pas
de moyen de soumettre du courrier via cette organisation, ce qui est fréquent 
avec les adresses de fonction. Par exemple, on est membre d'une organisation 
qui fournit des adresses à ses membres et/ou responsables, ce qui permet de 
recevoir du courrier, mais on n'a pas de MSA pour en envoyer, on doit donc 
utiliser celui d'une autre organisation.)

Et les MTA, eux, quel est leur rôle dans les problèmes DKIM ? S'il change 
l'encodage (par exemple en passant du « 8 bits » à l'abominable 
Quoted-Printable), il va invalider les signatures DKIM (la canonicalisation de 
DKIM ne prévoit pas des transformations aussi radicales, même si elles ne 
modifient pas le message final). Idem si le MTA corrige les en-têtes du message
pour les rendre conformes (une tâche qui relève plutôt du MSA, le MTA devant 
lui, transmettre fidèlement les messages qu'il a choisi d'accepter) : cela sort
également du champ de la canonicalisation DKIM et cela invalide donc les 
éventuelles signatures. Enfin, le changement ou la suppression de certaines 
parties MIME (par exemple l'élision d'un document ZIP attaché, pour des raisons
de protection contre les logiciels malveillants transmis par courrier) va 
évidemment également rendre les signatures invalides.

Et le MDA ? Peut-il casser des choses, également ? Oui, s'il passe les messages
par Sieve (RFC 5228), qui a la possibilité d'ajouter ou de retirer des 
en-têtes, voire de modifier le corps (extension Sieve du RFC 5703). Si les 
tests DMARC sont faits après le passage de Sieve, ou bien si le message est 
ensuite réinjecté dans le système de courrier, des problèmes peuvent se 
produire.

Reste le cas des intermédiaires (mediators). Ce sont les entités qui prennent 
un message, puis le ré-expédient (parfois après modification). Un exemple est 
l'alias. Via une entrée dans /etc/aliases ou bien via un .forward, ou bien via 
le redirect de Sieve, ou encore via encore une autre méthode, un message 
initialement destiné à une adresse est finalement transmis à une autre. C'est 
par exemple courant pour les adresses « ancien élève », que fournissent 
certaines universités, et qui permettent de garder à vie une adresse dans le 
domaine de l'établissement où on a fait ses études. Un certain nombre 
d'associations professionnelles fournissent un service équivalent. En général, 
ces intermédiaires ne cassent pas DKIM (ils ne modifient pas le message) mais, 
selon la façon dont ils redirigent, peuvent invalider l'autorisation SPF.

Un autre exemple d'intermédiaire classique est le gestionnaire de listes de 
diffusion. En plus de rediriger un message (ce qui fait que le message écrit 
par alice@univ.example n'est pas émis par les serveurs de courrier de 
l'université), ces logiciels changent souvent le message, par exemple en 
ajoutant une inutile étiquette [Ma jolie liste] aux sujets des messages, en 
ajoutant un texte à la fin (instructions de désabonnement, pourtant déjà 
possibles avec l'en-tête List-Unsubscribe:), en retirant des pièces jointes, ou
bien (surtout dans les théocraties comme les États-Unis) en remplaçant des gros
mots par des termes plus acceptables.

Toutes ces modifications vont probablement invalider les signatures DKIM (cf. 
RFC 6377) et faire que les messages envoyés par certains participants à la 
liste (ceux qui ont une politique DMARC p=reject) ne seront pas reçus par les 
destinataires qui testent cette politique. (Si un avis de non-remise est 
transmis, le logiciel de gestion de la liste peut en déduire que l'adresse 
n'existe pas, et désabonner d'autorité le destinataire.)

Et les filtres ? Certaines organisations insèrent dans le réseau des 
dispositifs qui vont analyser le courrier, par exemple à la recherche de 
logiciel malveillant. Souvent, ils vont modifier les messages, afin de 
supprimer ces contenus indésirables. Ces modifications vont évidemment 
invalider les signatures. Idem si on change ou supprime des URL contenus dans 
le message et considérés « dangereux ». Même chose avec un système anti-spam 
qui ajouterait un [SPAM] dans le sujet.

En revanche, le courrier reçu d'un serveur secondaire (MX de secours), qui a 
pris le relais pendant une panne du primaire, puis expédié le courrier quand le
primaire remarche, ne pose pas de problèmes. Bien sûr, les tests SPF échoueront
mais, normalement, on ne fait pas ces tests sur le courrier qui vient de son 
propre serveur secondaire.

Bon, voici le tour d'horizon complet de tout ce qui peut marcher mal. Mais que 
faire ? La section 4 du RFC s'attaque aux solutions. Elles sont nombreuses et 
très différentes. Mais attention : DMARC est là pour rejeter des messages 
considérés comme invalides. On peut arranger les choses pour que certains de 
ces messages « passent » mais cela va contre le but de DMARC. Si les messages 
sont de grande valeur (transactions financières, par exemple), il vaut mieux ne
pas chercher de solutions, et simplement se contenter de messages transmis 
directement, ne subissant pas de traitements qui vont invalider SPF ou DKIM.

C'est d'autant plus vrai que l'écosystème du courrier électronique est très 
complexe. On trouve un zillion de logiciels différents, plus ou moins bien 
écrits. Par exemple, des gens utilisent encore Qmail, qui n'a plus eu une seule
mise à jour depuis 1998. Certaines des mesures ou contre-mesures utilisées pour
la sécurité du courrier sont parfaitement légales, mais vont casser tel ou tel 
logiciel qui est utilisé à certains endroits.

Assez d'avertissements, les solutions. D'abord, du côté de l'expéditeur. 
Celui-ci (ou son premier MTA) peut faire des efforts pour améliorer l'accord 
entre les identificateurs. Un logiciel sur info.example qui envoie du courrier 
pour le compte de bob@univ.example peut ainsi décider d'utiliser un en-tête 
From: qui ne posera pas de problème, celui du vrai envoyeur, et de mettre 
l'adresse de Bob dans un Reply-To:. Comme la plupart des solutions présentées 
dans cette section 4, elle est imparfaite (le destinataire peut se demander qui
est cet envoyeur qu'il ne connait pas). Le RFC fournit de nombreux autres 
exemples de désaccord entre identités, qui peuvent être réparés en changeant un
peu le processus d'envoi du message. Comme le disait ma grand-mère, « il y a 
toujours une solution, pour peu que chacun y mette du sien ».

Les envoyeurs peuvent aussi limiter le risque de modifications invalidantes, en
ne signant pas trop d'en-têtes avec DKIM, ou en envoyant des messages 
parfaitement formés (pour éviter aux serveurs ultérieurs la tentation de les 
« réparer »).

Les receveurs peuvent aussi agir mais leurs possibilités sont plus limitées, 
note le RFC.

Entre les expéditeurs et les receveurs, il y a tous les intermédiaires qui 
prennent un message et le ré-expédient. Ce sont souvent eux qui causent le 
problème, et ils sont donc souvent en position de le réparer. Par exemple, ils 
peuvent changer le From: du message pour mettre le leur, ce qui permettrait à 
peu près n'importe quelle modification, et serait plus « franc » (puisque le 
message n'est plus tout à fait l'original, autant changer l'auteur...) 
Évidemment, dans ce cas, assez violent, il faut au minimum garder l'information
sur l'émetteur originel, avec l'en-tête Original-From: (RFC 5703). Le problème 
est que le récepteur humain sera sans doute déconcerté par cet expéditeur 
(d'autant plus qu'Original-From: est peu ou pas affiché).

Comme les modifications invalident les signatures, les ré-expéditeurs 
pourraient les éviter, par exemple en ajoutant des en-têtes au lieu de modifier
les existants, lorsqu'ils veulent ajouter un contenu (du genre « ceci est un 
spam »). Il serait peut-être préférable, dans certains cas, de rejeter les 
messages plutôt que de les modifier, ce qui cassera la vérification de 
signatures plus loin.

Et, en parlant des ré-expéditeurs, les listes de diffusion, pas vraiment 
prévues par DKIM, que faire pour elles ? Le RFC 6377 a déjà traité leur cas. 
Une technique courante est de modifier le champ From: pour mettre l'adresse de 
la liste, réduisant l'auteur original à un commentaire dans cet en-tête (avis 
personnel : je déteste ça). Comme cela rend difficile de répondre en privé au 
vrai auteur d'un message, l'ajout d'un Reply-To: peut aider. Une autre solution
est d'emballer le message original dans une partie MIME message/rfc822. Cette 
partie resterait intact et le message emballant aurait comme expéditeur la 
liste. Mais peu de MUA savent afficher proprement ce genre de messages 
(spécialement dans le monde des mobiles).

Encore plus fasciste, le gestionnaire de liste pourrait interdire l'abonnement 
des gens utilisant une adresse où il y a une politique DMARC autre que p=none. 
(Le RFC oublie de parler du cas où une politique p=reject n'existait pas au 
moment de l'abonnement mais a été rajoutée après.)

Enfin, il existe aussi des solutions qui sont encore en cours de discussion à 
l'IETF, et dont le RFC décourage l'usage dans un environnement de production. 
Ce sont entre autres des extensions au modèle du RFC 7601 pour créer une chaîne
d'authentification où chaque acteur important signerait le message en route. 
Ou, plus radical, des mécanismes stockant l'état initial d'un message avant 
transformation, pour pouvoir retrouver cet état original et vérifier la 
signature.

Bref, le problème n'est pas résolu...