Ein Security-Update für Microsoft Office verhindert in Outlook 2013 die Möglichkeit, per E-Mail allen Empfängern und dem Absender zu antworten. Im Issue KB3172519 [1] beschreibt Microsoft, dass ab sofort die eigene E-Mail-Adresse beim Aufruf von „Allen antworten“ mit beachtet wird, man diese E-Mail also auch sich selbst schreibt. Die Implementation des Features ist ungeschickt und sperrt andere MAPI-Provider wie den Zarafaclient aus. Zudem hat ein Feature in einem Security-Update nichts zu suchen. Es ist vermutlich nicht möglich, diese Funktionseinschränkung im Zarafaclient zu lösen. Dieser Blog-Beitrag, an dem ich mit meinem Kollegen Mike gearbeitet habe, erklärt die Hintergründe und benennt Workarounds. Das englische Original kann im Kopano Blog gelesen werden.

Ein großer Vorteil von MAPI ist, dass Beziehungen zwischen allen möglichen Objekten hergestellt werden können. So gibt es zum Beispiel die Beziehung zwischen einer E-Mail und den Empfängern wie auch dem Absender einer E-Mail, sowie Kontaktordnern oder dem Globalen Adressbuch (GAB). Diese Beziehungen sind zum Beispiel sinnvoll, wenn Outlook alle E-Mails, Termine und Aufgaben die mit einem Kontakt in Verbindung stehen, auflistet.

MAPI Hintergründe

Ein (valides) MAPI Objekt wie eine E-Mail besteht aus einer Fülle von MAPI-Attributen. Die Bandbreite diverser MAPI-Attribute ist vielfältig. Jedes einzelne Attribut ermöglicht unter anderem eben oben genannte Beziehungen, statische Informationen oder eben gar eine Hierarchie von Attributen.

Ein jedes Programm – so auch Microsoft Outlook – arbeitet mit aktiven und persistenten Objekten, wobei die aktiven Objekte rein im Programm selbst bearbeitet werden. Nun ist Outlook ein Closed Source Produkt. Das bedeutet, dass ein Dritter, wie zum Beispiel der Zarafaclient, keinerlei Einfluss auf die aktiven Objekte und deren Erstellung hat. Zarafa konnte immer nur die von Outlook erstellten Objekte speichern und weiter verarbeiten.

Nun ist es sehr wichtig zu verstehen, dass MAPI-Objekte auch von Outlook immer wieder zwischengespeichert werden, um diese im Verlauf der weiteren Bearbeitung zu modifizieren. Dies geschieht selbstverständlich auch weiterhin als MAPI-Objekt. Funktionen in Zarafa, wie etwa SaveObject(), kümmern sich dann um die persistente Speicherung des Objektes. Erst dann, wenn ein Objekt in irgendeiner Art und Weise auch wirklich gespeichert wurde, lässt sich auf dieses oder von diesem auch referenzieren.

Was passiert nun genau?

Mit diesem Verständnis von MAPI kommen wir nun zum eigentlichen Problem: Wir können aktiv in Bearbeitung befindliche und noch nicht gespeicherte MAPI-Objekte in keiner Weise nutzen. Ein MAPI-Provider muss immer warten, bis diese gespeichert werden.

Microsoft hat ein Feature hinzugefügt, welches den Schreiber einer E-Mail selbst zur Liste der Empfänger hinzufügt, wenn dieser die „An alle Antworten“-Funktion aufruft. So einfach und sinnvoll das klingt: Die zumindest „unschöne“ Implementation der Funktion führt zu großem Ärger für jeden, der von Schnittstellen abhängt.

Soweit wie wir es „von außen“ sehen können, ändert dieses Feature die Standardprozeduren. Es soll eine Referenz auf ein anderes MAPI-Objekt erstellt werden, um ein Objekt zur „Verlinkung“ mit einem Empfänger (z.B. aus dem Globalen Adressbuch oder auch eines Kontakteverzeichnisses) aufzulösen. Dies geht aber nicht, weil das Objekt noch nicht gespeichert wurde. Hier finden also grundlegende Aktionen statt, bevor der Zarafa MAPI-Provider eingreifen kann.

Dies hat zur Folge, das uns beim Aufruf der „Senden“-Funktion eine bereits vorbelegte Referenz an eine aus unserer Sicht leere Stelle erreicht. Diese Referenz führt dann zu einem „MAPI_E: Object not found“-Error.

Unsere Kritik

Rein technisch kritisieren wir diese Lösung als vermutlich ungeschickt. Warum vermutlich? Wir können nur von außen auf auftretende Effekte schauen und aus unserer Erfahrung deuten. Outlook ist ja Closed Source. Wir sind auch nicht die Einzigen, die hiervon betroffen sind. Andere diskutieren den Fall im Microsoft Technet [2].

Wirklich nicht korrekt ist es, dass dieses neue Feature in einem Security-Patch eingebaut ist. Der Patch [1] behebt zwei CVEs, 4 weitere sicherheitsrelevante Dinge und fügt dieses Feature hinzu. Es ist nicht möglich, nur die Security-relevanten Patches aus diesem Security-Patch zu installieren. Somit bleibt betroffenen Anwendern nur die Möglichkeit, den Patch mitsamt der Security-Patches zu deinstallieren.

Lösungen

Outlook-Profile, die rein nach Microsoft-Manier speichern, sind nicht betroffen. Somit kann mit ActiveSync-Profilen, deren Daten ja – auch wenn sie mit Z-Push verbunden sind – von Outlook-eigenen Mechanismen in OST-Dateien abgelegt werden, auch nach dem Einspielen dieses Patches gearbeitet werden.

Andere, auch große Kunden, haben sich nun aufgrund dieses Schachzugs von Microsoft direkt dafür entschieden, die Kopano DeskApp auszurollen.

Eine dritte Option ist natürlich, den Patch zu deinstallieren. Technisch ist das in MSI-Installationen möglich, indem das Update KB3172519 deinstalliert wird. Click-to-Run-Installationen können nur auf die Version 15.0.4911.1002 zurückgesetzt werden [3]. Da dieser Patch auch zwei CVEs behebt, kann man bei dieser Option aber weder von einer Lösung noch von einer Empfehlung sprechen.

[1] https://support.microsoft.com/en-us/help/3172519/description-of-the-security-update-for-outlook-2013-april-11-2017
[2] https://social.technet.microsoft.com/Forums/office/en-US/a9beb468-3fdf-40f9-bf8e-3bba75d77cf7/cannot-reply-all-outlook-2013-2016-after-update-kb3172519
[3] https://support.microsoft.com/en-us/help/2770432/how-to-revert-to-an-earlier-version-of-office-2013-or-office-2016-click-to-run