Lutter contre le SPAM avec DKIM et SPF

Il y a fort longtemps, dans une lointaine galaxie nommée Internet, les serveurs SMTP (Simple Mail Transfer Service) relayaient les e-mails sans poser de questions. Puis les vilains SPAMMEURS ont débarqué et il fallut commencer à tout repenser. Nous allons voir ici comment s’est organisée la lutte contre ces êtres démoniaques et pourquoi il est devenu essentiel de mettre en place des technologies telles que SPF et DKIM pour prouver que les e-mails que vous envoyez proviennent bien de votre serveur SMTP et pas d’un autre.

Quel est le rôle du serveur SMTP dans l’envoi et la réception de mail ? Ce dernier est appelé MTA (Mail Transfer Agent) et il est voué à distribuer les e-mails que vous envoyez à leurs destinataires et à recevoir (stocker d’une manière cohérente sur le serveur) ceux que vous recevez. Le MTA est le seul élément indispensable pour envoyer et recevoir des e-mails, les serveurs POP/IMAP sont des services mis en place pour permettre à l’utilisateur de récupérer les e-mails sur le serveur SMTP à l’aide d’un client (Client lourd : Outlook, Thunderbird, Mail… , Webmail, Smartphone …).

Les serveurs SMTP les plus connus et utilisés sont l’historique Sendmail et ses petits frères Postfix Exim Qmail. Les exemples de configuration que vous pourrez trouver dans la suite de l’article sont issus de Postfix.

Comment le serveur SMTP fait-il pour savoir où acheminer le courrier ? Simple comme bonjour, il interroge la zone DNS du domaine — partie à droite de l’@ dans une adresse mail — qu’il souhaite joindre à la recherche d’un enregistrement MX (Mail Exchanger) qui pointe vers l’IP du serveur mail chargé de collecter le courrier pour ce domaine. Si vous cherchez à envoyer un mail à cam@bibabox.fr, votre serveur SMTP va chercher où envoyer le mail dans la zone DNS de bibabox.fr. Vous pouvez faire le test vous-même à l’aide de la commande Nslookup.

> nslookup -q=mx bibabox.fr

bibabox.fr MX preference = 1, mail exchanger = mx0.ovh.net
bibabox.fr MX preference = 100, mail exchanger = mxb.ovh.net

Vous noterez la présence de deux enregistrements MX qui diffèrent par leur « préférence » ou « priorité ». Ici non plus rien de bien sorcier, on commence par essayer de joindre le serveur avec la priorité la plus basse, et s’il ne répond pas on passe au serveur avec une priorité plus haute jusqu’au premier serveur qui répond. A noter qu’il serait sûrement préférable de laisser tomber les enregistrements MX au profit des enregistrements SRV, qui proposent plus de fonctionnalités, comme la répartition de charge ou encore la possibilité de spécifier le port où est hébergé le service.

Pour l’image, le MTA c’est un peu la poste, la société s’occupe de transférer le courrier d’un bureau de poste (serveur) à un autre en se basant sur votre adresse (e-mail) où le code postal fait office de champ MX permettant de savoir dans quel bureau de poste envoyer le courrier. Le MUA c’est votre facteur, il délivre le courrier qui arrive au bureau de poste dans votre boîte aux lettres (Ordinateur, Téléphone, PDA …). L’intérêt de l’échange de mail sur l’échange postal c’est que l’on peut facilement recevoir le courrier à plusieurs endroits simultanément en laissant une copie du message sur le serveur pour une durée plus ou moins longue.

Tout comme la poste, par défaut le serveur SMTP ne cherche pas à vérifier l’adresse de l’émetteur, ni plus qu’il ne cherche à authentifier la personne utilisant le service. Une bagatelle pour les Spammeurs et autres individus malveillants agissant sur la toile. La première chose à faire est donc d’implémenter les mécanismes de sécurité dont vous avez besoin afin que votre serveur SMTP ne devienne pas un relais-ouvert utilisable par le premier venu. Les systèmes de configuration des serveurs mails disposent de mécanismes permettant d’accepter ou de rejeter l’envoi d’un mail en se basant sur la configuration du client ou sur la destination. Les directives de configuration smtpd_client_restrictions ou smtpd_recipient_restrictions (Postfix) permettent par exemple de faire ce travail. C’est pourquoi la valeur de ce genre de directives est extrêmement importante et ne doit en aucun cas être laissée au hasard. Si votre serveur SMTP est ouvert sur internet, il vous faudra aussi certainement mettre en place un mécanisme d’authentification tel que SASL, afin que seuls les utilisateurs disposant d’une boîte mail — et donc d’un couple login/mot de passe associé — sur votre serveur puissent l’utiliser. Bien entendu, comme en SMTP tout passe en clair et que vous n’avez pas envie que quelqu’un puisse attraper votre mot de passe ou lire les mails que vous envoyez, il faudra mettre en place une surcouche SSL/TLS avec un certificat valide pour avoir enfin un service sécurisé à proposer à vos utilisateurs.

Votre serveur SMTP est maintenant sécurisé et seuls les utilisateurs authentifiés sont autorisés à l’utiliser, le courrier qui en sort peut donc être considéré comme légitime. Mais puisqu’il est possible d’envoyer des mails sans aucune vérification de l’identité de l’expéditeur via n’importe quel serveur non sécurisé, qu’est-ce-qui prouve à votre destinataire que le courrier qu’il vient de recevoir de vous est bien légitime ? Puisque notre serveur est considéré comme digne de confiance, on va donc chercher à établir l’identité du serveur qui a envoyé le message et à vérifier qu’il s’agit bien d’un serveur digne de confiance. C’est exactement le but des enregistrement DNS SPF et DKIM.

