En tant que plus grand fournisseur de messagerie électronique chiffrée au monde, travailler avec l’IMAP (Internet Message Access Protocol) fait partie de notre quotidien. L’IMAP est au cœur de l’application Proton Mail Bridge, qui vous permet d’ajouter le chiffrement Proton Mail à des clients de messagerie standards tels qu’Outlook, Thunderbird ou Apple Mail.
Mais l’IMAP va au-delà de Proton Mail. C’est l’un des deux protocoles standards de récupération d’e-mails (l’autre étant le POP) que presque toutes les applications de messagerie utilisent pour accéder et gérer vos e-mails. En essence, il alimente la messagerie électronique à l’échelle mondiale.
Aujourd’hui, nous introduisons Gluon(new window), une nouvelle bibliothèque IMAP écrite dans le langage de programmation Go conçue pour être performante, fiable, conviviale pour les développeurs et, surtout, open source.
Parallèlement au lancement de Gluon, nous publions également une nouvelle version de Proton Mail Bridge alimentée par Gluon. Grâce aux innovations ci-dessous, le nouveau Proton Mail Bridge est 1000 % plus rapide, bien plus fiable et également compatible avec davantage de clients de messagerie.
Pourquoi créer une nouvelle bibliothèque IMAP ?
La messagerie doit être fiable, mais elle doit également être performante, en particulier car la taille moyenne des boîtes de réception a considérablement augmenté au cours de la dernière décennie. De nombreuses implémentations IMAP open source tendent à optimiser l’un au détriment de l’autre, conduisant à des compromis significatifs ou à des bugs.
Gluon cherche à combler cette lacune et à surmonter les limitations des bibliothèques IMAP open source existantes, qui sont souvent mal entretenues ou pas totalement évolutives. Gluon y parvient en utilisant une architecture qui repose sur un système de « snapshots ».
Les clients IMAP se réfèrent généralement aux messages par leur « numéro de séquence », la position du message dans une boîte aux lettres. Le premier message a le numéro de séquence « 1 », le second « 2 », et ainsi de suite. Si un client souhaite marquer un message comme « lu », il envoie une commande au serveur telle que « marquer le message 5 comme lu ». Mais que se passe-t-il si un autre client supprime le quatrième message dans la boîte aux lettres ? Les numéros de séquence de tous les messages suivant le message supprimé seront décalés d’un cran vers le bas ; le client qui a envoyé la commande « marquer le message 5 comme lu » se réfère maintenant à un message différent de celui qu’il visait initialement.
Les serveurs IMAP (qui incluent des applications telles que Proton Mail Bridge) doivent être capables de gérer cette situation. Lorsqu’un client déplace des messages dans ou hors d’une boîte aux lettres, le serveur doit notifier tous les autres clients des changements pour qu’ils puissent mettre à jour leur propre vue de la boîte aux lettres. Et jusqu’à ce que les clients aient reçu la mise à jour, le serveur doit se souvenir de ce que chaque client pense que la boîte aux lettres représente pour interpréter correctement les commandes du client.
Dans l’exemple précédent, le serveur doit savoir que le client qui a envoyé la commande « marquer le message 5 comme lu » fait référence au message qui était initialement en position 5, et non au message qui est actuellement en position 5.
Ce type de scénario peut survenir plus fréquemment dans l’utilisation moderne de la messagerie, où l’utilisateur pourrait utiliser Proton Mail sur le web sur un appareil, utiliser les applications mobiles en déplacement et ensuite utiliser un client de bureau via Proton Mail Bridge sur un ordinateur de bureau, tous pouvant ne pas être en ligne en même temps.
Un autre scénario est celui des applications de messagerie qui utilisent souvent plusieurs connexions simultanées à votre boîte aux lettres pour accélérer les choses, mais cela peut alors entraîner des problèmes de concurrence. En utilisant un système de snapshots, Gluon attribue à chaque client IMAP son propre « snapshot » de la boîte aux lettres sélectionnée. Chaque snapshot conserve la vue unique du client sur la boîte aux lettres, permettant au serveur d’interpréter exactement à quel message le client fait référence à tout moment, indépendamment des actions effectuées par d’autres clients. Cela garantit une expérience e-mail stable et cohérente pour l’utilisateur.
Comment nous avons écrit Gluon
Notre première étape dans l’écriture de Gluon a été de générer un analyseur IMAP à partir de la syntaxe donnée dans RFC3501(new window). Nous avons utilisé ANTLR4(new window), un générateur d’analyseur populaire, pour créer un analyseur capable d’interpréter les commandes et les réponses IMAP selon la spécification. Cela nous a permis de nous concentrer sur la mise en œuvre de la logique du protocole IMAP plutôt que sur l’analyse et la validation des entrées.
Une fois que nous avions un analyseur, nous avons écrit le type de serveur de base pour Gluon. Le type de serveur attend les connexions TCP entrantes et lance une « session IMAP » exécutée dans une goroutine séparée (un thread léger et vert utilisé dans le langage de programmation Go) pour gérer chaque connexion.
La session a un travail simple :
- Lire la commande d’un client.
- Analyser la commande.
- Appeler le bon gestionnaire de commande.
- Enfin, envoyer toutes les réponses nécessaires au client.
Cette conception permet également à Gluon de gérer plusieurs connexions client en parallèle, chaque session gérant son propre état.
L’un des principaux défis de la mise en œuvre d’un serveur IMAP est de gérer à la fois les états persistants et les états par session des boîtes aux lettres. L’état persistant fait référence aux messages qui sont réellement dans une boîte aux lettres sélectionnée tandis que l’état par session fait référence aux messages que chaque client pense être actuellement dans une boîte aux lettres sélectionnée.
Dans Gluon, nous utilisons une base de données SQL pour stocker l’état IMAP persistant, tel que les boîtes aux lettres et les messages qu’un utilisateur possède. De plus, la base de données SQL permet une gestion plus rapide et plus efficace des commandes grâce à une pré-récupération et un indexage intelligents.
La gestion de l’état par session était plus compliquée, car elle dépend entièrement des réponses IMAP qui ont été envoyées à un client à un moment donné. Pour modéliser cela, nous avons défini un type qui contient une liste des identifiants de message, des UID et des drapeaux en mémoire. Cette liste est peuplée à partir de la base de données lorsqu’un client sélectionne pour la première fois une boîte aux lettres. Cette approche nous permet de gérer efficacement l’état par session et de traiter de nombreuses commandes IMAP entièrement en mémoire sans nécessiter de lectures sur disque, conduisant à des performances beaucoup plus rapides.
Pour synchroniser l’état par session entre plusieurs clients connectés, Gluon utilise un système de « répondants ». Ce sont des types qui encapsulent un changement d’état et, lorsqu’ils sont exécutés, sont convertis en réponses IMAP. Lorsqu’un client effectue une action (comme marquer un message comme lu) qui changerait l’état d’un autre client, le backend crée un répondant pour l’action et le pousse vers l’état affecté. L’état affecté reste inchangé jusqu’à ce que le répondant soit exécuté, à ce moment-là, il est mis à jour, et une réponse IMAP correspondante est envoyée au client. Cette approche permet à Gluon de gérer efficacement l’état par session tout en assurant la cohérence entre plusieurs clients.
En développant le support de Gluon pour chaque commande IMAP, nous avons utilisé le développement piloté par les tests. Nous avons créé un cadre de test qui nous a permis de spécifier à quoi devrait ressembler une session IMAP entière, en précisant les commandes du client et les réponses attendues du serveur.
Nous avons d’abord écrit un test pour chaque commande IMAP (souvent copié directement de RFC3501) puis mis en œuvre le traitement de la commande pour faire réussir le test. De plus, pour assurer la justesse et la fiabilité de Gluon, nous avons utilisé Dovecot(new window), le serveur IMAP le plus populaire au monde, comme implémentation de référence, et nous avons effectué des tests de justesse en utilisant l’outil de test de Dovecot, imaptest(new window).
La dernière étape consistait à intégrer Gluon dans le Proton Mail Bridge. Nous avons conçu Gluon de manière à ce que son intégration dans n’importe quelle application soit aussi simple que la mise en œuvre de son interface « Connector ». Le Connector maintient la synchronisation entre l’état de Gluon et les états externes (l’état Proton).
Par exemple, lorsqu’un client IMAP marque un message comme lu, le connector marque ce même message comme lu sur le serveur Proton. Lorsque le serveur Proton reçoit un message, le connector le télécharge et le déchiffre, puis le place dans la boîte aux lettres Gluon appropriée.
Cette conception extensible permet d’utiliser Gluon avec presque n’importe quelle application nécessitant IMAP.
La confidentialité sans compromettre la performance
Plus tôt cette année, nous avons lancé en version bêta la nouvelle version 3 du Proton Mail Bridge (alimenté par Gluon), et les retours des utilisateurs étaient en accord avec nos propres tests de performance, indiquant une amélioration de la vitesse de 1000%. Nous espérons qu’en publiant Gluon en tant que logiciel open source, nous pourrons permettre à une nouvelle génération de logiciels de messagerie modernes de mieux répondre aux exigences des utilisateurs d’e-mails contemporains.
En tant qu’entreprise open source, nous invitons d’autres à utiliser, examiner et contribuer au code, et comme pour d’autres projets open source que Proton maintient(new window), nous nous engageons à maintenir cette bibliothèque à long terme.
Notre mission est de rendre la confidentialité accessible et largement disponible en ligne, et un Proton Mail Bridge amélioré par Gluon qui rend les e-mails chiffrés de bout en bout disponibles sur n’importe quelle application de messagerie de bureau est une étape importante vers la réalisation de cet objectif.
Comme toujours, merci pour votre soutien et n’oubliez pas de partager vos retours et pensées avec nous sur Reddit(new window), et Twitter(new window).
Ce travail a été réalisé par James Houlahan, Leander Beernaert, Jakub Cúth, Xavier Michelon, Romain Le Jeune, Gjorgji Slamkov, Alexander Khusanov, Gabor Meszaros et Andrzej Szafranski de l’équipe Proton Mail.
