Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
EPL Standings
 
 
Windows Server

Implementing Edge Services for an Exchange 2010 Environment : Using Address Rewriting to Standardize on Domain Address Naming for an Organization

3/22/2011 3:38:41 PM
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 that 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 Alexa@, Reese@, or support@ will have more conflicts when using address rewriting than organizations that use more unique or defined usernames like Alexa_Chimner@, 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 mike@companyabc.com. 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 address 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"					  
Top Search -----------------
- Windows Server 2008 R2 : Work with RAID Volumes - Understand RAID Levels & Implement RAID
- Windows Server 2008 R2 Administration : Managing Printers with the Print Management Console
- Configuring Email Settings in Windows Small Business Server 2011
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Implement Permissions
- Monitoring Exchange Server 2010 : Monitoring Mail Flow
- Windows Server 2008 R2 :Task Scheduler
- Windows Server 2008 R2 : File Server Resource Manager
- Windows Server 2008 R2 : Installing DFS
- Exchange Server 2010 : Managing Anti-Spam and Antivirus Countermeasures
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Share Folders
Other -----------------
- Application Development with SharePoint Designer 2010 and Visual Studio 2010 : Developing a Visual Web Part
- Using Visual Studio 2010 with SharePoint 2010
- Creating a Workflow-Based Application in SharePoint Designer 2010
- Windows Server 2003 : Authorizing Remote Access Connections (part 3) - Configuring Access Beyond the Remote Access Server
- Windows Server 2003 : Authorizing Remote Access Connections (part 2) - Understanding Remote Access Policies
- Windows Server 2003 : Authorizing Remote Access Connections (part 1) - Configuring Dial-In Properties of the User Account
- Windows Server 2008 R2 : Understanding Remote Desktop Services (part 5) - Single Sign-On & Remote Desktop Connection Display
- Windows Server 2008 R2 : Understanding Remote Desktop Services (part 4)
- Windows Server 2008 R2 : Understanding Remote Desktop Services (part 3) - RD Connection Broker & RD Licensing
- Windows Server 2008 R2 : Understanding Remote Desktop Services (part 2) - RD Gateway & RD Web Access
 
 
Most view of day
- Windows Server 2008 Server Core : Compressing Data with the Compact Utility
- Manage the Active Directory Domain Services Schema : Remove Attributes from the Index
- Add an InfoPath Form Web Part to a SharePoint Web Part Page
- Microsoft Systems Management Server 2003 : Defining Parent-Child Relationships (part 2) - Installing the Secondary Site Locally from the SMS CD
- Windows Server 2003 : Analyzing Traffic Using Network Monitor (part 1)
- BizTalk 2009 : Host Integration Server 2009 - Planning Your Host Integration Server Topology
- Using Windows Live Programs (part 2) - Using Windows Live Mail
Top 10
- Automating Windows 7 Installation : Customizing Images Using Deployment Image Servicing and Management (part 3) - Servicing the Operating System in an Image , Committing an Image
- Automating Windows 7 Installation : Customizing Images Using Deployment Image Servicing and Management (part 2) - Mounting an Image , Servicing Drivers in an Image
- Automating Windows 7 Installation : Customizing Images Using Deployment Image Servicing and Management (part 1) - Viewing Information about an Image with DISM
- Automating Windows 7 Installation : Applying an Image Using ImageX
- Automating Windows 7 Installation : Capturing an Image Using ImageX
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 4) - Fine-tuning Web Pages and Battling Bugs - Saving a Visio Drawing as a Web Page
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 3) - Fine-tuning Web Pages and Battling Bugs - Customizing Web Page Output
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 2) - Exploring Visio-Generated Web Pages
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 1) - Saving as Web Page
- Microsoft Visio 2010 : Sending Visio Files in Email, Saving as PDF or XPS Files
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro