Encrypt Only Email Option
Similar to the new Do Not Forward option, have an option that simply encrypts the email to the recipient. With the AIP templates not able to utilize 'all external recipients' and the DNF being too restrictive we still need to use a third party for email encryption. The downloading of a .html file is not feasible to implement with thousands of clients and the hand holding that is required.
Currently in private preview. Depends on an upcoming Office 2016 update for full support.
Johan Voerman commented
This currently works fine in Outlook and Outlook Web. The problem for now is that when you select the encrypt setting the attachments are also encrypted. This is not a convenient solution. For most parts you just want encryption until the recipient. When it's there the recipient must be able to do whatever they want with the mail/attachment.
Will this option come in the near future?
@Jason: this feature IS the Encrypt-Only option available via a transport rule in OME (OME itself can protect with any policy, Encrypt Only is one of the possible policies). This feature is only available through a Transport Rule at this moment, and emails so protected can only be consumed via the OME web experience, no inline within Office clients, which is why it is flagged as Preview. Upcoming Office and AIP updates will make the experience more integrated within Office, at which point we will tag this feature as released instead of preview.
I actually don't fully understand what the difference is between this request and using the existing OMEv2 via a transport rule, Outlook Desktop (Options > Permissions), or the protect button in OWA.
Is it that the Encrypt Only option provided by AIP could be used to "encrypt" a document instead of just an email? If so I get that, but if the request is to "simply encrypt emails to external recipients" isn't that what OMEv2 does and why exactly do we need that to be a capability in AIP?
I'm not saying I don't want it, I just don't understand what "IT" is.
@morebaconpls: no, it does not mean we are not addressing the original request, quite the contrary, it means we are addressing the original request, but in order for some aspects of the feature to be released in its full capacity an update for Office is needed.
To be clear, OME is already available, and it meets most of the criteria you describe in your question:
There's no "attached .HTML". OME v2 doesn't work that way anymore. In OME the protected message is wrapped in a way that native clients will render directly, while other clients will view an email which contains instructions on how to open the protected message through a web portal (usually in one click).
Also, in OME, there's no need to register any account. If the account is already an existing Office 365 or Microsoft Online Services (i.e. Azure AD) account, or a Microsoft Account, the message will just open and render. If it is not, the user can access the content via a One Time Passcode or a federated identity such as Gmail. See https://aka.ms/enableome for more information.
This should work for all customers, even government customers.
In addition to that there are two features that fall under this specific request in UserVoice (the first one included in the OP, the second one implied in some of the questions):
1) Encrypt only, that is, similar to DNF but will all rights granted to the recipients. This is already built, deployed and working, but for users to be able to consume such content from Office an update to Office is required (content protected with this policy can only be consumed in the web UI at this point). You can test this feature today from OWA: select PROTECT and then CHANGE POLICY, from there you will se an option called ENCRYPT, which does exactly as requested. But broader deployment of the feature is dependent on the aforementioned Office update as we don't want to release a feature that only works for OWA clients (OME is not only used for B2C scenarios, it is also used in B2B where support within Office is critical for a fluid user experience).
2) Connected to this request is a separate feature for not encrypting attachments when the email is encrypted. This is a separate feature (not mentioned in the original UserVoice ask). This feature is also already build, awaiting for the same update to be released.
The aforementioned features just add flexibility to the already existing OME experience.
Original post Oct 9, 2017, ENCRYPT ONLY EMAIL, NO .HTML DOWNLOAD, NO AIP ON ATTACHED FILES. THE ORIGINAL OME had 2 out of these 3. Can you please just address the no .html download using the original ome. THIS WAY YOU CAN CONTINUE WITH THE ROADMAP YOU HAVE FOR NEW OME WITH AIP and we can all get back to work. This is causing serious work stoppage at the federal, state, tribal and local law enforcement levels.
Depending on an upcoming office 2016 update means you are not addressing the original request...? The original request asked for "Encrypt only email option" just like original OME without an attached .html to download for a one time passcode. NO AIP on attached documents. Please, we need to keep it simple in some scenarios where external recipients are not running office365. I email thousands of email@example.com, yet when I went to the AIP INDIVIDUAL PORTAL AND ENTERED A VALID EMAIL@USDOJ.GOV, i got the message "SORRY" not able to register this work email. Folks, GOVERNMENT grinds like salt, and they won't be moving to o365 anytime soon. We need microsoft to allow "encrypt only email option" so when personal informaiton or criminal justice information is being emailed it is encrypted in transport but easy for the recipient to open, download, print, forward. HELP, the US GOVERNMENT IS ASKING WHAT YOU CAN DO FOR YOUR COUNTRY. RESPECTFULLY
Andrew Burger commented
Will all external recipients be added to label protection? I would want to create a label with multiple protections encrypted, do not forward and can't print for certain label
Do Not Forward and Encrypt Only are different in the rights they grant. In fact, they are polar opposites in that regard. While both grant rights to the same users (the recipients in the email), DNF grants very limited, basically View-only rights, while Encrypt Only grants all rights, including the right to forward and to add other users to the rights list. The use cases are generally also opposite: generally speaking, if you are sharing *your* information with someone, use DNF. If you are sharing with someone *their* data, Encrypt Only makes more sense as they will be able to use it any way they want.
Hope this makes more sense now.
Brian Johnson commented
Am I missing something, or is this not exactly what the Do Not Forward option does. You are removing the content from the email and sending them a link where they have to authorize reading the content?
Like some others in this thread I have been ******* my head against the wall for 2 days trying to figure out what was wrong with my implementation and sending "Confidential" or "Highly Confidential" emails to external users. I even created a new label in Azure Information Protection but I can't figure out how to turn that into a template that will publish down to the "Permissions" drop down on the Options in Outlook.
After coming here I read about Do Not Forward and it seems this does what I want. Am I missing something. Also if anybody knows how to convert labels into Templates or can link me I would appreciate that too.
Samuel Beck commented
Please, Please, Please do this ASAP
J B commented
Interested in seeing this asap.
any eta on this please? this is a very important feature for many organizations to have.
I felt like a crazy person trying to figure out how to send encrypted messages to any e-mail address. I feel better knowing that it wasn't possible with AIP yet. I am anxious to have the ability as I don't necessarily want to revert to OME.
This is ridiculous that you don't have this option already.
This has a very recent (2 days) response but I am wondering if there is any rough ETA?
As a financial institution we need this capability and if the release timeline is longer than a month we need to start looking at a 3rd party solution.
Thank you for any guidance you can give on this.
Any eta on this ?
Geert Vandenbranden commented
This will allow ‘more secure’ sharing of information via e-mail. Although from an information management perspective one prefers links to be shared (single source of truth principle), as old habbits are hard to change, this allows organizations to protect information during the transition period (towards the new way of working) while preserving the user experience.
great news. Any eta when it is targeted to be available?