As part of recreating the rules that my customer currently has set up with a popular cloud-based message hygiene platform, I needed to create an Office 365 profanity filter for Exchange Online. Believe it or not, there isn’t one built into the product (it disappeared with BPOS) but you can do some interesting things with DLP classification rules and policies.
I’d like to publish the exact steps here but I can’t, for commercial reasons. What I can do though is signpost some useful resources:
- Jedi Hammond has a useful post on Creating Custom DLP Classification Rules and Policy.
- The XML you need for the Custom DLP policy template can be found in the Microsoft TechNet advice for developing sensitive information rule packages. It’s a bit difficult to follow in places and a couple more posts that might help include this blog post from Jorge R Diaz and this forum question from John Mello.
- You’ll need to generate some GUIDs.
- Jamie Wilkinson has dug out a list of bad words that Google uses.
Once you’ve created a policy you can apply it in PowerShell with:
New-ClassificationRuleCollection –FileData ([Byte[]]$(Get-Content -path ProfanityPolicy.xml -Encoding byte -ReadCount 0))
If you need to update it then the cmdlet is Set-ClassificationRuleCollection and if you want to take it out again, Remove-ClassificationRuleCollection will do the trick.
With the classification in place, you can create rules that use the policy. In my case, one to block emails containing sensitive content (i.e. a list of pre-defined words) and send an incident report to a defined mailbox.
Even though I was working with Exchange Online (v15), the same process will work for Exchange Server 2013 and, presumably 2016 when it comes…
Finally, one gotcha I found (well, it was a user error really):
- I thought my rule wasn’t working. When I later logged into the shared mailbox that blocked messages were copied to, I found copies of the messages I’d been sending for quite a while. My confusion was because I’d been testing with Policy Tips (which seemed a bit hit and miss in OWA) and that doesn’t actually block the message (doh!). As soon as I enforced the rule, my rude messages started bouncing back as expected…
If organizations need to go beyond blocking due to high IT administration or false positives, they can add Adaptive Redaction to Office 365 or Exchange to redact out only the data that breaks policies and lets the rest of the message go unhindered.