Nov 02 2017
10:09 PM
- last edited on
May 24 2021
03:11 PM
by
TechCommunityAP
Nov 02 2017
10:09 PM
- last edited on
May 24 2021
03:11 PM
by
TechCommunityAP
Is there a way to prevent RMS/IRM protected emails from being sent externally?
We unsuccessfully tried using an Exchange Transport rule to block emails sent externally when the MessageType = Encrypted (the emails still are sent out).
The goal is to use RMS/IRM for internal emails only, but the business wants to insure that users do not attempt to send emails protected by RMS/IRM externally.
Thanks!
Nov 03 2017 01:34 AM
Funny, customers usually care about the opposite scenario 🙂
I believe the "encrypted" option for message type refers to S/MIME, for RMS/AIP protected messages try creating a rule that looks the following header - Content-Class: rpmsg.message
Or the "msip_labels" header, but that's only added when manually labeling the email I suppose.
Nov 03 2017 09:08 AM
It does not seem to be blocking it. Does this rule look right to you? If so, shouldn't the rule take effect in ~15 minutes? It has been 45 minutes.
Nov 03 2017 11:36 AM
You probably have to "sanitize" it, as the . symbol has special meaning when using regex ("matches"). Or just try the "header includes words" condition.
Nov 03 2017 01:38 PM
Tried using 'header includes words' to avoid the regex and it still is not blocking the emails.
I verified that on the receiving end, there is a message header called Content-Class that contains the value rpmsg.message so not sure why the rule is not working.
Nov 03 2017 02:43 PM
Nov 04 2017 09:47 AM
Well I'm out of ideas. I'll try to reproduce this when I get some free time and let you know the result, please do the same if you manage to resolve it or open a case 🙂
Nov 06 2017 07:59 AM
I was able to reproduce this inability to block outbound RMS messages in a separate tenant. Seems like content-class: rpmsg.message is being ignored in the message header evaluation. I'm waiting to hear back from MSFT Support.
Nov 07 2017 08:44 AM
Nov 07 2017 10:12 AM
Well according to the documentation (https://technet.microsoft.com/en-us/library/jj919238(v=exchg.150).aspx), Transport rules should be able to inspect all headers of RMS-encrypted messages. However, I'm having the same result as you - no matter what variation of the 'Content-Class' header I try, I get no hits on the rule.
Nov 09 2017 12:56 AM
Just curious, did you manage to get this solved?
Nov 09 2017 06:59 AM
Dec 01 2017 10:39 AM - edited Dec 01 2017 10:40 AM
SolutionCircling back on this - we worked with MSFT Support and they confirmed it no longer works using rpmsg.message.
They work-around they provided, which we confirmed works, is checking for a message type that is "Permission Controlled"
Jan 08 2018 12:33 PM - edited Jan 08 2018 12:34 PM
Hey - the response you get back; "no no no no". Is it all correct? When I try and do an RMS-labeled message to <me>@gmail.com, the response has what I've entered ("no no no no"), though it also says "Security or policy settings at gmail.com have rejected your message". Obviously, any domain I send to responds that policies at that domain have rejected the message. Thing is, this is completely incorrect - it's policies at MY domain gateway that have rejected the message. This is causing considerable confusion for users.
What's your experience? if you've fixed it, how?
D
Jan 08 2018 03:36 PM
Jan 08 2018 03:42 PM
Thanks Joe. I did log it as an issue with Microsoft Support 2-3 months ago; they were going to pass it to the relevent Dev team, I haven't heard anything since. Hence interest in how others are dealing with it.
Dec 01 2017 10:39 AM - edited Dec 01 2017 10:40 AM
SolutionCircling back on this - we worked with MSFT Support and they confirmed it no longer works using rpmsg.message.
They work-around they provided, which we confirmed works, is checking for a message type that is "Permission Controlled"