L’email, tel que l’on le connaît aujourd’hui, existe depuis le début des années 1980, l’époque où le protocole SMTP (Simple Mail Transfert Protocol) a commencé à être largement utilisé pour transférer des messages électroniques vers les serveurs de messagerie électroniques.

Le SMTP est un protocole assez simple (comme son nom l’indique, en français « Protocole simple de transfert de courrier ») : on commence par spécifier l’expéditeur du message, ensuite le ou les destinataires, et enfin, après avoir vérifié leur existence, le corps du message est transféré. Ce protocole, étant donc vieux et simple, comporte des failles permettant d’usurper l’identité de l’expéditeur.



Dans la dure lutte contre le Spam et le Phishing, il s’est avéré très important de mettre en place un moyen d’identifier les véritables expéditeurs de courriels. Seulement, comme souvent en informatique, quand il a fallu définir une norme, les géants de l’industrie ont immédiatement tiré la couverture à eux en définissant leur propre vision de la chose. C’est ainsi que les différentes normes d’authentification d’émetteurs des emails ont vu le jour…

Actuellement, 3 systèmes d’authentification majeurs existent : Sender Policy Framework (SPF), Sender-ID et DKIM… autant de techniques qui poursuivent un objectif : identifier les hôtes autorisés à communiquer des emails pour un domaine donné. L’authentification de l’expéditeur se fait au niveau du serveur de messagerie traitant les emails entrants et est intégrée dans les techniques de filtrage. Avec pour principe l’ajout d’un champ de type TXT sur le domaine émetteur, le système définit la liste des serveurs émetteurs autorisés ou publie une clef publique qui servira à certifier la légitimité de l’émetteur d’un email.



Sender Policy Framework (SPF)
La norme SPF est utilisée par Google et AOL. Elle permet de publier, sur les serveurs DNS gérant le domaine de l’adresse expéditeur, un enregistrement (de type SPF ou de type TXT) indiquant quelles adresses IP sont autorisées ou interdites à envoyer du courrier pour le domaine considéré. L’identité testée par SPF est celle indiquée par la commande « MAIL FROM : » de l’enveloppe du message SMTP et non le champ « From : » de l’entête.

Exemples (source AltoSpam)

1.) domaine.tld IN TXT « v=spf1 mx ~all »

2.) domaine.tld IN TXT « v=spf1 ip4:192.168.0.1/32 ~all »

Dans le premier cas, la présence du champ TXT indique que les serveurs émetteurs d’un domaine correspondent à ses serveurs MX, dans le second que seules peuvent envoyer du courrier pour ce compte domaine les machines avec l’adresse IP 192.168.0.1/32. Le reste de l’Internet (all) n’a probablement (le tilde veut dire « sans doute non ») pas le droit. Un serveur de courrier participant à SPF peut donc rejeter un mail provenant d’autres blocs d’adresses que ceux qui sont indiqués.

En revanche, cette technologie perd de son efficacité lorsqu’il s’agit de transfert d’emails (forwarding). SPF ne garantit en effet pas que la partie locale de l’adresse de courrier électronique (à gauche du signe @) est authentique.

Sender-ID
La norme Sender ID est développée et proposée par Microsoft et donc utilisée pour le filtrage par Hotmail et WindowsMail. Il s’agit d’une convergence de SPF et Caller-ID (Microsoft), son principe est donc globalement identique à celui du SPF. Cependant, ce système parfait SPF en précisant que la vérification de l’adresse de l’enveloppe SMTP ne suffit pas. En effet, le champ « From : » de l’entête doit également être examiné.

SenderID apporte la notion de PRA (Purported Responsible Address) capable de définir l’adresse email responsable de l’envoi du message. Dans certains cas, comme l’emailing, adresse d’émission de l’email et responsable de l’émission peuvent être distincts. Et avec l’ajout de la commande « SUBMITTER » au protocole SMTP proposé par ce système, le forwarding de messages n’est plus un problème.

Exemple (source Wikipedia)

aol.com. 300 IN TXT « spf2.0/pra ip4:152.163.225.0/24 … ptr:mx.aol.com ~all »

La présence du champ TXT indique que seules peuvent envoyer du courrier pour le compte d’aol.com (en utilisant l’algorithme PRA) les machines du réseau 152.163.225.0/24 ainsi que les machines dont le nom se termine par « mx.aol.com ».

Notons néanmoins que Sender ID a notamment été critiqué pour le brevet que possède la société Microsoft sur l’algorithme PRA, brevet qui pourrait permettre à cette dernière de bloquer les mises en œuvre de Sender ID qui ne lui plaisent pas. Le problème de la généralisation de l’utilisation de cette norme est donc très politique.

DKIM (DomainKeys Identified Mail)
La norme DKIM est issue de la fusion de DomainKey (Yahoo!) et d’Identified Internet Mail (Cisco). A ce titre elle est utilisée par Yahoo! Mail pour sa procédure de filtrage ainsi que par AOL et Google. Cette technologie a pour objectif d’ajouter une signature unique propre à l’expéditeur à tous les messages qu’il diffuse. En effet, DKIM fonctionne par signature cryptographique du corps du message et d’une partie de ses en-têtes. Une signature DKIM vérifie donc l’authenticité du domaine expéditeur et garantit l’intégrité du message.

DKIM spécifie comment signer les messages en utilisant un chiffrement asymétrique, en publiant les clefs publiques via le DNS et en confiant le processus de signature aux serveurs de messagerie. Un domaine peut en outre annoncer dans le DNS qu’il signe tous ses messages (et donc qu’un message sans signature est suspect) ou bien qu’il ne signe pas systématiquement et qu’il faut donc être indulgent à la vérification.

Exemple (source AltoSpam)

La clef publique DKIM du domaine yahoo.com au format 1024 bits est stockée dans le champ TXT de l’entrée

« s1024._domainkey.yahoo.com »: « k=rsa; t=y; p=MIGADCBiQKBgQD(…)B; n=A 1024 bit key; »

Cette clef permet de vérifier l’authenticité de la signature présente dans l’email (générée grâce à la clef privée installée sur le serveur émetteur). Exemple de signature présente dans un email :

« DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Message-ID; b=cuXRK(…)vazo=; ».

De cette manière, on s’assure que le mail provient bien du serveur émetteur annoncé et que le domaine émetteur n’est pas usurpé.

En conclusion…
Vous l’aurez compris, le but de l’authentification est de crédibiliser l’émetteur d’un message en lui permettant de prouver qu’il est celui qu’il prétend et ainsi éviter de voir son identité usurpée. Dans le cadre de l’Email Marketing, les annonceurs légitiment ainsi leurs communications par courriel et optimisent la délivrabilité de leurs campagnes.

Malheureusement, malgré la mise en place de ces technologies la délivrabilité n’est pas garantie. L’utilisation de ces différentes méthodes permet aux courriels de ne pas être assimilés à du phishing, mais cela ne garantit pas aux FAI que le contenu du message soit de confiance et n’assure non plus une bonne réputation. Il y a encore beaucoup de points à travailler tels que la qualité de la base de données, la qualité du message et de son contenu, le développement de l’engagement des contacts, etc. C’est réellement un travail de tous les jours.