L' email : architecture et protocoles
Un article qui explore notre système d'échange d'emails actuel, son architecture et les protocoles qui y sont utilisés.
Introduction
Cet article va explorer notre système d'échange d'emails actuel, un système pour le moins complexe alors qu'envoyer un mail est l'une des actions les plus banales et courante qu'il nous est donné de faire.
Vous trouverez ici des informations relatives à l'architecture de ce système et aux protocoles qui y sont utilisés. En revanche, cet article n'aborde pas le contenu ni le format des messages électroniques.
L'envoi d'emails date de plus de 40 ans (premier format standard RFC pour permettre l'envoi d'emails en 1977). Il faut savoir qu'à l'origine ces échanges se faisaient de manière très peu sécurisés. En général : n'importe qui pouvait envoyer n'importe quoi à n'importe qui et il était très facile pour des personnes mal intentionnées :
- d'intercepter des messages
- de changer son identité
- d'envoyer de grandes quantités de messages indésirés (spamming)
L'architecture actuelle définie par l'Internet Engineering Task Force (IETF) affecte des tâches bien précises à différentes entités. Le défaut de cette architecture est sa complexité qui la rend peu abordable. Son avantage est qu'elle permet d'améliorer l'environnement de l'email sur plusieurs fronts.
La deuxième partie de l'article aborde l'évolution des protocoles et particulièrement :
- les nouvelles options
- la rétrocompatibilité
- les effets sur l'architecture
Cette évolution est le fruit des progrès de la technologie durant ces 40 dernières années. Des progrès qui apportent des solutions aux problèmes de base de l'échange d'emails (mais surtout des réseaux en général) : authentification, cryptage et filtrage.
Architecture actuelle
Vue d'ensemble
La documentation officielle de l'IETF défini les 5 entités suivantes dans un environnement client-serveur :
| TLA | Nom | Rôle |
| MUA | Mail user agent | Le client de messagerie (comme Microsoft Outlook, Mozilla Thunderbird...). |
| MSA | Mail submission agent | Cette entité reçoit les messages en provenance du client et forme une ligne d'attente avant de faire suivre les mails au Mail transfer agent (MTA). |
| MTA | Mail transfer agent | Cette entité délivre les messages qui lui sont transmis par le MSA. Elle se charge également de recevoir les messages envoyés par les autres MTA et de les faire suivre au Mail Delivery agent (MDA). |
| MDA | Mail delivery agent | Cette entité reçoit les messages du MTA local et doit les stocker dans la boîte au lettre électronique (MS). |
| MS | Message store | Cette entité stocke les messages reçus par le MDA et les délivre aux MUA lorsque celui-ci en fait la demande. |
Rien n'empêche plusieurs de ces entités à résider sur un même serveur.
L'envoi d'un mail et les interactions entre ces entités qui en découlent sont schématisés dans la RFC 5598 par un graphique ASCII.
Bien que la version ASCII ait du charme, le graphique présenté dans l'article Email explained from First principles permet de mieux se représenter l'intervention des acteurs :
Le serveur d'envoi (MSA + MTA)
Nous considérons le serveur d'envoi comme l'abstraction réunissant le MSA et le MTA (dans son rôle de transmetteur).
Rôles
Les rôles du serveur d'envoi sont d'accepter les messages du client de messagerie et de créer la file d'attente pour la livraison, de déterminer le serveur de réception des destinataires puis de leurs délivrer les messages.
- Le serveur d'envoi est tenu d'authentifier l'expéditeur.
- Si le serveur d'envoi ne peut pas livrer son message, il doit en notifier l'expéditeur.
Résolution d'adresse :
Afin de déterminer le serveur de réception à partir d'une adresse mail, le serveur d'envoi va consulter le Domain Name System (DNS) à la recherche :
- D'un enregistrement mail exchanger (MX) qui associe au nom de domaine de l'adresse une liste ordonnée de serveurs de messagerie électronique.
- Ensuite d'un enregistrement A (IPv4) ou AAAA (IPv6) qui associe le nom du serveur de messagerie à une adresse IP.
Les enregistrements MX peuvent lister plusieurs serveurs de messageries électroniques et assigner à chacun une priorité qui va déterminer dans quel ordre chercher à communiquer avec ces serveurs. Cela est utile pour prévenir les pannes de serveurs.
Dans le cas où le serveur d'envoi ne trouve pas d'enregistrement MX et donc de serveur de messagerie, il peut alors consulter les registres A ou AAAA avec le nom de domaine de l'adresse mail.
Pourquoi passer par un serveur d'envoi ?
- Déléguer le travail au serveur car contrairement au client de messagerie, le serveur a un accès permanent et fiable à une connexion Internet. Il est judicieux de demander à une entité externe d'assumer des fonctionnalités potentiellement coûteuses en ressources :
- Retenter l'envoi après un échec (la RFC 5321 précise que quand un message ne peut pas être transmis, le serveur d'envoi DOIT rajouter le message à la file d'attente et périodiquement retenter de l'envoyer pendant au moins 4-5 jours à moins que l'expéditeur abandonne l'envoi).
- Envoyer un message à de nombreux destinataires.
- Réduire le spam et le phishing. L'utilisation d'un serveur d'envoi permet de mettre en place des mesures de protection contre les mails non sollicités et trompeurs :
- Un système de réputation permet aux serveurs de réceptions d'apprendre les sources légitimes de messages. Les messages provenant de serveurs d'envois à mauvaise réputation ou pas de réputation ont de grandes chances d'être abandonnés où considérés comme du spam.
- L'authentification de l'utilisateur et ainsi la possibilité de limiter son potentiel malveillant et de repérer les abus (Gmail limite ses utilisateurs à 2000 messages par jour et 100 destinataires par message).
- L'authentification du serveur d'envoi et la possibilité pour les serveurs de réception de refuser les messages venant de certains noms de domaines.
Le serveur de réception (MTA + MDA + MS)
Nous considérons le serveur de réception comme l'abstraction réunissant le MTA (dans son rôle de récepteur), le MDA et le MS.
Rôles
Le serveur de réception reste à l'écoute d'une communication de la part d'un serveur d'envoi. Il y a plusieurs variables qui vont déterminer si le message va être accepté :
- Le destinataire existe-t-il ?
- La boîte est-elle pleine ?
- L'expéditeur est-il de confiance ?
Si le message n'est pas pris en charge, alors c'est au serveur d'envoi de retenter sa chance plus tard ou d'informer l'utilisateur à l'origine du message que son message n'a pas été délivré. Dans le cas contraire, le serveur de réception a la responsabilité de faire parvenir le message dans la boîte de réception du destinataire ou d'avertir l'expéditeur en cas d'échec.
Le serveur de réception peut être utilisé pour appliquer des filtres sur les messages entrants, générer des réponses automatiques, avertir de l'absence d'un employé et d'autres fonctionnalités.
Silent dropping
Avant de faire suivre le message, le serveur de réception procède à une évaluation afin d'estimer si celui-ci est un spam. Dans le cas où un spam est identifié, il est soit mis en quarantaine dans le dossier "Spam" du destinataire ou abandonné sans avertir l'expéditeur.
L'extrait ci-dessous explique que cette pratique est tolérée en raison du grand nombre de messages indésirables en circulation auxquels retourner une notification de non-réception viendrait confirmer au spammeur que cette adresse est valide.
Unwanted, Unsolicited, and "Attack" Messages
Utility and predictability of the Internet mail system requires that messages that can be delivered should be delivered [...] regardless of their content. If they cannot be delivered [...] they should be "bounced" (returned with non-delivery notification messages) as described above. In today's world, in which many SMTP server operators have discovered that the quantity of undesirable bulk email vastly exceeds the quantity of desired mail and in which accepting a message may trigger additional undesirable traffic by providing verification of the address, those principles may not be practical.As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. [...] So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate.
RFC 5321 (2008)
La boîte de messagerie et le dossier "Envoyé"
La boîte de messagerie attend la connexion du client qui doit va devoir s'authentifier afin de consulter et gérer son espace de stockage. Pour communiquer avec la boîte de messagerie, le client utilise un protocole différent que pour communiquer avec le serveur d'envoi.
Une des fonctionnalités importante de la boîte de messagerie est le dossier "Envoyé" qui répertorie les messages envoyés par l'utilisateur.
Comme l'architecture sépare les entités responsables de l'envoi des entités responsables de la réception, il faut faire en sorte que le serveur de réception reçoive également le message soumis au serveur d'envoi. La plupart du temps le client doit soumettre chaque message deux fois.
Cette solution naïve peut poser soucis aux clients ayant un accès limité à Internet et rompt le principe selon lequel il faut déléguer le travail du client vers les serveurs. Kaspar Etter montre ici quatre alternatives intéressantes.
Protocoles
Protocoles d'envoi
Simple Mail Transfer Protocol (SMTP)
Ce protocole a été la première fois documenté par l'IETF en 1982 dans la RFC 821.
Après avoir ouvert une connexion TCP sur le port 25, le client envoie des commandes (ASCII 8 bits) et le serveur lui répond par des codes de statuts. Comme son nom l'indique, SMTP est un protocole simple.
Il faut savoir que SMTP date d'une époque où la sécurisation des échanges est assez limitée.
Par conséquent, SMTP n'authentifie pas les utilisateurs lors de la connexion, donc il ne peut pas en déterminer la fiabilité. Par conséquent, les relais SMTP servent souvent à l'envoi de spam où à l'envoi de message en utilisant de fausses adresses.
De plus, SMTP ne crypte pas les communications entre les acteurs.
Extended Simple Mail Transfer Protocol (ESMTP)
Dix ans plus tard (1993), ESMTP a été introduit dans la RFC 1425. ESMTP est une extension du protocole SMTP et ajoute de nouvelles commandes qui permettent notamment :
- L'authentification de l'expéditeur : grâce à la commande AUTH, le client peut s'identifier auprès du serveur en spécifiant un mécanisme SASL en première argument.
- Le cryptage SSL des emails : grâce à la commande STARTTLS, le client peut demander au serveur s'il prend en charge le cryptage TLS. Si il reçoit un code 220 alors il peut initier la phase d'Handshake.
- La restriction de la taille des emails : grâce à la commande SIZE, le client peut demander au serveur de spécifier la taille maximale autorisée de l'email en octets.
- L'envoi de messages d’erreur standardisés en cas d’impossibilité de distribution
Les deux protocoles utilisent le même port sur le serveur, une fois la connexion établie, le client peut envoyer la commande ELHO (variante de HELO) qui signale qu'il veut initialiser un protocole ESMTP.
Distinction de deux situations dans l'envoi d'un mail
Le protocole d'envoi est utilisé pour deux situations : quand le client de messagerie soumet un email au serveur d'envoi et quand le serveur d'envoi relai un message à un serveur de réception.
A l'origine ces deux scénarios n'étaient pas distingués, toute entité (même un client de messagerie) était considérée comme un Mail Transfert Agent (MTA) et on pouvait librement lui demander de relayer un message. Cela provoquait deux problèmes :
- Les spammers pouvait router leurs mails par des serveurs de relais d'organisation réputées rendant difficile le blocage en fonction de l'origine du message.
- Comme les serveurs ne faisaient pas attention à leur simple rôle de relais, ils pouvaient modifier le contenu des mails afin d'appliquer des politiques spécifiques à leur organisation.
Avec l'arrivée de ESMTP qui a permit de sécuriser et complexifier le transfert de mails, l'IETF a décidé de délimiter les deux rôles de du protocole d'envoi dans la RFC 2476 en 1998.
On peut maintenant distinguer le protocole SUBMISSION au moment où le client soumet un message au serveur d'envoi.
Le protocole SUBMISSION se distingue par le fait qu'il peut demander l'authentification de l'utilisateur et qu'il peut modifier le contenu du message. Les serveurs ayant un rôle de relais ont aussi pu commencer à n'accepter les mails que des personnes internes à une organisation.
C'est ainsi qu'est née l'architecture actuelle qui sépare les serveurs d'envoi et les serveurs de réception.
Protocoles d'accès
L'accès à la boîte de messagerie se fait sur une interface différente et avec d'autres protocoles que les protocoles d'envoi. Les protocoles d'accès les plus utilisés sont POP3 et IMAP.
Post Office Protocol (POP)
Version 1 (POP1)
POP est introduit en 1984 dans la RFC 918. Comme SMTP, c'est un protocole textuel qui accepte des commandes de 4 lettres.
Ce protocole permet de relever la totalité des mails présent sur le serveur, d'interrompre la connexion puis de travailler en mode "hors-ligne".
Le protocole permet de récupérer ses mails sans les supprimer du serveur, mais cela impliquerai de retransférer toute sa boîte mail à chaque fois. Cette option n'est donc pas utilisée et le serveur est vidé à chaque requête du client.
L'avantage de POP (surtout pour l'époque où les communications Internet étaient chères) est qu'il réduit le temps passé en ligne.
Les désavantages sont importants :
- On ne peut recevoir ses mails qu'une fois et par conséquent sur un seul appareil. Si cet appareil est perdu, vous perdez également vos mails
- POP1 n'est fait que pour transmettre les mails d'un serveur à votre client, il ne permet pas de manipuler le contenu du serveur.
Version 3 (POP3)
La version 3 du protocole est documentée en 1996 dans la RFC 1939.
Elle utilise un fonctionnement très différent :
- La liste (ID + taille en octets) des messages sur le serveur est obtenue grâce à la commande LIST.
- Un message peut être demandé en spécifiant son ID en argument de la commande RETR.
- Un message peut être supprimé du serveur en spécifiant son ID en argument de la commande DELE.
Ainsi POP3 a résolu le principal inconvénient de POP1, les mails peuvent être conservés sur le serveur et synchronisés sur plusieurs appareils.
POP3 défini également la commande STLS qui permet d'améliorer la connexion de TLP à TLS et la commande APOP qui permet de s'identifier de façon plus sécurisée.
Internet Message Access Protocol (IMAP)
IMAP est un protocole d'accès contrairement à POP1 qui est un protocole de relève. Il a été conçu par Mark Crispin en 1986.
Jusqu'au début des années 90, IMAP a connu 3 versions. La quatrième et dernière (IMAP4) a alors été conçue par un groupe de travail formé par l'IETF
Il fonctionne de façon similaire à POP3 en proposant beaucoup plus de commandes et d'options.
Le principal atout d'IMAP est de pouvoir effectuer des opérations complexes sur le serveur, par exemple :
- Créer/supprimer/renommer des dossiers et y ranger ses messages
- Appliquer des règles de tri automatiques
- Rapatrier en local certains messages et pas d'autres
- Rechercher des mails selon plusieurs critères
- Ajouter des mails depuis le stockage local
Ces fonctionnalités nécessitent d'être connecté en permanence, mais un mode "hors ligne" est également possible.
Flags
Avec IMAP, il est possible d'appliquer des flags à des messages ce qui peut permettre de les différencier. L'IETF définis un ensemble de flags dans la RFC 3501 :
- \Seen : le message a été lu
- \Answered : on a répondu à ce message
- \Flagged : ce message demande une attention particulière
- \Deleted : ce message sera supprimé à la prochaine purge (commande EXPUNGE)
- \Draft : ce message est n'est pas fini et n'a pas été envoyé
- \Recent : ce message est récent, cette session est la première à en être notifiée.
Quelques commandes
| Commande | Argument(s) | Description |
| SEARCH | Critère(s) de recherche | Cherche les messages correspondant aux critères de recherche. Les nombreux critères permettent d'affiner les recherches. |
| FETCH | Un jeu de messages Noms de données | Retourne les données demandées dans le jeu de mails donné. |
| APPEND | Nom du dossier Message | Permet d'ajouter un nouveau mail dans le dossier spécifié. Cette commande est utilisée par les clients de messagerie pour stocker les messages envoyés. |
En raison de sa popularité, il existe de nombreuses extensions au protocole IMAP. Il est possible de lister les extensions qu'un serveur supporte grâce à la commande CAPABILITY.
| Commande | Description |
| STARTTLS | Permet d'améliorer la connexion de TCP à TLS. |
| ESEARCH | Une extension de SEARCH qui permet par exemple de spécifier le nombre de résultats que la recherche doit renvoyer. |
| MOVE | Permet de déplacer des messages d'un dossier à l'autre au lieu de la manipulation classique qui implique de copier le message puis supprimer le supprimer. |
Un système complexe
Vous l'aurez compris, le mail est un système incroyablement complexe.
Depuis 40 ans, son architecture et ses protocoles doivent se développer et s'adapter aux contraintes modernes tout en restant compatibles avec d'anciennes versions d'eux-mêmes.
Dans les protocoles
Les protocoles utilisés aujourd'hui sont en grande partie des extensions, cela est dû aux insuffisances des protocoles d'origines et principalement :
- À l'absence d'authentification : au début de l'email, les clients de messageries pouvait envoyer des messages à n'importe quel serveur sans avoir besoin de s'authentifier. Pour encadrer l'envoi de message, il a fallu mettre en place le protocole SUBMISSION dérivé de l'ESMTP.
- À l'absence de sécurité : les échanges d'emails et de mots de passe n'ont pas pu être sécurisés avant l'arrivé de TLS. Il a donc fallu étendre les protocoles avec des commandes permettant d'activer TLS. Continuer à prendre en charge des connexions non sécurisées rend les serveurs vulnérable aux attaques par repli (downgrade attack).
Dans l'architecture
Avant l'arrivée du protocole SUBMISSION seul l'accès à sa boîte de réception nécessitait une configuration particulière.
Depuis, les configurations nécessaires au bon fonctionnement d'un système envoi/réception doivent prendre en compte deux protocoles. À moins de faire appel à un service de messagerie prenant en charge ces configurations, vos problèmes sont potentiellement doublés.
Vous pouvez alors vous retrouver dans l'incapacité d'envoyer un mail alors que vous pouvez en recevoir, ou l'inverse.
Vous êtes aussi tenu d'envoyer vos messages deux fois afin de les stocker dans votre messagerie.
Sources
Global
Architecture
SMTP et ESMTP
- RFC 5321- Simple Mail Protocol (2008)
- RFC 1425 - SMTP Service Extensions
- IONOS - Qu’est-ce que SMTP ? Définition et principes de bases
POP et IMAP