Adding a mail disclaimer in an MS Exchange environment
One of the biggest and most glaring omissions from Microsoft Exchange 2003 is the facility to add an enterprise wide email signature. This popular choice which as recently become a legal requirement in 2007 has caused tremendous headache for those operating with Exchange.
Of course, traditionally not everyone liked the use of E-mail disclaimers, and although it has been proven in some cases that the content be legally worthless they have now become a necessity for most. In the UK at least, law dictates they must be present – hence this page looks at means to deploy these disclaimers. Alas, a number of options exist, each of which has its merits and drawbacks, as shown below:
Use your Anti-virus software
Perhaps the simplest (if not the most elegant method) would be to use the feature provided by many anti-virus solutions at append a message to all outgoing mail. While this would normally be some template text along the lines of “This message was checked by such a program version x.x”, many enterprises opt to change this to include the legal speil necessary for such a disclaimer. Advantages of this approach are that everyone has company-wide anti-virus (they do, don’t they?) and it’s a no-cost addition. Add to this it can be centrally managed and it seems like a lossless situation. The only conceivable drawback is that some AV solutions do not offer the feature and thus alternate methods must be found.
Transport Event Scripts (Using VB)
MS KB Artice Q317680 discusses and demonstrates the use of a VB event script that will append your message to each outgoing email. While a relatively simple process to follow, there are a good number of pros and cons, some of which will be noted below. The most significant being it’s a free/no-cost solution (+), adds little overhead to the server (+) and can be updated as frequently as you like (+). Conversely, and the killer for most people is that it does not work with MAPI clients (meaning the 99.9999% of people on using Exchange will also be using Outlook or another MAPI client).
Client Side signature appendage
OK, if server-side is proving costly or problematic, why not apply it at the client side? Well, if you have hundreds or even thousands of users it becomes an administrative nightmare. Users cannot be entrusted to apply the signature themselves, so some method of centrally pushing the signature and enforcing it client-side is needed. That’s where a quick Windows 2003 logon-script can come in handy. In just a couple of lines of code you can push your signature out to the users machine and set the client to append the signature.
The first thing you need to do is copy the signature files over to the client side application data folder (nothing more than
xcopy /d \\servername\path\to\sig.txt %APPDATA%\Microsoft\Signatures\)
making sure you copy over the txt, htm and rtf files if your company does not restrict the mail format settings in Outlook. Once you have the signature client-side, you then need to do a small registry fix.
You have two options – a soft and a hard set method. The first, the soft method, sets the signature but allows users to change/edit/delete the signature. Good if you want them to be able to customise the signature to add a job title, department etc. etc. To enforce this, just create a string value called ‘NewSignature’(for new mail) and ‘ReplySignature’ (for replies) and set it to the name of the file (minus the extension!!) in
(replacing 11.0 for the version of office you are using). Now, when users next log on their signature will be set to the company disclaimer, but they will still be able to manipulate this using the Tools->Options->Mail Format dialog. The second option is a little more restrictive and forces the signature and does not allow the user to change the signature. As with the above, copy the files over to their application data folder but change the
instead of the registry key specified above. This will not allow users to change or delete the signature and forces the signature of your choosing.
The best option using this approach is often to use a mixture of that hard and soft enforcement method. For those users who are department heads or need custom signatures then allowing them to edit and customise the signature will be a valuable asset, while those users who like to ‘dabble’ or are likely disable the signature then enforcing it should be a favoured approach. Advantages of this method are that it is again a no-cost option, it can be fully managed and is very flexible, and it can also be used to prevent users adding their own signatures or editing the companies. It can also be controlled centrally via group policy and edits/updates can be pushed out to clients with minimal admin overhead.
Use third-party software
After going to the trouble of funding, deploying and configuring Exchange Server, the last thing you want to do is add further software into the equation to make it do what you need. This, however, is a common approach as organisations find SPAM filtering, POP3 connectors, mail disclaimers and much more to be glaring omissions from the Exchange Server feature set. If you are going to go down this route then there are plenty of options, including GFI MailEssentials (www.gfi.com costing upwards of £1000 for medium-large organisations) which does disclaimers and a WHOLE lot more – much of which you may or may not require; Mailfender (www.softalk.ws costing $300) offering disclaimers, spam and virus protection but not a great deal more; MailDisclaimer (www.softalk.ws costing $90) which is from the makers of MailFender but offers disclaimer support only; DisclaimIT (www.netal.com @ £50) offering rule-based disclaimer addition and SMTPDisclaimer (www.adjenterprises.co.uk costing £50 for unlimited domains). All of these products do disclaimers and sometimes a whole lot more. Whether you go down this road will depend largely whether you can incur the additional costs and of course over-head on the communications framework in your organisation.
Hopefully this article has given you some insight into the options of deploying a mail disclaimer in Microsoft Exchange Server. Until Microsoft sort their act out and bridge this functionality gap there will be a need for mail disclaimers at all kinds of organisation. Hopefully this page has given you some ideas of how this problem can be solved. If you notice any inaccuracies or want further information on any of the above, please Get in touch! A good discussion of the merits, drawbacks, legalities and construction of email disclaimers can be found on (and I kid you not, the site does really exist!) EmailDisclaimers.com