ARCHIVÉE — Nouvelles technologies

Vue d'ensemble de la technologie anti-pourriel
Groupe de travail sur le pourriel
Sous-groupe sur la gestion des technologies et des réseaux, Services techniques d'homologation et de télécommunications
Mai 2005

---

4.1 Authentification du domaine
4.2 Protocole Internet (IP) version 6
4.3 Présence

---

4.1 Authentification du domaine

Les technologies d'authentification du domaine sont utilisées pour s'assurer que le domaine de l'expéditeur n'est pas usurpé. En raison de l'ouverture du protocole SMTP, un expéditeur peut usurper l'identité d'un autre expéditeur. Cette lacune du protocole est souvent exploitée par les polluposteurs. Pour éviter les poursuites judiciaires ou l'arrêt du service d'un FSI, les polluposteurs doivent rester anonymes. Les améliorations du protocole sont donc nécessaires pour assurer l'authenticité de l'adresse d'un expéditeur. La section qui suit traite de ces améliorations.

Les principaux artisans de ces technologies sont AOL pour Sender Policy Framework (SPF), Microsoft pour Sender ID, Yahoo! pour Domain Keys et Cisco Systems pour Identified Internet Mail (IIM).

4.1.1 Sender Policy Framework

SPF compte une grande base d'utilisateurs et est devenue largement accepté en tant que méthode courante d'authentification des expéditeurs. Des technologies similaires qui ont rivalisé avec SPF incluent Reverse Mail Exchange (RMX) et le protocole DMP (Designated Mailers Protocol). Toutes ces solutions utilisent le DNS pour authentifier les adresses des expéditeurs. Le but principal de la mise en place d'un plan d'authentification de l'expéditeur consiste à disposer d'une solution unique pour assurer une adoption à l'échelle mondiale.

Le besoin d'une norme unique mondiale est à l'origine de nombreux débats dans le milieu de la conception des technologies. L'Internet Research Task Force formait au départ un groupe de recherche sur les technologies anti-pourriel. Ce groupe a soumis plusieurs spécifications provisoires à l'Internet Engineering Task Force (IETF). Une fois que la nécessité de disposer d'une solution unique est devenue flagrante, le groupe de travail MARID a été formé et chargé d'élaborer la version suivante de SPF. Toutefois, ses membres n'ont pu s'entendre sur une méthode commune. Par conséquent, les activités du groupe de travail MARID ont pris fin le 22 septembre 2004⁹. Tout au long des débats, la version SPF 1 ou SPF Classic a été de mieux en mieux acceptée par les FSI en tant que méthode permettant de valider la source des messages.

SPF authentifie le domaine d'un expéditeur au moyen d'une recherche inverse dans un enregistrement MX dans le DNS. Le processus est similaire à celui qui utilise les enregistrements MX pour localiser le serveur de courriel d'un expéditeur. Un serveur de courrier récepteur utilise le domaine d'un expéditeur et fait une requête à propos de ce domaine. La réponse à cette requête renferme les adresses auxquelles le serveur est autorisé à envoyer le message. Le MTA récepteur utilise l'enregistrement SPF pour vérifier si l'adresse d'envoi est une source de courrier valide. S'il ne peut vérifier l'adresse, on suppose que l'expéditeur a usurpé l'adresse, et le message peut être filtré sur cette base.

On sait que SPF pose problème quand un MTA transmet un courrier au nom d'un destinataire. Le domaine de l'expéditeur original doit passer sans aucune modification, de sorte que la vérification n'échoue pas. SRS (Sender Rewriting Scheme) est l'une des solutions au problème de transmission pour SPF; l'autre est Sender ID.

On craint que les polluposteurs puissent encore avoir recours aux enregistrements SPF pour des domaines pouvant être utilisés pour l'envoi automatique de pourriels. En pareil cas, le pourriel pourra parvenir au destinataire en l'absence d'autres méthodes, mais la source du message demeure connue. Si l'on connaît la source du message, on peut avoir recours à des méthodes comme l'établissement de listes noires, la notification du registraire et les poursuites.

Les domaines jetables peuvent permettre aux polluposteurs d'envoyer des messages authentifiés et d'ensuite simplement enregistrer un nouveau domaine une fois que l'utilisation malveillante a été mise au jour. Ce problème n'a pas encore été réglé, mais une solution partielle peut être l'accréditation du domaine.

4.1.2 Identification de l'expéditeur

Au départ, Microsoft a mis au point le projet Caller ID for E-mail pour authentifier l'expéditeur comme solution de rechange au SPF. Une fois qu'on a compris qu'il fallait une solution globale, les concepteurs de la technologie, avec l'aide du groupe de travail MARID, ont essayé de fusionner les deux projets pour créer une nouvelle spécification provisoire appelée Sender ID.

Le projet Sender ID a une rétrocompatibilité avec SPF. Quand un expéditeur reçoit un message, l'adresse « De » de l'expéditeur est vérifiée en contrôlant un enregistrement DNS pour ce domaine. L'information contenue dans cet enregistrement est utilisée pour s'assurer que le message de l'expéditeur provenait du domaine présumé. Pour régler le problème de transmission relevé dans la version SPF 1 (SPFv1), on a introduit dans la version provisoire l'adresse du responsable prétendu (PRA).

L'algorithme PRA dans la version provisoire Sender ID renfermait les conditions de la licence visant la propriété intellectuelle détenue par Microsoft. Certains projets de source ouverte ne pouvaient accepter les modalités et étaient donc incapables de soutenir cette version. Comme on ne pouvait obtenir un consentement unanime pour le projet Sender ID, les efforts du groupe de travail MARID ont pris fin¹⁰. En novembre 2004, Microsoft a présenté le projet Sender ID lors de l'Email Authentication Summit tenu par la Federal Trade Commission des États-Unis. Le projet a maintenant été approuvé par AOL, qui a appuyé SPF au terme des travaux du groupe de travail MARID.

4.1.3 Domain Keys (clefs de domaine)

Domain Keys utilise une méthode différente de Sender ID et SPF pour authentifier les expéditeurs. Pour s'assurer que les utilisateurs peuvent se fier à l'authenticité d'un expéditeur, Domain Keys signe tous les messages au moyen d'une clé cryptographique propre au domaine.

La méthode Domain Keys a recours à un algorithme de clés asymétrique avec des clés publiques et privées. Le MTA expéditeur a besoin d'un MTA activé par clé de domaine, qui utilise une clé privée pour signer le message. Sur réception du message signé, le MTA récepteur examine le domaine de l'expéditeur pour trouver la clé publique de ce domaine. Celle-ci est ensuite utilisée pour vérifier si la signature de l'expéditeur est valide. Si celle-ci s'avère valide, le destinataire peut être certain du domaine de l'expéditeur. Comme pour d'autres protocoles d'authentification du domaine, seuls les MTA doivent prendre en charge la technologie.

4.1.4 Identified Internet Mail

La solution proposée Identified Internet Mail (IIM) est semblable à l'approche Domain Keys, mais ne dépend pas du DNS pour fournir les clés. Elle utilise plutôt un serveur d'enregistrement des clés qui est relié par le DNS. Ce serveur permet l'authentification des ordinateurs hôtes ou de groupes d'ordinateurs hôtes, et non pas simplement du domaine. Le protocole IIM est maintenant rédigé, en même temps que Domain Keys, par le groupe de travail de l'IETF responsable de la rédaction des signatures de courriel.

4.2 Protocole Internet (IP) version 6

L'actuelle version d'IP, IP version 4 (IPv4), limite le nombre d'ordinateurs hôtes adressables qui peuvent être pris en charge par le réseau. Plusieurs de ces adresses ont été attribuées, et on observe une pénurie. Une nouvelle version d'IP, IP version 6 (IPv6), a été conçue et comporte beaucoup plus d'espace adresse. Pour tirer parti de cette taille accrue du réseau et des caractéristiques supplémentaires, IPv6 a commencé à être déployé, notamment dans la région de l'Asie-Pacifique.

Comme IPv6 est généralement déployé, les applications destinées aux serveurs de courriel et les clients devront soutenir IPv6. Le logiciel doit pouvoir interpréter correctement les adresses plus longues qui seront utilisées pour identifier les MTA. La plupart des applications logicielles sont capables de traiter les adresses IPv6; toutefois, certaines devront être mises à niveau. Par ailleurs, les systèmes dont dépend le courriel, comme DNS, les passerelles SMTP et les filtres, devront également pouvoir soutenir IPv6. Les listes d'authentification reposant sur le domaine qui sont utilisées pour bloquer les expéditeurs malveillants devront être modifiées afin d'inclure les expéditeurs adaptés à IPv6. À mesure que les polluposteurs et leurs destinataires opteront pour IPv6, il sera de plus en plus nécessaire de prendre des mesures anti-pourriel adaptées &agra ve; ce protocole.

4.3 Présence

Le concept de « présence » est utilisé pour fournir des services capables de localiser l'utilisateur pour les applications IM et VoIP. Ces applications ont accès à l'information sur l'emplacement géographique et la situation d'un usager. Cette information doit toutefois être manipulée avec soin. Certains pourriels sans fil exploitent déjà cette information en utilisant des annonces propres à l'endroit, par exemple, dans des aéroports. Si l'information n'est pas bien sécurisée, les technologies IM et VoIP pourraient faire l'objet d'une utilisation pernicieuse de la part des polluposteurs.

---

⁹ www.imc.org/ietf-mxcomp/mail-archive/msg05054.html

¹⁰ www.imc.org/ietf-mxcomp/mail-archive/msg04673.html