E-mail address policies which were known as Recipient Policies back in Exchange 2000 and 2003, define the proxy addresses that are stamped onto recipient objects in the Exchange 2007 organization. E-mail address policies are added on an organization level meaning they apply to the whole Exchange 2007 organization. With Exchange 2007, the recipient policies have been split in two: Accepted Domains and E-mail Address Policies.
Those of you with Exchange 2000 and/or 2003 experience know that recipient policies also controlled which SMTP namespaces were accepted by the Exchange organization. Some of you probably wonder why these two features were split in Exchange 2007. There were three primary reasons why the Exchange Product group made the split.
First, if a domain was
specified for an e-mail address recipient policy, but wasn’t configured as the authoritative domain, the e-mail sent to the recipients with e-mail addresses defined by the policy would not be routed within the Exchange organization for this domain. Even though this is an invalid scenario, the Exchange 2000 and 2003 System Manager allowed this type of configuration.
Secondly, the authoritative domain concept was hidden under the e-mail address recipient policy GUI, which wasn’t very
intuitive for administrators. Lastly, relay domains were controlled via the SMTP connector’s GUI, allocated in a completely different location from where the authoritative domains (Recipient Policies) were controlled.
The separation of Accepted Domain and E-mail Address Policies are not the only design change that has been made in Exchange 2007. The infamous Recipient Update Service (RUS), which most of us know from Exchange 2000 and 2003, is also no longer part of the Exchange 2007 product.
RUS was responsible for stamping E-mail addresses on AD objects, in addition to address list membership, along with a few other things, it didn’t always work as expected and was very difficult to troubleshoot when it acted up. With Exchange 2007, the RUS (and thereby the asynchronous behavior used to provision objects) has been replaced by a new synchronous process (EmailAddressPolicy cmdlet), used to stamp E-mail addresses onto objects immediately!
Yes, you no longer have to wait for several minutes to see email addresses on your objects as was often the case with the antiquated RUS.
Note:
For a detailed explanation about the removal of RUS, read the following post on the MS Exchange Team blog.
Accepted Domains
Before you can begin creating a new E-mail Address Policy, you must first add the respective domain name under the Accepted Domains tab. Under the Accepted Domains tab, we specify the SMTP domains for which our Exchange 2007 organization should either be authoritative, relay to an e-mail server in another Active directory Forest within the
organization, or relay to an e-mail server outside the respective Exchange organization.
The difference between internal and external relayed domains is that internal relaying simply sends the e-mail messages directly to the e-mail server in the organization. Messages sent to an external relayed domain will first be delivered to the Edge Transport server in the perimeter network, and from there be routed to the respective external e-mail server on the Internet.
When the first Hub Transport server is deployed in the Exchange 2007 organization, the domain name of the Active Directory Forest root domain is configured as an authoritative domain by default. Since the Hub Transport server used as an example throughout this article has been installed into an Active Directory Forest named exchangedogfood.dk, this domain name is the authoritative domain for this Exchange 2007 organization by default (Figure 1).
Since we use a split-DNS setup, where the internal and external domain names match, we don’t need to do any configuration changes after the Hub Transport server has been deployed. Many organizations use an internal domain name that differs from the external domain name, which among other things are used for inbound mail.
For example, it’s common to use a domain.local domain internally. If this is the case in your organization, you must manually create an accepted domain matching your external domain name.
Figure 1: Property page for an Accepted Domain
Creating a new Accepted Domain
Creating a new accepted domain is a straightforward task. You simply click New Accepted Domain in the Action pane. In the New Accepted Domain wizard, enter a name for the accepted domain entry and the domain for which you want to receive
e-mail.
Note:
Any accepted domain which is added under the Accepted Domains tab can be linked to an E-mail Address Policy (EAP),
such that it will generate recipient e-mail addresses for the accepted domain. As a matter of fact, every EAP must link to an accepted domain, such that e-mail messages sent to e-mail address specified in an EAP are allowed to be routed by the Hub Transport servers in the organization. You’ll see what I mean when we cover E-mail Address Policies later in the article.
As we already talked about, the Hub Transport server can handle messages for a particular domain in several different ways (shown in Figure 2). Choose the desired option and click New and then Finish.
Figure 2: New Accepted Domain Wizard
If you’d rather create an Accepted Domain entry using the Exchange Management Shell, you can do so using the New-AcceptedDomain cmdlet. For example, to create an accepted domain entry similar to the one we created in Figure 2, you would need to run the following command:
New-AcceptedDomain –Name “Exchange-faq” –DomainName “exchange-faq.dk” –DomainType “Authoritative”
As you can see in Figure 3, we have several E-mail Address Policies in our Exchange 2007 organization, listed in prioritized order (the lower the number, the higher the priority) as was also the case in Exchange 2000 and 2003.
If you want to move a particular policy up the list, highlight the policy and click Change Priority in the Action pane. You must have at least two EAPs aside from the default in order to see the Change Priority Action pane option
Figure 3: Prioritized List of the E-Mail Address Policies in the organization
Creating a new E-mail Address Policy
Creating a new E-mail address policy is a straightforward task, although much different from Exchange 2000 and 2003. In order to do so, click New E-mail Address Policy in the Action pane. On the Introduction page of the New E-Mail Address Policy wizard, enter a name for the new policy, and then specify what type of recipients should be included (Figure 4) and then click Next.
Figure 4: The New E-Mail Address Policy Page
You can now be a bit more selective when defining your target group by using the filter and selecting one or more conditions as shown in Figure 5. When you have configured any conditions you want applied to the policy, click Next.
Figure 5: The New E-Mail Address Wizard Conditions Page
Now click Add and select the E-mail address local part to be used to create the username portion of the e-mail address, then choose an e-mail domain from the E-mail address domain in the drop-down box as shown in Figure 6. When ready click OK and Next.
Figure 6: Specifying the Local Part of the E-Mail Addresses and the E-Mail Address Domain
As you can see in Figure 6, you can choose between 7 local E-mail address parts. The local part of an e-mail address is the name format appearing before the “at sign (@)”. If none of the default 7 local parts fit what you need to use for your E-mail address Policy, you can use the variables listed in Table 1 below.
Variable | Description |
%g | Used for given name (first name) |
%i | Used for middle initial |
%s | Used for surname (last name) |
%d | Used for display name |
%m | Used for Exchange alias |
%xs | Uses the x number of letters of the surname. For example if x=2, then the first two letters of the surname are used. |
%xg | Uses the x number of letters of the given name. For example, if x=2, then the first two letters of the given name are used |