Require TLS Fallback Automatically to OME
When sending e-mails out with sensitive content, we can currently use a Transport Rule to detect said content (Sensitive Info Types) and take an action. Would like to be able to create a transport rule that first does "Require TLS." However, if TLS is not supported by the receiving server, have Office 365 automatically fail back over to OME and send out the e-mail securely that way. With Require TLS, if the receiving server doesn't support TLS, the user has to wait to find out that their e-mail did not go through. They also have to resend the e-mail manually. Having this automated would make securing sensitive information a much more palatable experience.
* Sensitive Information Found in e-mail
* Transport Rule Require TLS activated
* If receiving server supports TLS, e-mail sent, all is well.
* If receiving server does not support TLS, e-mail is sent using OME, all is still well.
We plan on implementing this functionality, although we do not have any timelines to share at this stage.
This would be super useful. Right now we maintain lists of domains for TLS that we've verified support it and thats really annoying.
One way you might implement this is instead of a rule that enforces tls and fails back to OME, create a version of or option for OME that doesnt do message encryption if transport encryption succeeds. You could still leave an option for full message encryption for people who actually want that, but for most of us here we're just trying to ensure the message is encrypted in transport. After it gets to the destination mail system encrypted its up to them to protect it.
I feel this is pretty much a must, for anyone handling sensitive data.
I agree with Blake. This is a much needed enhancement. It seems that OMEv2 is not as functional as other solutions we've used as there are many nuances with mail client configuration that can cause encryption to fail. This has been a major issue for my company and having the TLS with OME fallback is much needed.
Ryan Blake commented
Sean or other Microsoft Employee,
Any update on a timeline for releasing this? It would be very helpful to have! This along with improved reporting and OCR would really bring O365 up to par with the other big players.
Ryan, thanks for the suggestion, and I have voted on your recommendation. Yes, the manual solution with the headers is possible (in fact we're doing something similar with a third-party DLP rule pack) but it is a bit unwieldy and fragile if you're not the person who built it, so I would worry about its scalability and reliability over time. A simpler logic switch as in your recommendation would be a great solution.
Ryan Blake commented
This can be done right now. You create transport rules that do the following:
Create the first transport rule in Exchange Online Admin and call it something like ForceTLS. Then hit the More Options selection, select if message sent from inside the organization and then add another if rule to select if message sent to outside the organization. Then add another if statement that says sent to these domains. Then enter all your partner domains in the list. For action, select the Force TLS option and also add a second option to add a special message header for bypassing DLP (maybe do X-AlreadySecure and for data set to 1). Be sure to audit the transport rule, enable it, and move it to the top of the priority list. For any other transport rule that has DLP policies, be sure to add Except If and put in the header and data value you entered earlier. If you use DLP Policies within the Security and Compliance Center, be sure to edit these polices with Except If and then put in the header value you entered earlier. Now it will ONLY use TLS for those domains you know support TLS. It's manual, but it will work as you expect.
I respectfully ask that you please support this idea I submitted: https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/38213971-require-tls-fallback-automatically-to-ome
This automates the process and doesn't require keeping track of domains.
Should you have any further questions, please don't hesitate to reach out or reply.
David Jones commented
We use Proofpoint currently and this is how they handle sensitive email.
Not having a TLS first for sensitive emails is the one and only reason keeping us with them and not going all in for office 365 email security.
Barry Levites commented
YOU CAN DO THIS MICROSOFT. I BELIEVE IN YOU!
Definitely need this feature....If TLS fails when sending/receiving with external users, then automatically apply OME (Office 365 Message Encryption). Currently the thing close to this is using Mail Flow Rules to 'Require TLS' and if it fails then the message fails outright.
The desired function would be to add to this rule so if 'Require TLS' fails, then 'Apply O365 Message Encryption and rights protection to the message...' then select RMS Template 'Encrypt'. Please add this feature MSFT.
We would like to use TLS for all partner domains that we know support TLS. For everyone else, when there is an email with sensitive information, we would like to fall back to OME. This way, all emails that need encryption are protected but effort is reduced on the recipient's end. How this should work is, we specify partner domains in Office 365 that we know support TLS. If an email is sent to one of these domains, it should send using TLS immediately. If they are not in the domain list, the email is scanned for sensitive information or encryption trigger words. If these are found, OME should be used. All other email still sends using opportunistic TLS. This is currently not possible in Exchange Online with the existing rules.
Trac Tran commented
Please create a feature in Office 365 for the option that when the destination server does not support TLS encryption, it will automatic retry using passcode encryption method, instead of bounce back the email 2 days later.
Kurt Koenigsknecht commented
Use Case: Outbound email shall transmit securely with TLS as the preference method of delivery, if TLS is unavailable then automatically send as a secure envelope.
Goal is to securely deliver the email with as much transparency to the recipient as possible. TLS first and then if that fails, secure envelope.
Provide this capability by allowing the use of "key words" in the email subject to flag the system to transmit in this way.
Email is transmitted securely and the recipient does not have to manage passwords or act on a one-time password.