A security update for Microsoft Office in Outlook 2013 prevents users from responding by e-mail to all recipients and the sender. In issue KB3172519 , Microsoft describes that from now on, the e-mail address of the user is taken into account when you use the “Reply to all”-function. So this e-mail is also adding yourself to the recipient list, when you reply to all. The implementation of the feature seems carelessly implemented and blocks other MAPI providers like the Zarafaclient. Finally, a security update should be expected to ship a new feature in it. It is probably not possible to solve this function restriction within the Zarafaclient. This blog post explains the background and names workarounds.
Technically, we criticize this solution as most awkwardly implemented. Why most likely? We can only look at external effects and interpret them from our experience. Outlook is closed source. By the way: We are not the only ones affected by this. Others discuss the case in Microsoft Technet .
It is jarring that this new feature is delivered within a security patch. The patch  fixes two CVEs, 4 more security-related things, and adds this feature. It is not possible to install only the security-relevant patches from this security patch. This means that affected users will only be able to uninstall the patch together with the security patches.
Outlook profiles that are purely managed by Microsoft services are not affected. This means that ActiveSync profiles – which store data in OST-files – keep on working even if they are connected to Z-Push/KOE (Kopano Outlook Extension).
Others, including large customers, have now decided directly to move towards Kopano DeskApp because of this move by Microsoft.
A third option is, of course, to uninstall the patch. Technically, this is possible in MSI installations by uninstalling the KB3172519 update. Click-to-run installations can only be reset to version 15.0.4911.1002 . Since this patch also fixes two CVEs, this option is not a solution or a recommendation.
A great advantage of MAPI is, that relationships between all possible objects can be established. For example, there is the relationship between an e-mail and the recipients as well as the sender of an e-mail, as well as contact folders or the Global Address Book (GAB). These relationships are useful for example, when Outlook lists all e-mails, appointments, and tasks associated with a contact.
A (valid) MAPI object like an e-mail consists of lots of MAPI attributes. Each individual attribute allows among other things, the relationships mentioned above, static information or even a hierarchy of attributes.
Each program – including Microsoft Outlook – works with active and persistent objects, whereby the active objects being accessible in the program itself only. Now, Outlook is a closed source product. This means that a third party, such as the Zarafaclient, has no influence on the active objects and their creation at all. Zarafa could only store and process the objects created by Outlook.
It is very important to understand that MAPI objects are also temporarily stored by Outlook, in order to modify them during further processing. This, of course, continues to be a MAPI object. Functions in Zarafa, such as SaveObject(), then take care of the persistent storage of the object. Only when an object has been stored in some way or another it can be used for any reference by Zarafa.
What exactly happens now?
With this understanding of MAPI, we now come to the real problem: We cannot actively use MAPI objects that are currently being processed and have not yet been saved. A MAPI provider must always wait for these to be stored.
Microsoft has added a feature that adds the writer of an e-mail himself to the list of recipients when he calls the “reply-to-all” function. As simple and meaningful as this sounds: the at least “unsightly” implementation of this function leads to great annoyance for anyone who depends on interfaces, like the Zarafaclient does.
As far as we can see from the outside, this feature modifies the default procedures. A reference to another MAPI object is to be created to resolve an object for “linking” to a recipient (e.g., from the Global Address Book or even a contacts folder), which is not possible because the object has not yet been saved. So, basic actions take place within Outlook, before the Zarafa MAPI provider can intervene.
When the “Send”-function is called by the user, exactly this leads to a pre-defined reference which links to an empty point is delivered to the Zarafaclient. This reference then results in a “MAPI_E: Object not found” error.