Als weltweit größter Anbieter von verschlüsselten E-Mails gehört die Arbeit mit IMAP (Internet Message Access Protocol) zu unserem täglichen Geschäft. IMAP ist ein Kernbestandteil der Proton Mail Bridge-App, die es dir ermöglicht, Proton Mail-Verschlüsselung zu Standard-E-Mail-Clients wie Outlook, Thunderbird oder Apple Mail hinzuzufügen.
Aber IMAP geht über Proton Mail hinaus. Es ist einer von zwei standardisierten E-Mail-Abrufprotokollen (das andere ist POP), die fast jede E-Mail-App verwendet, um auf deine E-Mails zuzugreifen und sie zu verwalten. Im Wesentlichen treibt es also den E-Mail-Verkehr weltweit an.
Heute stellen wir Gluon(new window) vor, eine neue IMAP-Bibliothek, die in der Programmiersprache Go geschrieben ist und darauf ausgelegt ist, leistungsstark, zuverlässig, entwicklerfreundlich und vor allem Open Source zu sein.
Zusammen mit der Einführung von Gluon veröffentlichen wir auch eine neue Version der Proton Mail Bridge, die von Gluon angetrieben wird. Dank der folgenden Innovationen ist die neue Proton Mail Bridge 1000% schneller, weitaus zuverlässiger und zudem mit mehr E-Mail-Clients kompatibel.
Warum eine neue IMAP-Bibliothek erstellen?
E-Mails müssen zuverlässig sein, aber auch leistungsstark, besonders da die typische Größe des Posteingangs im letzten Jahrzehnt deutlich zugenommen hat. Viele Open-Source-IMAP-Implementierungen optimieren eher für das eine als für das andere, was zu ziemlich signifikanten Kompromissen oder Fehlern führt.
Gluon versucht, diese Lücke zu schließen und die Einschränkungen in bestehenden Open-Source-IMAP-Bibliotheken zu überwinden, die oft schlecht gewartet oder nicht vollständig skalierbar sind. Gluon erreicht dies durch eine Architektur, die auf einem „Snapshot“-System basiert.
IMAP-Clients beziehen sich typischerweise auf Nachrichten anhand ihrer „Sequenznummer“, der Position der Nachricht in einem Postfach. Die erste Nachricht hat die Sequenznummer „1“, die zweite „2“ und so weiter. Wenn ein Client eine Nachricht als „gelesen“ markieren möchte, sendet er einen Befehl an den Server wie „markiere Nachricht 5 als gelesen“. Was aber, wenn ein anderer Client die vierte Nachricht im Postfach gelöscht hat? Die Sequenznummern aller Nachrichten nach der gelöschten Nachricht werden um eins nach unten verschoben; der Client, der den Befehl „markiere Nachricht 5 als gelesen“ gesendet hat, bezieht sich nun auf eine andere Nachricht als beabsichtigt.
IMAP-Server (zu denen auch Anwendungen wie die Proton Mail Bridge gehören) müssen in der Lage sein, diese Situation zu bewältigen. Wenn ein Client Nachrichten in ein Postfach verschiebt oder daraus entfernt, muss der Server alle anderen Clients über die Änderungen informieren, damit diese ihre eigene Ansicht des Postfachs aktualisieren können. Und bis die Clients das Update erhalten haben, muss sich der Server daran erinnern, wie jeder Client glaubt, dass das Postfach aussieht, um die Befehle des Clients korrekt zu interpretieren.
Im obigen Beispiel muss der Server wissen, dass der Client, der den Befehl „markiere Nachricht 5 als gelesen“ gesendet hat, sich auf die Nachricht bezieht, die ursprünglich auf Position 5 war, und nicht auf die Nachricht, die aktuell auf Position 5 ist.
Ein solches Szenario kann im modernen E-Mail-Verkehr häufiger auftreten, wo der Nutzer Proton Mail im Web auf einem Gerät verwendet, die mobilen Apps unterwegs nutzt und dann über die Proton Mail Bridge einen Desktop-Client auf einem Desktop verwendet, wobei nicht alle gleichzeitig online sein müssen.
Ein anderes Szenario sind E-Mail-Apps, die oft mehrere gleichzeitige Verbindungen zu deinem Postfach nutzen, um die Dinge zu beschleunigen, was dann zu Gleichzeitigkeitsproblemen führen kann. Indem Gluon ein Snapshot-System verwendet, weist es jedem IMAP-Client seinen eigenen „Snapshot“ des ausgewählten Postfachs zu. Jeder Snapshot hält die einzigartige Sicht des Clients auf das Postfach fest und ermöglicht es dem Server, genau zu interpretieren, auf welche Nachricht sich der Client zu jedem Zeitpunkt bezieht, unabhängig davon, welche Aktionen von anderen Clients durchgeführt wurden. Das garantiert eine stabile und konsistente E-Mail-Erfahrung für den Nutzer.
Wie wir Gluon entwickelt haben
Unser erster Schritt bei der Entwicklung von Gluon war die Erstellung eines IMAP-Parsers aus der Syntax, die in RFC3501(new window) gegeben ist. Wir verwendeten ANTLR4(new window), einen beliebten Parser-Generator, um einen Parser zu erstellen, der IMAP-Befehle und -Antworten gemäß der Spezifikation parsen konnte. Das ermöglichte es uns, uns auf die Implementierung der Logik des IMAP-Protokolls zu konzentrieren, anstatt Eingaben zu parsen und zu validieren.
Nachdem wir einen Parser hatten, schrieben wir den grundlegenden Server-Typ für Gluon. Der Server-Typ wartet auf eingehende TCP-Verbindungen und startet für jede Verbindung eine “IMAP-Sitzung”, die in einer separaten Goroutine ausgeführt wird (ein leichtgewichtiger, grüner Thread, der in der Programmiersprache Go verwendet wird).
Die Sitzung hat eine einfache Aufgabe:
- Einen Befehl des Clients lesen.
- Den Befehl parsen.
- Den richtigen Befehlshandler aufrufen.
- Schließlich jede notwendige Antwort an den Client senden.
Dieses Design ermöglicht es Gluon auch, mehrere Client-Verbindungen gleichzeitig zu verwalten, wobei jede Sitzung ihren eigenen Zustand verwaltet.
Eine der Hauptaufgaben bei der Implementierung eines IMAP-Servers ist die Verwaltung der dauerhaften Zustände und sitzungsspezifischen Zustände von Postfächern. Der dauerhafte Zustand bezieht sich auf die Nachrichten, die tatsächlich in einem ausgewählten Postfach sind, während der sitzungsspezifische Zustand sich auf die Nachrichten bezieht, von denen jeder Client glaubt , dass sie derzeit in einem ausgewählten Postfach sind.
In Gluon verwenden wir eine SQL-Datenbank, um den dauerhaften IMAP-Zustand zu speichern, wie zum Beispiel welche Postfächer und Nachrichten ein Nutzer hat. Darüber hinaus ermöglicht die SQL-Datenbank durch intelligentes Vorausladen und Indizieren eine schnellere und effizientere Verarbeitung von Befehlen.
Die Verwaltung des sitzungsspezifischen Zustands war komplizierter, da sie vollständig davon abhängt, welche IMAP-Antworten zu einem bestimmten Zeitpunkt an einen Client gesendet wurden. Um dies zu modellieren, definierten wir einen Typ, der eine Liste von Nachrichten-IDs, UIDs und Flags im Speicher hält. Diese Liste wird aus der Datenbank gefüllt, wenn ein Client zum ersten Mal ein Postfach auswählt. Dieser Ansatz ermöglicht es uns, den sitzungsspezifischen Zustand effizient zu verwalten und viele IMAP-Befehle vollständig im Speicher zu verarbeiten, ohne Festplattenzugriffe zu benötigen, was zu einer viel schnelleren Leistung führt.
Um den sitzungsspezifischen Zustand zwischen mehreren verbundenen Clients zu synchronisieren, verwendet Gluon ein System von „Respondern“. Das sind Typen, die eine Zustandsänderung kapseln und bei Ausführung in IMAP-Antworten umgewandelt werden. Wenn ein Client eine Aktion durchführt (wie das Markieren einer Nachricht als gelesen), die den Zustand eines anderen Clients ändern würde, erstellt das Backend einen Responder für die Aktion und leitet ihn an den betroffenen Zustand weiter. Der betroffene Zustand bleibt unverändert, bis der Responder ausgeführt wird, zu welchem Zeitpunkt er aktualisiert wird und eine entsprechende IMAP-Antwort an den Client gesendet wird. Dieser Ansatz ermöglicht es Gluon, den sitzungsspezifischen Zustand effizient zu verwalten und gleichzeitig Konsistenz über mehrere Clients hinweg sicherzustellen.
Beim Aufbau der Unterstützung für jeden IMAP-Befehl in Gluon verwendeten wir testgetriebene Entwicklung. Wir erstellten ein Testframework, das es uns ermöglichte zu spezifizieren, wie eine gesamte IMAP-Sitzung aussehen sollte, indem wir Client-Befehle und erwartete Server-Antworten festlegten.
Zuerst schrieben wir einen Test für jeden IMAP-Befehl (oft direkt aus RFC3501 kopiert) und implementierten dann die Befehlsverarbeitung, um den Test zu bestehen. Darüber hinaus verwendeten wir, um die Korrektheit und Zuverlässigkeit von Gluon zu gewährleisten, Dovecot(new window), den weltweit beliebtesten IMAP-Server, als Referenzimplementierung und führten Korrektheitstests mit Dovecots eigenem Testwerkzeug, imaptest(new window), durch.
Der letzte Schritt war die Integration von Gluon in den Proton Mail Bridge. Wir haben Gluon so entworfen, dass die Integration in jede Anwendung so einfach wie die Implementierung seiner „Connector“-Schnittstelle sein sollte. Der Connector hält Gluon und externe Zustände (den Proton-Zustand) synchron.
Wenn beispielsweise ein IMAP-Client eine Nachricht als gelesen markiert, markiert der Connector dieselbe Nachricht auf dem Proton-Server als gelesen. Wenn der Proton-Server eine Nachricht erhält, lädt der Connector diese herunter, entschlüsselt sie und platziert sie im richtigen Gluon-Postfach.
Dieses erweiterbare Design ermöglicht die Verwendung von Gluon mit fast jeder Anwendung, die IMAP benötigt.
Datenschutz ohne Kompromisse bei der Leistung
Zu Beginn dieses Jahres haben wir die neue Version 3 des Proton Mail Bridge (angetrieben von Gluon) in die Beta-Tests gegeben, und das Nutzerfeedback stimmte mit unseren eigenen Leistungstests überein, die eine Geschwindigkeitsverbesserung von 1000 % anzeigen. Wir hoffen, dass wir durch die Veröffentlichung von Gluon als Open-Source-Software eine neue Generation moderner E-Mail-Software ermöglichen können, die besser auf die Anforderungen heutiger E-Mail-Nutzer eingehen kann.
Als Open-Source-Unternehmen begrüßen wir es, wenn andere den Code nutzen, überprüfen und dazu beitragen, und wie bei anderen Open-Source-Projekten, die Proton pflegt(new window), sind wir langfristig zur Pflege dieser Bibliothek verpflichtet.
Unsere Mission ist es, Privatsphäre online zugänglich und weit verbreitet zu machen, und ein besserer Proton Mail Bridge, der durch Gluon angetrieben wird und Ende-zu-Ende-verschlüsselte E-Mails auf jeder Desktop-E-Mail-Anwendung verfügbar macht, ist ein wichtiger Schritt, um dieses Ziel zu erreichen.
Wie immer danken wir dir für deine Unterstützung und vergiss nicht, dein Feedback und deine Gedanken mit uns auf Reddit(new window) und Twitter(new window) zu teilen.
Diese Arbeit wurde von James Houlahan, Leander Beernaert, Jakub Cúth, Xavier Michelon, Romain Le Jeune, Gjorgji Slamkov, Alexander Khusanov, Gabor Meszaros und Andrzej Szafranski aus dem Proton Mail-Team durchgeführt.
