While document creators have by definition unrestricted access to the data they add to the document, having owner rights would allow them to later extract data others have added to the documents they created. Owner rights also allow creators to downgrade classification on documents that have already been classified.
The suggestion is to have a setting on each policy that when enabled does not automatically grant the creator of a document full control rights or the ability to reclassify once the document is closed. This should enable revocation of access for content creators and would also prevent such users from removing protection.

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 ?

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!

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.

On a tenant with DKIM configured and enabled, using a domain with a configured DMARC policy, Microsoft does not DKIM sign the message.

This might seem fine to Microsoft, the message originates and terminates within their system, and to Microsoft there's no reason to enable features that allow other systems to verify the authenticity of those e-mails.

This ignores third party e-mail filters that hook in to O365 to catch phishing attempts. Phishing of internal e-mail domains would be the most difficult to catch for average users.

Another scenario not involving third party tech solutions is this that DMARC alignment with forwarded e-mails from within a Tenant is not performed. The lack of signing internal e-mails means that if those e-mails are altered and forwarded outside of the organization DMARC alignment cannot be performed to catch unauthorized alteration of a person's correspondence.

Such correspondence altering could include banking details, or their views on a topic that would benefit a rogue actor to simulate.

That could be avoided if Microsoft just indiscriminately signed messages originating in O365 regardless of where they terminate. The e-mail correspondence would be much safer.

This should at the very least be an option to enable within the DKIM configuration.