Mozilla Thunderbird va intégrer nativement la prise en charge d’Exchange

• Thunderbird prendra en charge nativement Microsoft Exchange, largement utilisé dans les entreprises et les établissements d’enseignement, à partir de l’ESR de juillet 2024 ; le premier périmètre sera limité aux e-mails
• Ce travail va au-delà de la prise en charge d’Exchange Web Services (EWS) et devient l’occasion de remettre progressivement à plat les limites d’une architecture de protocoles de messagerie vieille de plus de 20 ans et d’un ancien code C++
• Rust a été choisi comme langage d’implémentation, principalement pour la sécurité mémoire, les performances natives, la modularité, ainsi que pour la CI partagée avec Firefox et l’interopérabilité XPCOM
• Lors de l’intégration d’EWS, des crates comme xpcom_async, moz_http, xml_struct et ews ont été créées ; elles encapsulent de façon plus idiomatique pour Rust les appels HTTP basés sur XPCOM et la sérialisation XML
• EWS sera indisponible dans Exchange Online après octobre 2026, mais de nombreux utilisateurs d’Exchange Server on-premise en ont encore besoin, ce qui rend cette prise en charge toujours nécessaire dans Thunderbird

---

Périmètre de la prise en charge d’Exchange dans l’ESR de juillet 2024

• Thunderbird prévoit de proposer une prise en charge native d’Exchange dans sa prochaine version ESR (Extended Support Release), en juillet 2024
• Le périmètre initial est limité aux e-mails
  • La prise en charge du calendrier et du carnet d’adresses sera ajoutée ultérieurement
  • Jusqu’à récemment, les fonctionnalités Exchange n’étaient disponibles que via des modules complémentaires
• La cible d’implémentation est l’API Exchange Web Services (EWS) de Microsoft
  • EWS fonctionne au-dessus de HTTP
  • Les corps des requêtes et des réponses utilisent XML

Le poids d’une architecture de messagerie vieille de plus de 20 ans

• L’architecture actuelle des protocoles de messagerie de Thunderbird repose sur du code plus ancien que Thunderbird lui-même
  • Elle a été développée il y a plus de 20 ans dans le cadre de Netscape Communicator
  • Après que Mozilla a transféré la propriété de Thunderbird à la communauté en 2012, et jusqu’à son retour au sein de la Mozilla Foundation en 2017, il n’y a pas eu de maintenance rémunérée
• À mesure que des changements ponctuels se sont accumulés sans grande direction architecturale, beaucoup de code C++ n’utilisant pas les standards modernes est resté en place
• Pendant les 20 ans du projet Thunderbird, aucune prise en charge d’un nouveau protocole de messagerie n’avait été ajoutée
  • Alors que les protocoles de messagerie évoluaient pour s’adapter aux usages modernes, les structures associées n’ont pas pu être mises à jour
  • Une grande partie du savoir institutionnel a également disparu
• La prise en charge d’Exchange est le premier travail piloté par l’organisation visant à comprendre les limites de l’architecture de Thunderbird et à les résoudre progressivement

Pourquoi Rust a été choisi

• Rust a été choisi comme langage d’implémentation pour la prise en charge des nouveaux protocoles dans Thunderbird
• Ce choix tient à la fois aux avantages généraux de Rust et aux conditions propres à Thunderbird
  • Sécurité mémoire : Thunderbird recevant des entrées de toute personne envoyant un e-mail, il est important de réduire les bugs de sécurité
  • Performances : Rust s’exécute sous forme de code natif
  • Modularité et écosystème : la structure modulaire de Rust et son écosystème lié à l’e-mail peuvent être exploités
• Thunderbird étant construit sur le code de Firefox, les conditions d’adoption de Rust étaient déjà réunies
  • L’infrastructure de CI partagée avec Firefox prend Rust en charge
  • La couche d’interopérabilité XPCOM (Cross-Platform Component Object Model) de Firefox permet des appels entre Rust, C++ et JavaScript
• Les types et les outils de Rust aident à créer des API difficiles à mal utiliser
  • Ils permettent par exemple d’éviter les références circulaires, ou de créer des fonctions impossibles à appeler avec des valeurs dépourvues de sens
  • Les outils de documentation étant inclus de base dans le langage, ils sont utiles pour une petite équipe
• Une conception sous forme de crates modulaires permet aussi une réutilisation dans d’autres projets comme Thunderbird for Android/K-9 Mail

