Allow Office 365 users to transparently open OME encrypted emails within Outlook
If a user sends an email to multiple recipients including Office 365 users (internal or external) as well as non-Office 365 users that don't support TLS transport and wants to protect that email with OME, it has to be encrypted. This would lead to the situation where all recipients would have to go through the portal process to retrieve the message including the Office 365 users.
This would be a reason that TLS encryption for Office 365 users to reasonably protect emails is not adequate and OME is inconvenient for Office 365 users. This is the reason for my inquiry about making message decryption transparent to the Office 365 users within Outlook 2016.
I understand that the login to the portal is to a different system than the login for email, but it seems to me that Outlook could be programmed to sense the receipt of an OME message and transparently to the user make a connection to the encryption server portal using the credentials used to log into the email server and display the message within Outlook. This would be the same login information that a user would use at the encryption portal anyway. I understand that Non-Office 365 users and Office 365 users using a different email client would still need to go through the portal.
Take a look at “decrypt rule” in this help topic:
Please let us know if this doesn’t meet your requirements.
Rob Traynere commented
@Admin O365 Feedback Team (Admin, Microsoft)
that's fine. but give use the option to opt out of that control. ideally allowing orgs to choose whether to opt in to "federated" domains would be ideal (like Skype).
the issue here is that competing services (Zix) do this out of the box and make using secure email fairly seamless for the end users.
Ciaran Madden commented
Absolutely agree with @Mikko. It's bizarre that mails sent from the same tenant and replies I recieve made my external users on the encryption web interface which effectively we're providing to them to communicate to us should mean we don't have to log in to it as well. The message should appear in our inboxes as normal if we choose for that to be the case.
The link in the comment dated Ocr 27, 2015 seems to be dead.
For the usage case where the mail is supposed to be delivered to an encryption-unaware application, the server-side decryption is an important requirement. This should be possible at least for mails sent from the same tenant, as well as replies by externals made in the encryption portal web interface.
Application-type recipients are usually on IMAP or the like, too - no MAPI or Outlook-specific features.
As of right now this works in the "old" OME but not OMEv2. Therefore anyone who needs this is unable to move to OMEv2. Please provide a way to enable this for compatibility.
Dan Van Soest commented
Its also a problem for many organizations as webmail is blocked.
Thank you for the feedback. It would be nice perhaps if the client could streamline the authentication (so we will leave this open).
However, the design to not decrypt mail that originates from another Office 365 tenant at the server level is intentional -- each sender controls exactly who can decrypt the message. If it was able to be decrypted at the receiving organization level, then a rogue administrator or someone else might be able to see the message contents. By forcing end user authentication, this problem is avoided and the sender controls exactly who may decrypt. The organizational decrypt rule works for conversations which that organization owns.
Mark Baker commented
This link talks about emails within the same organization and may or may not be on replies to encrypted emails. The feature request I am referring to would work at the outlook 2016 application and allow for transparent decryption and for emails from any Office 365 user, not just within your own organization. Can Outlook 2016 not identify the OME attachment and either perform the authentication transparently for the user, or at least display the encryption portal within Outlook itself for manual password input and email processing (reply, foward...)? The extra step to open and login to the OME portal is somewhat inconvenient.