Applications Server

Exchange Server 2010 : Edge Transport and Messaging Security (part 2) - Edge Transport Configurations

10/24/2010 3:34:15 PM

3. Edge Transport Configurations

This section describes Edge Transport configurations that you should consider when planning for this server role: cloned configuration, delivery status notifications, header firewall, and address rewriting.

3.1. Edge Transport Cloned Configuration

Cloned configuration is the process of configuring multiple Edge Transport servers with identical configurations. You can use the cloned configuration scripts provided as part of the Exchange installation kit with EMS to duplicate the configuration of a source server to a target server.

Edge Transport servers do not support Windows Failover Clustering. A failover cluster provides high availability by making application software and data available on several servers that are linked together in a cluster configuration. But because failover clustering is not available, to achieve high availability for messaging transport, you should implement multiple Edge Transport servers.

Note: Even though AD LDS supports directory replication, Exchange Server 2010 does not provide an option to use directory replication for configuring multiple Edge Transport servers. The only way to copy the configuration between the Edge Transport servers is to use cloned configuration. This needs to be done whenever you do any configuration changes to one of the servers.

You can use cloned configuration to ensure that all the Edge Transport servers have the same configuration. You only configure one server, and export the configuration to an XML file that is then imported to the target servers.

The XML file includes the following configuration information:

  • Transport server file paths and all log files paths (such as the Message Tracking log path)

  • Transport agents, including status and priority

  • All Send and Receive connector–related settings (including Send connector passwords encrypted with a default encryption key)

  • Accepted Domain information

  • Anti-spam features and configuration settings

Note: Don't forget that any Transport Rule configured on the Edge Transport server is not exported, so you need to export the rules with the Export-TransportRuleCollection cmdlet and import them on the target Edge Transport servers.

Some settings are not cloned; however, they are synchronized by EdgeSync and therefore only need to be considered in a configuration where EdgeSync is not used:

  • TLSReceiveDomainSecureList

  • TLSSendDomainSecureList

  • InternalSMTPServers

To configure cloned configuration, use the ExportEdgeConfig.ps1 and ImportEdgeConfig .ps1 scripts located in the <Exchange_Install_Path>\Scripts folder to export configuration information from one Edge Transport server to an identically configured Edge Transport server. You can also use the tool to test configuration changes and offer rollback assistance or to assist in disaster recovery when you deploy a new Edge Transport server or replace a failed server.

To configure cloned configuration, follow these steps:

  1. Use the ExportEdgeConfig.ps1 script to export the configuration information on the source Edge Transport server.

  2. Validate configuration and create an answer file using the ImportEdgeConfig.ps1 script on the target Edge Transport server. The answer file will contain entries for every source server setting that is not valid for the target server.

  3. Edit answer file and change all server-specific settings, such as the server name, to reflect the target server settings.

  4. Import configuration using the ImportEdgeConfig.ps1 script with the -IsImport $true parameter to import the information from both the intermediate XML file and the answer file on the target Edge Transport server.

    Note: When importing the configuration, depending if the target Edge Transport configuration is part of Edge Synchronization or not, you may face error messages that some settings, such as Accepted Domains, cannot be imported. This situation is normal and can be ignored.
  5. Delete the configuration and answer XML files to prevent retrieval of Send Connector passwords (if used).

3.2. Understanding Header Firewall

Every Receive or Send connector adds information to the message it is transferring. This information is available in the SMTP message header and includes information such as all the servers that transferred that message and at what time. To prevent spoofing of such information, Exchange 2010 includes a feature called Header Firewall that (if configured) removes all additional information from inbound and outbound messages. But let's first start with an overview of the X-header fields.

3.2.1. Overview of Exchange 2010 X-Headers

Exchange Server 2010 adds X-header fields to every message to transfer Exchange-internal information. X-header fields are an unofficial but generally accepted way to add header fields to a message.

The purpose of X-header fields is to transfer information about the message to the other Transport servers. For example, a message is scanned by the Content Filter agent only at the first Transport server, which adds the spam confidence level (SCL) rating to the X-MS-Exchange-Organization-SCL field to the header of the message. All subsequent Transport servers can then use this information and do not need to scan the message again. In Figure 4 you see a message that contains various X-header fields by looking at the Internet headers field in Microsoft Outlook.

Figure 4. Viewing X-headers in Outlook

To read the message headers correctly, it is important to understand their meaning. Exchange Server 2010 includes several X-header fields and they are listed in Table 2.

Table 2. X-Header Fields Used by Exchange 2010
X-MS-Exchange-Forest-RulesExecutedLists all transport rules that processed this message.
X-MS-Exchange-Organization-Antispam-ReportProvides a summary report of the anti-spam filter results that have been applied to the message by the Content Filter agent. Detailed information can be found on TechNet "Understanding Anti-Spam Stamps" at
X-MS-Exchange-Organization-AuthAsSpecifies the authentication source. The possible values are Anonymous, Internal, External, or Partner.
X-MS-Exchange-Organization-AuthDomainThis field is only added when Domain Secure authentication took place and includes the fully qualified domain name (FQDN) of the remote authenticated domain.
X-MS-Exchange-Organization-AuthMechanismSpecifies the authentication mechanism for the submission of the message as a two-digit hexadecimal number.
X-MS-Exchange-Organization-AuthSourceSpecifies the FQDN of the server computer that evaluated the authentication of the message on behalf of the organization.
X-MS-Exchange-Organization-Journal-ReportIdentifies journal reports in transport.
X-MS-Exchange-Organization-OriginalArrivalTimeIdentifies the time when the message first entered the Exchange organization.
X-MS-Exchange-Organization-Original-SenderIncludes the original sender of a quarantined message.
X-MS-Exchange-Organization-OriginalSizeIncludes the original size of a quarantined message.
X-MS-Exchange-Organization-Original-SCLIncludes the original SCL of a quarantined message.
X-MS-Exchange- Organization-PCLIdentifies the phishing confidence level. The possible phishing confidence level values are 1 through 8.
X-MS-Exchange-Organization-QuarantineIndicates 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.
X-MS-Exchange- Organization-SCLIncludes the SCL of the message. The possible SCL values are 0 through 9. A larger value indicates a suspicious message. The special value -1 means that it is an internal message that is not processed by the Content Filter agent.
X-MS-Exchange-Organization-SenderIdResultIncludes 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 used in the sender's e-mail address.
X-MS-Exchange- Organization-PRDIncludes the result of the Sender ID agent, especially the Purported Responsible Domain (PRD). This is the domain of the purported responsible address as determined by the Sender ID agent.

Besides X-header fields, Header Firewall also controls Routing headers. Routing headers include information about all messaging servers used to deliver the message.

3.2.2. Configuring Header Firewall

In some situations you need to implement Header Firewall to prevent someone from creating a message that will spoof X-headers and thereby imitate an Exchange Transport server in order to have their messages accepted as legitimate by the receiving server. This is especially crucial if your organization does not include a smart host that removes these headers.

Header Firewalls are configured by assigning Active Directory permissions on the respective Send connector or Receive connector. A dedicated ExtendedRightDeny permission is used to control enabling or disabling a Header Firewall. The following principle applies: attribute and

  • If Deny is enabled (or True), the Header Firewall is turned on for the specified area and headers are removed.

  • If Deny is disabled (or False), the Header Firewall is turned off and the headers are preserved by the connector.

By default, no Send or Receive connector is configured for Header Firewall. In a situation where you use an Edge Transport server, the X-header is overwritten anyway when a message enters the organization. But for outbound messages, Routing headers might disclose too much information about your company. For example, the name of any internal Hub Transport server that processes the message is shown in the Routing header.

Several Extended Rights control Header Firewalls on Send connectors and Receive connectors. Table 3 provides an overview of possible Extended Rights.

Table 3. Connectors and Extended Rights for X-Header Configuration
Receive connectorms-Exch-Accept-Headers-ForestConfigures Header Firewall on "X-MS-Exchange-Forest …" headers

ms-Exch-Accept-Headers-OrganizationConfigures Header Firewall on "X-MS-Exchange-Organization …" headers

Ms-Exch-Accept-Headers-RoutingConfigures Header Firewall on "Resent- …" and "Received:" headers
Send connectorMs-Exch-Send-Headers-ForestConfigures Header Firewall on "X-MS-Exchange-Forest …" headers

Ms-Exch-Send-Headers-OrganizationConfigures Header Firewall on "X-MS-Exchange-Organization …" headers

Ms-Exch-Send-Headers-RoutingConfigures Header Firewall on "Resent- …" and "Received:" headers