Contraintes du système de build et de XPCOM

• Lors de l’exécution du premier composant Rust dans Thunderbird, le système de build a été le premier obstacle
• Thunderbird n’est pas structuré comme une dépendance classique du code Firefox
  • Le code Firefox est récupéré au moment du build
  • Le code Thunderbird est intégré comme sous-arbre de Firefox
  • Un fichier de configuration de build pointe vers ce sous-arbre
• Firefox regroupe les crates individuelles dans un seul workspace Cargo afin de construire le graphe de dépendances Cargo de tout l’arbre
  • Thunderbird avait aussi besoin de son propre workspace Cargo, mais Cargo n’autorise pas les workspaces imbriqués
  • La solution a consisté à définir un workspace propre à Thunderbird et à configurer l’outil de build parent mach pour le construire à la place du workspace Firefox
  • Une nouvelle sous-commande mach synchronise les dépendances et le lockfile avec ceux du niveau parent, puis vendore le superset obtenu
• XPCOM est conçu autour de C++, ce qui rend l’expérience de développement en Rust peu fluide
  • L’implémentation et l’utilisation d’interfaces XPCOM exigent beaucoup de boilerplate
  • Il est difficile de tirer pleinement parti d’outils comme rust-analyzer
  • Firefox a beaucoup réduit sa dépendance à XPCOM, mais Thunderbird n’a pas pu mener un nettoyage similaire pendant sa période sans maintenance
• La prise en charge d’un nouveau protocole de messagerie exige l’implémentation de centaines de fonctions définies dans XPCOM
  • Les implémentations de protocoles existantes réduisent cette charge en héritant de classes C++ fournissant des comportements partagés
  • En Rust, ce n’est pas possible directement, donc la logique propre à chaque protocole est implémentée en Rust
  • Une classe passerelle C++ relie la crate interne ews_xpcom et le code existant de comportements partagés
• La façon de créer des composants Rust dans Thunderbird est documentée dans la documentation

Gérer les requêtes HTTP à la manière de Rust

• Firefox dispose déjà d’une pile HTTP via le composant réseau necko
• necko est écrit en C++ et exposé via XPCOM, ce qui impose beaucoup de boilerplate pour l’utiliser directement depuis Rust
  • Même une simple requête GET nécessite de créer de nombreux objets XPCOM
  • XPCOM gère la durée de vie des pointeurs, mais le compilateur Rust ne le sait pas, ce qui nécessite des blocs unsafe
  • Les interfaces nécessaires reposent sur des callbacks
• La crate interne de Thunderbird xpcom_async convertit les opérations asynchrones XPCOM vers la syntaxe async/await de Rust
  • Elle met en mémoire tampon les données reçues via les callbacks
  • Elle implémente le trait Future de Rust afin que l’appelant puisse utiliser await
  • Le Future de Rust est similaire aux Promise de JavaScript ou aux coroutines de Python
• La crate interne moz_http fournit un client HTTP inspiré de reqwest
  • Elle gère la création des objets XPCOM nécessaires
  • Elle propose une gestion des erreurs plus idiomatique en Rust que la gestion d’erreurs XPCOM standard

Sérialisation XML d’EWS et nouvelles crates

• Dans EWS, le travail le plus délicat consiste à convertir les structures de données internes de Thunderbird vers le XML exigé ou fourni par EWS, et inversement
• Les crates existantes de sérialisation et de désérialisation XML ne répondaient pas aux besoins
  • Le modèle de données de serde ne correspond pas bien à XML, ce qui rend difficile la distinction entre attributs et éléments
  • EWS est sensible aux espaces de noms XML, un concept peu familier à serde
  • Les crates XML basées sur serde exigent d’annoter explicitement la manière de sérialiser chaque champ
  • EWS définit des centaines de types et des dizaines de champs par type, ce qui rend ce boilerplate ingérable
• L’implémentation existante basée sur serde suffisait pour désérialiser XML vers Rust, mais aucun outil de sérialisation satisfaisant n’a été trouvé
• La nouvelle crate xml_struct fournit un trait définissant le comportement de sérialisation XML et une macro procédurale de dérivation
  • Elle génère automatiquement l’implémentation du trait pour les structures de données Rust
  • Elle est construite au-dessus de la crate existante quick_xml
  • Elle vise un mapping avec peu de boilerplate entre XML et Rust
  • Elle ne dépend pas de l’intérieur de Thunderbird/Firefox et en est à un stade précoce de développement
• La nouvelle crate ews définit des types et des API de sérialisation/désérialisation XML pour travailler avec EWS
  • Elle s’appuie sur xml_struct et serde
  • Elle est en phase initiale de développement et publiée sur GitHub

Tests, gestion des erreurs et plan de connexion à l’UI

• Des tests automatisés sont en cours de renforcement avant l’ajout des prochaines fonctionnalités majeures
  • Un serveur EWS mock pour les tests d’intégration a été ajouté, en plus des tests unitaires
  • Le renforcement des tests a mis en évidence quelques crashs et problèmes de double synchronisation, qui ont été corrigés
  • Les nouvelles fonctionnalités deviennent plus faciles à tester et à valider
• La gestion des erreurs EWS est en cours d’amélioration
  • Le comportement d’EWS en cas d’erreur est souvent peu documenté
  • Une requête entière peut échouer à cause du throttling ou d’une structure incorrecte
  • Certaines parties d’une requête peuvent réussir tandis que d’autres échouent à cause d’identifiants invalides
  • Certaines erreurs peuvent être gérées au niveau du protocole, mais d’autres nécessitent l’intervention de l’utilisateur ou peuvent être difficiles à résoudre
• La prise en charge du protocole EWS est étendue via ews et la crate interne ews_xpcom, et elle est en cours de connexion à l’UI de Thunderbird
  • Un patch récent permet d’ajouter un compte EWS à Thunderbird
  • Il est possible de synchroniser depuis le serveur distant la hiérarchie des dossiers du compte
  • Les dossiers synchronisés peuvent être affichés dans l’UI
  • Cette fonctionnalité, actuellement en état alpha, est cachée derrière un flag de build et des valeurs de configuration
• Les prochaines étapes portent sur la récupération de la liste des messages depuis le serveur distant et la généralisation de la prise en charge de l’envoi d’e-mails dans Thunderbird
• À des fins de maintenance, la documentation explique comment les différents composants s’assemblent, ainsi que l’architecture existante des protocoles de messagerie de Thunderbird et les pistes d’amélioration futures

Relation entre EWS et Microsoft Graph

• EWS ne sera plus utilisable avec Exchange Online après octobre 2026
• L’étude préalable du projet a montré qu’un nombre important d’utilisateurs continuent d’utiliser Exchange Server on-premise
  • De nombreuses entreprises et institutions éducatives exploitent Exchange Server sur leur propre matériel
  • Ces installations on-premise prennent généralement EWS en charge
  • Elles ne peuvent pas prendre en charge l’API Graph basée sur Azure
• La prise en charge d’EWS devient donc un moyen de servir ces utilisateurs dans un avenir proche
• Certaines questions liées à l’API Graph ne sont pas encore résolues
  • L’API Graph a été conçue en pensant aux services web plutôt qu’aux applications desktop
  • Ajouter d’abord la prise en charge d’EWS donne du temps pour trouver des solutions à ces problèmes avant de construire la prise en charge de l’API Graph
• Le travail sur Rust et EWS s’inscrit dans un effort plus large visant à réduire le turnaround de Thunderbird et à accroître la résilience du cœur du logiciel

[GN⁺]

Commentaires sur Hacker News

• Comme EWS est déjà prévu pour être abandonné puis supprimé dans deux ans, je ne vois pas pourquoi l’implémenter : https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

  • EWS est la seule méthode réellement viable pour permettre à des clients autres qu’Outlook de fonctionner, et MAPI n’est pas vraiment une API ouverte.
    Si EWS disparaît, beaucoup de clients partiront aussi, et au début cela ne suffira peut-être pas à affecter significativement les résultats de Microsoft.
    Puis il finira par apparaître que tous les e-mails se valent, et Exchange Online pourrait devenir une simple note de bas de page dans l’histoire. Que Microsoft se soit ainsi planté sur l’e-mail est un peu embarrassant en apparence, mais en réalité ce n’est pas forcément si grave pour eux.
    Exploiter un système de messagerie est pénible, et ce que Microsoft veut vraiment, ce sont les données et métadonnées qu’il peut extraire pour les revendre à d’autres obsédés de la donnée. Les e-mails sont généralement volumineux mais assez statiques côté stockage, alors que les échanges entre personnes peuvent être une mine d’or.
    Dans l’idéal, il suffit de laisser AWS, Google et d’autres supporter la douleur, tout en forçant les clients à utiliser Outlook. Ensuite, on modifie le tout pour stocker les identifiants dans le cloud de Microsoft, comme avec la nouvelle version Electron d’Outlook, puis on utilise ces identifiants pour extraire les données e-mail hébergées dans les clouds des autres, en leur laissant les coûts de stockage. Magnifique
  • Comme l’a dit Sean Burke dans le bug Bugzilla concerné, EWS est actuellement la meilleure façon de prendre en charge à la fois Exchange Online et les installations on-premise : https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
    La Graph API a aussi été étudiée et pourra l’être à nouveau plus tard, mais pour l’instant sa couverture est plus limitée qu’EWS et il lui manque certaines fonctions nécessaires aux applications de bureau.
    Même si la suppression du support d’EWS dans Exchange Online a été annoncée, cela garde de la valeur à court terme pour permettre l’accès à une large base d’utilisateurs, et à long terme pour prendre en charge les installations on-premise
  • C’est parce que, face à quelque chose comme Exchange, il n’existe pratiquement aucune autre option réaliste pour le moment
  • Tout le monde n’utilise pas Exchange Online

• Si l’objectif est simplement d’augmenter le nombre d’utilisateurs de Thunderbird, c’est stratégiquement cohérent, mais idéologiquement le support de JMAP paraît bien meilleur

  • Une grande partie du travail réalisé cette fois semble aussi devoir être essentielle pour ajouter plus tard le support de JMAP

• J’ai récemment essayé Thunderbird à la place d’Outlook, et j’y ai retrouvé le même problème que Firefox avant la mise à jour Quantum : c’est trop lent.
  Il y a un délai visible quand on bascule entre des dossiers contenant des centaines ou des milliers d’e-mails, alors que dans Outlook le changement est pratiquement instantané

  • Si vous utilisez Windows, d’après mon expérience Thunderbird est presque inutilisable tant que vous n’ajoutez pas le profil Thunderbird aux exceptions de Windows Defender
  • Mon expérience est exactement l’inverse. Utiliser Outlook pour le mail est bien trop pénible, surtout parce que la recherche fonctionne mal. Dans Thunderbird, j’utilise expressionsearchNG.
    Pour l’agenda, c’est exactement l’inverse, donc pour l’instant je fais tourner les deux côte à côte. Un des problèmes semble venir du pont iCal vers le serveur Outlook que je dois utiliser au travail.
    Cette annonce ne change malheureusement rien sur ce point. J’ai utilisé pendant un temps l’extension EWS maintenue par Ericsson : https://github.com/Ericsson/exchangecalendar
    Mais Mozilla semble avoir fait fuir beaucoup de développeurs de plugins en cassant rapidement les interfaces. Ils remettent maintenant une partie des fonctions dans le cœur du produit, mais je ne sais pas si c’est une bonne stratégie. À mon avis, ils devraient plutôt se concentrer sur des interfaces stables

• Je déteste Exchange, mais ce travail est bienvenu. Il sera peut-être enfin possible d’envoyer avec succès des e-mails en texte brut via Exchange même en étant coincé sur Windows

  • En faisant cela, les e-mails pourraient s’afficher bien plus mal dans plusieurs clients, par purisme technique ou nostalgie d’une autre époque.
    Vu à quel point il est courant que les e-mails en texte brut soient rendus avec une police à chasse fixe, j’ai du mal à justifier le texte brut simplement parce que « les e-mails HTML sont une abomination »

• Dire que « personne n’a ajouté la prise en charge d’un nouveau protocole mail dans toute l’histoire de 20 ans du projet Thunderbird » est techniquement vrai, mais chaque grande entreprise a eu besoin de son implémentation OAuth2 hors bande et de paramètres spécifiques par client de messagerie, autrement dit de contournements, et Thunderbird en a déjà accumulé pas mal.
  Ce ne sont pas des protocoles mail génériques. Ce n’est ni IMAP, ni POP3, ni SMTP : cela fonctionne au-dessus de HTTPS.
  Dire qu’« ils n’ont jamais ajouté de nouveau protocole mail » est une bonne chose, et ce changement ne l’est pas. Le support de configurations propriétaires est pratique et compréhensible, mais ce n’est pas une bonne chose.
  Cela ne fait qu’atténuer temporairement le problème d’un e-mail fragmenté en dizaines de variantes propres à chaque entreprise, tout en encourageant à long terme les gens à accepter ces variantes

  • Les employés ne peuvent pas choisir leur fournisseur d’e-mail professionnel, et pour 99,99999 % d’entre eux, ce n’est pas une cause pour laquelle ils vont monter au front.
    En revanche, pouvoir utiliser Thunderbird comme client est un bénéfice net et un choix pragmatique
  • Il ne s’agit pas d’une grande entreprise parmi d’autres, mais de Microsoft Exchange, de très loin le système le plus courant pour l’e-mail professionnel, en particulier Exchange Online

