Comment fonctionne l’email ?

Le courrier électronique permet l’échange de messages à travers un réseau informatique. Il est antérieur à l’avènement d’Internet et en est une des briques les plus importantes. Il a naturellement beaucoup évolué depuis sa création, utilise plusieurs protocoles et est encadré par un grand nombre de RFC. Toujours en évolution, il continue de susciter des recherches et améliorations. 

Anatomie d’une adresse de messagerie

Une adresse de messagerie est composée de 3 éléments :

– une partie locale, généralement les nom ou initiales de la personne qui utilise la boite.
– l’arobase « @ » qui agit en tant que séparateur,
– le nom de domaine pleinement qualifié.

La partie locale est définie par la RFC 3696 (https://tools.ietf.org/html/rfc3696#section-3). Celle-ci est particulièrement permissive. Dans la réalité, beaucoup de serveurs de messagerie sont plus restrictifs. Nous vous conseillons donc d’en limiter les caractères spéciaux afin d’être compatibles avec autant d’implémentations que possible.

Chaque domaine doit obligatoirement inclure deux adresses de gestion : « abuse » et « postmaster ». Elles servent respectivement à recueillir les plaintes en cas de comportements abusifs, le spam par exemple (voir RFC 2142 :  https://tools.ietf.org/html/rfc2142#section-2) et les messages d’erreur techniques concernant la messagerie du domaine (voir RFC 5312 : https://tools.ietf.org/html/rfc5321#section-4.5.1)

Connaître le serveur de messagerie d’un domaine

Lors de l’envoi d’un message, la première chose que fait un serveur émetteur est une requête DNS de type MX (Mail eXchange) sur la partie « nom de domaine » de l’adresse de messagerie destinataire. Cette requête a pour but de récupérer l’adresse IP du serveur de messagerie du domaine. Cette étape est définie par la RFC 2821 (https://tools.ietf.org/html/rfc2821#section-5).

Il est tout à fait possible, voire conseillé, d’avoir plusieurs enregistrements MX pour un domaine donné. Entre alors en jeu la valeur de priorité du champ MX. Elle indique l’ordre de contact des serveurs : une connexion est tentée vers le serveur ayant la valeur la plus faible. En cas d’échec, on tente sur le serveur suivant et ainsi de suite. Si deux serveurs sont désignés avec la même priorité, le contact est effectué aléatoirement sur l’un des deux, formant ainsi une répartition de charge minimale. 

Enfin, ce n’est pas une configuration recommandée, mais il est possible de n’avoir aucun enregistrement MX. On cherche alors un champ A (qui doit renvoyer une adresse IP). S’il est présent, une connexion est tentée vers cette adresse. Si aucun champ MX ou A n’est indiqué pour le domaine, l’envoi est un échec. Un message d’erreur est généré par le serveur de messagerie émetteur et envoyé à l’expéditeur.

A noter qu’un champ MX ne doit être un alias (CNAME) comme défini par la RFC 2181 (https://tools.ietf.org/html/rfc2181#section-10.3) afin d’éviter une multiplication inutile des requêtes.

Dialogue SMTP

Une fois l’adresse du serveur de messagerie établie, une connexion est initiée par le serveur expéditeur. Celle-ci utilise le protocole SMTP (Simple Mail Transfer Protocol) et se fait sur le port 25. Cette communication se passe en quatre étapes :

– HELO (ou EHLO) : Le serveur émetteur se présente, avec son nom d’hôte.
– MAIL FROM : Le serveur émetteur indique de quelle adresse vient le message.
– RCPT TO : Le serveur émetteur indique l’adresse destinataire du message.
– DATA : Le contenu du message lui-même, en-têtes compris est transmis.

Un certain nombre d’autres commandes existe, mais elles sont optionnelles. C’est le cas de VRFY ou EXPN par exemple.

À chacune de ces étapes, le serveur destinataire doit répondre qu’il accepte de poursuivre la conversation. On utilise dans ce but un code retour :

– 2XX : c’est accepté, on passe à l’étape suivante.
– 4XX : blocage temporaire. La connexion est stoppée et le serveur émetteur est invité à renouveler l’envoi ultérieurement.
– 5XX : blocage permanent. Les informations transmises déclenchent une erreur ou un rejet sur le serveur destinataire. La communication est interrompue et ne sera pas renouvelée.

Dans le cas d’une interruption du dialogue (temporaire ou permanente), le serveur émetteur est invité à tenter une connexion similaire sur le serveur de messagerie suivant, comme vu précédemment. C’est pourquoi il est important d’apporter le même niveau de sécurité à tous ses serveurs de messagerie. Un serveur secondaire considéré comme moins crucial et donc moins bien sécurisé sera une porte d’entrée favorisée par les attaques de spams notamment.

Si la communication ne peut être menée à terme, sur l’ensemble des serveurs disponibles, un message d’erreur indiquant l’échec de la connexion est généré par le serveur émetteur et transmis à l’expéditeur. 

Prise en charge des données non standard (MIME)

Dès sa création, le protocole SMTP n’est conçu que pour transférer du texte brut en ASCII. Il ne peut donc gérer le texte riche (caractères spéciaux ou accentués) ou les fichiers binaires. De plus, de nos jours, la plupart des messages électroniques contiennent une version HTML/CSS qui en améliore la lisibilité et l’apparence (intégration de liens et d’images, mise en page, etc). Il a ainsi été nécessaire d’ajouter au protocole SMTP des méthodes et standards lui permettant de prendre en charge ces formats. C’est le rôle de MIME (Multipurpose Internet Mail Extensions) qui est aujourd’hui massivement utilisé.

MIME est un standard (RFC 2045 à 2047) qui définit les mécanismes de transformation de tout type de données (fichiers multimédias, images, documents bureautiques, exécutables, etc) en texte brut codé en ASCII. Il utilise pour cela des en-têtes qui indiquent le format des données contenues: le type et l’encodage utilisé. 

C’est typiquement le client de messagerie (client lourd ou webmail) qui transforme les données en MIME avant de les transmettre au serveur de messagerie. Ces données seront extraites (on parle parfois de « démimer ») par le client de messagerie du destinataire. Il est néanmoins souvent nécessaire que le serveur de messagerie destinataire extrait les fichiers afin de mener des contrôles antivirus ou antispam.

Récupération, classement et lecture des messages (IMAP, POP)

Le message est maintenant correctement reçu par le serveur de messagerie destinataire, mais celui-ci ne sait pas le rendre disponible aux utilisateurs. Il doit le transmettre au MDA (Mail Delivery Agent), c’est le gestionnaire des boites aux lettres, il va être capable de stocker, ranger (dossiers, tags) et rendre accessible les messages aux utilisateurs. C’est aussi lui qui permet le classement automatique suivant les expéditeurs ou les en-têtes par exemple, notamment le déplacement vers les dossiers « Spams » ou « Indésirables ».

Le MDA peut être contacté via les protocoles IMAP pour accéder ou POP pour copier les messages aux clients de messagerie. Le protocole IMAP, plus récent, est conseillé, il permet notamment de synchroniser les messages et leur organisation sur l’ensemble de vos accès si vous utilisez différents terminaux.

Certaines solutions de messagerie intègrent tous ces services, par exemple Gmail, Zimbra ou Exchange qui sont capables de gérer l’ensemble de la chaîne. D’autres séparent les différents services notamment Postfix qui ne fait que la gestion du trafic SMTP (MTA, Mail Transfert Agent) ou Thunderbird qui ne fait que client de messagerie (MUA, Mail User Agent).

Dans tous les cas, les 3 briques sont nécessaires :
– un MTA pour envoyer et recevoir,
– un MDA pour stocker et accéder,
– un MUA pour lire et écrire (le client de messagerie).

Et Altospam dans tout ça ?

Altospam est un système de sécurisation de la messagerie. Il intervient techniquement en amont du serveur de messagerie, par l’intermédiaire des champs MX du domaine client, en tant que relai. Tous les messages envoyés au domaine sont donc dirigés vers les serveurs d’Altospam. Ils sont alors extraits (démimés) puis contrôlés : 

– Validité SMTP : Le système vérifie que le domaine émetteur est correctement configuré, que le serveur émetteur est autorisé à émettre pour ce domaine, etc.

– Contrôle antivirus, antimalwares : Altospam intègre 6 antivirus, ayant des bases de données et des méthodes différents, mis à jour très régulièrement. Nous nous assurons ainsi de bloquer un maximum des menaces connues et inconnues : virus, malwares, ransomwares…

– Technologies antispam, antiphishing : Nous utilisons plusieurs systèmes antispam, antiphishing, antiscan, antifovi dont le rôle est d’identifier et catégoriser les messages suspects.

Si tous les contrôles sont passés, le message original est transmis au serveur destinataire du domaine. La seule modification effectuée est d’ajouter les en-têtes validant que le message a bien été contrôlé (X-ALTOSPAM). Le message est tout à fait inchangé, du fait que les analyses et contrôles sont faits sur une copie extraite qui est automatiquement supprimée. Dès que le message est transmis, en échec ou en réussite, au destinataire, il est effacé de nos serveurs. Le seul cas où nous conservons le message est lorsqu’il y a une incertitude sur le traitement à appliquer. Il est alors placé en quarantaine pendant 28 jours. Il n’est pas livré, mais l’utilisateur ou l’administrateur de la boite concernée a la possibilité de le libérer.

Enfin, si le mail est rejeté, aucun message n’est transmis au serveur destinataire, lui épargnant ainsi bande passante et ressources. Un message de synthèse journalier ou l’utilisation de l’interface de contrôle se chargeant d’informer l’utilisateur des opérations effectuées sur les messages lui étant destinés.

Dans tous les cas, nous conservons, conformément à la loi, les méta-données (sous forme de logs) pendant 1 an : date et heure, expéditeur et destinataire, ainsi que le titre du message.

Le système Altospam est donc capable de s’insérer dans le flux de messagerie d’un domaine, en accord avec les protocoles qui régissent les communications électroniques, sans impacter les configurations spécifiques du serveur client.