DKIM et les listes de diffusion
Serge Aumont
Comité Réseau des Universités,
Université de Rennes 1, Campus de Beaulieu 35042 Rennes Cedex
Résumé
DKIM (Domain Keys Identified Mail) est une technologie de signature des messages dont l'objet est de pouvoir certifier qu'un message est intègre et qu'il provient bien du domaine de son auteur. Le but de DKIM est bien entendu de renforcer l'arsenal des dispositifs de lutte contre le spam et plus particulièrement du hameçonnage. L'objectif de cette étude est d'éclairer les interactions entre DKIM et les listes de diffusion, en les illustrant par les développements spécifiques faits pour le serveur de listes Sympa.
Cet article décrit les grands principes de DKIM. Alors que SPF (Sender Policy Framework) permet de s'assurer qu'un MTA donné est autorisé à émettre des messages pour un domaine donné, DKIM utilise du chiffrement asymétrique pour garantir l'intégrité du corps du message et de certains de ses entêtes. L'entête From: fait bien entendu partie des entêtes signés. La signature ainsi construite, insérée dans un nouvel entête du message, peut être vérifiée par tout destinataire en exploitant la clef publique du domaine concerné. Celle-ci est publiée dans le DNS. Nous comparons cette technologie à PGP et S/MIME, deux autres techniques permettant la signature de message.
Dans une deuxième partie, nous examinons quelles difficultés peuvent être engendrées par un serveur de listes de diffusion au regard du statut DKIM des messages. Nous expliquons pourquoi les serveurs de listes doivent être adaptés, faute de quoi ils pourraient perdre des messages. De plus, nous évaluons les bénéfices qu'un serveur de listes peut tirer de cette technologie. Le propos est illustré par la description des fonctionnalités DKIM introduites dans Sympa pour lequel nous proposons des configurations.
Mots clefs
DKIM, ADSP, listes de diffusion, antispam, UCE,
La facilité avec laquelle tout un chacun peut falsifier certains entêtes de messagerie, en particulier le « From: » est une faille de la messagerie SMTP qui facilite, entre autres, les attaques par hameçonnage. Par ailleurs la complexité de la lutte contre le spam est largement aggravée par cette faiblesse. En effet, il n'est pas raisonnable de baser le filtrage des messages sur la réputation de l'adresse SMTP de leur auteur puisque celle-ci est le plus souvent contrefaite. C'est pourquoi on emploie des moyens détournés comme par exemple les listes noires et les bases de réputation qui ne s'appliquent qu'aux adresses IP des serveurs d'émission des messages.
Citons aussi parmi les conséquences de l'usurpation généralisée des adresses dans le « Return-path: » le backscattering, terme qui désigne les réponses automatiques qu'un utilisateur reçoit pour des messages qu'il n'a jamais envoyés. Au premier rang du backscattering figurent les rapports de non-remise car les bases d'adresses utilisées par les spammeurs sont souvent de mauvaise qualité et elle contiennent de nombreuses adresses invalides. Aussi, même si les RFC stipulent explicitement le contraire, il est souvent préférable de ne pas notifier le rejet d'un spam par un rapport de non-remise. Ceci évite d'ajouter à la pollution des spams celle issue de ces rapports de non-remise pour des messages dont vous n'êtes pas l'auteur1. Dès lors, il est primordial de filtrer le flux de messages sur le MX du domaine, pendant les sessions SMTP, de sorte que les rejets soient notifiés par un code d'erreur en session et non par la génération d'un DSN2. Cette contrainte impacte fortement les architectures de messagerie ; elle contribue à l'obligation de surdimensionner les serveurs de filtrage afin de traiter en temps réel des pointes de trafic très élevées.
Les raisons ne manquent donc pas pour chercher à généraliser une technologie permettant d'authentifier l'auteur d'un message. PGP et S/MIME sont des techniques qui possèdent les propriétés requises mais dont l'usage reste marginal. En effet, ces deux techniques requièrent d'une part le déploiement d'une infrastructure de gestion de clés publiques, dont on sait que le coût de gestion est très élevé, et d'autre part le déploiement de clients de messagerie dotés des fonctionnalités de chiffrement ad hoc. Enfin, la formation des utilisateurs à l'emploi de ces outils n'est pas la moindre des difficultés car la compréhension des techniques sous-jacentes requiert une solide culture informatique.
Les auteurs du RFC 4871 [1] qui spécifie DKIM tirent les leçons de ces écueils. DKIM est aussi une technique utilisant du chiffrement asymétrique pour signer des messages, mais la diffusion des clés publiques nécessaires à la vérification des signatures est fondée sur le DNS. En conséquence, disposer d'une PKI reconnue de tous n'est plus un préalable au déploiement de cette technologie. Mieux encore, l'ajout et la vérification des signatures étant en général faite par des MTA, ce déploiement n'impose pas de mise à niveau des clients de messagerie utilisés.
Une signature DKIM est un nouvel entête SMTP : « DKIM-Signature: ». Elle contient une série de valeurs séparées par des « ; » . L'une de ces valeurs est obtenue par le chiffrement asymétrique (RSA) de l'empreinte (SHA1 ou SHA256) d'une forme canonique du message et de certains de ses entêtes. Le destinataire du message peut déchiffrer cette empreinte au moyen de la clé publique du domaine signataire et vérifier l'intégrité du message en la recalculant. On observe que la technique utilisée est très similaire à celle utilisée pour la signature S/MIME ou PGP. L'entête « From: » faisant partie des entêtes qui sont toujours signés, sa falsification n'est possible qu'en disposant de la clé privée de signature.
|
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cru.fr; s=lists; t=1253606545; bh=OlpSJ5JchtJ2CadL8LtZ4wmoqGhpXKmpd54T9aeD6fY=; |
Figure 1 - Un exemple de signature DKIM
La figure 1 montre l'exemple d'un entête DKIM-Signature. Bien entendu celui-ci se continue sur plusieurs lignes. Les valeurs présentes dans cette signatures sont :
v= : la version de référence de DKIM ;
a= : l'algorithme d'empreinte et celui de chiffrement ;
c= : l'algorithme de canonisation utilisé avant calcul de l'empreinte (dans l'exemple utilisé, l'algorithme « relaxed » est utilisé pour les entêtes du message et « simple » pour son corps). Cette passe préalable au calcul de l'empreinte du message permet de rendre la signature plus résistante à de petites altérations comme par exemple l'ajout ou la suppression d'un « white space » (au sens de la RFC 2822) en fin de message.
h= : la liste des entêtes du message qui sont inclus lors du calcul de l'empreinte du message ;
d= : le domaine de l'entité qui signe le message, cette information est capitale, elle est utilisée pour construire la requête DNS de recherche de la clé publique nécessaire à la vérification de la signature ;
s= : le sélecteur, cette valeur est elle aussi utilisée pour chercher la clé publique via le DNS. Il peut être mis à profit pour faciliter la gestion des clés, par exemple le sélecteur peut être le mois courant si on renouvelle le bi-clé mensuellement. Ainsi pour le domaine cru.fr le sélecteur « lists » est réservé aux signatures de messages provenant des listes de diffusion (une autre valeur est utilisée pour les messages de personne à personne).
b= : l'empreinte chiffrée du message ;
Le MTA du destinataire d'un tel message peut vérifier cette signature à l'aide de la clé publique contenue dans l'enregistrement DNS3 de type TXT identifié par la chaîne obtenue par concaténation ordonnée de :
la valeur de la marque «s=»,
la constante «_domainkey»4,
la valeur de la marque «d=».
Dans notre exemple, la recherche porte sur la chaîne : « lists._domainkey.cru.fr. ». L'enregistrement DNS correspondant précise le type de clé (RSA en général) et sa valeur :
|
lists._domainkey.cru.fr IN TXT "k=rsa\; p=MFwwDQYJ...............r15UCAwEAAQ==" |
Figure 2 - exemple d'enregistrement DNS pour DKIM (la valeur de la clé est écourtée)
Il convient de noter qu'à la différence de la signature S/MIME, certains entêtes du message sont inclus lors du calcul de la signature. C'est bien entendu un progrès intéressant puisque le destinataire du message peut vérifier leur intégrité. C'est aussi la source d'une fragilité des signatures dans la mesure où certains services comme les moteurs de listes de diffusion ou même certains MTA peuvent transformer des entêtes et donc rendre les signatures invalides.
Le déploiement de DKIM à l'échelle des domaines de messagerie de nos établissements est assez simple puisqu'il suffit d'installer un MTA qui signe tous les messages légitimes du domaine. Il existe plusieurs solutions pour arriver à ce résultat (milter-dkim ou son fork de opendkim5 sont deux produits qui peuvent convenir au plus grand nombre puisque l'interface milter est supportée par les deux MTA favoris de notre communauté : sendmail et postfix).
Toutefois, derrière cette apparente simplicité se cache un travail important sur l'architecture des services de messagerie. En effet, en signant tous les messages émis, on prend le risque de signer les messages qui seraient émis suite à la corruption d'une machine : on risque de signer du spam. Il est donc évident que la signature DKIM doit être insérée non pas sur le MTA de sortie des messages mais sur le ou les MSA de façon à ne signer que les messages authentifiés. Ceci constitue un argument supplémentaire pour rendre obligatoire l'authentification SMTP pour la soumission de message. Pour plus d'informations sur les éléments constitutifs de l'architecture de messagerie, le lecteur intéressé est invité à se référer à l'article de JRES 2005 [2].
Déployer DKIM c'est aussi exploiter les signatures DKIM existantes, en particulier pour améliorer le filtrage antispam. Cette opération sera donc probablement effectuée prioritairement sur le MX du domaine de messagerie.
Dans le cas où le message contient une signature valide, le message est considéré comme intègre c'est-à-dire qu'il est conforme à ce qui a été signé (y compris l'entête « From: »). Cela ne signifie pas que c'est un ham6. En effet, rien n'interdit aux spammeurs de signer leurs messages7 ; tout au plus peut-on penser qu'il a été envoyé à visage découvert par un « gentil spammeur ». On peut donc créer des « whitelist » et des « blacklist » de domaines pour exploiter ces signatures. Une telle blacklist permet alors de cibler une catégorie de spam appelés UCE « Unsolicited Commercial Email », qui sont émis par des sociétés ayant pignon sur rue et qui sont plus respectueuses des lois.
Toutefois, les spammeurs les plus indélicats ont identifié depuis longtemps les nombreux bénéfices qu'ils peuvent avoir à pirater ou à créer automatiquement des comptes de service chez de gros hébergeurs de messagerie tels que Yahoo ou Google. Cette voie leur permet entre autre d'émettre des messages avec une signature DKIM valide. Elle permet aussi d'échapper aux listes noires d'adresses IP ou encore de satisfaire à bon compte les critères de SPF8.
L'objectif du RFC 5617 [3] (Author Domain Signing Practice , ADSP)est de préciser quels traitements doivent être entrepris lorsqu'un message reçu ne contient pas une signature DKIM valide issue du domaine de son auteur. Dans le cas favorable où un message contient une signature valide, il n'est pas utile de rechercher l'enregistrement ADSP pour ce domaine. Dans le cas contraire, un enregistrement DNS pour le domaine de l'auteur permet de préciser si cette situation est anormale. Cet enregistrement peut prendre trois valeurs, unknown , all et discardable :
« unknown », indique que certains messages peuvent être signés, d'autres non. C'est la valeur par défaut autrement dit la valeur appliquée aux domaines qui n'ont pas explicitement précisé leur politique de signature au moyen de cet enregistrement DNS.
« all » indique que le domaine signe tous ses messages ;
« discardable » indique que le domaine signe tous ses messages et recommande de ne pas accepter les messages non signés ou comprenant une signature invalide.
Dans un billet de son blog intitulé « Tree myths about DKIM » [4] John Levine bat en brèche l'affirmation selon laquelle DKIM ne serait pas compatible avec les listes de diffusion. Pourtant, chacun sait que les mythes contiennent une part de vérité...
Une première approche consiste à considérer que la vérification des signatures doit être faite par le MTA en amont du serveur de listes. Une première vérification sera en effet opérée par le MTA dans le cadre de l'indispensable filtrage antispam qui doit protéger le service de listes. Ainsi, un message sans signature, ou avec une signature invalide pour un domaine qui publie un enregistrement ADSP « discardable », aura été rejeté avant d'être délivré au serveur de listes.
Toutefois, un serveur de listes peut lui aussi tirer bénéfice de la vérification DKIM d'un message. En effet, l'intégrité d'un message étant vérifiée à travers DKIM, il est possible d'accorder une confiance plus fine aux différents éléments du message utilisés pour décider du traitement fait par le serveur de listes. Il n'est bien entendu pas question d'accepter un message uniquement parce qu'il est signé (souvenons-nous que les spammeurs ont adopté DKIM plus vite que nous). Il est cependant possible de renforcer la sécurité du moteur de listes de diffusion qui évalue souvent l'autorisation d'accès à tel ou tel service sur la base de l'entête « From: ». On adresse alors le cas de malveillances ciblées plutôt que celui de l'usurpation généralisée des adresses de « From: », observée dans le spam, qui ne conduit que très exceptionnellement à une usurpation des droits telle que la diffusion d'un spam dans une liste privée.
Cette consolidation de la validité de l'adresse email d'émetteur peut aussi permettre de limiter le « backscattering » en n'envoyant une réponse automatique à un message (demande de confirmation, rapport d'erreur du robot...) que si celui-ci contient une signature DKIM valide.
Les robots de listes de diffusion ne sont pas seulement des diffuseurs de messages reçus à destination des abonnés. Ils génèrent aussi un nombre significatif de messages de service (réponses à des commandes, messages de bienvenue, demandes de confirmation). Il importe que ces messages soient signés. Ceci peut-être réalisé par le MTA en aval du serveur de listes de diffusion. Cette hypothèse suppose que tous les messages soient signés avec les mêmes paramètres car il serait très difficile de paramétrer ce MTA pour distinguer les messages à signer. L'exemple le plus évident de ce qui peut faire varier les paramètres de signature est bien entendu la possible existence de plusieurs serveurs de listes dans plusieurs domaines, donc utilisant une marque DKIM « d= » et une clé privée différentes pour chaque domaine. De même, la gestion des clés utilisées pour les signatures du service de listes et celle utilisée pour les personnes peuvent différer ; dans ce cas, le sélecteur (marque DKIM « s= ») sera différent pour ces deux contextes.
Il peut donc être préférable de disposer de la fonction de signature dans le moteur de listes de diffusion, de sorte que l'on puisse contrôler par configuration quels messages doivent être signés et avec quels paramètres.
Les serveurs de listes de diffusion modifient très souvent les messages avant de les diffuser aux abonnés. Ce faisant, il peuvent altérer la signature des messages. C'est le cœur du problème. Plusieurs types de modifications opérées par les serveurs de listes de diffusion sont concernés :
les modifications d'entêtes signés. Le cas le plus fréquent est l'ajout d'une marque dans le « Subject: » avec le nom de la liste ;
l'ajout ou la suppression d'entêtes faisant partie des éléments signés : les serveurs de listes « nettoient » les entêtes de messages, ils ajoutent les leurs (certaines de ces modifications sont imposées par le RFC 2919) ;
les options d'abonnement avec modification du message : par exemple l'option « urlize » de Sympa permet d'extraire les pièces jointes d'un message et de les remplacer par un lien vers le serveur ;
l'ajout d'un pied de message (footer) : le RFC DKIM prévoit qu'une signature peut indiquer que la signature a été calculée en n'utilisant qu'un certain nombre des premiers octets du message9 . Ainsi un ajout au delà de cette limite n'altère pas la signature. Le RFC justifie ce bidouillage spécifiquement pour régler la difficulté créée par cet usage dans les listes de diffusion. Son emploi est déconseillé car les messages l'utilisant pourraient être rejoués en ajoutant du spam à la fin d'un ham sans altérer la signature. De plus, cet aménagement n'est d'aucun secours puisque que l'ajout d'un pied de message ne devrait se faire que par l'ajout d'une partie de corps qui modifie donc les entêtes MIME en début du message. Cette petite imperfection du RFC révèle que leurs auteurs ont perçu les difficultés liées aux listes de diffusion, mais se sont contentés d'une approche superficielle ;
la personnalisation des messages : ce traitement opéré par un serveur de listes permet d'adapter le message diffusé pour chaque destinataire. Le message reçu contient des variables qui sont remplacées par leur valeur pour chaque destinataire lors de la diffusion.
Cette problématique de l'altération des signatures de messages via des serveurs de listes de diffusion est devenue assez centrale dans les projets de déploiement de DKIM. En effet, une forte proportion des messages que nous recevons ont transité par un serveur de listes. Aussi longtemps que DKIM ne s'applique pas à ces messages, les avancées permises par DKIM resterons limitées à une petite partie des flux de messagerie.
Quelques personnes soutiennent que les serveurs de listes de diffusion doivent changer radicalement leur façon de traiter les messages pour ne pas altérer les signatures DKIM. Trois solutions sont avancées :
renoncer totalement à toute modification des messages pouvant altérer une signature DKIM.
ré-écrire l'entête « From: » du message en utilisant une adresse du serveur de listes, supprimer les signatures pré-existantes et signer le message avec la signature du domaine du serveur de listes.
en-capsuler le message à diffuser dans un nouveau message au format MIME et signer ce message.
Ces approches ont peu de chances de s'imposer. En effet, elles remettent radicalement en cause non seulement les implémentations des serveurs de listes de diffusion, mais surtout la façon dont les listes de diffusion sont utilisées par leurs abonnés.
La troisième solution apparaît comme une variante de la solution 2 parce que comme elle, elle consiste à signer le message diffusé en appliquant un champ « From: » qui correspond à la marque « d= » de la signature DKIM. En effet, les difficultés surviennent dès lors que le domaine qui a signé un message n'est pas celui de son auteur apparent (autrement dit quand le message initial n'est pas issu du même domaine que le serveur de listes). D'un point de vue théorique, la dernière solution est satisfaisante, mais elle fait abstraction du très mauvais traitement des attachements de type message/rfc822 tel qu'il est assuré aujourd'hui par les clients de messagerie déployés.
Aussi, les techniciens doivent admettre que des usages comme le fait de marquer le sujet des messages avec le nom de la liste sont des besoins légitimes à ne pas mépriser. Ainsi, précisément du fait des ravages causés par le spam, il existe une forte pression pour qu'à chaque message soit ajouté un lien permettant de se désabonner10. On nous demande même de personnaliser ce lien de sorte que la personne puisse se désabonner facilement, et cela même si elle ne se souvient plus de l'adresse avec laquelle elle s'est abonnée. DKIM doit être employé de façon à rester compatible avec tous ces services ajoutés qui ne doivent pas devenir l'apanage des spammeurs.
La solution proposée consiste à :
ajouter un entête SMTP « Sender: » dont la valeur est « <listname>-request@<domaine-serveur> » ;
supprimer les signatures DKIM du message reçu qui seraient altérées par le serveur de listes ;
signer les messages diffusés aux abonnés avec les paramètres de signature du domaine du serveur.
Comme suggéré par les RFC 4871 et 5672 [5], la signature DKIM inclut le paramètre optionnel identity (marque « i= », même valeur que l'entête « Sender: »). Dans le cas où l'émetteur du message appartient au même domaine que le serveur de listes, l'opération est indolore. Dans tous les cas, cette signature prouve le passage par le serveur de listes. L'objectif n'est-il pas alors atteint ? En effet, l'authentification DKIM vise à fiabiliser la consultation de listes de réputation basées non plus sur l'adresse IP de provenance, mais sur le domaine de l'émetteur. Dans le cas des listes de diffusion, c'est la réputation du serveur de listes de diffusion qui permet de valider ou non la réception des messages (il est entendu que le serveur de listes est paramétré pour se protéger au mieux des spams).
Hélas cette solution n'est pas parfaite car, dans le cas défavorable où les modifications apportées au message sont de nature à altérer sa signature d'origine, le destinataire du message observe alors un message signé avec un domaine différent de celui de son entête « From: ». Or la notion de signature par un tiers n'a pas été retenue dans le RFC 5617 sur les pratiques de signature (ADSP) ; ce traitement peut donc être à l'origine de messages qui ne sont plus conformes, après diffusion dans une liste, à l'enregistrement ADSP du domaine d'origine.
De ce fait, certains débatteurs soutiennent que la valeur « discardable » de l'enregistrement ADSP doit être réservée aux domaines qui ne font pas de messagerie. Nous ne sommes pas loins de nous ranger à cet avis, cette configuration s'applique à quelques domaines spécialement ciblés par du hameçonnage (banques, sites de vente aux enchères...) et qui n'offrent pas un service de messagerie SMTP universel. Elle est vivement déconseillée aux domaines tels que ceux gérés dans notre communauté puisqu'elle interdit l'envoi de messages dans des listes de diffusion. Elle pourrait cependant être utilisée avec beaucoup de profit pour un sous-domaine spécialisé dans les annonces officielles en s'appuyant en particulier sur un serveur de listes implémentant DKIM.
Les discussions sur ADSP continuent. Plus de deux ans après l'adoption laborieuse du RFC décrivant la signature DKIM, le traitement des signatures invalides ou absentes fait toujours débat. En octobre 2009, une nouvelle proposition de RFC a été déposée « DKIM Third-Party Authorization Label » [6] pour tenter de résoudre ce problème. La technique consiste à spécifier, au moyen d'un nouvel enregistrement DNS, quels domaines tiers sont autorisés à signer les messages du domaine d'origine et dans quels entêtes du message on doit retrouver la trace de cette intervention tierce.
La version 6.1 de Sympa intègre des fonctionnalités DKIM natives. Le code s'appuie sur une librairie Perl CPAN (Mail::DKIM) permettant de vérifier ou d'ajouter une signature DKIM à un message.
Le résultat de cette vérification est utilisé principalement pour enrichir le pouvoir d'expression du mécanisme de scénario d'autorisation de Sympa. Celui-ci distingue maintenant les messages :
non authentifiés ;
les messages authentifiés par un challenge ;
les messages signés avec S/MIME ;
les messages signés avec DKIM.
|
!is_subscriber([sender],[listname]) smtp -> reject,quiet !is_subscriber([sender],[listname]) dkim,md5,smime -> reject |
Figure 3 - exemple de scénario avec rejet silencieux sauf authentification de l'auteur (prévention du backscattering)
La mise en route de cette fonctionnalité dans Sympa est optionnelle, elle requiert la révision de l'ensemble des scénarios d'autorisation (sauf bien entendu ceux distribués avec Sympa lui-même). En effet, une fois la fonctionnalité activée, les règles spécifiées pour les méthodes d'authentification smtp, md5 et smime ne s'appliquent pas aux messages contenant une signature DKIM, ce qui peut conduire à des rejets indésirables.
Avec Sympa, tous les services qui peuvent conduire à l'altération d'une signature sont optionnels. Il est donc possible de configurer les listes pour que les messages signés avec DKIM soient diffusés sans altération de cette signature. Toutefois, selon nous, cet usage restera marginal.
Dans tous les autres cas, notre proposition est de prévenir la redistribution par le serveur de listes de messages non conformes à l'enregistrement ADSP du domaine émetteur. C'est-à-dire, ne pas accepter de diffuser les messages, même correctement signés, si l'enregistrement ADSP est « discardable » et si la liste transforme les messages. Ceci évite de diffuser un message que les destinataires devraient finalement rejeter (ce traitement n'est pas encore implémenté).
En outre, une des dernières étapes du processus interne de traitement des messages consiste à vérifier la validité d'une éventuelle signature DKIM pré-existante, c'est-à-dire à vérifier que les transformations des messages n'ont pas altéré cette signature. Dans le cas contraire elle est supprimée puisqu'il est inutile de transmettre une signature invalide.
Sympa peut être configuré pour signer l'ensemble des messages de service ainsi que tout ou partie des messages distribués dans les listes. Ainsi, on peut choisir de n'apposer la signature DKIM du serveur de listes que sur les messages des catégories suivantes :
messages reçus avec une signature DKIM valide ;
messages authentifiés par S/MIME ou par un challenge email ;
messages validés par un modérateur.
L'ensemble des paramètres (valeurs des marques « s= », « d= », « i= », valeur de la clé privée, cas d'application d'une signature) peut être défini pour chaque liste, chaque robot virtuel ou pour l'ensemble de l'installation. Le lecteur se réfèrera à la section DKIM du manuel de référence de Sympa [7]
DKIM n'est pas l'outil ultime qui permettra d'éradiquer le spam. Toutefois, c'est une arme supplémentaire qu'il ne faut pas négliger. Les services de listes de diffusion subissent de plus en plus de dégâts collatéraux de la part des mesures de lutte contre le spam que chacun met en œuvre. Citons le greylisting, qui engorge le spool de sortie des serveurs de listes, mais aussi la limitation du nombre de destinataires par message, la limitation de cadence des sessions SMTP, etc. Parfois même, les serveurs de listes sont mis en liste noire. C'est parfois parce que le robot de listes de diffusion a répondu intempestivement à un spam non détecté et dont le « From: » contenait une adresse de pot de miel 11
Des services de réputation qui permettraient de distinguer les domaines diffusant des UCE de ceux de services de listes qui s'appliquent à ne diffuser que des messages sollicités (double opt-in, procédure de désabonnement facilitée, rappel périodique des abonnements, contrôle des messages diffusés, etc.) seraient peut être un progrès décisif.
Le déploiement de DKIM tarde malgré sa simplicité. Ceci s'explique en partie parce que le bénéfice qu'un domaine peut tirer à le mettre en œuvre pour son propre domaine est indirect, mais aussi parce la problématique des listes de diffusion a peut-être été un peu négligée.
L'implémentation réalisée dans le serveur Sympa vise à contribuer à la généralisation de DKIM. Internet 2 et l'ISOC ont contribué au financement de ces travaux pour cette raison. Nous voulons aussi mettre en évidence les difficultés liées aux spécifications existantes et obtenir des réponses explicites des auteurs de ces différents RFC.
RFC4871 DomainKeys Identified Mail (DKIM) Signatures http://tools.ietf.org/html/rfc4871
Serge Aumont et Claude Gross L'impact de la lutte contre le spam et les virus sur les architectures de messagerie Article de JRES 2005 . http://2005.jres.org/paper/136.pdf
RFC5617 Author Domain Signing Practices (ADSP) https://wiki.tools.ietf.org/html/rfc5617
John Levine « Three myths about DKIM » http://weblog.johnlevine.com/Email/threemyths.html
RFC 5672 DomainKeys Identified Mail (DKIM) Signatures – Update RFC 4871 http://tools.ietf.org/html/rfc5672
Douglas Otis « DKIM Third-Party Authorization Label » http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03
Sympa reference manual / Chapitre DKIM http://www.sympa.org/manual_6.1/dkim
1 Il existe des techniques spécifiquement destinées à se prémunir contre ces rapports de non-remise intempestifs, citons en particulier « Bounce Address Tag Validation »
2 Delivery Status Notification, communément appelé « bounce »
3 Le lecteur averti ne manquera pas de signaler que le niveau de sécurité de DKIM est dépendant de celui du DNS puisque si une attaque permet de faire accepter à un resolver un faux enregistrement DNS pour un domaine donné, il est alors possible d'utiliser un faux bi-clé DKIM pour ce domaine. La falsification des envois d'email n'est pas la plus grave des conséquences d'une telle attaque... DNSSEC est bien entendu une bonne parade, sauf compromission du serveur DNS lui même.
4 La constante «_domainkey» est définie dans le RFC 4871 ; le recours à une constante préfixée par un « _ » permet d'éviter toute collision avec une autre entrée du DNS puisque ce caractère est interdit dans les noms de domaine ou de host. Un nouveau type d'enregistrement dédié aurait permis d'éviter cette constante mais aurait été un handicap insurmontable au déploiement de DKIM.
5 Opendkim : http://www.opendkim.org/ milter-dkim : https://www.milter.org/milter/2
6 ham : message qui n'est pas un spam
7 Il a été constaté dans les premiers mois suivant la publication de DKIM que les spammeurs ont adopté DKIM plus vite que le reste de la communauté internet, ce qui conduisit au paradoxe suivant : la présence d'une signature DKIM amenait une plus forte probabilité d'être en présence d'un spam.
8 SPF : Sender Policy Frameword (RFC 4408), permet de publier au moyen du DNS la liste des serveurs autorisés à émettre des messages pour un domaine donné.
9 Cette longueur est exprimée en octets et figure dans la marque « l= »
10 Si les clients de messagerie savaient interpréter et présenter l'entête « List-Unsubscribe: » introduit il y a pourtant plus de dix ans dans le RFC-2369 et supporté par la quasi-totalité des serveurs de listes, le désabonnement serait devenu une action simple pour tous.
11 Nous pensons que les répondeurs automatiques de listes de diffusion ont vécu et nous proposerons dans une prochaine version de Sympa le moyen de se passer complètement de l'interface de commande en mode messagerie.