If you would like to read the next part in this article series please go to Header Firewall in Exchange 2010 (Part 1).
Introduction
If you have been working with Exchange Server for any length of time, you will almost certainly have come across message headers before. Each message has a message header and an optional body. The message header itself is described in RFC2821 and RFC2822, and to quote RFC2822 in terms of the header description:
“Header fields are lines composed of a field name, followed by a colon (“:”), followed by a field body, and terminated by CRLF.”
It is possible to view the message headers using Outlook. If you are using Outlook 2010, you can view the message headers by first opening the message, then selecting the File menu option, and then choosing the Properties button that you can see in Figure 1-1.
Figure 1-1: Properties Button to View a Header
Doing so will bring up the message properties window that you can see in Figure 1-2. Notice the field at the bottom called Internet headers, which contains the message headers. In this field you can see the common “Received:” header. Other common headers are the Subject:, Date:, and From: headers. Additionally, you may also see other headers known as “X-headers”.
Figure 1-2: Headers in a Message
X-headers are custom headers that start with “X” and are a method of adding additional headers to a message. Perhaps one of the most common uses of X-headers is from antivirus or anti-spam applications that add custom X-headers to indicate values such as the Spam Confidence Level (SCL) of a message. A quick scan through messages that I’ve received in my personal mailbox reveals many different types of X-headers, such as X-MailingID, X-Abuse-Reports-To, X-Originating-IP and X-Mailer. The last one in that list, X-Mailer, happens to reveal the name of the sending system on the particular email I examined. However, in this article I’m going to focus on routing headers rather than X-headers.
Routing Headers
For the remainder of this article series, I will refer to “received:” headers as “received headers” to make things easier to read. The received headers that you can see in Figure 1-2 give routing information about the message and detail the various servers or systems that the message has passed through in order to arrive at its destination. There is also another type of routing header known as resent headers that you can use to see if a message has been forwarded and these include lines such as Resent-Sender, Resent-To and Resent-Cc. In Sender ID, the Purported Responsible Address (PRA) can be calculated using some of these resent headers. However, I will only be covering “received:” headers in this article. With all the routing information contained with the message headers, some organizations want to ensure that these headers are removed from the outbound messages that they send, or even removed from inbound messages to the organization and that’s where the header firewall feature of Exchange Server 2010 comes in. Let’s have a look at how we can use the header firewall to remove these routing headers.
The header firewall can be applied to outbound messages that are processed by send connectors, or applied to inbound messages that are processed by receive connectors; these connectors will be configured on either the Hub Transport or Edge Transport server role. If you were to create a standard send connector of usage type Internet and send messages through it, you will notice that the received headers are still visible after the message has been processed by the send connector. Similarly, the default receive connector will do the same thing.
Broadly speaking, enabling the header firewall for send and receive connectors involves running an Exchange Management Shell command to modify the permissions set on that connector. To illustrate this, let’s consider an example scenario where there are two separate Exchange Server 2010 organizations. One organization, neilhobson.com, has a Hub Transport server and an Edge Transport server to communicate with external recipients, while the other organization, nghcloud.co.uk, has just a Hub Transport server to communicate with external recipients. Of course, the organization with just a Hub Transport server may not be typical of what we’d expect to see in a production environment, but this article is based around a simple lab environment for demonstration purposes only.
In the first scenario, we will send a message from the Exchange organization with the Edge Transport server to the organization without the Edge Transport server. This configuration uses the default receive connector in the nghcloud.co.uk organization. In the neilhobson.com organization, we are using the default send and receive connectors created as a result of installing both the Hub Transport server role and the Edge Transport server role together with an Edge subscription.
If the message sent to a recipient at nghcloud.co.uk is now opened and the message headers examined, something similar to the headers that you already seen in Figure 1-2 will be seen and this is a good example of the received headers. The user in the nghcloud.co.uk organization can clearly see that the message was received from the server named HF-EDGE.neilhobson.com. In the lab environment, this is the externally-facing Edge Transport server for this organization. However, what is also important to note is that further down the list of headers, the user can see that the message was also received by HF-EDGE.neilhobson.com from a separate server named HF-EXCH.neilhobson.com. In this example, the server named HF-EXCH.neilhobson.com is a multi-role server running the Hub Transport server role. These message headers therefore contain internal server names together with internal IP addresses, which is something that you may not want to expose. Admittedly in my lab for this article both the Edge Transport and Hub Transport servers are on the same network, but typically you’d expect to see the Edge Transport and Hub Transport servers separated by a firewall with the Hub Transport server having an IP address from the internal network.
Enabling the Header Firewall on a Send Connector
Let’s now look at how we can apply the header firewall to the servers in the sending organization, neilhobson.com, such that we no longer send the received headers outbound. One way of doing this is to modify permissions on the send connector. Since we have an environment whereby the Edge Synchronization process is used, we must make the changes to the send connector on the Hub Transport server which will then be synchronized with the Edge Transport send connector. First, we can see via the Get-SendConnector cmdlet that there are two connectors created by the Edge Synchronization process. The particular connector we are interested in is the connector that is named EdgeSync – Default-First-Site-Name to Internet as you can see from Figure 1-3.
Figure 1-3: Results of Running Get-SendConnector
To set the header firewall to remove routing from a send connector, the particular extended right that we are interested in is called ms-Exch-Send-Headers-Routing. We will be looking at how we apply this extended right in the second part of this article series.
Summary
That concludes part one of this two-part article on the header firewall feature of Exchange Server 2010. We have briefly covered what the received headers are and how they contain information that we might not want sent outbound from our organization. In part two, we will cover setting the permissions firstly on the send connector and secondly on the receive connector.
If you would like to read the next part in this article series please go to Header Firewall in Exchange 2010 (Part 1).
