Systemadministratoren erinnern sich sicher noch an die Schmerzen, die der Betrieb von Mailservern Anfang der 2000er-Jahre mit sich brachte. Nein, wir reden nicht von Sendmail-Konfigurationsdateien, das Problem löste Postfix wunderbar auf. Maßgeblich verantwortlich für viele Inkompatibilitäten war Microsoft: Der Konzern hatte früh das Potenzial des Internets erkannt und proprietäre Anwendungen auf den Markt gebracht, die sich kaum um bestehende Standards kümmerten und diese teils gar nicht erst zu implementieren versuchten. Microsoft dominierte mit Exchange einst den Groupware-Markt fast vollständig und noch immer finden sich vielerorts Exchange-Installationen.

Wollen IT-Verantwortliche von Exchange hin zu einer standardbasierten, quelloffenen Implementierung wechseln, finden sie in Open-Source-Software wie etwa grommunio eine Alternative. Dass es zum Teil allerdings sehr kompliziert und aufwendig ist, die proprietären Microsoft-Protokolle nachzubauen, demonstrierten die grommunio-Entwickler um Jan Engelhardt bei der FOSDEM in Brüssel [1]. Dabei zeigten sie auch, wie sie vorgehen und welche proprietären Protokolle von Exchange grommunio mittlerweile beherrscht [2].

E-Mails sind dafür ein hervorragendes Beispiel. Denn es ist ja nicht so, als seien POP3, IMAP und SMTP Erfindungen der Neuzeit, die Anfang der 2000er-Jahre noch nicht zur Verfügung gestanden hätten - ganz im Gegenteil. Auch Sendmail, Postfix und Dovecot sind offene und gut dokumentierte Standards, die Redmond aber in schöner Regelmäßigkeit verschmähte. POP3 und IMAP etwa ließen jede Option auf eine Kalenderfunktion vermissen, erklärte Microsoft, die offenen Standards böten folglich gar nicht alle Funktionen, die Nutzer im Alltag benötigten. Stattdessen müsse es ein von Microsoft selbst erdachtes Protokoll als POP3-Ersatz sein, das die angeblich fehlenden Funktionen liefert, das aber natürlich kein offener Standard werden durfte.

Damals lief auf Arbeitsplatzcomputern fast ausschließlich Windows, das mit Outlook Express im Schlepptau den Nutzer von Anfang an in die Microsoft-Welt einband. Dass Redmond zudem in Form von Exchange früh mit einer Art Groupware am Start war, sorgte dafür, dass Microsoft zu einem nicht zu ignorierenden Faktor im Datenverkehr des frühen Internets wurde - sehr zum Leidwesen jener, die Nicht-Microsoft-Mailserver pflegen mussten. Denn diese hatten regelmäßig Schwierigkeiten damit, E-Mails mit Exchange-Installationen auszutauschen. Bis heute finden sich Exchange-Instanzen, die GPG-Signaturen in E-Mails beschädigen, weil sie deren korrekte Handhabung nicht beherrschen.

Auch die als Bestandteil von Windows ausgelieferten E-Mail-Programme trugen andererseits ihr Scherflein bei, indem sie mit anderen Servern als Exchange nur teilweise oder in mancherlei Hinsicht gar einsetzbar waren. Auch wenn es gerade jüngeren Administratoren heute in dieser Schärfe gar nicht mehr klar ist: Eine ganze Weile existierte im Groupware-Universum einerseits Microsoft mit Exchange und der ganze Rest andererseits, der sich mal mehr und mal weniger an offene Standards hielt und besser oder schlechter mit Exchange interagieren konnte.

Besonders in jüngerer Vergangenheit hat sich allerdings einiges grundlegend geändert. Microsoft hat sich längst technischer Innovation verschrieben und ist in vielerlei Hinsicht nicht mehr darauf bedacht, Monopole zu bilden. Was auch damit zu tun haben dürfte, dass Redmond vor diversen Regulierungsbehörden teuer baden ging. Jahrzehnte technischer Schuld schafft das allerdings nicht aus der Welt.

