Outlook Desktop | Refinement of the QR code attaching procedure

features
1

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

2

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.
3

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
4

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

5

During the last couple of weeks I’ve been reading lots of documentation related to MS Graph API, so I’ve researched and practically tested not only attachment of the seal but using Graph instead of EWS and Outlook Rest API (which will be fully decommissioned in November 2022) throughout the entire add-in.

So I’ll try to summarize my findings and conclusions here:

1. Authentication and authorization

To call the MS Graph the add-in must acquire an access token from the Microsoft identity platform and be authorized by the user to access their Microsoft Graph data. Microsoft recommends using some of their authentication libraries, depending on the app type, to do this.

I think the best way to authenticate is using SSO, but for sure there needs to be a fallback for the cases when SSO is not enabled. For those cases MSAL works great for web because it caches the token which then can be obtained silently, not bothering the user at all, but for desktop there’s an issue with initially signing in the user with the login popup:
image

So the only way I found to authenticate a user is through the Office dialog UI, which would have to ask the user to authenticate every time he opens the add-in.

Authorization occurs only once when the user installs and uses the add-in for the first time via a dialog which asks for their consent.

I tried using the msal-browser and msal-react (although it’s still in preview). They are based on MSAL v2.0 that implements the Auth Code flow which is a significant improvement compared to v1.0 (microsoft-authentication-library-for-js/lib/msal-browser at dev · AzureAD/microsoft-authentication-library-for-js · GitHub).

Conclusion:
We can implement SSO (I’ll open a separate ticket for this), but there needs to be a fallback, which as explained above may be different for web and desktop for the sake of the better UX which can be achieved with MSAL on web.

I’ll reference here some samples which helped me with the auth implementation:
React sample
Desktop client sample

2. Usage

  • Getting the MIME of a message using MS Graph works well for both signing and verification on web and desktop. The add-in verifies emails sent before that change, too.

  • Attachment and appending of the seal to the message works for both web and desktop using the sendMail endpoint which requires the Mail.Send scope in the Microsoft Identity Platform. Implementing this endpoint would require small UX changes since the request body should contain the whole message object (Send mail - Microsoft Graph v1.0 | Microsoft Docs)

  • We can use the Graph API to entirely replace usage of EWS

Conslusion:
Graph API will work for both web and desktop, with backward compatibility.

3. On-premise support

All I found on this matter is Graph API supports on-premise deployments of Exchange, but this feature is still in preview, which means until it goes into the so-called GA status, it’s not guaranteed to be absolutely stable.

4. Cons

The onSend version won’t work with Graph API, because of the usage of the sendMail endpoint. This would mean extracting a separate project using onSend, which would not work on desktop client.

2 Likes
6

Thank you for a thorough research and lots of valuable details. Great job!
Last Friday I was really impressed by the improvement of the speed of sending email.

Looks like we’re getting really close to have our solution working on Desktop, and I believe we have a decent chance to have it ready for QA in the next milestone.

I shall prepare an update of the mime parser and seal lib in order to be able to extract replied/forwarded parts of emails sent by Outlook Desktop.

Also, if you manage to finalize implementation of the email sending this week, I will be able to spend the next one covering test cases for MIME normalizer.

Let me ask a couple of questions.

but for sure there needs to be a fallback for the cases when SSO is not enabled.

Is it enabled by default? In which circumstances it might be disabled?

…but for desktop there’s an issue with initially signing in the user with the login popup:

I’ve found a couple of threads explaining similar issue:

The problem seems to be related to the inability of Desktop client to open popups, which seems fair.

This piece of documentation says that in such cases app has to utilize redirect method of the MSAL authentication. Can we try this option for the Desktop app?

…sendMail… Implementing this endpoint would require small UX changes since the request body should contain the whole message object

Can you please elaborate? I’m not sure I understand how this might affect the UX.

The onSend version won’t work with Graph API, because of the usage of the sendMail endpoint.

You’ve mentioned that there’s a method which can be used to update email body only, but there’s some issue with synchronisation, and in the end seal is not being added to the email.

I suggest to go with the sendMail functionality in order to push Outlook Desktop to the users quicker and create a ticket to research a problem with the body update Graph API method with all details and initial MR provided. So that we know where to start.

So, to summarize, here’s what I suggest:

  • Go with SSO as the main method of authentication
  • As a fallback for Web, implement popup MSAL authentication
  • As a fallback for Desktop, implement redirect MSAL authentication
  • Finish implementation of the sendMail endpoint and utilize it for both Web and Desktop.
  • Produce test cases for MIME normalizer (I think that coverage of Windows-Windows and MacOS-MacOS should be enough for now)
  • Create a ticket and initial MR with the research of the functionality that updates only email body, and will allow us to use onSend functionality.
  • Clean up backend which exposes proxyEWS API endpoint
  • Create a ticket to track progress of the Exchange hybrid deployments and leave it for further implementation
1 Like
7

As mentioned here, the add-in should not rely on SSO in certain error situations, such as when the user switches to a client that does not support it, or if the user’s mailbox is on an on-premises Exchange server. I think it’s not enabled by default, for example our tenant does not have SSO enabled currently.

If the user tries to seal and send the message without recipients, sendMail will throw an error which should be handled properly in the UI. Not sure how this case is handled currently, so it actually might be an improvement of the UX.

I agree this needs more thorough research before taking a decision how to proceed with onSend.

I just tested it using msal-react and it worked for desktop, which gives much better UX, I think. I’ll do more tests and hopefully this would be the method to use for authentication on desktop, which would be a much cleaner way.

2 Likes