Address rewriting allows us to conceal the original email sender replacing it with an address that better satisfies our business needs.

The most common application I encounter involves outsourcing of services. One organization could be handling support, sales, or marketing services for another organization. Using address rewriting the service provider can conceal his identity with that of the client. In this manner email recipients are kept unaware of the service provider.

Another application that you will find linked to address rewriting involves mergers. Here two organizations with their own email domains want all emails to appear to originate from a single domain.

Address Rewriting in Exchange 2007

The Exchange 2007 Edge server includes two address rewriting transport sinks one for each of the inbound and outbound directions.

Note: The sinks are only available as long as you are running the Edge server role. There is no out-of-the box solution for those not running Edge.

You may be wondering why address re-writing caters for both Inbound and Outbound emails. Whereas the primary goal of address rewriting is that of replacing the sender of outgoing emails, depending on your scenario, you may need to perform the reverse process to incoming emails. This is most obvious in the merger scenario where outbound emails from domain1.com and domain2.com are mapped to domain3.com. In this case any email replies will go to domain3.com. Thus inbound address rewriting may be employed for the routing of email to the recipients at domain1/domain2.

Note: An important but potentially tricky requirement in such a setup concerns address uniqueness. Each domain3.com address must map to only one address either at domain1.com or domain2.com but not both. Thus it is necessary to first resolve potential conflicts before deploying address rewriting.

Inbound address rewriting is normally not required in the outsourcing scenario. Here the service provider employs outbound address rewriting for sending emails. However replies then go straight to the client organization that the provider is representing.

While at it, we can also consider a third scenario where inbound address rewriting is not required:

Here an organization is consolidating multiple domains in a similar manner to the merger scenario. However we assign proxy addresses to each recipient mailbox such that inbound address rewriting is not required. Outgoing emails from user@domain1.com gets rewritten to user@domain3.com. By adding user@domain3.com to the list of proxy addresses, incoming replies are routed correctly without the need of address rewriting.

Changes in Email Addressing Information

An SMTP email includes addressing information within the Envelope and the email content itself. The envelope addresses are transmitted as part of the SMTP protocol MAIL and RCPT commands. We discussed these in Telnet Port 25. Within the email, of course we also have various headers that include addressing information.

In outbound address rewriting, Exchange tries to make the best possible job in concealing the original sender. Thus it edits both the Envelope Sender and the following headers:
From
To
Cc
Sender
Reply-To
Return-Receipt-To
Disposition-Notification-To
Resent-From
Resent-Sender

Even so, the true origin of outgoing emails is not completely hidden. For example the Received and Message-ID headers will uncover the true email origin. However these are not immediately visible to email recipients. Thus we don't really lose much of the address rewriting benefits.

When it comes to inbound address rewriting, the goal is not that of concealing. Instead all we care is to route emails correctly. In this case Exchange only modifies the Envelope recipients leaving all email content headers intact. Thus internal recipients will see the original unaltered email.

This Sounds like Spoofing

The outsourcing scenario could easily raise the question whether Address Rewriting is actually a tool for spoofing senders. Isn't this what spammers do so often, sending spam faking the sender address?

Yes, this is something worth being aware of especially in the outsourcing scenario. The main difference between a spammer and a service provider (apart for the email content I hope), is that the latter was authorized by the legitimate domain owner to send emails on his behalf. Another difference is that your service provider hopefully has a better reputation than a spammer. Some filters do take reputation into account.

Even so it is worth being careful when using things like SPF where a domain declares the list of host IPs that may legitimately send emails. In this case the SPF should include the IPs of the service provider.

Configuring Address Rewriting

As already mentioned address rewriting runs on the Exchange 2007 Edge server role and is implemented as two transport agents.

NOTE: There are some small differences between Exchange 2007 RTM and SP1. Here I will only discuss Exchange 2007 SP1.

Address Rewriting is only configurable through the shell. Enabling/Disabling this functionality is done directly by enabling/disabling the corresponding transport agents:
Address Rewriting Inbound Agent
Address Rewriting Outbound Agent

