Understanding Address Rewriting
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
In Microsoft Exchange Server 2010, address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange 2010 organization.
Looking for management tasks related to managing transport servers? See Managing Transport Servers.
Contents
Why Use Address Rewriting
Address Rewriting Scenarios
SMTP Message Headers
What Address Rewriting Agents Don't Rewrite
Considerations for Use of Outbound-Only Address Rewriting
Considerations for Bidirectional Address Rewriting
Considerations for Rewriting Addresses in Multiple Domains
Prioritization of Address Rewriting Entries
Digitally Signed, Encrypted, and Rights-Protected Messages
Why Use Address Rewriting?
You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2010 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 2010 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.
Return to top
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 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's 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're 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, rewritten, and then 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.
Return to top
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. The following table shows which SMTP header fields are rewritten on outbound and inbound messages.
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 |
Return to top
What Address Rewriting Agents Don't Rewrite
Address Rewriting agents don't 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 aren't 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 don't rewrite header fields within e-mail messages that contain domains for which the Hub Transport server isn't authoritative. Rewriting such domains causes an uncontrollable form of message relay.
Address Rewriting agents also don't 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 don't trigger transport rules that are implemented between the sender and recipient.
Return to top
Considerations for Use of Outbound-Only Address Rewriting
When an e-mail message is outbound from the Exchange 2010 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 ed@sales.contoso.com and ed@research.contoso.com are included in a rule to rewrite all addresses to contoso.com, the Address Rewriting agent will rewrite both addresses to ed@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 can't affect the user name or display name part of the address.
Only literal strings are supported.
Return to top
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.
Return to top
Considerations for Rewriting Addresses in Multiple Domains
Before you create an address rewrite entry that rewrites multiple domains, you must prepare your subdomains. Also, before you perform the procedure for creating an address rewrite entry for multiple subdomains that's described in Create an Address Rewrite Entry, you must understand the requirements for rewriting e-mail addresses in multiple domains to a single domain, and the appropriate preconfiguration for the affected mailboxes and contacts.
Important Considerations
When you flatten internal subdomains into a single external domain, you must consider the following factors, which apply only when multiple subdomains are being rewritten:
Unique aliases are required All e-mail aliases, the part of the e-mail address to the left of the at (@) sign, must be unique across all subdomains. For example, if there is a joe@sales.contoso.com, there can't be a joe@marketing.contoso.com.
Proxy addresses are required A proxy address that matches the e-mail address that's produced by the Address Rewriting agent must be configured on every e-mail account that's in the subdomains that are rewritten. For example, if joe@sales.contoso.com is rewritten to joe@contoso.com, the e-mail address joe@contoso.com must be added as a proxy address to Joe's mailbox.
Contacts may be required If you're rewriting e-mail from a non-Exchange 2010 e-mail system, you must create Active Directory mail-enabled contacts for each e-mail address in the non-Exchange 2010 e-mail address that's being rewritten. This mail-enabled contact must contain the original e-mail address and the rewritten e-mail address. For example, if joe@unix.contoso.com is rewritten to joe@contoso.com, you must create a mail-enabled contact in Active Directory with joe@unix.contoso.com as the target SMTP address and joe@contoso.com as the proxy SMTP address.
These factors are important because rewriting addresses in multiple subdomains causes a many-to-one relationship between internal subdomains and the externally visible domain. Because of this many-to-one relationship, the Address Rewriting agent can't determine which subdomain contains the correct recipient when a message that's addressed to the externally visible domain is received.
Important
Make sure that every e-mail alias that exists across all subdomains is unique. Exchange 2010 doesn't check to verify that every e-mail alias that can be rewritten to a single domain is unique.
Removing Conflicting E-Mail Addresses
To create an address rewrite entry that rewrites multiple subdomains, you must first make sure that all e-mail aliases are unique across all your subdomains. For example, consider the following configuration:
The following users are in the subdomains sales.contoso.com, marketing.contoso.com and research.contoso.com:
maria@sales.contoso.com
chris@sales.contoso.com
david@marketing.contoso.com
brian@marketing.contoso.com
chris@research.contoso.com
adam@research.contoso.com
Each subdomain has two users, and each user has a unique e-mail address. However, you want to rewrite the subdomains sales.contoso.com, marketing.contoso.com, and research.contoso.com into a single domain that's called contoso.com. The following table shows each original e-mail address and its corresponding rewritten e-mail address.
Original e-mail addresses and corresponding rewritten e-mail addresses
| Original e-mail address | Rewritten e-mail address |
|---|---|
maria@sales.contoso.com |
maria@contoso.com |
chris@sales.contoso.com |
chris@contoso.com |
david@marketing.contoso.com |
david@contoso.com |
brian@marketing.contoso.com |
brian@contoso.com |
chris@research.contoso.com |
chris@contoso.com |
adam@research.contoso.com |
adam@contoso.com |
When the e-mail addresses in each subdomain are rewritten, a conflict occurs between chris@sales.contoso.com and chris@research.contoso.com. Therefore, both e-mail addresses are rewritten to chris@contoso.com. To resolve this situation, you must change the e-mail address of one of the recipient mailboxes to an address that doesn't conflict with the e-mail address in any other subdomain.
Applying Proxy Addresses to Recipient Mailboxes
For internal recipient mailboxes to receive replies to addresses that have been rewritten, you must configure those recipient mailboxes by using a proxy address that matches the rewritten external address.
For example, if a mailbox exists for adam@research.contoso.com, and the rewritten external address is adam@contoso.com, the mailbox must be configured by using a proxy address that's set to adam@contoso.com.
Return to top
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 An example is mapping john@contoso.com to support@contoso.com.
Specific domain or subdomain mapping An example is mapping Contoso.com to Northwindtraders.com or Sales.contoso.com to Contoso.com.
Domain flattening An example is 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.jpIf 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.
Return to top
Digitally Signed, Encrypted, and Rights-Protected Messages
Address rewriting shouldn't 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 isn't applied.
Addresses and information in the following message sections can be rewritten, because information in these sections isn't part of message signing, encryption, or rights protection:
SMTP envelope fields
Top-level message body headers
Addresses and information in the following message sections isn't rewritten because information in these sections is part of message signing, encryption, or rights protection:
Headers located inside MIME body parts that may be signed
The boundary string parameter of the MIME content type
Return to top
© 2010 Microsoft Corporation. All rights reserved.