To configure Header Firewalls, you can either use EMS or directly access the Permissions tab of the connector's Advanced Security Settings using ADSIEdit, as shown in Figure 5. You can see Advanced Security Settings of the Send connector on the Edge Transport server that connects to the Internet. Because Deny is set for Anonymous Logon on Send Routing Headers permission, all internal message servers are removed from the routing path.

Figure 5. Configuring Header Firewall using ADSIEdit

When using ADSIEdit in Active Directory to configure permissions, remember that you can configure Edge Transport Receive connectors only directly on the Edge Transport server. Thus you can only configure Send connectors using ADSIEdit in Active Directory, for configuring Edge Transport Receive connectors you need to use EMS on the Edge Transport directly, as Receive connectors are not synchronized to Active Directory with EdgeSync.

Configuring Header Firewall using EMS is not trivial—many groups are involved and you have to configure the right group to turn Header Firewall on or off. The best approach is to look at your existing connectors to identify the groups you need to configure. The following cmdlet is an example to show you the Extended Rights of a Receive connector:

Get-ReceiveConnector <ReceiveConnectorName> | Get-ADPermission | ft user, deny,

To configure Header Firewall in your scenario you just need to change the permissions on the respective Receive or Send connector. For example, let's turn on Header Firewall for Routing headers on the Send connector to the Internet for all non-authenticated target servers. You can configure this using the following cmdlet on the Send connector that sends messages to the Internet:

Add-ADPermission -id "<SendConnectorName>" -User "NT Authority\Anonymous
Logon" -ExtendedRights Ms-Exch-Send-Headers-Routing -Deny

Remember that after you configure the permissions, you need to restart the Microsoft Exchange Transport service on all Hub Transport servers that are configured to use the Send connector so that Header Firewall will take immediate effect.

You can verify whether Header Firewall is turned on by enabling verbose logging on the Receive connector in EMC or using the ProtocolLoggingLevel VerboseSet-ReceiveConnector cmdlet. You will now receive a detailed protocol log in the <Exchange_Install_Path>\TransportRoles\Logs\ProtocolLog\SMTPReceive folder. In the current log file, you will find the following entries for each SMTP session that has Header Firewall turned off: parameter in the

  • AcceptRoutingHeaders

  • AcceptForestHeaders

  • AcceptOrganizationHeaders

For every entry that's missing, Header Firewall is enabled!

Notes From The Field: Make Sure Edge and Hub Authenticate Correctly

Christian Schindler

Senior Consultant, NTx BackOffice Consulting Group, Austria

One of my customers once had an issue where inbound mail delivery from Edge Transport to Hub Transport was working correctly, but anti-spam—although correctly configured—didn't work as expected: X-AntiSpam- and Antivirus-Headers (SCL, SenderID, and so on) weren't part of the message header when the message reached Outlook.

After digging into the issue, I finally discovered that authentication methods between the Edge and Hub Transport server were modified from the default settings. I re-enabled Exchange Server authentication on the connectors, which fixed the issue.

So why is authentication between Edge and Hub Transport important in my scenario? Because Exchange only accepts X-AntiSpam- and AntiVirus-Headers through authenticated SMTP Sessions. This makes it nearly impossible for spammers or hackers to send fake X-AntiSpam or X-Antivirus Headers.

3.2.3. Header Firewall for Contoso Scenario

For most scenarios, especially if you use Edge Transport servers, you do not need to change Header Firewall settings—their default configuration is sufficient for most scenarios. However, if you do not use Edge Transport servers, you should enable Header Firewall for the Receive connector and Send connector to the Internet.

In the Contoso scenario, the Hub Transport server receives messages from a smart host from the Internet. To prevent spoofing of X-headers it is best practice to configure your Receive connector that receives the messages from the Internet to enable Header Firewall. This is done using the following cmdlet:

Add-ADPermission -id <ReceiveConnectorName> -User "NT Authority\Anonymous Logon"
-ExtendedRights ms-Exch-Accept-Headers-Organization -Deny

Figure 6 shows you the header configuration as performed through EMS for X-headers Organization and the command to verify that the permission was configured correctly. As seen in the figure, only the ms-Exch-Accept-Headers-Organization has a Deny permission configured; thus only this X-header has Header Firewall turned on.

Figure 6. Configuring Header Firewall configuration in EMS

3.3. Configure Address Rewriting

Edge Transport servers include Transport agents that allow you to modify e-mail addresses for inbound or outbound messages. This process is called address rewriting.

Two Transport agents provide the capability for address rewriting: Address Rewriting Inbound agent and Address Rewriting Outbound agent. They should be enabled for address rewriting to work correctly.

But why do address rewriting? You need to implement it for several reasons, including the following:

  • Group consolidation or Partners This is when your company includes several groups that have separate e-mail addresses internally. For example, you have a group that uses the e-mail address but your company wants to move to a single e-mail address and thus replace all messages with the originator of @sales with

  • Mergers and acquisitions This situation occurs when your company purchases a new company that is running in a separate messaging system. For this situation all messages get rewritten to a common e-mail address. For example, Fabrikam purchases Contoso, and because they should use the Fabrikam e-mail address, they rewrite every address into

Note: Address rewriting will replace the e-mail addresses of messages. You have to make sure that the properties of the recipient mailboxes include the replaced e-mail address in their proxy addresses; otherwise a reply will receive an NDR.

In some situations—for example, signed, encrypted, or rights-protected messages—you cannot change an e-mail address because that would, for example, make a signed message invalid. The address rewriting agent thus will not change the message in any way as it would make the message unreadable.

Note: Using address rewriting can break your federating calendaring requests because the domain name is changed. If you use address rewriting and you want to implement federated sharing, ensure that all domains involved in the address rewriting are defined in your federated organization identifier.

Address rewriting is configured using the Exchange Management Shell (EMS); you cannot configure address rewriting in the Exchange Management Console.

You configure address rewriting using the New-AddressRewriteEnty cmdlet. You can configure address rewriting in the following ways:

  • Rewrite a single e-mail address, one domain, or a domain including all its subdomains.

  • Rewrite addresses on either inbound and outbound messages or just outbound messages.

Let's go back to our scenario where Fabrikam buys Contoso. Contoso's Exchange organization is currently not your responsibility, but every message they sent to the Internet is transported over Fabrikam's Edge Transport servers. You want to make sure that every outbound e-mail address is replaced with So first you have to make sure that every Contoso recipient exists in the Fabrikam Exchange organization with an e-mail address that matches both their and the address. Additionally there must be a Send connector to forward messages for Contoso users (addressed with their mail address) to the Contoso Exchange organization.

If that's guaranteed, you can use the following cmdlet on your Edge Transport servers to enable address rewriting:

New-AddressRewriteEntry -Name "Contoso to Fabrikam" -InternalAddress
-ExternalAddress -OutboundOnly $true
Other -----------------
- Exchange Mailbox Services Architecture
- Message Routing in Exchange 2010 (part 4) - Planning and Configuring Your SMTP Namespace
- Message Routing in Exchange 2010 (part 3) - Planning Message Routing to the Organization Perimeter
- Message Routing in Exchange 2010 (part 2) - Reviewing and Configuring Message Routing Between Active Directory Sites
- Message Routing in Exchange 2010 (part 1) - Message Routing within an Exchange Organization
- Exchange 2010 : Understanding Transport Agents
- Exchange Transport Server Architecture (part 2)
- Exchange Transport Server Architecture (part 1)
- Client Access Server Architecture in Exchange 2010 (part 4)
- Client Access Server Architecture in Exchange 2010 (part 3)
- Client Access Server Architecture in Exchange 2010 (part 2)
- Client Access Server Architecture in Exchange 2010 (part 1) - Client Access Server Architecture
- Exchange Server 2010 Mailbox Services Configuration (part 5) - Configuring Public Folders
- Exchange Server 2010 Mailbox Services Configuration (part 4) - Client Configuration
- Exchange Server 2010 Mailbox Services Configuration (part 3)
- Exchange Server 2010 Mailbox Services Configuration (part 2) - Database Maintenance
- Exchange Server 2010 Mailbox Services Configuration (part 1)
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
Most View
- Windows Server 2008: Using the Task Manager for Logging and Debugging (part 1)
- .NET Components : Serialization and Class Hierarchies (part 2) - Manual Base-Class Serialization
- SharePoint 2010 : Discard the Check-out of a Page
- SQL Server 2008 : Implementing Transactions - Transaction Traps
- sharepoint 2007 : Search in WSS
- Microsoft Dynamic GP 2010 : Payables Management (part 1) - Payables Management Setup
- SQL Server 2008 : Managing Remote Servers
- Service Management API (part 1)
- Overview of Process Management in Microsoft Visio 2010 (part 3) - Validation of process diagrams
- Windows 8 : Applications - The Run Dialog Box, Closing a Program
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS