Auto-Signatures For All
In the early days of email, we didn’t worry so much about applying signatures to outbound messages. Even when Exchange came along in 1996, the focus stayed on the content rather than adding pretty company information at the bottom of messages. Roll on twenty years, the situation is different and it is common to find various disclaimers, logos, and contact information added to messages, sometimes to meet legal requirements (as in the U.K.).
The Signature Options
Given that a real need might exist to ensure that messages contain some form of signature information (if only to fully identify the sender), the question is then how best to make this happen when using either Office 365 or on-premises Exchange.
You can use three approaches to solve the problem:
- Have users apply disclaimers.
- Central management using PowerShell or transport rules.
- Deploy a commercial product.
The last two options depend on information extracted from Active Directory to populate fields in email signatures, so making sure that correct user and organizational data are present in the directory is fundamental to success.
Making Users do the Right Thing
Option one relies on users to create and maintain signatures. You can tell users what they need to do to create a suitable email signature through their client of choice. Figure 1 shows how to edit a signature with Outlook 2016.
A signature can pretty complex and include logos and other images. In some cases, companies like to include text to inform recipients that they disclaim responsibility of pretty well everything together with dire warnings of the horrible consequences that await someone who receives a message in error. Other text that you could include is the formal company name, contact information, and registration numbers or other details.
The problem with users is that they forget to do things or create signatures that are not in line with the desired standard. Some organizations try to solve the problem by circulating template signatures periodically to remind users that they should have a signature that follows a certain standard. This will not stop users taking artistic license with their signatures, but it might help.
Because users cannot really be depended upon to maintain their autosignatures to a corporate standard, the need for a different approach usually becomes quickly apparent, especially in larger organizations.
Two options are available to manage autosignatures centrally. The first is the PowerShell Set-MailboxMessageConfiguration cmdlet, which can be used to create an autosignature for a target mailbox. This example creates a simple HTML-format autosignature using a specific font and size. The same signature is used for OWA and Outlook and is only applied to new messages.
[PS] C:\> Set-MailboxMessageConfiguration -Identity "Rob Young" -AutoAddSignature $True -SignatureHTML "<h3>Rob Young is fantastic! </h>" –DefaultFormat HTML –DefaultFontName "Verdana" –DefaultFontSize 4 -AutoAddSignatureOnReply $False
It’s perfectly possible to write a script that will loop through all user mailboxes, compose a suitable autosignature for each mailbox based on information held in Active Directory, and then apply the autosignature to each mailbox complete with the necessary corporate logo and disclaimer text.
The problem with this approach is its manual nature. New mailboxes won’t have autosignatures applied when they are created and users will be able to overwrite autosignatures if they want.
Transport Rules and Autosignatures
The second way to manage signatures centrally is to use an Exchange Transport Rule (ETR) to apply autosignatures to messages as they go through the transport pipeline. The advantage of this method is that you can be sure that an autosignature is applied because all messages are processed by transport, even when sent to a local mailbox. ETRs are applied to messages sent by any client, so they provide a good way to ensure that every message is processed in the same way.
You’re not limited to a single ETR as different ETRs can be used to process messages from different groups. For instance, you could have an ETR for each country so that the autosignatures include some country-specific information.
The downside is that ETRs can’t process encrypted (protected) or signed messages because applying an autosignature would compromise the integrity of these messages. In addition, users are free to apply their own autosignature, so you can end up with some messy combinations at the end of messages (Figure 2). Nevertheless, ETRs can be a good solution to the autosignature problem, providing that you construct suitable rules.
As a practical example, here’s the PowerShell code to create an ETR to apply disclaimers to outbound messages (a modified version of the example in my Exchange 2010 Inside Out book). The trick here is to avoid autosignatures being inserted into replies where the original message already contains the autosignature. To do this, the rule includes an exception covering that case. The rule is the same that is used to apply the autosignature shown in Figure 2.
[PS] C:\> New-TransportRule -Name 'Company disclaimer' -Comments 'This transport rule applies the approved company disclaimer to every outgoing message' –Priority ‘0’ -Enabled $true -SentToScope 'NotInOrganization' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText '<h4 style="font-family:verdana">Redmond and Associates</h4><p><p style="font-family:verdana; font-size:70%;color:green">This message is the property of <b>Redmond and Associates</b> If you receive this message in error, please delete it <u>immediately</u> and inform us at +353 1 2xxxxxx about its delivery.<p><p style="font-family:Arial; font-size:80%; color:blue"><i>%%FirstName%% %%LastName%%</i><p style="font-family:Arial; font-size:70%; color:red">Phone: %%PhoneNumber%%<p style="font-family:Arial; font-size:70%; color:red">Email: %%Email%%' -ApplyHtmlDisclaimerFallbackAction 'Wrap' -ExceptIfSubjectOrBodyContainsWords 'This message is the property of Redmond and Associates'
Maintaining HTML formatting in ETRs can be a challenge at times because neither PowerShell nor the Exchange Administration Center is designed for this purpose. However, some trial and error usually gets the job done.
If you don’t want to create-your-own solution or tire of debugging HTML text in ETRs, you can pay for and deploy a commercial solution. A number of well-known products exist in this area, such as CodeTwo, and different capabilities are available for Office 365 and Exchange on-premises, so it is important that you take this into account.
Commercial products offer the major advantage of being tried and trusted and based on the experience of many years of dealing with various customer demands for different types of autosignatures. All come with administration facilities to make it easier to build and deploy autosignatures. Given that autosignatures have been around for years, it would be surprising if a new and unmet requirement appeared now.
Cost is the downside of using a commercial product, But the cost of using an off-the-shelf product is often much less than the cost of creating and maintaining your own solution.
Before making a choice, it’s best to test these products in your own environment to ensure that the software satisfies your needs. A search of user forums like Reddit often provides useful insight into how people use these products.
A Lingering Problem
Autosignatures are a problem that has been around for a long time. In fact, it’s surprising that Microsoft doesn’t include some basic functionality to manage autosignatures for organizations. I guess the feature is low on their priorities – or perhaps this is one field that Microsoft is willing to leave to ISVs.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros,” the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle