Outlook Desktop | Refinement of the QR code attaching procedure

Hello everybody.

I come with this information after two days of playing around with Outlook Desktop. Ticket.

Key points

  • Calculation of the MIME signature
  • QR code (seal) image attaching procedure

What

Research another approaches to attach QR code for Desktop version of Microsoft Outlook
Screenshot 2021-02-08 at 12.41.18

Why

A current approach is not suitable because it amends MIME structure on sender side (after MIME signature being calculated) and corrupts it in certain circumstances.

I would like to review pros and cons of the current approach and suggest two alternatives.

1. Current approach

Uses Office.Body.setAsync method of the Add-in API.

Pros

  • Works with email composer and does not require interaction with the server.
  • Works robust with Outlook Web (outlook.com)

Cons

2. Attaching QR code using EWS update operation

It’s stability and robustness pending research.

Cons

  • It’s a remote request which in some cases requires going through our infrastructure. (Via so called EWS proxy)
  • @sasha.ilieva mentioned that it does not work in combination with onSend feature

3. Attaching QR code using Microsoft Graph API.

This approach allows directly amend draft.

Pros and cons pending research.

Having in mind stated above, I vote for research of the third option. My initial estimation of research, implementation and QA is two weeks.

@sasha.ilieva @zdravko @georg.greve please review

Thank you for the thorough research and explanation, @markin.io, good work! :100:

Some follow-up questions:

  • Are you proposing to use two methods for sending, depending on the client? In other words: Will Outlook on the Web stay with Option 1 and only Outlook on the Desktop will switch to Option 3 then? Or would both switch to Option 3?
  • If the latter, what would be the implication for validity of messages sent in the next weeks?

To me, Option 2 isn’t actually an option.

EWS is an old protocol, and is in the process of being phased out. Exact timeline to be determined, but it does not seem wise to invest time now into a solution based on EWS if we know that Microsoft is slowly choking the life out of it.

The future of Microsoft API is Microsoft Graph, so your Option 3.

My main concern with Option 3 is what happens to On Premise deployments of Microsoft Exchange, since many of our customers will be with those for some time to come? I could not find a definitive answer, but Stack Exchange pointed me toward Use REST APIs to access mailboxes in Exchange hybrid deployments (preview) - Microsoft Graph | Microsoft Docs which indicates that this would be considered a so-called “Hybrid Deployment” and might work with Graph.

TL;DR:

  • We need to understand how Option 1 & 3 interact / co-exist or how Option 3 might replace Option 1 for Outlook on the Web
  • We need to understand how Option 3 works with On Premise legacy Exchange servers of version 2016 and above, or whether we need to invest into Option 2 for those, which would truly be the worst of all worlds, in a way.

Regardless, I don’t think there is an actual choice for us to make regarding research.

For all our products we depend on a robust and well-working integration with Outlook on the desktop for years to come. In fact it is likely the most important client of them all.

So I would vote to:

  • Release Outlook on the Web early & often and ongoing while we finish the desktop side;
  • Do our research with priority, and once we know answers to the questions above, implement right away.

Are you proposing to use two methods for sending, depending on the client? In other words: Will Outlook on the Web stay with Option 1 and only Outlook on the Desktop will switch to Option 3 then? Or would both switch to Option 3?

I propose to leave Outlook Web Version with Option 1 unless something indicates that it cannot be used together with Option 3.

1 Like

Excellent. That means we can keep this as is and work forward from there. I like it.