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.

The security trimming is not working with external sharing switched on. Users are only supposed to see what they have been given access to see in SharePoint Online. However, when you share content externally as read only, users are still able to see the full Site Owner menu options for the items. They can also click on them, but then when trying to submit the change, they get an error saying access denied. (The errors messages are also not consistent causing more confusion - see deleting a document versus renaming it). This is a MAJOR design flaw as external sharing is activated by default on all tenants. It is a governance nightmare as there is no way for administrators to test access of external users without now manually clicking every single menu option on every single item. Please fix this as a matter of urgency. Anonymous links stay active for the default 3 months despite changing the timeframe to whatever days you need.

When an email with OME is sent, it is delivered to the recipient as a notification with instructions to view the message on the portal. The body of that notification is changed, but the subject of the original email is preserved. Please provide the option (another parameter in Set-OMEConfiguration) to set a custom subject for that notification email while still preserving the original subject when the recipient views the email in the portal.

For example, allow an administrator to replace the notification email's subject with something like "You have a new encrypted message." Ideally, it would be great if we could have tokens so that we can have the subject be something like "You have a new encrypted message from <from email address>."

By changing the delivered subject, we are protecting the entirety of the email, not just the body. The subject could include sensitive or controlled information, so masking it in the notification email could provide further protection. I have one customer who would love to use OME but might not be able to because the original subject is preserved in that notification email.

Thank you for considering it!

Hello,

We have created a transport rule in Exchange Control Panel to apply Office 365 Message Encryption with RMS template "Encrypt" to emails having subject ending by " (crypted)".

When we send an email matching the conditions, the rule is triggered.

However, when the email is received in Outlook 2016 (ProPlus) or Outlook Online, it is not displayed directly as described on https://support.office.com/en-us/article/how-do-i-open-a-protected-message-1157a286-8ecc-4b1e-ac43-2a608fbf3098. Instead, a link to the web portal is displayed.

We raised a support request on this (#7596564).

Office 365 support told us to use the "Do Not Forward" RMS template. However this is not what we intended. We only want the email to be encrypted, nothing more.

We were told that the Encrypt RMS template should work as we expected and that this is probably a defect, hence we post in uservoice: here we are.

PS: I think it's quite unusual to submit an idea in uservoice for a defect. I feel uservoice is intended to submit ideas for changes to the product, not fixes.

The one time passcode was working few weeks ago for people outside of our organization, but it is no longer working and nothing has been changed from our end. I have been on a call with Microsoft Support and they told me that will not work with Gmail, which is not acceptable because our clients have their domain integrated with Google and they are using Gmail. It is also not working with Yahoo as well. OTP works with Hotmail because it is a Microsoft product. I know it works using a Microsoft Live account but that is not the point. Can you please find a way to fix this ?

It would be great if mail messages generated and sent via a PowerShell or Telnet SMTP sessioin could make use of Azure Info Protect instead of RMS.

For example, if I enter the command:
PS C:\Users\fakeuser> Send-MailMessage -From noreply@blah.com -To fakedude@gmail.com -Subject "Testing Encryption Again2" -Bo
dy "Test PowerShell message send which should be encrypted" -SmtpServer smtp.office365.com -Credential $msolcred -UseSs
l -Port 587

Currently, I can only get either of 2 outcomes by doing this:
1.) If I change a label to detect the use of a keyword (i.e. the word "credentials") and then apply 'Highly Confidential', AIP does not get enforced by using this SMTP command. The message completely bypasses protection and the message is not encrypted. Users do not get the 'wrapper' e-mail which requires them to go through the Protected Message Portal.

2.) I can create a rule in Exchange Online Admin to force anything from 'noreply@blah.com' to apply a protection 'template' (but not a label) which makes use of the old RMS. Once the e-mail reaches fakedude@gmail.com, they get the wrapper e-mail message, go to the Protected Message Portal, finally landing on a link that says they don't have permission to view the message. This is the way the older RMS worked, in that anyone outside of the domain could not view an RMS protected e-mail.

I raised a trouble ticket with Microsoft on this, (30126-6822280) however they have told me Exchange Online is not currently set-up to work this way.