Avec l’avènement du courrier électronique les fournisseurs d’accès Internet et les entreprises ont rapidement été confrontés à la problématique des courriels non-sollicités, les spams, ou les pourriels pour les plus francophiles d’entre-vous. Il n’était pas rare à certains moment d’avoir 85% (voir même 97% selon les sources) des courriels qui étaient identifiés comme étant des spams.

Afin d’endiguer ce fléau, la communauté Internet à développer des techniques de prévention et de détection des spams: SPF (Sender Policy Framework) & Sender ID, DMARC, DKIM ou le scoring du contenu.

Comme c’est toujours le cas, toute mesure de protection apporte aussi de nouveaux risques. Dans ce cas-ci, celui que certains messages important ne soient pas délivrés à leurs destinataires parce que considérés à tort comme du spam. Comme le montre notre petit coup de sonde sur le Top 500 des entreprises mondiales et comme vous pourrez le voir prochainement sur un échantillonnage plus grand de sites belges, le nombres de sociétés ou de personnes qui ont misent en oeuvre ces technologies ne sont pas si nombreuses que cela (même si ce n’est pas négligeable) alors que pour DMARC et SPF & Sender ID, il s’agit réellement de quelques minutes de travail. C’est d’autant plus important que des sociétés comme Google et Microsoft, qui gèrent des services de messagerie électronique utilisés par des millions de personnes privées et d’entreprises, ont installés ces technologies et que vos emails ont peu de chances d’atteindre leurs destinataires si leur messagerie est hébergée chez ces deux prestataires ou chez n’importe quelle société qui aurait décidé de mettre des systèmes anti-spam performant en place.

La première étape, comme d’habitude, est de faire un état des lieux. Pour ce faire, vous pouvez utiliser un certains nombre de services gratuits accessible en ligne tels emailspamtest.com ou l’ email spam checker d’Alexis Ragot. Cependant nous aimons particulièrement Mail tester qui nous semble le plus convivial et le plus pertinent. Pour ce faire, il vous suffit d’aller sur http://www.mail-tester.com/, en d’envoyer un email à l’adresse qui s’affiche sur la page d’accueil puis de cliquer sur « Ensuite vérifier votre score » et vous verrez un joli petit rapport très complet en compréhensible e français s’afficher.

Si votre score n’est pas glorieux (en dessous de 7 chez Mail-tester, par exemple), Nous allons donc vous détailler ci-après comment mettre en oeuvre les technologies nécessaires pour remonter votre score et augmenter les chances de voir vos courriels atteindre leurs destinations.

SPF & Sender ID

Pour commencer, le plus simple est de mettre en oeuvre Sender Policy Framework (SPF) et Sender ID. Bien qu’elles ne soient pas totalement identiques, les deux techniques sont très proches et peuvent être dans certains cas configurée en une seule et même ligne. SPF est un standard ouvert qui est maintenant sous le contrôle de l’IETF (Internet Engineering Task Force) d’abord via le RFC 4408, rendu obsolète depuis par le RFC 7208 qui a été enrichi du RFC 7372. Si vous ne voulez pas vous plonger dans la lecture de ces deux derniers documents (les RFC ne sont pas fait pour être des plus agréables à lire), vous pouvez visiter le site du projet SPF: http://www.openspf.org/. Sender ID est la version Microsoft de SPF, aussi standardisée par l’IETF sous le RFC 4406. La différence principale, assez technique, est que SPF valide le serveur qui expédie le message via les informations fournies lors de la connexion SMTP: D’abord sur base du HELO, donnant le nom du serveur de messagerie qui envoie le courriel, et ensuite du MAIL FROM:, l’adresse, et donc aussi le nom de domaine, de l’expéditeur du courriel. Sender ID par contre valide l’adresse email « responsable » de l’envoi du courriel tel que défini par l’algorithme PRA (Purported Responsible Address) tel que défini dans le RFC 4407 (un de plus). L’une des conséquence de ces deux techniques, c’est qu’elle empêche un des modes de fonctionnement du courriel (SMTP) qui est l’envoi en mode différé (Store & Forward en Anglais). Néanmoins, celui-ci n’est plus fort utilisé de nos jours.

Néanmoins, si vous n’êtres pas anglophile ou si vous ne voulez pas perdre du temps à saisir toutes les subtilités de SPF et Sender ID, voici un petit cours accéléré.

En quelques mots, SPF utilise un champ texte (TXT) dans la zone DNS du domaine utilisé pour envoyer des messages afin de déterminer quels serveurs de messagerie peuvent délivrer des messages pour ce domaine. Trop compliqué? Prenons l’exemple d’un envoi d’email de Alice@A.com vers Bob@B.com. Je ne vais pas faire ici un cours sur DNS mais juste revenir rapidement sur les principes. Lorsque l’on veut envoyer un email vers une adresse email comme Bob@B.com, le serveur de messagerie de l’expéditeur (A.com) contacte un serveur DNS pour connaitre l’adresse IP du serveur de messagerie du destinataire en lui demandant les enregistrement de type Mail eXchanger (MX). Le serveur DNS communique la ou les adresses des différents serveurs qui peuvent recevoir les messages (avec une liste de priorité). Le serveur de messagerie envoie alors le message vers le premier serveur de B.com (appelons le mail.B.com). Lorsque le serveur mail.B.com reçoit une connexion du serveur de messagerie de A.com, il va le laisser s’identifier et donner l’adresse de l’expéditeur (Alice@A.com). mail.B.com va alors interroger un serveur DNS pour savoir quelles sont les serveurs de messagerie qui peuvent envoyer des messages depuis le nom de domain B.com en lui demandant les enregistrements texte (TXT) de ce domaine et en regardant s’il y a un enregistrement SPF. S’il trouve un enregistrement SPF, il utilisera l’information pour déterminer si le serveur de messagerie (mail.A.com) peut envoyer des messages provenant de Alice@A.com et donc d’accepter ce message ou non.

