Planning for Address Rewriting

Article
01/23/2017

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

In Microsoft Exchange Server 2007, address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange 2007 organization.

Why Use Address Rewriting?

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2007 organization. Address rewriting can be valuable to organizations that use third-party vendors to provide e-mail support and services. Customers and partners expect e-mail messages to come from the organization, not a third-party vendor. Similarly, after a merger or acquisition, an organization might want all e-mail messages to appear to come from the single new organization. The address rewriting feature frees organizations to structure their businesses by business requirements instead of by technical requirements or limitations.

You can also use address rewriting to enable appropriate routing of inbound messages from outside your Exchange 2007 organization to internal recipients. Address rewriting enables replies to messages that were rewritten to be correctly routed to the original sender of the rewritten message.

You configure Address Rewriting agents on the Receive connector and Send connector on a computer that has the Edge Transport server role installed.

Address Rewriting Scenarios

The following scenarios are examples of how address rewriting can benefit organizations:

Group consolidation Some organizations segment their internal businesses into separate domains that are based on business or technical requirements. However, this configuration can cause e-mail messages to appear as if they come from separate groups or even separate organizations. This appearance might not be desirable to the organization.

The following example shows how an organization, Contoso, Ltd., could hide its subdomains:
- Outbound messages from the Northamerica.contoso.com, Europe.contoso.com, and Asia.contoso.com domains are rewritten to appear as if they all originate from a single Contoso.com domain. All messages are rewritten as they pass through Edge Transport servers that provide Simple Mail Transfer Protocol (SMTP) connectivity between the whole organization and the Internet.
- Inbound messages to the Contoso.com domain are passed on by the Edge Transport server to the Hub Transport server role, which then determines the correct recipient. For example, messages to chris@contoso.com are sent to an internal Hub Transport server, which then determines the correct mailbox to send the message to by using the proxy address that is configured on the recipient's e-mail account.
Mergers and acquisitions When organizations merge or are acquired, their technology infrastructure must be modified to match new business and technical requirements. An acquired company may continue to run as a separate business unit, but the e-mail administrator can use address rewriting to make the two organizations appear as if they are one integrated organization.

The following example shows how Contoso, Ltd. could hide the e-mail domain of the newly acquired company, Fourth Coffee:
- Contoso, Ltd. wants all outbound messages from Fourth Coffee's Exchange organization to appear as if they originate from Contoso.com. All messages from both organizations are sent through the Edge Transport servers at Contoso, Ltd., where e-mail messages are rewritten from someone@fourthcoffee.com to someone@contoso.com.
- Inbound messages to adam@contoso.com are rewritten and routed to his adam@fourthcoffee.com e-mail account. Incoming messages that use his old adam@fourthcoffee.com domain are also accepted, because the domain still exists. Inbound replies to e-mail messages that were rewritten are handled by the Edge Transport servers at Contoso, Ltd., where the Address Rewriting agent rewrites the recipient address so that replies are correctly routed to the appropriate Fourthcoffee.com e-mail address. Replies to e-mail messages that were sent before the merger to Fourthcoffee.com e-mail addresses are routed directly to Fourth Coffee's e-mail servers.
Partners Many organizations use external partners to provide services for their customers, other partners, or the organization itself. To avoid confusion, the organization might replace the e-mail domain of the partner organization with its own e-mail domain.

The following example shows how Contoso, Ltd. could hide a partner's e-mail domain:
- Contoso, Ltd. provides support for the larger Wingtip Toys organization. Wingtip Toys wants a unified experience for its customers and requires all messages that originate from support personnel at Contoso, Ltd. to appear as if they were sent from Wingtip Toys. All outbound messages that relate to Wingtip Toys are sent through their Edge Transport servers, and all Contoso.com addresses are rewritten to appear as Wingtiptoys.com addresses.
- Inbound messages for support@wingtiptoys.com are accepted by Wingtip Toy's Edge Transport servers, are rewritten, and then are routed to the support@contoso.com e-mail address.
Warning

So that inbound e-mail is appropriately mapped and routed, you must make sure that the user name part of the address is unique across all e-mail organizations that may be affected by address rewriting.

SMTP Message Headers

Address Rewriting agents rewrite e-mail addresses by rewriting the SMTP headers on e-mail messages that are sent and received by an Edge Transport server. Address Rewriting agents typically rewrite outbound messages because the organization wants to hide the internal domains and subdomains as effectively as possible and present a single external domain to the Internet. Address Rewriting agents typically rewrite inbound messages to route those messages to their intended recipients. For these reasons, Address Rewriting agents rewrite several SMTP header fields on outbound e-mail messages. Address Rewriting agents rewrite only one SMTP header field on inbound e-mail messages. Table 1 shows which SMTP header fields are rewritten on outbound and inbound messages.

Table 1 SMTP header fields rewritten on outbound and inbound messages

SMTP header field	Outbound	Inbound
Envelope From (MAIL FROM)	Rewritten	Not rewritten
Envelope To (RCPT TO)	Not rewritten	Rewritten
Body To	Rewritten	Not rewritten
Body Cc	Rewritten	Not rewritten
Body From	Rewritten	Not rewritten
Body Sender	Rewritten	Not rewritten
Body Reply-To	Rewritten	Not rewritten
Body Return-Receipt-To	Rewritten	Not rewritten
Body Disposition-Notification-To	Rewritten	Not rewritten
Body Resent-From	Rewritten	Not rewritten
Body Resent-Sender	Rewritten	Not rewritten

What Address Rewriting Agents Will Not Rewrite

Address Rewriting agents do not rewrite several SMTP header fields, because address rewriting would break SMTP functionality. For example, changing these SMTP headers could affect message loop detection, invalidate the signature, or make a rights-protected message unreadable. The following SMTP header fields are not modified by the Address Rewriting agents:

Return-Path
Received
Message-ID
X-MS-TNEF-Correlator
Content-Type Boundary=string
Headers located inside MIME body parts

Address Rewriting agents also do not rewrite header fields within e-mail messages that contain domains for which the Hub Transport server is not authoritative. Rewriting such domains causes an uncontrollable form of message relay.

Address Rewriting agents also do not modify the header fields of messages that are embedded in another message. Senders and recipients expect embedded messages to remain intact and be delivered without modification, as long as the messages do not trigger transport rules that are implemented between the sender and recipient.

Important

Meeting requests that are sent to remote domains that do not support TNEF are sent as iCalendar attachments. Because address rewriting agents do not modify the header fields of embedded messages, the addresses on these meeting requests will not be modified.

Considerations for Use of Outbound-Only Address Rewriting

When an e-mail message is outbound from the Exchange 2007 organization, outbound-only address rewriting involves modification of the sender SMTP address only. The Address Rewriting agent is configured only on the Send connector on the Edge Transport server. The following list shows the conditions that are required to configure an outbound-only Address Rewriting agent:

The resulting addresses must be unique across the organization. For example, if the unique e-mail addresses ted@sales.contoso.com and ted@research.contoso.com are included in a rule to rewrite all addresses to contoso.com, the Address Rewriting agent will rewrite both addresses to ted@contoso.com and will cause a conflict.
A proxy address must be configured on each mailbox that matches the rewritten e-mail address. This enables those mailboxes to receive replies to e-mail messages in which headers are rewritten.
When you use wildcard characters, there must be a period between the wildcard character and the domain name.
You can use wildcard characters only in the internal domain.
No characters can be in front of the wildcard character.
Outbound-only address rewriting cannot affect the user name or display name part of the address.
Only literal strings are supported.

Considerations for Bidirectional Address Rewriting

Bidirectional address rewriting modifies the sender SMTP address on e-mail messages that are leaving the Exchange organization and the recipient SMTP address on e-mail messages that are entering the Exchange organization. To do this, you configure the Address Rewriting agent on both the Send connector and Receive connector on the Edge Transport server.

The following list shows the conditions that are required when you create a bidirectional Address Rewriting agent:

You can't use wildcard characters.
You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For example, the internal address is chris@contoso.com, and the external address is support@contoso.com.
Only literal strings are supported.
The address must be unique across the organization. For example, if an e-mail address, bob@contoso.com, already exists, mapping robert@fourthcoffee.com to bob@contoso.com will cause replies to messages from bob@contoso.com to be delivered to the wrong person.

Prioritization of Address Rewriting Entries

The rule that best matches the internal and external domain pair is applied. The following prioritization is the exact order of address rewriting entries from highest priority to lowest priority:

Individual e-mail addresses For example, mapping john@contoso.com to support@contoso.com.
Specific domain or subdomain mapping For example, mapping Contoso.com to Northwindtraders.com or Sales.contoso.com to Contoso.com.
Domain flattening For example, flattening *.contoso.com into Contoso.com. For example, the following two rules are configured on the Edge Transport server:
```
*.contoso.com maps to Contoso.com
Japan.sales.contoso.com maps to Contoso.jp
```
If masato@japan.sales.contoso.com sends an e-mail message, the address is rewritten as masato@contoso.jp, because that rule most closely matches the sender's internal domain, even though the *.contoso.com rule is present.

Digitally Signed, Encrypted, and Rights-Protected Messages

Address rewriting should not affect most signed, encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an encrypted or rights-protected message unreadable, or otherwise change the security status of such messages in any way, address rewriting is not applied.

Addresses and information in the following message sections can be rewritten, because information in these sections is not part of message signing, encryption, or rights protection:

SMTP envelope fields
Top-level message body headers

Addresses and information in the following message sections is not rewritten because information in these sections is part of message signing, encryption, or rights protection:

Headers that are located inside MIME body parts that may be signed
The boundary string parameter of the MIME content type

For More Information

For more information about address rewriting, see the following topics:

Share via