I noticed an Office 365 user voice request looking for journal decryption for Office 365 Message Encryption (OME). The text of the request wants the Rights Management configuration for tenants to support an equivalent setting to JournalReportDecryptionEnabled to enable OME decryption. Although the original request dates from February 2017, some recent responses say that this is a blocking factor stopping deployments. In fact, the requested functionality exists in Office 365 today. Let me explain how things work when Exchange Online processes journal reports for protected messages.
The Rights Management configuration (IRM configuration) dictates how Exchange Online works with protected messages. The configuration is managed with the Set-IRMConfiguration PowerShell cmdlet, part of the Exchange Online cmdlet set. Messages can be protected with the two OME standard templates (Encrypt-Only and Do Not Forward) or by using an Office 365 sensitivity label.
By default, the JournalReportDecryptionEnabled setting is $True, meaning that when Exchange Online processes a protected message against a journal rule, it uses its IRM super-user permission to decrypt the content and attaches a decrypted copy of the message to the journal report. This is the same super-user permission used by the transport service to allow it to apply mail flow rules for protected messages and to decrypt protected messages when Exchange Online exports messages found in an Office 365 content search.
After processing, the journal report sent to the journaling mailbox has two attachments: one is the original (encrypted) message, the second is the decrypted copy.
The documentation for journal report decryption dates back to Exchange 2013, but is still helpful. However, because the documentation has not been updated for Exchange Online, it’s easy to see how readers could assume that newer message encryption features like OME and Office 365 sensitivity labels are unsupported for journal decryption. In fact, both OME and Office 365 sensitivity labels use the same rights management service as the older IRM, so there shouldn’t be any issue with journal decryption. Or so the theory goes.
To test the assertion, I created a new journal rule to create journal reports for messages sent to a journal recipient (an SMTP address pointing to a mailbox, distribution group, or contact). Journal rules can be managed through the Exchange Admin Center (EAC) or PowerShell. For the test, the journal rule is very simple:
Get-JournalRule Name : Yandex Test Recipient : [email protected] JournalEmailAddress : [email protected] Scope : Internal Enabled : True
Exchange Online doesn’t allow the journaling mailbox (used to collect journal reports) to be one of its mailboxes, so I used an Yandex.com mailbox. In a production environment, the journaling mailbox is usually a special mailbox belonging to a journaling service. The service collects messages that arrive into the mailbox and move them to the journal repository.
Before testing that messages in journal reports are decrypted, I made sure that the journal rule processed normal messages as expected. The next step was to create and send a protected message using the standard OME Encrypt-Only template (Figure 1).
When the journal report arrived in Yandex.com, it had two attachments (Figure 2).
Normal journal reports have one attachment. In this case, two are expected because the first attachment is the copy of the original encrypted message while the second attachment is the decrypted copy. If you open the first attachment, you see the wrapper placed by OME around the message to protect it and the link to the OME portal that a normal user would use to read the message (Figure 3).
If we open the second attachment, we see the decrypted content (Figure 4). The formatting isn’t perfect, but that’s not important because all that we need is for the journaling service to be able to access the content to index and otherwise process it in the service repository. If any attachments are present in the protected message, they are also decrypted and available to the journaling service.
The same processing occurs for journal reports containing messages protected with Office 365 sensitivity labels and the journal reports for these messages also have a decrypted, perfectly accessible copy of the message.
My tests show that the functionality requested in user voice seems to work as people want. It’s possible that things didn’t work so smoothly in 2017 when the original request was made, but Microsoft has done a lot of work in the area of information protection since to release a new version of OME and to support sensitivity labels across Office 365.
It’s also possible that certain journaling systems might still have a problem processing the journal reports generated for protected email. For example, a system might expect just one attachment and not recognize that the function of the two attachments sent by Exchange. For this reason, it’s a good idea to test how things work against whatever journaling system you choose to use.
My view is that the amount of protected email generated by Office 365 tenants will grow over time as tenants ramp up the use of sensitivity labels and OME. With that in mind, any journaling system that can’t handle these journal reports has a few questions to answer.