Utilisateur d'origine : Pierre
Lorsqu'on administre un serveur mail, il y a un défi à relever : faire en sorte que les messages envoyés par les utilisateurs soient acceptés par les serveurs du destinataire, et ce, sans terminer dans la boîte SPAM de l'utilisateur final. Pour déterminer si un mail est indésirable ou non, le serveur se base bien sûr sur son contenu, mais une grande partie des critères utilisés concerne les spécifications techniques du serveur expéditeur. En effet, le serveur destinataire doit répondre à l'affirmative (entre autres) à ces deux questions :
- Le mail a-t-il bien été envoyé par le serveur correspondant à l'adresse de l'expéditeur ? (Pour information, l'adresse de l'expéditeur apparaissant dans l'en-tête du message est une déclaration simple de l'expéditeur, comme au dos d'une enveloppe. Il est donc très facile d'usurper l'identité de quelqu'un.)
- Suis-je certain que le mail n'a pas été altéré durant son transit ? (Le mail va être relayé par un bon nombre de serveurs, ce qui multiplie les risques de modification du message).
Afin que notre message passe avec succès ces deux tests, nous pouvons mettre en place divers sysèmes :
- DKIM : Signer le message afin de s'assurer qu'il provienne bien du domaine expéditeur déclaré, et qu'il n'a pas été altéré durant le transit
- SPF : Définir quels serveurs sont autorisés à envoyer des mails en mon nom, et définir la liste des domaines utilisés par mon serveur
- DMARC : Définir ce qu'il adviendra des messages qui tentent d'usurper mon identité
- rDNS : Faire correspondre avec certitude l'adresse IP du serveur d'envoi avec son domaine
Le reverse DNS est plus ou moins facultatif. En effet, d'après la RFC 5321, section 4.1.4, si le rDNS du serveur expéditeur n'est pas défini, le message ne devrait pas être rejeté. Par expérience, je peux vous garantir que certains serveurs SMTP outrepassent cette convention et refusent tous les messages provenant de serveurs dont le rDNS n'est pas défini.
Dans la suite de ce tutoriel, nous allons étudier le fonctionnement général de ces systèmes et décrire succintement comment les mettre en place.
DKIM
Principe
DKIM signifie DomainKeys Identified Mail. Cette technologie permet d'authentifier de manière fiable le nom de domaine de l'expéditeur. Ainsi, si je possède un serveur dont le domaine est example.com et que je signe mes mails avec DKIM, aucun autre serveur ne pourra envoyer de mails en utilisant mon domaine comme expéditeur. Pour ce faire, DKIM ajoute une signature cryptographique dans l'en-tête du message. La clé privée se situe sur le serveur expéditeur, et la clé publique sur le DNS du domaine.
Lorsqu'un message est prêt à être envoyé, le MTA (Mail Transfer Agent) calcule deux valeurs de hachage : une pour le contenu, et une pour l'en-tête du message. Ces valeurs sont ensuite chiffrées par DKIM et placées dans l'en-tête : c'est ce qui forme la signature DKIM. Une signature DKIM est donc constituée de deux valeurs de hachage chiffrées.
Le message arrive sur le serveur destinataire, puis est à nouveau traité par le MTA. Ce dernier récupère le domaine de l'adresse déclarée par l'expéditeur puis va rechercher sur le DNS la clé publique DKIM. Il décode ensuite la signature et récupère les valeurs de hachage. Si ces valeurs correspondent à celles qu'il a calculées à partir du message lors de la réception, il est alors certain que le message a bien été envoyé par un utilisateur du domaine déclaré, et que le contenu du message n'a pas été altéré pendant le trafic. Le message est donc légitime.
Un domaine peut disposer de plusieurs clés DKIM. Pour ce faire, il faut faire appel à des sélecteurs. A un sélecteur correspond une paire de clés. Sur le DNS, on retrouvera un enregistrement par sélecteur et par clé publique. Le sélecteur utilisé lors de la signature est indiqué dans l'en-tête du mail pour que le serveur destinataire sache quelle clé publique utiliser.
Mise en place
La mise en place de DKIM sur votre serveur mail doit se faire comme suit :
- Sur le serveur, génération d'une paire de clés et d'un sélecteur pour un domaine donné
- Enregistrement, sur le DNS, du sélecteur et de la clé publique
- Après la propagation DNS, activer DKIM sur le serveur pour commencer à signer les messages expédiés
La procédure de mise en place est différent pour chaque serveur mail. Si vous utilisez Zimbra, j'ai réalisé un tutoriel ici. Sinon, vous devez consulter la documentation de votre serveur pour connaître la procédure à suivre.
L'enregistrement DNS que vous aurez ajouté doit normalement respecter cette structure :
<sélecteur>._domainkey TXT v=DKIM1; k=rsa; p=<clé publique DKIM>
Après sa mise en place, vos mails seront signés par un bloc DKIM-Signature ajouté dans l'en-tête :
DKIM-Signature: v=1; a=rsa-sha256; s=selecteur; d=example.com;
c=simple/simple; q=dns/txt; i=pierre@example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=N2M0YThkMDljYTM3NjJhZjYxZTU5NTIwOTQzZGMyNjQ5NGY4OTQ
xYg==;
b=aWNpIGxhIHNpZ25hdHVyZSBkdSBtZXNzYWdlDQppY2kgbGEgc2ln
bmF0dXJlIGR1IG1lc3NhZ2UNCmljaSBsYSBzaWduYXR1cmUgZHUgbW
Vzc2FnZQ==;
Nous retrouvons plusieurs paramètres dans ce bloc :
v=1 est la version de DKIM utiliséea=rsa-sha256 indique l'algorithme utilisé pour générer la signature : SHA256 pour calculer la valeur de hachage, et RSA pour la chiffrers=selecteur indique le sélecteur utilisé pour générer la signature, que le serveur destinataire devra rechercher dans le DNS pour trouver la clé publiqued=example.com est le domaine de l'adresse déclarée par l'expéditeur, l'objectif est de déterminer si ce domaine correspond bien au domaine de l'expéditeur réelc=simple/simple est l'algorithme utilisé pour la canonicalisation du message. Il s'agit d'un procédé complexe dont je ne vous ai pas parlé, mais je vais vous en toucher deux mots. Lors de leur transfert par les différents serveurs SMTP, les e-mails peuvents subir des modifications mineures dans leur structure (sauts de ligne, espaces, alinéas, etc...). Ces modifications entraînent donc fatalement une modification de la valeur de hachage, et le mail est considéré comme frauduleux par le MTA. Pour remédier à cela, on supprime les parties "variables" du messages pour ne garder que les parties "immuables", et on calcule les valeurs de hachage à partir de cette version "standard", appelée forme canonique. Pour ce faire, il existe plusieurs algorithmes, et celui qui a été utilisé par le MTA expéditeur pour hacher le mail est indiqué par cette valeur c.q=dns/txt est la méthode utilisée pour récupérer la clé publique : ici, on cherche un enregistrement TXT sur le DNSi=pierre@example.com est l'adresse de l'expéditeur (tout du moins, celle qu'il prétend posséder)h est la liste des composants (dans l'ordre) de l'en-tête utilisés pour générer la valeur de hachage stockée dans bhb est la valeur de hachage du corps du message
Cas particuliers et limites
Si le message n'est pas signé avec DKIM et qu'aucune clé publique n'est présente sur le DNS du domaine expéditeur (la mise en place ou non de DKIM sur un domaine peut être connue grâce à une déclaration dans un enregistrement DMARC, voir plus loin), alors, le serveur destinataire sera dans l'impossibilité de vérifier l'authenticité et l'intégrité du message, et sera donc contraint de l'accepter (ou de se baser sur d'autres critères de détection des messages frauduleux).
Si un message échoue à la vérification de sa signature DKIM, le serveur destinataire devrait alors respecter la politique définie par le domaine usurpé grâce à DMARC (voir un peu plus bas dans le tutoriel).
La canonicalisation est une opération complexe et plus ou moins approximative. Il peut arriver que les serveurs SMTP relai effectuent des modifications dans la structure d'un message qui échappent à l'algorithme de canonicalisation. Dans ce cas, la valeur de hachage calculée par le MTA destinataire est différente que celle présente dans la signature DKIM, et le message est considéré comme frauduleux, alors que les modifications ne sont ni délibérées, ni fatales. DKIM n'est donc pas fiable à 100%, et des faux-négatifs peuvent exister.
Malheureusement, DKIM est trop peu mis en place sur les serveurs mail, surtout chez les fournisseurs d'accès à Internet, car les mails ne représentent généralement pas une priotité pour eux. Pourtant, la majorité des internautes ont une adresse de ce type, qui peut être facilement usurpée à cause de l'absence de DKIM.
SPF
Principe
SPF vient de l'anglais Sender Policy Framework. Comme DKIM, il est utilisé pour vérifier que l'expéditeur déclaré dans le champ FROM du message n'est pas factice ou usurpé. Pour rappel, l'expéditeur d'un e-mail peut choisir quelle adresse indiquer sur l'enveloppe SMTP, même si elle ne se situe pas à l'intérieur de son domaine.
SPF se résune à un enregistrement DNS sur le domaine à protéger contre l'usurpation. Cet enregistrement contient la ou les adresses IP (v4 ou v6) autorisées à envoyer des e-mails au nom de ce domaine, et la liste des domaines secondaires utilisés par ces serveurs. Ce deuxième élement n'est généralement pas utile si vous ne mettez pas en place de reverse DNS.
Lorsqu'il reçoit un mail, le serveur destinataire va alors effectuer une requête sur le DNS de l'expéditeur déclaré dans le champ FROM du message. Il récupère ainsi, dans l'enregistrement SPF, la liste des adresses IP autorisées à envoyer des e-mails. Si l'adresse IP du serveur expéditeur fait partie de cette liste, alors, le test est réussi.
Mise en place
SPF doit être mis en place pour chaque domaine géré par votre serveur. Sur le DNS, il suffit d'ajouter un enregistrement ressemblant à celui-ci :
@ TXT v=spf1 mx a:example2.com ip4:11.22.33.44 ip6:2001:db8:a0b:12f0::1 -all
Analysons ensemble cet enregistrement :
v=spf1 est la version du protocolemx signifie que le serveur pointé par l'enregistrement MX du domaine est lui-même autorisé à envoyer des mailsa:example2.com est un autre domaine géré par les serveurs autorisés, ceci sera surtout utile si vous mettez en place un reverse DNSip4 et ip6 sont les adresses IP (v4 et v6) des serveurs autorisés-all signifie que tout mail ne provenant pas d'un serveur autorisé doit échouer le test SPF, et potentiellement être rejeté
Si vous n'êtes pas à l'aise, ou que vous souhaitez vérifier votre enregistrement, vous pouvez générer un enregistrement SPF grâce à ce site.
Evidemment, dans mon cas, je vais effectuer la même opération pour le domaine example2.com, en précisant comme domaine alternatif example.com.
Limite
Contrairement à DKIM, SPF ne permet pas de garantir qu'un e-mail provient d'un nom de domaine légitime. Il permet juste de vérifier que le mail provient d'un serveur qui a été autorisé par le propriétaire du domaine à envoyer des mails au nom du domaine. Si je possède un serveur avec deux domaines : example1.com et example2.com, ces deux domaines auront la même adresse IP autorisée dans leur enregistrement SPF. Il sera alors possible pour les utilisateurs du domaine example1.com d'usurper l'identité des utilisateurs de example2.com et vice-versa.
DMARC
Principe
DMARC signifie Domain-based Message Authentication, Reporting and Conformance. Derrière ce nom à rallonge se cache un système ingénieux permettant aux serveurs mails de collaborer entre eux pour déterminer si un message est frauduleux ou non. En effet, DMARC permet à un propriétaire de domaine de préciser qu'il utilise DKIM et/ou SPF, et d'indiquer quel doit être le sort réservé aux messages qui tentent d'usurper son domaine. De plus, DMARC permet de spécifier une adresse mail sur laquelle les serveurs destinataires peuvent envoyer des rapports si des messages échouent aux vérifications DKIM/SPF. Cela permet à un propriétaire de domaine de savoir si quelqu'un tente d'usurper son domaine, ou bien si ses serveurs sont mal configurés (et donc que ses propres mails échouent à la vérification DKIM/SPF).
En clair, DKIM et SPF ont pour but de tester l'authenticité et l'intégrité d'un message. DMARC, lui, indique les opérations qui doivent être effectuées si un mail est frauduleux. Dans l'absolu, rien n'oblige le serveur destinataire à respecter la politique DMARC de l'expéditeur, mais dans ce cas, toute la collaboration que tente d'établir DMARC entre les différents serveurs tombe à l'eau.
Mise en place
Comme SPF, DMARC se met en place très simplement, il s'agit juste d'un enregistrement DNS. Voici sa structure :
_DMARC TXT v=DMARC1; p=none; rua=mailto:3aaf7360@mxtoolbox.dmarc-report.com; fo=1
Là encore, nous allons étudier un par un les constituants de cet enregistrement :
v=DMARC1 est la version du protocolep=none définit la politique à appliquer si un message échoue aux tests SPF/DKIM. none signifie que le message doit être accepté malgré tout, de simplement envoyer un rapport à l'adresse mail enregistrée plus loin dans l'enregistrement. quarantine et reject signifient respectivement : placer le message en quarantaine (boîte spam et/ou tag SPAM devant l'objet du message), ou le rejeter. Ces deux dernière politiques peuvent s'accompagner d'un argument pct qui définit le pourcentage (aléatoire) de messages à mettre en quarantaine / rejeter. Les messages échappant à ce pourcentage sont acceptés. Nous reviendrons sur les politiques à appliquer un peu plus tard.rua est le destinataire des rapports DMARC dits agrégés. Il s'agit d'un bilan (souvent quotidien) envoyé par les serveurs destinataires de vos messages, des mails échouant aux tests. Vous pouvez également spécifier une adresse ruf qui recevra des rapports individuels, pour chaque mail échouant aux tests.fo définit les tests auxquels le message doit échouer pour déclencher l'envoi d'un rapport détaillé. 0 signifie "DKIM ou SPF", 1 signifie "DKIM et/ou SPF", et enfin, d et s signifient respectivement "DKIM uniquement" et "SPF uniquement".
Si vous n'êtes pas à l'aise, ou que vous souhaitez vérifier votre enregistrement, vous pouvez générer un enregistrement DMARC grâce à ce site.
MxToolbox propose d'analyser les rapports DMARC pour vous. Si vous ne souhaitez pas utiliser ce système, mais plutôt rediriger les rapports vers une adresse qui vous appartient, répondez simplement "No" à la question "Would you like to have MxToolbox automatically process your DMARC reports for analysis and delivery insights ?".
Quelle politique appliquer ?
Le "danger" de DMARC est d'appliquer une politique trop stricte, qui conduirait au rejet de ses propres messages, à cause d'une mauvaise configuration de DKIM ou SPF (par exemple, des messages qui ne seraient pas signés).
Au début, il est préférable de définir une politique de non-rejet (none), et de vérifier (sur un intervalle de temps suffisamment long) que vous ne recevez pas de rapports pour des messages envoyés par vos propres utilisateurs. Si cette première étape est passée, vous pouvez augmenter la sévérité de votre politique et passer à quarantine. Si vous le souhaitez, vous pouvez définir un pourcentage aléatoire de messages qui respecteront cette politique (le reste sera accepté), pour effectuer un changement de politique en douceur. Enfin, si vous êtes sûr de votre configuration, vous pouvez passer à une politique de rejet systématique (reject).
Reverse DNS
Principe et mise en place
Pour schématiser, le reverse DNS est une technologie permettant de faire pointer une adresse IP vers un domaine (c'est l'opération inverse du DNS classique). Le propriétaire d'une adresse IP peut donc aisément indiquer au monde entier le domaine de l'organisation qui est associée à cette adresse. Le reverse DNS peut donc servir à identifier la personne qui gère une adresse IP, ou par exemple à identifier le fournisseur d'accès, dans le cas d'une IP résidentielle.
Le reverse DNS se base sur des enregistrements DNS particuliers, appelés PTR. Ces enregistrements sont présents sur le DNS du domaine spécial in-addr.arpa. Pour obtenir le reverse DNS de l'adresse IP 11.22.33.44, je vais effectuer une requête DNS sur 44.33.22.11.in-addr.arpa (l'adresse IP est "à l'envers" pour respecter les principes d'encapsulation) et j'obtiendrai un nom de domaine.
La mise en place d'un reverse DNS doit être effectué par le propriétaire du bloc IP dans lequel se situe l'adresse. Si il s'agit de Dyjix (car vous possédez un service VPS ou dédié par exemple), une simple demande au support suffit.
Utilité
Certains serveurs SMTP exigent que le reverse DNS du serveur expéditeur soit mis en place pour accepter ses messages, en dépit de la RFC 5321, section 4.1.4, qui indique qu'un reverse DNS inexistant n'est pas un critère suffisant pour rejeter un e-mail. Il faut donc que le reverse DNS de l'adresse IP du serveur expéditeur corresponde à l'adresse de l'expéditeur pour être accepté.
Si vous avez plusieurs domaines sur votre serveur, vous devrez déclarer les domaines alternatifs sur le DNS du domaine sur lequel pointe le reverse DNS pour que les messages provenant des domaines alternatifs soient acceptés.
Par exemple, imaginons que mon serveur mail ait l'adresse 11.22.33.44, pointant par reverse DNS vers example1.com et que jenvoie également des mails depuis example2.com. Pour que les mails envoyés avec ce second domaine soient acceptés, je devrai le déclarer dans l'enregistrement SPF de example1.com. Ainsi, quand le serveur destinataire effectuera la requêté, il vérifiera que le domaine fait bien partie de la liste des domaines alternatifs au domaine pointé par le reverse DNS.
Conclusion
Dans ce tutoriel plutôt théorique, nous avons pu étudier le fonctionnement et la mise en place de 4 technologies :
- DKIM, qui permet de signer les messages pour garantir leur origine et leur intégrité
- SPF, qui permet de définir quels serveurs sont autorisés à envoyer des mails au nom du domaine
- DMARC, qui "englobe" DKIM et SPF et qui définit la politique de l'expéditeur
- Et le reverse DNS, qui permet de déterminer le domaine associé à une adresse IP
DKIM, SPF et DMARC sont intimement liés dans leur fonctionnement, et le reverse DNS est un peu à part, mais fonctionne tout de même en collaboraton avec SPF pour la gestion des domaines alternatifs, c'est pourquoi j'ai décidé de l'inclure dans ce tutoriel.
Si vous mettez en place tous ces systèmes, vous mettez toutes les chances de votre côté pour ne pas que vos messages finissent dans la boîte SPAM de votre destinataire, et vous diminuez drastiquement les risques d'usurpation de votre domaine.