Une petite vidéo valant mieux qu’une longue explication, on vous à préparé une petite animation de quelques secondes pour comprendre le principe.

Maintenant, que vous avez compris le principe, entrons un peu plus dans les détails.

Que devez-vous renseigner dans un enregistrement SPF?

Dans votre fichier de configuration DNS (BIND ou autre) ou dans l’interface que vous utilisez, vous devez rajouter un enregistrement de type TXT pour votre nom de domaine (ou du moins celui que vous utilisez pour envoyer vos messages).

Un enregistrement spf commence toujours par « v=spf1« . Pour exemple, dans un fichier d’enregistrement de domaine Bind, cela donnerait ceci:

           IN TXT "v=spf1 mx -all"

Dans ce cas, seuls les serveurs renseignés comme étant vos serveurs de messagerie dans votre DNS (MX records) pourront envoyer les messages.

Une version plus simple peut être celle-ci: « v=spf1 -all« . Ceci signifie que toute tentative d’envoi d’email pour votre nom de domaine doit être refusée.

Ce peut tout aussi bien être « v=spf1 +all« , signifiant que n’importe quelle machine peut envoyer un message.

Les mécanismes sont définis après le « v=spf1 » et sont traité séquentiellement dans l’ordre de lecture (de gauche à droite). C’est le traitement du premier mécanisme qui correspond qui est utilisé. Voici une petite table des symbole pour le traitement du message:

? ou pas de signe = un traitement neutre
+ = Accepte
– = Refuse
~= Accepte mais marque le message

D’autre part, les mécanismes permis sont:

all = Tous les mécanismes
ip4 = une adresse IPv4
ip6= une adresse IPv6
a = l’adresse IP du nom de domaine
mx = les serveurs de messagerie du domaine spécifié (ou du domaine par défaut de cet enregistrement)
include = ajouter les informations SPF provenant de ce domaine. Exemple: « v=spf1 include:_spf.google.com ~all » pour ajouter les serveurs de Google Apps for Business

Pour tous les mécanismes utilisant une adresse IP, une adresse de réseau avec un masque CIDR (exemple: ip4:192.168.1.0/24) peut être aussi utilisé.

Si vous voulez pouvoir envoyer des emails depuis vos serveurs de messagerie ainsi que depuis GMail et un serveur de mailing, votre enregistrement ressemblera probablement à cela:

     IN TXT "v=spf1 +mx include:_spf.google.com +ip4:10.1.2.3 -all"

Vous devez en savoir assez à ce point pour configurer vous même votre enregistrement SPF.

DKIM

DKIM ou DomainKeys Identified Mail est une technique plus compliquée de signature électronique du contenu de vos messages. DKIM est désormais définis par le RFC 6376 de l’IETF. Cette signature n’est pas propre à chaque expéditeur mais bien à chaque domaine. Cette technique est plus difficile à mettre en oeuvre car elle requiert la création et la publication dans votre enregistrement DNS de clés cryptographiques publiques et privées qui seront utilisées pour signer vos messages. Cela demande aussi l’intégration de modules de signature dans vos serveurs de messagerie ou la configuration de ces clés chez votre fournisseurs de services de messagerie. Par exemple, Google fournit ce service ainsi qu’un processus très simple permettant de générer les clés et de créer les enregistrements DNS nécessaires: https://support.google.com/a/topic/2752442?hl=fr&ref_topic=2683865

Pour l’intégration de DKIM (pour vérifier et/ou intégrer la signature dans vos emails), le site www.dkim.org fournit une liste des modules, payant ou gratuits, existants pour les nombreux serveurs et clients disponibles sur le marché. Nous reviendront ultérieurement sur la mise en oeuvre de DKIM.

DMARC

DMARC ou Domain-based Message Authentication, Reporting and Conformance est une technique qui permet de définir comment seront traités vos emails (ou les emails qui proviennent prétendument de votre domaine) par les récepteurs de ceux-ci. Il utilise aussi un enregistrement TXT dans votre DNS. DMARC vous permet de définir la fréquence et le destinataire d’un rapport avec l’état des emails reçus par chaque récipiendaire ainsi que le pourcentage de messages « illégitimes » (ou perçu comme tels) qui doivent être bloqués (ce qui permet une montée en puissance progressive de vos mesure de sécurité et de contrôles les éventuelles pertes de message).

DMARC possède lui aussi son groupe de travail et son site internet dmarc.org. Comme pour les autres techniques, il est défini dans un RFC IETF, le 7489.

Pas besoin de réinventer la roue ici, Google à publié un très bon document sur le sujet en français: https://support.google.com/a/answer/2466563?hl=fr

J’espère que tout cela est plus clair pour vous désormais et que vous allez ainsi pouvoir mieux sécuriser l’envoi de vos courriels.