Denn nach wie vor setzen lokal installierte Exchange-Server unter der Haube auf diverse Protokolle und Standards, die in der Vergangenheit entstanden und für die es entweder gar keine oder höchstens unvollständige Alternativen gibt. Gleichzeitig fühlen sich immer mehr IT-Verantwortliche unwohl mit der Bindung an Microsoft durch Exchange und beginnen mit der Suche nach Alternativen.

Gerade in größeren Konzernen und Organisationen ist das allerdings alles andere als ein leichtes Unterfangen. Denn bestehende und liebgewonnene Funktionen sollen einerseits erhalten bleiben und andererseits tun sich die Endanwender oft schwer mit einem neuen E-Mail-Client, ganz zu schweigen von der notwendigen Einarbeitung. Hier setzt grommunio an und verspricht Unternehmen, ein Eins-zu-eins-Ersatz für Exchange zu sein und dessen Protokolle vollumfänglich zu unterstützen, ohne Registry-Einträge und Plug-ins auf Windows sowie ohne zusätzliche Apps auf Android oder macOS. Client-Apps gibt es nur für die erweiterten Funktionen rund um die integrierten Jitsi Meet, Nextcloud und Mattermost.

Das funktioniert aber nur, weil grommunio die diversen Protokolle nachgebaut hat - inklusive vieler Krücken und Workarounds, die sich Microsoft in den vergangenen Jahrzehnten überlegt hat. Mancher Admin mag da skeptisch werden und infrage stellen, ob das Ansinnen überhaupt möglich ist, auch weil schon viele Open-Source-Projekte daran gescheitert sind.

Um solche Bedenken auszuräumen, haben die grommunio-Entwickler, vertreten durch Jan Engelhardt, bei der diesjährigen FOSDEM in Brüssel einen Einblick in ihre Arbeit gegeben. Engelhardt erläuterte dort im Detail, mit welchen Protokollen sie es überhaupt zu tun haben und auch, wie sie diese untersuchten und nachbauten, um Kompatibilität mit den diversen Outlook-Clients und anderen Programmen zu erreichen. Dank einer konsequenten Open-Source-Strategie kommen das Reverse Engineering und die Implementierung der Protokolle und APIs jedermann zugute.

Die grommunio-Groupware besteht aus mehreren Komponenten, im Kern werkelt aber Gromox. Dies ist das Werkzeug, innerhalb dessen der größte Teil der aus Exchange und Outlook stammenden Protokolle umgesetzt ist. Kommuniziert ein Client also mit grommunio, redet er in den meisten Fällen direkt mit Gromox. Ursprünglich basierte Gromox auf einer Open-Source-Software namens "Steep", ist also ein Fork von Steep. Doch diese Software hatte noch zahlreiche Defizite, knapp 2500 Coverity-Defekte und über 17.000 Compiler-Warnungen musste grommunio bearbeiten: Vier arbeitsreiche Jahre voller Entwicklung später liegt Gromox in C++ vor und baut wo immer möglich auf die stdlib auf, mit C++17 oder neuer.

Und genau da muss dann auch die Magie passieren, die grommunio dazu bringt, einerseits quelloffen zu sein, andererseits aber Microsoft-spezifische Protokolle und Erweiterungen zu unterstützen. Ein zentraler Schlüssel dafür, wie das funktionieren kann, ist ein tiefgreifendes Verständnis von Microsofts Exchange-Protokollen und -Spezifikationen. Hier unterscheiden die Entwickler zwischen mehreren Ebenen.

Zunächst geht es um die Frage, über welches Protokoll ein Exchange-Server und der anfragende Client miteinander kommunizieren. In der Nicht-Microsoft-Welt ist klar, dass für E-Mails die bewährten Standards SMTP, POP3 oder IMAP zum Einsatz kommen und macOS EWS (Exchange Web Services) nutzt. Die Details von Protokollen wie beispielsweise ROP (Remote Operations Protocol), EWS oder dem MAPI-Stack sind etwas verwirrend und überaus komplex organisiert. Heute ist die babylonische Verwirrung perfekt, weil auch noch die Cloud und MS Graph hinzugekommen sind.

