WinDeveloper O365 Mailer FREE for 1 Year

WinDeveloper IMF Tune
WinDeveloper IMF Tune
  • Home
  • General
  • Appending Disclaimers Using Exchange 2007 Hub Transport Rules

Appending Disclaimers Using Exchange 2007 Hub Transport Rules

Alexander Zammit

Alexander Zammit Photo

Software Development Consultant. Involved in the development of various Enterprise software solutions. Today focused on Blockchain and DLT technologies.

Cast your Vote
Poor Excellent

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.

Exchange 2007 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.

New Transport Rule

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.

Rule Conditions

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:

Scope Selection

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:

Disclaimer Action

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.

Disclaimer Text Configuration

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-'.

Custom Header

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'.

Custom Header Configuration

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.

Exchange Management Shell command

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.

Final Tips

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.

User Comments - Page 1 of 1

Manish 23 Dec 2010 11:19
"if I applied the hub Transport Rule and i want to Edit the the Rule but the edit tab is not highlighted then what will be the problem"

please help
TED 19 Jan 2010 09:28

"if emails are encrypted or digitally signed and you append a disclaimer by using transport rules then the original emails arrive as attachment to a disclaimer email "

Has anyone found a solution for this?
Sachin 29 Dec 2009 03:51
I have tried this. But the disclaimer gets attached everytime the message is replied.
I have checked the header and the X-MY-DISCLAIMER was already set to ready.

SO how did the transport processor missed this?
any ideas?
Björn 27 Feb 2009 07:06

if emails are encrypted or digitally signed and you appand a disclaimer by using transport rules then the original emails arrive as attachment to a disclaimer email. I understand that Exchange is not allowed to change a signed email, but the solution is not ver comfortable for recipients especially not in the case for regularely encrypted email conversations.
Additionally I'm wondering why there is no option to exclude encyrypted or signed emails in the rules.

Matthew Aylard 6 Oct 2008 05:58
One thing that confused me though is why it changes are not processed straight away after editing an existing rule. Then read the MS article about the cache and how you need to bounce the transport service on all hub transport servers.
Copyright © 2005 - 2024 All rights reserved. is not affiliated with Microsoft Corporation