Teraoctet a écrit :Certes vous avez raison en partie, mais il y a aussi un danger du fait que ce ne sera pas la teneur du message qui sera vérifié.
Pour les analyses de contenu, il y a des technologies qui existent, certaines d'entre elles assez efficaces. DMARC n'a pas du tout pour objectif de se préoccuper de cela. Une seule chose à la fois
DMARC se préoccupe de quelque chose qui n'est pas forcément très intuitif : beaucoup de gens (y compris des gens par ailleurs très bien informés sur les technologies de l'internet) ont de la peine à comprendre que n'importe qui peut envoyer un message depuis n'importe où en se faisant passer pour n'importe qui.
Je peux très facilement envoyer un email en me faisant passer (par exemple) pour Caméléon. Tout ce dont j'ai besoin c'est de connaitre son adresse email. Pas du tout besoin de son mot de passe. Pas besoin d'un accès à son compte. Sans que ce ne soit un contournement du système ou un abus (cela reste probablement illégal dans quasiment tous les pays, mais le système est parfaitement conçu pour me permettre cela très facilement sans grande connaissance technique - il suffit de savoir ajouter une identité dans Thunderbird). Je peux utiliser une adresse email qui n'existe pas. Je peux envoyer un email depuis mon FAI X en utilisant une adresse @Y, ou inversément. Tout cela est très souvent mal compris voire ignoré (ou au moins les conséquences et surtout l'importance de ce fait).
Tout au long du transfert SMTP du message, il n'y a absolument aucun moyen de vérifier l'authenticité de la source. C'est à la fois une force (cela permet beaucoup de souplesse) et une faiblesse (facile à abuser) intrinsèque du protocole SMTP. Avec ces technologies du type DMARC, on essaye de mettre un emplâtre sur une jambe de bois, en disant "ce message a bien été envoyé par / depuis" (ça c'est le DKIM déjà existant) et "les emails de ce domaine doivent être signés avec cette clé" (ça c'est la marque DMARC). Mais on ne résout pas les problèmes suivants :
- on peut envoyer des emails au nom de domaines qui n'en envoient normalement pas (et ne feront jamais l'effort de configuration requis pour signifier qu'ils n'envoient pas d'emails) ;
- beaucoup de serveurs mal configurés servent de relais ouverts (même s'il y en a de moins en moins, il suffit d'un seul) et laissent entrer n'importe quoi dans le circuit (ces messages seront très facilement authentifiés au nom de n'importe quoi) ;
- on peut envoyer des emails indiquant comme provenance une adresse qui ne nous appartient pas.
Si un seul de ces points n'est pas réglé, toute authentification ne sert à rien, si ce n'est à complexifier encore le système, et donc le rendre plus fragile car plus difficile à configurer correctement. Pour régler le problème de l'authentification, il faudrait revoir le protocole SMTP de fond en comble. Il faudrait surtout un formidable effort de tous (et je dis bien tous : les 200M de domaines et les 4G de machines : une seule exception et c'est fichu). C'est totalement illusoire, infaisable, disproportionné. Il aurait fallut faire ça il y a 20 ans, maintenant c'est trop tard et on ne pourra jamais le rattraper.
caméléon a écrit :Je pense que si autant de multinationales s'investissent dans le projet, ce n'est certainement pas pour que ce soit n'importe quoi...
Pas n'importe quoi : cela fait de la pub (regardez on se préoccupe du problème du spam / phishing) à moindre coût (une petite organisation de ce genre, pour un gros fournisseur genre MS/Yahoo/Google ce n'est vraiment rien). Qu'on ne s'y trompe pas, cela sert à quelque chose : si cela fonctionne, on ne pourra plus envoyer un email @yahoo.com vers gmail.com sans utiliser le serveur SMTP de yahoo. Mais ce sera bien plus gênant pour l'utilisateur légitime qui n'y connait rien que pour le spammeur qui pourra toujours envoyer du spam (certes, plus à gmail.com avec une adresse @yahoo.com, mais qu'est-ce que ça change ?)