SPF (Sender Policy Framework) est une norme de vérification du nom de domaine de l’expéditeur d’un mail, normalisé dans la RFC4408. SPF vise à réduire les possibilités d’usurpation en publiant, dans le DNS, un enregistrement (de type SPF ou, autrefois, de type TXT) indiquant les adresses IP des serveurs qui sont autorisées à envoyer du courrier pour le domaine considéré. Quand le serveur SMTP de destination reçoit le mail, il peut faire une vérification de ce type, auquel cas soit il décide de refuser purement et simplement le mail soit il peut l’accepter tout de même. Il peut encore décider de notifier l’utilisateur — en rajoutant une ligne dans le corps du message par exemple — ou l’administrateur. Plus généralement cela va surtout influer sur le score que l’anti-spam mis en place chez votre destinataire accorde à votre message et c’est ce dernier qui décidera du sort de ce message. La décision à prendre en cas d’échec de la vérification ou d’absence d’enregistrement SPF appartient à la solution mise en place par l’administrateur. Gardez simplement à l’esprit qu’aujourd’hui encore, seul un trop faible pourcentage des domaines comportent un enregistrement SPF avant de rejeter tout les mails qui ne remplissent pas cette condition.

exemple d’enregistrement SPF :

v=spf1 a mx ptr ip4:1.2.3.4 mx:mail.exemple.com ~all

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un mail, normalisé par l’IETF (Internet Engineering Task Force) dans le RFC 4871 pour palier aux faiblesses de SPF. DKIM a été produit par un consortium industriel en 2004. Il intègre et améliore DomainKeys de Yahoo! et Identified Internet Mail de Cisco. Il est à noter que d’autres acteur majeurs de l’Internet et des systèmes d’information ont pris part au projet, IBM, Microsoft, PGP Corporation, Sendmail, StrongMail Systems … Le but final de la solution est le même que pour SPF : lutter contre le spam et l’usurpation d’identité. On trouve des implémentations libres prêtes à être couplées aux principaux MTA. Le projet le plus abouti à ce jour semble être OpenDKIM.

Exemple d’enregistrement DKIM :

mail._domainkey.example.com. IN TXT « v=DKIM1; k=rsa; p=MEwwPQRJKoZIhvcNADAQCQADOwAwOAIxANPpYHdE2tevfEpvL1Tk2dDYv0pF28/f5MxU83x/0b sn4R4p7waPaz1IbOGs/6bm5QIDAQAB »

Mais qu’apporte DKIM par rapport à SPF ?

SPF se base sur des adresses IP — ou des blocs d’adresses IP — pour vérifier la provenance du message. Seulement, et contrairement à ce qu’essaie de nous faire croire le gouvernement français et sa HADOPI , une adresse IP n’est pas une preuve irréfutable, et il est relativement facile ou en tous cas loin d’être impossible d’usurper une adresse IP sur un réseau. Cette technique s’appelle le spoofing. C’est pourquoi on a recours ici à un système cryptographique asymétrique. On génère une paire de clefs, on stocke la clef publique dans un enregistrement de type TXT de la zone DNS concernée, et on stocke bien précieusement la clef privée sur le serveur. A chaque fois que le serveur SMTP va envoyer un mail, il va chiffrer une petite partie du message à l’aide de sa clef privée. A la réception du message, le serveur SMTP qui détecte ce champ va chercher à le déchiffrer avec la clef publique disponible dans la zone DNS du domaine de l’expéditeur. Si l’opération aboutit, il peut alors assurer que le message reçu provient bien d’un serveur possédant la clef privée. Il devient ainsi impossible — sauf cas du vol de la clef privée — d’usurper l’identité d’un serveur SMTP. Ici aussi les décisions qui découlent de la vérification sont à définir par l’administrateur (acceptation, rejet, notification à l’utilisateur ou à l’administrateur …).

Voici comment Gmail notifie ses utilisateurs du résultat de ses tests :

Mais alors pourquoi mettre en place de telles solutions puisque tout le monde ne le fait pas ? Tout da’bord car ça fait clairement partie des « Best Practices ». Ensuite, c’est un geste citoyen qui permet de réduire globalement le fléau qu’est le spam — c’est bien pour cela qu’autant d’acteurs industriels se sont rassemblés autour du projet. Enfin, vous gagnerez de précieux points dans les mécanismes anti-spams mis en place chez vos destinataires, ainsi le nombre de vos messages qui finira dans les boîtes de courriers indésirables se trouvera réduit.

Certes, DKIM et SPF authentifient le domaine, mais quid de la partie gauche, le nom d’utilisateur ? Comment vérifier l’authenticité non pas du serveur qui a envoyé le mail mais de l’utilisateur ? Ici pas vraiment de choix, il vous faudra recourir à un système de chiffrage et/ou de signature de données tel que PGP ou S/MIME pour authentifier le message et assurer ainsi la confidentialité et/ou l’intégrité de la transmission.

Si vous souhaitez vous renseigner un peu plus sur les technologies anti-spam, je vous conseille de faire un tour sur ce site.

http://www.altospam.com/fr/panorama-des-technologies-antispam.php

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *