Understanding Header Firewall

Understanding Header Firewall

Exchange 2007

Understanding Header Firewall

Applies to: Exchange Server 2007, Exchange Server 2007 SP1 Topic Last Modified: 2007-09-13

In Microsoft Exchange Server 2007, header firewall is a mechanism that removes specific header fields from inbound and outbound messages. Computers that are running Exchange 2007 that have the Hub Transport server role or the Edge Transport server role installed insert custom X-header fields into the message header. An X-header is a user-defined, unofficial header field that exists in the message header. X-headers are not specifically mentioned in RFC 2822, but the use of an undefined header field starting with "X-" has become an accepted way to add unofficial header fields to a message. Messaging applications, such as anti-spam, antivirus, and messaging server applications may add their own X-headers to a message. X-header fields are usually preserved but ignored by messaging servers and clients that don't use them.

The X-header fields contain details about the actions that are performed on the message by the transport server, such as the spam confidence level (SCL), content filtering results, and rules processing status. Revealing this information to unauthorized sources could pose a potential security risk.

Header firewall prevents the spoofing of these X-headers by removing them from inbound messages that enter the Exchange organization from untrusted sources. Header firewall prevents the disclosure of these X-headers by removing them from outbound messages that will go to untrusted destinations outside the Exchange organization. Header firewall also prevents the spoofing of standard routing headers that are used to track the routing history of a message.

Custom Organization X-Headers and Forest X-Headers that Are Used in Exchange 2007

Organization X-headers start with "X-MS-Exchange-Organization-". Forest X-headers start with "X-MS-Exchange-Forest-".

Table 1 describes some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2007 organization.

Table 1 Some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2007 organization

X-Header	Description
X-MS-Exchange-Forest-RulesExecuted	This X-header lists the transport rules that were performed on the message.
X-MS-Exchange-Organization-Antispam-Report	This X-header is a summary report of the anti-spam filter results that have been applied to the message by the Content Filter agent.
X-MS-Exchange-Organization-AuthAs	This X-header is always present when the security of a message has been evaluated. This X-header specifies the authentication source. The possible values are `Anonymous`, `Internal`, `External`, or `Partner`.
X-MS-Exchange-Organization-AuthDomain	This X-header is populated during Domain Secure authentication. The value is the fully qualified domain name (FQDN) of the remote authenticated domain.
X-MS-Exchange-Organization-AuthMechanism	This X-header specifies the authentication mechanism for the submission of the message. The value is a 2-digit hexadecimal number.
X-MS-Exchange-Organization-AuthSource	This X-header specifies the FQDN of the server computer that evaluated the authentication of the message on behalf of the organization.
X-MS-Exchange-Organization-Journal-Report	This X-header identifies journal reports in transport. As soon as the message leaves the transport server, the header becomes X-MS-Journal-Report.
X-MS-Exchange-Organization-OriginalArrivalTime	This X-header identifies the time when the message first entered the Exchange organization.
X-MS-Exchange-Organization-Original-Sender	This X-header identifies the original sender of a message when it first entered the Exchange organization.
X-MS-Exchange-Organization-OriginalSize	This X-header identifies the original size of a message when it first entered the Exchange organization.
X-MS-Exchange-Organization-Original-Scl	This X-header identifies the original SCL of a message when it first entered the Exchange organization.
X-MS-Exchange-Organization-PCL	This X-header identifies the phishing confidence level (PCL). The possible PCL values are from 1 to 8. A larger value indicates a suspicious message. For more information, see Anti-Spam Stamps.
X-MS-Exchange-Organization-Quarantine	This X-header indicates that the message has been quarantined in the spam quarantine mailbox and a delivery status notification (DSN) has been sent. Or it indicates that the message was quarantined and released by the administrator. This X-header field prevents the released message from being submitted to the spam quarantine mailbox again. For more information, see How to Recover Quarantined Messages from the Spam Quarantine Mailbox.
X-MS-Exchange-Organization-SCL	This X-header identifies the SCL of the message. The possible SCL values are from 0 to 9. A larger value indicates a suspicious message. The special value -1 exempts the message from processing by the Content Filter agent. For more information, see Configuring Content Filtering.
X-MS-Exchange-Organization-SenderIdResult	This X-header contains the results of the Sender ID agent. The Sender ID agent uses the sender policy framework (SPF) to compare the message's source IP address to the domain that is used in the sender's e-mail address. The Sender ID results are used to calculate the SCL of a message. For more information, see Sender ID.

Header Firewall for Organization X-Headers and Forest X-Headers

Exchange 2007 applies header firewall to organization X-headers and forest X-headers that exist in messages in the following ways:

Permissions that can be used to preserve or remove specific X-headers in messages are assigned to Send connectors or Receive connectors.
Header firewall is automatically implemented for X-headers in messages during other types of message submission.

How Header Firewall is Applied to Organization X-Headers and Forest X-headers in Messages

Header firewall for organization X-headers and forest X-headers that exist in inbound messages consists of two specific permissions that are assigned to a Receive connector that is configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Receive connector, header firewall is not applied to the message. The organization X-headers or forest X-headers in the message are preserved.
If the permissions are not applied to the Receive connector, header firewall is applied to the message. The organization X-headers or forest X-headers are removed from the message.

Table 2 describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector.

Table 2 Header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector for inbound messages

Permission	By default, the security principals that have the permission assigned	Permission group that has the security principals as members	By default, the usage type that assigns the permission groups to the Receive connector	Description
Ms-Exch-Accept-Headers-Organization	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only)	ExchangeServers	`Internal`	This permission applies to organization X-headers. Organization X-headers start with "X-MS-Exchange-Organization-". If this permission is not granted, the receiving server removes any organization headers from the message.
Ms-Exch-Accept-Headers-Forest	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only)	ExchangeServers	`Internal`	This permission applies to forest X-headers. Forest X-headers start with "X-MS-Exchange-Forest-". If this permission is not granted, the receiving server removes any forest headers from the message.

If you want to apply header firewall to organization X-headers and forest X-headers in a custom Receive connector scenario, use the any of following methods:

Create a new Receive connector, and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see How to Create a New Receive Connector.
Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see How to Modify the Configuration of a Receive Connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission from a security principal that is configured on the Receive connector. This method doesn't work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see Remove-ADPermission.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission to a security principal that is configured on the Receive connector. For more information, see Add-ADPermission.

How Header Firewall is Applied to Organization X-Headers and Forest X-Headers in Outbound Messages

Header firewall for organization X-headers and forest X-headers that exist in outbound messages consists of two specific permissions that are assigned to a Send connector that is configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Send connector, header firewall is not applied to the message. The organization X-headers or forest X-headers in the message are preserved.
If the permissions are not applied to the Send connector, header firewall is applied to the message. The organization X-headers and forest X-headers are removed from the message.

Table 3 describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector.

Table 3 Header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector for outbound messages

Permission	By default, the security principals that have the permission assigned	By default, the usage type that assigns the security principals to the Send connector	Description
Ms-Exch-Send-Headers-Organization	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only) Externally secured servers Exchange Legacy Interop universal security group Exchange Server 2003 and Exchange 2000 Server bridgehead servers	`Internal`	This permission applies to organization X-headers. Organization X-headers start with "X-MS-Exchange-Organization-". If this permission is not granted, the sending server removes any organization headers from the message.
Ms-Exch-Send-Headers-Forest	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only) Externally secured servers Exchange Legacy Interop universal security group Exchange 2003 and Exchange 2000 bridgehead servers	`Internal`	This permission applies to forest X-headers. Forest X-headers start with "X-MS-Exchange-Forest-". If this permission is not granted, the sending server removes any forest headers from the message.

If you want to apply header firewall for organization X-headers or forest X-headers in a custom Send connector scenario, use the any of following methods:

Create a new Send connector, and select a usage type other than Internal or Partner. The Send connector usage type can only be set when you create the connector. For more information, see How to Create a New Send Connector.
Remove a security principal that assigns the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from the connector. For more information, see How to Modify the Configuration of a Send Connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from one of the security principals that is configured on the Send connector. For more information, see Remove-ADPermission.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission to one of the security principals that is configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall is Applied to Organization X-Headers and Forest X-Headers from Other Message Sources

