Serveurs de messagerie
La messagerie électronique est l'une des applications les plus anciennes des réseaux informatiques. Sur le réseau ARPANET, ancêtre d'Internet, la messagerie électronique est apparue en 1969.
Fonctionnement d'un courriel
Un courriel se présente sous la forme d'un fichier texte. Voici un exemple du contenu d'un courriel simple :
Received: from iutdijon.u-bourgogne.fr (iut-dijon.u-bourgogne.fr [193.52.232.3]) by example.com (Postfix) with ESMTPS id 1AE55DFE90 for <jbonbeur@example.com>; Fri, 4 Dec 2020 13:37:18 +0100 (CET) Received: by example.com (Postfix, from userid 127) id 4C1FDDFE19; Fri, 4 Dec 2020 13:37:42 +0100 (CET) From: Antoine Pernot <antoine.pernot@iut-dijon.u-bourgogne.fr> To: Jean Bonbeur <jbonbeur@example.com> Subject: Bonjour ! Date: Fri, 4 Dec 2020 13:37:42 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Message-ID: <754c82a5-9ac6-5d90-b7ec-d897946b7212@iut-dijon.u-bourgogne.fr> Bonjour le monde ! Ceci est un message d'exemple. Antoine
Chaque boîte de réception est un répertoire sur le serveur de messagerie ou un fichier texte dont tous les messages se suivent. Cela est défini dans la configuration du serveur SMTP.
Lors de l'envoi d'un courriel, l'acheminement se fait comme suit :
- Le courriel est rédigé, puis envoyé en SMTP depuis le Mail User Agent (MUA) (plus simplement client de messagerie), vers le serveur SMTP également nommé Mail Transfer Agent (MTA).
- Le premier MTA envoie le courriel vers le MTA du domaine destinataire.
- Le MTA destinataire transfère le message au Mail Delivery Agent (MDA) qui héberge la boîte de réception du destinataire.
- Le client de messagerie du destinataire (MUA) interroge le MDA afin de récupérer les nouveaux messages en IMAP 4 ou POP 3.
- Le MDA répond à la requête en fournissant le message envoyé.
Il est courant d'héberger le MTA et le MDA sur le même serveur.
Les champs destinataires
Une adresse courriel se compose comme suit :
| alain | @ | example.com |
| Identifiant utilisateur | Séparateur symbolisant "chez" | Domaine |
Le système de courriel admet trois champs permettant de renseigner :
- Les destinataires principaux.
- Les destinataires en copie dont l'adresse est visible par les autres destinataires : Copie carbone "Cc".
- Les destinataires en copie dont l'adresse n'est pas visible par les autres destinataires : Copie carbone invisible "Cci".
Dans les faits, même si un message est destiné à plusieurs destinataires, un seul courriel est acheminé au MTA qui se chargera de le dupliquer pour chaque destinataire.
Le serveur d'envoi : SMTP
Le protocole utilisé pour l'envoi de courriels est le Simple Mail Transfer Protocol (SMTP). Il écoute par défaut sur les ports suivants (selon la configuration) :
- TCP 25 (sans chiffrement)
- TCP 465 (chiffrement implicite)
- TCP 587 (chiffrement explicite)
Il s'agit d'un protocole simple permettant de se connecter à un serveur et d'envoyer un message en saisissant quelques commandes. Voici ci-dessous un exemple d'envoi de message en saisissant manuellement les commandes SMTP. Ces opérations sont réalisées par le MUA émetteur lors de l'envoi de message.
$ telnet example.com 25 Trying 93.184.216.34... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Postfix (Debian/GNU) HELO antoine 250 example.com MAIL FROM: <antoine@example.com> 250 2.1.0 Ok RCPT TO: <alain@example.com> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: Bonjour ! Bonjour le monde ! Ceci est un message d'exemple. Antoine . 250 2.0.0 Ok: queued as DE0C7DF3EB QUIT 221 2.0.0 Bye
Multipurpose Internet Mail Extensions (MIME)
Initialement, le protocole SMTP ne supporte que l'envoi de textes encodés en ASCII. Le support des autres encodages de caractères (Unicode), ainsi que des fichiers multimédia (images, sons, vidéos, documents bureautiques) est apporté par le format Multipurpose Internet Mail Extensions (MIME).
Des en-têtes supplémentaires spécifiques à MIME sont ajoutées à celles par défaut afin que le client de messagerie destinataire soit informé du format, de l'encodage ou de la présentation du courriel pour l'interpréter correctement.
Il permet ainsi d'étendre les fonctionnalités de la messagerie sans avoir à remplacer les serveurs existants.
Voici quelques en-têtes courantes pour un courriel :
- MIME-Version : Indique que le message utilise MIME et fournit la version de MIME utilisée (en général 1.0).
- Content-Type : Définit le format du message. Les plus courants sont :
- text/plain pour du texte simple.
- text/html pour du contenu formaté en HTML.
- multipart/alternative pour envoyer un message contenant plusieurs formats à la fois (HTML et texte simple). Le client de messagerie destinataire choisira le format désiré.
- multipart/encrypted pour les messages chiffrés.
- multipart/signed pour les messages signés cryptographiquement.
- multipart/mixed pour l'envoi des pièces jointes. Chaque élément du message (pièces jointes et texte) est désigné alors par son propre en-tête Content-Type et est séparé des autres par un délimiteur spécifié précédé d'un double trait d'union.
Content-Type: multipart/mixed; boundary="delimiteur_multipart" MIME-Version: 1.0 Ce courriel contient une pièce jointe --delimiteur_multipart Content-type: text/html; charset=utf-8 Ce courriel contient une <strong>pièce jointe</strong> --delimiteur_multipart Content-type: image/gif Content-transfer-encoding: base64 R0lGODlhQAAQAKEAADRJXv///zRJXjRJXiH5BAEKAAIALAAAAABAABAAAAJmhI+py+0Po5y02ruC 3uFw7mxYpCGl2UHi+JyG+6ZhB9e0uzJ2Aus3CgTgZD5Pr6cYGoPCX+tDjD2XUmosWqwyfR9rE4XN EI9h7/esLSGT4+jafBqmlDNeu7GOi9Rylv8PGCg4yFIAADs= --delimiteur_multipart
Exemple de courriel type multipart/mixed
Pour les données de type text, une spécification sur l'encodage peut y être ajoutée : Content-type: text/html; charset=utf-8
- Content-Transfer-Encoding : Cette en-tête spécifie la méthode utilisée pour convertir les données sous la forme d'une chaîne de caractères ASCII :
- 7bit indique qu'aucune transformation n'a été appliquée
- quoted-printable indique que les caractères non pris en charge dans l'encodage ASCII ont été remplacés par la représentation hexadécimale du ou des octets du caractère, précédé par "=". Par exemple, le caractère "é" de l'encodage UTF-8 est remplacé par =C3=A9. Cela permet d'encoder les caractères non ASCII tout en gardant la lisibilité du message.
- base64 indique que le contenu a été encodé en base64. Chaque groupe de 6 bits a été représenté par un caractère ASCII. Cette méthode permet d'encoder des données binaires, mais cela augmente d'un tiers la taille de la donnée et la rend humainement illisible.
Relais SMTP
Comme son nom l'indique, un relais SMTP permet de transférer les messages émis par un serveur SMTP vers le serveur destinataire. Du point de vue du serveur destinataire, le message provient du serveur relais et non du serveur initial. Cette opération est utile lorsque le serveur SMTP émetteur ne remplit pas les critères nécessaires pour être reconnu comme légitime (adresse IP publique dans une plage d'adresse IP fixe, reverse DNS, etc.).
Le serveur de consultation : IMAP et POP
La consultation des mails sur le MDA peut se faire avec les protocoles Internet Message Access Protocol (IMAP) 4 ou Post Office Protocol (POP) 3.
Le protocole le plus utilisé actuellement est le protocole IMAP car, dans sa configuration par défaut, il laisse les messages sur le serveur. Quant à lui, le POP, par défaut, supprime les messages du serveur après les avoir rapatriés sur le client de messagerie.
De plus, le protocole IMAP permet de modifier l'état de chaque message sur le serveur (lu/non lu, répondu, transféré, etc.). Ainsi, le protocole IMAP est plus adapté pour une configuration dans laquelle plusieurs clients de messagerie différents consultent une même boîte de messagerie (ordinateur, téléphone, tablette, etc.).
Le POP non sécurisé écoute sur le port TCP 110 et la version sécurisée sur le port TCP 995. L'IMAP non sécurisé écoute sur le port TCP 143 et la version sécurisée écoute sur le port TCP 993.
Aller à l'exercice 1 Aller à l'exercice 2
Signature et chiffrement cryptographiques
Les procédés de signature et de chiffrement cryptographiques apportent des garanties supplémentaires pour le destinataire du message et ajoutent de la sécurité à la communication.
Les standards de chiffrement et de signature les plus courants sont S/MIME, PGP/Inline et PGP/MIME. Ils se basent sur la cryptographie asymétrique.
Contrairement au chiffrement symétrique qui utilise la même clef pour chiffrer et déchiffrer, le chiffrement asymétrique utilise deux clefs :
- La clef publique pouvant être diffusée auprès des tiers avec lesquels on communique.
- La clef privée devant être gardée secrète.
Ainsi, il est nécessaire à ce que l'expéditeur possède la clef publique du destinataire afin de chiffrer ou signer un message lui étant destiné.
Voici la terminologie à employer :
- chiffrer : Transformer un message en clair en un message inintelligible pour assurer le secret de sa transmission.
- déchiffrer : Traduire en clair un message chiffré à l'aide de la clef de déchiffrement.
- décrypter : Traduire en clair un message chiffré en ignorant la clef de déchiffrement.
Le chiffrement
Le chiffrement permet de rendre illisible le contenu du message à toute personne ne possédant pas la clef de déchiffrement (clef privée dans le cas d'un chiffrement asymétrique).
L'envoi d'un message chiffré de A vers B se fait comme suit :
- Le message en clair est chiffré à l'aide de la clef publique de B.
- Le message chiffré est envoyé à B.
- Le message est déchiffré par la clef privée de B.
La signature numérique
La signature numérique permet de garantir l'origine du message et son intégrité. Elle possède les avantages suivants :
- Elle est authentique et infalsifiable : le signataire est identifié et son identité ne peut être usurpée.
- La signature est à usage unique : on ne peut pas réutiliser la signature d'un message pour en signer un second.
- Le document est inaltérable : s'il est modifié, la signature devient invalide.
- La signature est irrévocable : le signataire ne peut pas nier la signature vu qu'il est seul a posséder la clef privée.
Ainsi, la signature numérique propose de nombreux avantages par rapport à la signature manuscrite.
L'envoi d'un courriel signé entre A et B s'effectue comme suit :
- Une empreinte du message est calculée à l'aide d'une fonction de hachage. Une fonction de hachage produit une empreinte unique pour un contenu. Il s'agit d'une fonction à sens unique qui ne permet pas à partir de l'empreinte de retrouver le contenu originel. Quelques fonctions de hachages courantes : MD5, SHA1, SHA256, SHA512. Certaines sont a éviter telles que le MD5 et SHA1 car il y a risque de collision (le fait que deux contenus différents aient la même empreinte).
- L'empreinte est chiffrée avec la clef privée de l'émetteur. On obtient la signature du message.
- La signature est ajoutée au message en clair.
- Le message signé est envoyé.
- La signature est séparée du message.
- La signature est déchiffréestrong> avec la clef publique de l'émetteur.
- L'empreinte du message est calculée à l'aide de la même fonction de hachage que lors de la création de la signature.
- L'empreinte obtenue en hachant le message en clair et l'empreinte obtenue en déchiffrant la signature sont comparées. Si elles sont identiques, le message est authentique.
Aller à l'exercice 3 Aller à l'exercice 4
La norme DomainKeys Identified Mail (DKIM)
Le DKIM permet de signer numériquement les messages émis par un domaine. Son fonctionnement est celui d'une signature cryptographique à clef asymétriques. Le DKIM permet de s'assurer que le message n'a pas été altéré durant le transport entre les serveurs SMTP. Il est décrit dans la RFC 6376.
La clef publique permettant à un MTA destinataire de vérifier la signature est renseignée dans un enregistrement DNS TXT du sous-domaine _domainkey. Voici un exemple
mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; t=y; h=sha256; p=<clef publique encodée en base64>"
Les informations sont fournies sous la forme "clef=valeur" séparées par un point-virgule
| Clef | Libellé |
|---|---|
| v= | Version de DKIM |
| h= | Liste des fonctions de hachages supportées |
| k= | Type de clef publique |
| n= | Notes humainement lisibles, non interprétées |
| p= | Clef publique encodée en base64 |
| s= | Types de services pour lesquels la clef est destinée. Par défaut, tous |
| t= | Drapeaux. y : le domaine vérifie l'enregistrement DKIM. s : le domaine de la balise "i=" ne doit pas être un sous-domaine de la balise "d=" |
Chaque courriel émis par le domaine comporte un en-tête supplémentaire de ce type
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=mail; t=1607069100; bh=xMoSG8Ll7XmdNbRh0iQburgk/ydKxfjnV3uNf9tSjHY=; h=To:From:Subject:Date:From; b=<signature encodée en base64>
Les champs de l'en-tête DKIM du message sont également au format "clef=valeur" et sont séparés par un point virgule
| Clef | Libellé |
|---|---|
| v= | Version de DKIM |
| a= | Fonction de hachage utilisée |
| b= | Signature du message encodée en base64 |
| bh= | Empreinte du corps du message mis en forme canonique |
| c= | Algorithme de canonicalisation utilisé |
| d= | Identifiant de domaine responsable de la signature (SDID) |
| h= | Liste des champs d'en-têtes concernés par la signature |
| i= | Courriel du responsable du domaine SDID |
| l= | Taille du corps de message après canonicalisation |
| q= | Méthodes de requêtes utilisées afin de récupérer la clef publique de signature, séparées par une virgule |
| s= | Le sélecteur de sous-domaine du SDID |
| t= | Date et heure de la signature au format timestamp UNIX |
| x= | Date et heure de l'expiration de la signature au format timestamp UNIX |
| z= | Copie des noms et des valeurs des champs d'en-tête présents lors de la signature du message. |
Le Sender Policy Framework (SPF)
Le Sender Policy Framework (SPF) permet de restreindre les serveurs autorisés à envoyer des messages dont l'adresse courriel expéditeur appartient à un domaine donné. Il est défini dans la RFC 7208.
En effet, il est possible d'envoyer un message provenant d'un domaine depuis un serveur SMTP d'un autre domaine. L'enregistrement SPF permet alors au MTA destinataire de vérifier si le MTA expéditeur est autorisé par le domaine expéditeur.
Cela a pour but de limiter les courriers indésirables et les usurpations d'identités depuis le domaine avec un enregistrement SPF.
Les informations sont saisies dans un enregistrement TXT sur le DNS du domaine
example.com. IN TXT "v=spf1 a mx -all" example.fr. IN TXT "v=spf1 ip4:10.207.72.0/24 ip4:10.207.73.12 -all"
Un enregistrement SPF doit commencer par v=spf1. Voici les principaux mécanismes possibles (non exhaustif) :
| Clef | Libellé |
|---|---|
| all | Toutes les IP sont valides |
| a | Si l'IP fait partie des enregistrements A ou AAAA du domaine |
| ip4 | Si l'IPv4 fait partie de la plage spécifiée |
| ip6 | Si l'IPv6 fait partie de la plage spécifiée |
| mx | Si l'IP correspond à une IP de l'enregistrement MX du domaine |
| exists | Vérifie si le domaine peut être résolu |
Les modificateurs principaux sont à mettre avant le mécanisme. Le symbole + fait que si le mécanisme est validé, le courriel est approuvé. Il s'agit du comportement par défaut et est donc facultatif. Le symbole - rejette le mail correspondant au mécanisme : par exemple, le paramètre -ip4:10.205.0.0/16 rejettera tous les courriels émis par les IP dans la plage 10.205.0.0/16.
Ainsi, le paramètre -all rejettera tous les messages ne correspondant pas aux règles précédentes.
Bonnes pratiques
Afin de limiter les risques de pertes de données et réduire l'impact environnemental et énergétique, voici quelques recommandations. N'hésitez pas à les partager auprès de vos utilisateurs :
- Laissez une copie des messages sur le serveur en cas de dysfonctionnement du stockage du client de messagerie.
- Supprimez les messages inutiles afin de réduire l'impact sur le stockage serveur et client, et ainsi limiter les besoins en dispositifs de stockage pour réduire l'impact environnemental et énergétique.
- Si une pièce jointe doit être envoyée à plusieurs destinataires, déposez le document sur un service de partage de fichiers et envoyer le lien pour y accéder. Auquel cas, la pièce jointe sera copiée autant de fois qu'il y a de destinataires.
- Limitez les signatures au strict nécessaire afin de réduire le poids de chaque message.
- Si vous répondez ou transférez un message, supprimez les échanges précédents si cela n'est pas nécessaire.
- N'imprimez un message que si cela est nécessaire.
- Lors de la création d'un compte sur un service en ligne, désactivez l'envoi de messages des partenaires commerciaux.
- Signez cryptographiquement les mails si cela est possible.
- N'ouvrez ni transférez les courriels vérolés (indésirables, frauduleux). Prenez garde à l'origine des messages.
- Sauvegardez les courriels de votre serveur, si possible sur un site de sauvegarde distant.
- Inscrivez-vous aux publications des préconisations d'une liste noire afin de limiter la réception de messages indésirables (Spamhaus, SORBS, etc.).
- Vérifiez régulièrement que votre serveur de messagerie ne soit pas émetteur de messages indésirables.
- Ouvrez une boîte de messagerie du type abuse@domaine.tld afin que puissent être signalés les envois de messages indésirables depuis vos serveurs.
Divers textes de loi encadrent les communications électroniques.
Secret des correspondances
L'article 226-15 du Code Pénal punit toute violation du secret des correspondances, y compris des courriels :
"Le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance, est puni d'un an d'emprisonnement et de 45 000 euros d'amende.
Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie électronique ou de procéder à l'installation d'appareils de nature à permettre la réalisation de telles interceptions.
Lorsqu'ils sont commis par le conjoint ou le concubin de la victime ou le partenaire lié à la victime par un pacte civil de solidarité, ces faits sont punis d'une peine de deux ans d'emprisonnement et de 60 000 euros d'amende."
Dans le milieu professionnel, le pourvoi n°99-42.942 du 2 octobre 2001 de la Cour de Cassation prévoit que si un employé identifie clairement un répertoire, un message ou des pièces jointes comme étant des correspondances privées, il ne peut pas violer le secret des correspondances, même si l'employeur interdit l'usage des équipements professionnels à cette fin.
En l'absence d'indications claires sur le caractère privé, l'employeur peut consulter les correspondances professionnelles.
Messages commerciaux
L'envoi de message commerciaux (publicités, prospection directe, newsletters, etc.) par courriel est encadré par l'article L34-5 du Code des Postes et des Communications Électroniques :
"Est interdite la prospection directe au moyen de système automatisé de communications électroniques au sens du 6° de l'article L. 32, d'un télécopieur ou de courriers électroniques utilisant les coordonnées d'une personne physique, abonné ou utilisateur, qui n'a pas exprimé préalablement son consentement à recevoir des prospections directes par ce moyen.
[…]
Dans tous les cas, il est interdit d'émettre, à des fins de prospection directe, des messages au moyen de système automatisé de communications électroniques au sens du 6° de l'article L. 32, télécopieurs et courriers électroniques, sans indiquer de coordonnées valables auxquelles le destinataire puisse utilement transmettre une demande tendant à obtenir que ces communications cessent sans frais autres que ceux liés à la transmission de celle-ci. Il est également interdit de dissimuler l'identité de la personne pour le compte de laquelle la communication est émise et de mentionner un objet sans rapport avec la prestation ou le service proposé.
[…]"
Ne peuvent être envoyés des messages commerciaux uniquement aux personnes l'ayant demandé et elles peuvent à tout moment résilier leur abonnement.