Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-04-18
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
- Bifurcation and the controlling of recipient expansion
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 email@example.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
The IMCEA encapsulation method uses the following
The placeholder <Type> identifies the type
of non-SMTP address, for example
|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.
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|
Any mail-enabled group object. The distribution group object types are as follows:
An object that has the Active Directory class msExchDynamicDistributionList. For more information, see How to Create a New Dynamic Distribution Group.
A user object that has an e-mail address and a defined Database parameter
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.
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.
A public folder object that has an e-mail address
An object that has the Active Directory class msExchExchangeServerRecipient. For more information about the Exchange recipient object, see Set-OrganizationConfig.
An object that has the Active Directory class msExchPublicMDB
An object that has the Active Directory class exchangeAdminService. There should be only one system attendant mailbox in the Exchange 2007 organization.
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
recipient proxyAddresses Active Directory attribute.
The legacyExchangeDN Active Directory attribute
- 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 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
- When two distribution groups contain one another as
- 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
$Trueand the ForwardingAddress parameter is set to one another.
- When two distribution groups contain one another as members.
- 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
$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
$False. The default value is
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
- 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
- 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 the
Disposition-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
- 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
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
The size that is used for message restrictions that are
configured for recipients is the value of the
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
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
Microsoft Exchange Recipient.
- Public folder replication
messages These messages are sent by a public
- 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
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:
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
- 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.
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
- 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.
|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|
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.
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.
This is the number of failed recipients that were detected during recipient resolution.
This is the number of recipients that failed recipient resolution because of recipient loops.
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.
This is the number of messages that were created during recipient resolution.
This is the number of messages that were scheduled for retry during recipient resolution.
Unresolved Org Recipients
This is the number of unresolved recipients from an authoritative domain that were detected during recipient resolution.
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|
This event indicates that a distribution group was expanded.
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.
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.
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
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.