Configuring Cross-Forest SMTP Mail Collaboration

Article
07/25/2014

To prevent spoofing (that is, forging identities), Exchange 2003 requires authentication before a sender's name is resolved to its display name in the global address list (GAL). Therefore, in an organization that spans two forests, a user who sends mail from one forest to another forest is not authenticated. Furthermore, the user's name is not resolved to a display name in the GAL, even if the user exists as a contact in the destination forest.

To enable cross-forest mail collaboration in Exchange 2003, additional configuration steps are required to resolve contacts outside your organization to their display names in Active Directory. You have two options to enable the resolution of these contacts:

Option 1 (recommended) Use authentication so that users who send mail from one forest to another are authenticated users, and their names are resolved to their display names in the GAL.
Option 2 Restrict access to the SMTP virtual server that is used for cross-forest collaboration, and then configure Exchange to resolve anonymous e-mail. This configuration is supported, but it is not recommended. By default, in this configuration, the Exch50 message properties, which are the extended properties of a message, are not persisted when mail is sent from one forest to another.

To understand the benefits of configuring cross-forest mail collaboration, consider the following scenarios of anonymous mail submission and cross-forest authenticated mail submission.

Scenario: Anonymous Mail Submission

E-mail addresses are not resolved if the submission is anonymous. Therefore, when an anonymous user who attempts to spoof (forge) an internal user's identity sends mail, the return address does not resolve to its display name in the global address list (GAL).

For example, Kim Akers is a legitimate internal user at Contoso, Ltd. Her display name in the GAL is Kim Akers, and her e-mail address is kim@contoso.com.

To send mail, Kim must be authenticated. Because she is authenticated, the intended recipients of Kim's mail see that the sender is Kim Akers. In addition, the properties of Kim Akers are displayed as her GAL entry. However, if Ted Bremer attempts to forge Kim's address by using kim@contoso.com in the From line and then sending the mail to the Exchange 2003 server at Contoso, the e-mail address is not resolved to Kim's display name because Ted did not authenticate. Therefore, when this e-mail message is displayed in Microsoft Office Outlook®, the sender address appears as kim@contoso.com; it does not resolve to Kim Akers, as authenticated mail from Kim does.

Scenario: Cross-Forest Mail Delivery

Consider a company that spans two forests: the Adatum forest and the Fabrikam forest. Both these forests are single domain forests using the domains of adatum.com and fabrikam.com, respectively. To allow cross-forest mail collaboration, all users in the Adatum forest are represented as contacts in the Fabrikam forest's Active Directory. Likewise, all users in the Fabrikam forest are represented as contacts in Adatum forest's Active Directory.

If a user in the Adatum forest sends mail to the Fabrikam forest, and the mail is submitted over an anonymous connection, the sender's address is not resolved, despite the fact that the sender exists as a contact in the Active Directory and in the Outlook GAL. This is because a user in the Adatum forest is not an authenticated user in the Fabrikam forest.

For example, Ted Bremer is a mail user in the Adatum forest—his e-mail address is ted@adatum.com, and his Outlook GAL display name is Ted Bremer. Adam Barr is a user in the Fabrikam forest—his e-mail address is adam@fabrikam.com, and his Outlook GAL display name is Adam Barr. Because Adam is represented as an Active Directory contact in the Adatum forest, Ted can view Adam's e-mail address and resolve it to the display name of Adam Barr in the Outlook GAL. When Adam receives mail from Ted, Ted's address is not resolved; instead of seeing Ted's display name as it appears in the GAL, Adam sees his unresolved e-mail address of ted@adatum.com. Because Ted sent mail as an anonymous user, his e-mail address did not resolve. Although Ted is authenticated when sending mail, the connection between the two forests is not authenticated.

To ensure that senders in one forest can send mail to recipients in other forests and to ensure that their e-mail addresses resolve to their display names in the GAL, you should enable cross-forest mail collaboration. The following sections explain the two options that are available for configuring mail collaboration between two forests.

Enabling Cross-Forest Authentication

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from the other forest. By doing this, any mail that is sent between the two forests by an authenticated user resolves to the appropriate display name in the GAL. This section explains how to enable cross-forest authentication.

Using the example of the Adatum forest and the Fabrikam forest (see "Scenario: Cross-Forest Mail Delivery" earlier in this topic), perform the following steps to set up cross-forest authentication:

Create an account in the Fabrikam forest that has Send As permissions. (For all users in the Adatum forest, a contact exists in the Fabrikam forest as well; therefore, this account allows Adatum users to send authenticated mail.) Configure these permissions on all Exchange servers that will accept incoming mail from Adatum.
On an Exchange server in the Adatum forest, create a connector that requires authentication using this account to send outbound mail.

Similarly, to set up cross-forest authentication from the Fabrikam forest to the Adatum forest, repeat these steps, creating the account in Adatum and the connector in Fabrikam.

Step 1: Creating a User Account in the Destination Forest with Send As Permissions

Before you set up your connector in the connecting forest, you must create an account in the destination forest (the forest to which you are connecting) that has Send As permissions. Configure these permissions on all servers in the destination forest that will accept inbound connections from the connecting forest. The How to Create the Account Used for Cross-Forest Authentication procedure shows you how to set up an account in the Fabrikam forest, and the How to Configure a Connector and Require Authentication for Cross-Forest Authentication procedure shows you how to configure a connector in the Adatum forest, thereby allowing users in the Adatum forest to send mail to the Fabrikam forest with resolved e-mail addresses.

Step 2: Creating a Connector in the Connecting Forest

After creating the account with the proper permissions in the destination forest, create a connector in the connecting forest and require authentication using the account you just created. In the How to Configure a Connector and Require Authentication for Cross-Forest Authentication procedure, assume that you are creating a connector on an Exchange server in the Adatum forest that connects to the Fabrikam forest.

Enabling Cross-Forest Collaboration by Resolving Anonymous Mail

Another way you can configure Exchange to resolve contacts outside your organization to their display names in Active Directory is to configure Exchange to resolve anonymous e-mail. Assume that your company spans two forests, from the Adatum forest to the Fabrikam forest.

Important

Configuring Exchange servers to resolve anonymous mail submissions allows unscrupulous users to submit messages with a falsified return address. Recipients are unable to differentiate between authentic mail and spoofed mail. To minimize this possibility, ensure that you restrict access to the SMTP virtual server to the IP addresses of your Exchange servers.

Perform the steps below to resolve contacts for Adatum users to their display names in the Fabrikam forest. Each of these steps is explained in detail in the following sections:

Create a connector in the Adatum forest that connects to the Fabrikam forest.
On the receiving bridgehead server in the Fabrikam forest, restrict access to the SMTP virtual server by IP address. By doing this, you can ensure that only servers from the Adatum forest can send mail to this server.
On the SMTP virtual server that hosts the connector, enable the Resolve anonymous e-mail setting.
Change a registry key to ensure that the extended message properties (Exch50 properties) are persisted across the forests. Otherwise, you can lose important message information.

After you complete these steps, all users who send mail from the Adatum forest to the Fabrikam forest will resolve to their display names in the Fabrikam global address list (GAL). In a production environment, you would then repeat this process to configure the resolution of Fabrikam contacts in the Adatum forest.

Step 1: Creating a Connector in the Connecting Forest

First you must create a connector in the connecting forest. For detailed instructions, see "How to Create a Connector in a Connecting Forest" in What's New in Exchange Server 2003.

After you create the connector, Exchange Server will route all mail destined to fabrikam.com (the Fabrikam forest) through this connector.

Step 2: Restricting IP Addresses on the Receiving Bridgehead Server

After you create the connector in the Adatum forest (the connecting forest) you must restrict access to the receiving bridgehead server. You do this by allowing only the IP address of the connecting servers in the Adatum forest to send mail to the receiving bridgehead server in the Fabrikam forest.

For detailed instructions, see How to Restrict Access by IP Address on the Receiving Bridgehead Server.

Step 3: Resolving Anonymous Mail on the SMTP Virtual Server

After you have restricted access to the receiving bridgehead server, you must configure the SMTP virtual server on this bridgehead to resolve anonymous e-mail addresses.

For detailed instructions, see How to Configure an SMTP Virtual Server to Resolve Anonymous E-mail Addresses.

Step 4: Enabling Registry Key to Persist Message Properties Across Forests

As explained earlier, when messages are sent anonymously across forests, the extended message properties on a message are not transmitted. For single companies that implement a cross-forest scenario, these message properties must be transmitted because information about the message can be lost. For example, the SCL property, an extended Exchange property, contains a spam rating that is generated by third-party solutions. This property is not transmitted when mail is sent anonymously. So, if an anti-spam solution is deployed in the Adatum forest, and a message that is received in this forest is destined to a recipient in the Fabrikam forest, the anti-spam solution stamps the SCL property on the message. However, when the message is delivered to the Fabrikam forest, the extended property that contains the spam rating is not persisted.

To configure Exchange to accept the extended message properties, you can enable a registry key on the receiving bridgehead server or on the SMTP virtual server that resides on the bridgehead. Enabling the registry key on the Exchange server configures all SMTP virtual servers on the Exchange server to accept extended properties.

Configuring the Exchange Server to Accept Extended Message Properties on Anonymous Connections

Perform the How to Enable an Exchange Server to Accept Message Extended Properties that Are Sent Anonymously procedure to configure the Exchange server to accept extended properties on anonymous connections. If your Exchange server functions solely as the bridgehead server for cross-forest communication, you may want to configure this setting at the server level. If you have other SMTP virtual servers on this Exchange server, consider setting this registry key on the SMTP virtual server only.

Note

If you enable this registry key on an Exchange server, the setting applies to all SMTP virtual servers on the Exchange server. If you want to configure a single SMTP virtual server with this setting, enable the registry key on the SMTP virtual server.