Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
A Software Development Consultant with over 20 years of experience. Many of his projects involved Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.
Exchange 2007 Hub Transport rules provide us with centralized email processing. Inserting disclaimers is one possible application. We look at how to configure this whilst exploring the functionality transport rules provide.
Most organizations require the insertion of disclaimer text to emails. Despite their questionable legal weight, disclaimers asserting that email content does not reflect the organization views are extremely common. Others insert disclaimers to give corporate emails a uniform professional look.
In earlier Exchange versions, disclaimers necessitated a third-party extension or custom sink. Exchange 2007 now includes this functionality. Today we have a first look at Hub Transport Rules. We use these to configure a disclaimer for all outgoing emails. Although we focus on disclaimer configuration, the discussion is applicable to the configuration of a wide array or possible transport rules.
As the name implies hub transport rules are enforced by Exchange 2007 servers running the Hub Transport role. At least one such server is necessary for Exchange to function. All emails, including internal, must flow through such a server. This makes the Hub Transport an ideal candidate for all kind of server side email processing.
We start our journey from the Exchange Management Console under Organization Configuration | Hub Transport.
From the Actions pane click New Transport Rule to start the configuration wizard. Those accustomed to the Outlook Rules Wizard will immediately feel comfortable. The logic is the same, except that transport rules are tailor made for server side processes.
The first step requires a rule name, an optional comment and the initial rule enablement status. We name this 'Outgoing Email Disclaimer' and move on.
Next we select the conditions that will identify the emails to be processed. This is done by ticking the checkbox of relevant conditions. Selected conditions are added to the bottom pane. From here these are customized by clicking on the blue links. If we wanted to add the disclaimer to all emails, we would have not selected any conditions. However we will only add a disclaimer to outgoing emails. Thus we select the conditions 'from users inside or outside the organization' and 'sent to users inside or outside the organization'.
We now configure the selected conditions so that the bottom pane reads: 'Apply rule to messages from users inside the organization and sent to users outside the organization'.
The first condition happens to be correct by default but the second needs to be changed. We do this by clicking on the second 'Inside' link. This brings up the scope selection dialog:
Change the scope to 'Outside' and click OK. The Next Wizard step takes us to the Action selection stage. This lists the set of built-in actions. From here we choose the one for appending disclaimers:
As the bottom pane shows, we can now specify the disclaimer text and also its presentation aspects such as the font and text colour. We set the text to be appended by clicking on the 'disclaimer text' link.
In case we only have one hub transport server this would be the only necessary rule action. However we need a second action in case of organizations running more than one hub transport. Since all emails must flow through a hub transport, multiple servers may be necessary to distribute load and fault tolerance. This introduces the risk of emails flowing through more than one hub transport, leading to multiple disclaimer insertions. We thus insert a custom header:
This flags the email as processed. We will soon use this to setup an exception for excluding already processed emails. The header name and value are not important as long as these are consistent throughout the rule configuration and the header name starts with 'X-'.
Thus from the action list we also select 'set header with value'. We then click on the 'header' link to specify the header name as 'X-MY-DISCLAIMER' and the 'value' link to set this to 'ready'.
Clicking Next, the wizard moves to the Exception configuration stage. You already know how this goes. Configurations with multiple hub transports will configure an exception excluding emails with X-MY-DISCLAIMER header.
Select the 'except when the text specific words appear in a message header' exception. From the bottom pane click the 'specific words' link setting it to 'ready' and the 'message header' link setting it to X-MY-DISCLAIMER.
We are almost done. Move the wizard to the completion stage so that to create the rule. If at the wizard introductory step the rule was configured as enabled, emails will immediately start being stamped by the disclaimer.
The completion step also provides the Exchange management shell command that was used to create the rule. We could copy this and reuse it to create the same rule at other Exchange installations. This is very handy when moving from the test environment to the live environment. Exactly the same rule can be recreated without rerunning the wizard avoiding any potential configuration differences. Of course the command would still need to be tweaked if it contained domain specific settings not applicable to the new environment.
This completes our disclaimer configuration. As we have seen the Rules Transport Wizard interface mimics the Outlook Rules Wizard logic rendering it immediately intuitive. Once you configure the first rule, it is easy to appreciate how the various conditions, actions and exceptions can be combined for all kind of email processing operations.
We used X-MY-DISCLAIMER for marking processed emails. A similar result was achievable through an exception that looks for the disclaimer text in the message body. This is neater as it avoids inserting the additional header. However let's consider an email conversation with many replies flowing back and forth. The exception may match the disclaimer text of an earlier reply somewhere in the middle of the email text. Some organizations require the disclaimer text to always appear right at the bottom of the email. Thus in such a case the additional header is necessary. Apart for that, the additional header is a more generic solution that you may find applicable in other rules not related to disclaimers.