Applying Autosignatures with Transport Rules

Encryption for Exchange Online Autosignatures

When I wrote about the effect of encryption on ISV autosignature products, I made the point that the Exchange transport service can apply autosignatures (disclaimer text) to outbound messages with a rule even if the messages are encrypted. This is because Exchange uses rights management super-user permissions to decrypt messages, apply the disclaimer, and then encrypt them again for final delivery.

Questions flowed in to know if it is easy to create a transport rule (aka mail flow rule) to apply an autosignature like those generated by the ISV products. The answer is that you can, but it takes some effort, especially if you want to use nicely formatted HTML text in the autosignature. The UI in the Exchange Admin Center to create and manage transport rules isn’t very accommodating when it comes to inserting complex formatted text. However, with persistence, it’s possible to create nicely formatted autosignatures (see the Exchange documentation for some examples, including how to insert a graphic file like a logo in an autosignature).

Apart from the difficulty of editing the text used in autosignatures applied by transport rules, the most common complaint is that rules stamp all messages, including replies, so you end up with multiple autosignatures in a mail thread. This is true, but it’s easy to build an exception into the rule so that the autosignature is applied once.

Once you’ve built a transport rule to apply an autosignature, you can combine it with other rules to protect messages sent to all or some destinations by applying a rights management template, including the special Encrypt-Only or Do Not Forward templates.

An Example of Encrypted Email

An example is always helpful. The screenshot below shows a protected message received by an Outlook.com user. The message has an autosignature applied by a transport rule. The text of the autosignature is inserted into the message content even though the message is protected. Some Azure Active Directory elements (like the first name, last name, phone number, etc.) are used in the autosignature. The phone number is blank, meaning that it hasn’t been populated for the user (more on this below).

The relevant extracts from the transport rule (using Get-TransportRule) are shown below.

ExceptIfSubjectOrBodyContainsWords            : {This message is the property of Redmond and Associates}
ApplyHtmlDisclaimerLocation                   : Append
ApplyHtmlDisclaimerFallbackAction             : Wrap
ApplyHtmlDisclaimerText                       :

Redmond and Associates

This message is the property of Redmond and Associates If you receive this message in error, please delete it immediately and inform us at +353 1 991 17463 about its delivery.
%%FirstName%% %%LastName%%
Phone: %%PhoneNumber%%
Email: %%Email%%

The exception in ExceptIfSubjectOrBodyContainsWords is important because it stops the autosignature being inserted into replies.

Why Use Third-Party Autosignature Products?

If it’s relatively straightforward to use a transport rule to insert autosignatures, including for protected email, why do people buy and use third-party autosignature products? The biggest reasons are flexibility and ease of use. The third-party products make it much easier to build and deploy attractive autosignatures to targeted sets of users (or the whole company) without having to grapple with the Exchange Admin Centre UI or PowerShell. Much as I like PowerShell, using it to edit HTML is not a rewarding experience.

Organizations that need to change autosignatures frequently (for instance, to advertise events) or deploy a range of different autosignatures to different groups within the company will find it easier to use specialized autosignature products. The downside, as I pointed out in the Petri.com article, is that server-side processing by these products cannot deal with protected messages. A client-side add-in must inject the autosignature into a message before encryption is applied by the client.

Directories

A word on directories… No centrally-managed autosignature will work unless the directory it’s based on holds accurate information. Make sure that your Azure Active Directory is updated with valid information for any of the attributes (like address or phone number) used by autosignatures.

For more information about transport rules, see Chapter 17 of the Office 365 for IT Pros eBook.