MAPI meint eigentlich nicht immer das gleiche Protokoll, auch wenn der Begriff MAPI heute regelmäßig als Synonym für sämtliche Standards und Vorgaben genutzt wird, die Microsoft und Exchange umgehen. Der historische Hintergrund der MAPI ist aber eigentlich ein anderer: Die Abkürzung steht für "Messaging Application Programming Interface" [3] und beschreibt zunächst eigentlich nur technische Standards für eine Schnittstelle in Windows, die Programme in die Lage versetzen sollte, E-Mails zu versenden. E-Mails lesen lassen sich aber sowohl mit POP, IMAP, MAPI, ROP, EWS und EAS.

Mindestens ebenso verwirrend ist dabei, dass auch MAPI im Laufe seiner Geschichte etliche großflächige Umbauten durchlaufen hat. Zunächst etwa war es lediglich auf den Versand vom lokalen Host aus beschränkt, bestimmte Funktionen innerhalb des LAN unterstützte es ebenfalls. Mit Outlook Anywhere gab es dann Microsofts E-Mails überall, auch außerhalb von Windows-Domänen. Outlook 2010 brachte RPC-over-HTTP, heute ebenfalls ein Protokoll im MAPI-Stack. Exchange 2013 bohrte MAPI nochmals gehörig auf und schuf ein neues "Wire-Protocol", das anstelle der ersten Implementierung (geeignet nur für LANs) und der zweiten Variante (RPC über HTTP) letztlich normales HTTP nutzt und bis heute zur Anwendung kommt. Eine Übersicht der komplexen Hintergründe samt Abkürzungen liefert [4].

Das über die Jahre entstandene Kuddelmuddel bei den Protokollen und MAPI-Erweiterungen brachte weiteres Ungemach: Denn durch seine Eigenschaft als De-Facto-schaffende Instanz für Standards hat MAPI implizit auch viele weitere Details der Kommunikation zwischen Exchange und seinen Clients definiert. Dazu gehört das genutzte Datenmodell ebenso wie die bereits beschriebenen Wire-Protocols, also die Protokolle, die Client und Server für die Kommunikation nutzen.

Offiziell bezeichnet Microsoft beinahe jede einzelne Funktion, die in der Kommunikation mit Exchange oder auch mit Exchange Online aufrufbar ist, als "Protokoll". Der Hersteller beruft sich darauf, dass jedes dieser Protokolle mittlerweile öffentlich dokumentiert ist, weshalb auch das Verhalten des Servers nachvollziehbar wird, wenn ein Client einen bestimmten Befehl schickt. Diese Dokumentation umfasst 8400 Seiten, ist jedoch keineswegs fehlerfrei, vollständig oder stets zutreffend. Vor allem gibt es dabei immer wieder Probleme mit Clients, die zu unterschiedlichen Zeitpunkten entstanden, aber dieselben Funktionen unterschiedlich implementieren.

Microsoft fällt das freilich nur selten überhaupt auf, denn im Konzern gibt es schließlich eine Matrix von unterstützten Exchange-Versionen und den jeweils damit zusammen unterstützten Varianten von Outlook, Outlook Express und Windows Mail. Alles außerhalb dieser statischen Zuweisung von Server und Client interessierte Redmond schlicht nicht, das änderte sich erst mit Mobilgeräten und Apple-Anbindung. Beim Quasi-Nachbau von Exchange in Form eines Open-Source-Projekts sind die Feinheiten der Doku und die des Verhaltens eines Clients sehr schnell wichtig. Es lassen sich dementsprechend etliche Stellen in der Microsoft-Dokumentation finden, bei denen sich einzelne Varianten von Exchange oder Outlook nicht so verhalten, wie der Standard es vorgibt.

Allerdings ändert Microsoft die Dokumentation oder versieht sie zumindest mit einem Warnhinweis, wenn entsprechende Fehlerberichte eintreffen. Die grommunio-Entwickler allerdings lässt das mit dem Problem zurück, Gromox so zu entwickeln, dass es nicht nur die Exchange-eigenen Funktionen bietet, sondern diese im Tandem mit diversen Exchange-kompatiblen Clients auch in der jeweils richtigen Form implementiert. Wer sich jetzt klassisches Debugging auf dem Draht und eine bestimmte Form des Reverse Engineerings vorstellt, liegt goldrichtig: Genau so gehen Engelhardt und die knapp 30 grommunio-Entwickler vor, wenn sie ein neues Exchange-Protokoll implementieren und testen.

Zwar bietet Microsoft selbst eine Anwendung namens "MFCMAPI" an, die etliche Protokolle von Exchange und Exchange Online beispielhaft implementiert und ihre Funktionalität so dokumentiert. Obendrein fungiert MFCMAPI auch als Referenzimplementierung. Aber das Debugging lässt sich mit MFCMAPI nur insofern betreiben, als dass sich anhand der Funktionalität im Programm nachvollziehen lässt, wie Client und Server sich grundlegend verhalten sollen. Tun sie das in einer spezifischen Kombination nicht, sind Werkzeuge nötig, die auch beim klassischen Reverse Engineering zum Einsatz kommen. Auf der untersten Protokollebene, also dem Wire-Protocol, setzt grommunio dabei beispielsweise auf TCP-Analyse-Tools.

Werkzeuge wie Tcpdump oder Wireshark geben den Netzwerkverkehr aus und zeigen die Daten optisch aufbereitet an. Das macht sie obendrein durchsuchbar und erleichtert einem Entwickler auf der Suche nach Fehlern das Leben erheblich. Deutlich eingeschränkt ist der Nutzen von Tcpdump und Wireshark allerdings, wenn verschlüsselte Verbindungen zum Einsatz kommen - und das ist beim Austausch von E-Mails heute Standard. Deshalb benötigen die Entwickler ein zusätzliches Werkzeug namens Fiddler [5], das gewissermaßen eine gewollte Man-in-the-Middle-Attacke zwischen Client und Server initiiert und so das Auffinden von Bugs ermöglicht. Dazu konfiguriert der Entwickler Fiddler zunächst so, dass es dieselben SSL-Zertifikate besitzt wie der Client und der Server und sich der jeweils einen Instanz gegenüber als die andere ausgeben kann. Weil Fiddler HTTPS unterstützt und MAPI mittlerweile HTTPS wie beschrieben als Transportprotokoll nutzt, sind die beiden Ansätze kompatibel.

Sobald die Kommunikation zwischen Exchange-Server, dem jeweiligen Client und Fiddler etabliert ist, lesen die Entwickler dann zunächst die Kommunikation zwischen Client und Server mit und vergleichen das Geschehen mit den Standardbeschreibungen Microsofts. Dann implementieren sie in Gromox vergleichbare Funktionalität und testen mit diversen Clients erneut, bis es funktioniert wie gewünscht.

Die Erfolge können sich sehen lassen: Bis zum Redaktionsschluss hat grommunio nach eigener Aussage nicht weniger als 42 der Exchange- und Exchange-Online-Standards als Open Source implementiert. Heute macht das bereits einen ordentlichen Teil der zuvor bereits erwähnten 8400 Seiten Dokumentation aus, eine stets aktualisierte Liste der aktuell unterstützten Protokolle zeigt die bereits erwähnte Website [2].

Für die Zukunft gibt es obendrein umfassende Pläne: Nicht nur soll die grommunio-Unterstützung für die diversen Exchange-Protokolle noch besser werden, sondern grommunio soll auch beim Austausch von E-Mails mit Nicht-Exchange-Servern die Latte noch höher hängen. Schon bisher implementiert Gromox neben MAPI und den diversen Exchange-Protokollen auch SMTP, IMAP sowie POP 3. Den Support für die diversen offiziellen E-Mail-Standards etwa der IETF wollen die Entwickler künftig aber noch deutlich ausbauen und dabei auch die MAPI-Schnittstelle besser einbinden.

Engelhardts Einblicke zeigen, dass ein Drop-in-Ersatz für Exchange alles andere als trivial zu bauen ist und einiges technische Geschick erfordert. Aber er ist möglich und grommunio wähnt sich diesbezüglich auf einem guten Weg. Die Open-Source-Groupware bringt ganz nebenbei zahlreiche weitere Features mit, die Exchange nicht von Haus aus an Bord hat - von Chat, Konferenzen, Archiv, Domänen- und Multitenant-Management bis hin zu File-Share und Sync sowie modernem Monitoring.