Dans cet article, nous allons voir comment mettre en place des protocoles qui vont permettre d’authentifier un domaine de messagerie. Avant de présenter ces protocoles, nous allons faire un rappel du fonctionnement de la messagerie pour comprendre la problématique de la messagerie, puis nous verrons comment authentifier le domaine.
La messagerie électronique
La messagerie électronique est l’un des services les plus utilisés sur Internet. Nous avons près de 2 millions de mails qui sont envoyés par seconde à travers le monde(1). Mais comment est né ce service ? Il est apparu dans les années 1960 pour permettre de faire communiquer les différents utilisateurs dans le réseau ARPANET (ancêtre d’Internet). Ce service fût créé par M. Raymond Tomlinson en utilisant différents programmes qui sont: SNDMSG et READMAIL. Le premier programme permettait d’envoyer un message sur le même ordinateur, tandis que le second permettait de lire les messages. En couplant ces programmes ainsi que l’application CPYNET (permet d’envoyer des données à travers un réseau), M. Tomlinson à réussi à envoyer le premier message électronique. La messagerie est née.
Au vu du succès de ce service, différents protocoles sont apparu mais aussi des normes pour permettre d’utiliser la messagerie sur des équipements différents. C’est en 1981 que l’IETF (Internet Ingeneering Task Force) normalisa le protocole SMTP (Simple Message Transfer Protocol) qui va permettre d’envoyer un message dans un réseau TCP/IP. La RFC 821 décrit ce protocole dans sa première version, mais au fil du temps, différentes version sont apparues dont la dernière en date est la RFC 5321. Pour permettre d’envoyer un message, il suffisait de se connecter sur une passerelle SMTP via le protocole TELNET et de saisir une suite de commande. Les messages sont ensuite transmis de passerelle en passerelle jusqu’à atteindre la destination.
Envoyer les messages c’es bien, mais les lires, c’est encore mieux. C’est pour cela qu’est apparu le protocole POP (Post Office Protocol) qui à permit de lire tous ces mails en s’authentifiant sur un serveur via un couple login/mot de passe. Ce protocole fût décrit dans la RFC 918 en 1988. L’inconvénient majeur de POP, c’est qu’il télécharge tous les messages et ne conserve aucune copie sur le serveur. En cas de perte de message sur la machine, ils seront définitivement perdus. C’est pour cette raison qu’est apparu le protocole IMAP (Internet Mail Access Protocol) en 1988 dans la RFC 1064. L’avantage de ce protocole c’est qu’il copie les messages sur la machine ce qui permet d’accéder à ses messages depuis n’importe quelles ordinateurs.
Connaître les principaux protocoles c’est une chose, mais comment fonctionne la messagerie grâce à ces protocoles ? Pour mieux comprendre ce fonctionnement, nous allons voir avec une analogie que tout le monde connaît qui est le courrier postal. Lorsque nous souhaitont envoyer un courrier à une connaissance, nous mettons notre message dans une enveloppe qui va contenir l’adresse du destinataire avec le nom, le prénom, la rue destination ainsi que la ville et le code postal, mais aussi l’adresse de l’expéditeur, puis nous devons l’affranchir et enfin aller dans un bureau de poste le plus proche pour poster notre lettre. Lorsque les agents postaux vont récupèrer les lettres, il vont analyser la ville de destination, puis la transmettre dans le centre de distribution de la ville de destination, cependant, les courriers ne vont pas directement dans le centre de distrubution de destination, mais peuvent passer de centre en centre. Par exemple, une lettre est envoyé depuis Paris et doit être envoyé à Nice, la lettre passera dans le centre de distribution de Paris, puis va être transmit dans celui de Lyon et enfin dans celui de Nice. Lorsque la lettre est enfin arrivé dans la ville de destination, les agents postaux vont faire une tournée pour poster les lettres dans les boites aux lettres de destination en fonction du nom et du prénom ainsi que de la rue.
La messagerie électronique repose sur le même schéma des courriers postaux. Un utilisateur va rédiger un message grâce à un logiciel de messagerie, puis le logiciel va ajouter dans ce message un en-tête SMTP qui est tout simlement l’enveloppe. Cet en-tête est une structure de données qui contient différentes directives qui vont permettre d’envoyer un message. L’exemple ci-dessous nous illustre un en-tête SMTP:
Date: Sun, 5 Feb 2017 18:16:29 +0100 (CET)
From: [email protected]
To: [email protected]
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_96992773_1195490604.1486314989602"
X-Originating-IP: [1.2.3.4]
X-Authenticated-User: [email protected]
------=_Part_96992773_1195490604.1486314989602
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Test d'un message
Dans l’exemple ci-dessus, ont peut voir deux directives importantes. La première est la directive From qui contient l’adresse de l’expéditeur mais aussi la directive To pour l’adresse du destinataire. D’autres directives permettent d’indiquer le type de format du message, ici, nous voyons que nous utilisons un encodage UTF-8 et que notre message est du texte brut text/plain indiqué dans la directive Content-Type. Cette directive est très utile, puisqu’ont peut spécifier le format du message, par exemple, ont peut très bien indiqué d’utiliser des balises HTML pour faire la mise en forme de notre message, mais nous ne rentrons pas plus loins dans les détails des différentes directives, je vous invite à lire les RFCs 822 et 2045 pour obtenir plus de détails sur ces directives.
Après que le logiciel est ajouté l’en-tête SMTP au dessus de notre message, qui est ici Test d’un message, le message sera transmit à une passerelle SMTP qui est souvent celui de notre FAI. Notre message sera ensuite relayé de passerelle en passerelle jusqu’à atteindre la destination. Une fois arrivé dans le serveur SMTP de destination, le message sera transmis dans la boite aux lettres de l’utilisateur. A cette étape, nous avons transmit notre message. Lorsque l’utilisateur se connectera sur le serveur, il va récupérer le nouveau message via le protocole POP ou IMAP et va pouvoir le lire.
La figure ci-dessous nous fait un lien entre l’infrastructure du réseau de La Poste et celui de la messagerie électronique ainsi que les éléments que composent ce service:
Comme le montre la figure ci-dessus, l’infrastructure de la messagerie électronique intègre plusieurs composants:
- MUA (Mail User Agent): c’est le client de messagerie qui peut être un client lourd ou un webmail. Ce client prend en charge le protocole SMTP et POP/IMAP.
- MTA (Mail Transfer Agent): cet agent à pour rôle de relayer les messages qu’ils recoient entre les différents MTA jusqu’au destinataire. Chaque agent communique via le protocole SMTP.
- MSA (Mail Submission Agent): cet agent à pour rôle de transmettre le message au MTA du domaine expéditeur. Le terme submission fait référence à un utilisateur qui se connecte sur le serveur SMTP de son entreprise à distance (hors du domaine de l’utilisateur). La plupart du temps, le MSA est installé sur le serveur MTA.
- MDA (Mail Delivery Agent): c’est la boite aux lettres de l’utilisateur pour qu’il puisse récupérer ces messages via le protocole POP ou IMAP. Un MDA est souvent installé sur un MTA.
Mais une question se pose. Comment les MTA délivrent les messages jusqu’à la destination ? Une adresse mail est au format suivant user@domaine et est composé de deux parties séparées par un @:
- user
- domain
La partie domain, identifie le domaine DNS de l’utilisateur. C’est souvent un opérateur de messagerie ou une entreprise, tandis que le partie user identifie l’utilisateur dans le domaine. Par exemple, une adresse mail [email protected], indique que l’utilisateur test fait partie du domaine example.com.
C’est grâce au domaine que les MTA relaient les messages jusqu’au MTA de destination. Prenons le cas de figure suivant. L’utilisateur [email protected] souhaite envoyer un message à l’utilisateur [email protected]. L’utilisateur du domaine example.com va transmettre son message au MSA/MTA de son entreprise et ce dernier va relayer le message à l’agent MTA de example.org, car c’est le domaine de destination. A cette étape-là, le MTA sait que l’utilisateur user2 fait partie dans son domaine et va donc transmettre le message au MDA du domaine pour que l’utilisateur puisse récupérer son message. La figure ci-dessous illustre ce fonctionnement:
Mais comment un MTA trouve le MTA de destination ? Grâce aux serveurs DNS (Domain Name System). Le MTA va contacter le serveur DNS faisant autorité du domaine destinataire pour obtenir les entrées MX. C’est dans ces entrées que contiennent les MTA. Voici un exemple d’une entrée MX:
example.org 3600 IN MX 10 mta.example.org
Dans cette exemple, on peut voir que pour envoyer un message au domaine example.org, il faut relayer le message au MTA mta.example.org. La valeur 3600 correspond ici à la taille maximum pour la durée du cache DNS, tandis que la valeur 10 est une priorité. Il est possible d’avoir plusieurs MTA pour un domaine. Le MTA expéditeur va choisir le MTA ayant la priorité la plus faible. La figure ci-dessus illustre le fonctionnement de la résolution DNS:
L’usurpation d’identité
Dans la section précédente, nous avons vu le fonctionnement de la messagerie et les différents protocoles, cependant, le protocole SMTP ne fournit aucun moyen d’authentification de l’utilisateur, ont peut très bien se faire passer par quelqu’un d’autres en envoyant un message depuis un serveur SMTP jusqu’à un destinataire dans le but d’envoyer des SPAMs, c’est de l’usurpation de mail ou email spoofing.
Les attaquant usurpent l’identité d’utilisateurs pour ce cacher dernière une identité et permettre ainsi de commettre leurs méfaits. Pour illustre l’usurpation d’identité, prenons le cas de figure suivant : un utilisateur reçoit un mail de sa banque indiquant des problèmes sur son compte. Ce dernier, non conscient des risques, clique sur le lien indiqué dans le message et s’authentifie sur le site de la banque et saisit ensuite ces informations banquaires (numéro de carte, cryptogramme, date d’expiration, etc), mais voilà, le site était factice et l’attaquant s’est fait passer par un conseiller banquaire. Toutes les informations que l’utilisateur à saisit va permettre à l’attaquant d’accéder au véritable compte banquaire de la victime et va pouvoir effectuer des transactions. Si la banque n’a pas mis de protection 3-D Secure (permets de vérifier que la transaction est bien effectuée par le titulaire du compte), les débits de son compte seront effectués. Ce type d’attaque se nome phishing et exploite la faiblesse de l’utilisateur.
L’usurpation d’adresse mail peut aussi avoir des conséquences pour les entreprises. Récemment, la société Vinci en a fait les frais(3). Cette dernière a subi une perte de 18% dans la bourse. Et pour cause, un groupe se faisant passer pour Vinci à émis un communiqué indiquant le licenciement d’un directeur financier, ce communiqué a fait chuter Vinci dans la bourse en seulement quelques minutes.
Lorsque notre adresse mail vient d’être usurpée, le domaine émetteur peut très bien être mis sur liste noire. En effet, un attaquant ne va pas se contenter d’envoyer un eul message, mais une multitude de message. Un opérateur de messagerie peut s’il le souhaite mettre ce domaine sur liste noire, ce qui peut avoir des conséquences graves pour une entreprise puisque sont image sera dégradée.
Comme le montre la figure ci-dessous, plus de 50% des messages envoyés à travers le monde sont des SPAMs, ce qui potentiellement sont des risques d’attaques pour les entreprises ou les particuliers.
Source: http://www.symantec.com/security_response/landing/spam/
Pour permettre de se protéger contre les SPAMs et éviter d’être mis sur listes noire, nous allons découvrir dans la section ci-dessous trois principaux protocoles qui vont permettre d’authentifier notre domaine de messagerie.
Authentification du domaine émetteur
Maintenant que nous avons vu la problématique avec SMTP, nous allons voir dans cette section différents protocoles qui vont permettre de nous protéger contre les risques d’usurpation d’identité et que nos messages soient considérés comme des SPAMs.
Autorisation des serveurs SMTP
Le premier protocole que nous allons étudier est SPF (Sender Policy Framework). Ce protocole est normalisé dans la RFC 7208(4) et va permettre d’autoriser les serveurs SMTP à émettre un message pour un domaine émetteur et permettre ainsi d’éviter l’usurpation d’un domaine de messagerie.
Mais comment SPF fonctionne-t-il ? Il va vérifier si l’entité émetteur, que ce soit un hôte où bien un serveur, est autorisé à émettre un message pour ce domaine. Par exemple, un MTA initie une session SMTP avec un autre MTA pour relayer le courrier, le MTA de destination va vérifier si le MTA émetteur est autorisé à émettre le message. Pour permettre de vérifier si le MTA est autorisé, il va contacter le serveur DNS du domaine émetteur et vérifier si l’équipement est autorisé grâce à une entrée DNS spécifique. Ce processus peut être illustré comme suit:
Comme le montre la figure ci-dessus, le MTA du domaine example.org implémente SPF et effectue une requête DNS pour obtenir l’entrée SPF. Lorsqu’il reçoit la réponse DNS, il va vérifier si cette entrée comporte l’entité MTA du domaine example.com. Si le serveur MTA est autorisé, alors il va pouvoir transmettre le message à l’utilisateur. Dans le cas où le serveur n’est pas autorisé, le message peut être considéré comme du SPAM soit il est supprimé, mais c’est une décision locale (Cf. section 8.4 de la RFC 7208(4)). Par ailleurs, en cas d’erreur, un code de retour SMTP peut être envoyé à l’expéditeur pour l’informer de l’échec de la transmission du message.
Mais que ce passe-t-il si une entrée SPF n’existe pas dans le DNS ? Cela va dépendre du MTA. S’il le souhaite, il peut supprimer tous les messages qui n’ont pas été authentifié, mais c’est une solution radicale, soit de les considérés comme du SPAM.
Les autorisations SPF sont stockées dans une entrées DNS de type TXT qui contient toutes les entités autorisées à émettre un message. L’exemple ci-dessous permet d’autoriser les entités 1.1.1.2 et mta.example.org et les autres seront pas autorisés:
mta 38400 IN A 1.1.1.1
mta2 38400 IN A 1.1.1.2
example.org 38400 IN TXT "v=spf1 a:mta.example.org ip4:1.1.1.2 -all"
L’utilisation de SPF va empêcher les autres serveurs SMTP d’utiliser notre serveur comme relais, cela peut aussi avoir un impacte sur les utilisateurs nomades qui se connectent hors du domaine de messagerie au serveur interne de l’entreprise. Prenons le cas de la figure ci-dessous, l’utilisateur de l’entreprise example.org ne pourra pas envoyer de message puisque le serveur SMTP de son FAI n’est pas autorisé à relayer un message:
Mais vous me direz qu’il suffit à l’utilisateur d’utiliser le serveur SMTP de son entreprise et non de son FAI. Et j’ai envie de vous dire oui, cependant, la plupart des FAI vont bloquer l’accès des serveurs SMTP externes autres que celui du FAI pour éviter les SPAMs. Mais y’a une solution, l’utilisation du port de soumission. Le port de soumission va permettre à un utilisateur nomade d’utiliser le serveur interne de l’entreprise après qu’il ce soit authentifié. Contrairement au protocole SMTP qui écoute sur le port 25, le port de soumission fournit deux méthodes d’accès:
- Connexion sur le port 587(5) en utilisant STARTTLS (protocole qui s’appuie sur TLS pour sécuriser une session SMTP)
- Connexion sur le port 465 en créant un tunnel SSL/TLS
La méthode de connexion via STARTTLS consiste à établir une session ESMTP (Extended SMTP) auprès du serveur SMTP de l’entreprise, puis d’utiliser le protocole STARTTLS pour authentifier les entités et sécuriser les échanges. La seconde méthode consiste à établir un tunnel SSL/TLS, puis dans ce tunnel, nous pouvons lancer une session SMTP pour l’envoi du message.
Comment l’utilisateur sais que le mail est considéré comme légitime et non un SPAM ? Lorsqu’un serveur SMTP implémente SMTP, il va ajouter une nouvelle directive dans l’en-tête SMTP et indiquer le résultat de la vérification SMTP. L’exemple ci-dessous nous indique la directive SPF:
Received-SPF: pass (example.org: domain of [email protected] designates 1.1.1.1 as permitted sender) client-ip=1.1.1.1
Comme le montre l’exemple ci-dessus, le serveur SMTP du domaine example.org a effectuer un contrôle SPF et grâce au résultat de sa requête DNS, il indique que le serveur SMTP 1.1.1.1 est autorisé à émettre le message pour le domaine example.com. Dans le cas où le message ne passe pas le contrôle SPF, le message sera considéré comme fail. Grâce à cette directive, il est possible de mettre des filtres au niveau du logiciel de messagerie de l’utilisateur et de placer tous les messages non autorisé dans la corbeille.
Avantages et inconvénients de SPF
Comme nous l’avons vu, SPF va permettre de supprimer les relais SMTP qui ne sont pas autorisé à émettre un message pour un domaine de messagerie et permettre ainsi de fournir une barrière supplémentaire contre l’envoi des SPAMs.
SPF s’appuie sur l’architecture DNS et cela induit une charge sur ces serveurs, puisque pour chaque message, une requête DNS est effectuée, or, en cas de nombreuse requêtes, cela aura comme concéquence la réalisation d’une attaque DDoS. Pour palier à ce problème, SPF n’autorise que seulement 10 requêtes DNS pour un seul message. Par ailleurs, il est important de garantir une haute disponibilité du service DNS, puisqu’en cas de panne d’un des serveurs, tous les messages seront considérés comme SPAM en utilisant des solutions comme heartbeats où autre technologie propriétaire.
Une autre bonne pratique durant la mise en place de SPF est d’utiliser DNSSEC pour garantir l’intégrité des données. En effet, un attquant peut très bien ajouter de fausse entrée SPF en utilisant la techique d’empoisonnement DNS pour que ces serveurs soient autorisés à émettre un message et celui lui permettra de continuer à envoyer des SPAMs.
Signature du domaine expéditeur
Le protocole SPF va permettre d’autoriser les entités à émettre un message pour un domaine et éviter ainsi l’usurpation d’un domaine de messagerie. Il existe un autre protocole qui va permettre de fournir une protection supplémentaire contre les SPAM et d’éviter que le domaine émetteur ne soit usurpé. Ce protocole ce nomme DKIM (DomainKeys Identified Mail). DKIM est normalisé dans la RFC 6376(6) et va permettre de signer tous les messages et permettre de garantir l’authenticité et l’intégrité du mail.
Comment DKIM fonctionne-t-il ? DKIM s’appuie sur un chiffrement asymétrique, c’est-à-dire qu’il nécessite la génération d’une clé privée et d’une clé publique. Tout d’abord, le MTA expéditeur va créer une empreinte numérique grâce à une fonction de hachage, puis il va signer cette empreinte via la clé privée. Cette signature sera ensuite ajoutée dans l’en-tête SMTP du message pour être ensuite transmit au MTA destinataire. Lorsque ce dernier recevra le message, il va déchiffrer la signature du message via la clé publique et obtenir l’empreinte chiffrée, puis il va comparer cette empreinte avec l’empreinte qu’il aura générée du message. Si les empreintes sont correctes, alors le MTA de destination s’aura que le message provient bien du domaine example.org. Mais fournir la clé publique ? Tout comme SPF, DKIM s’appuie sur les serveurs DNS qui vont stocker la clé publique dans un enregistrement TXT. La figure ci-dessous nous illustre un diagramme de séquence pour le fonctionnement de DKIM:
DKIM ne va pas signer que le message lui-même, mais d’autres champs annexes, qui sont l’adresse de l’expéditeur et du destinataire, ainsi que la date du message pour ainsi assurer l’authenticité des données qui ont été transmises. Comme nous l’avons vu précédemment, DKIM va ajouter une directive dans l’en-tête SMTP qui va contenir notre signature, cependant, il ajoute d’autres éléments. L’exemple ci-dessous, est un extrait d’une en-tête SMTP qui contient notre directive DKIM:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
s=E3D915AE-5644-11E7-AC1B-8B071EE04938; t=1504679551;
bh=+EHHh00ewffzbuGK57PsBMQxWWf+3rRkyB40fJm9btA=;
h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type;
b=ANOWCm+Zkg0sxxqkA7c0TDg1YfjT2KxAd5lIRPKtCdpU/frjgIiQvzaCao9Kb8fAF
VLi0wBaOpF6JR7OWyRmaiuCBq86ekaCy8K3RwcPJwS5fUwvPpETW2ffxJ9BQB3+avp
770wU57Hy3Jlz8VZoWDKA4UJUNzKXABYC9PVL7/k=
Comme le montre l’exemple ci-dessous, notre directive contient différents champs au format champ=valeur. Le tableau ci-dessous récapitule tous les champs dans l’exemple ci-dessous. Je vous invite à lire la section 3.5 de la RFC 6376(6) pour obtenir tous les champs possibles.
Lorsque le MTA de destination à fini de déchiffrer le message et vérifier l’intégrité de celui-ci, il va ajouter dans l’en-tête SMTP le résultat. Si la signature correspond, alors, il va indiquer dans l’en-tête SMTP que la validation DKIM est un succès et prendra la valeur pass, dans le cas contraire, la valeur sera fail. Dans l’exemple ci-dessous, ont peut voir que le résultat de DKIM est un succès:
Authentication-Results: example.org
dkim=pass [email protected] header.s=E3D915AE-5644-11E7-AC1B-8B071EE04938 header.b=ANOWCm+Z;
Mais que faire des messages qui n’ont pas été validé par DKIM ? Cela va dépendre d’une décision locale, ont peut très bien indiquer de supprimer tous les messages ou qu’ils soient considérés comme des SPAM et ce sera l’utilisateur qui effectuera le trie des messages.
Avantages et inconvénients
DKIM permet d’authentifier le domaine émetteur en appliquant une signature au message mais garantie aussi l’intégrité et l’authenticité du message grâce aux algorithmes de hachage et de chiffrement. Comme il est stipulé dans la section 3.3.3 de la RFC 6376(6), il faut générer une paire de clé avec une longueur d’au moins 1024bits pour éviter que la clé de chiffrement soit facilement cassé. Par ailleurs, une bonne préconisation est de renouveller au minimum une fois par an les clés de chiffrements.
Tout comme SPF, DKIM s’appuie sur les services DNS pour le partage des clés publiques et il est donc important de mettre en place des solutions pour garantir une disponibilité du service mais aussi de se protéger des attaques qui peuvent corrompre les entrées DNS en utilisant la technologie DNSSEC.
SPF + DKIM
SPF et DKIM sont des protocoles qui vont permettres d’authentifier un domaine émetteur en autorisant les équipements à émettre un message pour un domaine et d’ajouter une signature numérique au message, cependant, ils agissent de façon indépendantes. Le protocole DMARC (Domain-Based Message Authentication, Reporting and Conformance) est décrit dans la RFC 7489(7) et va combiner SPF et DKIM.
DMARC va simplement appliquer une politique lors de l’échec de l’authentification SPF/DKIM définit par le domaine émetteur mais aussi d’envoyer un rapport en cas d’échec. Cette politique va définir quelle action à effectuer et qui sont:
- Ne rien faire
- Mettre le message en quarantaine, c’est-à-dire de le considérer comme étant un SPAM
- Supprimer le message
A l’image de SPF et DKIM, DMARC utilise une entrée DNS pour stocker les éléments qui vont permettre à DMARC de fournir la politique à appliquer mais aussi l’adresse mail pour les rapports d’échec. L’exemple ci-dessous est tiré de la RFC 7489(7) et présente un exemple d’une entrée TXT dans le DNS:
_dmarc IN TXT ("v=DMARC1; p=quarantine;"
"rua=mailto:[email protected];"
"ruf=mailto:[email protected];"
"adkim=r; aspf=r;")
Le tableau ci-dessous indique les différents champs présents dans l’entrée DNS ci-dessus. Je vous invite à lire la section 6.3 de la RFC 7489(7) qui expliquent tous ces champs en détails.
Conclusion
De nos jours, la message est un service devenue omniprésent dans notre sociéte, puisque nous l’utilisons tous les jours, que ce soit pour les particuliers ou les professionnels. Dans le cas d’une entreprise, il est vivement recommandé de mettre en place des outils qui vont permettre de sécuriser la messagerie, puisque c’est l’un des principaux vecteurs d’attaques et de transmission de virus pour y placer des logiciels d’espionnage mais aussi pour obtenir des informations confidentielles et cela peut nuire à l’image de l’entreprise et occasionner des pertes financiers en cas d’infection virale.
Les technologies que nous venons de voire sont des barrières supplémentaire dans la sécurisation du service de la messagerie, mais la meilleure protection est la sensibilisation des risques aux utilisateurs façon de se protéger et de former les utilisateurs aux risques qu’encours une entreprise et comment analyser les différents messages qui peuvent être frauduleux. Je vous invite à lire cette article pour la détection des courriers malveillants rédigé par la CNIL.
Sources
Voici les sources qui m’ont permit de rédiger cet article: