Accepting inbound mail for a DNS domain and relaying it to responsible mail hosts outside your Exchange organization was a simple process in Exchange 2003, albeit one that required some explanation, which was discussed in the following articles:
- KB 321721 How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003
- KB 315511 XADM: How to Set Up Centralized SMTP Domain Sharing in Exchange 2000 Server for Independent Organizations
Exchange 2003 used Recipient Policies to define the domains for which your Exchange servers will accept email and to generate email addresses for your recipients using those domains.
Additionally, Recipient Policies also allowed you to apply Mailbox Manager settings, the Exchange 2003 equivalent of Messaging Retention Management (MRM).
Accepted Domains and Email Address Policies
In Exchange 2007, the Recipient Policy functionality was split into two components – Accepted Domains and Email Address Policies. As the names suggest, Accepted Domains are used to define the SMTP domains for which your transport servers will accept email, and Email Address Policies (EAPs) are used to generate email addresses for your recipients. EAPs use Accepted Domains – you must have an Accepted Domain to be able to create email addresses using that domain. For example, if you wanted your recipients to have email addresses from the domains contoso.com and tailspintoys.com, you first create an Accepted Domain for each of these domains and then create an email address policy to define the format of automatically generated email addresses – for example, firstname.lastname@contoso.com.
Whereas Exchange 2003 allowed you to use LDAP filters to apply Recipient Policies, Exchange 2010 and 2007 filter recipients using OPATH filtering syntax to apply EAPs. A number of pre-canned filters are included in the Email Address Policy interface in EMC or as parameters in the Shell, making it quite easy to use some of the more commonly used recipient properties such as company name, department, state and custom attributes 1-15 to apply policies. The pre-canned filters meet the needs of most Exchange deployments. For more complex filters, you can create a custom recipient filter by using the RecipientFilter parameter from the Shell. A custom recipient filter allow you to use a long list of recipient properties, called filterable properties, in a recipient filter. You can find a list of filterable properties in Filterable Properties for the -RecipientFilter Parameter in Exchange 2007 SP1 and SP2.
Accepted Domains and Sharing SMTP Address Spaces
The separation of domain name and email address policy objects makes sharing SMTP address spaces much easier. You can create the following three types of Accepted Domains in Exchange 2010 and Exchange 2007:
Authoritative domains: An authoritative domain means your Exchange organization is authoritative for the domain and knows about all its recipients. Generally, all recipients in an authoritative domain are Exchange recipients – mailboxes, distribution groups, mail-enabled public folders. Recipients can also be in other email systems, but Exchange must have a mail-enabled contact (MailContact) or a mail-enabled user (MailUser) object for them. Although one-off mail contacts or mail users can be created manually, they're generally created using directory synchronization in the following scenarios, for example:
- Another business unit which has its own Active Directory forest
- Another messaging system/directory in use within the same organization
Once replicated, Exchange knows how to deliver mail to these recipients.
Because Exchange is authoritative for the domain, it must generate a non-delivery report (NDR) for messages it accepts but can’t deliver for any reason, including for recipients it can’t find in Active Directory. You can use Recipient Filtering and silently drop mail for non-existent recipients.
External Relay domains: If your Exchange servers must accept email for a domain that it doesn’t have any recipients for, and then forward all such email to another mail host, you can create an External Relay domain. In this case, Exchange has no knowledge of recipients, and thus can’t take actions such as performing recipient filtering and dropping mail for recipients that don’t exist. Accepting inbound mail through a central messaging infrastructure is a common scenario. Because Exchange isn’t authoritative for the domain, it’s only responsible for forwarding mail to the next hop for that domain, which must generate any NDRs upon failure to deliver.
To forward email for an external relay domain to mail hosts that are authoritative for the domain (or the next hop, which can then relay it on), you must create a Send Connector for that domain and specify the next hop as a smarthost. In topologies with an Edge Transport server, such email is relayed by the Edge Transport and the Hub Transport servers never need to handle messages.
Internal Relay domains: Internal relay domains fulfill an important need, one that required a fairly involved setup in Exchange 2003. They allow you to accept email for a domain where some recipients may exist in your Exchange organization, and some recipients may be on another messaging system. Exchange may know about recipients in the other messaging system using mail contacts or mail users. Or it may deliver all messages that can be delivered locally (on any Exchange server in the organization) and relay messages for unknown recipients to another mail host using a Send Connector for the same domain. Because Exchange is not authoritative for this domain, it does not generate NDRs for recipients it’s not responsible for.
Internal Relay domains and Send Connectors
One important consideration when using an internal relay domain is that the Send Connector you use to send mail for unknown recipients to another mail host can’t be sourced to an Edge Transport server, because the Edge Transport server has already been instructed to accept all mail for that domain and forward it to Hub Transport servers. Instead, the Send Connector must be sourced to Hub Transport servers and you must specify another mail host as a smarthost.
Figure 1: Creating an Accepted Domain in EMC
More details in Understanding Accepted Domains.
Accepted Domains and Recipient Filtering
When creating Accepted Domains, an important consideration is Recipient Filtering. If you use Exchange’s built-in anti-spam filters, you can filter recipients that don’t exist in your organization using Recipient Filtering. This allows you to drop a large chunk of spam (at the gateway if you’ve implemented an Edge Transport server with EdgeSync). Additionally, it also means your servers won’t be processing mail for non-existent recipients and generating a NDR for the sender, which may also be either non-existent address or a valid addresses spoofed by a spammer.
If you’re in a topology with an Edge Transport server and have EdgeSync configured, recipient information is synchronized from a Hub Transport server to the Edge Transport server, which can then use this information to drop email for recipients that don’t exist in your organization. If you don’t have an Edge Transport server deployed, you can install anti-spam agents on a Hub Transport server and enable Recipient Filtering.
Many third-party SMTP security solutions that are typically deployed in perimeter networks can also lookup recipients in Active Directory, although they may require LDAP connectivity to an Active Directory DC/GC, which sits on your internal network, or some other means for replicating recipient information. Comparatively, EdgeSync communication is outbound (Secure LDAP) from Hub Transport servers to the Edge Transport server and doesn’t require you to open any ports on your internal firewall for inbound traffic.
How does Recipient Filtering treat recipients from different types of accepted domains? For authoritative domains, where Exchange knows about all recipients, Recipient Filtering drops mail for recipients that don’t exist in Active Directory. For External Relay domains, Exchange doesn’t know about any recipients, so such filtering isn’t possible. Internal Relay domains are a grey area – Exchange may or may not know about the recipients.
You can configure whether Recipient Filtering is allowed for an Accepted Domain by setting its AddressBookEnabled property. The default values for each accepted domain type are in the following table:
| Accepted Domain type | AddressBookEnabled |
|---|---|
| Authoritative | true |
| External Relay | false |
| Internal Relay | false |
For internal relay domains, it’s set to false by default – meaning Exchange (i.e. the Recipient Filtering agent, if enabled and configured to drop mail for recipients that don't exist in Active Directory) won’t check if the recipient exists. If you’re using a mechanism to replicate recipients from another Exchange organization or non-Exchange messaging system to Active Directory, you can set the property to true and have Recipient Filter check for valid recipients.
Set-AcceptedDomain foo.com –AddressBookEnabled $true