7.1. Eléments logiciels
7.1.1. Rappel et compléments sur les agents mail [1] [2] [3]
Lors de la transmission d’un email, différents modules logiciels interviennent au niveau des clients et des serveurs. Ces modules, ou agents, ont des rôles distincts dans la transmission des emails. Connaître les différents types d’agent permet de choisir le ou les produits logiciels qui permettront de mettre en place les rôles souhaités dans chaque cas d’utilisation spécifique. Chaque rôle est nommé selon le même pattern : “Mail XXXX Agent”. On parle des agents “MxA”, le x étant une wildcard pour l’initiale de la fonctionnalité spécifique.
- MUA : Mail User Agent. Tourne sur un poste client, et se charge de deux actions :
- La rédaction et l’envoi d’un email à un serveur mail (MSA ou MTA)
- La consultation d’un email depuis le stockage local
- MSA : Mail Submission Agent [4]: Cet agent, souvent conjoint voire fusionné au MTA, est celui qui reçoit les demandes d’envoi d’email depuis les MUAs des clients et les transfère au MTA pour envoi. Un MSA est normalement joignable sur le port 587 (mais peut aussi écouter sur le port 25). Le MSA permet de fournir un service spécifique et plus riche aux clients du domaine, alors que le MTA ne fait pas de différence entre les emails venant du domaine et les emails d’Internet. Le MSA est apparu lorsque les employés ont commencé à envoyer des emails depuis l’extérieur de l’entreprise (employés nomades), et qu’il s’est avéré nécessaire de traiter ce flux de mail différemment du flux de mail entrant traditionnel, notamment via de l’authentification. On parle de soumission lorsque le mail à traiter provient d’un utilisateur du domaine, et de relai lorsque c’est un mail extérieur au domaine. La soumission de mail, définie par le RFC6409, impose que les clients dont il reçoit les mails soient authentifiés et autorisés. Cela peut se faire par SMTP-AUTH ou par d’autres techniques (RADIUS, certificats, …).
- MTA : Mail Transfert Agent : S’occupe de la transmission SMTP avec d’autres serveurs mail. On l’appelle aussi relais mail, ou serveur MX.
- MDA : Mail Delivery Agent. S’occupe de distribuer un email dans sa boîte mail de destination. On parle aussi parfois de LDA (Local Delivery Agent).
- MRA : Mail Retrieval Agent. S’occupe de la récupération d’un email depuis une boîte mail. Un MRA peut s’intégrer à un MUA, ou exister indépendamment. Un MRA va typiquement supporter les protocoles POP/IMAP.
La figure ci-dessous montre un exemple d’agencement des différents agents lors du transfert d’un email. Dans cet exemple, le premier serveur mail au niveau de la source est un MSA, et transmet l’email à un MTA dans le domaine de destination. Lorsque le MTA détecte que le message est arrivé à destination, il le transmet à un MDA qui se charge du stockage dans une mailbox. Le destinataire consulte ensuite son email via son MRA, éventuellement intégré à son MUA.
7.1.2. Implémentation d’un service mail
Si l’on souhaite gérer son service mail de A à Z, l’ensemble des agents présentés ci-dessus seront a priori nécessaires. Si, par contre, on utilise un fournisseur, les agents seront répartis partiellement en interne et partiellement en externe. Par exemple, on peut utiliser un fournisseur mail mais garder des clients applicatifs dédiés (MUAs) tel que Thunderbird ou Outlook sur les postes clients. Dans le cas extrême d’un fournisseur “cloud” complet avec un applicatif client de type Webmail (ex : Gmail ou Office365), il est même possible de n’utiliser aucun client applicatif (client “lourd”) sur les postes utilisateurs, les navigateurs servant d’interface avec le MUA.
Nous allons ici étudier le cas d’un service mail “On Premise” (hébergé en interne). Ce n’est pas spécialement le modèle adapté à l’heure actuelle à l’ensemble des entreprises, mais il permet de comprendre les mécanismes et protocoles qui sont en jeu, plutôt que de ne voir du service mail qu’une “boîte noire dans le cloud”.
Deux “flux de données” sont à considérer : le flux de mails sortant (outgoing) et les flux de mails sortants (incoming).
Flux de mails sortant
Le flux de mails sortant est constitué des mails envoyés par les employés de l’entreprise. Les étapes de ce flux de données est le suivant :
- Le mail est rédigé sur le MUA par le client
- Le MUA se connecte au MSA. S’il est bien configuré, ce dernier vérifie si l’email qui lui est soumis est conforme : provient-il d’une adresse connue dans le domaine de l’entreprise? L’utilisateur s’est-il authentifié pour prouver qu’il est bien celui qu’il prétend et qu’il a le droit d’envoyer le mail?
- Une fois le message accepté, le MSA cherche le serveur MTA “next hop”, typiquement sur base de l’adresse de destination, et le transfère en SMTP. Le message sera alors transmis à la destination.
Flux de mails entrant
Le flux de mail entrant comprend quant à lui les mails qui sont reçus de l’extérieur, et qui sont destinés à l’entreprise.
La première étape pour recevoir un email est d’annoncer sur Internet que le domaine possède un serveur mail (MX). Pour cela, on va utiliser le système DNS, en publiant le Resource Record dédié : le record Mail eXchange (MX).
Voici un exemple de RR MX pour le domaine example.com :
example.com MX 10 mail.example.com 45000
Ce record (avec un TTL de 45000) indique que, pour le domaine example.com, il existe un serveur mail appelé mail.example.com. Le chiffre 10 indique la priorité : si plusieurs MX existent pour un même domaine, il faut préférer le MX avec la plus basse priorité.
Les emails, une fois arrivés dans l’entreprise, suivent les étapes suivantes :
- Ils arrivent sur le serveur MX/MTA du domaine, qui est le point d’entrée pour les emails.
- Le serveur MTA vérifie l’adresse de destination, et, si la destination est une adresse de l’entreprise, il transfère le message à l’agent MDA (Mail Delivery Agent).
- Le serveur MDA va stocker le message dans la boîte email correspondant à l’adresse de destination.
- L’employé, souhaitant consulter ses emails, va démarrer son logiciel client (MUA). Lorsque les boîtes mail sont stockées non pas en local, mais sur un serveur distant, un agent MRA va se charger de la récupération des messages sur le serveur, notamment via les protocoles POP/IMAP.
Lors du choix des logiciels à installer sur le ou les serveurs mail et sur les clients, il sera important de s’assurer que les différents agents sont présents et configurés pour fonctionner harmonieusement.
Dans le monde Unix, de nombreux logiciels sont disponibles, chacun supportant un ou plusieurs agents. Par exemple, Sendmail et Postfix sont des MTAs avec MDA intégré, mais ils peuvent tout aussi bien communiquer avec un MDA d’un autre logiciel (ex : procmail ou Dovecot).
Gestion des utilisateurs et des mailboxes
Dans l’analyse des flux de données, deux éléments de configuration sont apparus : la gestion des utilisateurs, et la gestion des boîtes mail.
La gestion des utilisateurs transparait à deux endroits :
- Lors de l’envoi du mail, dans l’étape de soumission : l’utilisateur doit être authentifié et autorisé. Il faut donc un système qui permettent l’enregistrement des utilisateurs et de leur mode d’authentification
- Lors de la récupération des emails, via le MRA. Il est logique que l’utilisateur distant s’authentifie afin que les boîtes email ne soient consultés que par les personnes autorisées.
Il faudra donc définir quel type d’utilisateurs et d’authentification seront utilisés dans le service mail complet, afin de configurer le MSA et/ou le MRA en fonction du système choisi. Idéalement, on utilisera le système de gestion des utilisateurs global de l’entreprise s’il existe (LDAP, Active Directory, Radius, …). D’autres options existent si cette première option n’est pas possible :
- Utiliser les utilisateurs Unix de l’OS. C’est une option peu sécurisée et peu pratique qui est à réserver uniquement pour des tests.
- Utiliser des utilisateurs virtuels. Il s’agit d’utilisateurs qui ne correspondent pas à des comptes Unix (pas de shell ni de home directory) et n’existent que dans le cadre du système de courrier électronique. Ils peuvent être définis soit dans des fichiers de configuration, soit via une base de données.
En plus du type d’utilisateur, il faut évidemment utiliser un système d’authentification sécurisé, et éviter les solutions trop légères (mots de passe en clair par ex.).
Enfin, une fois les utilisateurs définis, il faut également spécifier où et comment les emails seront stockés, afin que les différents agents (surtout le MDA) puissent accéder aux boîtes mail pour y déposer des messages ou les consulter.
Deux formats sont souvent mentionnés pour les emails [5] :
- Le format mbox : il s’agit du format de boîte électronique traditionnel Unix, basé sur un fichier unique concaténant les emails les uns après les autres. Il est peu pratique pour l’accès aux emails, dès lors que la mailbox devient volumineuse, et nécessite d’être entièrement bloqué en écriture lors des accès.
- Le format Maildir : dans ce format, proposé à l’origine pour le serveur QMail, les emails sont stockés dans des répertoires, chaque message dans un fichier dédié. Ce format est plus pratique et plus efficace que le format mbox, et lui est généralement préféré.
On pourrait imaginer stocker les emails dans une base de données. Néanmoins, les emails avec leurs pièces jointes ne constituent pas des données structurées pour lesquels une base de données apporterait une forte valeur ajoutée, sauf cas d’usage spécifique. Dans un cas d’utilisation classique, les formats de mailbox classiques conviennent.
Bibliographie
[1] Wikipédia, Email Agent (infrastructure), janv. 2022, consulté en avril 2023
[2] K. McCarthy, Mail Concepts, wiki du logiciel mutt, 2018, consulté en avril 2023
[3] D. Crocker, RFC 5598, Internet Mail Architecture, 2009
[4] Wikipédia, Message Submission Agent, mars 2023, consulté en avril 2023
[5] Red Hat Customer Portal, Understanding Maildir and mbox store formats, may 2022, consulté en avril 2023