The content below is taken from the original ( Rights Management, Protection, and Email AutoSignatures), to continue reading please visit the site. Remember to respect the Author & Copyright.
Protection for the Masses
As part of its Microsoft 365 Information Protection initiative, Microsoft has done a good job to make encryption more accessible for Exchange Online users through the introduction of Sensitivity Labels and the Encrypt-Only and Do Not Forward options in Outlook and OWA. The net effect is that it’s easier than ever before for Office 365 users to protect their email with encryption and rights management.
Increased use of inbuilt encryption might see a reduction of the use of third-party encryption schemes like S/MIME or PGP, simply because sensitivity labels and the inbuilt protection are so easy to use. You don’t have to install add-ins for clients, there’s no need for key management, and any recipient on any email system can read a protected message. Everything works out of the box for Office 365 E3 and E5 tenants because the licenses for rights management are baked into these plans.
Encryption and Rights Management
Protecting email with easy-to-use encryption has many benefits, especially when combined with rights management. If a protected message reaches someone who shouldn’t have it, the assigned permissions will probably stop the recipient being able to read the message. Even if the permissions allow access (for instance, you can now assign a special Any Authenticated Users permission to allow any account authenticated with a Microsoft directory to access content) the sender can easily revoke access to the message. Another advantage is that no one can read a protected message if a recipient forwards it without the permission of the sender.
However, the advent of easy encryption has a knock-on effect on any third-party product that processes email. With that thought in mind, I’ve been looking at how autosignature products deal with protected email.
Autosignature Technology
Autosignature products allow companies to manage text and graphics inserted into outbound messages. The content usually includes the sender’s name, their contact details, some cheery text to promise dire consequences on anyone who accesses the email without authorization, and the company logo. It’s a matter of speculation as to how much of the Exchange Online mailbox databases are filled with company logos, but that’s not important right now.
Market Review
I contacted four autosignature vendors to ask them how they cope with protected email. Table 1 documents what I discovered.
| Product | Outcome |
| Code Two Email Signatures for Office 365 | Can’t process protected email. |
| Crossware Mail Signature | Client-side autosignatures support protected email; server-based processing can’t process protected email. |
| Exclaimer Cloud Signatures for Office 365 | Client-side autosignatures support protected email; server-based processing can’t process protected email. |
| Symprex Email Signature Manager | Can’t process protected email. [At least, Symprex logged my query and then did not respond further. I interpret this to be the case from their documentation] |
Table 1: Popular Email autosignature products and protected email
Exclaimer’s client-side component supports Outlook for Windows. The Crossware client-side solution uses the Outlook manifest model and supports Outlook 2013 onward for Windows, Outlook 2016 for Mac, and OWA. Crossware allows users to preview an autosignature before insertion and has an “intelligent” mode that selects the best autosignature from a set based on the content of a message.
If your preferred client doesn’t support autosignatures, server-side processing is the only alternative. This is especially so for mobile clients like Outlook for iOS and Android, the native email apps found on mobile devices like the iOS mail app, and IMAP4/POP3 clients like Thunderbird. Given the widespread and increasing usage of mobile devices for email, server-side processing is very important for any company that wants to manage autosignatures.
Need for Change
Current autosignature products do a sterling job inserting text and graphics into unprotected email. But technology changes and new functionality brings new challenges. According to some of the companies I spoke with, they are working with Microsoft to figure out how to process protected email in the cloud.
Hopefully, Microsoft and the ISVs come up with a scheme to allow autosignatures to be applied to protected messages in transit. Because processing happens in transit, it can be managed centrally, and all clients are supported. Until this functionality is available, client-side injection is the only way to add autosignature text to protected messages, unless you use a transport rule.
Transport Super-User
Exchange Online transport (mail flow) rules can insert text even to protected messages. The Exchange transport service has super-user privilege for rights management, which it uses to decrypt protected messages, insert text, and then encrypt the messages again for onward transmission. It’s possible that Microsoft might allow ISVs to use something like super-user privilege to insert autosignatures. There’s no reason why this wouldn’t work but allowing third-party products to decrypt and encrypt messages is a big step that not all customers might be happy with.
Future Solutions
Like any other technology, it will take some time before Office 365 tenants fully embrace sensitivity rules and make more extensive use of rights management and encryption to protect email. While the brains trust in the ISVs figure out how to best deal with protected email, if you’re interested in using autosignatures with protected email now, you should check out the available products and go with the one that offers the best all-round solution for both protected and unprotected email.
The post Rights Management, Protection, and Email AutoSignatures appeared first on Petri.
