Address rewriting was created by Microsoft
to allow an organization to have all outbound or inbound email appear
to be delivered from one domain when several mail-enabled domains could
be sending messages through the same systems. This allows a company to
provide a consistent appearance when communicating via email. Address
rewriting is commonly used on outbound email when companies merge with
or acquire other organizations. Address rewriting is also used on
outbound email when an organization’s network contains several other
domains. Using address rewriting in these scenarios results in
external recipients seeing email as originating from one domain name
even if it is coming from a domain with a completely different name.
Note
If
you enable address rewriting on external messages, ensure you have
enabled address rewriting on inbound messages as well, so that inbound
messages will be delivered to the appropriate recipients.
Configuring Address Rewriting
As
with many of the components for the Edge Transport server, address
rewriting is enabled on inbound email messages so messages that were
rewritten when sent externally can be routed back to the appropriate
person. Address rewriting can also be beneficial when sending email
between internal systems. For example, if an IT department has multiple
domains and the organization wants all email communication from the IT
department to internal departments (other than IT) to come from *@it.companyabc.com, then address rewriting would be used to accomplish this.
Note
Using
address rewriting on your outbound email messages eases white-listing
of your organization’s email for external recipients and business
partners by simplifying the answer to their question “What domain and
systems can we expect to receive email from?”
Note
Changes
described in this section are applied only to the local system. This is
important if you have more than one Edge Transport server in your
environment.
Some
considerations to take into account when using address rewriting are
items that will not be rewritten, end result of email addresses being
combined, messages that have been secured, and rewriting in both
directions.
Address rewriting will not
modify messages that are attached to the message being rewritten and
also will not modify the SMTP Return-Path, Received, Message-ID,
X-MS-TNEF-Correlator, Content-Type Boundary=string headers, and headers
located inside of MIME body parts. Message-ID, X-MS-TNEF-Correlator,
Content-Type Boundary=string headers, and headers located inside of
MIME body parts are used when securing email messages such as with
encryption or Microsoft Rights Management and are, therefore, not
rewritten purposely to ensure the message isn’t modified to ensure
delivery and integrity of the content.
To
ensure messages (mainly responses to rewritten messages) get routed to
the appropriate person, a few items need to be addressed. First, the
end result of the email address must be unique between users so
conflicts and incorrect delivery of messages does not occur; second, a
proxy address must be configured on the mailbox that matches the
rewritten address; and third, address rewriting must be configured on
both the Send and Receive Connectors of the Edge Transport server.
To
ensure the rewritten email address between domains will remain unique
to the user, take into account how each domain creates their usernames.
For example, domains that allow simple usernames like Heather@, Reese@, or support@ will have more conflicts when using address rewriting than organizations that use more unique or defined usernames like Heather_Loso@, RMChimner@, or online-sales-support@.
If two domains used simple usernames in their email addresses and the
organization wanted to use address rewriting, the end result could
contain too many conflicts presenting the need to change email
addresses at least in one domain. This could end up being quite an
involved task depending on the number of users in each domain. For
example, CompanyABC.com wants to have all email from domains like infosec.companyabc.com, it.companyabc.com, and development.companyabc.com leave the organization as companyabc.com. If two different users named Mike have the same email prefix (mike) in it.companyabc.com and infosec.companyabc.com, there will be a conflict as they would both be rewritten to [email protected]. This has more of an impact on replies to rewritten messages than it does to new outbound messages.
Note
The
use of wildcards is supported in limited usage when rewriting
addresses. For example, wildcards can only be used on internal domains.
Partial wildcard use such as john*@finance.companyabc.com or username@sales*.companyabc.com is not supported, whereas username @*.companyabc.com is. One example of wildcard usage is rewriting *@development.companyabc.com and *@software.companyabc.com to *@support.companyabc.com.
Address
rewriting can only be configured through the Exchange Management Shell.
No attachment rewriting options are available in the Exchange
Management Console. Each shell command has its own parameters you can
set based on the action(s) performed by the command. There are four
commands: Get-AddressRewriteEntry, New-AddressRewriteEntry, Set-AddressRewriteEntry, and Remove-AddressRewriteEntry.
The Get- command is used to retrieve the configuration of address rewriting. For example, entering Get-AddressRewriteEntry displays the configuration settings on the local system.
The New-AddressRewriteEntry command can be used to add a new rewriting entry. Use of this command requires three parameters: ExternalAddress, InternalAddress, and Name. The following example rewrites all email addresses in both directions for companyabc.com.
New-AddressRewriteEntry -Name "Two-way Rewrite entry for companyabc.com"
-InternalAddress companyabc.com -ExternalAddress companydef.com
The Set-
command allows an administrator to activate address rewriting or modify
the existing configuration. The following example switches the internal
and external domains given in our previous example and updates the
description to reflect the change.
Set-AddressRewriteEntry -Identity "Two-way Rewrite entry for companyabc.com"
-ExternalAddress companydef.com -InternalAddress companyabc.com -Name "Two-way Rewrite entry for companydef.com"
The Remove-
command can be used to delete an address rewriting entry. The following
example removes the entry created in the previous examples.
Remove-AddressRewriteEntry -Identity "Two-way Rewrite entry for companydef.com"
