Understanding Header Firewall
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
In Microsoft Exchange Server 2010, header firewall is a mechanism that removes specific header fields from inbound and outbound messages. Computers that are running Exchange 2010 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 aren't 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.
Looking for management tasks related to managing transport servers? See Managing Transport Servers.
Contents
Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010
Header Firewall for Organization X-Headers and Forest X-Headers
Header Firewall for Routing Headers
Header Firewall and Earlier Versions of Exchange
Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010
Organization X-headers start with X-MS-Exchange-Organization-. Forest X-headers start with X-MS-Exchange-Forest-.
The following table describes some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 organization.
Some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 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 |
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 quarantined message when it first entered the Exchange organization. |
X-MS-Exchange-Organization-OriginalSize |
This X-header identifies the original size of a quarantined message when it first entered the Exchange organization. |
X-MS-Exchange-Organization-Original-Scl |
This X-header identifies the original SCL of a quarantined message when it first entered the Exchange organization. |
X-MS-Exchange-Organization-PCL |
This X-header identifies the phishing confidence level. The possible phishing confidence level values are from 1 through 8. A larger value indicates a suspicious message. For more information, see Understanding 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. Alternatively, 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 Release 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 through 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 Understanding 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's 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 Understanding Sender ID. |
Return to top
Header Firewall for Organization X-Headers and Forest X-Headers
Exchange 2010 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's configured on a Hub Transport server or an Edge Transport server:
If the permissions are assigned to the Receive connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved.
If the permissions aren't 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.
The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector.
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 |
|
ExchangeServers |
|
This permission applies to organization X-headers. Organization X-headers start with X-MS-Exchange-Organization-. If this permission isn't granted, the receiving server removes any organization headers from the message. |
Ms-Exch-Accept-Headers-Forest |
|
ExchangeServers |
|
This permission applies to forest X-headers. Forest X-headers start with X-MS-Exchange-Forest-. If this permission isn't 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 any of the following methods:
Create a 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 Create an SMTP Receive Connector.Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties.
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's 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's 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's configured on a Hub Transport server or an Edge Transport server:
If the permissions are assigned to the Send connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved.
If the permissions aren't 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.
The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector.
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 |
|
|
This permission applies to organization X-headers. Organization X-headers start with X-MS-Exchange-Organization-. If this permission isn't granted, the sending server removes any organization headers from the message. |
Ms-Exch-Send-Headers-Forest |
|
|
This permission applies to forest X-headers. Forest X-headers start with X-MS-Exchange-Forest-. If this permission isn't 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 the following methods:
Create a Send connector and select a usage type other than
InternalorPartner. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP 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 Configure Send Connector Properties.
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's 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's 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 2010 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 Understanding the Pickup and Replay Directories.
Replay directory The Replay directory is used to resubmit messages that have been exported from Exchange 2010 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
MSExchange14, header firewall isn't applied to the message.If the value of
X-CreatedBy:isn'tMSExchange14, header firewall is applied.If the
X-CreatedBy:header field doesn't exist in the message file, header firewall is applied.
For more information about the Replay directory, see Understanding the Pickup and Replay Directories.
Drop directory The Drop directory is used by Foreign connectors on Hub Transport servers to send messages to messaging servers that don't use SMTP to transfer messages. Header firewall for organization X-headers and forest X-headers is always applied to message files before they're put in the Drop directory. For more information about Foreign connectors, see Understanding 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 aren't 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 Understanding Transport Pipeline.
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's 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 isn't applied to messages that are submitted by agents.
Return to top
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:, andResent-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 2010 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's 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 isn't granted, all routing headers are removed from the inbound message.
The following table describes the default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector.
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 |
|
Authenticated user accounts |
ExchangeUsers |
|
|
ExchangeServers |
|
Exchange Legacy Interop universal security group |
ExchangeLegacyServers |
|
Partner Server account |
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 Receive connector and select the usage type
Custom. Don't 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's necessary, use the 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's 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 isn't granted, all routing headers are removed from the outbound message.
The following table describes the default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector.
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 |
|---|---|
|
|
Anonymous User Account |
|
Partner Servers |
|
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 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 Create an SMTP Send Connector.Remove a security principal that assigns the Ms-Exch-Send-Headers-Routing permission from the connector. For more information, see Configure Send Connector Properties.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from one of the security principals that's 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's 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 2010 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 message 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 Understanding the Pickup and Replay Directories.
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 isn't applied to incoming messages for delivery to mailbox recipients. For more information about the store driver, see Understanding Transport Pipeline.
DSN messages Header firewall for routing headers is always applied to the original message or the original message header that's 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 isn't applied to messages that are submitted by the Replay directory, the Drop directory, or agents.
Return to top
Header Firewall and Earlier Versions of Exchange
Exchange 2003 and earlier versions of Exchange don't use the organization X-headers or forest X-headers. Exchange 2010 treats versions of Exchange earlier than Exchange 2007 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. 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 that exist in the Exchange organization.
Earlier versions of Exchange 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 (BLOB). The Exch50 BLOB is a collection of binary data that's stored as a single object. Exch50 contains data such as the SCL, address rewriting information, and other MAPI properties that don't 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 doesn't have Exchange installed. For more information, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence.
Routing group connectors between servers that have Exchange 2010 or Exchange 2003 installed are automatically configured to support sending and receiving Exch50 data. Send connectors and Receive connectors have permissions that enable the Exch50 command.
The following table describes the permissions that allow the Exch50 command on a Receive connector for inbound messages. If one of these permissions isn't granted, and a message is sent that contains the Exch50 command, the server accepts the message, but doesn't include the Exch50 command.
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 |
|
ExchangeServers |
|
Ms-Exch-Accept-Exch50 |
Exchange Legacy Interop universal security group |
ExchangeLegacyServers |
|
If you want to block the Exch50 command in a custom Receive connector scenario, use the any of following methods:
Create a 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 Create an SMTP Receive Connector.Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties.
Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Exch50 permission from a security principal that's 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-Exch50 permission to a security principal that's configured on the Receive connector. For more information, see Add-ADPermission.
The following table describes the permission that allows the Exch50 command on a Send connector for outbound messages. If this permission isn't granted and a message is sent that contains the Exch50 command, the server sends the message, but doesn't include the Exch50 command.
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 |
|
|
If you want to block the Exch50 command in a custom Send connector scenario, you can use the any of following methods:
Create a 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 Create an SMTP 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's 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's configured on the Send connector. For more information, see Add-ADPermission.
Return to top
© 2010 Microsoft Corporation. All rights reserved.