Understanding Recipient Resolution
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
Recipient resolution is the process of expanding and resolving all the recipients in a message. The act of resolving the recipients matches a recipient to the corresponding Active Directory directory service object in the Microsoft Exchange organization. The act of expanding the recipients expands all distribution groups into a list of individual recipients. Recipient resolution allows message limits and alternative recipients to be applied correctly to each recipient.
In a Microsoft Exchange Server 2007 organization, recipient resolution is performed by the categorizer on a server that has the Hub Transport server role installed. Categorization on each message happens after a newly arrived message is put in the Submission queue. Recipient resolution, in addition to content conversion and routing, is performed on the message before the message is put in a delivery queue. The categorizer performs recipient resolution before routing. The component of the categorizer that is responsible for recipient resolution is frequently called the resolver.
This topic explains how recipient resolution works. Recipient resolution performs the following activities:
Top-level resolution
Expansion
Bifurcation and the controlling of recipient expansion
Top-Level Resolution
Top-level resolution is the first stage of recipient resolution. Top-level resolution associates each recipient in an incoming message to a matching recipient object in Active Directory. During top-level resolution, the categorizer creates a list that contains the sender and the initial, unexpanded recipient e-mail addresses that exist within the message. The categorizer then uses that list of e-mail addresses to query Active Directory to find any mail-enabled objects that have matching e-mail address attributes. When a match is found, the properties of matching Active Directory object are cached for later use. Any sender message restrictions are also enforced.
Recipient E-mail Addresses
Top-level resolution begins with a message and the initial, unexpanded list of recipients from the message envelope. The message envelope contains the commands that are used to transmit messages between Simple Mail Transfer Protocol (SMTP) messaging servers. The sender's e-mail address is contained in the MAIL FROM: command. Each recipient's e-mail address is contained in a separate RCPT TO: command. The envelope sender and envelope recipients are typically created from the sender and recipients in the To:, From:, Cc: and Bcc: header fields in the message header. However, this is not always true. The To:, From:, Cc:, and Bcc: header fields in a message are easily forged and may not match the actual sender or recipient e-mail addresses that were used to transmit the message.
Encapsulated E-mail Addresses
Standard SMTP e-mail addresses follow the specifications of RFC 2821 and RFC 2822, such as chris@contoso.com, for example. However, an e-mail address can also be a non-SMTP e-mail address that is encapsulated inside a valid SMTP address. Exchange 2007 supports encapsulated addresses that use the Internet Mail Connector Encapsulated Address (IMCEA) encapsulation method.
This encapsulation method was introduced with Microsoft Exchange Server version 5.5. This method requires the encoding of any characters that are invalid in SMTP e-mail addresses. Alphanumeric characters, the equal sign ( = ) and the hyphen ( - ) don't require encoding. Other characters use the following encoding syntax:
A forward slash ( / ) is replaced by an underscore ( _ ).
Other US-ASCII characters are replaced by a plus sign ( + ) and the two digits of its ASCII value are written in hexadecimal. For example, the space character has the encoded value
+20.
The IMCEA encapsulation method uses the following syntax: IMCEA<Type>-<address>@<domain>
The placeholder <Type> identifies the type of non-SMTP address, for example EX, X400, or FAX.
Note
Although SMTP and X500 are theoretically valid values for <Type>, Exchange 2007 recipient resolution rejects any IMCEA encoded addresses that use either of these types.
The placeholder <address> is the encoded original address. The placeholder <domain> represents the SMTP domain that is used to encapsulate the non-SMTP address, for example, contoso.com
With the IMCEA encapsulation method, addresses are unencapsulated only when the domain matches the default authoritative domain in the Exchange organization. For more information about accepted domains, see Managing Accepted Domains.
The maximum length for an SMTP e-mail address in Exchange 2007 is 571 characters. This limit includes the following:
315 characters for the name part of the address
255 characters for the domain name
The "@" character that separates the name part of the address from the domain name
Currently, Exchange 2007 doesn't support messages that are encoded with the IMCEA encapsulation method when the name part of the address exceeds 315 characters.
Address Resolution
For each message, the sender e-mail address and all recipient e-mail addresses are added to a list that is used to query Active Directory. Any encapsulated addresses are unencapsulated before they are added to the list of e-mail addresses. The Active Directory query is performed on up to 20 e-mail addresses at a time. If the Active Directory query encounters any transient errors, the message is returned to the Submission queue and deferred for the time that is specified by the ResolverRetryInterval parameter in the EdgeTransport.exe.config application configuration file. The default value is 30 minutes.
The following table describes the recipient objects that are found in Active Directory. For more information about Exchange 2007 recipient types, see Understanding Recipients.
Recipient objects in Active Directory
| Active Directory recipient type | Description |
|---|---|
DistributionGroup |
Any mail-enabled group object. The distribution group object types are as follows:
|
DynamicDistributionGroup |
An object that has the Active Directory class msExchDynamicDistributionList. For more information, see How to Create a New Dynamic Distribution Group. |
Mailbox |
A user object that has an e-mail address and a defined Database parameter |
MailUser |
A user object that has an e-mail address without a defined Database parameter. For more information, see How to Create a New Mail-Enabled User. |
MailContact |
A contact object that has an e-mail address. Typically, a mail contact is used for recipients outside the Exchange organization. A mail contact is also used in cross-forest Exchange environments. For more information, see How to Create a New Mail Contact. |
MailPublicFolder |
A public folder object that has an e-mail address |
MicrosoftExchangeRecipient |
An object that has the Active Directory class msExchExchangeServerRecipient. For more information about the Exchange recipient object, see Set-OrganizationConfig. |
PublicDatabase |
An object that has the Active Directory class msExchPublicMDB |
SystemAttendantMailbox |
An object that has the Active Directory class exchangeAdminService. There should be only one system attendant mailbox in the Exchange 2007 organization. |
SystemMailbox |
A user object that has an e-mail address and that is located in the Microsoft Exchange System Objects container. There should be one system mailbox for each mailbox database in the Exchange 2007 organization. |
An object that contains missing or malformed critical properties is classified by the Active Directory query as an invalid object. For example, a dynamic distribution group object without an e-mail address is considered invalid. Messages that are sent to recipients that are classified as invalid objects generate a non-delivery report (NDR).
For each e-mail address, a single initial query is performed for all possible recipient properties, such as the recipient identifiers, recipient type, message limits, e-mail addresses, and alternative recipients. The applicable properties for the recipient are cached for later use. Recipient resolution classifies the recipients based on similarities in how the recipients are resolved, and the similarity of the applicable recipient properties.
The Lightweight Directory Access Protocol (LDAP) filter that is used for address resolution is described as follows:
For the EX e-mail address type, the LDAP filter is based on the recipient legacyExchangeDN Active Directory attribute or the recipient proxyAddresses Active Directory attribute. The legacyExchangeDN Active Directory attribute takes precedence.
For all other e-mail addresses types, the recipient proxyAddresses Active Directory attribute is used as the LDAP filter.
If the e-mail address that is used in the message doesn't match the primary SMTP address of the corresponding Active Directory object, the categorizer rewrites the e-mail address in the message to match the primary SMTP address. The original e-mail address is saved in the ORCPT= parameter in the RCPT TO: command in the message envelope.
Sender Message Restrictions
The size that is used for the sender message size restriction is the value of the X-MS-Exchange-Organization-OriginalSize: header field in the message header. Exchange 2007 uses this header field to record the original message size of the message when it entered the Exchange 2007 organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. If this header field doesn't exist, it is created by using the current message size value. If the message is too large, an NDR is generated and additional message processing is stopped.
The sender recipient limit is only enforced on the first Hub Transport server that processes the message. The original, unexpanded message envelope recipient count is compared to the sender recipient limit. The original, unexpanded message envelope recipient count is used to avoid the partial message delivery problems that occur in Microsoft Exchange Server 2003 when nested distribution lists used remote expansion servers.
The message sender and all recipients are marked as resolved by stamping an extended property in the message. This extended property allows the message to bypass top-level resolution if the message must go through recipient resolution again. A message may have to go through recipient resolution again because the Microsoft Exchange Transport service restarted.
Expansion
Expansion occurs after top-level resolution. Expansion completely expands nested levels of recipients into individual recipients. Expansion may require multiple trips through the expansion process to expand all recipients. Not all recipients have to be expanded. However, all recipients must go through the expansion process. The expansion process also enforces recipient message restrictions for all kinds of recipients.
The following list describes the kinds of recipients that require expansion:
Distribution groups and dynamic distribution groups Distribution groups are expanded based on the memberOf Active Directory property. Dynamic distribution groups are expanded by using the Active Directory query definition. If the ExpansionServer parameter is set on the group, the group is not expanded by the current server. The distribution group is routed to the specified server for expansion.
Note
If you select a specific Hub Transport server in your organization as the expansion server, the distribution group usage becomes dependent on the availability of the expansion server. If the expansion server is unavailable, any messages that are sent to the distribution group can't be delivered. If you plan to use specific expansion servers for your distribution groups, to reduce the risk of service interruption, you should consider implementing high availability solutions for these servers. To learn more about high availability, see High Availability Strategies.
Alternative recipients The ForwardingAddress parameter may be set on mailboxes and mail-enabled public folders. The ForwardingAddress parameter redirects all messages to the specified alternative recipient. This is known as a forwarded recipient. When the ForwardingAddress parameter is set, and the DeliverToMailboxAndForward parameter is set to
$True, the message is delivered to the original recipient and the alternative recipient. This is known as delivered and forwarded recipient.Contact chains A contact chain is a mail user or mail contact that has the ExternalEmailAddress parameter set to the e-mail address of another recipient in the Exchange organization.
Detection of Recipient Loops
As the distribution groups, alternative recipients, and contacts chains are expanded, the categorizer checks for recipient loops. A recipient loop is a recipient configuration problem that causes message delivery to the same recipients in an endless circle. The following list describes the different types of recipient loops:
Harmless recipient loop A harmless recipient loop results in successful message delivery. The following list describes two scenarios when harmless recipient loops occur:
When two distribution groups contain one another as members.
When mailboxes or mail-enabled public folders are set to deliver and forward to one another. This happens when the DeliverToMailboxAndForward parameter of both recipients is set to
$Trueand the ForwardingAddress parameter is set to one another.
When a harmless recipient loop is detected, the message is delivered to the recipient, but no additional attempts are made to deliver the message to the same recipient.
Broken recipient loop A broken recipient loop can't result in successful message delivery. An example of a broken recipient loop is when mailboxes or mail-enabled public folders have the ForwardingAddress parameter set to one another. When the categorizer detects a broken recipient loop, expansion activity for the current recipient stops, and an NDR is generated for the recipient.
Detection of recipient loops doesn't prevent duplicate message delivery. For example, Distribution Group C will experience duplicate message delivery if the following conditions are true:
Distribution Group B and Distribution Group C are members of Distribution Group A.
Distribution Group C is also a member of Distribution Group B.
Delivery Report Redirection for Distribution Groups
When a distribution group is expanded, the message type is checked to determine whether it is a delivery report message. If the message is a delivery report, the redirection settings of the distribution group are checked to determine whether redirection of the delivery report is required. You may want to suppress the delivery reports because the delivery reports may disclose unwanted information about the distribution group and its membership.
The following list describes the delivery report redirection settings that are available for distribution groups and dynamic distribution groups:
ReportToManagerEnabled This parameter enables delivery reports to be sent to the distribution group manager. Valid values are
$Trueor$False. The default value is$False. For a distribution group, the manager is controlled by the ManagedBy parameter in the Set-Group cmdlet. For a dynamic distribution group, the manager is controlled by the ManagedBy parameter in the Set-DynamicDistributionGroup cmdlet.ReportToOriginatorEnabled This parameter enables delivery reports to be sent to the sender of e-mail messages that are sent to this distribution group. Valid values are
$Trueor$False. The default value is$True.Note
The values of the ReportToManagerEnabled parameter and ReportToOriginatorEnabled parameter can't both be
$True. If one parameter is set to$True, the other must be set to$False. The values of both parameters can be$False. This suppresses all redirection of all delivery report messages.
The following list describes the available delivery report messages:
Delivery receipt (DR) This report confirms that a message was delivered to its intended recipient.
Delivery status notification (DSN) This report describes the result of an attempt to deliver a message. For more information about DSN messages, see Managing Delivery Status Notifications.
Message disposition notification (MDN) This report describes the status of a message after it has been successfully delivered to a recipient. A read notification (RN) and a non-read notification (NRN) are both examples of an MDN message. MDN messages are defined in RFC 2298, and are controlled by the
Disposition-Notification-To:header field in the message header. MDN settings that use theDisposition-Notification-To:header field are compatible with many different messages servers. MDN settings can also be defined by using MAPI properties in Microsoft Outlook and Exchange Server.Non-delivery report (NDR) This report indicates to the message sender that the message couldn't be delivered to the specified recipients.
Non-read notification (NRN) This report indicates that a message was deleted before it was read.
Out of office (OOF) This report indicates that the recipient will not respond to e-mail messages. The acronym OOF dates back to the original Microsoft messaging system where the corresponding notification was named "out of facility".
Read notification (RN) This report indicates that a message was read.
Recall Report This report indicates the status of a recall request for a given recipient. A recall request is when a sender tries to recall a sent message by using Outlook.
When a delivery report message is sent to a distribution group, the following settings cause the report message to be deleted:
Report redirection is not set. Alternatively, report redirection is set to the message sender.
Report redirection is set to the distribution group manager. And the delivery report message is not an NDR.
When a delivery report message is sent to a distribution group, the following settings cause the delivery report message to be delivered to the distribution group manager:
- Report redirection is set to the distribution group manager. And the report message is an NDR.
When a message that is not a delivery report message is sent to a distribution group, the message is delivered to the distribution group members. The report request settings are summarized in the following list:
If report redirection is set to the message sender, the report request settings are not modified.
If report redirection is not set, all report request settings are suppressed. The NOTIFY=NEVER parameter is added to RCPT TO: for each recipient in the message envelope.
If report redirection is set to the distribution group manager, all report request settings are suppressed except NDR messages that are sent to the distribution group manager.
Message Restrictions on Recipients
The expansion process also enforces any message restrictions that are configured for recipients. These restrictions may be configured individually for each recipient or organizationally for all Hub Transport servers in the Exchange organization. The following table describes the message restrictions that are configured for recipients:
Message restrictions on recipients
| Source | Parameter | Description |
|---|---|---|
Set-DistributionGroup Set-DynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser Set-TransportConfig |
MaxReceiveSize |
The size that is used for message restrictions that are configured for recipients is the value of the |
Set-DistributionGroup Set-DynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser |
RequireSenderAuthenticationEnabled |
The RequireSenderAuthenticationEnabled parameter requires that all messages that are sent to the recipient come from authenticated senders. When the value of this parameter is set to |
Set-DistributionGroup Set-DynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser |
AcceptMessagesOnlyFrom AcceptMessagesOnlyFromDLMembers RejectMessagesFrom RejectMessagesFromDLMembers |
The categorizer checks the recipient permission in two passes. The first pass determines whether the sender is present in the AcceptOnlyMessagesFrom or RejectMessagesFrom parameter. If the sender is not found in either parameter, the recipients in the AcceptMessagesOnlyFromDLMembers and RejectMessagesFromDLMembers parameters are fully expanded. This complete expansion of distribution groups may take some time. We recommend that you minimize the depth of nested distribution groups in the AcceptMessagesOnlyFromDLMembers parameter and the RejectMessagesFromDLMembers parameters |
Certain types of messages that are sent by authenticated senders are exempt from restrictions. The following list describes the messages that are exempt from recipient restrictions:
All messages that are sent by the Microsoft Exchange recipient These messages include DSN messages, journal reports, quota messages, and other system-generated messages that are sent to internal message senders. For more information about the Microsoft Exchange recipient, see Managing the Microsoft Exchange Recipient.
Public folder replication messages These messages are sent by a public database sender.
All messages that are sent by the external postmaster address These messages include DSN messages and other system-generated messages that are sent to external message senders. For more information about the external postmaster address, see Managing the External Postmaster Address.
Certain types of messages are blocked when they are sent from the Exchange organization to external domains. The settings are controlled by the following parameters in the Set-RemoteDomain cmdlet:
AllowedOOFType
AutoForwardEnabled
AutoReplyEnabled
DeliveryReportEnabled
NDREnabled
SendOofMessageToOriginatorEnabled
For more information, see Managing Remote Domains.
Bifurcation and Controlling Recipient Expansion
Because the complete list of message recipients is expanded and resolved by recipient resolution, there are occasions when different copies of the same message must to be created. These occasions are described by the following scenarios:
When message recipients require different message settings Message properties such as read receipts may have to be enabled for some recipients and blocked for other recipients. Creating a new version of the message that has slightly different properties than the original message is called bifurcation.
To limit the number of envelope recipients in a single message The recipient expansion process can generate thousands of individual recipients when large distribution groups are expanded. In Exchange 2007, instead of creating a single copy of the message that has thousands of envelope recipients, multiple copies of the same message that have a limited number of envelope recipients are created.
Bifurcation
Recipient resolution bifurcates a message if the following conditions are true:
When the message sender in MAIL FROM:, in the message envelope, is updated. For example, when the ReportToManagerEnabled parameter on a distribution group is
$True.When auto-response messages, such as DSNs, OOF messages, and recall reports must be suppressed.
When alternative recipients are expanded.
When a
Resent-From:header field must be added to the message header. Resent header fields are informational header fields that can be used to determine whether a message has been forwarded by a user. Resent header fields are used so that the message appears to the recipient as if it was sent directly by the original sender. The recipient can view the message header to discover who forwarded the message. Resent header fields are defined in section 3.6.6 of RFC 2822.When the history of the expansion of the distribution group must be transmitted.
Controlling Recipient Expansion
When the number of expanded recipients is too large, the categorizer splits the message into multiple copies. This is performed to reduce system resource use during message expansion. The maximum number of envelope recipients in a message is controlled by the ExpansionSizeLimit parameter in the EdgeTransport.exe.config application configuration file. The default value is 1000.
Warning
We recommend that you do not modify the value of the ExpansionSizeLimit parameter on an Exchange transport server in a production environment.
Recipient Resolution Diagnostics
Reporting and diagnostic information for recipient resolution is provided by performance counters, message tracking log entries, and recipient resolution logging. These sources can help you identify and diagnose problems with recipient resolution.
Recipient Resolution Performance Counters
The following table describes the performance counters that are available for recipient resolution.
Recipient resolution performance counters
| Counter name | Display name | Description |
|---|---|---|
AmbiguousRecipientsTotal |
Ambiguous Recipients |
This is the total number of ambiguous recipients that were detected during recipient resolution. Ambiguous recipients are different recipients that have matching legacyExchangeDN Active Directory attributes or matching proxyAddresses Active Directory attributes. |
AmbiguousSendersTotal |
Ambiguous Senders |
This is the number of ambiguous senders that were detected during recipient resolution. Ambiguous senders are different senders that have matching legacyExchangeDN Active Directory attributes or matching proxyAddresses Active Directory attributes. |
FailedRecipientsTotal |
Failed Recipients |
This is the number of failed recipients that were detected during recipient resolution. |
LoopRecipientsTotal |
Loop Recipients |
This is the number of recipients that failed recipient resolution because of recipient loops. |
MessagesChippedTotal |
Messages Chipped |
This is the total number of copies of the same message that were created during recipient resolution to control the number of envelope recipients in a single message. In Exchange 2007, this process is referred to as chipping. |
MessagesCreatedTotal |
Messages Created |
This is the number of messages that were created during recipient resolution. |
MessagesRetriedTotal |
Messages Retried |
This is the number of messages that were scheduled for retry during recipient resolution. |
UnresolvedOrgRecipientsTotal |
Unresolved Org Recipients |
This is the number of unresolved recipients from an authoritative domain that were detected during recipient resolution. |
UnresolvedOrgSendersTotal |
Unresolved Org Senders |
This is the number of unresolved senders from an authoritative domain that were detected during recipient resolution. |
Recipient Resolution Events That are Written in the Message Tracking Log
The following table describes the recipient resolution events that are written in the message tracking log.
Recipient resolution events in the message tracking log
| Message tracking event | Description |
|---|---|
EXPAND |
This event indicates that a distribution group was expanded. |
REDIRECT |
This event indicates that a message sent to a mailbox recipient or a mail-enabled public folder recipient was redirected to an alternative recipient as specified by the ForwardingAddress parameter. |
RESOLVE |
This event indicates that a recipient e-mail address was changed to the primary SMTP e-mail address of the corresponding Active Directory recipient object. |
TRANSFER |
This event indicates that message bifurcation or chipping occurred. |
For more information about message tracking, see Managing Message Tracking.
Recipient Resolution Logging
Recipient resolution logging is controlled by the ResolverLogLevel parameter in the EdgeTransport.exe.config application configuration file. The valid values for this parameter are Disabled, Enabled, and FullContent. The default value is Disabled. When the ResolverLogLevel parameter is set to Enabled, only message envelope data is logged. When the ResolverLogLevel parameter is set to FullContent, message envelope data and message header data is logged.