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"					  
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
- Windows Server 2008 R2 : Understanding Remote Desktop Services (part 1) - RD Session Host & RD Virtualization Host
- Windows Server 2008 R2 : How Remote Desktop Works
- Installing Microsoft SharePoint Server 2010 and Configuring PerformancePoint Services : Installing SharePoint (part 2) - Running the Server Farm Installation for SharePoint
- Installing Microsoft SharePoint Server 2010 and Configuring PerformancePoint Services : Installing SharePoint (part 1)
- Installing Microsoft SharePoint Server 2010 and Configuring PerformancePoint Services : Examining PPS Installation Prerequisites
- PerformancePoint Services 2010 Architecture
- Building BizTalk Server 2009 Applications : Working with BizTalk orchestration
- Building BizTalk Server 2009 Applications : Configuring BizTalk messaging
- Building BizTalk Server 2009 Applications : What are BizTalk maps?
- Implementing Edge Services for an Exchange 2010 Environment : Using Sender/IP Reputation to Filter Content
 
 
Most view of day
- Maintaining Security : Restricting DVD Movies in Windows Media Player, Preventing Access While Using Windows Media Player
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 1) - State Model
- Microsoft PowerPoint 2010 : Incorporating Motion Video - Placing a Video on a Slide
- Microsoft Exchange Server 2010 : Basics of Recipient Management - Exchange Recipients
- Sharing Your Computer with Others : Display User Accounts
- Windows Server 2012 : Provisioning and managing shared storage (part 7) - Managing shared storage - Managing volumes, Managing shares
- Windows Server 2008 R2 file and print services : Services for Network File System, Windows Search Service
- Plug and Play and Power Management : WMI Request Handler, Synchronization Issues, Security
- Windows Server 2012 Group Policies and Policy Management : Understanding Group Policy (part 3) - GPO Filtering, Group Policy Loopback Processing
- BizTalk Server 2009 Operations : Maintaining the BizTalk Group (part 1) - SQL Agent Job Configuration
Top 10
- Using the Windows 7 Libraries : USING THE EXPLORER BROWSER CONTROL (part 2)
- Using the Windows 7 Libraries : USING THE EXPLORER BROWSER CONTROL (part 1) - Adding the Explorer Browser to Your Toolbox , Configuring the Explorer Browser Example
- Using the Windows 7 Libraries : CONSIDERING USER-DEFINED COLLECTIONS
- Using the Windows 7 Libraries : USING NON-FILESYSTEM CONTAINERS
- Using the Windows 7 Libraries : WORKING WITH KNOWN FOLDERS
- Microsoft Exchange Server 2007 : Implementing Client Access and Hub Transport Servers - Installing the Hub Transport Server
- Microsoft Exchange Server 2007 : Implementing Client Access and Hub Transport Servers - Transport Pipeline
- Microsoft Exchange Server 2007 : Hub Transport Server Policy Compliance Features (part 4) - Message Classification , Rights Management and the Hub Transport Server
- Microsoft Exchange Server 2007 : Hub Transport Server Policy Compliance Features (part 3) - Journaling
- Microsoft Exchange Server 2007 : Hub Transport Server Policy Compliance Features (part 2) - Disclaimers
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro