Mozilla Thunderbird führt native Unterstützung für Exchange ein
(blog.thunderbird.net)- Microsoft Exchange, das in Unternehmen und Bildungseinrichtungen weit verbreitet ist, wird von Thunderbird ab dem ESR im Juli 2024 nativ unterstützt; der erste Umfang ist auf E-Mail beschränkt
- Diese Arbeit geht über die Unterstützung von Exchange Web Services (EWS) hinaus und ist ein Anlass, die Grenzen einer seit über 20 Jahren bestehenden Mail-Protokoll-Architektur und alten C++-Codes schrittweise aufzuräumen
- Als Implementierungssprache wurde Rust gewählt; die wichtigsten Gründe sind Speichersicherheit, native Performance, Modularität sowie gemeinsam mit Firefox genutzte CI und XPCOM-Interoperabilität
- Im Zuge der EWS-Integration wurden Crates wie
xpcom_async,moz_http,xml_structundewserstellt, die XPCOM-basierte HTTP-Aufrufe und XML-Serialisierung Rust-freundlich kapseln - EWS ist in Exchange Online nach Oktober 2026 nicht mehr nutzbar, bleibt für Thunderbird aber weiterhin wichtig, da es viele Nutzer von On-Premises Exchange Server gibt
Umfang der Exchange-Unterstützung im ESR vom Juli 2024
- Thunderbird will die Exchange-Unterstützung nativ in der nächsten ESR(Extended Support Release) im Juli 2024 bereitstellen
- Der anfängliche Umfang ist auf E-Mail begrenzt
- Unterstützung für Kalender und Adressbuch soll später ergänzt werden
- Bis vor Kurzem waren Exchange-Funktionen nur über Add-ons nutzbar
- Implementiert wird Microsofts Exchange Web Services (EWS) API
- EWS läuft über HTTP
- Anfrage- und Antworttexte verwenden XML
Die Last einer über 20 Jahre alten Mail-Architektur
- Die aktuelle Mail-Protokoll-Architektur von Thunderbird basiert auf Code, der älter ist als Thunderbird selbst
- Sie wurde vor über 20 Jahren als Teil von Netscape Communicator entwickelt
- Nachdem Mozilla 2012 die Verantwortung für Thunderbird an die Community übergeben hatte, gab es bis zur Rückkehr zur Mozilla Foundation im Jahr 2017 keine bezahlte Wartung
- Ohne große architektonische Richtung haben sich provisorische Änderungen angesammelt, sodass viel C++-Code verblieben ist, der keine modernen Standards nutzt
- In den 20 Jahren des Thunderbird-Projekts wurde nie Unterstützung für ein neues Mail-Protokoll hinzugefügt
- Während sich Mail-Protokolle an moderne Nutzungsmuster angepasst haben, wurden die zugehörigen Strukturen nicht erneuert
- Viel institutionelles Wissen ist ebenfalls verloren gegangen
- Die Exchange-Unterstützung ist die erste organisationsgetriebene Arbeit, die die Grenzen der Thunderbird-Architektur verstehen und schrittweise beheben soll
Warum Rust gewählt wurde
- Rust wurde als Implementierungssprache für die Unterstützung neuer Protokolle in Thunderbird ausgewählt
- Hinter der Entscheidung stehen sowohl allgemeine Rust-Vorteile als auch Thunderbird-spezifische Bedingungen
- Speichersicherheit: Thunderbird empfängt Eingaben von jedem, der E-Mails senden kann, daher ist es wichtig, Sicherheitsfehler zu reduzieren
- Performance: Rust wird als nativer Code ausgeführt
- Modularität und Ökosystem: Die modulare Struktur von Rust und das E-Mail-bezogene Ökosystem lassen sich nutzen
- Thunderbird basiert auf Firefox-Code, sodass die Voraussetzungen für den Einsatz von Rust bereits vorhanden sind
- Die mit Firefox gemeinsam genutzte CI-Infrastruktur unterstützt Rust
- Über die Interoperabilitätsschicht von Firefoxs XPCOM(Cross-Platform Component Object Model) sind Aufrufe zwischen Rust, C++ und JavaScript möglich
- Rusts Typen und Werkzeuge helfen dabei, APIs zu bauen, die schwer falsch zu verwenden sind
- Es ist möglich, zirkuläre Referenzen zu vermeiden oder Funktionen zu erstellen, die nicht mit bedeutungslosen Werten aufgerufen werden können
- Dokumentationswerkzeuge sind direkt in die Sprache integriert, was für kleine Teams nützlich ist
- Werden die Komponenten als modulare Crates gebaut, können sie auch in anderen Projekten wie Thunderbird for Android/K-9 Mail wiederverwendet werden
Build-System und XPCOM-Einschränkungen
- Beim Ausführen der ersten Rust-Komponente in Thunderbird war das Build-System das erste Hindernis
- Thunderbird ist nicht so eingebunden wie eine normale Abhängigkeit des Firefox-Codes
- Beim Build wird Firefox-Code geholt
- Thunderbird-Code wird als Subtree in Firefox eingebracht
- Die Build-Konfigurationsdatei verweist auf diesen Subtree
- Firefox sammelt einzelne Crates in einem Cargo-Workspace, um einen Cargo-Abhängigkeitsgraphen für den gesamten Baum zu erstellen
- Thunderbird brauchte ebenfalls einen eigenen Cargo-Workspace, aber Cargo erlaubt keine verschachtelten Workspaces
- Als Lösung wurde ein eigener Thunderbird-Workspace definiert und das übergeordnete Build-Tool
machso konfiguriert, dass es diesen statt des Firefox-Workspaces baut - Ein neuer
mach-Unterbefehl synchronisiert Abhängigkeiten und Lockfile mit dem übergeordneten Projekt und vendorisiert das daraus entstehende Superset
- XPCOM ist C++-zentriert entworfen, wodurch die Entwicklung in Rust nicht reibungslos ist
- Das Implementieren und Verwenden von XPCOM-Schnittstellen erfordert viel Boilerplate
- Werkzeuge wie
rust-analyzerlassen sich nicht ausreichend nutzen - Firefox hat die Abhängigkeit von XPCOM stark reduziert, Thunderbird konnte während der Wartungslücke ähnliche Aufräumarbeiten jedoch nicht durchführen
- Die Unterstützung neuer Mail-Protokolle erfordert die Implementierung von Hunderten in XPCOM definierten Funktionen
- Bestehende Protokollimplementierungen verringern den Aufwand, indem sie von C++-Klassen erben, die gemeinsames Verhalten bereitstellen
- In Rust ist das nicht direkt möglich, daher wird die protokollspezifische Logik in Rust implementiert
- Eine C++-Bridge-Klasse verbindet das interne Crate
ews_xpcommit dem bestehenden Code für gemeinsames Verhalten
- Wie man in Thunderbird Rust-Komponenten erstellt, ist in der Dokumentation beschrieben
HTTP-Anfragen auf Rust-Art behandeln
- In Firefox existiert bereits ein HTTP-Stack über die Netzwerkkomponente
necko neckoist in C++ geschrieben und über XPCOM verfügbar, weshalb die direkte Nutzung aus Rust viel Boilerplate erfordert- Schon für eine einfache GET-Anfrage müssen viele XPCOM-Objekte erzeugt werden
- XPCOM verwaltet die Lebensdauer von Zeigern, aber der Rust-Compiler weiß das nicht, daher sind
unsafe-Blöcke nötig - Die benötigten Schnittstellen sind callback-basiert
- Das interne Thunderbird-Crate
xpcom_asyncwandelt asynchrone XPCOM-Arbeit in Rusts async/await-Syntax um- Es puffert Daten, die über Callbacks hereinkommen
- Es implementiert Rusts
Future-Trait, sodass der Aufruferawaitverwenden kann - Rusts
Futureähnelt JavaScriptsPromiseoder Python-Koroutinen
- Das interne Crate
moz_httpbietet einen vonreqwestinspirierten HTTP-Client- Es übernimmt die Erstellung der benötigten XPCOM-Objekte
- Es bietet eine Rust-typischere Fehlerbehandlung als die Standard-Fehlerbehandlung von XPCOM
EWS-XML-Serialisierung und neue Crates
- Die schwierigste Arbeit bei EWS ist die Umwandlung zwischen den internen Thunderbird-Datenstrukturen und dem von EWS benötigten oder gelieferten XML
- Bestehende Crates für XML-Serialisierung und -Deserialisierung erfüllten die Anforderungen nicht
- Das Datenmodell von
serdepasst nicht gut zu XML, weshalb Attribute und Elemente schwer zu unterscheiden sind - EWS ist empfindlich gegenüber XML-Namespaces, was für
serdekein vertrautes Konzept ist - XML-
serde-Crates verlangen, dass die Serialisierungsweise jedes Felds explizit annotiert wird - EWS definiert Hunderte Typen und Dutzende Felder pro Typ, sodass der Boilerplate-Aufwand kaum beherrschbar ist
- Das Datenmodell von
- Eine bestehende
serde-basierte Implementierung reichte aus, um XML nach Rust zu deserialisieren, aber ein zufriedenstellendes Werkzeug für die Serialisierung wurde nicht gefunden - Das neue Crate
xml_structstellt Traits zur Definition des XML-Serialisierungsverhaltens und prozedurale Derive-Makros bereit- Es erzeugt die Trait-Implementierungen für Rust-Datenstrukturen automatisch
- Es baut auf dem bestehenden Crate
quick_xmlauf - Ziel ist ein Mapping mit wenig Boilerplate zwischen XML und Rust
- Es hängt nicht von Thunderbird/Firefox-internen Komponenten ab und befindet sich in einer frühen Entwicklungsphase
- Das neue Crate
ewsdefiniert Typen für EWS-Arbeit sowie APIs für XML-Serialisierung und -Deserialisierung- Es basiert auf
xml_structundserde - Es befindet sich in einer frühen Entwicklungsphase und ist auf GitHub öffentlich verfügbar
- Es basiert auf
Tests, Fehlerbehandlung und Pläne zur UI-Anbindung
- Bevor die nächsten wichtigen Funktionen hinzukommen, wird die automatisierte Testabdeckung ausgebaut
- Zusätzlich zu Unit-Tests wurde ein Mock-EWS-Server für Integrationstests hinzugefügt
- Bei der Verstärkung der Tests wurden einige Abstürze und Double-Sync-Probleme entdeckt und behoben
- Dadurch lassen sich neue Funktionen leichter testen und validieren
- Die Fehlerbehandlung für EWS wird verbessert
- Das Fehlerverhalten von EWS ist oft nur unzureichend dokumentiert
- Eine gesamte Anfrage kann wegen Throttling oder fehlerhafter Struktur scheitern
- Teile einer Anfrage können erfolgreich sein, während andere wegen ungültiger IDs fehlschlagen
- Manche Fehler lassen sich auf Protokollebene behandeln, andere erfordern möglicherweise Eingriffe durch den Nutzer oder sind schwer zu lösen
- Die Unterstützung des EWS-Protokolls wird über
ewsund das interne Crateews_xpcomerweitert und mit der Thunderbird-Oberfläche verbunden- Ein aktueller Patch ermöglicht es, EWS-Konten in Thunderbird hinzuzufügen
- Die Ordnerhierarchie eines Kontos kann mit dem Remote-Server synchronisiert werden
- Synchronisierte Ordner können in der UI angezeigt werden
- Diese Funktion befindet sich derzeit im Alpha-Stadium und ist hinter Build-Flags und Konfigurationswerten verborgen
- Als Nächstes sollen das Abrufen von Nachrichtenlisten vom Remote-Server sowie eine Verallgemeinerung der Unterstützung für ausgehende E-Mails in Thunderbird umgesetzt werden
- Für die Wartung wird dokumentiert, wie die einzelnen Komponenten zusammenwirken, wie die bestehende Thunderbird-Mail-Protokoll-Architektur aussieht und in welche Richtung sie künftig verbessert werden soll
Beziehung zwischen EWS und Microsoft Graph
- EWS wird in Exchange Online nach Oktober 2026 nicht mehr nutzbar sein
- Voruntersuchungen des Projekts zeigen jedoch, dass es weiterhin eine beträchtliche Zahl an Nutzern von On-Premises Exchange Server gibt
- Viele Unternehmen und Bildungseinrichtungen betreiben Exchange Server auf eigener Hardware
- Diese On-Premises-Installationen unterstützen in der Regel EWS
- Eine Azure-basierte Graph API können sie nicht unterstützen
- Die EWS-Unterstützung ist damit in naher Zukunft ein Mittel, diese Nutzer zu unterstützen
- Bei der Graph API gibt es noch einige ungelöste Probleme
- Die Graph API wurde mit Blick auf webbasierte Dienste entwickelt, nicht auf Desktop-Anwendungen
- Wenn zuerst EWS-Unterstützung hinzugefügt wird, gewinnt man Zeit, Lösungen für diese Probleme zu finden, bevor Unterstützung für die Graph API entsteht
- Die Arbeit an Rust und EWS ist Teil einer größeren Anstrengung, die Turnaround-Zeit von Thunderbird zu verkürzen und die Widerstandsfähigkeit des Software-Kerns zu erhöhen
1 Kommentare
Meinungen auf Hacker News
Ich verstehe nicht, warum man das implementiert, wenn EWS bereits zur Einstellung vorgesehen ist und in zwei Jahren entfernt wird: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...
Wenn EWS verschwindet, werden wohl ziemlich viele Kunden gehen; anfangs vielleicht nicht genug, um Microsofts Zahlen zu treffen.
Am Ende zeigt sich dann, dass alle E-Mails gleich sind, und Exchange Online könnte zu einer Fußnote der Geschichte werden. Oberflächlich wirkt es etwas peinlich, dass Microsoft E-Mail macht und es so gründlich vermasselt, aber in Wirklichkeit ist es nicht unbedingt so.
Der Betrieb von E-Mail-Systemen ist schmerzhaft, und was Microsoft wirklich will, sind Daten und Metadaten, die man ausschürfen und an andere Datenbesessene verkaufen kann. E-Mail ist gemessen am Speicherplatz meist statisch und groß, aber im Austausch zwischen Personen kann eine Goldgrube stecken.
Idealerweise lässt man AWS, Google und ähnliche Anbieter den Schmerz übernehmen und bringt die Kunden dazu, Outlook zu verwenden. Dann ändert man es so, dass die Zugangsdaten wie in der neuen Electron-Version von Outlook in der Microsoft-Cloud gespeichert werden, und nutzt diese Zugangsdaten, um E-Mail-Daten in den Clouds anderer Leute auszuschürfen, während diese die Speicherkosten tragen. Hervorragend.
Die Graph API wurde ebenfalls geprüft und könnte künftig erneut geprüft werden, aber derzeit ist ihr Unterstützungsumfang geringer als bei EWS, und es fehlen einige Funktionen, die Desktop-Anwendungen benötigen.
Auch wenn angekündigt wurde, dass die EWS-Unterstützung in Exchange Online entfernt wird, hat sie kurzfristig weiterhin Wert, um einem breiten Nutzerkreis Zugang zu ermöglichen, und langfristig, um Nutzer von On-Premises-Installationen zu unterstützen.
Wenn das Ziel einfach ist, mehr Thunderbird-Nutzer zu gewinnen, ergibt es strategisch Sinn; ideologisch wirkt JMAP-Unterstützung aber viel besser.
Ich habe neulich Thunderbird statt Outlook ausprobiert, und es hatte dasselbe Problem wie Firefox vor dem Quantum-Update: viel zu langsam.
Beim Wechsel zwischen Ordnern mit Hunderten bis Tausenden Mails gibt es eine spürbare Verzögerung; in Outlook passiert das praktisch sofort.
Beim Kalender ist es genau andersherum, deshalb lasse ich derzeit beide nebeneinander laufen. Ein Problem scheint die iCal-Bridge zu dem Outlook-Server zu sein, den ich in der Firma nutzen muss.
Daran ändert diese Ankündigung leider nichts. Eine Zeit lang habe ich das von Ericsson gepflegte EWS-Add-on verwendet: https://github.com/Ericsson/exchangecalendar
Aber Mozilla hat die Schnittstellen offenbar so schnell kaputtgemacht, dass viele Plugin-Entwickler abgesprungen sind. Jetzt bauen sie wieder Teile der Funktionalität in den Core ein, aber ich bin mir nicht sicher, ob das eine gute Strategie ist. Meiner Ansicht nach sollten sie sich lieber auf stabile Schnittstellen konzentrieren.
Ich mag Exchange nicht, aber diese Arbeit begrüße ich. Vielleicht kann ich jetzt selbst in der Windows-Zwangslage erfolgreich Plain-Text-Mails aus Exchange verschicken.
Nachdem ich gesehen habe, wie häufig Plain-Text-E-Mails nicht auf eine sinnvollere Weise, sondern in einer Festbreitenschrift gerendert werden, fällt es mir schwer, Plain Text allein mit „HTML-E-Mail ist ein Gräuel“ zu rechtfertigen.
Die Aussage, dass „in der gesamten 20-jährigen Geschichte des Thunderbird-Projekts niemand Unterstützung für ein neues Mail-Protokoll hinzugefügt hat“, ist technisch korrekt; allerdings brauchten die OAuth2-Out-of-Band-Authentifizierungen der großen Anbieter jeweils spezielle Einstellungen pro E-Mail-Client, also Workarounds, und Thunderbird hat davon ziemlich viele angesammelt.
Das sind keine allgemeinen Mail-Protokolle. Sie laufen nicht über IMAP, POP3 oder SMTP, sondern über HTTPS.
„Noch nie ein neues Mail-Protokoll hinzugefügt zu haben“ ist eine gute Sache, und diese Änderung ist keine gute. Unterstützung für proprietäre Setups ist praktisch und nachvollziehbar, aber nichts Gutes.
Sie lindert nur vorübergehend das Problem, dass E-Mail in Dutzende unternehmensspezifische Varianten zersplittert, und ermutigt die Leute langfristig, solche Varianten zu akzeptieren.
Dass man Thunderbird als Client verwenden kann, ist dagegen ein Nettogewinn und eine pragmatische Entscheidung.
Ich verstehe nicht, warum der Titel geändert wurde. Dieser Artikel handelt von Rust-Programmierung.
„Bringing Exchange Support to Thunderbird“ klingt wie ein Artikel über Thunderbird und Exchange-Unterstützung, aber das geht aus diesem Artikel nicht hervor.
Unterstützung für proprietäre Spezifikationen mag nützlich sein, aber ich wünschte, Mozilla würde Standardimplementierungen wie die automatische Erkennung von Mail-Submission-Servern (SMTP) priorisieren. rfc6186 stammt zum Beispiel aus dem Jahr 2011.
Derzeit müssen Nutzer Hostnamen und Port des SMTP-Servers manuell eingeben. Für die Leute hier auf dieser Seite mag das in Ordnung sein, für die übrigen 99,9 % der Menschheit ist es überhaupt nicht benutzerfreundlich.
Der Aufwand, ganz Exchange zu implementieren, dürfte wahrscheinlich um mehrere Größenordnungen höher sein als die Erkennung von Submission-Servern per DNS/SRV. Ich verstehe Mozillas Prioritäten wirklich nicht.
Werden diese als Sonderfälle behandelt?
Wow, das erinnert mich an die Zeit, als ich vor etwa 20 Jahren in der IT gearbeitet habe. Es war fast vollständig eine Microsoft-Umgebung, nur ein paar Leute nutzten Linux.
Exchange war immer eines dieser Dinge, für die es schwer war, einen brauchbaren Client zu finden, und wenn es das damals gegeben hätte, wäre ich wirklich überglücklich gewesen.
Microsoft-Produkte unter Linux zu verwenden ist wirklich schmerzhaft, und besonders wenn man nicht Edge nutzt, wirkt es so, als würden sie gerade dabei sein, die Teams-Webversion abzuschaffen. :(
Dass „Mozilla sich um 2012 herum von Thunderbird zurückzog und die Verantwortung an die Community übergab, sodass es bis zur Rückkehr von Thunderbird zur Mozilla Foundation im Jahr 2017 keine bezahlte Wartung gab“, war wirklich ein Skandal.
Das ist ein Paradebeispiel für Mozillas verdrehte Prioritäten.
Das muss einem nicht gefallen; ich bin darüber auch nicht besonders glücklich. Aber es ist nun einmal so, und für Mozilla war es nicht wert, dafür Geld bereitzustellen.
Ich wünschte, PST-Datei-Import wäre standardmäßig enthalten, damit Leute, die von einer Outlook-Installation weg wollen, reibungslos wechseln können, ohne Outlook selbst anfassen zu müssen.
Es gibt bereits freie Projekte, die PST-Dateien lesen können; man müsste sie nur in die Produktsuite integrieren.
Edit: Ah, nein. Nur On-Premises. Das ist wirklich dumm.