Messages can enter the Exchange 2007 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for organization X-headers and forest X-headers is applied to messages originating from these other message sources as described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for organization X-headers and forest X-headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Managing the Pickup Directory.
Replay directory The Replay directory is used to resubmit messages that have been exported from Exchange 2007 message queues. How header firewall for organization X-headers and forest X-headers is applied in these messages is controlled by the X-CreatedBy: header field in the message file:
- If the value of this header field is MSExchange12, header firewall is not applied to the message.
- If the value of X-CreatedBy: is not MSExchange12, header firewall is applied.
- If the X-CreatedBy: header field does not exist in the message file, header firewall is applied.
For more information about the Replay directory, see Managing the Replay Directory.
Drop directory The Drop directory is used by Foreign connectors on Hub Transport servers to send messages to messaging servers that do not use the Simple Mail Transfer Protocol (SMTP) to transfer messages. Header firewall for organization X-headers and forest X-headers is always applied to message files before they are put in the Drop directory. For more information about Foreign connectors, see Foreign Connectors.
Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. For outgoing messages that are created and submitted from mailboxes, header firewall for organization X-headers and forest X-headers is always applied. For incoming messages, header firewall for organization X-headers and forest X-headers is selectively applied. The X-headers that are specified in the following list are not blocked by header firewall for inbound messages to mailbox recipients:
- X-MS-Exchange-Organization-SCL
- X-MS-Exchange-Organization-AuthDomain
- X-MS-Exchange-Organization-AuthMechanism
- X-MS-Exchange-Organization-AuthSource
- X-MS-Exchange-Organization-AuthAs
- X-MS-Exchange-Organization-OriginalArrivalTime
- X-MS-Exchange-Organization-OriginalSize
For more information about the store driver, see Transport Architecture.
DSN messages Header firewall for organization X-headers and forest X-headers is always applied to the original message or the original message header that is attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications.
Agent submission Header firewall for organization X-headers and forest X-headers is not applied to messages that are submitted by agents.

Header Firewall for Routing Headers

Routing headers are standard SMTP header fields that are defined in RFC 2821 and RFC 2822. Routing headers stamp a message by using information about the different messaging servers that were used to deliver the message to the recipient. The available routing headers are described in the following list:

Received: A different instance of this header field is added to the message header by every messaging server that accepted and forwarded the message to the recipient. The Received: header typically includes the name of the messaging server and a date-timestamp.
Resent-*: Resent header fields are informational header fields that can be used to determine whether a message has been forwarded by a user. The following resent header fields are available: Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc:, and Resent-Message-ID:.
The Resent fields are used so that the message appears to the recipient as if it was sent directly by the original sender. The recipient can view the message header to discover who forwarded the message.

Routing headers that are inserted into messages can be used to misrepresent the routing path that a message traveled to reach a recipient. Exchange 2007 uses two different ways to apply header firewall to routing headers that exist in messages:

Permissions are assigned to Send connectors or Receive connectors that can be used to preserve or remove routing headers in messages
Header firewall is automatically implemented for routing headers in messages during other types of message submission.

How Header Firewall is Applied to Routing Headers in Inbound Messages

Receive connectors have the Ms-Exch-Accept-Headers-Routing permission that is used to accept or reject any routing headers that exist in an inbound message:

If this permission is granted, all routing headers are preserved in the inbound message.
If this permission is not granted, all routing headers are removed from the inbound message.

Table 4 describes the default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector.

Table 4 Default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector

By default, the security principals that have the permission assigned	Permission group that has the security principals as members	By default, the usage type that assigns the permission groups to the Receive connector
Anonymous user account	Anonymous	`Internet`
Authenticated user accounts	ExchangeUsers	`Client` (unavailable on Edge Transport servers)
Hub Transport servers Edge Transport servers Exchange Servers (Hub Transport servers only) Externally Secured servers	ExchangeServers	`Internal`
Exchange Legacy Interop security group	ExchangeLegacyServers	`Internal`
Partner Server account	Partner	`Internet` `Partner`

The Ms-Exch-Accept-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom Receive connector scenario, follow these steps:

Perform one of the following actions:
- Create a new Receive connector, and select the usage type Custom. Do not assign any permission groups to the Receive connector. You can't modify the assigned permissions or the group membership of a permission group.
- Modify an existing Receive connector, and set the PermissionGroups parameter to the value None.
Use the Add-ADPermission cmdlet to add the appropriate security principals that are required on the Receive connector. Make sure that no security principals have the Ms-Exch-Accept-Headers-Routing permission assigned to them. If it is necessary, use that Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Headers-Routing permission to the security principal that you want to configure to use the Receive connector.

For more information, see the following topics:

How Header Firewall is Applied to Routing Headers in Outbound Messages

Send connectors have the Ms-Exch-Send-Headers-Routing permission that is used to allow or remove any routing headers that exist in an outbound message:

If this permission is granted, all routing headers are preserved in the outbound message.
If this permission is not granted, all routing headers are removed from the outbound message.

Table 5 describes the default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector.

Table 5 Default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector

By default, the security principals that have the permission assigned	By default, the usage type that assigns the security principals to the Send connector
Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only) Externally secured servers Exchange Legacy Interop universal security group Exchange 2003 and Exchange 2000 bridgehead servers	`Internal`
Anonymous User Account	`Internet`
Partner Servers	`Partner`

The Ms-Exch-Send-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom Send connector scenario, use the any of following methods:

Create a new Send connector, and select the usage type Custom. The Send connector usage type can only be set when you create the connector. For more information, see How to Create a New Send Connector.
Remove a security principal that assigns the Ms-Exch-Send-Headers-Routing permission from the connector. For more information, see How to Modify the Configuration of a Send Connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from one of the security principals that is configured on the Send connector. For more information, see Remove-ADPermission.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Routing permission to one of the security principals that is configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall is Applied to Routing Headers from Other Message Sources

Messages can enter the Exchange 2007 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for routing headers is applied to the other messages sources that are described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for routing headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Managing the Pickup Directory.
Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. Header firewall for routing headers is always applied to all messages that are sent from mailboxes on Mailbox servers. Header firewall for routing headers is not applied to incoming messages for delivery to mailbox recipients. For more information about the store driver, see Transport Architecture.
DSN messages Header firewall for routing headers is always applied to the original message or the original message header that is attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications.
Replay directory, Drop directory, and Agent submission Header firewall for routing headers is not applied to messages that are submitted by the Replay directory, the Drop directory, or agents.

Header Firewall and Earlier Versions of Exchange Server

Exchange 2003 and earlier versions of Exchange Server do not use the organization X-headers or forest X-headers. Exchange 2007 treats earlier versions of Exchange Server as untrusted message sources. Header firewall is applied to all organization X-headers and forest X-headers in messages coming from servers that are running earlier versions of Exchange Server. Header firewall for organization X-headers and forest X-headers is also applied to messages that are delivered to servers that are running earlier versions of Exchange Server that exist in the Exchange organization.

Earlier versions of Exchange Server use the proprietary verb X-EXCH50 to transmit information about messages and recipients that can't be included in the e-mail message. The information is transmitted as the EXCH50 binary large object. The EXCH50 binary large object is a collection of binary data that is stored as a single object. Exch50 contains data such as the SCL, address rewriting information, and other MAPI properties that do not have MIME representation. Because X-EXCH50 is a proprietary Extended Simple Mail Transfer Protocol (ESMTP) verb, Exch50 data can't be propagated by a server that does not have Exchange Server installed. For more information, see Planning for Coexistence.

Routing group connectors between servers that have Exchange Server 2007 or Exchange Server 2003 installed are automatically configured to support sending and receiving Exch50 data. Send connectors and Receive connectors have permissions that enable the Exch50 command.

Table 6 describes the permissions that allow the Exch50 command on a Receive connector for inbound messages. If one of these permissions is not granted, and a message is sent that contains the Exch50 command, the server accepts the message, but doesn't include the Exch50 command.

Table 6 Permissions that allow the Exch50 command on a Receive connector for inbound messages

Permission	By default, the security principals that have the permission assigned	Permission group that has the security principals as members	By default, the usage type that assigns the permission groups to the Receive connector
Ms-Exch-Accept-Exch50	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only) Externally Secured servers	ExchangeServers	`Internal`
Ms-Exch-Accept-Exch50	Exchange Legacy Interop security group	ExchangeLegacyServers	`Internal`

If you want to block the Exch50 command in a custom Receive connector scenario, use the any of following methods:

Create a new Receive connector, and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see How to Create a New Receive Connector.
Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see How to Modify the Configuration of a Receive Connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Exch50 permission from a security principal that is configured on the Receive connector. This method does not work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see Remove-ADPermission.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Exch50 permission to a security principal that is configured on the Receive connector. For more information, see Add-ADPermission.

Table 7 describes the permission that allows the Exch50 command on a Send connector for outbound messages. If this permission is not granted and a message is sent that contains the Exch50 command, the server sends the message, but doesn't include the Exch50 command.

Table 7 Permission that allows the Exch50 command on a Send connector for outbound messages

Permission	By default, the security principals that have the permission assigned	By default, the usage type that assigns the security principals to the Send connector
Ms-Exch-Send-Exch50	Hub Transport servers Edge Transport servers Exchange Servers (Note: On Hub Transport servers only) Externally secured servers Exchange Legacy Interop universal security group Exchange 2003 and Exchange 2000 bridgehead servers	Internal

If you want to block the Exch50 command in a custom Send connector scenario, you can use the any of following methods:

Create a new Send connector, and select a usage type other than Internal. The Send connector usage type can only be set when you create the connector. For more information, see How to Create a New Send Connector.
Remove a security principal that assigns the Ms-Exch-Send-Exch50 permission from the connector.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Exch50 permission from one of the security principals that is configured on the Send connector. For more information, see Remove-ADPermission.
Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Exch50 permission to one of the security principals that is configured on the Send connector. For more information, see Add-ADPermission.

Product Families

Resources

About Microsoft

Popular Places

Popular Searches

Popular Downloads