SOLVED

Block outbound RMS Encrypted Emails with Exchange Transport Rule?

Bronze Contributor

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!

15 Replies

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.

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.content-class.jpg

You probably have to "sanitize" it, as the . symbol has special meaning when using regex ("matches"). Or just try the "header includes words" condition.

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.

 

image.jpg

If there are no other suggestions, I will open a support case since this is not working after several hours.

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 🙂

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.

The first level of Microsoft Support has looked at it and they didn't offer any suggestions or help as to why this is not working. I asked that they escalate it and waiting to hear back. In the mean time I have created as many variations as possible to try to block outbound RMS... Can you spot any problems with these rules?

Identity : Block outbound RMS header contains ''rpmsg.message''
Description : If the message:
Is sent to 'Outside the organization'
and Is received from 'joe@contoso.com'
and 'Content-Class' header contains ''rpmsg.message''
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header contains ''rpmsg.message'''
with the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS header matches "rpmsg.message"
Description : If the message:
Is sent to 'Outside the organization'
and Is received from 'joe@contoso.com'
and 'Content-Class' header matches the following patterns: 'rpmsg\.message'
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header matches "rpmsg.message"' with
the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS header includes Content Description
Description : If the message:
Is sent to 'Outside the organization'
and Is received from 'joe@contoso.com'
and 'Content-Description' header contains ''message.rpmsg''
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header includes Content Description'
with the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS header includes Content-Type
Description : If the message:
Is sent to 'Outside the organization'
and Is received from 'joe@contoso.com'
and 'Content-Type' header contains ''application/x-microsoft-rpmsg-message''
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header includes Content-Type' with
the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS header includes Content Description Rule 2
Description : If the message:
'Content-Description' header contains ''rpmsg' or 'message.rpmsg''
and sender's address domain portion belongs to any of these domains: 'contoso.com'
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header includes Content Description
Rule 2' with the status code: '5.7.1'


Identity : Block outbound RMS header includes Content-Type Rule 2
Description : If the message:
Is sent to 'Outside the organization'
and 'Content-Type' header contains ''rpmsg''
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header includes Content-Type Rule 2'
with the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS header includes Content-Disposition
Description : If the message:
Is sent to 'Outside the organization'
and Is received from 'joe@contoso.com'
and 'Content-Disposition' header contains ''attachment; filename="message.rpmsg"''
Take the following actions:
reject the message and include the explanation 'Block outbound RMS header includes Content-Disposition'
with the status code: '5.7.1'
and Stop processing more rules


Identity : Block outbound RMS messages based on attachment name
Description : If the message:
Is sent to 'Outside the organization'
and has an attachment file name that matches these text patterns: 'message.rpmsg'
Take the following actions:
reject the message and include the explanation 'Block outbound RMS messages based on attachment name'
with the status code: '5.7.1'
and Stop processing more rules


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.

Just curious, did you manage to get this solved?

not yet - we have requested for the support case to be escalated (5+ days with no resolution).
best response confirmed by Joe Stocker (Bronze Contributor)
Solution

Circling 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"

 clip_image002.jpg

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

unfortunately it is what it is - you could send an email to your users informing them that RMS emails sent outbound are not permitted via policy, and include a screen shot informing your users that they may get a message like this if they attempt it. For those users who stumble on it later, theoretically they will only get this type of message once and then when they learn it is not allowed, they shouldn't keep getting this... sorry there doesn't seem to be a better answer.

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.

1 best response

Accepted Solutions
best response confirmed by Joe Stocker (Bronze Contributor)
Solution

Circling 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"

 clip_image002.jpg

View solution in original post