© pixelvario / 123RF.com

Es muss Office 365 sein, aber die E-Mails sollen lieber über eigene Server laufen? Das ist nicht ganz einfach, aber machbar.

Wo man auf Office 365 in der Cloud umstellt, bleiben Linux-Nutzer auf der Strecke. Datenschutz und IT-Sicherheit sprechen objektiv gegen die Office-Cloud. Die Usability ist meiner Meinung nach aus der Hölle – zumindest sowohl die der Outlook-Web-App als auch des nativen Clients. Dazu kommt die Bespitzelung durch Dynamics 365, die Unsicherheit, was mit den eigenen E-Mails auf dem fremden Server passiert und wer da alles Zugriff hat. Viele Gründe, lieber mit echten, standardkonformen Mailclients arbeiten zu wollen und am besten die Nachrichten auch lokal vorzuhalten, wenn man schon das fragwürdige Produkt aufgezwungen bekommt.

Unterstützte früher ein lokales Exchange mit den üblichen Einschränkungen Microsofts so leidlich den IMAP-Standard, ist dank OAuth2 heutzutage schon die Authentifizierung für die meisten MUAs unmöglich. Stellt also der Arbeitgeber auf Exchange in der Office-365-Cloud um, bleiben die eigenen Mailclients auf der Strecke. Das zwingt zum Outlook-Web-Access, der beim Offline-Arbeiten (etwa auf Reisen) wenig Freude bringt, oder Outlook als Mailclient, der zumindest mich mit seiner unterirdischen Usability regelmäßig in den Wahnsinn treibt.

Datenschutz

Daneben entstehen durchaus relevante Datenschutzfragen. Die erste hat Max Schrems vom EuGH durchjudizieren lassen: Daten europäischer Nutzer dürfen nicht ohne Weiteres in die USA gelangen, sondern müssen in Europa bleiben.

Hintergrund sind die häufig laxen Datenschutzvorschriften in den USA. Hinzu kommt das Recht der US-Geheimdienste auf Einsicht – überwacht nur durch eine Sondergerichtsbarkeit, ohne Publikationspflicht derer, die Einblick gewähren müssen. Theoretisch wären das perfekte Voraussetzungen für Industriespionage; das sollte selbst den datenschutzfeindlichsten Unternehmer von der Office-Cloud abhalten. Nun stellt sich Microsoft auf den Standpunkt, dass ihre Server in Europa stünden, es erfolge kein Transfer in die USA. Wer spitz auf deren Cloud ist, erfreut sich an der Nebelkerze. Wer kritisch nachfragt, erfährt, dass der US-Konzern “zu Wartungszwecken” Vollzugriff hat. Das genügt nach Ansicht der konsequenteren Datenschützer, um eine unzulässige Datenübertragung in die USA zu konstituieren.

Daneben wirbt der Softwareschuppen aus Redmond mit einer Analyse des Nutzungsverhaltens, unter anderem, um Beziehungsnetze in und außerhalb der Organisation zu erzeugen. Wer auf eine solche Digital-Stasi nicht steht, kann das zwar in der Benutzeroberfläche abschalten und hoffen, dass es Microsoft nicht so ergeht wie LimeVPN, denen angeblich nicht aufgezeichnete Daten abhandengekommen sind. Oder er zieht sich die E-Mails auf ein lokales System. Wem da unwohl wird, dem bleibt die Beschwerde bei der zuständigen Datenschutzaufsicht, doch so manche ist auf dem Auge Microsoft schlicht blind. Oft lautet das Argument, es gebe keinen gleichwertigen Ersatz. Linux-Magazin-Leser können das widerlegen.

OAuth2

Also ist dann doch eine technische Lösung der verbleibende Weg. Da bot sich früher an, einfach mit Mbsync die Exchange-IMAP-Mailboxen auf einen lokalen IMAP-Server zu schieben. Doch seit Microsoft OAuth2 eingeführt hat, geht das nicht mehr, denn Mbsync beherrscht diesen Sonderweg nicht. Gegen Mbsync, das zwei IMAP-Accounts synchronisiert, spricht auch die Datensammelwut in der Office-Cloud: Beim Synchronisieren bleiben die E-Mails ja weiter für Microsoft im Zugriff. Wer dem Anbieter misstraut, hätte nichts gewonnen.

Das Prozedere sieht daher vor, einen lokalen IMAP-Account zu haben und zunächst einmal die Mailboxen aus der Office-Cloud dorthin zu schieben. Dann zieht man nur noch neue Nachrichten aus der Office-Cloud in den Account, sodass alle Nachrichten im lokalen IMAP-Account liegen. Anschließend gilt es, den Versand vom eigenen Rechner wieder über die Office-Cloud zu realisieren, weil sonst – SPF, DKIM und Co sei Dank – die eigenen Nachrichten wegen des unpassenden Mailservers als Spam gelten würden.

Damit entziehen sich die E-Mails dem Zugriff Microsofts. Das Setup bleibt aber maximal kompatibel und abstrahiert sauber von der Office-Cloud: Der eigene IMAP- und SMTP-Server sind standardkonform und zum Beispiel mit dem OpenSMTPd und Dovecot schnell aufgesetzt.

Next Generation

Weil ich meine E-Mails ungern in den Fängen des Redmonder Riesen lassen möchte, scheint Fetchmail eine gute Wahl. Das kann zwar in der aktuellen Version 7 noch kein OAuth2, aber der Next-Zweig beherrscht das Verfahren. Den gibt es auf Gitlab zum Download [1]. Der übliche Dreisatz aus »configure«, »make« und »make install« bringt Fetchmail zum Laufen.

Weil auf meinem System bereits für einen anderen Mailserver ein älteres Fetchmail lief und ich sichergehen wollte, dass dieser Teil meiner Konfiguration weiterläuft, habe ich meinem Fetchmail per »configure« als Suffix an den Programmnamen ein »-next« anhängen lassen. Damit hört es nicht mehr auf »fetchmail«, sondern nur noch auf »fetchmail-next«.

Token-Sammler

Dort, wo Make lief, liegt im Verzeichnis »contrib/« das Skript »fetchmail-oauth2.py«, das die nötigen Token für eine OAuth2-Authentifizierung erlangen kann (Listing 1, erste Zeile). Die Konfiguration dazu steht in meinem Beispiel im Home-Verzeichnis in der ».fetchmail-next.oauth2.cfg«. Listing 2 zeigt die Vorgaben für Outlook 365; der Nutzername (erste Zeile) wäre noch geeignet zu ersetzen.

$ contrib/fetchmail-oauth2.py -c ~/.fetchmail-next.oauth2.cfg -obtain_refresh_token_file
$ contrib/fetchmail-oauth2.py -c ~/.fetchmail-next.oauth2.cfg -auto_refresh

user=user@bei-ms-gehostet.net
client_id=9e5f94bc-e8a4-4e73-b8be-63364c29d753
client_secret=
refresh_token_file=/home/tobias/.fetchmail-next-refresh
access_token_file=/home/tobias/.fetchmail-next-token
imap_server=outlook.office365.com
smtp_server=outlook.office365.com
scope=https://outlook.office365.com/IMAP.AccessAsUser.All
https://outlook.office365.com/POP.AccessAsUser.All
https://outlook.office365.com/SMTP.Send offline_access
auth_url=https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url=https://login.microsoftonline.com/common/oauth2/v2.0/token
redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient

Tatsächlich darf das »client_secret« leer bleiben – was das dann bringt, wird ewig ein Geheimnis von Microsoft bleiben. Die »client_id« beschreibt der Kasten “Wie damals”. Sie ist wichtig: Passt sie nicht, gibt es obskure Fehlermeldungen, die nicht unbedingt verraten, dass Microsoft einfach den Client nicht mochte.

Das Skript meldet eine URL zurück, die man im erstmaligen Durchlauf in den Browser kopiert. Dort geht dann das Microsoft-Login-Theater los, an dessen Ende wieder eine URL in der Adresszeile des Browsers auftaucht. Darin steht das Secure-Token, das das Skript nun als Eingabe erwartet. Vorsicht beim Kopieren aus der URL: Oft hängt hinter dem Token noch ein weiterer Parameter, eine gründliche Suche nach dem »&«-Symbol lohnt sich.

Das Cut-and-Paste-Gewurstel mit der URL braucht es zum Glück nur selten, denn das Token lässt sich ohne Nutzerinteraktion automatisch aktualisieren. Das erledigt dasselbe Skript mit einem geringfügig anderen Parameter (Listing 1, zweite Zeile).

Soweit sich das aus der Dokumentation herauslesen lässt, ist solch ein Refresh alle 30 bis 40 Minuten notwendig. Mein System bekam einen Cronjob spendiert, der – wer weiß, was denen in Redmond so alles einfällt – alle 20 Minuten einen Refresh auslöst. Das erledigt via »crontab -e« der Eintrag aus Listing 3.

1,21,41 * * * * $HOME/fetchmail-next/contrib/fetchmail-oauth2.py -c $HOME/.fetchmail-next.oauth2.cfg -auto_refresh

Jagen und Sammeln

Mit dem Token ist Fetchmail nun gerüstet und kann sich die E-Mails aus der Office-Cloud ziehen. Das dafür nötige »~/.fetchmailrc« zeigt Listing 4. Können Sie beispielsweise wegen Firewalls nicht auf Port 993 für IMAP über TLS zugreifen, ändern Sie Ihre »~/.fetchmailrc« wie in Listing 5 gezeigt ab und behelfen sich mit einem SSH-Tunnel:

$ ssh ssh.example.com -L64993:outlook.office365.com:993

poll outlook.office365.com proto imap port 993
  bad-header accept
  auth oauthbearer username "user@bei-ms-gehostet.net"
  passwordfile "/home/tobias/.fetchmail-next-token"
  is o365 here
  tlsmode wrapped
  folders INBOX

poll 127.0.0.1 proto imap port 64993
  bad-header accept
  auth oauthbearer username "user@bei-ms-gehostet.net"
  passwordfile "/home/tobias/.fetchmail-next-token"
  is o365 here
  tlsmode wrapped
  sslcommonname outlook.office365.com
  no sslcertck
  folders INBOX

Die zusätzlichen Zeilen in der Konfiguration für den Tunneleinsatz weisen Fetchmail an, das Zertifikat nicht zu überprüfen, jedoch im TLS-Handshake den Rechnernamen »outlook.office365.com« statt »127.0.0.1« zu erwarten. Durch den Tunnel würde die Zertifikatsprüfung sonst scheitern.

Damit kann es losgehen: Das Kommando »fetchmail-next -f /home/tobias/.fetchmailrc« sammelt alle bisher ungelesenen E-Mails ein. Fetchmail ist in der Beispielkonfiguration so eingestellt, dass es abgeholte Nachrichten nicht auf dem Server lässt. Falls Sie das für Tests sympathischer finden, fügen Sie in der Konfiguration eine Zeile mit »keep« nach der fünften Zeile ein.

Übertrag

Jetzt soll freilich auch der Bestand aus dem Exchange-Online-Postfach seinen Weg auf den heimischen Mailserver finden. Dafür eignen sich OAuth-Proxies. Einer ist O2popper, der allerdings vornehmlich für Mailclients auf dem Arbeitsplatzrechner gedacht ist. Er lässt sich aber mit einem sportlichen Reverse-SSH-Tunnel auch vom Mailserver nutzen:

$ ssh mymailserver -R64993:localhost:8143 -g

Auch O2popper möchte eine Client-ID, doch zum Glück kennen wir ja die von Thunderbird. Gleiches, allerdings ohne bunte Oberfläche, leistet der Email-Oauth2-Proxy mit einem Python-Skript. Den kann man direkt auf dem Mailserver laufen lassen. In beiden Fällen lässt sich dann mit Mbsync oder per »doveadm-backup« der Inhalt der Mailbox auf den eigenen Server kopieren.

Ab die Post

Jetzt fehlt nur noch der Versand. Weil der eigene Server nicht als gültiger Absender für die Domain im Sender Permitted From (SPF) eingetragen ist und auch DKIM-Signaturen nicht funktionieren, müssen die E-Mails auch ausgehend über den Microsoft-Server gehen. Hier ist ebenfalls OAuth2 nötig – wenn schon Lock-in, dann aber richtig, scheint man sich in Redmond gedacht zu haben.

OpenBSDs OpenSMTPd spricht zwar kein OAuth2, doch ausgerechnet der minimale SMTP-Server Msmtp beherrscht es. Den konfiguriert systemweit die »/etc/msmtprc«; ein Beispiel zeigt Listing 6. Zeile 5 definiert einen Account-Namen, der allerdings nur in Msmtp gilt. Auf diesen Namen referenziert später in der letzten Zeile die Default-Einstellung. Der Nutzername für das Cloud-Exchange findet sich in Zeile 7, er kann von der Absenderadresse darüber abweichen.

defaults
tls on
domain mail.example.org
syslog LOG_MAIL
account o365
from user@bei-ms-gehostet.net
user user@bei-ms-gehostet.net
from_full_name "Max Muster"
host outlook.office365.com
auth xoauth2
protocol smtp
port 587
tls_starttls on
passwordeval cat /home/tobias/.fetchmail-next-token
allow_from_override off
set_from_header on
account default: o365

Weil Zeile 16 anweist, den From-Header auf die bei Exchange bekannte E-Mail-Adresse zu setzen, würde der Absendername ebenfalls überschrieben. Zeile 8 legt ihn daher neu fest. Das OAuth2-Token liest Msmtp dann recht brachial in Zeile 14 per Cat aus der schon für Fetchmail erzeugten Token-Datei aus. Damit genügt ein Token für Versand und Empfang.

Testen lässt sich das Setup ganz einfach: Das Kommando aus Listing 7 sendet eine Test-E-Mail an »user@example.com« – sinnvollerweise eine eigene Mail-Adresse, am besten eine, die mit dem MS-Setup nichts zu tun hat. Dann lässt sich der Versand einfach testen. Auf Dauer ist eine Kommandozeile zum Mailen selbstverständlich nicht komfortabel, Msmtpd lässt sich aber mit »msmtpd –port 3025 -log=syslog« auch als Daemon im Hintergrund starten.

$ (echo Subject: Test; echo; echo Test;) | msmtp -a o365 user@example.com

Integration

Jetzt nimmt Msmtpd auf Port 3025 E-Mails zum Weiterversand entgegen. Wollen Sie lediglich Outlook in der Cloud auf Ihrem System umgehen, sind Sie schon fertig und stellen den Versand-Server in Ihrem Mailclient entsprechend ein. Allerdings lässt er sich beispielsweise bequem auch in OpenSMTPd integrieren, der abhängig von der Absenderadresse unterschiedliche Regeln für die Mail-Verarbeitung beherrscht. Listing 8 zeigt einen Auszug einer entsprechenden Konfigurationsdatei.

action "relay_o365" relay host smtp://localhost:3025
match mail-from "user@bei-ms-gehostet.net" for any action "relay_o365"

Damit sollte theoretisch der heimische Mailclient nichts mehr von der Microsoft-Welt da draußen mitbekommen.

Doch einen Haken hat die Sache noch: Aus völlig unerfindlichen Gründen meint der Exchange-Server eine als »text/plain« mit dem Zeichensatz UTF-8 kodierte Nachricht umwandeln zu müssen. Er wandelt sie in eine Multipart-Message um, deren erster Teil »text/plain« und UTF-8, aber Base64-kodiert ist. Daran hängt er zusätzlich einen völlig nutzlosen HTML-Teil an.

Warum Microsoft auf diese krude Weise HTML-Nachrichten erzwingt, erschließt sich nicht. Gerade in Redmond sollte man ja eigentlich wissen, dass sich zum Beispiel Phishing mit HTML viel leichter realisieren lässt, und müsste HTML-Injections als Sicherheitslücke in E-Mails kennen. (jcb/jlu)