Authentifier les emails et faciliter la délivrabilité

Actuellement, plusieurs systèmes d’authentification d’émetteurs des emails existent. Sender Policy Framework (SPF), Caller-ID (Microsoft), Sender-ID (convergence de SPF et Caller-ID), DomainKeys (Yahoo) et DKIM (Yahoo et Cisco)… autant de techniques qui poursuivent un objectif : identifier les hôtes autorisés à communiquer des emails pour un domaine donné. Ces systèmes permettent de crédibiliser l’émetteur d’un message. 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.

SPF (Sender Policy Framework)
Cette technique est extraordinairement facile. Il suffit d’extraire le domaine de l’émetteur (« MAIL FROM : » de l’enveloppe du message SMTP et non le champ « From : » de l’entête). Une requête DNS de type TXT s’effectue alors sur le domaine en question. Double objectif : connaître la liste des serveurs de messagerie autorisés à émettre des emails et la comparer avec l’IP émettrice du message. La présence d’un champ TXT (« domaine.tld IN TXT « v=spf1 mx ~all ») suffit pour observer que les serveurs émetteurs d’un domaine correspondent à ses serveurs MX. Pour déterminer aisément une adresse IP, il faut utiliser la syntaxe : « v=spf1 ip4:192.168.0.1/32 ~all ». En revanche, cette technologie perd de son efficacité lorsqu’il s’agit de transfert d’emails. Le serveur émetteur ne sera pas nécessairement le serveur de messagerie de l’émetteur d’origine de l’email.

SenderID
Développée par Microsoft, SenderID est la fusion de SPF et Caller-ID (Microsoft). SenderID 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.

DomainKeys
La technologie développée par Yahoo consiste d’abord à signer tous les emails émis avec une clef privée et, ensuite, à diffuser la clef publique concordante par l’intermédiaire d’une entrée DNS dans le but de donner aux serveurs destinataires la possibilité de contrôler l’authenticité de l’email. Un champ d’en-tête supplémentaire nommé : « DomainKey-Signature » est contenu dans les emails émis. Il précise différents éléments :
– l’algorithme de chiffrement utilisé (a),
– le domaine concerné (d),
– un sélecteur (s) grâce auquel il est possible de travailler avec plusieurs clefs,
– la signature du message elle-même (b).
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=;
« k=rsa; t=y; p=MIGADCBiQKBgQD(…)B; n=A 1024 bit key; »… Pour récupérer les informations nécessaires sur la clef publique du domaine et évaluer la pertinence du mail, on utilisera cette requête DNS de type TXT sur l’entrée du sélecteur déterminé dans l’email (Cf. entrée « s » précédente) : « s1024._domainkey.yahoo.com ».

DKIM
DomainKeys Identified Mail (DKIM) est un draft (au sens IETF) issu de la fusion de DomainKey (Yahoo) et d’Identified Internet Mail (Cisco). Comme DomainKey, DKIM indique comment signer les messages : utiliser un chiffrement asymétrique, publier les clefs publiques via le DNS et confier le processus de signature aux serveurs de messagerie. Une différence entre DomainKey et DKIM subsiste. En effet, auteur, émetteur et signataire ne sont pas nécessairement la même personne. Le champ de signature est auto-signé et la signature peut contenir un délai de validité.

En conclusion, ces diverses technologies d’authentification sont malgré tout limitées car un spammeur a toujours la possibilité de configurer son serveur émetteur et son nom de domaine dans le but de convenir aussi aux préconisations. En outre, ces technologies seraient une solution face au spam à condition que tout le monde les utilise. Or, les hébergeurs, en majorité, n’acceptent pas l’ajout d’un simple champ TXT sur un domaine. L’unique objectif poursuivi par ces technologies : lutter de façon globale contre le spam et le spoofing d’adresses email. Malheureusement, elles n’ont pas pour priorité de préserver les utilisateurs.