We check the enablement status using:
Get-TransportAgent

Here we can see that the agents are enabled. If this was not the case we would enable these with:
Enable-TransportAgent -Identity "Address Rewriting Inbound Agent"
Enable-TransportAgent -Identity "Address Rewriting Outbound Agent"

To disable the agents we could instead use:
Disable-TransportAgent -Identity "Address Rewriting Inbound Agent"
Disable -TransportAgent -Identity "Address Rewriting Outbound Agent"

With the agents enabled we configure the address mapping rules using:
New-AddressRewriteEntry

These are the most important cmdlet parameters you will require:
New-AddressRewriteEntry
-Name <rule name>
-InternalAddress <internal e-mail address/domain(s)>
-ExternalAddress <external e-mail address/domain>
[-OutboundOnly $True]

Name just identifies the rule name.

InternalAddress identifies which internal addresses are to be processed by address rewriting. This could be a single email address in the form name@domain.com. In this case the rule will only process emails sent from this single address. Otherwise InternalAddress could also be a domain such as domain.com. In this case the rule applies to all emails sent from this domain. Lastly using the * wildcard we can also identify all sub-domains using the syntax *.domain.com.

Note: New-AddressRewriteEntry also supports the ExceptionList parameter that allows us to exclude domains. This can be employed when InternalAddress specifies a set of domains using the * wildcard.

ExternalAddress specifies the new address to be set on processed emails.

Here we can either have the full address in the form nameout@domainout.com or just the domain in the form domainout.com. The former is used whenever rewriting a single address; the latter is used when InternalAddress specifies an entire domain or multiple sub-domains.

OutboundOnly is set to true whenever the address re-writing rule is only to be employed on outbound emails.

Using New-AddressRewriteEntry we can create multiple address rewriting rules. In this case the agents will look for the rule that best matches the email to be replaced. Thus, full addresses in the form name@domain.com take priority, next in priority are rules specifying a single domain/sub-domain and the lowest priority goes to rules using the* wildcard.

Of course apart for New-AddressRewriteEntry, we can also use Get-AddressRewriteEntry, Set-AddressRewriteEntry and Remove-AddressRewriteEntry to review, edit and remove address rewriting rules.

Address Rewriting in Action

To conclude I will setup a simple address rewriting rule just to demonstrate what we discussed. Here I will use address rewriting to change the domain of all emails from exchangeinbox.com to adminstop.com. I will apply the rule to the entire domain both in the inbound and outbound direction.

Thus after confirming that the agents are enabled using get-transportagent, we run the cmdlet:
New-AddressRewriteEntry
-Name AdminStop
-InternalAddress exchangeinbox.com
-ExternalAddress adminstop.com

This actually did not work, at least not until I restarted the 'Microsoft Exchange Transport' service. Following the restart everything worked fine.

Sending a test email to a hotmail account we can have a look at the headers. As expected the headers listed earlier (those present) are rewritten correctly.

And here are the Received and Message-ID headers that remain unchanged. Of course these headers would standout more if we were working in an outsourcing scenario.

Received: from MELITA.malta1.local ([xxx.xxx.xxx.xxx]) by COL0-MC1-F7.Col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 08:07:57 -0700

Received: from exchsrv.exchinbox.local (xxx.xxx.xxx.xxx) by MELITA.malta1.local (xxx.xxx.xxx.xxx) with Microsoft SMTP Server id 8.1.240.5; Wed, 22 Jul 2009 17:08:32 +0200

Received: from exchsrv.exchinbox.local ([fe80::6dc1:a981:50b:a2dc]) by exchsrv.exchinbox.local ([fe80::6dc1:a981:50b:a2dc%10]) with mapi; Wed, 22 Jul 2009 17:08:32 +0200

Message-ID: <99748EF61046E34D995DB9813D16C69A0201421F3DBD@exchsrv.exchinbox.local>

References

Planning for Address Rewriting

New-AddressRewriteEntry