• Je ne sais pas pourquoi le titre a été changé. Cet article parle de programmation Rust
  « Bringing Exchange Support to Thunderbird » donne l’impression d’un article sur Thunderbird et la prise en charge d’Exchange, mais ce n’est pas ce qu’on peut en apprendre ici

  • Comme le premier paragraphe de l’article met davantage l’accent sur Exchange que sur le langage, il semble que la fonctionnalité elle-même soit plus importante que l’implémentation. La plupart des utilisateurs s’en soucient aussi davantage
  • Le même article a déjà été posté plus tôt avec le titre complet, mais il n’a pas suscité d’intérêt : https://news.ycombinator.com/item?id=40095870
  • Je ne vois pas de quoi tu parles. Toute la seconde moitié de l’article traite de la prise en charge d’Exchange dans Thunderbird

• La prise en charge d’une spécification propriétaire peut être utile, mais j’aimerais que Mozilla donne la priorité aux implémentations standard comme la découverte automatique du serveur d’envoi d’e-mails (SMTP). Par exemple, la RFC 6186 date de 2011
  Aujourd’hui, l’utilisateur doit saisir manuellement le nom d’hôte et le port du serveur SMTP ; ça va peut-être pour les gens de ce site, mais ce n’est absolument pas convivial pour les 99,9 % restants de l’humanité
  L’effort nécessaire pour implémenter Exchange dans son ensemble est probablement de plusieurs ordres de grandeur supérieur à celui requis pour la découverte du serveur d’envoi via DNS/SRV. Je ne comprends vraiment pas les priorités de Mozilla

  • Il me semble que je n’ai pas eu à saisir ce genre d’informations quand j’ai ajouté des comptes Hotmail, Google ou Yahoo à Thunderbird. J’ai juste entré chaque adresse e-mail
    Est-ce que ces services sont traités comme des cas particuliers ?

• Waouh, ça me rappelle l’époque où je bossais dans l’IT il y a environ 20 ans. On était dans un environnement presque entièrement Microsoft, avec seulement quelques personnes sous Linux
  Exchange faisait toujours partie des choses pour lesquelles il était difficile de trouver un bon client, et si ça avait existé à l’époque, j’aurais été aux anges

  • Je le suis encore aujourd’hui
    Utiliser des produits Microsoft sous Linux est vraiment pénible, et on dirait surtout qu’ils sont en train d’abandonner progressivement la version web de Teams si on n’utilise pas Edge :(
  • Nous avions le même problème, mais nous avons pris une autre voie. Nous avons fait en sorte que l’entreprise abandonne Exchange et SharePoint, et depuis, nous sommes bien plus heureux

• Le fait qu’« autour de 2012, Mozilla ait cessé de s’occuper de Thunderbird et en ait transféré la propriété à la communauté, puis qu’il n’y ait eu aucune maintenance rémunérée jusqu’au retour de Thunderbird dans la Mozilla Foundation en 2017 » était vraiment scandaleux
  C’est un exemple emblématique des priorités inversées de Mozilla

  • Je ne suis pas d’accord. Le monde est passé aux applications mail web/mobile
    On peut ne pas aimer ça, et ça ne me réjouit pas non plus. Mais c’est un fait, et ça ne valait pas la peine que Mozilla y consacre des fonds

• J’aimerais qu’ils intègrent par défaut l’import de fichiers PST, afin que les gens qui veulent quitter une installation Outlook puissent migrer en douceur sans avoir à bricoler Outlook lui-même
  Il existe déjà des projets libres capables de lire les fichiers PST, il suffirait donc de les intégrer à la suite

  • L’export PST via le module Exchange pour PowerShell existe depuis Exchange 2010. Voir « New-MailboxExportRequest » : https://learn.microsoft.com/en-us/powershell/module/exchange...
    Édition : ah non. C’est réservé à l’on-premise. C’est vraiment stupide