The April 7 article “Spare us the email yada-yada” published in The Economist provoked some consideration of how email disclaimers have evolved to a point where they have become one of the “minor nuisances of modern office life”, mostly because the information inserted in the disclaimer is designed to make the legal department happy and is largely ignored by anyone else.
The first disclaimers were text-only and were applied in the form of autosignatures or text automatically inserted by an email client when messages were created. With modern clients, autosignatures can be extremely complex and graphic-rich, such as the example of an executive who cut and pasted a picture of a newly-arrived baby into his autosignature and inflicted a couple of extra megabytes of loving graphics onto all his correspondents.
The problem with autosignatures is that they are personal. Administrators may ask users to follow a set format for their autosignature and include whatever text is deemed appropriate by the company, but there’s no good way of checking that every single user has done the right thing short of asking them to send you a message. Even then, users can change their autosignature at any time and are prone to follow the latest habit, whether this is to insert the company’s logo or some other graphic that does nothing whatsoever except waste a vast amount of disk space on email servers and keep disk salespeople happy. I’ve never quite worked out why people insist on inserting company logos into their autosignatures because invariably the vast bulk of their messages are internal and everyone knows that the sender works for the company and what the company logo is like… Maybe it creates a warm feeling of belonging. I don’t know…
The difficulty of implementing standard autosignatures or having users include the text deemed necessary by regulatory or other requirements leads us to system-applied disclaimers. This feature has been with us for quite a while. Early versions of Exchange used third-party products or home-grown “event sinks” to insert text into outgoing messages. Things got a lot easier and much cheaper with the introduction of transport rules in Exchange 2007 as you can define a rule to append text to every outgoing message. Some limitations exist in Exchange 2007 such as the plain text nature of the appended disclaimers, but the fact that you could define and apply a transport rule to do the job in about three minutes was a huge advance when compared to the torturous and costly effort required to write an event sink for Exchange 2000 or Exchange 2003.
Today, Exchange 2010 allows great flexibility in building transport rules that create the potential for administrators to have the transport system automatically stamp all outgoing messages with nicely formatted disclaimer text and so avoid the need for users to create individual autosignatures with their email client. Here’s an example that I discuss in chapter 16 of my Microsoft Exchange Server 2010 Inside Out book.
New-TransportRule -Identity 'Company disclaimer' -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">Contoso Corporation</h4>
<p style="font-family:verdana; font-size:70%;color:green">
This message is the property of <b>Contoso Corporation.</b> If you receive this message in error, please delete it <u>immediately</u> and inform us at 827-1176 about its delivery.
<p style="font-family:Arial; font-size:80%; color:blue">
<p style="font-family:Arial; font-size:70%; color:red">
<p style="font-family:Arial; font-size:70%; color:red">
-ExceptIfSubjectOrBodyContainsWords "This message is the property of Contoso Corporation"
A number of important points are illustrated here that serve to demonstrate just how feasible it is to replace the vast bulk of user-specified autosignatures with system-generated text. First, Exchange 2010 allows you to include data extracted from Active Directory, so we’ve specified instructions to extract commonly-included attributes such as the user name, phone number, and email address in the transport rule (these items are prefixed and terminated with %%). You can find the full set of Active Directory attributes that are available for use in transport rules in TechNet.
Second, while Exchange 2007 allows a rule to append simple disclaimer text, Exchange 2010 can do a much nicer job by instructing the transport rule to use HTML formatting. Unfortunately, EMC doesn’t include an HTML editor, so you can normally expect a few trial-and-error attempts before you will input the HTML code 100% correctly, but once it’s done, you end up with the ability to produce some very nice results. If you want, you can also include an image file in the disclaimer by including a reference such as the one shown below. Ideally, such an image file will be as small as possible (2KB seems like a good target) so as to avoid the dreaded “message size swelling with embedded graphics” syndrome.
The final flourish is performed with the instruction contained in the ExceptIfSubjectOrBodyContainsWords parameter, where we specify that Exchange shouldn’t add the disclaimer text if the message already contains it. This avoids the situation where a message thread contains multiple repeats of disclaimer information that obscures the really important information contained in the messages.
Of course, rules that generate disclaimers like this depend on accurate population of Active Directory. In other words, if the data can’t be extracted from Active Directory, you’ll end up with blanks as Exchange won’t guess what the information should be.
The bottom line is that while disclaimers are an annoyance of office life, the litigious nature of modern society means that we won’t be able to revert to the simpler life that existed for early email systems. Then again, we didn’t have to deal with so much spam or virus outbreaks then either, so maybe all these things are advances. What’s important is that transport rules offer a real solution to the problem that can be very quickly implemented to apply the necessary disclaimer text and allow us all to move on to the next item in our work list.