You are on page 1of 493

My Collection

This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2013 Microsoft. All rights reserved. Terms of Use (http://technet.microsoft.com/cc300389.aspx) | Trademarks (http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx)

Table Of Contents
Chapter 1
Understanding Message Routing Understanding Transport Understanding Mailbox Getting Started With Exchange 2010

Chapter 1

Understanding Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-12 The primary task of Hub Transport and Edge Transport servers in your organization is to route messages received from users and external sources to their ultimate destinations. This topic explains how Microsoft Exchange Server 2010 routes messages in your organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Overview of Message Routing in Exchange 2010 Routing Components Using Active Directory Sites for Routing Exchange 2010 Routing Tables Receiving Messages for Routing Routing Messages Rerouting and the Unreachable Queue

Overview of Message Routing in Exchange 2010

Routing decisions are made during message categorization. The categorizer is a component of the Microsoft Exchange Transport service that processes all incoming messages and determines what to do with the messages based on information about the intended recipients. The categorizer processes messages in several dependent phases and also uses other components of the Microsoft Exchange Transport service during message processing. After a message is received by an Exchange 2010 transport server, and after the preliminary processing that occurs during SMTP Receive is complete, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:

1. Agent processing of submitted messages Some agent processing on the Hub Transport server occurs when the message is received for categorization. The agents that are applied during this phase include the optional Microsoft Forefront Protection for Exchange Server antivirus agent and the Journaling agent. 2. Recipient resolution During this phase, the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address. 3. Routing After information about the recipient is resolved, the routing component of the categorizer determines the ultimate destination for the message and the route to that destination, selects the next segment, or hop, for message relay, and resolves the next hop information to a list of physical servers and IP addresses. 4. Content conversion Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that's readable by the recipient. Content conversion transforms e-mail messages from one format to another format for mail flow or storage, such as MAPI to MIME, or UUENCODE to base64 encoded, or for appropriate rendering that's specific to an e-mail client, such as HTML, rich text format (RTF), or plain text. 5. Agent processing of routed messages After the routing decisions for a particular message are made, the Transport Rules agent and the Journaling agent are applied on the Hub Transport server. The Journaling agent is applied both when the message is submitted and when it's routed so that any changes that are made to the message by the Transport Rules agent, for example, when it modifies a delivery address or applies a message-specific journaling requirement, don't bypass the Journaling agent. 6. Message packaging and DSN generation The final categorized message is assembled and moved to a delivery queue. A delivery status notification (DSN) may also be generated during this phase. Messages are next processed by SMTP Send, the store driver, delivery agents, or the foreign gateway connection handler. The component that's used depends on the ultimate destination. A delivery queue is dynamically generated for each hop. The messages are queued in these delivery queues after a routing decision is made. If a route can't be found for a recipient, the messages are queued to the Unreachable queue. The following figure shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination. Routing context in mail flow

Return to top

Routing Components
To make routing decisions, Exchange 2010 must access configuration information that's stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Lightweight Directory Services (AD LDS) instance on the local server. Microsoft Windows and Exchange 2010 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2010 references these tables when it makes routing decisions. The cache is updated when the routing topology changes. The Exchange services that are used during message transport are common to both the Hub Transport server role and the Edge Transport server role. However, the Edge Transport server role doesn't cache information about the Active Directory topology. The following configuration and service components are important to message routing:

Active Directory sites An Active Directory site represents the routing boundary for Hub Transport servers. A Hub Transport server delivers directly to Mailbox servers, distribution group expansion servers, and to source servers for connectors in the local Active Directory site and to Edge Transport servers subscribed to that site. However, a Hub Transport server must relay messages to another Hub Transport server for recipients, expansion servers, and connectors that are located in remote Active Directory sites. The Hub Transport server role must be deployed in every Active Directory site that contains other Exchange 2010 server roles. Active Directory IP site links Active Directory IP site links define logical paths between Active Directory sites. Exchange 2010 references the IP site link objects to determine the least-cost routing path of remote Active Directory sites. Send connectors Send connectors are used for sending messages to other SMTP hosts. The address space configuration on Send connectors are used to make routing decisions. When a message is delivered to an external domain, the routing destination is typically a Send connector. An Exchange organization that accepts messages for more than one e-mail domain may decide to create Send connectors that are dedicated to each address space. For more information about Send connector selection for routing messages to external domains, see External Message Routing. Delivery agents Delivery agents are used to route messages to foreign systems that don't use SMTP protocol for message transfer. The address space and protocol configuration of delivery agents are used when making routing decisions. Foreign connectors Foreign connectors use drop directories to send messages to foreign systems that don't use SMTP protocol for message transfer. Exchange uses the configuration of Foreign connectors when making routing decisions. Routing groups Routing groups represent a routing boundary for Exchange Server 2003. If Exchange 2010 is deployed in an existing Exchange 2003 organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on Exchange 2003. To implement compatibility with Exchange 2003, all computers running Exchange 2010 deployed in the organization belong to a single, global routing group. Routing group connectors Routing group connectors define logical paths between Exchange routing groups. If Exchange 2010 is deployed in an existing Exchange 2003 organization, messages are routed between server versions through routing group connectors. When the first Hub Transport server is deployed, the setup process prompts you to create a routing group connector from the global Exchange 2010 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange is deployed, see Internal Message Routing. Microsoft Exchange Transport service The Microsoft Exchange Transport service is the SMTP provider for Exchange 2010 and controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport and perform anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery. Microsoft Exchange Active Directory Topology service The Microsoft Exchange Active Directory Topology service is responsible for locating the domain controllers and global catalog servers that Exchange 2010 can use to retrieve configuration and recipient data from Active Directory. The Microsoft Exchange Active Directory Topology service is also responsible for keeping Active Directory site affinity for an Exchange 2010 server up to date. Routing tables The routing tables hold the information that the routing component uses to make routing decisions. The routing table is composed of a map of topology components and their relationship to one another. DNS Exchange 2010 uses an enhanced Domain Name System (DNS) client, a component of the Microsoft Exchange Transport service, to resolve the next hop selection to a list of target server names. The standard DNS client is used to resolve that list of server names to IP addresses. Enhanced DNS also provides loadbalancing functionality for Exchange 2010 transport servers by using round robin. SMTP SMTP is used for communication when messages are relayed between SMTP servers. An SMTP server can be a Hub Transport server, Edge Transport server, Exchange 2003 server, or a smart host. A Hub Transport server uses remote procedure call (RPC) to deliver messages directly to Mailbox servers that have the same Active Directory site membership as the Hub Transport server. Return to top

Using Active Directory Sites for Routing


An Active Directory site is a logical configuration component that's based on the physical aspects of the network. The primary purpose for creating an Active Directory site is to define which subnets in the network are connected in a way that optimizes control of Active Directory replication traffic. The Active Directory site represents a routing boundary for Exchange 2010. Computers that have the Hub Transport server role installed make routing decisions based on the Active Directory site topology.

Determining Site Membership


By default, an Active Directory forest contains only one Active Directory site. The default name for this Active Directory site is Default-First-Site-Name. If no other Active Directory sites are created, all domain member computers in the forest are members of Default-First-Site-Name. You don't have to configure a subnet-to-site

association. If additional Active Directory sites are created, you must specify the subnets that are assigned to that Active Directory site. Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site membership to computers that are configured as domain controllers and global catalog servers. Other domain member computers, such as Exchange servers, are assigned Active Directory site membership automatically when they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site. Computers that have the same Active Directory site membership are presumed to have good network connectivity. A server is always a member of a single Active Directory site. When an application can determine the Active Directory site membership of the computer where it's installed and of other computers in the forest, and then use that information to control communication flow, it's a site-aware application. When site-aware applications must use the services of another server, such as a domain controller or global catalog server, priority is given to the servers that have the same Active Directory site membership as the computer that's requesting those services. Exchange 2010 is a site-aware application and uses the Active Directory topology for message routing and to communicate with the services that are running on computers that have other Exchange 2010 server roles installed. The Active Directory site isn't only the routing boundary. It's also the service discovery boundary. Determining site membership for a domain member computer depends on a series of DNS queries to compare the local IP address to defined subnets and then determine the appropriate site membership association. To reduce the overhead that's associated with DNS queries, the Exchange 2010 Active Directory schema additions include the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object. When site membership affinity is stored as an attribute of the server object, the current topology can be read directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for a non-domain computer, such as a subscribed Edge Transport server. The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory. The following table shows how an organization might define Active Directory sites. In this example, three Active Directory sites are defined, and each Active Directory site is associated with more than one IP subnet. Example of an Active Directory site-to-subnet association

Active Directory site name Site A

Associated IP subnets 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 192.168.6.0/24

Site B

Site C

If a server named HubTransportA has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address of a server, you may change its site membership. If you change the IP address of HubTransportA to 192.168.2.1, it won't change the server's Active Directory site membership because that subnet is also associated with Site A. However, if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of Site B. A change in site membership can also occur if you change the association of subnets to Active Directory sites. For example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site membership occurs, Exchange 2010 must update its configuration data so that the change is considered when Exchange 2010 makes routing decisions. Some latency occurs between the time that a change in an Active Directory site membership occurs and the topology change is fully propagated. The following communication must occur in the following order to propagate topology changes:

1. The change in site membership is written to a domain controller. The updated information replicates between the domain controllers in each Active Directory site in the forest. The time that's required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links. 2. The Net Logon service runs on all Windows-based computers and polls frequently for changes in Active Directory site membership. The Net Logon service polls at five-minute intervals. Therefore, the change is detected by the Net Logon service within five minutes of the local domain controller receiving the update. 3. The Microsoft Exchange Active Directory Topology service queries the Net Logon service at 15-minute intervals to determine the Active Directory site membership of the local Exchange server. If a change is detected, the Microsoft Exchange Active Directory Topology service updates the MsExchServerSite attribute. 4. The changed site attribute value of the Exchange server configuration object is then replicated throughout the organization. The Exchange servers in the organization detect this change. Then the routing tables are updated with the new Active Directory site membership attribute value. Some latency occurs between the time that an Active Directory site membership change takes effect and the time that the updated information is available to another Exchange 2010 server. For more information about how Exchange 2010 handles these types of configuration changes, see "Rerouting and the Unreachable Queue" later in this topic.

IP Site Links
Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can communicate at a uniform cost through a specified intersite transport. Site links don't correspond to the actual path taken by network packets on the physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection with a speed of 10 Mbps. By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C, Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link bridge. An Active Directory site link can be configured to use either IP or SMTP as the transport protocol for communication. An SMTP site link is limited in the types of data that can be replicated by using that protocol and is designed to provide a store and forward mechanism for replication between Active Directory sites that don't have

a reliable network link. An IP site link isn't limited in the types of data that can be replicated across it. Exchange 2010 uses only IP site links to determine its routing topology. The cost that's assigned to the IP site link will be considered by the routing component of Exchange 2010 when calculating a routing table. These costs are used to calculate the least-cost routing path to the ultimate destination for a message. Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link named DEFAULTIPSITELINK. When you create an Active Directory site, you must associate that site to an IP site link. You can create additional IP site links to implement the desired topology, or you can associate every Active Directory site to the DEFAULTIPSITELINK. Each Active Directory site that's part of an IP site link can communicate directly with every other site in that link at a uniform cost. In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with the DEFAULTIPSITELINK. Therefore, each Active Directory site communicates directly with every other site by using the same cost metric. More than one communication path is indicated, but only a single IP site link is defined. Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator has configured IP site links to create a hub-and-spoke topology of Active Directory sites. Each spoke site can communicate directly with the central site, and the spoke sites can communicate with one another by using the transitive IP site links. Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links only when determining the least-cost path, but will always try to deliver messages directly to the destination Hub Transport server. For example, if a user in Site B in the topology shown in the preceding figure sends a message to another user in Site C, the Hub Transport server in Site B will connect directly to the Hub Transport server in Site C. If you want to force messages to go through Site A, you must enable that site as a hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic. An Active Directory administrator implements the topology that best represents the connectivity and communication requirements of the forest. Because the same topology is used by Exchange 2010, you must make sure that the current topology supports efficient messaging communication. The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site link, it will be used by Exchange 2010. Otherwise, the Active Directory cost is used. For more information about how to set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who has membership in the Enterprise Administrators group can create additional IP site links. For more information about Active Directory site configuration, see Designing the Site Topology.

Controlling IP Site Link Costs


Active Directory IP site links costs are based on relative network speed compared to all network connections in the WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the existing IP site link costs should work well for Exchange 2010 message routing. However, if after documenting the existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and traffic flow patterns aren't optimal for Exchange 2010, you can make adjustments to the costs evaluated by Exchange. Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment. Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link. For example, to set a different cost on the IP site link SITELINKAB for message routing purposes, run the following command in the Shell.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

When an Exchange cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost routing path. Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange costs can also be used to control where messages are queued when communication to an Active

Directory site fails. The following figure shows an Active Directory topology with four sites. Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's only used for Active Directory replication and shouldn't be used for message routing. However, the Active Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D prevents that IP site link from being included in the least-cost routing path to Site D. Exchange 2010 provides support for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2010 doesn't impose a maximum message size limit on messages that are relayed between Hub Transport servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR) for any message that has a size larger than the maximum message size limit that's configured on any Active Directory site link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to remote Active Directory sites that must communicate over low-bandwidth connections. For more information, see Understanding Message Size Limits.

Implementing Hub Sites


In your Exchange organization, you may have to force all message delivery to be relayed through a particular Active Directory site. In this scenario, connectivity may prevent direct SMTP relay between sites. Therefore, messages must be relayed through an interim site before they're sent to their destination. Because of an Exchange organization's internal policies, an administrator may also want to relay all messages through a particular site. You can use Shell cmdlets to designate an Active Directory site as a hub site. By designating an Active Directory site as a hub site, you cause additional overall overhead because more servers are involved in message delivery. For example, consider a message that's sent from Site A to Site E. If the least-cost routing path is Site A-Site B-Site C-Site D-Site E, and you designate Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E. You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along the least-cost routing path for message delivery, the messages queue and are processed by the Hub Transport servers in the hub site before they're relayed to their ultimate destination. After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If a hub site is configured, messages stop at a Hub Transport server in the hub site before they're relayed to the target destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site along the routing path. This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path. The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site. Messages that are relayed from Site A to Site D are relayed to Site B before they're delivered to Site D. Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been designated as a hub site. However, because it doesn't

exist along the least-cost routing path between any other sites, queuing at Site B before delivery to the destination doesn't occur. An Active Directory site is never used as a hub site if it isn't on the least-cost routing path between two other sites. Misconfigured hub site

You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you must have deployed at least one Hub Transport server in the hub site.

Topology Discovery
The Exchange 2010 topology relies on the Active Directory site topology and doesn't have its own configuration. The Active Directory topology is made available to Exchange 2010 by the following required elements:

The Microsoft Exchange Active Directory Topology service The topology discovery module inside the Microsoft Exchange Transport service The Microsoft Exchange Active Directory Topology service runs on all Exchange 2010 server roles, except the Edge Transport server role. These Exchange 2010 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2010 binds to the identified directory servers whenever Exchange has to read from or write to Active Directory. The topology discovery module is part of the Microsoft Exchange Transport service and provides information about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the organization and determines their relationship to the Active Directory configuration objects. Configuration data is retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are running on that computer. The topology discovery module performs the following steps to generate an Exchange routing topology:

1. Data is read from Active Directory. All the following objects are retrieved: Active Directory sites. IP site links. All Exchange servers. This includes information about the Exchange 2010 server roles deployed on those servers. 2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects. 3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that's stored in Active Directory. 4. Routing tables are updated with the collection of information retrieved. This process makes every Exchange 2010 server aware of the other Exchange servers in the organization and of how close the Exchange servers are to one another. Return to top

Exchange 2010 Routing Tables


When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that's based on the snapshot of information that's retrieved from Active Directory or, on an Edge Transport server, from AD LDS. The configuration information that's stored in AD LDS includes available connectors and accepted domains, but doesn't include topology data. The routing component refers to the routing tables to determine how to route messages to recipients. When configuration changes are made, the routing tables are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery queues are also rerouted if the routing component determines that they're affected by the configuration changes. For more information about message rerouting, see "Rerouting and the Unreachable Queue" later in this topic. The following configuration data is retrieved from Active Directory and made available to the routing component of Hub Transport servers:

Active Directory sites Active Directory IP site links Exchange servers and their relationship to Active Directory sites SMTP connectors Non-SMTP connectors Note: Non-SMTP connectors include Exchange 2010 delivery agent connectors, Foreign connectors, and in coexistence scenarios, any non-SMTP connectors hosted

by Exchange 2003. Routing groups Routing group connectors Mailbox stores (private message databases (MDBs)) Public folder stores (public MDBs) Public folder hierarchies Based on this data, the routing component of the Microsoft Exchange Transport service populates routing tables to help streamline routing decisions. The routing table correlates the data to create a topology map. This topology map contains the following elements:

Linked connectors map This map correlates the identifiers of Receive connectors on the local server to the linked Send connector. Server map All Exchange 2010 and Exchange 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the server map. This map correlates the distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. Legacy server map All Exchange Server 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the legacy server map. This map correlates the legacy distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. This map supports store override functionality. Store override functionality is specific to public folders. For more information, see "Routing to Public Folders" in Internal Message Routing. MDB map All MDBs in the organization are contained in the MDB map. This map correlates the distinguished name of each MDB to server routing data. This includes the total cost to reach that server. Active Directory site map This map correlates each Active Directory site to a structure that contains the least-cost routing path from the local site to every other site. The map includes any hub sites along the least-cost routing path. Each routing path hop also identifies all Hub Transport servers in that site that will be used by the enhanced DNS component. Routing groups map This map associates the total cost and first hop routing group connector for the least-cost routing path from the Exchange 2010 routing group to each legacy routing group. Send connectors map This map identifies the Send connectors configured in the organization and the source servers for each connector. The routing tables are built every time that a transport server is started and recalculated when configuration changes are received. Configuration changes can be detected in any of the following ways:

Active Directory change notifications There is a delay between the time that a notification is received and the time that the change is written to the routing tables. This delay lets the routing component batch the changes and process more than one change in a single operation. By default, each notification causes the routing component to delay processing by five seconds. For example, if five notifications are received exactly one second after the previous notification, routing delays processing the change for a total of nine seconds. Configuration reloading caused by service control commands The routing component reloads the configuration data when the Microsoft Exchange Transport service is restarted. Periodic reload to track changes that aren't supported by Active Directory notifications By default, routing will periodically reload the configuration data to make sure that all changes are tracked. The configuration reload occurs at six-hour intervals. The information in the routing tables is logged to routing logs. By default, these logs are located in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing folder. A new log is generated every time that the routing tables are calculated. If for some reason the Hub Transport server is unable to contact Active Directory, routing continues to make routing decisions based on the currently cached data, even though that data may not be up to date. For more information, see Understanding Routing Table Logging. Return to top

Receiving Messages for Routing


A message can arrive at a Hub Transport server in any of the following ways:

E-mail is received from an Internet-facing SMTP server for delivery to a recipient in the Exchange organization or to a recipient in an internal relay accepted domain. E-mail is received from another Hub Transport server in the Exchange organization for delivery to a recipient mailbox that's located on a Mailbox server in that Active Directory site. E-mail is received from SMTP clients. These are typically POP3 or IMAP4 users that may exist in your environment. E-mail is received from Pickup and Replay directories on a Hub Transport server. These directories are typically used by Foreign connectors to transmit messages to your Exchange infrastructure. E-mail is retrieved from an Exchange 2010 Mailbox server by the Hub Transport server. E-mail is received from an Exchange 2007 or Exchange 2003 server for delivery to a recipient mailbox that's located on an Exchange 2010 Mailbox server. Processing of all e-mail that's received by a Hub Transport server for categorization begins in the Submission queue.

Receiving Messages from Edge Transport Servers, Other Exchange Hub Transport Servers, and SMTP Clients
In this scenario, messages are received from Edge Transport servers, Hub Transport servers, or other third-party SMTP hosts by using standard SMTP connections. The remote host initiates an SMTP connection and transfers the messages to the Hub Transport server. Hub Transport servers use Receive connectors for accepting incoming SMTP connections. Each Hub Transport server has two Receive connectors created during setup. One of these connectors is used to receive authenticated SMTP connections from other Exchange servers. The second one is used to receive SMTP connections from SMTP clients used by POP3 or IMAP4 users in your organization. These two Receive connectors have different permissions configured that are appropriate for their intended use. To learn more about Receive connectors, see Understanding Receive Connectors. By default, Hub Transport servers don't accept unauthenticated anonymous connections. If you need to enable this functionality, we recommend that you create a separate Receive connector to handle the anonymous connections. For more information, see Allow Anonymous Relay on a Receive Connector.

Collecting Messages from Pickup and Replay Directories


Messaging systems that don't use SMTP as the transfer protocol can be connected to your Exchange organization using Foreign connectors. When a message is sent to an Exchange user from a remote system, the Foreign connector writes that message to a special directory on the Hub Transport server called the Pickup directory.

The Hub Transport server periodically checks the Pickup directory for new messages. When it detects a new message, the Hub Transport server then converts the message to an Exchange e-mail message and routes it as a regular message. To learn more about how the Pickup and Replay directories are used, see Understanding the Pickup and Replay Directories.

Retrieving Messages from a Mailbox Server


In this scenario, the Microsoft Exchange Mail Submission service that runs on Mailbox servers notifies a Hub Transport server that's located in the same Active Directory site that messages are ready for retrieval from a sender's outbox. Each Mailbox server maintains a list of Hub Transport servers that are located in the same Active Directory site. This list of Hub Transport servers is known as the submission server list. The server discovery process repeats every ten minutes to keep the list up to date. If more than one Hub Transport server is located in the same Active Directory site as the Mailbox server that's submitting a notification that mail is ready for retrieval, the following process is used to select the server:

If the local Mailbox server is also running the Hub Transport server role and it is not participating in a database availability group (DAG), the local server is notified. If the local Microsoft Exchange Transport service isn't running or the local Hub Transport server can't process new mail submissions because of back pressure, another available Hub Transport server is notified. For more information about back pressure, see Understanding Back Pressure. If the local Mailbox server is also running the Hub Transport server role and is also participating in a DAG, it first tries to notify any Hub Transport server in the site before notifying the local Hub Transport server. This is done to avoid having redundant copies of messages on the same server hardware. To learn more about coexisting Mailbox and Hub Transport server roles when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. If the local Mailbox server isn't running the Hub Transport server role, notifications are load balanced among Hub Transport servers by using round robin. If the selected Hub Transport server can't be contacted, the Microsoft Exchange Mail Submission service fails over to a different Hub Transport server in the same Active Directory site. The failing server is marked as inactive, and the next Hub Transport server in the submission server list is selected. If no Hub Transport servers in the local Active Directory site are available, the submission server list is empty. In this case, an event is logged and mail submission notifications are temporarily stopped. Hub Transport servers that are marked as inactive are retried after five minutes. By default, the Microsoft Exchange Mail Submission service load balances notification events across the Hub Transport servers in a site so that each Hub Transport server receives an equal distribution of notification events to process. In some circumstances, providing an equal distribution may not be an optimal solution. Not all Hub Transport servers have the same capacity, and some messages require additional processing. For example, a message that has a large attachment or many recipients takes longer for a Hub Transport server to process than a small message that's addressed to only one recipient. If you want to create a static list of Hub Transport servers that a Mailbox server should notify, you can use the Set-MailboxServer cmdlet in the Shell. Use the SubmissionServerOverrideList parameter to specify a list of Hub Transport servers that the local Mailbox server will notify when it has mail for retrieval. For more information about how to configure this setting, see Set-MailboxServer. After a Hub Transport server receives a mail submission notification from a Mailbox server, it uses the store driver to retrieve the message from the mailbox database and put it in the Submission queue on the Hub Transport server. The transfer of the message from the Mailbox server to the Hub Transport server happens by using Exchange RPC.

Receiving Messages from Legacy Exchange Servers


Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. All messages sent from Exchange 2007 recipients are first picked up from the Mailbox servers by Exchange 2007 Hub Transport servers and are then relayed to Exchange 2010 Hub Transport servers. To learn more about message routing when coexisting with Exchange 2007, see Upgrade from Exchange 2007 Transport. As opposed to Active Directory sites, Exchange 2003 uses routing groups to route messages. Routing groups are connected to each other using routing group connectors. To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed in an Exchange 2003 organization. All messages that originate on Exchange 2003 mailboxes are delivered to the Exchange 2010 environment through the routing group connectors between the Exchange 2010 routing group and the Exchange 2003 routing groups. To learn more about message routing when coexisting with Exchange 2003, see Upgrade from Exchange 2003 Transport. Return to top

Routing Messages
After a Hub Transport server or an Edge Transport server receives a message, it determines the ultimate destination and uses the Exchange topology and connector configurations to determine the least-cost routing path. After the routing path is determined, the message is delivered to the next hop on the routing path. Although this topic explains how Exchange makes routing decisions in general, the following two topics provide additional information about specific routing scenarios. The internal message routing topic discusses message delivery to Mailbox servers, public folders, and legacy servers. The external message routing topic discusses routing messages to recipients that are outside your Exchange organization. The topic also discusses the roles of Send connectors, delivery agent connectors, and Foreign connectors.

Internal Message Routing External Message Routing

Determining the Ultimate Destination


The previous section described the various sources from which a Hub Transport server can receive messages. When a message is received by a Hub Transport server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. A single, deterministic route is selected. That route isn't recalculated unless the routing configuration changes. From the perspective of the sending server, each delivery queue represents the destination for a particular message. When the Hub Transport server or Edge Transport server selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving server also performs message categorization and queues the

message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination. The destination for a message can be classified as one of the following delivery types:

DNS connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use DNS to resolve the recipient addresses. Smart host connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use a smart host for delivery. SMTP relay in an Active Directory site to an Edge Transport server The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the source server is an Edge Transport server that's subscribed to the local Active Directory site. SMTP relay in an Active Directory site to a Hub Transport server The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be an Exchange 2007 Hub Transport server, the source server for a Send connector, a delivery agent connector or Foreign connector, the source server of a routing group connector, or a distribution group expansion server. SMTP relay to a remote Active Directory site The messages are queued for delivery to a Hub Transport server that's located in a remote Active Directory site. The ultimate destination server in the remote Active Directory site can be any of the following: The source server for a connector that's configured to transport messages for external recipients The source server for a routing group connector A distribution group expansion server A Mailbox server that's located in the remote Active Directory site The messages are delivered to one of the Hub Transport servers in the destination site. The receiving server relays the message within the Active Directory site if it's necessary. SMTP relay to a legacy routing group The messages are queued for delivery to the first hop routing group connector used to reach an Exchange 2003 routing group. The ultimate destination server can be any of the following: The source server for a connector An expansion server An Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that's located on a Mailbox server that's located in the local Active Directory site. Non-SMTP gateway delivery The messages are queued for delivery to an external recipient by using a delivery agent connector or Foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to delivery agent connectors or the Foreign connector drop directory on the local server. Unreachable A route to the recipient couldn't be determined and the messages are located in the Unreachable queue.

Determining the Least-Cost Routing Path


The least-cost routing path to the remote Active Directory site is determined by the calculation of all the costs assigned to the Active Directory IP site links that exist between the two sites. The links are bridged, and a direct connection occurs. Exchange 2010 Hub Transport servers always select a single, deterministic least-cost routing path. Availability of the underlying connection or destination server is never a consideration in routing path selection, and no alternative routing path is considered. The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. In Exchange 2010, backoff is a mechanism used to deliver messages at an interim hop along the least-cost routing path when direct relay fails for any reason, such as network issues or servers going offline. The routing component tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. First, a connection attempt is made to each Hub Transport server in the destination Active Directory site. If no Hub Transport servers in the Active Directory site respond, the least-cost routing path is checked to determine how to start backing off from the delivery site. The goal is to deliver the message as close as possible to the destination and queue it at a Hub Transport server in that Active Directory site. Depending on the individual message routing scenario, the following factors may influence the selection of a least-cost routing path:

Linked connectors If the Receive connector that the message is received on is linked to a Send connector, messages are routed to that Send connector regardless of cost. This configuration always takes precedence. The cost assigned to the IP site links and routing group connectors that must be traversed to reach the destination If more than one routing path exists between a source server and a destination server, the routing path with the lowest aggregate cost is selected. The address space assigned to a Send connector The Send connector with the most specific address space match to the destination is selected. The cost assigned to the address space configured on a Send connector If more than one Send connector is assigned the same address space, the routing component compares the cost assigned to the address space. The Send connector with the lowest cost is selected. Connector scope A connector may be limited to use by Exchange 2010 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange, the connector scope could be limited to servers that have the same routing group membership. Message size restrictions The message size constraint specified on a connector must be larger than the size of the message being routed. Connectors with a message size restriction that's less than the size of the message are eliminated from routing consideration. The proximity of the destination to the sending server Routing will prefer the server that's closest, in this order: local server, server in the same Active Directory site, or server in a remote Active Directory site or routing group. The name assigned to an Active Directory site If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the Active Directory sites that precede the target site along each routing path. The routing path where the Active Directory site nearest to the destination is lowest in alphanumeric order is used. The name assigned to a routing group connector If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the routing group connectors that come before the target destination along each routing path. The routing path where the routing group connector nearest to the destination is lowest in alphanumeric order is used. The connector state The Exchange 2010 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange don't consider connector state. The following logic is used to select the routing path:

1. First, calculate the least-cost routing path by adding the cost of the IP site links and of any routing group connectors that must be traversed to reach the destination. If the destination is a connector, the cost assigned to the address space is added to the cost to reach the selected connector. If multiple routing paths are possible, only the routing path with the lowest aggregate cost is used. 2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used. 3. If more than one routing path is still available, the name assigned to the Active Directory sites or routing group connectors before the destination are considered. The routing path where the Active Directory site nearest the destination is lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths being evaluated, an earlier site name is considered. The following figure shows the routing topology for an Exchange organization. This topology is used in the following examples to demonstrate the logic used by the

routing algorithm to select the least-cost routing path. Exchange 2010 routing topology

Example 1 A message that's being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D. Example 2 A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops. Example 3 A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of 10. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E. After the least-cost routing path has been determined, the Exchange 2010 routing component doesn't consider alternative routing paths.

Next Hop Selection


Exchange 2010 Hub Transport servers don't relay to each Active Directory site along the least-cost routing path. After the routing path is determined, the message is relayed directly from the source server to the next hop. The next hop selection tries to deliver the messages as close as possible to the ultimate destination. Additional intrasite relay may be required to arrive at the ultimate destination. When routing to legacy routing groups, direct relay to the Active Directory site where the source server for the first hop routing group connector resides occurs. After the message is relayed to the legacy environment, standard legacy routing occurs. The following figure shows a simple Exchange topology and illustrates many of the Exchange routing components. Exchange topology and routing components

Using the preceding figure as a reference, a message that's sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:

1. The Microsoft Exchange Mailbox Submission service that's running on Mailbox1 notifies an Exchange 2010 Hub Transport server that's located in the same Active Directory site of the new mail item for transport. 2. Using RPC, the store driver component on an Exchange 2010 Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server. 3. From the Submission queue, the message moves through categorization. The categorizer first performs recipient resolution and determines that

joe@contoso.com is an external recipient. 4. The routing component selects the best connector through which to route the message and calculates the least-cost routing path to that connector. In this example, a Send connector has the address space *.contoso.com and is the connector selected by the routing component. All the source servers for this Send connector are located in Site B. 5. The routing component determines the next hop required to reach a source server for the Send connector. The Hub Transport server in Site A queues the message for SMTP delivery to Site B. 6. If the receiving server in Site B is a source server for the Send connector, it queues the message for delivery to that Send connector. If the receiving server isn't a source server for the *.contoso.com Send connector, the message is relayed by using SMTP to a Hub Transport server in Site B that's the source server for the connector. The following table provides additional examples of the next hop selection for several recipients based on the topology shown in the preceding figure. It isn't a complete list of all routing possibilities. It simply provides examples that are most common in a topology like the one shown in the preceding figure. Examples of next hop selection in the preceding figure

Receiving server Hub1 Hub1 Hub1 Hub1 Hub1 Hub3 Hub4 Hub4 Hub4 Hub4 Edge1

Ultimate destination Mailbox1 Mailbox2 Mailbox3 Mailbox4 Recipient@fourthcoffee.com Mailbox1 Mailbox1 Mailbox4 Recipient@contoso.com Recipient@fourthcoffee.com Recipient@fourthcoffee.com

Next hop Mailbox1 Hub3 Site B Routing group connector Edge1 Hub1 or Hub2 Site A Site A Contoso SMTP Host Site A Fourth Coffee SMTP Host

Queue delivery type MAPI delivery SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a legacy routing group SMTP relay to Edge Transport SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a remote Active Directory site Smart host delivery SMTP relay to a remote Active Directory site DNS delivery

After the least-cost routing path has been calculated and the next hop destination has been chosen, Exchange 2010 routing tries to relay the message directly to the destination, unless a hub site is configured along the least-cost routing path.

Queue at Point of Failure


The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. Exchange 2010 tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. This behavior is known as queue at point of failure. When the messages are queued at the point in the delivery path where communication failed, it not only speeds up delivery after the problem is resolved, but it will also help you determine why the message delivery failed. In the topology shown in the following figure, if a message is being delivered from Site A to Site D, the least-cost routing path may be Site A-Site B-Site C-Site D. Delivery will first be tried directly from Site A to Site D. If no Hub Transport server in Site D responds, delivery will be tried to the Hub Transport servers in Site C. This process continues until a Hub Transport server accepts the message. If all intermediate sites are unavailable, the message will be queued at the source site. If the message is queued in Site C, you can start investigating the failure at the Hub Transport servers in Site D or the network connectivity between Site C and Site D. Queue at point of failure

When the message is queued at the point of failure, the queue is put in a retry state and delivery attempts continue based on the message retry intervals until delivery succeeds or the message expires. The queue is automatically resubmitted for categorization again after a default interval of 12 hours. Queues that have a connector as the next hop destination aren't automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue. You can use the Mail Flow Troubleshooter to help diagnose problems with mail flow. This tool is a component of the Microsoft Exchange Troubleshooting Assistant and can be run from the Toolbox of the Exchange Management Console. In more complex topologies, the least-cost routing path between two Active Directory sites can contain many intermediate Active Directory sites. If a network issue occurs somewhere early along the routing path, it may be too inefficient to back off site by site from the end and try to deliver to every one of the intermediate sites. If the routing path is longer than four hops, binary backoff is implemented until four or fewer sites are remaining. Binary backoff means that the next connection attempt is made at the halfway point in the routing path. For example, if the least-cost routing path from Active Directory Site A to Site G is A - B - C - D - E - F - G and the network failure occurs at the link between Site B and Site C, the first connection attempt is made to all Hub Transport servers in Site G. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site D. This is halfway to Site G. When that connection attempt fails, connection attempts are

made to Site C, and Site B because they're closer than four links to the source site. The message will eventually be queued on a Hub Transport server in Site B until the B-C link connectivity is restored.

Delayed Fan-Out
A single e-mail message can be addressed to more than one recipient. These recipients may have internal mailboxes, or they may be external recipients. To route a single message to more than one recipient, the following steps occur:

1. Recipient resolution Each recipient of the message is resolved to a delivery destination. 2. Routing The least-cost routing path for each recipient is determined. This includes whether a hub site is configured. 3. Message splitting To route the message to recipients that have different delivery locations, the message must be split into multiple copies. After each recipient has been resolved and a routing path to each delivery destination is determined, Exchange 2010 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, doesn't occur until a fork in the routing path is encountered. For example, if multiple recipients of a single message share part or all of the least-cost routing path, a single copy of the message is sent until the message reaches the point in the routing path where a fork occurs. When the divergence in routing paths occurs, the message splits to create a separate copy for each recipient. In the following figure, a single message is sent from Site A to recipients in Site C, Site D, and Site E. The least-cost routing path is shared until the message reaches Site B. In this scenario, a single copy of the message that contains all recipients is relayed to Site B. This represents the first fork in the routing path. From Site B, a single message copy is routed to the recipient in Site D, and a single copy is relayed to Site C. In Site C, the message splits again. A copy of the message is delivered to the recipient in Site C. And, a copy of the message is relayed to Site E for delivery to the recipient in that site. Delayed message fan-out

Return to top

Rerouting and the Unreachable Queue


If routing is unable to determine a route for a valid recipient for any reason, the messages are put in the Unreachable queue. Messages in this queue are rerouted when configuration changes are processed and routing tables are recalculated. Messages aren't rerouted in the following scenarios. Instead, an NDR is returned to the sender. The following scenarios result in a message being routed to the Unreachable queue:

The recipient is a non-SMTP address and a matching connector for the address space can't be found. The message doesn't meet the message size restrictions of any matching connector. Not all configuration changes require resubmission of the messages in the queue. For example, a change to the list of smart hosts for a connector doesn't cause messages to be rerouted. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

External Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Microsoft Exchange Server 2010 handles the routing of messages to external recipients. An external recipient is any message recipient that doesn't have a mailbox in the Exchange organization. Exchange uses Send connectors to route messages to external SMTP domains. If the external recipient isn't on an SMTP messaging system, a Delivery Agent connector or a Foreign connector is used instead. For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Send Connectors Delivery Agent Connectors Foreign Connectors Connector Considerations Selecting the Routing Path to an External Recipient Routing Examples

Send Connectors

To route messages to external SMTP domains, you must configure at least one Send connector to relay messages to the Internet. You can configure a Send connector and define the address space as the asterisk (*) wildcard character. The * character indicates that the Send connector can be used to relay messages to all external SMTP addresses. You can also configure Send connectors to relay messages to specific address spaces when Send connector restrictions, such as message size, vary for those external domains. When you configure a Send connector, you must select at least one source server for that Send connector. The source servers are the transport servers associated with that connector to handle message delivery. The source server for a Send connector can be a Hub Transport server, an Edge Transport server, or an Edge server subscribed to an Active Directory site. You can configure more than one source server for a Send connector to provide load balancing and fault tolerance for the address spaces defined on that Send connector. However, each Exchange 2010 source transport server you specify must be in the same Active Directory site. For more information about how to configure your Exchange organization to send and receive Internet e-mail, see Managing Message Routing. When Exchange is processing a message sent to an external recipient, the routing component of the Microsoft Exchange Transport service must select the best Send connector through which to route the message, and then calculate the least cost routing path to reach that Send connector. To learn more about Send connectors, see Understanding Send Connectors. Return to top

Delivery Agent Connectors


Delivery Agent connectors are used to route messages addressed to messaging systems that don't use SMTP. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management for non-SMTP messages, thereby eliminating the need for storing messages on the file system in the Drop and Pickup directories. For more information, see Understanding Delivery Agents. Return to top

Foreign Connectors
Foreign connectors are used to send messages to third-party messaging systems. Each Foreign connector uses a Drop directory configured on the source Hub Transport servers for receiving messages. The foreign gateway server must be configured to obtain messages from the Drop directory specified for that Foreign connector. For more information about Foreign connectors, see Understanding Foreign Connectors. Return to top

Connector Considerations
Restrictions applied to the connectors may eliminate a specific connector from routing consideration. The following configuration options on connectors can determine whether those connectors are considered when making routing decisions. For more information about configuring connectors, see Managing Connectors.

Connector State
You can disable and enable any connector in your organization. If a connector is disabled, it's not considered when routing messages. For example, if an Exchange 2010 Send connector is disabled, messages aren't routed to that connector. Note: Exchange Server 2003 doesn't detect the disabled state of connectors. Therefore, if Exchange 2003 is deployed in the same organization, it may route to that connector.

Connector Scope
Routing only considers connectors in scope for the sending server. By default, no scope limitation is applied to connectors, and they are available to all Hub Transport servers in the organization. However, you can specify a local scope for a connector. If you configure a connector as scoped, the availability of that connector is limited to Hub Transport servers located in the same Active Directory site as the source servers for the connector. Scoped connectors aren't considered when routing by Hub Transport servers in other Active Directory sites.

Address Space
The address space for a connector specifies the following:

Recipient domains to which this connector routes e-mail Address space type Cost assigned to the address space for that connector When you create a Send connector, the address space type is always configured as SMTP by default. Even though you can also specify a non-SMTP address space for a Send connector, the messages are still sent using SMTP. If you need to use a different transport protocol for transmitting messages to their destination, you must use a Delivery Agent connector or a Foreign connector. When the Microsoft Exchange Transport service selects a connector for routing, it only considers connectors that have a matching address space for the destination domain. You can use the wildcard character * in an address space to indicate all domains, all domains that have a particular top-level domain, such as *.com, or a second-level domain and all its subdomains, such as *.contoso.com. When you configure a connector for a particular domain, e-mail sent to that domain is always routed through that connector. If more than one connector matches the address space for the destination recipient domain, the connector with the more precise address match is selected. For example, if Send connector C1 is configured to have the address space *.contoso.com and Send connector C2 is configured to have the address space northamerica.contoso.com, e-mail addressed to user@europe.subdomain.contoso.com is routed to Send connector C1 and e-mail addressed to user@northamerica.contoso.com is routed to Send connector C2. Even though the latter address matches the address spaces on both connectors, the address space of C2 is a better match.

Message Size Restrictions


A message size restriction on a connector may also remove that connector from consideration during routing path selection if the message being routed is larger than the size restriction configured on that Send connector.

Cost
Connector cost is used to set selection priority when more than one connector is configured for the same address space. During routing, when the connector selection is made, the lowest cost routing path to the destination is selected. By adjusting connector costs, you can control the preferred routing path for mail flow in your organization and to the Internet. When you create a connector, the default cost is set to 1. Return to top

Selecting the Routing Path to an External Recipient


When a message is sent to an external recipient, Exchange 2010 will always select a single connector through which to send the message. The selected connector must meet the message size constraints. After Exchange 2010 has eliminated all connectors whose message size restrictions are less than the size of the message being routed, routing applies the following criteria to determine which connector it will select:

1. From the list of all the connectors configured in the Exchange organization, Exchange narrows the list to connectors that satisfy all the following criteria: In the scope for the local server Enabled With an address space that matches the recipient's e-mail domain 2. From the resulting list, Exchange selects the connector with the most specific address space match. If more than one connector meets the address space match criteria, Exchange 2010 routing evaluates the following criteria to select a connector:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the IP site links between the source Active Directory site and the Active Directory site that contains the source servers for the connector, and the cost assigned to the connector. The connector with the lowest aggregate cost is selected. If more than one connector has the same cost, the selection process continues to the next step. 2. Proximity The source server that has the closest proximity to the routing server is selected. This means that the local server is chosen over another Hub

Transport server in the same Active Directory site, and a server in the local Active Directory site is chosen over a source server in a remote Active Directory site. If more than one connector matches the criteria, the selection process continues to the next step. 3. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected.

Routing Path Selection When Coexisting with Exchange 2003


In a coexistence scenario, the selection varies slightly depending on whether the source server for the selected connector is an Exchange 2010 or Exchange 2003 server. If more than one connector meets the address space match criteria, and they are all are hosted on servers running Exchange 2003, the following selection method is used:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the routing group connectors between the routing server and the routing group that contains the source servers for the connector and the cost assigned to the connector. 2. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected. If more than one connector meets the address space match criteria, and they are spread across Exchange 2010 and Exchange 2003, Exchange 2010 will always prefer Exchange 2010 connectors. When a connector is selected, if there are legacy servers listed as source servers as well as Exchange 2010 servers, messages are routed to the Exchange 2010 servers. When all things are equal, Exchange 2010 will always route the messages to other Exchange 2010 servers. After a connector is selected by using the previous criteria, there may be more than one routing path to reach the Active Directory site where the source server for the selected connector is located. In this case, the lowest cost routing path to the connector is calculated by using the logic used for intra-organizational routing. For more information, see Internal Message Routing.

Handling Messages That Can't Be Routed


If no connector satisfies all criteria required to select a connector according to the logic described earlier, one of the following actions occurs:

If there is no matching connector for an SMTP address space, the recipient is marked as unreachable and the message is routed to the Unreachable queue. If the message size exceeds the connector size restriction for all connectors, a non-delivery report (NDR) is returned to the sender. If there is no matching connector for a non-SMTP address space, an NDR is returned to the sender. Return to top

Routing Examples
The following examples illustrate how messages are routed to external recipients.

Example 1: Selecting a Connector Based on Address Space Match


In this topology, a message is being routed from Active Directory Site A to the external recipient, john@subdomain.contoso.com. The following figure shows that two connectors can route messages to this address space.

The following table shows the configuration of two Send connectors in an Exchange 2010 topology.

Examples of Send connector configurations


Send connector name C1 C2 Address space *.contoso.com subdomain.contoso.com Connector cost 1 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

In this scenario, the message is routed by using C2 because the most specific address space match is chosen. C1 has a lower routing cost, and the source servers are located in the same site as the Hub Transport server processing the message. However, the address space match takes priority over the other factors.

Example 2: Selecting a Connector Based on Proximity

In this scenario, a message is being routed by a Hub Transport server located in Active Directory Site A to the external recipient, john@subdomain.contoso.com, as shown in the following figure.

The following assumptions apply:

The routing server isn't listed as a source server for any Send connector. The IP site link between Site A and Site B is assigned a cost of 5. Two Send connectors can route messages to the address space. The following table shows the connector configuration.

Alternative Send connector configuration


Send connector name C1 C2 Address space subdomain.contoso.com subdomain.contoso.com Address space cost 15 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

Because both connectors have the same address space match, the connector cost is evaluated next. The cost assigned to connector C2 is added to the cost of the IP site link between Active Directory Site A and Site B, for a combined cost of 15. The source servers for connector C1 are located in the local Active Directory site. Therefore, the IP site link cost to reach the connector is 0, for a total cost of 15. In this scenario, both connectors match the address space equally and have an equal cost. Routing selects connector C1 because it has a closer proximity.

Example 3: Selecting a Connector Based on Exchange Version


In the next example, a message is being relayed from Active Directory Site A to the external recipient, john@contoso.com, as shown in the following figure.

The following assumptions apply:

There are two Send connectors that match the destination address space equally. The source servers for the routing group connector between Exchange 2003 and Exchange 2010 are located in Site A. The routing group connector has a routing cost of 5. The IP site link between Site A and Site B is assigned a cost of 5. The source server for one of the Send connectors is an Exchange 2003 server located in routing group 1. The following table shows the connector configuration.

Connectors configured on different versions of Exchange


Connector name C1 C2 Address space *.contoso.com *.contoso.com Address space cost 10 1 Source servers Hub Transport servers in Active Directory Site B Exchange 2003 bridgehead servers in routing group 1 Message size restrictions None None

In this scenario, the aggregate cost of using connector C1 is 15, which is the sum of the IP site link cost and the Send connector cost. The aggregate cost of using connector C2 is 6, which is the sum of the routing group connector cost and the Send connector cost. However, even though C1 has a lower routing cost, Exchange will still route the message to the Exchange 2010 connector. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Message Rerouting and the Unreachable Queue


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 In Microsoft Exchange Server 2010, there are message routing scenarios where a message that isn't delivered is put in the Unreachable queue or rerouted. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. The decision to reroute a message occurs during the message delivery phase in the SMTP Send connector process. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for categorization in the message delivery phase and rerouted with the new configuration information. Depending on the type of configuration change, some or all resubmitted messages may be sent to the Unreachable queue or to a different delivery queue. For more information about how the least-cost routing path is computed, see Understanding Message Routing. For more information about how the categorizer works, see Understanding Transport Pipeline. Looking for management tasks related to message routing? See Managing Message Routing.

Message Rerouting
There are two types of message delivery in Exchange:

Local delivery refers to delivery of messages sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred. Remote delivery refers to delivery of messages to recipients in other Active Directory sites of the Exchange organization and to external recipients. Remote delivery queues are the main focus of message rerouting. Remote delivery can be affected by configuration changes in various ways. The routing component of the categorizer tries to detect whether messages in a queue must be rerouted during enhanced Domain Name System (DNS) resolution. During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. In this phase, the NextHopSolutionKey attribute is resolved to a list of targets. This enables routing to automatically detect any configuration changes that invalidate or modify the NextHopSolutionKey attribute. If routing detects that configuration changes require rerouting of messages in a queue, the messages in the affected queue are resubmitted to the categorizer and the least cost path is recalculated, taking the new configuration changes into account. The store driver, which delivers inbound messages to the Exchange databases, may also reroute messages. It resubmits a message for rerouting if either of the following conditions is true:

The message is in a MAPI delivery queue, and the next hop has been selected, but the message hasn't been delivered. The destination mailbox is moved to another Mailbox server. If a Mailbox server is unavailable when the store driver tries to deliver the messages to that Mailbox server, the store driver puts the message queue in a retry state. If continued attempts to contact the Mailbox server are unsuccessful, when the retry interval expires, all messages in the queue are resubmitted to the categorizer. If a message is located in a non-SMTP gateway delivery queue (a queue being routed to a Delivery Agent connector or a Foreign connector), the foreign gateway connection handler determines whether the configuration change requires rerouting. The foreign gateway connection handler is a component of the Microsoft Exchange Transport service that manages delivery of messages to Delivery Agent connector queues and Foreign connector Drop directories. For example, deleting or disabling a Foreign connector requires rerouting messages to another connector. The following list summarizes the types of configuration changes that affect message routing. Each configuration change is discussed in detail later in this topic:

Invalid next hop The next hop for the message has been deleted or modified, therefore invalidating the previously calculated routing path. The next hop for a message may be an Active Directory site, a connector, or a transport server (either a Hub Transport server or Edge Transport server). Changes to next hop The configuration of the next hop has changed in a way that affects connectivity. For example, changes to the list of Hub Transport servers in the remote Active Directory site cause the next hop connection to be modified. Less preferred routing paths When configuration changes occur along a previously computed routing path, messages already routed are delivered if the routing path is reachable. But new messages are rerouted with the updated configuration changes. Unavailable next hop Network connectivity or target server availability cause the next hop to be unavailable for connectivity. However, the next hop doesn't change. An example is when the Hub Transport servers in an Active Directory site are offline. Additional scenarios where rerouting occurs In some cases, configuration changes may be caused when DNS MX resource record resolution fails for a DNS connector or a smart host connector. Configuration changes that cause message rerouting or delay When specific configuration changes are detected during the message delivery phase, routing actions occur, and messages are rerouted or delivery is delayed.

Invalid Next Hop


Configuration changes can invalidate a previously calculated next hop. In these circumstances, the routing component of the categorizer can detect the configuration change and reroute to compensate for that change.

Delivery to an SMTP Connector on the Local Computer


When a message is being delivered to an SMTP connector on the local computer, the server that received the message for relay to its destination is also the source server for the Send connector through which the message is routed. This kind of delivery occurs when either of the following conditions is true:

The message was received on a linked Receive connector. The recipient has an external address, and a source server for the selected connector is the local computer.

If the Send connector selected by the routing component of the categorizer is deleted or disabled, the configuration change is detected during the message delivery phase. This causes all messages in the queue to be categorized again. If the configuration of the Send connector is changed to remove the local server as a source server of the connector, the configuration change is detected during the message delivery phase, and all messages in the queue are categorized again. A change of the address resolution method of the Send connector causes the queue to be rerouted. A Send connector can be configured to use DNS to resolve MX records and route messages automatically or it can be configured to route all messages through one or more smart hosts. If you change the address resolution of a Send connector, the messages routed through that Send connector are rerouted.

SMTP Relay in an Active Directory Site


SMTP message relay in an Active Directory site occurs in the following scenarios:

The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Hub Transport server located in the local Active Directory site. The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Edge Transport server subscribed to the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2007 in the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2003, and at least one of the source servers for the selected routing group connector is an Exchange 2010 Hub Transport server in the local Active Directory site. The recipient is a distribution group, and the expansion server for the group is an Exchange 2010 Hub Transport server in the local Active Directory site. In the first four scenarios, if the Send connector is deleted or disabled, the configuration change is detected during the message delivery phase, and the queue is resubmitted. In the last scenario, the messages are queued for delivery to an expansion server and the NextHopSolutionKey attribute contains the fully qualified domain name (FQDN) of the expansion server for the distribution group. If the Hub Transport server role is uninstalled from the specified expansion server, that configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to a Remote Active Directory Site


When a message is being delivered to a remote Active Directory site, the next hop is a different Active Directory site than the Hub Transport server processing the message. This kind of delivery occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder, and the destination computer is an Exchange 2010 server in a remote Active Directory site. The recipient is an external address, and the source servers of the Send connector selected for that address are Exchange 2010 servers in a remote Active Directory site. The recipient is an external address, and the source servers of the Foreign connector selected by the routing component of the categorizer are Exchange 2010 servers in a remote Active Directory site. The recipient is a distribution group, and the expansion server is an Exchange 2010 Hub Transport server in a remote Active Directory site. The recipient's mailbox is located on an Exchange 2003 server, and the closest Hub Transport server listed as a source server for the selected routing group connector is located in a remote Active Directory site. In these scenarios, if the remote Active Directory site is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to an Exchange 2003 Server


When a message is being delivered to an Exchange 2003 server, the Exchange 2010 Hub Transport server relays the message through a routing group connector to an Exchange 2003 server. This delivery type occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder located on an Exchange 2003 server. The recipient is an external address, and the source servers for the SMTP connector selected for that address are Exchange 2003 servers. The recipient is an external address, and the source servers for the selected Foreign connector for that address are Exchange 2003 servers. The recipient is a distribution group, and the designated expansion server is an Exchange 2003 server. In these scenarios, if the routing group connector is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

Changes to Next Hop


In some scenarios, the next hop isn't invalidated. However, it's modified in a way that affects the connection to a next hop target. Such configuration changes are automatically detected during the message delivery phase, and messages are delivered to the new targets. The following types of changes cause an update of the list of next hop targets:

Changes to the target server list of a routing group connector. Changes to the list of Hub Transport servers in the remote Active Directory site. Changes to the list of Hub Transport servers or Edge Transport servers in the local Active Directory site. The introduction of hub sites along a previously calculated routing path. When this change is detected during the message delivery phase, the IP address list returned to the resolve request is adjusted so that the message is sent to the hub site.

Less Preferred Routing Paths


If a configuration change causes the previously calculated routing path to become less preferred or removes the routing path from consideration, the routing path is still reachable and the messages can still be delivered along the previously calculated routing path. The following configuration changes are in this category:

Message size restrictions are added along the routing path. This causes messages that exceed the size limit to be routed along a different routing path. A routing path with better cost or proximity is created. The address space of the connector changes. Other connector-related changes occur, such as the enabling of a connector or modification of the scope for a connector. For example, if a connector whose scope is changed from global to scoped is in the local Active Directory site, the change has no effect. If the connector is in a remote Active Directory site, the change isn't detected during the message delivery phase because the messages are queued to the remote Active Directory site instead of to the connector. As the routing path tries to SMTP-relay to a Mailbox server in the remote Active Directory site, the Mailbox server moves from a remote Active Directory site to a local Active Directory site. The routing path is trying to reach the expansion server for a distribution group when it's no longer an expansion server. In these scenarios, existing messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.

Unavailable Next Hop


In this scenario, a configuration change or network connectivity change doesn't invalidate the next hop to which messages are routed but a configuration change or network connectivity change makes the next hop unavailable. This means that an SMTP connection can't be established to the next hop target for some reason. Possible reasons are as follows:

An attempt is made to establish an SMTP connection with a currently offline Hub Transport server in the local site. A remote Active Directory site has unavailable or offline Hub Transport servers. A remote routing group has unavailable or offline Exchange 2003 bridgehead servers. Remote domains are unavailable because of network connectivity issues. Message delivery failures caused by network connectivity problems aren't detected by the routing component of the categorizer. When an SMTP connection can't be established to the next hop target, the SMTP Send connector retries the queue. The MaxIdleTimeBeforeResubmit parameter, which is located in the EdgeTransport.exe.config file, has a default value of 12 hours. After the configurable retry interval (MaxIdleTimeBeforeResubmit) has expired without successfully establishing a connection, all messages from the delivery queue are resubmitted to the Submission queue. If the connectivity problem still exists, this process is repeated. If the connectivity problem is resolved, messages are delivered as soon as message retry is successful. Or, a configuration change that modifies the next hop destination may resolve the problem. For example, if the problem is caused by all the Hub Transport servers in a destination site being offline, and you move mailboxes to a server in a different site, the next hop would change to the new site. Note: The automatic resubmission from the message delivery queue to the Submission queue only happens for queues that aren't connector queues. Connector queues remain in retry mode until the problem is fixed, or the messages expire and a non-delivery report (NDR) is sent.

Additional Scenarios Where Rerouting Occurs


In addition to the scenarios described earlier in this section, the following scenarios cause messages to be rerouted during the message delivery phase:

DNS MX resolution fails for a DNS connector. If the DNS MX resolution fails because the authoritative host for the MX record wasn't found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry mode until a connection is established or the messages expire. DNS MX resolution fails for a smart host connector. The queue is put into retry mode until the messages expire.

Configuration Changes That Cause Message Rerouting or Delay


The following table summarizes the routing actions taken when specific configuration changes are detected during the message delivery phase, and messages are rerouted or delivery is delayed.

Configuration changes that cause message rerouting and delay


Routing scenario Message is routed to a DNS connector configured on the local server. Configuration change The connector is deleted. The connector is changed to a smart host connector. The connector is modified to remove the local server from the source server list. A fatal DNS MX resolution failure occurs. A DNS MX resolution failure that isn't fatal occurs. Routing action The queue is resubmitted. The queue is resubmitted. The queue is resubmitted. Configuration change and routing action

An NDR is sent. The queue is retried until messages

expire. The connector is disabled. The queue is resubmitted.

Message is routed to a smart host connector configured on the local server. Configuration change The connector is deleted. The connector is modified to remove the local server from the source server list. The connector is changed to a DNS connector. The smart host list for the connector is modified. Any DNS MX resolution failure occurs. The connector is disabled. The SMTP server is offline or the destination isn't running an SMTP server. Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted.

The updated smart hosts list is automatically detected and used during the message delivery phase. The queue is retried until messages expire. The queue is resubmitted. The queue is retried until messages expire.

Message is routed to a connector with a source Hub Transport server or Edge Transport server in the local Active Directory site.

Configuration change The connector is deleted. The source server list for the connector is modified to remove or add Hub Transport or Edge Transport servers in the local Active Directory site. The source server list for the connector is modified to remove all Hub Transport or Edge Transport servers in the local Active Directory site.

Routing action The queue is resubmitted. Changes to source servers in the local site are automatically detected and used during the message delivery phase. The queue is resubmitted.

Message is routed to an expansion server for a distribution group in the local Active Directory site. Configuration change The server is no longer configured for the Hub Transport server role. Routing action The queue is resubmitted.

Message is routed to a transport server in the local Active Directory site. Configuration change The server is offline or the Microsoft Exchange Transport service isn't running. Routing action The queue is resubmitted after an interval.

Message is routed to a remote Active Directory site. Configuration change The remote Active Directory site is deleted. The link to the remote Active Directory site is deleted. Therefore, the site is unreachable from the local site. The list of Hub Transport servers in the remote Active Directory site changes. All Hub Transport servers in the remote Active Directory site are removed. Hub sites are introduced along the routing path of the destination Active Directory site. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase so that the messages are relayed to the hub site. The queue is resubmitted after an interval.

All Hub Transport servers in the remote

Active Directory site are offline. The remote site is the delayed fan-out point, and all Hub Transport servers in the site are offline. The queue is resubmitted after an interval.

The message is routed to an Exchange 2003 server in a remote routing group. Configuration change The connector is deleted. The source Hub Transport server list for the connector changes to remove the local server from the list. The target bridgehead server list for the connector is changed by removing or adding bridgehead servers in the remote routing group. All Exchange 2003 bridgehead servers in the remote routing groups are offline. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is retried until messages expire.

The message is routed to a destination, and there are configuration changes, but the destination is still reachable.

Configuration change The routing path becomes less preferred because a new routing path appears with a reduced cost or closer proximity, or both.

Routing action Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase.

The routing path is removed for a message because maximum message size restrictions are added along the path.

A previously disabled routing path comes into consideration with a reduced cost because the connector is enabled, put back in scope, or has no message size restrictions. The connector address space changes.

The connector is changed to add local Hub Transport or Edge Transport servers to the source server list.

The message is relayed to a Mailbox server in the remote Active Directory site, while the Mailbox server housing the destination mailbox database is moved to a different site. The message is relayed to a distribution group expansion server when it's no longer an expansion server. (The distribution group's HomeMTA attribute is modified.)

The message is routed by using MAPI delivery to a Mailbox server. Configuration change The mailbox moves to a different Mailbox server. The Mailbox server is offline. Routing action The store driver detects the change and resubmits the messages. The queue is retried and resubmitted after an interval.

The message is routed by using a non-SMTP gateway to a non-SMTP connector configured on the local server.

Configuration change A Foreign connector is deleted. A Foreign connector is modified to remove the local server from the source server list. The connector is disabled. The Drop directory isn't found.

Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted. The queue is retried until

messages expire.

Unreachable Queue
The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by misspelled e-mail addresses, or configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. Messages in the Unreachable queue are rerouted after configuration changes are processed. There is only one Unreachable queue for each Exchange 2010 transport server. During categorization, messages are put in the Unreachable queue when the following conditions are true:

The recipient is a valid Active Directory recipient object. However, a routing path can't be calculated for that recipient. The recipient is an external SMTP address and a matching connector can't be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it's disabled or configured incorrectly. The recipient is a distribution group. The expansion server for the distribution group is invalid or doesn't have the Hub Transport server role installed. The recipient is an SMTP address recipient of a message received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because it's disabled or configured incorrectly in some way. In the following scenarios, messages aren't put in the Unreachable queue, and NDRs are sent instead:

The routing path can't be calculated for a recipient because constraints, such as message size restrictions, prevent delivery of the message using the single, deterministic route calculated by the categorizer. The recipient is a non-SMTP address and a matching connector can't be found. Or the matching connector is disabled or configured incorrectly. The recipient is a non-SMTP address recipient received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because the Send connector is disabled or configured incorrectly. Messages in the Unreachable queue are resubmitted to the categorizer when the routing tables are rebuilt because of configuration changes. The old routing tables and new routing tables are compared. The Unreachable queue is resubmitted only if the old routing tables and new routing tables aren't the same.

Scenarios Where Messages Are Put in the Unreachable Queue


This section describes some scenarios where messages are put in the Unreachable queue.

Routing group connector between an Exchange 2010 organization and Exchange 2003 organization doesn't exist A routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups hasn't been configured, or the last routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups has been removed. No routing group connector exists to provide a routing path to the Exchange 2003 recipients. To resolve this problem, first verify that the routing group connector is missing. If that's the case, you can create a routing group connector. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. Check the configuration of the routing group connector.

Destination Active Directory site doesn't have Hub Transport servers The destination Active Directory site has no Hub Transport servers. In this scenario, messages to recipients in that site are sent to the Unreachable queue. To resolve this problem, deploy a Hub Transport server in the Active Directory site. For more information, see Overview of the Hub Transport Server Role.

Active Directory site link doesn't exist between two Active Directory sites An Active Directory site link has been removed and as a result, a disconnected Active Directory site contains Exchange 2010 servers. To resolve this problem, create an Active Directory site link by using Active Directory Sites and Services.

Other issues When a message is put in the Unreachable queue, the last error message specifies why the message was placed in the Unreachable queue. If more than one recipient of the same message is routed to the Unreachable queue, but for different reasons, the last error available on each recipient specifies the reason for each. When inconsistencies are found during routing table computation, events are logged in the Application log of Windows Event Viewer. The last error message and these events can help you determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully. You can also manually force the messages in queues to be resubmitted. For more information, see Resubmit Messages in Queues.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Internal Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Internal message delivery involves a routing process that relays e-mail in the following ways:

From a server running Microsoft Exchange Server 2010 that has the Hub Transport server role installed to an Exchange Server 2007 or Exchange 2010 Hub Transport server in a different Active Directory site From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server located in the same Active Directory site From an Exchange 2010 Hub Transport server to a Hub Transport server running Exchange 2007 for delivery to a recipient mailbox located on an Exchange 2007 server From an Exchange 2010 Hub Transport server to a server running Exchange Server 2003 for delivery to a recipient mailbox located on an Exchange 2003 server From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server for delivery to a mail-enabled public folder For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Routing Messages for Delivery to Exchange 2010 Servers Routing Messages for Delivery to Exchange 2007 Servers Routing Messages for Delivery to Exchange 2003 Servers Routing to Public Folders

Routing Messages for Delivery to Exchange 2010 Servers

In Exchange 2010, after a message is received by the Hub Transport server, the message is added to the Submission queue. Messages move from the Submission queue through the categorizer. When the message is categorized, a recipient's e-mail address is resolved to an object in Active Directory. This query determines the mailbox associated with that e-mail address and which Mailbox server is hosting that mailbox. After information about the recipient is resolved, the next step is resolving the Mailbox server to an Active Directory site. This Active Directory site information is stamped on the message as the NextHopSolutionKey attribute. The enhanced DNS component of the Microsoft Exchange Transport service accesses the topology information to determine which Hub Transport servers are located in the same site as the destination Mailbox server. A list of Hub Transport servers in the Active Directory site is then referenced to determine where to route the message. If the destination Mailbox server is located in the same site as the querying Hub Transport server, that Hub Transport server queues the message for local delivery. If the destination Mailbox server is located in a different site, the local Hub Transport server queues the message for remote delivery to that Active Directory site. A message queued for local delivery is submitted to the destination mailbox store by the store driver. The message is transferred from the Hub Transport server to the Mailbox server by using an Exchange remote procedure call (RPC). A message queued for delivery to a remote Active Directory site is transferred by using SMTP. Before the message is relayed, the routing component of the categorizer selects the least cost routing path. The method for determining the least-cost routing path is explained in detail in "Determining the Least-Cost Routing Path" in Understanding Message Routing. Return to top

Routing Messages for Delivery to Exchange 2007 Servers


Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly, Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site. When a Hub Transport server queries Active Directory to determine the Mailbox server hosting the destination mailbox, it also retrieves the version of the Mailbox server. If the Mailbox server is an Exchange 2007 server that's in the same site as the Hub Transport server, the Hub Transport server will relay the message to an Exchange 2007 Hub Transport server in the same Active Directory site. The process of using the version information to make routing decisions is called versioned routing and is explained in detail in Upgrade from Exchange 2007 Transport. If the Mailbox server is in a different Active Directory site, the message is queued for delivery to that remote site and is transferred by using SMTP. Return to top

Routing Messages for Delivery to Exchange 2003 Servers


The routing topology and components of Exchange 2010 differ significantly from those of Exchange 2003 but generally correlate in the following ways:

The Active Directory site in Exchange 2010 correlates to routing groups in Exchange 2003. IP site links in Exchange 2010 correlate to the concept of routing group connectors in Exchange 2003. The functionality of the Hub Transport server role in Exchange 2010 correlates to the functionality of a dedicated bridgehead server in Exchange 2003. However, each Exchange version differs in the method used to determine routing paths. For more information about the routing differences, see Upgrade from Exchange 2003 Transport. A message relayed from a Hub Transport server to an Exchange 2003 server for delivery to a recipient mailbox located on an Exchange 2003 server must be relayed across a routing group connector. All Exchange 2010 servers are associated with a single routing group named Exchange Routing Group (DWBGZMFD01QNBJR) for the purposes of routing to earlier versions of Exchange when Exchange 2010 coexists in the same organization with Exchange 2003. Placement of Exchange 2010 and earlier versions of Exchange in the same routing group isn't supported. Therefore, at least one routing group connector will always separate Exchange 2010 servers from Exchange 2003 servers. When an Exchange 2010 Hub Transport server determines the least-cost routing path to an Exchange 2003 server, the routing component of the Microsoft Exchange Transport service uses the following algorithm to select the least-cost routing path to a computer running Exchange 2003:

1. Examine all possible routing paths across routing group connectors and select the routing path that has the least total cost. 2. If more than one routing path has the same cost, examine all possible routing paths across IP site links to reach the first routing group connector and select the routing path that has the lowest total IP site link cost. 3. If more than one routing path has the same routing group cost and has the same IP site link cost, select the routing path that includes the least number of hops. 4. If more than one routing path has the same routing group cost, the same IP site link cost, and the same number of hops, select the routing path where the name of the last Active Directory site before the destination site has the lowest alphanumeric value. The following figure shows an example of a routing topology where Exchange 2010 and Exchange 2003 coexist.

In this example, a message is being routed from a Hub Transport server in Site A to an Exchange 2003 server located in routing group 2. Two possible routing paths exist to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 20. This routing path has a total cost of 30. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this example, Option 2 has a lower total routing group connector cost, and the message is routed from the Hub Transport server in Site A, to a Hub Transport server in Site C where it's queued for delivery by using routing group connector C1. The previous example shows how the routing decisions may not result in optimal routing due to the assigned costs on the routing group connectors. To maintain optimal routing, you may need to modify the routing group connector costs you have in your organization. The following figure shows the same topology, but with the cost of routing group connector 2-3 changed to 10.

Again, two possible routing paths are available to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 10. This routing path has a total cost of 20. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this scenario, both options have the same total routing group connector cost. Routing next evaluates the cost of the IP site links that must be crossed to reach the first routing group connector. From Site A, the IP site link cost to reach routing group connector A3 is zero, and the cost to reach routing group connector C1 is 20. Therefore, the routing path described in Option 1 is selected. Return to top

Routing to Public Folders


Public folders can be mail-enabled in Exchange. Users can send messages to mail-enabled public folders just like any other recipient. When a Hub Transport server receives a message sent to a mail-enabled public folder, the following routing process applies:

1. The categorizer must determine which public folder hierarchy in which the public folder resides. 2. The categorizer looks up the homeMDB attribute for the public folder. The homeMDB attribute identifies the public folder hierarchy where the destination public folder is located. 3. Based on the routing table calculations performed by the Microsoft Exchange Transport service, and described in "Selecting the Destination Public Folder Database" later in this topic, the preferred public folder database is used to determine which public folder hierarchy contains a replica of the destination public folder. If the preferred public folder database is located in the same Active Directory site as the routing Hub Transport server, message processing proceeds as described in step 4 in this section. If the preferred public folder database is located in a remote Active Directory site, the message is relayed to that site by using the least cost routing path. The message categorization process described in step 1 and step 2 earlier in this section are repeated by the Hub Transport server that receives the message in the remote site. If the preferred public folder database is located on an Exchange 2007 or Exchange 2003 server, the message is relayed to the Exchange 2007 Hub Transport server or the Exchange 2003 bridgehead server, and message delivery is determined by the earlier version of Exchange. 4. The Hub Transport server establishes a connection to the store driver on the Mailbox server that contains the preferred public folder database. The public folder database is queried to determine whether content for the public folder is available. The identity of the destination folder is referenced by the legacyExchangeDN attribute, and content availability is determined by the value of the IsContentAvailable attribute. The store driver either accepts the message for delivery, or if the folder contents aren't available locally, the store driver responds with a list of alternative servers that contain a replica of that public folder. The behavior of returning an alternative list of servers is known as store override. The alternative list of servers that contain the public folder replica is listed in the same order provided in client folder referrals, and the top entry is chosen by transport. This referral is provided to routing as the destination to which the message should be routed. For more information about client folder referrals, see Configure Public Folder Referrals. 5. If store override occurs, the Hub Transport server uses the routing table to determine the least cost routing path to the server that contains the preferred public folder replica and routes the message to that destination. 6. The message is delivered to the public folder store.

Selecting the Destination Public Folder Database


Public folders are stored in databases created on Mailbox servers. For efficiency and fault tolerance, you can replicate the content in your public folders to multiple Mailbox servers. Public folder content exists only in Exchange databases configured to have a replica of a specific folder, whereas the hierarchy is replicated to all public folder databases. Content and hierarchy information are replicated separately. Public folder hierarchies are retrieved when routing tables are calculated. The top-level hierarchy object has a list of all the public folder databases to which that hierarchy is replicated. This list of public folder databases is stored as the msExchOwningPFTreeBL attribute in Active Directory. The msExchOwningPFTreeBL attribute always lists the most recently added public folder databases at the top of the list. In Exchange 2010, the preferred public folder hierarchy database is selected by using the following criteria:

1. Ranking by the age of the public folder database By default, public folder databases that have an age threshold of less than two days aren't considered unless the age of all public folder databases is less than the threshold or the age is unknown. 2. Proximity Thelocal server is preferred. If the local server doesn't contain a replica of the public folder database, a server in the same Active Directory site is preferred. If the local Active Directory site doesn't contain a replica of the public folder database, a server in a remote Active Directory site or routing group is selected as the preferred destination. 3. Cost If more than one remote Active Directory site or routing group contains a replica of the public folder database, the server in the Active Directory site or routing group that has the least cost routing path from the local Active Directory site is selected as the preferred destination. If more than one server still meets the criteria, the first server in the replica list returned by Active Directory is selected. After the hierarchy is read, Exchange then determines which public folder databases have replicas of the content. To make sure that correct message delivery can occur to the public folder replica, a preferred public folder database is selected by the routing component of the Microsoft Exchange Transport service from the msExchOwningPFTreeBL list. This selection is made by using the following evaluation process:

1. If only a single instance of a public folder database exists, the server that hosts that database is selected. 2. If the list contains any public folder databases located on servers running Exchange 2007 or Exchange Server 2003, these public folder databases are removed from consideration as the preferred public folder database if a replica also exists on an Exchange 2010 Mailbox server. 3. If more than one Exchange 2010 public folder database is available, the following criteria are used to select a preferred public folder database: a. Ranking by the age of the public folder database The older a public folder database is, the more likely it is to have a replica of the target public folder. Therefore, all public folder databases listed in the msExchOwningPFTreeBL list are ranked according to their date of creation by using a configurable number of days as a baseline. The age ranking for each public folder database can be one of the following, listed from best to worst: More than baseline days old Less than baseline days old Unknown The public folder database that has the best age rating is selected as the preferred public folder database. By default, the baseline age for public folder replicas is two days (48 hours). You can modify this value by editing the PFReplicaAgeThreshold key in the EdgeTransport.exe.config file. This file is located in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin directory on a computer running Exchange 2010. b. Proximity If more than one public folder database has the best age rating, the Mailbox server that has the best proximity rating is selected. The proximity rating for each public folder database can be one of the following, listed from best to worst: Local server If the local server contains a replica of the public folder database, it's selected as the preferred destination for routing to public folders contained in that hierarchy. Server located in the local Active Directory site If more than one server on the list is located in the local Active Directory site, the first server on the list is selected as the preferred destination for routing to public folders contained in that hierarchy.

Server located in a remote Active Directory site If the list contains servers from multiple remote Active Directory sites, the server in the Active Directory site that has the least cost routing path from the local Active Directory site is selected as the preferred destination for routing to public folders contained in that hierarchy. If there is more than one server in that site that has a replica of the public folder database, the first server on the list is selected. If more than one remote Active Directory site has the same value for the least cost routing path, the first server on the list is selected. 4. If no public folder database replica is located on an Exchange 2010 Mailbox server, a public folder database located on an Exchange 2007 server is selected as the preferred destination. If there are no Exchange 2007 servers, a public folder database located on an Exchange 2003 computer is selected as the preferred destination for routing to public folders contained in that hierarchy. In either case, the destination public folder database is selected by the age ranking of the public folder database. The age ranking is determined by using the same method as for an Exchange 2010 server. If more than one public folder database has the same age ranking, the first server on the list is selected. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Using Exchange 2010 Transport to Relay Application Server SMTP Traffic


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-16 In Microsoft Exchange Server 2010, the Receive connector and load-balancing concepts remain the same as in Exchange Server 2007. Heres a quick review of those concepts. In Exchange 2007, Receive connectors are used to accept incoming messages. By default, when an Exchange Server 2007 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. In addition, Exchange 2007 automatically load-balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load-balancing of messages received from non-Exchange sources, such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. For more information about how you configure load balancing for messages received from non-Exchange sources, see Understanding SMTP Failover and Load Balancing in Transport. If you place a load-balancing solution in front of your Hub Transport servers, you need to create a separate Receive connector for that purpose and make sure that only traffic processed by that specific connector is subject to load balancing. This is achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector.

Changes in Behavior with Exchange 2010


Exchange 2010 introduces the shadow redundancy feature which provides redundancy for messages for the entire time theyre in transit. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. Because shadow redundancy is an Exchange 2010 feature, shadow redundancy is only supported by Exchange 2010 servers. If an Exchange 2010 transport server receives messages from a previous version of Exchange Server or a non-Exchange source, the source server cant send the expected XSHADOW command. Therefore, shadow redundancy isnt used. Non-Exchange sources include external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization or line-of-business (LOB) applications the source server. However, when an Exchange 2010 transport server receives a message from a non-Exchange 2010 source, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the sending server until it verifies that the message has been successfully delivered to all next hops internally. This way, if the Exchange 2010 server fails, the sending server assumes that the message was never delivered to Exchange and attempts delivery again. The delayed acknowledgement time-out is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. For more information about shadow redundancy, see Understanding Shadow Redundancy. Customers who have upgraded from Exchange 2007 to Exchange 2010 and use dedicated Receive connectors for the purpose of relaying messages from sources such as line-of-business (LOB) applications may see a significant decrease in SMTP throughput. This decrease in throughput is because of the default delayed acknowledgement time-out of 30 seconds configured for a Receive connector. To increase the SMTP throughput for the relay Receive connector, we recommend you either lower the time-out value for the delayed acknowledgement attribute or disable it completely. Whether you should lower or disable the time-out value depends on the amount of messages that go through the relay Receive connector. A good approach is to first lower the value and then verify whether SMTP throughput still suffers and, if it does, then disable the feature completely. Important: Although disabling delayed acknowledgements for a Receive connector increases SMTP throughput, it also means that you no longer benefit from the features provided by shadow redundancy. For this reason, we recommend the use of storage hardware redundancy for transport servers for which delayed acknowledgements are disabled.

Use the Shell to configure the maximum acknowledgement delay on a Receive connector
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Receive connectors" entry in the Transport Permissions topic. Note: You can't use the Exchange Management Console to configure the maximum acknowledgement delay on a Receive connector. This example lowers the time-out value for a Receive connector named SMTP Application relay from 30 to 15 seconds.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

This example disables delayed acknowledgement on the Receive connector.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0

Important: It isnt possible to disable shadow redundancy for a Receive connector. Instead, you must do this on the Exchange organization level. For detailed syntax and parameter information, see Set-TransportConfig.

Message Throttling Policy Considerations


When relaying application server SMTP traffic through an Exchange 2010 transport server, there are Receive connector specific message throttling policy options that may need to be adjusted, so the overall SMTP throughput doesnt suffer. For example, the MessageRateLimit parameter specifies the maximum number of messages that a Receive connector accepts from a single IP address per minute. On Hub Transport servers, this parameter is set to a value of Unlimited, which means SMTP throughput wont be affected. But, for an Edge Transport server, its set to accept 600 messages per minute. Depending on the relay application server SMTP traffic in your specific environment, you may need to raise this limit. This example raises the message rate limit for a Receive connector named SMTP Application relay from 600 to 2000.

Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000

Another Receive connector specific option that can have an impact on overall SMTP throughput from a relay application server is expressed in the value of the MessageRateSource parameter. With this parameter, you specify how the message submission rate is calculated. It can be set to None, IPAddress, User, or All. By default, the parameter is set to IPAddress, which means the message submission rate is calculated for sending hosts. If this parameter has a negative impact on SMTP throughput from your relay application servers, you should consider setting the value to None. This example disables the MessageRateSource parameter for a Receive connector named SMTP Application relay.

Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None

If youre planning to use a dedicated transport server for relay application server SMTP traffic, you should also consider increasing the maximum number of connections that a Receive connector will serve at the same time from a single IP address. This is done using the MaxInboundConnectionPercentagePerSource parameter. The value for this parameter is expressed as the percentage of available remaining connections on a Receive connector. By default, the value is set to 2 percent. This example changes the value of MaxInboundConnectionPercentagePerSource for a Receive connector named SMTP Application relay from 2 to 30 percent.

Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30

For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Transport
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-02-09 The component of Microsoft Exchange that is responsible for transferring messages is known as Transport. The following topics provide detailed information about the Transport features in Exchange Server 2010: Overview of the Edge Transport Server Role Overview of the Hub Transport Server Role Understanding Accepted Domains Understanding Address Rewriting Understanding Anti-Spam and Antivirus Functionality Understanding Approval Framework Understanding Back Pressure Understanding Content Conversion Understanding Delivery Agents Understanding DSNs and NDRs Understanding DNS Query Failure Sensitivity Understanding Domain Security Understanding Edge Subscriptions Understanding Edge Transport Server Cloned Configuration Understanding the EdgeTransport.exe.Config File Understanding Exchange 2010 Support for X.400 Authoritative Domains Understanding Foreign Connectors Understanding Group Metrics Understanding Header Firewall Understanding SMTP Failover and Load Balancing in Transport Understanding Journaling Understanding MailTips Understanding Message Routing Understanding Message Size Limits Understanding Message Throttling Understanding Moderated Transport Understanding the Pickup and Replay Directories Understanding Priority Queuing Understanding Receive Connectors Understanding Recipient Resolution Understanding Remote Domains Understanding Send Connectors Understanding Shadow Redundancy Understanding TLS Certificates Understanding Transport Agents Understanding Transport Database Configuration Options Understanding Transport Logs Understanding Transport Pipeline

Understanding Transport Policy and Compliance Agents Understanding Transport Queues Understanding Transport Rules 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Overview of the Edge Transport Server Role


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 In Microsoft Exchange Server 2010, the Edge Transport server role is deployed in your organization's perimeter network. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow, which provides SMTP relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they're processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow. The computer that has the Edge Transport server role installed doesn't have access to Active Directory. All configuration and recipient information is stored in Active Directory Lightweight Directory Services (AD LDS). To perform recipient lookup tasks, the Edge Transport server requires data that resides in Active Directory. This data is synchronized to the Edge Transport server using EdgeSync. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the AD LDS instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that's required for the Edge Transport server to perform anti-spam configuration tasks and the information about the connector configuration that's required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in AD LDS remains current. You can install more than one Edge Transport server in the perimeter network. Deploying more than one Edge Transport server provides redundancy and failover capabilities for your inbound message flow. You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain. You can achieve consistency in configuration between multiple Edge Transport servers by using cloned configuration scripts. The message-processing scenarios that you can manage on the Edge Transport server role are described in the following sections. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Internet Mail Flow


Servers that run the Edge Transport server role accept messages that come into the Exchange 2010 organization from the Internet. After the messages are processed by the Edge Transport server, they are routed to Hub Transport servers inside the organization. All messages that are sent to the Internet from the organization are routed to Edge Transport servers after the messages are processed by the Hub Transport server. You can configure the Edge Transport server to use DNS to resolve MX resource records for external SMTP domains, or you can configure the Edge Transport server to forward messages to a smart host for DNS resolution. For more information about mail flow, see Understanding Transport Pipeline.

Anti-Spam and Antivirus Protection


In Exchange 2010, the anti-spam and antivirus features provide services to block viruses and spam, or unsolicited commercial e-mail, at the network perimeter. Most viruses use spam-like tactics to gain access to your organization and to entice users to open an e-mail message. If you can filter out most of your spam, you're also more likely to capture viruses before they enter your organization. Spammers use a variety of techniques to send spam into your organization. Servers that run the Edge Transport server role help prevent users in your organization from receiving spam by providing a collection of agents that work together to provide different layers of spam filtering and protection. Establishing tarpitting intervals on connectors makes e-mail harvesting attempts ineffective. For more information about the anti-spam and antivirus features in Exchange 2010, see Understanding Anti-Spam and Antivirus Functionality.

Edge Transport Rules


Edge Transport rules are used to control the flow of messages that are sent to or received from the Internet. The Edge Transport rules help protect corporate network resources and data by applying an action to messages that meet specified conditions. These rules are configured for each server. Edge Transport rule conditions are based on data, such as specific words or text patterns in the message subject, body, header, or From address, the spam confidence level (SCL), or attachment type. Actions determine how the message is processed when a specified condition is true. Possible actions include quarantine of a message, dropping or rejecting a message, appending additional recipients, or logging an event. Optional exceptions exempt particular messages from having an action applied. For more information about the Edge Transport rules, see Understanding Transport Rules.

Address Rewriting
You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2010 organization. You configure the Address Rewriting agent on the Edge Transport server role to enable the modification of the SMTP addresses on inbound and outbound messages. Address rewriting is especially useful when a newly merged organization that has several domains wants to present a consistent appearance of e-mail addresses to external recipients. For more information about address rewriting, see Understanding Address Rewriting.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Overview of the Hub Transport Server Role


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Deployed inside your Active Directory forest, the Hub Transport server role handles all mail flow inside the organization, applies transport rules, applies journaling policies, and delivers messages to a recipient's mailbox. Messages that are sent to the Internet are relayed by the Hub Transport server to the Edge Transport server role that's deployed in the perimeter network. Messages that are received from the Internet are processed by the Edge Transport server before they're relayed to the Hub Transport server. If you don't have an Edge Transport server, you can configure the Hub Transport server to relay Internet messages directly or utilize a third-party smart host. You can also install and configure the Edge Transport server agents on the Hub Transport server to provide anti-spam and antivirus protection inside the organization, although this isn't recommended. You can install the Hub Transport server role on the same hardware with any other internal server role or on a server that's dedicated to the Hub Transport server role. You must deploy a Hub Transport server role in each Active Directory site that contains a Mailbox server role. Deploying more than one Hub Transport server per site provides redundancy. When you install more than one Hub Transport server in an Active Directory site, the connections are distributed. The message-processing scenarios that you can manage on the Hub Transport server role are described in the following sections. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Internal Mail Flow


The Hub Transport server role processes all messages that are sent inside the Microsoft Exchange Server 2010 organization before the messages are delivered to a recipient's Inbox or are routed to users outside the organization. There are no exceptions to this behavior; messages are always passed through a server that runs the Hub Transport server role. Messages are submitted to the Hub Transport server in three ways: through SMTP submission, from the Pickup directory, or when a user inside the organization sends a message, which is picked up from the user's Outbox by the store driver. The store driver is a software component of the Hub Transport server that delivers inbound messages to Exchange stores, the databases that contain public folder and mailbox stores. When messages are submitted to the Hub Transport server, they're processed by the categorizer. The categorizer is a component of Exchange transport that processes all inbound messages and determines what to do with the messages based on information about the intended recipients. In Exchange 2010, the Hub Transport server uses the categorizer to expand distribution lists and to identify alternative recipients and forwarding addresses. After the categorizer retrieves full information about the recipients, it uses that information to apply policies, route the messages, and perform content conversion. Messages are then delivered locally by the store driver to a recipient's mailbox, or they're delivered remotely by using SMTP to send messages to another transport server. Messages that are sent by users in your organization are picked up from the sender's Outbox by the store driver and are put in the Submission queue on a server that runs the Hub Transport server role. For more information, see Understanding Transport Pipeline.

Messaging Policy and Compliance Features


With a collection of transport agents, you can configure rules and settings that are applied as messages enter and leave the mail flow components. You can create messaging policy and rule settings that are designed to meet different regulations and that can easily be changed to adapt to your organization's requirements. The transport-based messaging policy and compliance features include server-based rules that you configure to enforce your organization's compliance scenarios and the Journaling agent that acts to enforce message retention. For more information, see Planning for Compliance.

Anti-Spam and Antivirus Protection


Exchange 2010 provides anti-spam and antivirus protection for messages. Although these features are designed for use in the perimeter network on the Edge Transport server role, the Edge Transport agents can also be configured on the Hub Transport server. By default, these agents aren't enabled on the Hub Transport server role. To use the anti-spam features on the Hub Transport server, you must register the agents in a configuration file and enable the features that you want to use by running a provided Exchange Management Shell script. You install and enable the antivirus agent in a separate operation. For more information, see Understanding Anti-Spam and Antivirus Functionality.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Accepted Domains


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 An accepted domain is any SMTP namespace for which a Microsoft Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an e-mail server that's outside the Active Directory forest for delivery to the recipient. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Configuring Accepted Domains Authoritative Domains Relay Domains Accepted Domains and E-Mail Address Policies

Configuring Accepted Domains

Accepted domains are configured as global settings for the Exchange organization and on computers that have the Edge Transport server role installed. You must configure every domain for which your Hub Transport servers relay or deliver messages as an accepted domain in your organization. The Edge Transport server requires that all domains for which it accepts and relays messages are configured as accepted domains. We recommend that you create and manage all accepted domains inside the organization and synchronize that information to the Edge Transport server by creating an Edge Subscription. When you subscribe the Edge Transport server to the Microsoft Exchange Server 2010 organization, all accepted domains that are configured in the organizational settings for the Hub Transport server role are replicated to the Edge Transport server during EdgeSync synchronization. To modify the accepted domain configuration on an Edge Transport server that's subscribed to the Exchange 2010 organization, you must make the change on the Hub Transport server. There are three types of accepted domains: authoritative, internal relay, and external relay. These accepted domain types are described in the following sections. Return to top

Authoritative Domains
An organization may have more than one SMTP domain. The set of e-mail domains for an organization are the authoritative domains. In Exchange 2010, an accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. The Edge Transport servers should always accept e-mail that's addressed to any of the organization's authoritative domains. By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name (FQDN) for your forest root domain. Frequently, the internal domain name differs from the external domain name. For example, your internal domain name may be Contoso.local, although your external domain name is Contoso.com. The Domain Name System (DNS) mail exchange (MX) resource record for your organization references Contoso.com. Contoso.com is the SMTP namespace that you assign to users when you create an e-mail address policy. You must create an accepted domain to match your external domain name. By default, no accepted domains are configured on the Edge Transport server role. Return to top

Relay Domains
When e-mail is received from the Internet by an Edge Transport server and the recipient of the message isn't part of an authoritative domain, the sending server tries to relay through the Exchange server. When a server acts as a relay server that has no restrictions, it can put a large burden on Internet-connected servers. Administrators can prevent this open relay scenario by rejecting all e-mail that isn't addressed to a recipient in the organization's authoritative domains. However, there are scenarios where an organization wants to let partners or subsidiaries relay e-mail through the Exchange servers. In Exchange 2010, you can configure accepted domains as relay domains. Your organization receives the e-mail messages and then relays the messages to another e-mail server. You can configure a relay domain as an internal relay domain or as an external relay domain. These two relay domain types are described in the following sections.

Internal Relay Domain


When you configure an internal relay domain, some or all of the recipients in this domain don't have mailboxes in this Exchange organization. Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. This configuration is used in the scenarios that are described in this section. An organization may have to share the same SMTP address space between two or more different e-mail systems. For example, you may have to share the SMTP address space between Microsoft Exchange and a third-party e-mail system, or between Exchange environments that are configured in different Active Directory

forests. In these scenarios, users in each e-mail system have the same domain suffix as part of their e-mail addresses. To support these scenarios, you must create an accepted domain that's configured as an internal relay domain. You must also add a Send connector that's sourced on a Hub Transport server and configured to send e-mail to the shared address space. If an accepted domain is configured as authoritative and a recipient isn't found in Active Directory, a non-delivery report (NDR) is returned to the sender. The accepted domain that's configured as an internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient isn't found, the message is routed to the Send connector that has the closest address space match. If an organization contains more than one forest and has configured global address list (GAL) synchronization, the SMTP domain for one forest may be configured as an internal relay domain in a second forest. Messages from the Internet that are addressed to recipients in internal relay domains are received and processed by the Edge Transport server and then relayed to the Hub Transport servers in the same organization. The receiving Hub Transport servers then route the messages to the Hub Transport servers in the recipient forest. You configure the SMTP domain as an internal relay domain to make sure that e-mail that's addressed to that domain is accepted by the Exchange organization. The connector configuration of your organization determines how messages are routed. In the following figure, Fourthcoffee.com is configured as an internal relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource records for Fourthcoffee.com reference a public IP address for the Contoso.com organization. A forest trust exists between Fourthcoffee.com and Contoso.com, and GAL synchronization is configured. The Contoso.com Edge Transport server accepts messages for the Fourthcoffee.com SMTP domain from the Internet and then relays those messages to the Hub Transport servers in the Contoso.com Exchange organization. The messages are then routed to the Hub Transport servers in the Fourthcoffee.com Exchange organization. A cross-forest Send connector is configured for routing messages from Contoso.com to Fourthcoffee.com. Messages that are sent from Fourthcoffee.com to external recipients are routed to the Hub Transport servers in the Contoso.com forest. A second cross-forest Send connector is configured for routing messages from Fourthcoffee.com to Contoso.com. When the Hub Transport servers in Contoso.com receive messages from the internal relay domain Fourthcoffee.com, they deliver messages for recipients in authoritative domains and relay messages for Internet recipients to the Edge Transport server for delivery.

External Relay Domain


When you configure an external relay domain, messages are relayed to an e-mail server that's outside the Exchange organization and outside the organization's network perimeter. The messages are relayed by the Edge Transport server. In this scenario, the MX resource record for the external relay domain references a public IP address for the Exchange 2010 organization that's relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the e-mail system for the external relay domain. A Send connector from the Edge Transport server to the external relay domain is required in this scenario. The external relay domain may also use your organization's Edge Transport server as a smart host for outgoing mail. In the following figure, Adatum.com is configured as an external relay domain for the Exchange 2010 organization in the Contoso.com forest. The MX resource record for Adatum.com references a public IP address for the Contoso.com organization. The Contoso.com Edge Transport server accepts messages for the Adatum.com SMTP domain from the Internet and then relays those messages to the e-mail servers in the Adatum.com organization. Adatum.com also uses the Contoso.com Edge Transport server as a smart host for routing outgoing messages. Messages that are sent from Adatum.com to external recipients are routed to the Edge Transport servers in the Contoso.com organization. When the Edge Transport servers in Contoso.com receive messages from Adatum.com, they deliver messages for recipients in authoritative domains and internal relay domains to the Hub Transport servers and route messages to the Internet.

Return to top

Accepted Domains and E-Mail Address Policies


You must configure an accepted domain before that SMTP address space can be used in an e-mail address policy. When you create an accepted domain, you can use a wildcard character (*) in the address space to indicate that all subdomains of the SMTP address space are also accepted by the Exchange organization. For example, to configure Contoso.com and all its subdomains as accepted domains, enter *.Contoso.com as the SMTP address space. The accepted domain entries are automatically available for use in an e-mail address policy. If you delete an accepted domain that's used in an e-mail address policy, the policy is no longer valid, and recipients with e-mail addresses in that SMTP domain will be unable to send or receive e-mail. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Address Rewriting


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 In Microsoft Exchange Server 2010, address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange 2010 organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Why Use Address Rewriting Address Rewriting Scenarios SMTP Message Headers What Address Rewriting Agents Don't Rewrite Considerations for Use of Outbound-Only Address Rewriting Considerations for Bidirectional Address Rewriting Considerations for Rewriting Addresses in Multiple Domains Prioritization of Address Rewriting Entries Digitally Signed, Encrypted, and Rights-Protected Messages

Why Use Address Rewriting?

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2010 organization. Address rewriting can be valuable to organizations that use third-party vendors to provide e-mail support and services. Customers and partners expect e-mail messages to come from the organization, not a third-party vendor. Similarly, after a merger or acquisition, an organization might want all e-mail messages to appear to come from the single new organization. The address rewriting feature frees organizations to structure their businesses by business requirements instead of by technical requirements or limitations. You can also use address rewriting to enable appropriate routing of inbound messages from outside your Exchange 2010 organization to internal recipients. Address rewriting enables replies to messages that were rewritten to be correctly routed to the original sender of the rewritten message. You configure Address Rewriting agents on the Receive connector and Send connector on a computer that has the Edge Transport server role installed. Return to top

Address Rewriting Scenarios


The following scenarios are examples of how address rewriting can benefit organizations:

Group consolidation Some organizations segment their internal businesses into separate domains that are based on business or technical requirements. However, this configuration can cause e-mail messages to appear as if they come from separate groups or even separate organizations. This appearance might not be desirable to the organization. The following example shows how an organization, Contoso, Ltd., could hide its subdomains: Outbound messages from the Northamerica.contoso.com, Europe.contoso.com, and Asia.contoso.com domains are rewritten to appear as if they all originate from a single Contoso.com domain. All messages are rewritten as they pass through Edge Transport servers that provide SMTP connectivity between the whole organization and the Internet. Inbound messages to the Contoso.com domain are passed on by the Edge Transport server to the Hub Transport server role, which then determines the correct recipient. For example, messages to chris@contoso.com are sent to an internal Hub Transport server, which then determines the correct mailbox to send the message to by using the proxy address that's configured on the recipient's e-mail account. Mergers and acquisitions When organizations merge or are acquired, their technology infrastructure must be modified to match new business and technical requirements. An acquired company may continue to run as a separate business unit, but the e-mail administrator can use address rewriting to make the two organizations appear as if they're one integrated organization. The following example shows how Contoso, Ltd. could hide the e-mail domain of the newly acquired company, Fourth Coffee: Contoso, Ltd. wants all outbound messages from Fourth Coffee's Exchange organization to appear as if they originate from Contoso.com. All messages from both organizations are sent through the Edge Transport servers at Contoso, Ltd., where e-mail messages are rewritten from someone@fourthcoffee.com to someone@contoso.com. Inbound messages to adam@contoso.com are rewritten and routed to his adam@fourthcoffee.com e-mail account. Incoming messages that use his old adam@fourthcoffee.com domain are also accepted, because the domain still exists. Inbound replies to e-mail messages that were rewritten are handled by the Edge Transport servers at Contoso, Ltd., where the Address Rewriting agent rewrites the recipient address so that replies are correctly routed to the appropriate Fourthcoffee.com e-mail address. Replies to e-mail messages that were sent before the merger to Fourthcoffee.com e-mail addresses are routed directly to Fourth Coffee's e-mail servers. Partners Many organizations use external partners to provide services for their customers, other partners, or the organization itself. To avoid confusion, the organization might replace the e-mail domain of the partner organization with its own e-mail domain. The following example shows how Contoso, Ltd. could hide a partner's e-mail domain:

Contoso, Ltd. provides support for the larger Wingtip Toys organization. Wingtip Toys wants a unified experience for its customers and requires all messages that originate from support personnel at Contoso, Ltd. to appear as if they were sent from Wingtip Toys. All outbound messages that relate to Wingtip Toys are sent through their Edge Transport servers, and all Contoso.com addresses are rewritten to appear as Wingtiptoys.com addresses. Inbound messages for support@wingtiptoys.com are accepted by Wingtip Toy's Edge Transport servers, rewritten, and then routed to the support@contoso.com e-mail address. Caution: So that inbound e-mail is appropriately mapped and routed, you must make sure that the user name part of the address is unique across all e-mail organizations that may be affected by address rewriting. Return to top

SMTP Message Headers


Address Rewriting agents rewrite e-mail addresses by rewriting the SMTP headers on e-mail messages that are sent and received by an Edge Transport server. Address Rewriting agents typically rewrite outbound messages because the organization wants to hide the internal domains and subdomains as effectively as possible and present a single external domain to the Internet. Address Rewriting agents typically rewrite inbound messages to route those messages to their intended recipients. For these reasons, Address Rewriting agents rewrite several SMTP header fields on outbound e-mail messages. Address Rewriting agents rewrite only one SMTP header field on inbound e-mail messages. The following table shows which SMTP header fields are rewritten on outbound and inbound messages.

SMTP header fields rewritten on outbound and inbound messages


SMTP header field Envelope From (MAIL FROM) Envelope To (RCPT TO) Body To Body Cc Body From Body Sender Body Reply-To Body Return-Receipt-To Body Disposition-Notification-To Body Resent-From Body Resent-Sender Return to top Outbound Rewritten Not rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Rewritten Inbound Not rewritten Rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten Not rewritten

What Address Rewriting Agents Don't Rewrite


Address Rewriting agents don't rewrite several SMTP header fields, because address rewriting would break SMTP functionality. For example, changing these SMTP headers could affect message loop detection, invalidate the signature, or make a rights-protected message unreadable. The following SMTP header fields aren't modified by the Address Rewriting agents:

Return-Path Received Message-ID X-MS-TNEF-Correlator Content-Type Boundary=string Headers located inside MIME body parts Address Rewriting agents also don't rewrite header fields within e-mail messages that contain domains for which the Hub Transport server isn't authoritative. Rewriting such domains causes an uncontrollable form of message relay. Address Rewriting agents also don't modify the header fields of messages that are embedded in another message. Senders and recipients expect embedded messages to remain intact and be delivered without modification, as long as the messages don't trigger transport rules that are implemented between the sender and recipient. Return to top

Considerations for Use of Outbound-Only Address Rewriting


When an e-mail message is outbound from the Exchange 2010 organization, outbound-only address rewriting involves modification of the sender SMTP address only. The Address Rewriting agent is configured only on the Send connector on the Edge Transport server. The following list shows the conditions that are required to configure an outbound-only Address Rewriting agent:

The resulting addresses must be unique across the organization. For example, if the unique e-mail addresses ed@sales.contoso.com and ed@research.contoso.com are included in a rule to rewrite all addresses to contoso.com, the Address Rewriting agent will rewrite both addresses to ed@contoso.com and will cause a conflict. A proxy address must be configured on each mailbox that matches the rewritten e-mail address. This enables those mailboxes to receive replies to e-mail messages in which headers are rewritten. When you use wildcard characters, there must be a period between the wildcard character and the domain name. You can use wildcard characters only in the internal domain. No characters can be in front of the wildcard character. Outbound-only address rewriting can't affect the user name or display name part of the address. Only literal strings are supported. Return to top

Considerations for Bidirectional Address Rewriting


Bidirectional address rewriting modifies the sender SMTP address on e-mail messages that are leaving the Exchange organization and the recipient SMTP address on email messages that are entering the Exchange organization. To do this, you configure the Address Rewriting agent on both the Send connector and Receive connector on the Edge Transport server. The following list shows the conditions that are required when you create a bidirectional Address Rewriting agent:

You can't use wildcard characters. You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For example, the internal address is chris@contoso.com, and the external address is support@contoso.com. Only literal strings are supported. The address must be unique across the organization. For example, if an e-mail address, bob@contoso.com, already exists, mapping robert@fourthcoffee.com to bob@contoso.com will cause replies to messages from bob@contoso.com to be delivered to the wrong person. Return to top

Considerations for Rewriting Addresses in Multiple Domains


Before you create an address rewrite entry that rewrites multiple domains, you must prepare your subdomains. Also, before you perform the procedure for creating an address rewrite entry for multiple subdomains that's described in Create an Address Rewrite Entry, you must understand the requirements for rewriting e-mail addresses in multiple domains to a single domain, and the appropriate preconfiguration for the affected mailboxes and contacts.

Important Considerations
When you flatten internal subdomains into a single external domain, you must consider the following factors, which apply only when multiple subdomains are being rewritten:

Unique aliases are required All e-mail aliases, the part of the e-mail address to the left of the at (@) sign, must be unique across all subdomains. For example, if there is a joe@sales.contoso.com, there can't be a joe@marketing.contoso.com. Proxy addresses are required A proxy address that matches the e-mail address that's produced by the Address Rewriting agent must be configured on every e-mail account that's in the subdomains that are rewritten. For example, if joe@sales.contoso.com is rewritten to joe@contoso.com, the e-mail address joe@contoso.com must be added as a proxy address to Joe's mailbox. Contacts may be required If you're rewriting e-mail from a non-Exchange 2010 e-mail system, you must create Active Directory mail-enabled contacts for each e-mail address in the non-Exchange 2010 e-mail address that's being rewritten. This mail-enabled contact must contain the original e-mail address and the rewritten e-mail address. For example, if joe@unix.contoso.com is rewritten to joe@contoso.com, you must create a mail-enabled contact in Active Directory with joe@unix.contoso.com as the target SMTP address and joe@contoso.com as the proxy SMTP address. These factors are important because rewriting addresses in multiple subdomains causes a many-to-one relationship between internal subdomains and the externally visible domain. Because of this many-to-one relationship, the Address Rewriting agent can't determine which subdomain contains the correct recipient when a message that's addressed to the externally visible domain is received. Important: Make sure that every e-mail alias that exists across all subdomains is unique. Exchange 2010 doesn't check to verify that every e-mail alias that can be rewritten to a single domain is unique.

Removing Conflicting E-Mail Addresses


To create an address rewrite entry that rewrites multiple subdomains, you must first make sure that all e-mail aliases are unique across all your subdomains. For example, consider the following configuration: The following users are in the subdomains sales.contoso.com, marketing.contoso.com and research.contoso.com:

maria@sales.contoso.com chris@sales.contoso.com david@marketing.contoso.com brian@marketing.contoso.com chris@research.contoso.com adam@research.contoso.com Each subdomain has two users, and each user has a unique e-mail address. However, you want to rewrite the subdomains sales.contoso.com, marketing.contoso.com, and research.contoso.com into a single domain that's called contoso.com. The following table shows each original e-mail address and its corresponding rewritten email address.

Original e-mail addresses and corresponding rewritten e-mail addresses


Original e-mail address maria@sales.contoso.com chris@sales.contoso.com david@marketing.contoso.com brian@marketing.contoso.com chris@research.contoso.com adam@research.contoso.com Rewritten e-mail address maria@contoso.com chris@contoso.com david@contoso.com brian@contoso.com chris@contoso.com adam@contoso.com

When the e-mail addresses in each subdomain are rewritten, a conflict occurs between chris@sales.contoso.com and chris@research.contoso.com. Therefore, both email addresses are rewritten to chris@contoso.com. To resolve this situation, you must change the e-mail address of one of the recipient mailboxes to an address that doesn't conflict with the e-mail address in any other subdomain.

Applying Proxy Addresses to Recipient Mailboxes


For internal recipient mailboxes to receive replies to addresses that have been rewritten, you must configure those recipient mailboxes by using a proxy address that matches the rewritten external address. For example, if a mailbox exists for adam@research.contoso.com, and the rewritten external address is adam@contoso.com, the mailbox must be configured by using a proxy address that's set to adam@contoso.com. Return to top

Prioritization of Address Rewriting Entries


The rule that best matches the internal and external domain pair is applied. The following prioritization is the exact order of address rewriting entries from highest priority to lowest priority:

1. Individual e-mail addresses An example is mapping john@contoso.com to support@contoso.com. 2. Specific domain or subdomain mapping An example is mapping Contoso.com to Northwindtraders.com or Sales.contoso.com to Contoso.com. 3. Domain flattening An example is flattening *.contoso.com into Contoso.com. For example, the following two rules are configured on the Edge Transport server:

*.contoso.com maps to Contoso.com Japan.sales.contoso.com maps to contoso.jp

If masato@japan.sales.contoso.com sends an e-mail message, the address is rewritten as masato@contoso.jp, because that rule most closely matches the sender's internal domain, even though the *.contoso.com rule is present. Return to top

Digitally Signed, Encrypted, and Rights-Protected Messages


Address rewriting shouldn't affect most signed, encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an encrypted or rights-protected message unreadable, or otherwise change the security status of such messages in any way, address rewriting isn't applied. Addresses and information in the following message sections can be rewritten, because information in these sections isn't part of message signing, encryption, or rights protection:

SMTP envelope fields Top-level message body headers Addresses and information in the following message sections isn't rewritten because information in these sections is part of message signing, encryption, or rights protection:

Headers located inside MIME body parts that may be signed The boundary string parameter of the MIME content type Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Anti-Spam and Antivirus Functionality


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 Spammers, or malicious senders, use a variety of techniques to send spam into your organization. No single tool or process can eliminate all spam. Microsoft Exchange Server 2010 builds on the foundation of Exchange Server 2007 to provide a layered, multipronged, and multifaceted approach to reducing spam and viruses. Exchange 2010 includes a variety of anti-spam and antivirus features that are designed to work cumulatively to reduce the spam that enters your organization. You can reduce the incidences of virus outbreaks and attacks by malicious software, which is also referred to as malware, in your organization if you reduce the overall volume of spam that enters your organization. When you eliminate the bulk of the spam at the computer that has the Edge Transport server role installed, you save processing resources, bandwidth, and storage when the messages are scanned for viruses and other malware further along the mail flow path. The layered approach to reducing spam refers to the configuration of several anti-spam and antivirus features that filter inbound messages in a specific order. Each feature filters for a specific characteristic or set of related characteristics on the inbound message. The following sections provide brief descriptions of each default anti-spam and antivirus feature. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Anti-Spam and Antivirus Filters Anti-Spam Stamps Microsoft Update for Anti-Spam Services Using Exchange Hosted Services Strategy for Anti-Spam Approach

Anti-Spam and Antivirus Filters

The anti-spam and antivirus filters are applied in a specific order. For more information, see Understanding Anti-Spam and Antivirus Mail Flow. The following order applies:

1. Connection filtering Connection filtering inspects the IP address of the remote server that's trying to send messages to determine what action, if any, to take on an inbound message. The remote IP address is available to the Connection Filter agent as a byproduct of the underlying TCP/IP connection that's required for the SMTP session. Connection filtering uses a variety of IP Block lists, IP Allow lists, as well as IP Block List provider services or IP Allow List provider services to determine whether the connection from the specific IP should be blocked or allowed in the organization. 2. Sender filtering Sender filtering compares the sender on the MAIL FROM: SMTP command to an administrator-defined list of senders or sender domains who are prohibited from sending messages to the organization to determine what action, if any, to take on an inbound message. 3. Recipient filtering Recipient filtering compares the message recipients on the RCPT TO: SMTP command to an administrator-defined Recipient Block list. If a match is found, the message isn't permitted to enter the organization. The recipient filter also compares recipients on inbound messages to the local recipient directory to determine whether the message is addressed to valid recipients. When a message isn't addressed to valid recipients, the message can be rejected at the organization's network perimeter. 4. Sender ID Sender ID relies on the IP address of the sending server and the Purported Responsible Address (PRA) of the sender to determine whether the sender is spoofed or not. PRA is calculated based on the following message headers: Resent-Sender: Resent-From: Sender: From: For more information about the PRA, see Understanding Sender ID and RFC 4407. 5. Content filtering Content filtering uses Microsoft SmartScreen technology to assess the contents of a message. Intelligent Message Filter is the underlying technology of Exchange content filtering. Intelligent Message Filter is based on patented machine-learning technology from Microsoft Research. During its development, Intelligent Message Filter learned distinguishing characteristics of legitimate e-mail messages and spam. Regular updates with Microsoft Exchange Anti-spam Update service ensure that the most up-to-date information is always included when the Intelligent Message Filter runs. Based on the characteristics of millions of messages, Intelligent Message Filter recognizes indicators of both legitimate messages and spam messages. Intelligent Message Filter can accurately assess the probability that an inbound e-mail message is either a legitimate message or spam. Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages that are incorrectly classified as spam. Spam quarantine provides a temporary storage location for messages that are identified as spam and that shouldn't be delivered to a user mailbox inside the organization. Content filtering also acts on the safelist aggregation feature. Safelist aggregation collects data from the anti-spam safe lists that Microsoft Outlook and Outlook Web App users configure and makes this data available to the Content Filter agent on the computer that has the Edge Transport server role installed in Exchange 2010. When an Exchange administrator enables and correctly configures safelist aggregation, the Content Filter agent passes safe e-mail messages to the enterprise mailbox without additional processing. E-mail messages that Outlook users receive from contacts or that those users have added to their Outlook Safe Senders List or have trusted are identified by the Content Filter agent as safe. The result is that messages that are identified as safe aren't classified as spam and unintentionally filtered out of the messaging system. 6. Sender reputation Sender reputation relies on persisted data about the IP address of the sending server to determine what action, if any, to take on an inbound message. The Protocol Analysis agent is the underlying agent that implements the sender reputation functionality. A sender reputation level (SRL) is calculated from several sender characteristics that are derived from message analysis and external tests. Senders whose SRL exceeds a configurable threshold will be temporarily blocked. All their future connections are rejected for up to 48 hours. In addition to the locally calculated IP reputation, Exchange 2010 also takes advantage of IP reputation anti-spam updates, available via Microsoft Update, which provide sender reputation information about IP addresses that are known to send spam. 7. Attachment filtering Attachment filtering filters messages based on attachment file name, file name extension, or file MIME content type. You can configure

attachment filtering to block a message and its attachment, to strip the attachment and allow the message to pass through, or to silently delete the message and its attachment. 8. Microsoft Forefront Protection 2010 for Exchange Server Forefront Protection 2010 for Exchange Server (FPE) is an antivirus software package that's tightly integrated with Exchange 2010 and offers antivirus protection for the Exchange environment. The antivirus protection that's provided by FPE is language independent. However, the setup, administration of the product, and end-user notifications are available in 11 server languages. For more information, see Microsoft Forefront Protection 2010 for Exchange Server. 9. Outlook junk e-mail filtering The Outlook junk e-mail filter uses state-of-the-art technology to evaluate whether a message should be treated as a junk email message based on several factors, such as the time that the message was sent, the content and structure of the message, and the metadata collected by the Exchange Server anti-spam filters. Messages caught by the filter are moved to a special Junk E-mail folder, where the recipient can access them later. Return to top

Anti-Spam Stamps
Anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as sender-specific information, puzzle validation results, and content filtering results, to messages as they pass through the anti-spam features that filter inbound messages from the Internet. These stamps are visible to the end-user mail client and encode sender-specific information, the version of the spam filter definition file, Outlook puzzle validation results, and content filtering results. Return to top

Microsoft Update for Anti-Spam Services


Exchange 2010 offers additional services to help keep anti-spam components up to date, taking advantage of the proven Microsoft Update infrastructure. Microsoft Exchange 2010 Standard Anti-spam Filter Updates offer anti-spam updates every two weeks via Microsoft Update. The Forefront Security for Exchange Server Anti-spam Update service is a premium service that updates the content filter daily via Microsoft Update. In addition, the premium service includes the spam signature and IP Reputation Service updates that are available on an as-needed basis, up to several times a day. Spam signature updates identify the most recent spam campaigns. IP Reputation Service updates provide sender reputation information about IP addresses that are known to send spam. Note: To use the premium service, you must have the Exchange Enterprise client access license (CAL). Return to top

Using Exchange Hosted Services


Spam filtering is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services. Return to top

Strategy for Anti-Spam Approach


Your strategy for how to configure the anti-spam features and establish the aggressiveness of your anti-spam agent settings requires that you plan and calculate carefully. If you set all anti-spam filters to their most aggressive levels and configure all anti-spam features to reject all suspicious messages, you're more likely to reject messages that aren't spam. On the other hand, if you don't set the anti-spam filters at a sufficiently aggressive level and don't set the spam confidence level (SCL) threshold low enough, you probably won't see a reduction in the spam that enters your organization. It's a best practice to reject a message when Exchange detects a bad message through the Connection Filter agent, Recipient Filter agent, or Sender Filter agent. This approach is better than quarantining such messages or assigning metadata, such as anti-spam stamps, to such messages. The Connection Filter agent and Recipient Filter agent automatically block messages that are identified by the respective filters. The Sender Filter agent is configurable. This best practice is recommended because the SCL that underlies connection filtering, recipient filtering, or sender filtering is relatively high. For example, with sender filtering, where the administrator has configured specific senders to block, there's no reason to assign the sender filtering data to such messages and to continue to process them. In most organizations, blocked messages should be rejected. (If you didn't want the messages rejected, you wouldn't have put them on the Blocked Senders List.) The same logic applies to real-time block list services and recipient filtering, although the underlying confidence isn't as high as the IP Block list. You should be aware that the further along the mail flow path a message travels, the greater the probability of false positives, because the anti-spam features are evaluating more variables. Therefore, you may find that if you configure the first several anti-spam features in the anti-spam chain more aggressively, you can reduce the bulk of your spam. As a result, you'll save processing, bandwidth, and disk resources so that you can process more ambiguous messages. Ultimately, you must plan to monitor the overall effectiveness of the anti-spam features. If you monitor carefully, you can continue to adjust the anti-spam features to work well together for your environment. With this approach, you should plan on a fairly non-aggressive configuration of the anti-spam features when you start. This

approach lets you minimize the number of false positives. As you monitor and adjust the anti-spam features, you can become more aggressive about the type of spam and spam attacks that your organization experiences. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Anti-Spam and Antivirus Mail Flow


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 When an external user sends e-mail messages to a server running Microsoft Exchange that runs the anti-spam features, the anti-spam features cumulatively evaluate characteristics of inbound messages and either filter out messages suspected to be spam or assign messages a rating based on the probability that the message is spam. This rating is stored with the message as a message property called the spam confidence level (SCL) rating. This rating is persisted with the message when the message is sent to other Exchange servers. The following figure shows the order in which the default anti-spam features and Microsoft Forefront Protection for Exchange Server filter inbound messages from the Internet. By default, the anti-spam and antivirus features are arranged in this order with the filters that use the least resources filtering first, and then the filters that use the greatest resources filtering last. Note: The following figures and explanations assume that the Microsoft Exchange Server 2010 Edge Transport server is the first SMTP server to accept inbound messages. In some organizations, the Edge Transport server may be deployed behind a third-party SMTP server. When the Exchange 2010 Edge Transport server is deployed behind a third-party SMTP gateway server, the Exchange 2010 Edge Transport server requires additional configuration. Specifically, you must make sure that all SMTP gateway servers are listed in the InternalSMTPServer property of the TransportConfig object. For more information, see Set-TransportConfig. For more information about additional Exchange anti-spam and antivirus features, see Microsoft Forefront Protection 2010 for Exchange Server.

As shown in the preceding figure, when an SMTP server connects to Exchange 2010 and initiates an SMTP session, filters are applied in the following order when the Edge Transport server is Internet-facing:

Connection filtering Sender filtering Recipient filtering Sender ID filtering Content filtering Sender reputation filtering Attachment filtering Antivirus scanning Outlook junk e-mail filtering Note: Connection filtering gathers information during two different events. In the first event, connection filtering gathers IP address information from the connection (shown in the preceding figure). In the second event, connection filtering gathers information when the Sender Filter agent parses the message headers to determine the first external IP address (shown in the figure in "Sender Filtering" later in this topic). Agents may monitor multiple events. The preceding figure shows a high-level view of the approximate order in which agents are applied, when all agents are enabled, for the purposes of illustrating message flow. For more information about specific events and which agents monitor which events, see Understanding Transport Agents. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Connection Filtering Sender Filtering Recipient Filtering Sender ID Filtering Content Filtering Sender Reputation Filtering Attachment Filtering Antivirus Scanning Outlook Junk E-Mail Filtering

Connection Filtering

During the SMTP session, Exchange 2010 applies connection filtering by using the criteria shown in the following figure.

The following process applies:

1. The Connection Filter agent examines the administrator-defined IP Allow list. If the IP address of the sending server is on the administrator-defined IP Allow list, the message is then processed by sender filtering. 2. The Connection Filter agent examines the local IP Block list. If the IP address of the sending server is found on the local IP Block list, the message is automatically rejected, and no other filters are applied. 3. The Connection Filter agent examines the list of allowed IP addresses from any IP Allow List providers that you have. If the IP address of the sending server is on the list of allowed IP addresses from the IP Allow List providers, the message is then processed by sender filtering. 4. The Connection Filter agent examines the real-time block lists of any IP Block List providers that you've configured. If the sending server's IP address is found on a real-time block list, the message is rejected, and no other filters are applied. For more information, see Understanding Connection Filtering. Note: If the Connection Filter agent is deployed on a computer behind another server that faces the Internet, other filters, such as sender filtering and recipient filtering, are invoked before the Connection Filter agent. Return to top

Sender Filtering
After connection filtering has been applied, Exchange 2010 examines the sender e-mail address against the list of blocked senders that you configure in sender filtering as shown in the following figure.

The Sender Filter agent then checks the sender's e-mail address contained in the From header fields in the message envelope and the message header. If either From header field matches the address in the Blocked Sender list, Exchange 2010 rejects the message at the protocol level, and no other filters are applied. Note: Even if recipients in your organization have put senders on their Microsoft Outlook Safe Senders List, sender filtering on the Edge Transport server will override the recipient's Outlook setting and reject the messages. For more information about sender filtering, see Understanding Sender Filtering. For more information about message envelopes and message headers, see Understanding the Pickup and Replay Directories. Return to top

Recipient Filtering
If sender filtering doesn't reject the message, Exchange runs connection filtering again. Exchange then applies the Recipient Filter agent as shown in the following figure.

The Recipient Filter agent examines the recipient against the Recipient Block list that you configure in the Recipient Filter agent settings. If the intended recipient matches an e-mail address on your Recipient Block list, Exchange 2010 rejects the message for that particular recipient. In addition, the Recipient Filter agent checks whether the recipient is present in the organization. If the recipient isn't present in the organization, Exchange rejects the message for that particular recipient. If multiple recipients are listed on the message and all the recipients aren't on the Recipient Block list, the message will continue to process. Otherwise, if the message is bound for only a single blocked recipient, no other filters are applied. When a message with blocked recipients is processed, the set of blocked recipients are removed from the message, and the message continues into the organization. Protocol-level SMTP rejection responses are sent to the sender for each blocked recipient. The Sender Reputation agent monitors the OnReject event to calculate sender reputation level (SRL). For more information, see Understanding Recipient Filtering. Return to top

Sender ID Filtering
If the message still contains valid recipients after recipient filtering has been applied, Exchange 2010 runs the Sender ID agent as shown in the following figure.

First, the Sender ID agent determines the Purported Responsible Address (PRA) of the message using the algorithm described in RFC 4407. This step is required to accurately identify the message sender. The PRA is an SMTP address, such as kim@contoso.com. The Sender ID agent then performs a Domain Name System (DNS) lookup against the domain part of the PRA. If that domain has published a sender policy framework (SPF) record, the agent uses the SPF record to evaluate the message according to the specification for RFC 4408. The result of the evaluation is stamped on the message in the anti-spam stamp. If that domain doesn't have a published SPF record, the Sender ID agent stamps a Sender ID result of "None" on the message. For more information about the types of stamps used for Sender ID filtering, see Understanding Anti-Spam Stamps. If the sender's DNS is from a blocked domain or a blocked address, the following actions may be taken depending on your configuration of Sender ID actions:

Reject message If the Sender ID action is set to Reject Message, Exchange rejects the message and sends an SMTP error response to the sending server. The SMTP error response is a 5xx level protocol response with text that corresponds to the Sender ID status. Delete message If the Sender ID action is set to Delete Message, Exchange deletes the message without informing the sending server of the deletion. The computer that has the Edge Transport server role installed sends a fake "OK" SMTP command to the sending server, and then deletes the message. Because the sending server assumes that the message was sent, the sending server won't retry sending the message in the same session. Stamp message with Sender ID result and continue processing Exchange stamps the message with the Sender ID result and continues processing the message. This metadata is evaluated by the Content Filter agent when an SCL is calculated. Additionally, sender reputation uses the message metadata when it calculates an SRL for the sender of the message. For more information, see Understanding Sender ID. Return to top

Content Filtering
Before Exchange content filtering calls the Exchange Intelligent Message Filter, it applies sender filtering again. The Exchange server then applies the Content Filter agent as shown in the following figure.

The Content Filter agent checks the following conditions in the message. If any of the conditions are true, the message bypasses content filtering and attachment filtering. These messages then go to antivirus scanning for processing. The following conditions are checked:

The sender's IP address is on the IP Allow list for connection filtering. All recipients are on the exceptions list for content filtering. The AntiSpamBypassEnabled parameter is set to $True on all the recipients' mailboxes. All the recipients have added this sender to their Outlook Safe Senders List, which is updated to the Edge Transport server by using safelist aggregation. The sender is a trusted partner and on the organization's list of senders that aren't filtered. In addition to the conditions listed, if the SMTP session has been authenticated as a trusted partner, and if the administrator has granted the Bypass Anti-Spam (MsExch-Bypass-Anti-Spam) permission to partners, the anti-spam agents will be disabled for messages during that session. The Bypass Anti-Spam permission isn't granted to partners by default and must be assigned by an administrator. If a message doesn't meet any of the conditions described, content filtering is applied. Content filtering assigns an SCL rating to the message. Based on the SCL rating, one of the following actions occurs:

If the SCL rating on the message is equal to or greater than the SCL delete threshold, and the SCL delete threshold is enabled, the Content Filter agent deletes the message. There is no protocol-level communication that tells the sending system or sender that the message was deleted. If the SCL rating is lower than the SCL

delete threshold value, the Content Filter agent doesn't delete the message. Instead, the Content Filter agent compares the SCL value to the SCL reject threshold. If the SCL rating on the message is equal to or greater than the SCL reject threshold, and the SCL reject threshold is enabled, the Content Filter agent rejects the message and sends a rejection response to the sending system. You can customize the rejection response. In some cases, a non-delivery report (NDR) is sent to the original sender of the message. If the SCL rating is lower than the SCL reject threshold value, the Content Filter agent doesn't reject the message. Instead, the Content Filter agent compares the SCL value to the SCL quarantine threshold. If the SCL rating on the message is equal to or greater than the SCL quarantine threshold, and the SCL quarantine threshold is enabled, the Content Filter agent sends the message to the spam quarantine mailbox. For more information about how to manage the spam quarantine mailbox, see Understanding Content Filtering. The message then continues to attachment filtering. For more information, see the following topics:

Configure Safelist Aggregation Understanding Content Filtering Return to top

Sender Reputation Filtering


After content filtering has been applied, Exchange applies sender reputation filtering as shown in the following figure.

Sender reputation weighs each of the following message statistics and calculates an SRL for each sender:

HELO/EHLO analysis Reverse DNS lookup Analysis of SCL ratings on messages from a specific sender Sender open proxy test The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. A value of 0 indicates that the sender isn't likely to be a spammer; a value of 9 indicates that the sender is likely to be a spammer. You can configure an SRL block threshold from 0 through 9 by which sender reputation issues a request to the Sender Filter agent to block the sender from sending a message into the organization. When a sender is blocked, the sender is added to the Blocked Senders list for a configurable period. How blocked messages are handled depends on the configuration of the Sender Filter agent. The following actions are the options for handling blocked messages:

Reject Delete and archive Accept and mark as a blocked sender If a sender is included in the IP Block list or Microsoft IP Reputation Service, the Sender Reputation agent issues an immediate request to the Sender Filter agent to block the sender. To take advantage of this functionality, you must enable and configure the Microsoft Exchange Anti-spam Update Service. By default, the Edge Transport server sets a rating of 0 for senders that haven't been analyzed. After a sender has sent 20 or more messages, sender reputation calculates an SRL that's based on the statistics listed earlier. For more information, see the following topics:

Understanding Sender Reputation Configure Sender Reputation Properties Return to top

Attachment Filtering
After sender reputation filtering has been applied, Exchange applies attachment filtering as shown in the following figure.

You can configure attachment filtering to block attachments based on their MIME content type, file name, or file name extension. If attachment filtering detects a content type or file name that has been blocked, one of the following actions will occur based on your attachment filtering settings:

Reject If the action setting is set to Reject, both the e-mail message and attachment are prevented from being delivered to the recipient and the system generates a delivery status notification (DSN) failure message to the sender. You can customize your rejection response. Silent Delete If the action setting is set to Silent Delete, both the e-mail message and attachment are prevented from being delivered to the recipient. A notification that the e-mail message and attachment were blocked isn't returned to the sender. Strip If the action setting is set to Strip, the attachment is stripped from the e-mail message. This value allows the message and other attachments that don't match an entry on the attachment block list to be delivered to the recipient. A notification that the attachment was blocked is added to the recipient's e-mail message. If the message wasn't rejected or deleted, or attachment filtering didn't detect blocked attachment types, the message is then scanned for viruses. For more information, see Configure Attachment Filtering. Return to top

Antivirus Scanning
After attachment filtering has been applied, or if the recipients were bypassed in content filtering, Forefront Protection for Exchange Server antivirus scanning is applied as shown in the following figure.

Forefront Protection for Exchange Server is an antivirus software package that's tightly integrated with Exchange 2010 and offers additional antivirus protection for your Exchange environment. When Forefront Protection for Exchange Server detects messages that seem to contain a virus, the system deletes the message, generates a notification message, and sends the notification to the recipients mailbox. For more information, see Microsoft Forefront Protection 2010 for Exchange Server. Return to top

Outlook Junk E-Mail Filtering


After all the filters are applied and the message has been scanned for viruses, the message is sent to the intended recipient's mailbox and junk e-mail filtering is applied as shown in the following figure.

If the SCL rating for the message is equal to or greater than the SCL Junk E-mail folder threshold, and the SCL Junk E-mail folder threshold is enabled, the Mailbox server puts the message in the Outlook user's Junk E-mail folder. If the SCL value for a message is lower than the values for the SCL delete, reject, quarantine, and Junk E-mail folder thresholds, the Mailbox server puts the message in the user's Inbox. For more information about the SCL thresholds, see Understanding Spam Confidence Level Threshold. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Anti-Spam Stamps


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-28 In Microsoft Exchange Server 2010, anti-spam stamps help you diagnose spam-related problems by applying diagnostic metadata, or stamps, such as sender-specific information, puzzle validation results, and content filtering results, to messages as they pass through the anti-spam features that filter inbound messages from the Internet. There are three anti-spam stamps: the phishing confidence level stamp, the spam confidence level stamp, and the Sender ID stamp. This topic explains how to view anti-spam stamps and describes the contents of the anti-spam report. You can use anti-spam stamps as diagnostic tools to determine what actions to take on false-positives and on suspected spam messages that individuals receive in their mailboxes. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Viewing Anti-Spam Stamps


You can view anti-spam stamps by using Microsoft Office Outlook 2007. For more information about how to view anti-spam stamps, see View Anti-Spam Stamps in Outlook 2010 and Outlook 2007.

Understanding the Anti-Spam Report


The anti-spam report is a summary report of the anti-spam filter results that have been applied to an e-mail message. The Content Filter agent applies this stamp to the message envelope in the form of an X-header as follows.

X-MS-Exchange-Organization-Antispam-Report: DV:<DATVersion>;CW:CustomList;PCL:PhishingVerdict <verdict>;P100:PhishingBlock;PP:Presolve;SID:SenderIDSt

The following table describes the filter information that can appear in an anti-spam report. Note: The anti-spam report only displays information from the filters that were applied to the specific message. An anti-spam report doesn't usually contain all the information listed in the following table. For example, you may receive the following anti-spam report: DV:3.1.3924.1409;SID:SenderIDStatus Fail;PCL:PhishingLevel SUSPICIOUS;CW:CustomList;PP:Presolved;TIME:TimeBasedFeatures.

Filter information in an anti-spam report


Stamp SID Description The Sender ID (SID) stamp is based on the sender policy framework (SPF) that authorizes the use of domains in e-mail. The SPF is displayed in the message envelope as Received-SPF. The Sender ID evaluation process generates a Sender ID status for the message. This status can be returned as one of the following values: Pass Both the IP address and Purported Responsible Address (PRA) passed the Sender ID verification check. Neutral Published Sender ID data is explicitly inconclusive. Soft fail The IP address for the PRA may be in the not permitted set. Fail The IP Address is not permitted; no PRA is found in the incoming mail or the sending domain does not exist. None No published SPF data exists in the sender's DNS. TempError A temporary DNS failure occurred, such as an unavailable DNS server. PermError The DNS record is invalid, such as an error in the record format. The Sender ID stamp is displayed as an X-Header in the message envelope as follows:

X-MS-Exchange-Organization-SenderIdResult:<status>

For more information about Sender ID, see Understanding Sender ID. DV SA The DAT version (DV) stamp indicates the version of the spam definition file that was used when scanning the message. The signature action (SA) stamp indicates that the message was either recovered or deleted because of a signature that was found in the message. The signature DAT version (SV) stamp indicates the version of the signature file that was used when scanning the message. The phishing confidence level (PCL) stamp displays the rating of the message based on its content and is applied when the message is processed by the Content Filter agent. This status can be returned as one of the following values: Neutral The message's content isn't likely to be phishing. Suspicious The message's content is likely to be phishing.

SV PCL

The PCL value can range from 1 through 8. A PCL rating from 1 through 3 returns a status of Neutral. This means that the message's content isn't likely to be phishing. A PCL rating from 4 through 8 returns a status of Suspicious. This means that the message is likely to be phishing. The values are used to determine what action Outlook takes on messages. Outlook uses the PCL stamp to block the content of suspicious messages. The PCL stamp is displayed as an X-header in the message envelope as follows:

X-MS-Exchange-Organization-PCL:<status>

SCL

The spam confidence level (SCL) stamp of the message displays the rating of the message based on its content. The Content Filter agent uses Microsoft SmartScreen technology to assess the contents of a message and to assign an SCL rating to each message. The SCL value is from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered more likely to be spam. The actions that Exchange and Outlook take depend on your SCL threshold settings. The SCL stamp is displayed as an X-header in the message envelope as follows:

X-MS-Exchange-Organization-SCL:<status>

For more information about SCL thresholds and actions, see Understanding Spam Confidence Level Threshold. CW The custom weight (CW) stamp of a message indicates that the message contains an unapproved word or phrase and that the SCL value, or weight, of that unapproved word or phrase was applied to the final SCL score: Unapproved phrases, or Block phrases, have maximum weight and change the SCL score to 9. Approved words or phrases, or Allow phrases, have minimum weight and change the SCL score to 0. For more information about how to add approved and unapproved words or phrases to the Content Filtering agent, see Configure Content Filtering Properties. PP The presolved puzzle (PP) stamp indicates that if a sender's message contains a valid, solved computational postmark, based on Outlook E-mail Postmark validation functionality, it's unlikely that the sender is a malicious sender. In this case, the Content Filter agent would reduce the SCL rating. The Content Filter agent doesn't change the SCL rating if the E-mail Postmark validation feature is enabled and either of the following conditions is true: An inbound message doesn't contain a computational postmark header. The computational postmark header isn't valid. For more information about the postmark validation feature, see Configure Content Filtering Properties. TIME:TimeBasedFeatures The TIME stamp indicates that there was a significant time delay between the time that the message was sent and the time that the message was received. The TIME stamp is used to determine the final SCL rating for the message. The MIME stamp indicates that the e-mail message isn't MIME compliant. The P100 stamp indicates that the message contains a URL that's present in a phishing definition file. The IPOnAllowList stamp indicates that the sender's IP address is on the IP Allow list. For more information about the IP Allow list, see Understanding Connection Filtering. The MessageSecurityAntispamBypass stamp indicates that the message wasn't filtered for content and that the sender has been granted permission to bypass the anti-spam filters. The SenderBypassed stamp indicates that the Content Filter agent doesn't process any content filtering for messages that are received from this sender. For more information, see Configure Content Filtering Properties. The AllRecipientsBypassed stamp indicates that one of the following conditions was met for all recipients listed in the message: The AntispamBypassedEnabled parameter on the recipient's mailbox is set to $true. This is a per-recipient setting that can only be set by an administrator. For more information about this setting, see Set-Mailbox. The message sender is in the recipient's Outlook Safe Senders List. For more information about the Safe Senders List, see Configure Safelist Aggregation. The Content Filter agent doesn't process any content filtering for messages that are sent to this recipient. For more information about recipient exceptions, see Configure Content Filtering Properties.

MIME:MIMECompliance P100:PhishingBlock IPOnAllowList

MessageSecurityAntispamBypass

SenderBypassed

AllRecipientsBypassed

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Anti-Spam Updates


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-06 Microsoft Exchange Server 2010 includes many anti-spam features that depend on downloaded data to determine whether a message can be delivered with confidence that it isn't spam. The following data must be kept up-to-date for the anti-spam features to operate optimally:

Content filter updates These updates contain data about phishing Web sites, Microsoft SmartScreen spam heuristics, and other Intelligent Message Filter updates. Content filter updates generally contain about 6 MB of data that's useful for longer periods of time than other anti-spam update data. Microsoft IP Reputation Service data The Microsoft IP Reputation Service is an IP Block list service offered exclusively to Exchange 2010 customers. Administrators can decide to implement and use the Microsoft IP Reputation Service in addition to other real-time block list services. Spam signature data Spam signatures identify the latest spam campaigns. The spam is hashed into a message digest, or spam signature. This data is used by content filtering to assign a higher spam confidence level (SCL) to known spam. The spam signature files are small. A collection of spam signatures is only a few KB. The spam signatures are also time sensitive. Therefore, they're updated more frequently than other anti-spam data sets. Anti-spam updates contain data only. They don't contain updated binaries or libraries. Anti-spam updates don't require mail flow interruption or service restarts.

Updates with Microsoft Update


By default, anti-spam updates aren't automatic. Instead, the administrator must visit Microsoft Update to download and install the content filter updates. The content filter update data is updated and available for download every two weeks. Manual updates from Microsoft Update don't include the Microsoft IP Reputation Service or spam signature data. The Microsoft IP Reputation Service and spam signature data is only available when you use the anti-spam features of Microsoft Forefront Protection 2010 for Exchange Server (FPE).

Updates with Forefront Protection 2010 for Exchange Server


Microsoft Forefront Protection 2010 for Exchange Server (FPE) integrates multiple scan engines into a comprehensive, layered solution that helps you protect your Microsoft Exchange server messaging environment from malware, spam, and inappropriate content. FPE prevents the spread of malicious content by scanning all messages in real time with minimal impact on Exchange server performance or message delivery time. You can enable FPE anti-spam technology in both the Exchange Edge Transport and Exchange Hub Transport roles. However, the Edge Transport role is the preferred location for anti-spam filtering. The technology includes a series of agents that are registered with Exchange and are invoked at specific points in the SMTP pipeline. FPE can also be integrated with Forefront Online Protection for Exchange (FOPE) to provide an additional layer of filtering for your messaging environment. When you deploy FPE, the anti-spam features that are built in to Exchange are disabled. To learn more about how the FPE anti-spam solution works, see Using Antispam Filtering. To learn more about how anti-spam updates work when you're using FPE, see Configuring and scheduling updates.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Attachment Filtering


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 In Microsoft Exchange Server 2010, you can use attachment filtering to apply filters at the server level to control the attachments that users receive. Attachment filtering is increasingly important in today's environment, where many attachments contain harmful viruses or inappropriate material that may cause significant damage to the user's computer or to the organization as a whole by damaging important documentation or releasing sensitive information to the public. Note: As a best practice, don't remove attachments from digitally signed, encrypted, or rights-protected e-mail messages. If you remove attachments from such messages, you invalidate the digitally signed messages and make encrypted and rights-protected messages unreadable. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

Types of Attachment Filtering in Exchange 2010


You can use the following types of attachment filtering to control attachments that enter or leave your organization:

Filtering based on file name or file name extension You can filter attachments by specifying the exact file name or file name extension to be filtered. An example of an exact file name filter is BadFilename.exe. An example of a file name extension filter is *.exe. Filtering based on file MIME content type You can also filter attachments by specifying the MIME content type to be filtered. MIME content types indicate what the attachment is, whether it is a JPEG image, an executable file, a Microsoft Office Excel file, or some other file type. E-mail attachments are encoded in email messages as ASCII text. E-mail servers and clients use the information about MIME content type to decode the ASCII text information in an e-mail message and convert it into a usable binary file familiar to the user. Content types are expressed as type/subtype. For example, the JPEG image content type is expressed as image/jpeg. To view a complete list of all file name extensions and content types that attachment filtering can filter on, run the following command.

Get-AttachmentFilterEntry | FL

If an attachment matches one of these filtering criteria, you can configure one of the following actions to be performed on the attachment:

Block whole message and attachment An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, the sender receives a delivery status notification (DSN) message that states that the message contains an unacceptable attachment file name. Strip attachment but allow message through An attachment that matches an attachment filter can be removed whereas the e-mail message and any other attachments that don't match the filter are allowed through. If an attachment is stripped, it's replaced with a text file that explains why the attachment was removed. This action is the default setting. Silently delete message and attachment An attachment that matches an attachment filter together with its whole e-mail message can be blocked from entering the messaging system. If an attachment and e-mail message are blocked, neither the sender nor the recipient receives notification. Caution: You can't retrieve e-mail messages and attachments that are blocked or attachments that are stripped. When you configure attachment filters, make sure that you carefully examine all possible file name matches and verify that legitimate attachments won't be affected by the filter. RejectResponse This parameter specifies the string response included in the non-delivery report (NDR) message if an e-mail message that has a filtered e-mail attachment is returned to the sender. For more information, see Configure Attachment Filtering.

File Filtering by Using Forefront Protection for Exchange Server


The file filtering functionality provided by Microsoft Forefront Protection 2010 for Exchange Server includes advanced features that are unavailable in the default Attachment Filter agent included with Exchange 2010 Standard Edition. For example, container files, which are files that contain other files, can be scanned for offending file types. Forefront Protection for Exchange Server filtering can scan the following container files and act upon embedded files:

PKZip (.zip) GNU Zip (.gzip) Self-extracting compressed file archives (.zip) Compressed files (.zip) Java archive (.jar) TNEF (winmail.dat) Structured storage (.doc, .xls, .ppt, and others) MIME (.eml) SMIME (.eml) UUEncode (.uue) UNIX tape archive (.tar) RAR archive (.rar) MACBinary (.bin)

Note: The default Attachment Filter agent included with Exchange 2010 Standard Edition detects file types even if they have been renamed. Attachment filtering also makes sure that compressed files with a .zip or .lzh file name extension don't contain blocked attachments by performing a file name extension match against the files in the compressed files. Forefront Protection for Exchange Server file filtering has the additional capability of determining if a blocked attachment has been renamed within a container file. You can also filter files by file size. Additionally, you can configure Forefront Security for Exchange Server to quarantine filtered files or to send e-mail notifications based on file filter matches. For more information, see Microsoft Forefront Protection 2010 for Exchange Server.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Connection Filtering


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-22 The Connection Filter agent is an anti-spam agent enabled on computers running Microsoft Exchange Server 2010 that have the Edge Transport server role installed. The Connection Filter agent relies on the IP address of the remote server that's trying to connect, to determine what action, if any, to take on an inbound message. The remote IP address is available to the Connection Filter agent as a by-product of the underlying TCP/IP connection required for the SMTP session. Because the Connection Filter agent must evaluate the IP address of the remote server that's sending the message to be effective, the Connection Filter agent is typically enabled on the Internet-facing Edge Transport server. However, you may also perform additional configuration to run the Connection Filter agent deeper in the inbound message path. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. To reduce redundancy and improve overall system performance and efficiency, you must understand the order in which the agents evaluate inbound messages. Understanding the order in which the filters evaluate inbound messages will help you optimize your configuration of the Edge Transport servers. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. When you enable the Connection Filter agent, the Connection Filter agent is the first anti-spam agent to run when an inbound message is evaluated. When an inbound message is submitted to an Edge Transport server on which the Connection Filter agent is enabled, the source IP address of the SMTP connection is checked against IP Allow lists and IP Block lists. If the source IP address is listed on an IP Allow list, the message is sent to the destination without additional processing by other anti-spam agents. If the source IP address is listed on an IP Block list, the SMTP connection is dropped after all RCPT TO headers in the message are processed. Note: The timing of when a specific connection is dropped may depend on other anti-spam configurations. For example, you can specify which recipients always receive email messages, even if the source IP address is blocked. Additionally, you may have configured other agents that rely on content from the DATA command to be parsed. The Connection Filter agent always drops blocked connections according to the overall anti-spam configuration. If the source IP address isn't listed on any IP Allow list or IP Block list, the message continues to flow through other anti-spam agents if other anti-spam agents are configured. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents IP Allow Lists and IP Block Lists Configuring Connection Filtering for Edge Transport Servers That Aren't the First SMTP Entry Point Testing IP Block List and IP Allow List Functionality

IP Allow Lists and IP Block Lists

The Connection Filter agent compares the IP address of the server sending a message to any of the following data stores of IP addresses:

Administrator-defined IP Allow lists and IP Block lists IP Block List providers IP Allow List providers For more information about IP Block List providers, see "IP Block List Providers" later in this topic. You must configure at least one of these data stores of IP addresses for the Connection Filter agent to be operational. If the data stores of IP addresses don't contain the IP addresses on the IP Allow lists or IP Block lists, or if you don't have any IP Block List providers or IP Allow List providers configured, you should disable the Connection Filter agent.

Administrator-Defined IP Allow Lists and IP Block Lists


Administrators of Edge Transport servers maintain administrator-defined lists of IP addresses. You can enter and delete the IP addresses that you want to allow or block by using the Exchange Management Console (EMC) or the Exchange Management Shell. You can add IP addresses individually, by IP address range, or by IP address and subnet mask. When you add an IP address or IP address range, you must specify the IP address or IP address range as an IP Block list address or an IP Allow list address. Additionally, you can specify an expiration time for each IP Block list entry that you create. When you set the expiration time, the expiration time specifies how long the IP Block list entry is active. When the expiration time duration is reached, the IP Block list entry is disabled. By using administrator-defined IP Allow lists and IP Block lists, you can configure connection filtering to support the following scenarios:

To exempt IP addresses from the IP Block lists of IP Block List providers You may have to exempt IP addresses from the IP Block lists of IP Block List providers when legitimate senders are unintentionally put on an IP Block List provider's IP Block list. For example, legitimate senders could be unintentionally put on an IP Block list when an SMTP server was unintentionally configured to act as an open relay. In this scenario, the sender will probably try to correct the misconfiguration and remove the IP address from the IP Block List provider's IP Block list. For more information about IP Block List providers, see "IP Block List Providers" later in this topic.

To deny access from IP addresses that are a source of unsolicited e-mail messages but aren't found on an IP Block List provider's IP Block lists Sometimes, you may receive a large quantity of unsolicited messages from a source that wasn't yet identified by a real-time block list service to which you subscribe.

IP Block List Providers


IP Block List provider services can help you reduce the number of unsolicited e-mail messages that enter your organization. Note: IP Block List provider services are frequently referred to as real-time block list services or RBL services. The EMC refers to real-time block list services as IP Block List provider services. The terms real-time block list services, RBL services, and IP Block List provider services are equivalent. IP Block List provider services compile lists of IP addresses from which spam has originated in the past. Additionally, some IP Block List providers provide lists of IP addresses for which SMTP is configured for open relay. There are also IP Block List provider services that provide lists of IP addresses that support dial-up access. Internet service providers (ISPs) that provide dial-up access services to their clients assign dynamic IP addresses for each dial-up session. Some ISPs block SMTP traffic from dial-up accounts. These ISPs and the attendant dial-up IP ranges aren't typically added to IP Block lists. However, some ISPs allow clients to send SMTP traffic from dial-up accounts. Malicious users take advantage of ISPs that allow SMTP traffic to send spam on dynamically assigned IP addresses. When the IP address is put on an IP Block list, the malicious users start another dial-up session and receive a new IP address. Frequently, a single IP Block List provider can provide a list of IP addresses that covers all these spam threats. You can configure multiple IP Block List provider configurations by using the EMC or the Shell. Each service requires a separate IP Block List provider configuration in the EMC or the Shell. When you configure the Connection Filter agent to use an IP Block List provider, the Connection Filter agent queries the IP Block List provider service to determine whether a match exists with the connecting IP addresses before the message is accepted into the organization. Before the Connection Filter agent contacts the IP Block List provider to verify an IP address, the IP address is first compared to the administrator-defined IP Allow list and IP Block list. If the IP address doesn't exist on either the administrator-defined IP Allow list or IP Block list, the Connection Filter agent queries the IP Block List provider services according to the priority rating assigned to each provider. If the IP address appears on the IP Block list of an IP Block List provider, the Edge Transport server waits for and parses the RCPT TO header, responds to the sending system with an SMTP 550 error, and closes the connection. If the IP address doesn't appear on the IP Block lists of any one of the IP Block List providers, the next agent in the anti-spam chain processes the connection. For more information about the order in which the default anti-spam and antivirus agents filter inbound messages from the Internet, see Understanding Anti-Spam and Antivirus Functionality. When you use the Connection Filter agent, it's a best practice to use one or more IP Block List providers to manage access into your organization. The use of an administrator-defined block list to maintain your own IP Block list is time-consuming and may be impossible from a human resource perspective in most organizations. Therefore, we recommend the use of an external IP Block List provider service, whose sole purpose is to maintain IP Block lists. However, there may be some disadvantages to using an IP Block List provider. Because the Connection Filter agent must query an external entity for each unknown IP address, outages or delays at the IP Block List provider service can cause delays in the processing of messages on the Edge Transport server. In extreme cases, such outages or delays could cause a mail-flow bottleneck on the Edge Transport server. The other disadvantage of using an external IP Block List provider service is that legitimate senders are sometimes added to the IP Block lists of IP Block List providers by mistake. For example, legitimate senders can be added to the IP Block lists maintained by IP Block List providers as the result of an SMTP misconfiguration, where the SMTP server was unintentionally configured to act as an open relay. For each IP Block List provider service that you configure, you can customize the SMTP 550 error returned to the sender when the sender IP address is matched to an IP Block List provider service and is subsequently blocked by the Connection Filter agent. It's a best practice to customize the SMTP 550 error to identify the IP Block List provider service that identifies the sender as a blocked IP address. This best practice enables legitimate senders to contact the IP Block List provider service so that they can be removed from the IP Block List provider service's IP Block list. Different IP Block List provider services may return different codes when the IP address of a remote server sending a message matches an IP address on an IP Block List provider service's IP Block list. Most IP Block List provider services return one of the following data types: bitmask or absolute value. Within these data types, there may be multiple values that indicate the type of list that the submitted IP address is on.

Bitmask Example
This section shows an example of the status codes returned by most Block List providers. For details about the status codes that the provider returns, see the documentation from the specific provider. For bitmask data types, the IP Block List provider service returns a status code of 127.0.0.x, where the integer x is any one of the values listed in the following table.

Values and status codes for bitmask data types


Value 1 2 4 Status code The IP address is on an IP Block list. The SMTP server is configured to act as an open relay. The IP address supports a dial-up IP address.

For absolute value types, the IP Block List provider service returns explicit responses based on the cause of the block of the IP address. The following table shows some examples of absolute values and the explicit responses.

Values and status codes for absolute value data types


Value 127.0.0.2 Explicit response The IP address is a direct spam source.

127.0.0.4 127.0.0.5

The IP address is a bulk mailer. The remote server sending the message is known to support multistage open relays.

IP Allow List Providers


You can also manage inbound messages by using IP Allow List provider services that provide IP Allow lists. IP Allow lists are sometimes referred to as IP safe lists or white lists elsewhere in the software industry. IP Allow List providers maintain lists of IP addresses that are definitively known not to be associated with any spam activity. When an IP Allow List provider returns an IP Allow match, which indicates that the sender's IP address is more likely to be a reputable or safe sender, the Connection Filter agent relays the message to the next agent in the anti-spam chain. Return to top

Configuring Connection Filtering for Edge Transport Servers That Aren't the First SMTP Entry Point
In some organizations, the Edge Transport server role is installed on computers that don't process SMTP requests directly on the Internet. In this scenario, the Edge Transport server is behind another front-end SMTP server that processes inbound messages directly from the Internet. In this scenario, the Connection Filter agent must be able to extract the correct originating IP address from the message. To extract and evaluate the originating IP address, the Connection Filter agent must parse the Received headers from the message and compare those headers to the known SMTP server in the perimeter network. When an RFC-compliant SMTP server receives a message, the server updates the message's Received header with the domain name and IP address of the sender. Therefore, for each SMTP server between the originating sender and the Edge Transport server, the SMTP server adds an additional Received header entry. When you configure your perimeter network to support Exchange 2010, you must specify all the IP addresses for the SMTP servers in your perimeter network. The IP address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the computer that runs the Connection Filter agent, the IP address in the Received header that doesn't match an SMTP server IP address in your perimeter network is assumed to be the originating IP address. You must specify all internal SMTP servers on the transport configuration object in the Active Directory forest before you run connection filtering. Specify the internal SMTP servers by using the InternalSMTPServers parameter on the Set-TransportConfig cmdlet. Return to top

Testing IP Block List and IP Allow List Functionality


After you configure an IP Block List provider service or IP Allow List provider service, you can test to make sure that connection filtering is configured correctly for the particular service. Most IP Block List provider services or IP Allow List provider services provide test IP addresses that you can use to test their services. When you run a test against an IP Block List provider service or an IP Allow List provider service, the Connection Filter agent issues a Domain Name System (DNS) query based on the real-time block list IP address that should respond with a specific response. For more information about how to test IP addresses against an IP Block List provider service or an IP Allow List provider service, see Test-IPAllowListProvider and Test-IPBlockListProvider. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Content Filtering


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-28 The Content Filter agent evaluates inbound e-mail messages and assesses the probability that an inbound message is legitimate or spam. Unlike many other filtering technologies, the Content Filter agent uses characteristics from a statistically significant sample of e-mail messages. The inclusion of legitimate messages in this sample reduces the chance of mistakes. Because the Content Filter agent recognizes characteristics of legitimate messages and spam, its accuracy is increased. Updates to the Content Filter agent are available periodically through Microsoft Update. Contents Using the Content Filter Agent Configuring the Content Filter Agent Using SCL Value Stamped by the Content Filter Agent in Edge Transport Rules Forefront Protection 2010 for Exchange Server

Using the Content Filter Agent


The Content Filter agent is one of several anti-spam agents. When you configure anti-spam agents on a computer that has the Edge Transport server role installed, the agents act on messages cumulatively to reduce the amount of spam that enters the organization. For more information about how to plan and deploy anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. The Content Filter agent assigns a spam confidence level (SCL) rating to each message. The SCL rating is a number between 0 and 9. A higher SCL rating indicates that a message is more likely to be spam. You can configure the Content Filter agent to take the following actions on messages according to their SCL rating:

Delete message Reject message Quarantine message For example, you may determine that messages that have an SCL rating of 7 or higher must be deleted, messages that have an SCL rating of 6 must be rejected, and messages that have an SCL rating of 5 must be quarantined. You can adjust the SCL threshold behavior by assigning different SCL ratings to each of these actions. For more information about how to adjust the SCL threshold to suit your organization's requirements and about per-recipient SCL thresholds, see Understanding Spam Confidence Level Threshold. Note: Messages that are over 11 MB aren't scanned by the Intelligent Message Filter. Instead, they pass through the Content Filter without being scanned. However, the default maximum message size limit configured on Exchange 2010 Receive connectors is 10 MB. Therefore, the 11 MB threshold for the Intelligent Message Filter isn't a practical concern in the default Exchange configuration.

Allow Phrases and Block Phrases


You can customize how the Content Filter agent assigns SCL values by configuring custom words. Custom words are individual words or phrases that the Content Filter agent uses to apply appropriate filter processing. You configure approved words or phrases with Allow phrases and unapproved words or phrases with Block phrases. When the Content Filter agent detects a preconfigured Allow phrase in an inbound message, the Content Filter agent automatically assigns an SCL value of 0 to the message. Alternatively, when the Content Filter agent detects a configured Block phrase in an inbound message, the Content Filter agent assigns an SCL rating of 9. You can enter custom words or phrases in any combination of uppercase and lowercase letters. However, when the Content Filter agent evaluates message content, it ignores case. The maximum number of custom words or phrases that can be created is 800.

Outlook E-mail Postmark Validation


The Content Filter agent also includes Microsoft Office Outlook E-mail Postmark validation, a computational proof that Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate e-mail from junk e-mail. This feature helps reduce the chance of false positives. In the context of spam filtering, a false positive exists when a spam filter incorrectly identifies a message from a legitimate sender as spam. When Outlook E-mail Postmark validation is enabled, the Content Filter agent parses the inbound message for a computational postmark header. The presence of a valid, solved computational postmark header in the message indicates that the client computer that generated the message solved the computational postmark. Computers don't require significant processing time to solve individual computational postmarks. However, processing postmarks for many messages may be prohibitive to a malicious sender. Anyone who sends millions of spam messages is unlikely to invest the processing power that is required to solve computational postmarks for all outbound spam. If a sender's e-mail contains a valid, solved computational postmark, it's unlikely that the sender is a malicious sender. In this case, the Content Filter agent would lower the SCL rating. If the postmark validation feature is enabled and an inbound message either doesn't contain a computational postmark header or the computational postmark header isn't valid, the Content Filter agent would not change the SCL rating.

Bypassing the Recipient, Sender, and Sender Domain

In some organizations, all e-mail to certain aliases must be accepted. This scenario can introduce problems if your organization is in an industry that manages significant volumes of spam. For example, a company named Woodgrove Bank has an alias named customerloans@woodgrovebank.com that provides e-mail-based support to external loan customers. The Exchange administrators configure the Content Filter agent to set Block phrases that filter out words or phrases that are typically used in spam that is sent by unscrupulous loan agencies. To prevent potentially legitimate messages from being rejected, the administrators set exceptions to content filtering by entering a list of SMTP e-mail recipient addresses in the Content Filter agent configuration. You can also specify senders and sender domains that you do not want the Content Filter agent to block.

Safelist Aggregation
In Exchange 2010, the Content Filter agent on the Edge Transport server uses the Outlook Safe Senders Lists, Blocked Sender List, Safe Recipients Lists, and trusted contacts from Outlook to optimize spam filtering. Safelist aggregation is a set of anti-spam functionality that is shared across Outlook and Exchange 2010. As its name suggests, this functionality collects data from the anti-spam safe lists that Outlook users configure and makes this data available to the anti-spam agents on the Edge Transport server. E-mail messages that Outlook users receive from contacts that those users have added to their Outlook Safe Recipients List, Safe Senders List, or trusted contacts list are identified by the Content Filter agent as safe. The Sender Filter agent also performs per-recipient sender filtering using the Blocked Senders list that users configure. For more information, see Understanding Safelist Aggregation.

Configuring the Content Filter Agent


You configure the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell. Important: Configuration changes that you make to the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell are only made to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must make Content Filter configuration changes to each computer. For more information about how to configure content filtering, see Configure Content Filtering Properties.

Using SCL Value Stamped by the Content Filter Agent in Edge Transport Rules
In Exchange 2010, transport rules that run on Edge Transport servers are applied to messages by the Edge Rule agent on the OnEndOfData SMTP transport event. One of the transport rule conditions available on Edge Transport servers is the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition. By using this transport rule condition, you can apply a transport rule action to a message based on the SCL value stamped on the message. The Content Filter agent stamps an SCL value on the message based on an analysis of the message content and is used to determine whether the message is spam. The Content Filter agent also runs on the OnEndOfData SMTP transport event.

Note: Although the Content Filter agent also runs on other events, the SCL value is stamped on the message by the instance of the Content Filter agent registered on the OnEndOfData SMTP transport event. Because both the Edge Rule agent and the Content Filter agent run on the OnEndOfData SMTP transport event, the priority value applied to each transport agent is used to determine which transport agent runs first. By default, the Edge Rule agent runs before the Content Filter agent to reduce the cost of processing messages that may be blocked by the Edge Rule agent. However, because the Edge Rule agent runs before the Content Filter agent and therefore the SCL value has not yet been stamped on the message, you can't use the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition in the default configuration. For details about how to configure the Content Filter agent to run before the Edge Rule agent on the OnEndOfData SMTP transport event, see Make the SCL Value Available to Edge Transport Rules. This enables the Content Filter agent to stamp an SCL value on a message that can then be read by the with a spam confidence (SCL) rating that is greater than or equal to limit transport rule condition. For more information about transport agents and transport agent priority, see Understanding Transport Agents. If you configure the Content Filter agent with a higher priority value than the Edge Rule agent, the Edge Transport server may incur additional processing costs because all the messages that are received by the Edge Transport server will be evaluated by the Content Filter agent. This is true even if the message is later rejected by a transport rule that is configured on the Edge Rule agent. Also, you will no longer be able to configure a transport rule on the Edge Transport server to stamp a message that has an SCL value of -1. This value indicates to the Content Filter agent that the message should not be evaluated.

Forefront Protection 2010 for Exchange Server


Microsoft Forefront Protection 2010 for Exchange Server (FPE) integrates multiple scan engines into a comprehensive, layered solution that helps you protect your Microsoft Exchange server messaging environment from malware, spam, and inappropriate content. FPE prevents the spread of malicious content by scanning all messages in real time with minimal impact on Exchange server performance or message delivery time. You can enable FPE anti-spam technology in both the Exchange Edge Transport and Exchange Hub Transport roles. However, the Edge Transport role is the preferred location for anti-spam filtering. The technology includes a series of agents that are registered with Exchange and are invoked at specific points in the SMTP pipeline. FPE can also be integrated with Forefront Online Protection for Exchange (FOPE) to provide an additional layer of filtering for your messaging environment. When you deploy FPE, the anti-spam features that are built in to Exchange are disabled. To learn more about how the FPE anti-spam solution works, see Using Antispam Filtering.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Recipient Filtering


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-11-30 The Recipient Filter agent is an anti-spam agent enabled on computers running Microsoft Exchange Server 2010 that have the Edge Transport server role installed. The Recipient Filter agent relies on the RCPT TO SMTP header to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. For more information about how to plan and deploy anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. The Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the organization. The Recipient Filter agent can help you prevent the acceptance of messages in the following scenarios:

Nonexistent recipients You can prevent delivery to recipients that aren't in the organization's address book. For example, you may want to stop delivery to frequently misused account names, such as administrator@contoso.com or support@contoso.com. Restricted distribution lists You can prevent delivery of Internet mail to distribution lists that should be used only by internal users. Mailboxes that should never receive messages from the Internet You can prevent delivery of Internet mail to a specific mailbox or alias that's typically used inside the organization, such as Helpdesk. The Recipient Filter agent acts on recipients stored in one or both of the following data sources:

Recipient Block list An administrator-defined list of recipients for which inbound messages from the Internet should never be accepted. Recipient Lookup Verification that the recipient is in the organization. Recipient Lookup requires access to Active Directory information provided by EdgeSync to Active Directory Lightweight Directory Services (AD LDS). For more information about Recipient Block lists and Recipient Lookup functionality, see "Recipient Data Sources" later in this topic. When you enable the Recipient Filter agent, one of the following actions is taken on inbound messages according to the characteristics of the recipients. These recipients are indicated by the RCPT TO header.

If the inbound message contains a recipient that is on the Recipient Block list, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server. If the inbound message contains a recipient that doesn't match any recipients in Recipient Lookup, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server. If the recipient isn't on the Recipient Block list and the recipient is in Recipient Lookup, the Edge Transport server sends a "250 2.1.5 Recipient OK" SMTP response to the sending server, and the next anti-spam agent in the chain processes the message. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Configuring AD LDS for Recipient Lookup Recipient Data Sources Tarpitting Functionality Configuring the Tarpitting Interval Multiple Namespaces

Configuring AD LDS for Recipient Lookup


One of the most effective ways to reduce spam is to validate recipients before accepting inbound messages from the Internet. Therefore, it's a good idea to configure the AD LDS instance that runs on the Edge Transport server to synchronize with Active Directory. By default, AD LDS is installed and configured on the Edge Transport server. However, you must configure AD LDS to communicate with an Active Directory domain-joined global catalog server. Most of the time, you must also configure your firewall to enable specific ports to communicate with AD LDS. For more information, see Understanding Edge Subscriptions. After you configure AD LDS to replicate a Recipient Block list from Active Directory, you must then enable blocking of messages sent to recipients who aren't present in the Exchange organization. You enable message blocking on the Blocked Recipients tab of the Recipient Filtering Properties page in the Exchange Management Console (EMC). You can also enable message blocking by using the Set-RecipientFilterConfig cmdlet in the Exchange Management Shell. For more information, see SetRecipientFilterConfig. Return to top

Recipient Data Sources


As mentioned earlier, the Recipient Filter agent references two data sources when it compares recipients on inbound messages: the Recipient Block list and Recipient Lookup.

Recipient Block List


The Recipient Block list is maintained by the Edge Transport server administrators. The Recipient Block list data is stored in the Edge Transport server instance of AD LDS. You must enter blocked recipients on each Edge Transport server computer.

You can enter the recipients that you want the Recipient Filter agent to block in the EMC on the Blocked Recipients tab of the Recipient Filtering Properties page. You use the Set-RecipientFilterConfig cmdlet in the Shell to enter recipients. For more information about how to configure the Recipient Filter agent, see Configure Recipient Filtering Properties.

Recipient Lookup
One benefit of the Recipient Filter agent is the ability to verify that the recipients on an inbound message are in your organization before Exchange 2010 transmits the message into your organization. The ability to verify recipients in your organization relies on a recipient data source available to the Edge Transport server. Because the Edge Transport server isn't an Active Directory domain-joined computer and could be segregated from the organization by a firewall, you must configure a Recipient Lookup data source for the Edge Transport server to use. The Edge Transport server role uses AD LDS for configuration and data storage. For more information, see Understanding Edge Subscriptions. Return to top

Tarpitting Functionality
Recipient Lookup functionality enables the sending server to determine whether an e-mail address is valid or invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Edge Transport server sends back a "250 2.1.5 Recipient OK" SMTP response to the sending server. This functionality provides an ideal environment for a directory harvest attack. A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization so that the e-mail addresses can be added to a spam database. Because all spam income relies on trying to make people open e-mail messages, addresses known to be active are a commodity that malicious users, or spammers, pay for. Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an automated program that uses common names or dictionary terms to construct e-mail addresses to a specific domain. The program collects all e-mail addresses that return a "250 2.1.5 Recipient OK" SMTP response and discards all e-mail addresses that return a "550 5.1.1 User unknown" SMTP session error. The spammer can then sell the valid e-mail addresses or use them as recipients for unsolicited messages. To combat directory harvest attacks, Exchange 2010 includes tarpitting functionality. Tarpitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for such e-mail traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting makes directory harvest attacks too costly to automate efficiently. If tarpitting isn't configured, Exchange Server immediately returns a "550 5.1.1 User unknown" SMTP session error to the sender when a recipient isn't located in Recipient Lookup. Alternatively, if tarpitting is configured, SMTP waits a specified number of seconds before it returns the "550 5.1.1 User unknown" error. This pause in the SMTP session makes automating a directory harvest attack more difficult and less cost-effective for the spammer. By default, tarpitting is configured for 5 seconds on Receive connectors. To configure the time before SMTP returns the "550 5.1.1 User unknown" error, use the EMC or the Shell to set the TarpitInterval value on the Receive connector. For more information about how to administer and configure Receive connectors, see Understanding Receive Connectors. Return to top

Configuring the Tarpitting Interval


As explained in Understanding Recipient Filtering, you can configure the Receive connectors that process inbound messages from the Internet to slow down the SMTP response. Make sure that you enable tarpitting functionality on the Receive connectors, especially if you have enabled the Recipient Lookup feature of recipient filtering. If you don't enable tarpitting, and you have enabled the Recipient Lookup feature, you are exposing your organization to a directory harvest attack. A directory harvest attack will likely cause more spam. When you specify a tarpitting interval time on a Receive connector, tarpitting is enabled. The default value is 5 seconds. We recommend that you start with a value of 5 (seconds). Use caution if you decide to change this value. An overly long interval could disrupt ordinary mail flow, whereas an overly brief interval may not be as effective in thwarting a directory harvest attack. If you change the tarpitting interval value, do so in small increments. If you are running a version of Exchange Server earlier than Microsoft Exchange Server 2010 Service Pack 2 (SP2), you can set the tarpitting interval on the Security tab of the Receive connector property pages in the EMC, or you can use the Set-ReceiveConnector cmdlet in the Exchange Management Shell. For more information about how to use the EMC to configure the tarpitting interval, see Configure Receive Connector Properties. If you are running Exchange Server 2010 SP2, or a later version, you set the tarpitting interval by using the Set-ReceiveConnector cmdlet in the Exchange Management Shell. Return to top

Multiple Namespaces
Some organizations accept e-mail messages for multiple domains. For example, one organization may accept messages for both the Contoso.com and the Woodgrovebank.com domains. Sometimes organizations are authoritative for all the domains for which they accept messages. In the context of SMTP, the organization is authoritative for a domain if the organization hosts and manages the mailboxes for that domain. This relationship extends to the Edge Transport server. An Edge Transport server may accept messages for multiple domains, but it may not be authoritative for all the domains. For example, an Edge Transport server can be configured to be authoritative for all recipients in the Contoso.com domain, but the Edge Transport server still accepts and forwards messages for the Woodgrovebank.com domain. When you enable the Recipient Filter agent, the Recipient Filter agent performs recipient lookups only for the domains specified as authoritative in the transport server configuration. If an Edge Transport server accepts and forwards messages on behalf of another domain, but the Edge Transport server isn't configured as authoritative, the Recipient Filter agent doesn't perform a recipient lookup. However, if a recipient that's not authoritative is specified in the Recipient Block list, the recipient will still be

blocked. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Safelist Aggregation


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-11-29 In Microsoft Exchange Server 2010, safelist aggregation refers to anti-spam functionality shared across Microsoft Outlook and Exchange. This functionality collects data from the anti-spam Safe Recipients Lists, Safe Senders Lists, Blocked Senders Lists, and contact data that Outlook users configure, and makes this data available to the anti-spam agents on the computer that has the Edge Transport server role installed. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the Edge Transport server. When you enable and correctly configure safelist aggregation, the Content Filter agent passes safe e-mail messages to the enterprise mailbox without additional processing. E-mail messages that Outlook users receive from contacts that those users have added to their Outlook Safe Recipients List or Safe Senders List or have trusted are identified by the Content Filter agent as safe. An Outlook contact is a person, inside or outside the user's organization, about whom the user can save several types of information, such as e-mail and street addresses, telephone and fax numbers, and Web page URLs. In Exchange 2010, the safelist aggregation process also replicates a per-recipient Blocked Senders List to the Edge Transport server. This allows the Sender Filtering agent on the Edge Transport server to block incoming messages from those senders. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the Edge Transport server. A false-positive is a positive test or filter result in a subject or body of data that doesn't possess the attribute for which the filter or test is being conducted. In the context of spam filtering, a false-positive occurs when a spam filter incorrectly identifies a message from a legitimate sender as spam. For organizations that filter hundreds of thousands of messages from the Internet every day, even a small percentage of false-positives means that users might not receive many messages identified incorrectly as spam, which were quarantined or deleted. Safelist aggregation is likely the most effective way to reduce false-positives. In Office Outlook 2007, users can create Safe Senders Lists. Safe Senders Lists specify a list of domain names and e-mail addresses from which the Outlook user wants to receive messages. By default, e-mail addresses in Outlook Contacts and in the Exchange Server global address list are included in this list. By default, Outlook adds all external contacts to which the user sends mail to the Safe Senders List. Contents Information Stored in the Outlook User's Safelist Collection How Exchange Uses the Safelist Collection Hashing of Safelist Collection Entries Enabling Safelist Aggregation

Information Stored in the Outlook User's Safelist Collection


A safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders List, and external contacts. This data is stored in Outlook and in the Exchange mailbox. The following types of information are stored in an Outlook user's safelist collection:

Safe senders and safe recipients The From message header indicates a sender. The To field of the e-mail message indicates a recipient. Safe senders and safe recipients are represented by full SMTP addresses, such as masato@contoso.com. Outlook users can add senders and recipients to their safe lists. Blocked senders Just like safe senders, users can block unwanted senders by adding them to their Blocked Senders Lists. Safe domain The domain is the part of an SMTP address that follows the @ symbol. For example, contoso.com is the domain in the masato@contoso.com address. Outlook users can add sending domains to their safe lists. Important: Exchange provides functionality that allows you to specify whether to include the safe domain data for the anti-spam agents on the Edge Transport server by using the Update-SafeList cmdlet. In most cases, we don't recommend that you include domains because users may include the domains of large Internet service providers (ISP), which could unintentionally provide addresses that may be used or spoofed by spammers. By default, Exchange doesn't include the domains during safelist aggregation. External contacts Two types of external contacts can be included in the safelist aggregation. The first type of external contact includes contacts to whom Outlook users have sent mail. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail settings in Outlook 2007. The second type of external contact includes the users' Outlook contacts. Users can add or import these contacts into Outlook. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail Filter settings in Outlook 2010 or Outlook 2007. Return to top

How Exchange Uses the Safelist Collection


The safelist collection is stored on the user's Mailbox server. A user can have up to 1,024 unique entries in a safelist collection. Exchange 2010 has a mailbox assistant, called the Junk E-mail Options mailbox assistant, which monitors changes to the safelist collection for your mailboxes. It then replicates these changes to Active Directory, where the safelist collection is stored on each user object. When the safelist collection is stored on the user object in Active Directory, the safelist collection is aggregated with the anti-spam functionality of Exchange 2010 and is optimized for minimized storage and replication. The Microsoft Exchange EdgeSync service replicates the safelist collection to the Active Directory Lightweight Directory Services (AD LDS) instance on the Edge Transport server. The Edge Transport servers use the safelist collection data during content filtering. Important:

Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the AD LDS instance on the Edge Transport server, the content filtering functionality doesn't act on safe recipient data. Return to top

Hashing of Safelist Collection Entries


Safelist collection entries are hashed (SHA-256) one way before they are stored as array sets across three user object attributes, msExchSafeSenderHash, msExchSafeRecipientHash, and msExchBlockedSendersHash, as a binary large object. When data is hashed, an output of fixed length is produced, and the output is likely to be unique. For hashing of safelist collection entries, a 4-byte hash is produced. When a message is received from the Internet, Exchange hashes the sender address and compares it to the hashes stored on behalf of the Outlook user to whom the message was sent. If the sender matches the safe senders hash, the message bypasses content filtering. If the sender matches the blocked senders hash, the message is blocked. One-way hashing of safelist collection entries performs the following important functions:

Minimizes storage and replication space Most of the time, hashing reduces the size of the data hashed. Therefore, saving and transmitting a hashed version of a safelist collection entry conserves storage space and replication time. For example, a user who has 200 entries in his or her safelist collection would create about 800 bytes of hashed data stored and replicated in Active Directory. Renders user safelist collections unusable by malicious users Because one-way hash values are impossible to reverse-engineer into the original SMTP address or domain, the safelist collections don't yield usable e-mail addresses for malicious users who might compromise an Edge Transport server. Return to top

Enabling Safelist Aggregation


Safelist aggregation is enabled by default in Exchange 2010. Unlike in Exchange Server 2007, you don't need to manually run the Update-SafeList cmdlet to hash and write the safelist collection data to Active Directory. In Exchange 2010, this is accomplished behind the scenes by the Junk E-mail Options mailbox assistant. You can still manually run safelist aggregation by using the UpdateSafelist cmdlet. The Update-SafeList cmdlet reads the safelist collection from the user's mailbox, hashes each entry, sorts the entries for easy search, and then converts the hash to a binary attribute. Finally, the Update-SafeList cmdlet compares the binary attribute that was created to any value stored on the attribute. If the two values are identical, the Update-SafeList cmdlet doesn't update the user attribute value with the safelist aggregation data. If the two attribute values are different, the Update-SafeList cmdlet updates the safelist aggregation value. To make the safelist aggregation data in Active Directory available to Edge Transport servers in the perimeter network, you must install and configure the Microsoft Exchange EdgeSync service so that the safelist aggregation data is replicated to AD LDS. Return to top

Options available in the msexchangemailboxassistants.exe.config file


To activate the options to include safe domains, or to change the maximum values for the default settings, you must change the msexchangemailboxassistants.exe.config file. Specifically, the following settings and values can be changed in the appsettings section of the msexchangemailboxassistants.exe.config file:

Setting IncludeSafeDomains UpdateInterval TestUpdateInterval MaxSafeSenders MaxSafeRecipients MaxBlockedSenders

Value The value for this setting can be True or False. By default, the value for this setting is 15 minutes. This setting can have a value from 15 minutes through 1 day. TestUpdateInterval is used in test environments. This setting can have a value from 10 seconds through 1 hour. 3*1024 2*1024 By default, the value for this setting is 500. The maximum value is 1000.

For example, the settings in the appsettings section of the msexchangemailboxassistants.exe.config file may be as follows:

<configuration> <runtime> <gcConcurrent enabled="false" /> <generatePublisherEvidence enabled="false" /> </runtime> <appSettings> <add key="IncludeSafeDomains" value="true" /> </appSettings> </configuration>

Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Sender Filtering


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-17 The Sender Filter agent is an anti-spam filter that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed. The Sender Filter agent relies on the MAIL FROM: SMTP header to determine what action, if any, to take on an inbound e-mail message. When you configure anti-spam filters on an Edge Transport server, the filters act on messages cumulatively to reduce the number of unsolicited messages that enter the enterprise. For more information about how to plan and deploy the anti-spam features, see Understanding Anti-Spam and Antivirus Functionality. The Sender Filter agent acts on messages from specific senders outside the organization. Administrators of Edge Transport servers maintain a list of senders who are blocked from sending messages to the organization. As an administrator, you can block single senders (kim@contoso.com), whole domains (*.contoso.com), or domains and all subdomains (*.contoso.com). You can also configure what action the Sender Filter agent should take when a message that has a blocked sender is found. You can configure the following actions:

The Sender Filter agent rejects the SMTP request with a "554 5.1.0 Sender Denied" SMTP session error and closes the connection. The Sender Filter agent accepts the message and updates the message to indicate that the message came from a blocked sender. Because the message came from a blocked sender and it's marked as such, the Content Filter agent will use this information when it calculates the spam confidence level (SCL). You can use the Exchange Management Console (EMC) or the Exchange Management Shell to designate blocked senders and to define how the Sender Filter agent should act on messages from blocked senders. For more information about how to configure the Sender Filter agent, see Configure Sender Filtering Properties. Important: The MAIL FROM: SMTP headers can be spoofed. Therefore, you shouldn't rely on the Sender Filter agent only. Use the Sender Filter agent and the Sender ID agent together. The Sender ID agent uses the originating IP address of the sending server to try to verify that the domain in the MAIL FROM: SMTP header matches the domain that's registered. For more information about the Sender ID agent, see Understanding Sender ID. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Using the Sender Filter Agent to Block Messages


By default, sender filtering is enabled on the computer that has the Edge Transport server role installed for inbound messages that come from the Internet but aren't authenticated. These messages are handled as external messages. You can disable the Sender Filter agent in individual computer configurations by using the EMC or the Shell. For more information, see Enable or Disable Sender Filtering. When you enable the Sender Filter agent on a computer, the Sender Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources. For more information about how to configure Receive connectors and how message source categories are determined, see Understanding Receive Connectors. As a best practice, you shouldn't filter e-mail messages from trusted partners or from inside your organization. When you run anti-spam filters, there's always a chance that the filters will detect false positives. You should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. This will reduce the chance that anti-spam filters will mishandle legitimate messages. You can enable and disable the Sender Filter agent to run on messages from any source by using the Shell. For more information, see Set-SenderFilterConfig. You can configure the Sender Filter agent to block inbound messages that don't specify a sender and domain in the MAIL FROM: SMTP header. You can use this feature to prevent non-delivery report (NDR) attacks on the Exchange server. Most legitimate SMTP messages come from SMTP servers that provide a sender and domain in the MAIL FROM: SMTP command.

Specifying the Block Action


After you've specified blocked senders and domains, you must specify how you want the Sender Filter agent to act on messages from blocked senders and domains. We recommend that you reject the messages. When you use the Sender Filter agent on which all blocked e-mail addresses and domains are specified by the Edge Transport server administrator, the chance of false positives is relatively less than when you use other anti-spam agents. For example, the Content Filter agent is an antispam agent that relies on many different variables to determine whether a message is spam. There are only two scenarios in which legitimate messages may be rejected by the Sender Filter agent:

If you mistype an e-mail address or domain name, the wrong sender may be blocked. If a domain name is reregistered to a legitimate company after you add the domain to your Blocked Senders list, you will unintentionally block legitimate messages. In either of these cases, it may still make sense to reject the messages.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Sender ID
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-27 The Sender ID agent is an anti-spam agent that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed. The Sender ID agent relies on the RECEIVED SMTP header and a query to the sending system's DNS service to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited e-mail messages that enter the organization. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. Sender ID is intended to combat the impersonation of a sender and a domain, a practice that's frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message. Spoofed mails typically contain a From: address that purports to be from a certain organization. In the past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL FROM: header, and in the RFC 822 message data, such as From: "Masato Kawai" masato@contoso.com, because the headers weren't validated. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Using Sender ID to Combat Spoofing Updating Your Organization's Internet-Facing DNS to Support Sender ID Specifying Recipients and Sender Domains to Exclude From Sender ID Filtering

Using Sender ID to Combat Spoofing

In Exchange 2010, Sender ID makes spoofing more difficult. When you enable Sender ID, each message contains a Sender ID status in the metadata of the message. When an e-mail message is received, the Edge Transport server queries the sender's DNS server to verify that the IP address from which the message was received is authorized to send messages for the domain that's specified in the message headers. The IP address of the authorized sending server is referred to as the purported responsible address (PRA). Domain administrators publish sender policy framework (SPF) records on their DNS servers. SPF records identify authorized outbound e-mail servers. If an SPF record is configured on the sender's DNS server, the Edge Transport server parses the SPF record and determines whether the IP address from which the message was received is authorized to send e-mail on behalf of the domain that's specified in the message. For more information about what an SPF record contains and how to create an SPF record, see Sender ID. The Edge Transport server updates the message metadata with the Sender ID status based on the SPF record. After the Edge Transport server updates the message metadata, the Edge Transport server delivers the message as it ordinarily would.

Sender ID Status Values


The Sender ID evaluation process generates a Sender ID status for the message. The Sender ID status is used to evaluate the spam confidence level (SCL) rating for the message. This status can be set to one of the following values:

Pass Both the IP address and Purported Responsible Address (PRA) passed the Sender ID verification check. Neutral Published Sender ID data is explicitly inconclusive. Soft fail The IP address for the PRA may be in the not permitted set. Fail The IP Address is not permitted; no PRA is found in the incoming mail or the sending domain does not exist. None No published SPF data exists in the sender's DNS. TempError A temporary DNS failure occurred, such as an unavailable DNS server. PermError The DNS record is invalid, such as an error in the record format. The Sender ID status is added to the message metadata and is later converted to a MAPI property. The junk e-mail filter in Microsoft Office Outlook uses the MAPI property during the generation of the SCL value. Outlook neither displays the Sender ID status nor necessarily flags a message as junk at certain Sender ID values. Outlook uses the Sender ID status value only during the calculation of the SCL value. Besides the seven scenarios that generate the Sender ID statuses, the Sender ID evaluation process may reveal instances where the From: IP address is missing. If the From: IP address is missing, the Sender ID status can't be set. If the Sender ID status can't be set, Exchange continues to process the message without including a Sender ID status on the message. The message isn't discarded or rejected. In this scenario, Sender ID status isn't set, and an application event is logged. For more information about how the Sender ID status is displayed in messages, see Understanding Anti-Spam Stamps.

Sender ID Options for Handling Spoofed Mail and Unreachable DNS Servers
You can also define how the Edge Transport server handles messages that are identified as spoofed mail and how the Edge Transport server handles messages when a DNS server can't be reached. The options for how the Edge Transport server handles spoofed mail and unreachable DNS servers include the following

actions:

Stamp the status This option is the default action. All inbound messages to your organization have the Sender ID status included in the metadata of the message. Reject This option rejects the message and sends an SMTP error response to the sending server. The SMTP error response is a 5xx level protocol response with text that corresponds to the Sender ID status. Delete This option deletes the message without informing the sending system of the deletion. In fact, the Edge Transport server sends a fake OK SMTP command to the sending server and then deletes the message. Because the sending server assumes the message was sent, it doesn't retry sending the message in the same session. For more information about how to configure the Sender ID agent, see Configure Sender ID Properties. Return to top

Updating Your Organization's Internet-Facing DNS to Support Sender ID


The effectiveness of Sender ID depends on specific DNS data. The more organizations that update their Internet-facing DNS servers by using an SPF record, the more effectively Sender ID identifies spoofed e-mail messages. To support the Sender ID infrastructure, you must update your Internet-facing DNS data by creating an SPF record and hosting the SPF record on your public DNS servers. For more information about how to create and deploy SPF records, see Sender ID. Return to top

Specifying Recipients and Sender Domains to Exclude From Sender ID Filtering


You may want to exclude specific recipients and sender domains from Sender ID filtering. To do this, specify the recipients and sender domains in the Exchange Management Shell. You can't specify the recipients and sender domains in the Exchange Management Console. For more information about how to set recipient and sender domain exclusions for Sender ID, see Set-SenderIdConfig. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Sender Reputation


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 Sender reputation is anti-spam functionality that's enabled on computers that have the Microsoft Exchange Server 2010 Edge Transport server role installed to block messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. For more information about how to plan and deploy the anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Calculation of the Sender Reputation Level Use of the SRL Enabling and Configuring the Detection of Open Proxy Servers Setting the SRL Block Threshold

Calculation of the Sender Reputation Level

A sender reputation level (SRL) is calculated from the following statistics:

HELO/EHLO analysis The HELO and EHLO SMTP commands are intended to provide the domain name, such as Contoso.com, or IP address of the sending SMTP server to the receiving SMTP server. Malicious users, or spammers, frequently forge the HELO/EHLO statement in various ways. For example, they type an IP address that doesn't match the IP address from which the connection originated. Spammers also put domains that are known to be locally supported at the receiving server in the HELO statement in an attempt to appear as if the domains are in the organization. In other cases, spammers change the domain that's passed in the HELO statement. The typical behavior of a legitimate user may be to use a different, but relatively constant, set of domains in their HELO statements. Therefore, analysis of the HELO/EHLO statement on a per-sender basis may indicate that the sender is likely to be a spammer. For example, a sender that provides many different unique HELO/EHLO statements in a specific time period is more likely to be a spammer. Senders who consistently provide an IP address in the HELO statement that doesn't match the originating IP address as determined by the Connection Filter agent are also more likely to be spammers, as are remote senders who consistently provide a local domain name, which is in the same organization as the Edge Transport server, in the HELO statement. Reverse DNS lookup Sender reputation also verifies that the originating IP address from which the sender transmitted the message matches the registered domain name that the sender submits in the HELO or EHLO SMTP command. Sender reputation performs a reverse DNS query by submitting the originating IP address to DNS. The result that's returned by DNS is the domain name that's registered by using the domain naming authority for that IP address. Sender reputation compares the domain name that's returned by DNS to the domain name that the sender submitted in the HELO/EHLO SMTP command. If the domain names don't match, the sender is likely to be a spammer, and the overall SRL rating for the sender is adjusted upward. The Sender ID agent performs a similar task, but the success of the Sender ID agent relies on legitimate senders to update their DNS infrastructure to identify all the e-mail-sending SMTP servers in their organization. By performing a reverse DNS lookup, you can help identify potential spammers. Analysis of SCL ratings on messages from a particular sender When the Content Filter agent processes a message, it assigns a spam confidence level (SCL) rating to the message. The SCL rating is a number from 0 through 9. A higher SCL rating indicates that a message is more likely to be spam. Data about each sender and the SCL ratings that their messages yield is persisted for analysis by sender reputation. Sender reputation calculates statistics about a sender according to the ratio between all messages from that sender that had a low SCL rating in the past and all messages from that sender that had a high SCL rating in the past. Additionally, the number of messages that have a high SCL rating that the sender has sent in the last day is applied to the overall SRL. Sender open proxy test An open proxy is a proxy server that accepts connection requests from anyone anywhere and forwards the traffic as if it originated from the local hosts. Proxy servers relay TCP traffic through firewall hosts to provide user applications transparent access across the firewall. Because proxy protocols are lightweight and independent of user application protocols, proxies can be used by many different services. Proxies can also be used to share a single Internet connection by multiple hosts. Proxies are usually set up so that only trusted hosts inside the firewall can cross through the proxies. Open proxies can exist because of either of the following conditions: Unintentional misconfiguration. Malicious Trojan horse programs. A Trojan horse program is a program that masquerades as another common program in an attempt to receive information. Frequently with insufficient logging, open proxies provide an ideal way for malicious users to hide their true identities and launch denial of service attacks (DoS) or send spam. As more proxy servers are configured to be open by default, open proxies have become more common. Additionally, malicious users can use multiple open proxies together to hide the sender's originating IP address. When sender reputation performs an open proxy test, it does so by formatting an SMTP request in an attempt to connect back to the Edge Transport server from the open proxy. If an SMTP request is received from the proxy, sender reputation verifies that the proxy is an open proxy and updates the open proxy test statistic for that sender. Sender reputation weighs each of these statistics and calculates an SRL for each sender. The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. A value of 0 indicates that the sender isn't likely to be a spammer; a value of 9 indicates that the sender is likely to be a spammer. You can configure a block threshold from 0 through 9 at which sender reputation issues a request to the Sender Filter agent, and, therefore, blocks the sender from sending a message into the organization. When a sender is blocked, the sender is added to the Blocked Senders list for a configurable period. How blocked messages are handled depends on the configuration of the Sender Filter agent. The following actions are the options for handling blocked messages:

Reject

Delete and archive Accept and mark as a blocked sender If a sender is included in the IP Block list or Microsoft IP Reputation Service, sender reputation issues an immediate request to the Sender Filter agent to block the sender. To take advantage of this functionality, you must enable and configure the Microsoft Exchange Anti-spam Update Service. By default, the Edge Transport server sets a rating of 0 for senders that haven't been analyzed. After a sender has sent 20 or more messages, sender reputation calculates an SRL that's based on the statistics listed earlier in this topic. Return to top

Use of the SRL


Sender reputation acts on messages during two phases of the SMTP session:

At the MAIL FROM: SMTP command Sender reputation acts on a message only if the message was blocked or otherwise acted on by the Connection Filter agent, Sender Filter agent, Recipient Filter agent, or Sender ID agent. In this case, sender reputation retrieves the sender's current SRL rating from the sender profile that's persisted about that sender in the Edge Transport server database. After this rating is retrieved and evaluated, the Edge Transport server configuration dictates the behavior that occurs at a particular connection according to the block threshold. After the "end of data" SMTP command The end of data transfer (_EOD) SMTP command is given when all the actual message data is sent. At this point in the SMTP session, many of the anti-spam agents have processed the message. As a by-product of anti-spam processing, the statistics that sender reputation relies on are updated. Therefore, sender reputation has the data to calculate or recalculate an SRL rating for the sender. For more information, see Configure Sender Reputation Properties. Return to top

Enabling and Configuring the Detection of Open Proxy Servers


Sender reputation evaluates several sender characteristics to calculate an SRL. Among the characteristics that sender reputation evaluates are the results of a test for open proxy servers. Frequently, spammers route messages through open proxy servers on the Internet. By routing spam through open proxy servers, spammers can send messages that appear to originate from a different server than their own. When sender reputation calculates an SRL, sender reputation tries to connect to the sender's originating IP address by using a variety of common proxy protocols, such as SOCKS4, SOCKS5, HTTP, Telnet, Cisco, and Wingate. Sender reputation formats a protocol-specific request in an attempt to connect back to the Edge Transport server from the open proxy server by using an SMTP request. If an SMTP request is received from the proxy server, sender reputation verifies that the proxy server is an open proxy server and adjusts the SRL rating according to this result. By default, detection of open proxy servers is enabled on sender reputation. For more information about how to enable detection of open proxy servers, see Configure Sender Reputation Properties. For more information about how to configure detection of open proxy servers, see Configure Outbound Access for Detection of Open Proxy Servers for Sender Reputation. Return to top

Setting the SRL Block Threshold


The SRL is a number from 0 through 9 that predicts the probability that a specific sender is a spammer or otherwise malicious user. You must set a threshold for sender blocking by SRL. This SRL block threshold defines the SRL value that must be exceeded for sender reputation to block a sender. By default, the SRL is set at 7. You should monitor the effectiveness of the agent at the default level. You may find that you can adjust the value to meet the needs of your organization. If you set other anti-spam agents aggressively, you may be able to set a higher SRL threshold for sender reputation than you would if the other anti-spam agents weren't set aggressively. For more information about how to adjust anti-spam configurations so that they work together to reduce spam, see Understanding Anti-Spam and Antivirus Functionality. If the SRL block threshold is exceeded for a particular sender, sender reputation adds the sender to the IP Block list on the Connection Filter agent. Sometimes, spammers send batches of spam from a single sender. In this scenario, if sender reputation calculates an SRL that exceeds the SRL block threshold, the sender is added to the Sender Block List for a configurable duration of time. The default duration is 24 hours. After 24 hours, the sender is removed from the Sender Block List and can send messages again. When a sender is added to the IP Block list, sender reputation deletes the profile for the sender. Sender reputation deletes the profile because the blocked sender's existing profile indicates that the sender's SRL exceeds the SRL block threshold. This would cause the blocked sender to be added to the IP Block list again as soon as the duration for sender blocking ends. For more information, see Configure Sender Reputation Properties. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Spam Confidence Level Threshold


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-09-10 In Microsoft Exchange Server 2010, you can define specific actions according to spam confidence level (SCL) thresholds. For example, you can define different thresholds for rejecting, deleting, or quarantining messages on a server that has the Edge Transport server role installed. The combination of this SCL threshold configuration on the Edge Transport server and the SCL Junk E-mail folder configuration on the user mailbox helps you implement a more comprehensive and precise anti-spam strategy. This more precise and detailed SCL threshold adjustment functionality in Exchange 2010 can help you reduce the overall cost of deploying and maintaining an anti-spam solution across your Exchange organization. The SCL threshold configuration is used by the Content Filter agent, one of the default anti-spam agents included with Exchange 2010. The Content Filter agent uses Microsoft SmartScreen technology to assess the contents of a message and to assign an SCL rating to each message. The Content Filter agent performs this function late in the anti-spam cycle, after other anti-spam agents have processed any inbound messages. Many of the other antispam agents that process inbound messages before they're processed by the Content Filter agent are deterministic in how they act on a message. For example, the Connection Filter agent rejects any message sent from an IP address on a real-time block list. The Sender Filter agent and Recipient Filter agent process messages in a similarly deterministic manner. In Exchange 2010, these deterministic anti-spam agents process messages first and therefore greatly reduce the number of messages that must be processed by the Content Filter agent. For more information about the order in which anti-spam agents process messages, see Understanding Anti-Spam and Antivirus Mail Flow. Because content filtering isn't an exact, deterministic process, the ability to adjust the action that the Content Filter agent performs on different SCL values is important. By carefully adjusting the SCL threshold configuration, you can minimize the following:

Size of the spam quarantine storage Number of legitimate e-mail messages mistakenly quarantined Number of legitimate e-mail messages that reach the Microsoft Outlook user's Junk E-mail folder Number of offensive spam e-mail messages that reach the Outlook user's Inbox or Junk E-mail folder Number of spam e-mail messages that reach the Outlook user's Inbox Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

SCL Threshold Actions in Exchange 2010


In Exchange 2010, by adjusting SCL threshold actions, you can escalate the content filtering action taken on messages that have a greater risk of being spam. To understand this functionality, it's helpful to understand the different SCL threshold actions and how they're implemented:

SCL delete threshold When the SCL value for a specific message is equal to or higher than the SCL delete threshold, the Content Filter agent deletes the message. There's no protocol-level communication that tells the sending system or sender that the message was deleted. If the SCL value for a message is lower than the SCL delete threshold value, the Content Filter agent doesn't delete the message. Instead, the Content Filter agent compares the SCL value to the SCL reject threshold. SCL reject threshold When the SCL value for a specific message is equal to or higher than the SCL reject threshold, the Content Filter agent deletes the message and sends a rejection response to the sending system. You can customize the rejection response. In some cases, a non-delivery report (NDR) is sent to the original sender of the message. If the SCL value for a message is lower than the SCL delete and SCL reject threshold values, the Content Filter agent doesn't delete or reject the message. Instead, the Content Filter agent compares the SCL value to the SCL quarantine threshold. SCL quarantine threshold When the SCL value for a specific message is equal to or higher than the SCL quarantine threshold, the Content Filter agent sends the message to a quarantine mailbox. E-mail administrators must periodically review the quarantine mailbox. If the SCL value for a message is lower than the SCL delete, reject, and quarantine threshold values, the Content Filter agent doesn't delete, reject, or quarantine the message. Instead, the Content Filter agent sends the message to the appropriate Mailbox server, where the per-recipient SCL Junk E-mail folder threshold value of the message is evaluated. SCL Junk E-mail folder threshold If the SCL value for a specific message exceeds the SCL Junk E-mail folder threshold, the Mailbox server puts the message in the Outlook user's Junk E-mail folder. If the SCL value for a message is lower than the SCL delete, reject, quarantine, and Junk E-mail folder threshold values, the Mailbox server puts the message in the user's Inbox. For example, if you set the SCL delete threshold to 8, the SCL reject threshold to 7, the SCL quarantine threshold to 6, and the SCL Junk E-mail folder threshold to 5, all email with an SCL of 5 or lower will be delivered to the user's Inbox. As you plan and deploy your strategy for adjusting the SCL threshold, it's important to understand that the Content Filter agent and the SCL Junk E-mail folder process the SCL threshold value differently. The Content Filter agent takes action on the SCL threshold value that you configure. The SCL Junk E-mail folder takes action on the SCL threshold value that you configure plus 1. For example, if you configure the Delete action to an SCL of 4 on the Content Filter agent, all messages with an SCL of 4 or greater are deleted. However, if you configure the Delete action to an SCL of 4 on the SCL Junk E-mail folder, all messages with an SCL of 5 or greater are deleted. To configure the SCL Junk E-mail folder threshold on individual user mailboxes, you must use the Set-Mailbox cmdlet in the Exchange Management Shell. You can configure the SCL delete, reject, and quarantine thresholds in two locations:

On the content filter configuration (per-transport server SCL configuration) We recommend that you set the organization-wide SCL thresholds on the content filter configuration on the Edge Transport server. If you run anti-spam agents on the Hub Transport server, set the organization-wide SCL thresholds on the Hub Transport server. By applying the same SCL thresholds across all transport servers, you can establish a consistent baseline level of SCL functionality across the organization. Over time, as you analyze the spam functionality and metrics provided by the anti-spam logging and reporting features, you can make additional adjustments to these SCL threshold configurations as needed. On user mailboxes (per-recipient SCL configuration) You can use the Set-Mailbox cmdlet to set per-recipient SCL delete, reject, and quarantine thresholds on individual user mailboxes. As mentioned earlier in this topic, you set the SCL Junk E-mail folder threshold on individual user mailboxes by using the SetMailbox cmdlet. The per-recipient SCL delete, reject, and quarantine thresholds are stored in Active Directory and are replicated to the Edge Transport servers by the Microsoft Exchange EdgeSync service. The per-recipient SCL threshold configurations are used by the Content Filter agent even if you've set per-transport server SCL configurations. Therefore, if you've set per-recipient SCL thresholds, the Content Filter agent uses the per-recipient SCL thresholds for specific users instead of the SCL configuration on the Content Filter agent. Note:

Per-recipient SCL thresholds are not enforced on mail received through distribution groups. These types of messages are rejected at the Transport server before the per-recipient threshold settings are applied. Additionally, if you're using Microsoft Forefront Protection 2010 for Exchange Server, any per-recipient SCL threshold settings replicated to the Edge Transport servers by the Microsoft Exchange EdgeSync service will take precedence over the Forefront anti-spam settings. For more information about how to use the Set-Mailbox cmdlet, see Set-Mailbox.

Best Practice for Setting Up and Adjusting SCL Thresholds


We recommend that you set up and adjust the SCL thresholds as follows:

1. Enable the SCL delete, reject, and quarantine thresholds on the content filter configuration on each Edge Transport server. We recommend that you enable SCL thresholds at an organization level and that you use the default values for these SCL thresholds. The default values were set by the Exchange Server team according to real-world data from the Microsoft IT messaging department and from Exchange 2010 early adopter feedback. The default values are optimized for large, global enterprise deployments. If needed, you can also configure the SCL delete, reject, and quarantine thresholds on a per-recipient configuration to bypass the SCL thresholds configured at the organization level. For more information about how to set the SCL thresholds on the content filter configurations, see Configure Content Filtering Properties. 2. Monitor spam reports and logs closely for the first week after you enable the SCL thresholds. You can use several built-in scripts located in the %ExchangeInstallPath%\Scripts folder, such as get-AntispamSCLHistogram.ps1, for gathering filtering result data. If the data indicates that you must make immediate adjustments, reconfigure the SCL thresholds. Otherwise, collect data and analyze the spam reporting to determine whether adjustments are required.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Spam Quarantine


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Many organizations are bound by legal or regulatory requirements to preserve or deliver all legitimate e-mail messages. In Microsoft Exchange Server 2010, spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages. Spam quarantine provides a temporary storage location for messages identified as spam that shouldn't be delivered to a user mailbox inside the organization. Messages identified by the Content Filter agent as spam are wrapped in a non-delivery report (NDR) and delivered to a spam quarantine mailbox inside the organization. You can manage messages delivered to the spam quarantine mailbox and take appropriate actions. For example, you can delete messages or let messages flagged as false positives in anti-spam filtering be routed to their intended recipients. In addition, you can configure the spam quarantine mailbox to automatically delete messages after a designated time period. For more information about how the anti-spam agents filter inbound messages and the order in which the agents are applied, see Understanding Anti-Spam and Antivirus Functionality. Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features. Contents Spam Confidence Level Spam Quarantine Exchange Hosted Services

Spam Confidence Level

When an external user sends e-mail messages to a server running Exchange that runs the anti-spam features, the anti-spam features cumulatively evaluate characteristics of the messages and act as follows:

Those messages suspected to be spam are filtered out. A rating is assigned to messages based on the probability that a message is spam. This rating is stored with the message as a message property called the spam confidence level (SCL) rating. Spam quarantine uses the SCL rating to determine whether mail has a high probability of being spam. The SCL rating is a numeric value from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered most likely to be spam. You can configure mail that has a certain SCL rating to be deleted, rejected, or quarantined. The rating that triggers any of these actions is referred to as the SCL quarantine threshold. Within content filtering, you can configure the Content Filter agent to base its actions on the SCL quarantine threshold. For example, you can set the following conditions:

SCL delete threshold is set to 8. SCL reject threshold is set to 7. SCL quarantine threshold is set to 6. SCL Junk E-mail folder threshold is set to 5. Based on the preceding SCL thresholds, all e-mail with an SCL of 6 will be delivered to the spam quarantine mailbox. For more information, see Configure Content Filtering Properties. Return to top

Spam Quarantine
When messages are received by the Edge Transport server and all default anti-spam filters are enabled, the anti-spam agents apply their filters. Then the content filter is applied as follows:

If the SCL rating is greater than or equal to the SCL quarantine threshold but less than either the SCL delete threshold or SCL reject threshold, the message goes to the spam quarantine mailbox. If the SCL rating is lower than the spam quarantine threshold, it's delivered to the recipient's Inbox. The message administrator uses Microsoft Office Outlook 2007 to monitor the spam quarantine mailbox for false positives. If a false positive is found, the administrator can send the message to the recipient's mailbox. The message administrator can review the anti-spam stamps if either of the following conditions is true:

Too many false positives are filtered into the spam quarantine mailbox. Not enough spam is being rejected or deleted. For more information, see Understanding Anti-Spam Stamps.

You can then adjust the SCL settings to more accurately filter the spam coming into the organization. For more information, see Understanding Spam Confidence Level Threshold. To use spam quarantine, you must follow these steps:

1. 2. 3. 4. 5. 6.

Enable content filtering. Create a spam quarantine mailbox. Specify the spam quarantine mailbox. Configure the SCL quarantine threshold. Manage the spam quarantine mailbox. Adjust the SCL quarantine threshold as needed.

Enabling Content Filtering


You must enable content filtering before you can apply spam quarantine. By default, the Content Filter agent filters all external messages that come through all Receive connectors on the computer on which the Content Filter feature is enabled. Important: Configuration changes that you make to the Content Filter agent by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If multiple instances of the Edge Transport server role are running in your organization, you must apply sender reputation configuration changes to each computer. For more information, see Enable or Disable Content Filtering.

Creating a Spam Quarantine Mailbox


You must create a spam quarantine mailbox before you can enable the feature. To set up a spam quarantine mailbox, you must follow these steps:

Create a dedicated Exchange database We recommend that you create a dedicated database for the spam quarantine mailbox. The spam quarantine mailbox should have a large database, because if the storage quota limit is reached, messages will be lost. For more information, see Create a Mailbox Database. Create an Active Directory user We recommend that you create a separate Active Directory user for the spam quarantine mailbox. You may apply different recipient policies, such as messaging records management and mailbox size, and delegation rights, according to your organization's compliance policies and needs. Create a user mailbox You must create a mailbox that you can use as the spam quarantine mailbox with an appropriate messaging records management policy that includes mailbox size and the number of days that messages will be saved before they are deleted. For more information, see Messaging Records Management. Note: If a quarantined message is rejected because of a storage quota, the message will be lost. Exchange doesn't generate NDRs for quarantined messages because the quarantined messages are wrapped as NDRs. For more information, see Create a Mailbox. Set up the Outlook account profile You must configure management or delegation of the Outlook account to meet the needs of your organization. In addition, to help with the account management, we recommend that you configure the Outlook profile to expose the original Sender[#0x0069001E], Recipient[#0x0E04001E], and Bcc[#0x0E02001E] fields in the Message view. For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox.

Specifying the Spam Quarantine Mailbox


After you set up the spam quarantine mailbox, you must specify the spam quarantine mailbox in the content filter configuration. You use the Set-ContentFilterConfig cmdlet in the Shell to specify a spam quarantine mailbox. The QuarantineMailbox parameter uses the SMTP address of the spam quarantine mailbox. Important: You must specify the spam quarantine mailbox on all servers that have the Edge Transport server role installed in Active Directory where user mailboxes are located. To specify the spam quarantine mailbox in Active Directory, run the Set-ContentFilterConfig cmdlet on a Hub Transport server. You don't have to have content filtering enabled on the Hub Transport server to specify a spam quarantine mailbox in Active Directory. For more information, see Specify a Spam Quarantine Mailbox.

Configuring the SCL Quarantine Threshold


The SCL quarantine threshold is the value at which a particular message identified as potential spam is delivered to the spam quarantine mailbox. You can set the SCL quarantine threshold to a value from 0 through 9, where 0 is considered less likely to be spam, and 9 is considered most likely to be spam. For more information about how to adjust SCL thresholds to suit your organization's requirements and how to adjust per-recipient SCL thresholds, see Configure Content Filtering Properties.

Managing the Spam Quarantine Mailbox


When you manage your spam quarantine mailbox, follow these guidelines:

Release items that have been sent to the spam quarantine mailbox by using the Send Again feature in Outlook to resend the original message.

For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox. Monitor the spam quarantine mailbox so that the size of the spam quarantine mailbox remains in an acceptable range. The volume of e-mail messages can change because of a larger set of recipients, the natural trend of larger messages, or the threshold on the SCL quarantine action. Monitor the spam quarantine mailbox for false positives. If your spam quarantine mailbox includes many false positives, adjust your SCL quarantine threshold as described in "Adjusting the SCL Quarantine Threshold" later in this topic. For more information about how to determine why false positives are being delivered to the spam quarantine mailbox, see Understanding Anti-Spam Stamps. Use the same Outlook profile to recover quarantined messages from the spam quarantine mailbox. Applying permissions to a different Outlook profile to recover messages isn't supported. You can't use a different Outlook profile to recover or release messages from the spam quarantine mailbox. Important: NDRs identified as spam are deleted, even if their SCL rating indicates that they should be quarantined. NDRs aren't delivered to the spam quarantine mailbox. To track such messages, use the agent log or the message tracking log. For more information, see Get-AgentLog and Search Message Tracking Logs.

Adjusting the SCL Quarantine Threshold


After you configure the SCL quarantine threshold, periodically monitor the settings and adjust them based on your organization's needs. For example, if too many false positives are filtered into the spam quarantine mailbox, raise the SCL quarantine threshold to a larger number. For more information about how to adjust the SCL quarantine threshold, see Understanding Spam Confidence Level Threshold. Return to top

Exchange Hosted Services


Spam filtering and quarantine functionality are enhanced by services available from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Using Edge Transport Rules to Manage Viruses


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 You can use the Edge Rules agent and transport rules in Microsoft Exchange Server 2010 to help protect your organization from viruses. New viruses threaten organizations every day. To minimize the damage caused by viruses, antivirus vendors and administrators must respond to virus threats as soon as possible. Despite a quick response, there will be a gap between the time that a virus threat appears and the time that a solution becomes available. This gap, when a virus threat remains unknown and unresolved, is called a zero-day virus threat. At the same time, viruses that have been circulating on the Internet for many years also continue to pose a significant threat to organizations. Although the majority of these viruses can be identified by antivirus scanners, antivirus scanners may be taken offline by mistake, updated with out-of-date definitions, or experience other problems that make them unavailable. The transport rules that run on computers that have the Edge Transport server role installed are designed to help you manage and control zero-day virus threats and preexisting or ongoing virus threats. For more information about transport rules, see the following topics:

Overview of Transport Rules Understanding How Transport Rules Are Applied Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

Managing Virus Threats


Most viruses contain unique characteristics that identify them as a virus, such as a specific e-mail address in the From message header field, a specific subject, or an attachment. You can configure transport rules to identify potentially harmful messages by these unique characteristics and perform a specific action on them. Available actions include sending the message to a quarantine mailbox, deleting it completely, or adding a warning to the subject.

Identifying Virus Threats


It's important to maximize the number of infected messages that you identify in your perimeter network on Edge Transport servers to reduce the cost of processing the messages after they have entered the Exchange organization. If you can identify an infected message on Edge Transport servers and either reject or delete it, you don't incur the cost of storing the message on your internal servers or the cost of scanning the message for viruses. When you create a transport rule to identify virus threats, you should examine the reports published about the virus and look for unique characteristics that identify the virus and that could be used in a transport rule. The following list describes some unique characteristics that a virus may contain:

Limited number of strings in the subject or message body Specific e-mail address in either the From header field or To header field Specific message header field that has a specific value Important: Although you may be able to identify unique characteristics about a particular virus, you must make sure that these characteristics don't match any content that may exist in legitimate messages. For more information about the types of message content that can be examined by transport rules on an Edge Transport server, see Transport Rule Predicates.

Controlling Virus Threats with Transport Rules


After you have identified the unique characteristics of a virus, you can create a transport rule to perform actions on it. The actions that you perform on specific messages depend on your organization's policies.

Caution: If you decide to drop an SMTP connection, delete a message, or reject a message, you can't retrieve it. If you want to prevent the message from being delivered, but don't want to delete it, configure the rule to deliver the message to a quarantine mailbox. For more information about the actions available on transport rules on an Edge Transport server, see Transport Rule Actions. For more information about how to manage and configure transport rules used to identify and perform actions on messages that may be infected with viruses, see the following topics:

Create a Transport Rule View a Transport Rule Modify a Transport Rule Remove a Transport Rule Configure a Disclaimer The following topics provide additional information that will help you manage and enhance transport rules:

Transport Rule Predicates Transport Rule Actions Regular Expressions in Transport Rules

Using Exchange Hosted Services


Transport messaging policies are enhanced by services available from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Approval Framework


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-18

Approval Framework
Microsoft Exchange uses the approval framework for simple decision-making about e-mail messages. For each workflow, the approval framework uses a special mailbox called the arbitration mailbox, which is used to store the original message and the decision state during the approval process. The following workflow is followed by any application that uses the approval framework:

1. 2. 3. 4. 5. 6.

The user starts a new workflow process using the workflow application. The workflow application sends an initiation message to the arbitration mailbox. Exchange stores the message in the arbitration mailbox and sends approval requests to the specified decision makers. The specified decision makers either approve or reject the approval request. Exchange marks the decision on the original message that is stored in the arbitration mailbox. The workflow application monitors the arbitration mailbox and acts on the decisions that are marked on the original message.

In Exchange Server 2010, the approval framework is used for the following:

Moderated recipients For more information, see Understanding Moderated Transport. Joining and departing distribution groups For more information, see step 7 in Configure Distribution Group Properties.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Back Pressure


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-02-02 Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on Microsoft Exchange Server 2010 Hub Transport and Edge Transport servers. Exchange transport can detect when vital resources, such as available hard disk space and memory, are under pressure, and take action in an attempt to prevent service unavailability. Back pressure prevents the system resources from being completely overwhelmed, and Exchange tries to deliver the existing messages. When utilization of the system resource returns to a normal level, the Exchange server gradually resumes normal operation. In Exchange Server 2007, when a Hub Transport or Edge Transport server is under resource pressure, it rejects incoming connections. In Exchange 2010, incoming connections are accepted, but incoming messages over those connections are either accepted at a slower rate or are rejected. When an SMTP host attempts to make a connection to a Hub Transport or Edge Transport server that's in back pressure, the connection will succeed but when the host issues the MAIL FROM command to submit a message, depending on the resource that's under pressure, Exchange either delays the acknowledgement to the MAIL FROM command or rejects it. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Resources Monitored Actions Taken by Exchange Transport When Under Resource Pressure Back Pressure Configuration Options in the EdgeTransport.exe.config File Back Pressure Logging Information

Resources Monitored

The following system resources are monitored as part of the back pressure feature:

Free space on the hard disk that stores the message queue database. Free space on the hard disk that stores the message queue database transaction logs. The number of uncommitted message queue database transactions that exist in memory. The memory that's used by the EdgeTransport.exe process. The memory that's used by all other processes. For each monitored system resource on a Hub Transport server or Edge Transport server, the following three levels of resource utilization are applied:

Normal The resource isn't overused. The server accepts new connections and messages. Medium The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, depending on the specific resource under pressure, the server uses tarpitting to delay server response or rejects incoming MAIL FROM commands from other sources. High The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new incoming MAIL FROM commands. The following sections explain how Exchange handles the situation when a specific resource is under pressure.

Free Hard Disk Space for the Message Queue Database


By default, the message queue database is stored at C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue. Exchange monitors the hard disk space utilization for this location. The high level of hard disk space utilization is calculated by using the following formula: 100 * (hard disk size - fixed constant) / hard disk size The value of fixed constant is 500 megabytes (MB). The results of this formula are expressed as a percentage of the total hard disk space that's being used. The results of the formula are always rounded down to the nearest integer. By default, the medium level of hard disk utilization is 2 percent less than the high level. By default, the normal level of hard disk utilization is 4 percent less than the high level. For more information about the message queue database, see Understanding Transport Queues.

Free Hard Disk Space for the Message Queue Database Transaction Logs
By default, the message queue database transaction logs are stored at C:\Program Files\Microsoft\ExchangeServer\V14\TransportRoles\data\Queue. Exchange monitors the hard disk space utilization for this location. The EdgeTransport.exe.config file contains a DatabaseCheckPointDepthMax parameter that has a default value of 512 MB. This parameter controls the total allowed size of all uncommitted transaction logs that exist on the hard disk. This parameter is used in the formula that calculates hard disk utilization.

Note: The value of the DatabaseCheckPointDepthMax parameter applies to all transport-related Extensible Storage Engine (ESE) databases that exist on the Hub Transport server or Edge Transport server. This would include the message queue database and the IP filter database. By default, the high level of hard disk utilization is calculated by using the following formula: 100 * (hard disk size - Max(5 GB, 3*DatabaseCheckPointDepthMax)) / hard disk size The results of the formula are always rounded down to the nearest integer. By default, the medium level of hard disk utilization is 2 percent less than the high level. The normal level of hard disk utilization is 4 percent less than the high level. For more information about the message queue database, see Understanding Transport Queues.

Number of Uncommitted Message Queue Database Transactions in Memory


A list of changes that are made to the message queue database is kept in memory until those changes can be committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding message queue database transactions that are kept in memory are known as version buckets. The number of version buckets may increase to unacceptably high levels because of an unexpectedly high volume of incoming messages, spam attacks, problems with the message queue database integrity, or hard disk performance. When Exchange starts receiving messages, these messages are grouped together in batches and then prepared as version buckets. If an incoming message has a large attachment, it can be separated into multiple batches. These batches that are being processed are known as batch points. The number of outstanding batch points can exceed the set thresholds, especially when there's an unexpectedly high volume of incoming messages with large attachments. When version buckets or batch points are under pressure, the Exchange 2010 transport server will start throttling incoming connections by delaying acknowledgement to incoming messages. Exchange will reduce the rate of inbound message flow by tarpitting, which introduces a delay to the MAIL FROM commands. If the resource pressure condition continues, Exchange will gradually increase the tarpitting delay. After the resource utilization returns to normal, Exchange will gradually start reducing the acknowledgement delay and ease into normal operation. By default, Exchange will start delaying message acknowledgements 10 seconds when under resource pressure. If the resources continue to be under pressure, the delay is increased in 5-second increments up to 55 seconds. Exchange 2010 keeps a history of version bucket and batch point resource utilization. If the resource utilization doesn't go down to normal level for a specific number of polling intervals, known as the history depth, Exchange will stop the tarpitting delay and start rejecting incoming messages until the resource utilization goes back to normal. By default, the history depths for version buckets and batch points are in 10 and 300 polling intervals respectively.

Memory Used by the EdgeTransport.exe Process


By default, the high level of memory utilization by the EdgeTransport.exe process is calculated by using the following formula: 75 percent of the total physical memory or 1 terabyte, whichever is less This calculation doesn't include virtual memory that's available on the hard disk in the paging file, or the memory that's used by other processes. The results of this formula are expressed as a percentage of the total memory that's used by the EdgeTransport.exe process. The results of the formula are always rounded down to the nearest integer. By default, the medium level of memory utilization by the EdgeTransport.exe file is calculated as 73 percent of the total physical memory or 2 percent less than the value of the high level, whichever is less. By default, the normal level of memory utilization by the EdgeTransport.exe file is calculated as 71 percent of the total physical memory or 4 percent less than the value of the high level, whichever is less. If the memory utilization of the EdgeTransport.exe process is higher than the specified normal level, garbage collection is forced. Garbage collection is a process that checks for unused objects that exist in memory, and reclaims the memory that's used by those unused objects. Exchange 2010 keeps a history of the memory utilization of the EdgeTransport.exe process. If the utilization doesn't go down to normal level for a specific number of polling intervals, known as the history depth, Exchange will start rejecting incoming messages until the resource utilization goes back to normal. By default, the history depth for EdgeTransport.exe memory utilization is 30 polling intervals.

Memory Used by All Processes


By default, the high level of memory utilization by all processes is 94 percent of total physical memory. This value doesn't include virtual memory that's available on the hard disk in the paging file. When the specified memory utilization level is reached, message dehydration occurs. Message dehydration is the act of removing unnecessary elements of queued messages that are cached in memory. Complete messages are cached in memory for enhanced performance. Removal of the MIME content of queued messages from memory reduces the memory that's used at the expense of higher latency because the messages are read directly from the message queue database. By default, message dehydration is enabled. Return to top

Actions Taken by Exchange Transport When Under Resource Pressure


The following table summarizes the actions taken by Exchange transport when a specific resource is under pressure.

Back pressure actions taken by Hub Transport and Edge Transport servers when responding to resource pressure
Resource under pressure Utilization level Actions taken

Hard disk space for message queue database

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database transaction logs

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Hard disk space for message queue database transaction logs

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Version buckets

Medium

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire version bucket history depth, take the following actions: Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Version buckets

High

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire version bucket history depth, take the following actions: Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Batch point

Medium

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire batch point history depth, take the following actions: Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Batch point

High

Introduce or increment the tarpitting delay to incoming messages. If normal level isn't reached for the entire batch point history depth, take the following actions: Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Memory used by EdgeTransport.exe process

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Force garbage collection

Memory used by EdgeTransport.exe process

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories

Memory used by all processes

Medium

Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Force garbage collection

Memory used by all processes

High

Reject incoming messages from other Exchange servers Reject message submissions from the store driver on Mailbox servers (Hub Transport server only) Reject incoming messages from non-Exchange servers Reject message submissions from Pickup and Replay directories Flush enhanced Domain Name System (DNS) cache from memory Start message dehydration

Return to top

Back Pressure Configuration Options in the EdgeTransport.exe.config File


All configuration options for back pressure are available in the EdgeTransport.exe.config application configuration file. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.

Caution: These settings are listed as a reference only. We strongly discourage any modifications to the back pressure settings in the EdgeTransport.exe.config file. Modifications to the back pressure settings may result in poor performance or data loss. We recommend that you investigate and correct the root cause of any back pressure events that you may encounter.

Back pressure configuration options


Parameter name EnableResourceMonitoring ResourceMonitoringInterval PercentageDatabaseDiskSpaceUsedHighThreshold PercentageDatabaseDiskSpaceUsedMediumThreshold Default value TRUE 00:00:02 0. This value indicates that the default formula will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseDiskSpaceUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseDiskSpaceUsedMediumThreshold. 0. This value indicates that the default formula will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseLoggingDiskSpaceUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentageDatabaseLoggingDiskSpaceUsedMediumThreshold. 0. This value indicates that the default calculation will be used. 0. This value indicates that the actual value is 2 percent less than the value of PercentagePrivateBytesUsedHighThreshold. 0. This value indicates that the actual value is 2 percent less than the value of PercentagePrivateBytesUsedMediumThreshold. 200 120 80 10 4000 2000 1000 300 TRUE 40 00:00:00.100 00:05:00 00:00:00 00:00:55 00:00:05 00:00:10 94

PercentageDatabaseDiskSpaceUsedNormalThreshold

PercentageDatabaseLoggingDiskSpaceUsedHighThreshold PercentageDatabaseLoggingDiskSpaceUsedMediumThreshold

PercentageDatabaseLoggingDiskSpaceUsedNormalThreshold

PercentagePrivateBytesUsedHighThreshold PercentagePrivateBytesUsedMediumThreshold

PercentagePrivateBytesUsedNormalThreshold

VersionBucketsHighThreshold VersionBucketsMediumThreshold VersionBucketsNormalThreshold VersionBucketsHistoryDepth BatchPointHighThreshold BatchPointMediumThreshold BatchPointNormalThreshold BatchPointHistoryDepth BatchPointUseCostForPressure BatchPointBatchSize BatchPointBatchTimeout BatchPointItemExpiryInterval SMTPBaseThrottlingDelayInterval SMTPMaxThrottlingDelayInterval SMTPStepThrottlingDelayInterval SMTPStartThrottlingDelayInterval PercentagePhysicalMemoryUsedLimit

DehydrateMessagesUnderMemoryPressure PrivateBytesHistoryDepth Return to top

TRUE 30

Back Pressure Logging Information


The following list describes the event log entries that are generated by specific back pressure events in Exchange 2010:

Event log entry for an increase in any resource utilization level Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15004 Description: Resource pressure increased from Previous Utilization Level to Current Utilization Level. Event log entry for a decrease in any resource utilization level Event Type: Information Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15005 Description: Resource pressure decreased from Previous Utilization Level to Current Utilization Level. Event log entry for critically low available disk space Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15006 Description: The Microsoft Exchange Transport service is rejecting messages because available disk space is below the configured threshold. Administrative action may be required to free disk space for the service to continue operations. Event log entry for critically low available memory Event Type: Error Event Source: MSExchangeTransport Event Category: Resource Manager Event ID: 15007 Description: The Microsoft Exchange Transport service is rejecting message submissions because the service continues to consume more memory than the configured threshold. This may require that this service be restarted to continue normal operation. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Content Conversion


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-07 Content conversion is the process of correctly formatting a message for each recipient. The decision to perform content conversion on a message depends on the destination and format of the message being processed. Messages sent to recipients inside the Microsoft Exchange Server organization don't require any content conversion. Only messages sent to external recipients may require content conversion. In an Exchange Server 2010 organization, content conversion is handled 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. In addition to recipient resolution and routing resolution, content conversion is performed on the message before the message is put in a delivery queue. If a single message contains multiple recipients, content conversion determines the appropriate encoding for each message recipient. On an Edge Transport server, an abbreviated categorization occurs, which doesn't involve content conversion. Contents Understanding the Structure of E-mail Messages Exchange 2010 and Outlook Message Formats Elements of Content Conversion Content Conversion Performed by the Store Driver Looking for management tasks related to content conversion? See Managing Transport Servers.

Understanding the Structure of E-mail Messages


To better understand content conversion, you must understand the structure of e-mail messages. An SMTP message is based on plain 7-bit US-ASCII text to compose and send e-mail messages. A standard SMTP message consists of the following elements:

Message envelope The message envelope is defined in RFC 2821. The message envelope contains information required to transmit and deliver the message. Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message contents. Message contents The message contents are defined in RFC 2822. The message contents consist of the following elements: Message header The message header is a collection of header fields. Header fields consist of a field name, followed by a colon (:) character, followed by a field body, and ended by a carriage return/line feed (CR/LF) character combination. A field name must be composed of printable US-ASCII text characters except the colon (:) character. Specifically, ASCII characters that have values from 33 through 57 and 59 through 126 are permitted. A field body may be composed of any US-ASCII characters, except for the carriage return (CR) character and the line feed (LF) character. However, a field body may contain the CR/LF character combination when used in header folding. Header folding is the separation of a single header field body into multiple lines as described in section 2.2.3 of RFC 2822. Other field body syntax requirements are described in sections 3 and 4 of RFC 2822. Message body The message body is a collection of lines of US-ASCII text characters that appears after the message header. The message header and the message body are separated by a blank line that ends with the CR/LF character combination. The message body is optional. Any line of text in the message body must be less than 998 characters. The CR and LF characters can only appear together to indicate the end of a line. When SMTP messages contain elements that aren't plain US-ASCII text, the message must be encoded to preserve those elements. The MIME standard defines a method of encoding content in messages that isn't text. MIME allows for text in other character sets, attachments without text, multipart message bodies, and header fields in other character sets. MIME is defined in RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2077. MIME defines a collection of header fields that specifies additional message attributes. The following table describes some important MIME header fields.

Important MIME header fields


Header field name MIMEVersion Default value Description

1.0

This header field is the first MIME header field that appears in a MIME-formatted message. This header field appears after the other standard RFC 2822 header fields, but before any other MIME header fields. MIME-aware e-mail clients use this header field to identify a MIME-encoded message. When this header field is absent, MIME-aware e-mail clients identify the message as plain text. This header field identifies the media type of the message content as described in RFC 2046. A media type consists of a type, a subtype, and one or more optional parameters, such as a charset= parameter that defines the MIME character encoding. Types that begin with "x" aren't standard. Subtypes that begin with "vnd." are vendor-specific. The Internet Assigned Numbers Authority (IANA) maintains a list of registered media types. For more information, see MIME Media Types. The multipart media type allows for multiple message parts in the same message by using sections defined by different media types. Some Content-Type field values include text/plain, text/html, multipart/mixed, and multipart/alternative. This header field can describe the following information about a message: The encoding algorithm used to transform any non-US-ASCII text or binary data that exists in the message body. An indicator that describes the current condition of the message body. There can be multiple values of the Content-Transfer-Encoding header field in a MIME message. When the Content-Transfer-Encoding header field appears in the message header, it applies to the whole body of the message. When the Content-Transfer-Encoding header field appears in one of the parts of a multipart message, it applies only to that part of the message. When an encoding algorithm is applied to the message body data, the message body data is transformed into plain US-ASCII text. This transformation allows the message to travel through older SMTP messaging servers that only support messages in US-ASCII text. The values of the Content-Transfer-Encoding header field that indicate an encoding algorithm was used on the message body are as follows:

ContentType

text/plain

ContentTransferEncoding

7bit

Quoted-printable This encoding algorithm uses printable US-ASCII characters to encode the message body data. If the original message text is mostly US-ASCII text, Quoted-printable encoding gives somewhat readable and compact results. All printable USASCII text characters except the equal sign (=) character can be represented without encoding. Base64 This encoding algorithm is based primarily on the privacy-enhanced mail (PEM) standard defined in RFC 1421. Base64 encoding uses the 64-character alphabet encoding algorithm and output padding characters defined by PEM to encode the message body data. A Base64 encoded message is typically 33 percent larger than the original message. Base64 encoding creates a predictable increase in message size and is optimal for binary data and non-US-ASCII text. Typically, you won't see multiple encoding algorithms used in the same message. When no encoding algorithm has been used on the message body, the Content-Transfer-Encoding header field merely identifies the current condition of the message body data. The following values of the Content-Transfer-Encoding header field indicate that no encoding algorithms were used on the message body: 7bit This value indicates that the message body data is already in the RFC 2822 format. Specifically, this means that the following conditions must be true: All lines of text must be less than 998 characters long. All characters must be US-ASCII text that have character values from 1 through 127. The CR and LF characters can only be used together to indicate the end of a line of text. The whole message body may be 7bit, or part of the message body in a multipart message may be 7bit. If the multipart message contains other parts that have any binary data or non-US-ASCII text, that part of the message must be encoded using the Quotedprintable or Base64 encoding algorithms. Messages that have 7bit bodies can travel between SMTP messaging servers by using the standard DATA command. 8bit This value indicates that the message body data contains non-US-ASCII characters. Specifically, this means that the following conditions must be true: All lines of text must be less than 998 characters long. One or more characters in the message body have values larger than 127. The CR and LF characters can only be used together to indicate the end of a line of text. The whole message body may be 8bit, or part of the message body in a multipart message may be 8bit. If the multipart message contains other parts that have binary data, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms. Messages that have 8bit bodies can only travel between SMTP messaging servers that support the 8BITMIME SMTP extension as defined in RFC 1652, such as servers running Exchange 2010, Exchange Server 2007, Exchange Server 2003, or Exchange 2000 Server. Specifically, this means that the following conditions must be true: The 8BITMIME keyword must be advertised in the server's EHLO response. Messages are still transferred by using the SMTP standard DATA command. However, the BODY=8BITMIME parameter must be added to the end of the MAIL FROM command. Binary This value indicates that the message body contains non-US-ASCII text or binary data. Specifically, this means that the following conditions are true: Any sequence of characters is allowed. There is no line length limitation. Binary message elements don't require encoding. Messages that have Binary bodies can only travel between SMTP messaging servers that support the BINARYMIME SMTP extension as defined in RFC 3030, such as servers running Exchange 2010, Exchange 2007, Exchange 2003, or Exchange 2000. Specifically, this means that the following conditions must be true: The BINARYMIME keyword must be advertised in the server's EHLO response. The BINARYMIME SMTP extension can only be used with the CHUNKING SMTP extension. Chunking enables large message bodies to be sent in multiple, smaller chunks. Chunking is also defined in RFC 3030. The CHUNKING keyword must also be advertised in the server's EHLO response. Messages are transferred using the BDAT command instead of the standard DATA command. The BODY=BINARYMIME parameter must be added to the end of the MAIL FROM command when the message has a message body. The values 7bit, 8bit, and Binary never exist together in the same multipart message. The values are mutually exclusive. The Quotedprintable or Base64 values may appear in a 7bit or 8bit multipart message body, but never in a Binary message body. If a multipart message body contains different parts composed of 7bit and 8bit content, the whole message is classified as 8bit. If a multipart message body contains different parts composed of 7bit, 8bit, and Binary content, the whole message is classified as Binary. ContentDisposition Attachment This header field instructs a MIME-enabled e-mail client on how it should display an attached file, and is described in RFC 2183. The values of this field may be Inline or Attachment. When the value of this field is Inline, the attachment is displayed in the message body. When the value of this field is Attachment, the attached file appears as a regular attachment separate from the message body. Other parameters are available when the value is Attachment, such as Filename, Creation-date, and Size.

Exchange 2010 and Outlook Message Formats


The following list describes the basic message formats available in Exchange 2010 and Microsoft Outlook:

Plain text A plain text message uses only US-ASCII text as described in RFC 2822. The message can't contain different fonts or other text formatting. The following two formats can be used for a plain text message: The message headers and the message body are composed of US-ASCII text. Attachments must be encoded by using Uuencode. Uuencode represents Unix-to-Unix encoding and defines an encoding algorithm to store binary attachments in the body of an e-mail message by using US-ASCII text characters. The message is MIME-encoded with a Content-Type value of text/plain, and a Content-Transfer-Encoding value of 7bit for the text parts of a multipart message. Any message attachments are encoded by using Quoted-printable or Base64 encoding. By default, when you compose and send a plain text message in Outlook, the message is MIME-encoded with a Content-Type value of text/plain. HTML An HTML message supports text formatting, background images, tables, bullet points, and other graphical elements. By definition, an HTML-formatted message must be MIME-encoded to preserve these formatting elements. Rich text format (RTF) RTF supports text formatting and other graphical elements. RTF is synonymous with the Transport Neutral Encapsulation Format (TNEF). TNEF and RTF can be used interchangeably. Only Outlook and a few other MAPI e-mail clients understand RTF messages. MAPI is a Microsoft-developed messaging architecture that enables multiple applications to interact with different messaging systems across a variety of hardware platforms. MAPI is built on the Component Object Model (COM) architecture. Outlook uses MAPI to communicate with mailboxes on a computer running Exchange 2010 that has the Mailbox server role installed. The rich text message format is completely different from the rich text document format available in Microsoft Word. TNEF TNEF is a Microsoft-specific format for encapsulating MAPI message properties. A TNEF message contains a plain text version of the message and an attachment that packages the original formatted version of the message. Typically, this attachment is named Winmail.dat. The Winmail.dat attachment includes the following information: Original formatted version of the message, including, for example, fonts, text sizes, and text colors

OLE objects, including, for example, embedded pictures or embedded Microsoft Office documents Special Outlook features, including, for example, custom forms, voting buttons, or meeting requests Regular message attachments that were in the original message The resulting plain text message can be represented in the following formats: RFC 2822-compliant message composed of only US-ASCII text with a Winmail.dat attachment encoded in Uuencode Multipart MIME-encoded message that has a Winmail.dat attachment A MAPI-compliant e-mail client that fully understands TNEF, such as Outlook, processes the Winmail.dat attachment and displays the original message content without ever displaying the Winmail.dat attachment. An e-mail client that doesn't understand TNEF may present a TNEF message in any of the following ways: The plain text version of the message is displayed, and the message contains an attachment named Winmail.dat, Win.dat, or some other generic name such as Attnnnnn.dat or Attnnnnn.eml where the nnnnn placeholder represents a random number. The plain text version of the message is displayed. The TNEF attachment is ignored or removed. The result is a plain text message. Messaging servers that understand TNEF can be configured to remove TNEF attachments from incoming messages. The result is a plain text message. Moreover, some e-mail clients such as Microsoft Outlook Express may not understand TNEF, but recognize and ignore TNEF attachments. The result is a plain text message. There are third-party utilities that can help convert Winmail.dat attachments. TNEF is understood by Exchange 2010, Exchange 2007, Exchange 2003, Exchange 2000, and Exchange Server version 5.5. TNEF messages are transferred between SMTP messaging servers by using the standard DATA command verb. TNEF is automatically used by Exchange based on the following situations: Exchange 2003 If the Exchange organization is in mixed mode, TNEF is used for messages transferred between Exchange servers in different routing groups. Exchange 2000 TNEF is used for messages transferred between Exchange servers in different routing groups. Summary Transport Neutral Encapsulation Format (STNEF) STNEF is equivalent to TNEF. However, STNEF messages are encoded differently than TNEF messages. Specifically, STNEF messages are always MIME-encoded and always have a Content-Transfer-Encoding value of Binary. Therefore, there's no plain text representation of the message, and there's no distinct Winmail.dat attachment contained in the body of the message. The whole message is represented by using only binary data. Messages that have a Content-Transfer-Encoding value of Binary can only be transferred between SMTP messaging servers that support and advertise the BINARYMIME and CHUNKING SMTP extensions as defined in RFC 3030. The messages are always transferred between SMTP messaging by using the BDAT command, instead of the standard DATA command. STNEF is understood by Exchange 2010, Exchange 2007, Exchange 2003, and Exchange 2000. STNEF is automatically used by Exchange if the following conditions are true: Exchange 2010 STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2007 STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2003 If the Exchange organization is in native mode, STNEF is used for all messages transferred between Exchange servers in the organization. Exchange 2000 STNEF is used for messages transferred between Exchange servers in the same routing group. An unsupported hotfix also enables Exchange 2000 to use STNEF for messages transferred between Exchange servers in different routing groups. Exchange never sends STNEF messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

Elements of Content Conversion


Content conversion is the act of correctly formatting a message for each external recipient. This conversion is performed by the categorizer on a Hub Transport server. The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether TNEF should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options specify message encoding options, such as MIME and non-MIME character sets, message encoding, and attachment formats. These conversion and encoding options are independent of one another. For example, whether TNEF messages can leave the Exchange organization isn't related to the MIME encoding settings or plain text encoding settings of those messages. You can specify the content conversion at various levels of the Exchange organization as described in the following list:

Remote domain settings Remote domains define the settings for outgoing message transfers between the Exchange 2010 organization and domains outside the Active Directory forest. Even if you don't create remote domain entries for specific domains, there's a predefined remote domain named Default that applies to all remote address spaces (*). Mail user and mail contact settings Mail users resemble mail contactsboth have external e-mail addresses and contain information about people outside the Exchange organization. The main difference is mail users have security contexts that can be used to log on to the Active Directory domain and access resources to which they have been granted permission. Outlook settings In Outlook, you can set the message formatting and encoding options described in the following list: Message format You can set the default message format for all messages. You can override the default message format as you compose a specific message. Internet message format You can control whether TNEF messages are sent to remote recipients or whether they are first converted to a more compatible format. You can also specify various message encoding options for messages sent to remote recipients. These settings don't apply to messages sent to recipients in the Exchange organization. Internet recipient message format You can control whether TNEF messages are sent to specific recipients or whether they are first converted to a more compatible format. You can set the conversion options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. These conversion options aren't available for recipients in the Exchange organization. Internet recipient message encoding options You can control the MIME or plain text encoding options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. These conversion options aren't available for recipients in the Exchange organization. International options You can control the character sets used in messages.

TNEF Conversion Options


You can specify the TNEF conversion options at the following levels:

Remote domain settings Mail user and mail contact settings Outlook settings, including: Message format Internet message format Internet recipient message format For detailed information, see TNEF Conversion Options.

Message Encoding Options


You can specify the message options at the following levels:

Remote domain settings Mail user and mail contact settings Outlook settings, including: Message format Internet message Internet recipient message format Message character set encoding options For detailed information, see Message Encoding Options.

Content Conversion Performed by the Store Driver


The store driver also performs content conversion. The store driver exists on Hub Transport servers to transport messages between mailboxes on Mailbox servers and the Submission queue. Specifically, the store driver transports messages from the sender's Outbox to the Submission queue on the Hub Transport server, and the store driver transports the messages from the Submission queue on the Hub Transport server to the recipient's Inbox. The store driver converts all outgoing messages from MAPI and converts all incoming messages to MAPI. Content conversion tracing captures these store driver conversion failures. For more information, see Content Conversion Tracing.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

TNEF Conversion Options


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether Transport Neutral Encapsulation Format (TNEF) should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options, such as MIME and non-MIME character sets, specify message encoding and attachment formats. This topic describes the TNEF conversion options that you can specify at the following levels:

Remote domain settings Mail user and mail contact settings Microsoft Outlook settings Message format Internet message format Internet recipient message format

TNEF Conversion Options for Messages Sent to Remote Domains


When you configure TNEF conversion options for a remote domain, those TNEF conversion options are applied to all messages sent to that domain. For remote domains in your organization, you have the following configuration options for TNEF conversion:

TNEF use enabled TNEF is used for all messages sent to the remote domain. TNEF use disabled TNEF is never used for any messages sent to the remote domain. Unspecified TNEF messages aren't specifically allowed or prevented for recipients in the remote domain. Whether TNEF messages are sent to recipients in the remote domain depends on the specific setting on the mail contact or mail user, or the setting specified by the sender in Outlook. This is the default setting. In Microsoft Exchange 2010, you can set the TNEF conversion options for messages sent to a remote domain in the Exchange Management Shell or on the Remote Domains tab in the Exchange Management Console (EMC). For more information about configuring TNEF options for a remote domain, see the following topics:

Configure Remote Domain Properties Set-RemoteDomain

TNEF Conversion Options for Messages Sent to Mail Users and Mail Contacts
When you configure TNEF conversion options for a mail contact or a mail user, those TNEF conversion options are applied to all messages sent to that specific recipient. For mail contacts and mail users in your organization, you have the following configuration options for TNEF conversion:

Always TNEF is used for all messages sent to the recipient. Never TNEF is never used for any messages sent to the recipient. Use default settings TNEF messages aren't specifically allowed or prevented for the mail user or mail contact. Whether TNEF messages are sent to the recipient depends on the specific setting for the corresponding remote domain or the setting specified by the sender in Outlook. This is the default setting. Note: In both the EMC and the Shell, the TNEF conversion settings are referred to as MAPI rich text format. You can set the TNEF conversion options for messages sent to mail users and mail contacts in the Shell or in the Recipient Configuration node in the EMC. For more information about configuring TNEF options for these recipient types, see the following topics:

Configure Mail Contact Properties Configure Mail User Properties Set-MailContact Set-MailUser

TNEF Conversion Options for Messages Available in Outlook


Senders can control the default TNEF message conversion options for TNEF messages sent to all recipients outside the Exchange organization. These options are called Internet message format options. The options only apply to remote recipients, and not to recipients in the Exchange organization. Note: The following options define how messages containing Outlook rich text are handled when sent to external recipients. If the message format you're using is HTML or plain text, these settings dont apply. You have the following TNEF conversion options in Outlook:

Convert to HTML format This is the default option. Any TNEF messages sent to remote recipients are converted to HTML. Any formatting in the message should closely resemble the original message. MIME-encoded HTML messages are supported by many, but not all, e-mail clients.

Convert to Plain Text format Any TNEF messages sent to remote recipients are converted to plain text. Any formatting in the message is lost. Send using Outlook Rich Text Format Any TNEF messages sent to remote recipients remain TNEF messages. These options can be configured in Outlook by navigating to Tools > Options > Mail Format, and then clicking Internet Format. Senders can also control the default TNEF message conversion options for TNEF messages sent to specific recipients outside the Exchange organization. These options are called Internet recipient message format options. The options only apply to remote recipients stored in your Contacts folder, and not to recipients in the Exchange organization. You have the following TNEF conversion options for remote recipients in your Contacts folder:

Let Outlook decide the best sending format This is the default setting. This setting forces Outlook to use the TNEF conversion option that's specified by the default Internet format. The possible values are Convert to HTML format, Convert to Plain Text format, or Send using Outlook Rich Text Format. Therefore, the TNEF message may be left as TNEF, converted to HTML, or converted to plain text. If you want to make sure that the TNEF message remains TNEF for this recipient, you should change this setting from Let Outlook decide the best sending format to Send using Outlook Rich Text format. Send Plain Text only Any TNEF messages sent to the recipient are converted to plain text. Any formatting in the message is lost. Send using Outlook Rich Text format Any TNEF messages sent to remote recipients remain TNEF messages. These options can be configured for a contact in Outlook by opening that contact and then double-clicking the E-mail field and selecting Internet format.

Order of Precedence for TNEF Conversion Options


Exchange 2010 uses the order of precedence as described in the following list to determine the TNEF conversion options for outgoing messages sent to recipients outside the Exchange organization:

1. Outlook settings 2. Mail user or mail contact settings 3. Remote domain settings The list specifies the order of precedence from lowest to highest. A setting made at a higher level overrides a setting made at a lower level. Exchange never sends Summary Transport Neutral Encoding Format (STNEF) messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Message Encoding Options


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The content conversion options that you can set in an Exchange organization can be described in the following categories:

TNEF conversion options These conversion options specify whether Transport Neutral Encapsulation Format (TNEF) should be preserved or removed from messages that leave the Exchange organization. Message encoding options These options specify message encoding options, such as MIME and non-MIME character sets, message encoding, and attachment formats. This topic describes message encoding options that you can specify at the following levels:

Remote domain settings Mail user and mail contact settings Microsoft Outlook settings Message format Internet message format Internet recipient message format Message character set encoding options

Message Encoding Options for Messages Sent to Remote Domains


When you configure message encoding options for a remote domain, the specific settings are applied for all messages sent to that domain. For remote domains in your organization, you have the following configuration options for message encoding:

Content type You can specify the content type for MIME messages sent to the recipients in the remote domain. You can use of the following settings: MimeHtmlText All messages are converted to MIME messages that use HTML formatting, unless the original message is a text message. If the original message is a text message, the outgoing message will be a MIME message that uses text formatting. This is the default setting. MimeText All messages are converted to MIME messages that use text formatting. MimeHtml All messages are converted to MIME messages that use HTML formatting. Note: You can only configure this setting using the Exchange Management Shell. Line wrap size You can specify the maximum number of characters that can exist on a single line of text in the body of the e-mail message. Older e-mail client applications may prefer 78 characters per line. MIME character set The character set that you specify will only be used for MIME messages that don't have their own character set specified. Setting this parameter won't overwrite character sets that are already specified in the outgoing mail. For a list of valid character set names, see Supported Character Sets for Remote Domain Configuration. Non-MIME character set This parameter is used if either of the following conditions are true: Incoming messages from a remote domain are missing the value of the charset= parameter in the MIME Content-Type: header field. Outgoing messages to a remote domain are missing the value of the MIME character set. For a list of valid character set names, see Supported Character Sets for Remote Domain Configuration. In Microsoft Exchange Server 2010, you can set the message encoding options for recipients in remote domains in the Shell or on the Remote Domains tab in the Exchange Management Console (EMC). For more information, see the following topics:

Configure Remote Domain Properties Set-RemoteDomain

Message Encoding Options for Mail Users and Mail Contacts


When you configure message encoding options for a mail contact or a mail user, that option is applied to all messages sent to that specific recipient. For mail contacts and mail users in your organization, you have the following configuration options for message encoding:

UsePreferMessageFormat This parameter specifies whether the message format settings configured for the mail contact override the global settings configured for the remote domain. If you disable this setting, Exchange ignores other message encoding options for this recipient and the message encoding is determined by the configuration of the remote domain or the settings configured by the message sender. MessageFormat This parameter specifies the message format. You can either specify Text or Mime as the message format. The value of this setting is dependent on the MessageBodyFormat parameter. If the message body format is Html or TextAndHtml, you must set this parameter to Mime. MessageBodyFormat This parameter specifies the message body format. You can specify Text, Html, or TextAndHtml. The value of this setting is dependent on the MessageFormat parameter. If the message format is Text, you must also set this parameter to Text. MacAttachmentFormat This parameter specifies the Apple Macintosh operating system attachment format for messages. You can specify BinHex, UuEncode, AppleSingle, or AppleDouble. The value of this setting is dependent on the MessageFormat parameter. If the message format is set to Text, you must set this parameter to either BinHex or UuEncode. If the message format is set to Mime, you must set this parameter to BinHex, AppleSingle or AppleDouble. You must use the Shell to set the message encoding options for mail users and mail contacts. For more information, see the following topics:

Enable-MailContact New-MailContact Set-MailContact Enable-MailUser New-MailUser

Set-MailUser

Message Encoding Options Available in Outlook


As a sender, you can specify message encoding options in Outlook at any of the following stages:

By configuring the default message format to be either plain text or HTML. By setting the message format as you're composing it to either plain text or HTML using the Format area in the Options tab. By configuring the message encoding options for messages that are sent to all recipients outside the Exchange organization. These options are called Internet message format options. The options only apply to remote recipients, and not to recipients in the Exchange organization. These options can be configured in Outlook by navigating to the Tools > Options > Mail Format, and clicking Internet Format. By configuring the message encoding options for messages that are sent to specific recipients outside the Exchange organization. These options are called Internet recipient message format options. The options only apply to remote recipients in your Contacts folder, and not to recipients in the Exchange organization. These options can be configured for a contact in Outlook by opening that contact and then double-clicking the E-mail field and selecting Send Options. By default, Outlook uses automatic character set message encoding by scanning the whole text of the outgoing message to determine the appropriate encoding to use for the message. This setting applies to messages that you send to Internet recipients and recipients in the Exchange organization. However, you can bypass this and specify a preferred encoding for outgoing messages. These options can be configured in Outlook by navigating to Tools > Options > Mail Format, and clicking International Options.

Order of Precedence for Message Encoding Options


Exchange 2010 uses the order of precedence as described in the following list to determine the message encoding options for outgoing messages sent to recipients outside the Exchange organization:

1. Remote domain settings 2. Outlook settings 3. Mail user or mail contact settings The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a setting made at a lower level. The following table describes the order of precedence from lowest priority to highest priority for message character set encoding options.

Order of precedence from lowest priority to highest priority for message character set encoding options
Source Set-RemoteDomain Set-RemoteDomain Outlook setting Parameter CharacterSet NonMimeCharacterSet Message character set encoding Values Specified Specified

Auto-select Specified

The value of the NonMimeCharacterSet parameter from the Set-RemoteDomain cmdlet is used to assign a character set to the following types of messages:

Outgoing messages to a configured remote domain that don't contain a specified character set Incoming messages from a configured remote domain that don't contain a specified character set The value of the Windows ANSI code page for the Hub Transport server is used to assign a character set to the following types of messages:

Internal messages that don't contain a specified character set Internal messages that contain a specified character set, but don't contain a specified server code page If a message contains a specified but invalid character set, the Hub Transport server tries to replace the invalid character set with a valid character set. The following table describes the order of precedence from lowest priority to highest priority for plain text message encoding options.

Order of precedence from lowest priority to highest priority for plain text message encoding options
Source SetRemoteDomain Parameter LineWrapSize Values

From 0 through 132 unlimited

Outlook settings Outlook settings

Message format Internet message format

Plain text Plain text options: Encode attachments in UuEncode format when you send a plain text message Automatically wrap text at nn characters

Outlook settings

Internet recipient message format

Plain text format: Encode attachments in UuEncode attachment format

Use BinHex Mac attachment format

Set-MailUser SetMailContact

UsePreferMessageFormat $true $false If the value is $false or if the recipient isn't defined as a mail user or mail contact in the Exchange organization, the mail user or mail contact settings are ignored.

Set-MailUser SetMailContact Set-MailUser SetMailContact Set-MailUser SetMailContact

MessageFormat

Text

MessageBodyFormat

Text

MacAttachmentFormat

BinHex UuEncode

The following table describes the order of precedence from lowest priority to highest priority for MIME message encoding options.

Order of precedence from lowest priority to highest priority for MIME message encoding options
Source SetRemoteDomain Parameter ContentType MimeHtmlText MimeText MimeHtml Values

Outlook settings

Message format

Plain text HTML

Outlook settings

Internet recipient message format

MIME message format Plain text Include both plain text and HTML HTML

Set-MailUser SetMailContact

UsePreferMessageFormat

$true $false If the value is $false or if the recipient isn't defined as a mail user or mail contact in the Exchange organization, the mail user or mail contact settings are ignored.

Set-MailUser SetMailContact

MessageFormat

Text Mime

Set-MailUser SetMailContact

MessageBodyFormat Text Html TextAndHtml

Set-MailUser SetMailContact

MacAttachmentFormat

BinHex AppleSingle AppleDouble

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Content Conversion Tracing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-06 Content conversion tracing captures failures in the content conversion that's performed by the store driver on inbound and outbound messages on a computer running Microsoft Exchange Server 2010 that has the Hub Transport server role installed. The categorizer on a Hub Transport server is responsible for the content conversion of all messages sent to external recipients. However, the store driver on a Hub Transport server is responsible for the content conversion of messages sent to and from mailbox recipients. Specifically, the store driver must convert outbound messages from mailbox users from MAPI to MIME. The store driver must also convert inbound messages for mailbox users from MIME to MAPI. Content conversion tracing is responsible for capturing these MAPI conversion failures. Content conversion tracing doesn't capture any content conversion failures that the categorizer encounters as it converts messages sent to external recipients. Contents Configuring Content Conversion Tracing How Content Conversion Tracing Works Considerations for Content Conversion Tracing

Configuring Content Conversion Tracing

Content conversion tracing is controlled by the following parameters in the Set-TransportServer cmdlet in the Exchange Management Shell:

ContentConversionTracingEnabled This parameter enables or disables content conversion. Valid values for this parameter are $True and $False. The default value is $False. If the Exchange organization contains multiple Hub Transport servers, you must enable content conversion tracing on each Hub Transport server responsible for delivery of messages to Mailbox servers. PipelineTracingPath Although this parameter is associated with pipeline tracing, it also specifies the root location of the content conversion tracing files. By default, the value of the PipelineTracingPath parameter is C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. The path must be local to the Exchange 2010 computer. Content conversion creates a folder named ContentConversionTracing inside the path specified by the PipelineTracingPath parameter. Inside the ContentConversionTracing folder, content conversion creates two subfolders: InboundFailures and OutboundFailures. The InboundFailures folder contains the information from inbound message content conversion failures. The OutboundFailures folder contains the information from outbound message content conversion failures. The maximum size for all the files in the InboundFailures folder is 128 megabytes (MB). The maximum size for all the files in the OutboundFailures folder is 128 MB. The content conversion tracing directories don't use circular logging to remove old files, depending on the age or size of the files. As soon as the maximum size for a folder is reached, content conversion tracing stops writing information to the folder. If you want to make sure that the maximum folder size limits aren't exceeded, you can create a scheduled task that periodically moves the content conversion tracing files to a different location. The permissions required on the folders and subfolders used in content conversion tracing are as follows:

Administrators: Full Control Network Service: Full Control System: Full Control

Caution: Content conversion tracing copies the complete contents of e-mail messages. To avoid unwanted exposure of confidential information, you must set appropriate security permissions on the location of the content conversion tracing files. Return to top

How Content Conversion Tracing Works


When the content conversion of an inbound message fails, a delivery status notification (DSN) that has the status code 5.6.0 is sent to the message sender. If content conversion tracing is enabled, the failure information is recorded at the time that the 5.6.0 DSN message is generated. Each content conversion error generates two separate files. A content conversion error that occurs when an inbound message is converted from MIME to MAPI generates the following two files in the InboundFailures folder:

<GUID>.eml This file contains the failed message in text format. <GUID>.txt This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver. A content conversion error that occurs when an outbound message is converted from MAPI to MIME generates the following two files in the OutboundFailures folder:

<GUID>.msg This file contains the failed message in the Microsoft Outlook message format.

<GUID>.txt This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver. The placeholder <GUID> is the same in both file names. Each content conversion error generates a different GUID that's used in the file names of the corresponding message and text files. An example of a GUID that's used in the file names is 038b930e-61fd-4bfd-b9b4-0374c18b73f7. Return to top

Considerations for Content Conversion Tracing


You can leave content conversion tracing enabled for proactive monitoring. Or, you can enable content conversion tracing to troubleshoot a specific failure event. You can usually reproduce inbound content conversion failures by asking the recipient of the 5.6.0 DSN message to resend the original message. Inbound content conversion failures are the most common. Some of the reasons for inbound content conversion errors include the following:

Violations of message size limits These message size limits are imposed by the store driver to help prevent denial of service attacks (DoS). These message limits are listed in the <GUID>.txt file. These message limits include the following: MaxMimeTextHeaderLength This limit specifies the maximum number of text characters that can be used in a MIME header. The value is 2000. MaxMimeSubjectLength This limit specifies the maximum number of text characters that can be used in the subject line. The value is 255. MSize This limit specifies the maximum message size. The value is 2147483647 bytes. MaxMimeRecipients This limit specifies the total number of recipients allowed in the To, Cc, and Bcc fields. The value is 12288. MaxRecipientPropertyLength This limit specifies the maximum number of text characters that can be used in a recipient description. The value is 1000. MaxBodyPartsTotal This limit specifies the maximum number of message parts that can be used in a MIME multipart message. The value is 250. MaxEmbeddedMessageDepth This limit specifies the maximum number of forwarded messages that can exist in a message. The value is 30. For more information about configurable message size limits used in Hub Transport servers or Edge Transport servers, see Understanding Message Size Limits. Failure to convert an inbound iCalendar message to a meeting request RFC 2445 defines iCalendar as a standard for calendar data exchange. Specific causes of the conversion failure include the following: Incorrect use of iCalendar by the sending agent. Constructs of iCalendar that can't be supported by the Outlook or Exchange calendar schema. Conversion failures of iCalendar don't result in the sender receiving a 5.6.0 DSN message. Instead, the message is delivered with an attached .ics file that contains the iCalendar message body. Failures caused by badly formatted MIME messages Unsolicited commercial e-mail or spam messages may have formatting errors in the message header, such as unmatched quotation marks in recipient descriptions. A much smaller number of failures caused by badly formatted MIME messages are considered bugs. Outbound content conversion failures are much less common than inbound failures. When outbound failures occur, they are usually caused by Exchange code bugs or corrupted message content. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Delivery Agents


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-17 Delivery agents are responsible for delivering messages addressed to foreign systems that don't use the SMTP protocol. Each delivery agent works with a Delivery Agent connector. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery agents are a significant improvement over Foreign connectors in handling non-SMTP messages in your Exchange organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Delivery Agents Adding Delivery Agents to Your Organization Events Used by Delivery Agents

Delivery Agents

A delivery agent is a custom agent that can:

Establish a connection to the foreign system for message delivery. Retrieve messages from the remote delivery queues on Hub Transport servers. Deliver messages to the foreign system. Provide acknowledgement for each successful message delivery. While the Foreign connector architecture remains in Microsoft Exchange Server 2010, we recommend using delivery agents for routing messages to non-SMTP systems whenever possible. Delivery agents provide the following benefits:

They allow queue management of messages routed to foreign systems using the familiar queue management tools. Because the messages no longer need to be written to and read from the file system, message delivery performance is improved. They provide access to message properties with rich events for agent developers. Development time for a delivery agent is faster than implementing a Foreign connector because the delivery agent can use the message representation and management features of Exchange. You can now be sure that the messages are delivered to the foreign system as opposed to just being written to the Drop directory. The usage of Delivery Agent connectors allows service level agreement (SLA) analysis because it's now possible to track the latency of message delivery to the foreign system. Return to top

Adding Delivery Agents to Your Organization


To use a delivery agent in your organization, you have to complete the following:

Acquire the delivery agent. Typically, delivery agents are written by third parties. Exchange 2010 comes with only one Delivery Agent connector by default: the Text Messaging Delivery Agent connector. Install the delivery agent on your Hub Transport servers that will act as source servers for the Delivery Agent connectors. Create a Delivery Agent connector for the specific protocol. When all of these steps are completed, messages to the foreign systems will be routed through the Delivery Agent connectors and processed by the delivery agent.

Delivery Agent Connectors


Don't confuse the Delivery Agent connectors with the actual delivery agents. Delivery Agent connectors are configured to make routing decisions. The Delivery Agent connectors handle queuing messages to be processed by the delivery agents; much like Send connectors or Routing Group connectors are used for SMTP delivery. Delivery Agent connectors ensure that the messages destined to the foreign system are inserted into the appropriate queues on the Hub Transport servers that are used for delivering messages to the foreign systems. After the messages are queued, Connection Manager invokes the delivery agent to handle the actual delivery of the message to the foreign system. Return to top

Events Used by Delivery Agents


Delivery agents act on the following events raised by the Connection Manager component:

OnOpenConnection This event is raised when there are messages in the queue to be delivered to the foreign system. It notifies the delivery agent to initiate a connection to the foreign system. OnDeliverMailItem This event notifies the delivery agent to retrieve the next item from the queue. OnCloseConnection This event is raised when there are no more messages in the queue to be delivered to the foreign system. It notifies the delivery agent to close the connection to the foreign system. In a typical delivery scenario, the following interaction between Connection Manager and the delivery agent takes place:

1. Connection Manager detects messages queued for delivery to the foreign system. 2. Connection Manager invokes the delivery agent using the OnOpenConnection event. 3. The delivery agent establishes a connection with the foreign system. After the connection is established, it notifies Connection Manager using the RegisterConnection method. 4. Connection Manager raises the OnDeliverMailItem event. 5. The delivery agent retrieves the message from the queue and delivers it to the foreign system. After delivery is complete, it provides acknowledgement to Connection Manager. 6. If there are additional messages in the queue, steps 4 and 5 are repeated until all messages are delivered. 7. Connection Manager raises the OnCloseConnection event. 8. The delivery agent closes the connection with the foreign system and notifies Connection Manager using the UnRegisterConnection method.

Retry Situations
The following are the situations where messages or the entire Delivery Agent connector queue would end up in the Retry state:

After Connection Manager raises the OnOpenConnection event, if no delivery agents respond with the RegisterConnection method, the entire queue for that Delivery Agent connector is put into retry. If the delivery agent doesn't provide an acknowledgement for a specific message, that message is put into retry. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding DSNs and NDRs


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-05-20 This topic describes how to read and interpret non-delivery report (NDR) delivery status notification (DSN) messages in Microsoft Exchange Server 2010.

NDR Sections
In Exchange 2010, NDRs have been designed to make them easier to read and understand by both end-users and administrators. Information that is displayed in an NDR is separated into the following two areas:

A user information section A Diagnostic information for administrators section The information in each section is targeted to the readers of that section. The user information section appears first and contains feedback to help the user understand in nontechnical terms why the delivery of the message failed. The Diagnostic information for administrators section provides deeper technical information such as the original message headers, to help e-mail administrators troubleshoot a delivery issue that may exist. The following figure shows the user information section and Diagnostic information for administrators section of an NDR.

User Information Section


The user information section of an NDR generated by Exchange 2010 contains information that you want to communicate to an end-user who has sent a message that is later returned with an NDR. The text that is displayed in this section is inserted by the Exchange server that generated the NDR. The text in the user information section is designed to help the end-user determine why the message was rejected and how to resend the message successfully if the message should be resent. When applicable, the fully qualified domain name (FQDN) of the server that rejected the message is included in the user information section. If delivery fails to more than one recipient, the e-mail address of each recipient is listed and the reason for the failure is included in the space below the recipient's e-mail address. You can modify the text in the user information section by using the New-SystemMessage cmdlet. By creating a custom message, you can provide specific information to end-users, such as a telephone number to use to contact the helpdesk department or a hyperlink to use to obtain self-service support. For more information about how to customize the text that is displayed in the user information section, Create a Custom DSN Message.

Diagnostic Information for Administrators


The Diagnostic information for administrators section contains more detailed information about the specific error that occurred during delivery of the message, the server that generated the NDR, and the server that rejected the message. The following fields are present in most NDRs and are visible in the "NDR sections"

figure earlier in this topic:

Generating server The generating server is the SMTP server that created the NDR. The generating server takes the enhanced status code that is explained later in this topic. This code creates an easy-to-read NDR. If no remote server is listed below the e-mail address of the sender in the Diagnostic information for administrators section, the generating server is also the server that rejected the original e-mail message. If message delivery fails when the message is sent to another recipient in the Exchange organization, the same server typically rejects the original message and generates the NDR. Rejected recipient The rejected recipient is the e-mail address of the recipient to which delivery of the original message failed. If delivery to more than one recipient has failed, the e-mail address for each recipient is listed. The rejected recipient field also contains the following sub-fields for each e-mail address listed: Remote server The remote server field contains the FQDN of the server that rejects delivery of the message during the Simple Mail Transfer Protocol (SMTP) conversation. The remote server field is only populated when delivery has been attempted to a remote server, and that delivery attempt has been rejected before the receiving server successfully acknowledges the message after the message body is sent. If the original message is successfully acknowledged by the receiving server and is then rejected because of content restrictions, for example, the remote server field is not populated. Enhanced status code The enhanced status code is the code returned by the server that rejected the original message. The enhanced status code indicates why the original message was rejected. The enhanced status code is not rewritten by Exchange 2007 but is used to determine what text to display in the user information section. The enhanced status codes you're most likely to encounter are listed in "Common Enhanced Status Codes" later in this topic. For a detailed list of enhanced status codes, see RFC 3463. SMTP response The SMTP response is the machine readable text returned by the server that rejected the original message. The SMTP response typically contains a short string that provides an explanation of the enhanced status code that is also returned. The SMTP response is not rewritten by Exchange 2010. Additionally, this response is always presented in US-ASCII format. Original message headers The original message headers section contains the message headers of the rejected message. These headers can provide useful diagnostic information, such as information that can help you determine the path that the message took before it was rejected or whether the To field matches the e-mail address that is specified in the rejected recipient field.

Examples of NDR Messages


The following sections provide examples of two ways that NDR messages can be generated:

By the same server By different servers

NDR Generated and Original Message Rejected by the Same Server


The following example shows what happens when a remote e-mail organization accepts delivery of an e-mail message through an Edge Transport server, and then rejects that message because of a policy restriction on the recipient's mailbox. In this case, the sender is not allowed to send messages to the recipient. Edge Transport servers do not perform message size validation so the Edge Transport server in this example accepts the message because it has a valid recipient address and the message does not violate another content restrictions. Because the remote e-mail organization accepts the whole message, including the message contents, the remote e-mail organization is responsible for rejecting the message and for generating the NDR message to be sent to the sender.

Also, messages that are rejected when they are sent to recipients that are part of the same Exchange 2010 organization are typically rejected by the same e-mail server that generates the NDR message. Messages sent to local recipients can be rejected for various reasons, such as mailboxes that have exceeded their quota, lack of authorization to send messages to the recipient address, or hardware failures that result in an extended loss of connectivity to other servers in the organization. In both situations, no remote server is included under the e-mail address of the recipients listed in the NDR message.

NDR Generated and Original Message Rejected by Different Servers

The following example shows what happens when a remote e-mail organization rejects delivery of an e-mail message before it ever accepts the message. In this example, the remote server rejects the message and returns an enhanced status code to the local sending server because the specified recipient does not exist. The rejection happens before the receiving server ever acknowledges the message. Because the receiving server doesn't successfully acknowledge the message, the receiving server is not responsible for the message. Therefore, the local sending server generates the NDR message and sends it to the sender of the original message.

Common Enhanced Status Codes


The following table contains a list of the enhanced status codes that are returned in NDRs for the most common message delivery failures.

Enhanced status code 4.3.1

Description

Possible cause

Additional information

Insufficient system resources

An out-of-memory error occurred. A resource problem, such as a full disk, can cause this problem. Instead of getting a disk full error, you might be getting an out-of- memory error. This NDR is generated when a queue has been frozen.

Ensure that your Exchange server has enough disk storage.

4.3.2

System not accepting network messages

You can resolve this condition by unfreezing the queue.

4.4.1

Connection timed out

The destination server is not responding. Transient network conditions can cause this error. The Exchange server tries automatically to connect to the server again and deliver the mail. If delivery fails after multiple attempts, an NDR with a permanent failure code is generated. A connection dropped between the servers. Transient network conditions or a server that is experiencing problems can cause this error. The sending server will retry delivery of the message for a specific time period, and then generate further status reports.

Monitor the situation. This may be a transient problem that may correct itself.

4.4.2

Connection dropped

Monitor the situation as the server retries delivery. This may be a transient problem that may correct itself. This situation can also occur when the message size limit for the connection is reached, or if the message submission rate for the client IP address has exceeded the configured limit.

4.4.7

Message expired

The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This message can also indicate that a message header limit has been reached on a remote server, or some other protocol time-out occurred while communicating with the remote server. This situation is a permanent failure. Possible causes include: There is no route for the given address space; for example, an SMTP connector is configured, but this address does not match. DNS returned an authoritative host that was not found for the domain. An SMTP error occurred.

This message usually indicates an issue on the receiving server. Check the validity of the recipient address, and determine if the receiving server is configured correctly to receive messages. You may have to reduce the number of recipients in the message header for the host about which you are receiving this error. If you send the message again, it is placed in the queue again. If the receiving server is available, the message is delivered.

5.0.0

HELO / EHLO requires domain address

Some potential resolutions include: On one or more SMTP connectors, add an asterisk (*) value as the SMTP address space. Verify that DNS is working.

5.1.0

Sender denied

This NDR is caused by a general failure (bad address failure). An e-mail address or another attribute could not be found in Active Directory. Contact entries without the targetAddress attribute set can cause this problem. Another possible cause could be that the homeMDB attribute of a user could not be determined. The homeMDB attribute corresponds to the Exchange server on which the user's mailbox resides. Another common cause of this NDR is if you used Microsoft Office Outlook to save your email message as a file, and then someone opened the message offline and replied to the message. The message property only preserves the legacyExchangeDN attribute when Outlook delivers the message, and therefore the lookup could fail. This failure may be caused by the following conditions: The recipient e-mail address was entered incorrectly by the sender. No recipient exists in the destination email system. The recipient mailbox has been moved and the Microsoft Office Outlook recipient cache on the sender's computer has not updated. An invalid legacy domain name (DN) exists for the recipient mailbox Active Directory.

Either the recipient address is incorrectly formatted, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again.

5.1.1

Bad destination mailbox address

This error typically occurs when the sender of the message incorrectly enters the e-mail address of the recipient. The sender should check the recipient's e-mail address and send again. This error can also occur if the recipient e-mail address was correct in the past but has changed or has been removed from the destination e-mail system. If the sender of the message is in the same Exchange organization as the recipient, and the recipient mailbox still exists, determine whether the recipient mailbox has been relocated to a new e-mail server. If this is the case, Outlook may not have updated the recipient cache correctly. Instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure. Other issues may cause this error, such as an invalid legacy distinguished name (DN) in Active Directory. Examine and correct the legacy DN of the recipient's mailbox. Then instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure. Verify that the recipient's address was entered correctly. If the recipient's address is in a non-SMTP e-mail system that you specifically want to provide mail delivery to, you will need to add the appropriate type of connector to your topology and configure it to provide service to the recipient's e-mail system.

5.1.2

Invalid X.400 address

The recipient has a non-SMTP address that can't be matched to a destination. The address does not appear to be local, and there are no connectors configured with address spaces that contain the recipient's address. This message indicates that the recipient address appears incorrectly on the message.

5.1.3

Invalid recipient address

Either the recipient address is formatted incorrectly, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again. Also, examine the SMTP recipient policy and ensure that each mail domain for which you want to accept mail appears correctly. This error typically occurs because of a misconfiguration in Active Directory. Possibly because of replication problems, two recipient objects in Active Directory have the same SMTP address or Exchange Server (EX) address.

5.1.4

Destination mailbox address ambiguous

Two or more recipients in the Exchange organization have the same address.

5.1.7

Invalid address

The sender has a malformed or missing SMTP address, the mail attribute in the directory service. The mail item cannot be delivered without a valid mail attribute. The mailbox cannot be accessed. The mailbox

Check the sender directory structure, and determine if the mail attribute exists.

5.2.1

Mailbox

Check to see if the recipient database is online, the recipient mailbox is disabled,

cannot be accessed 5.2.2 Mailbox full

may be offline, disabled, or the message has been quarantined by a rule.

or the message has been quarantined.

The recipient's mailbox has exceeded its storage quota and is no longer able to accept new messages.

This error occurs when the recipient's mailbox has exceeded its storage quota. The recipient must reduce the size of the mailbox or the administrator must increase the storage quota before delivery can be successful. If the recipient resides in the local Exchange 2010 organization, see Configure Storage Quotas for a Mailbox. Send the message again without attachments, or set the server or the client-side limit to allow a larger message size limit.

5.2.3

Message too large

The message is too large, and the local quota is exceeded. For example, a remote Exchange user might have a restriction on the maximum size of an incoming message. The recipient is a misconfigured dynamic distribution list. Either the filter string or the base DN of the dynamic distribution list is invalid. When the Exchange remote server reaches capacity of its disk storage to hold mail, it could respond with this NDR. This error usually occurs when the sending server is sending mail with an ESMTP BDAT command. This error also indicates a possible SMTP protocol error. The message exceeds a size limit configured on a transport or mailbox database and can't be accepted. This failure can be generated by either the sending e-mail system or the recipient e-mail system.

5.2.4

Mailing list expansion problem

Set the categorizer event logging level to at least the minimum level, and send another message to the dynamic distribution list. Check the application event log for a 6025 event or a 6026 event detailing which attribute is misconfigured on the dynamic distribution list object. Ensure that the remote server has enough storage capacity to hold mail. Check the SMTP log.

5.3.3

Unrecognized command

5.3.4

Message too big for system

This error occurs when the size of the message that was sent by the sender exceeds the maximum allowed message size when passing through a transport component or mailbox database. The sender must reduce the size of the message for the message to be successfully delivered. For more information about how to configure message size limits in an Exchange 2010 organization, see Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder. Check the configuration of the server's connectors for loops, and ensure that each connector is defined by a unique incoming port. If there are multiple virtual servers, ensure that none are set to "All Unassigned."

5.3.5

System incorrectly configured

A mail-looping situation was detected, which means that the server is configured to loop mail back to itself.

5.4.4

Invalid arguments

This NDR occurs if no route exists for message delivery, or if the categorizer could not determine the next-hop destination. A configuration error has caused an e-mail loop. By default, after 20 iterations of an e-mail loop, Exchange interrupts the loop and generates an NDR to the sender of the message.

Check that the domain name specified is valid, and that a mail exchanger (MX) record exists.

5.4.6

Routing loop detected

This error occurs when the delivery of a message generates another message in response. That message then generates a third message, and the process is repeated, creating a loop. To help protect against exhausting system resources, Exchange interrupts the mail loop after 20 iterations. Mail loops are typically created because of a configuration error on the sending mail server, the receiving mail server, or both. Check the mailbox rules configuration of the recipient and sender to determine whether automatic message forwarding is enabled. View the SMTP Log or a Netmon trace, and ensure that there is adequate disk storage and virtual memory available.

5.5.2

Send hello first

A generic SMTP error occurs when SMTP commands are sent out of sequence. For example, a server attempts to send an AUTH (authorization) command before identifying itself with an EHLO command. It is possible that this error can also occur when the system disk is full. The combined total of recipients on the To, Cc, and Bcc lines of the message exceeds the total number of recipients allowed in a single message.

5.5.3

Too many recipients

This error occurs when the sender has included too many recipients on the message. The sender must reduce the number of recipient addresses in the message or the maximum number of recipients must be increased to allow the message to be successfully delivered. To configure the maximum number of recipients that can be included in a message, use the RecipientLimits parameter on the Set-Mailbox cmdlet. For more information, see Set-Mailbox. Check the recipient address for nonstandard characters.

5.5.4

Invalid domain name

The message contains either an invalid sender or an incorrect recipient address format. One possible cause is that the recipient address format might contain characters that are not conforming to Internet standards. This message indicates a possible protocol error.

5.5.6

Invalid message content

Check Event Log for possible failures.

5.7.1

Delivery not authorized

The sender of the message is not allowed to send messages to the recipient.

This error occurs when the sender tries to send a message to a recipient but the sender is not authorized to do this. This frequently occurs when a sender tries to send messages to a distribution group that has been configured to accept messages only from members of that distribution group or other authorized

senders. The sender must request permission to send messages to the recipient. On an Exchange 2010 server, the following cmdlets accept the AcceptMessageOnlyFrom and AcceptMessagesOnlyFromDLMembers parameters. These enable you to determine who is authorized to send messages to the recipients that you configure: Set-Mailbox Set-MailUser Set-MailContact Set-DistributionGroup Set-DynamicDistributionGroup This error can also occur if an Exchange 2010 transport rule rejects a message because the message matched conditions that are configured on the transport rule. For more information about transport rules, see Understanding Transport Rules. 5.7.1 Unable to relay The sending e-mail system is not allowed to send a message to an e-mail system where that e-mail system is not the final destination of the message. This error occurs when the sending e-mail system tries to send an anonymous message to a receiving e-mail system, and the receiving e-mail system does not accept messages for the domain or domains specified in one or more of the recipients. The following are the most common reasons for this error: A third party tries to use a receiving e-mail system to send spam, and the receiving e-mail system rejects the attempt. By the nature of spam, the sender's e-mail address may have been forged and the resulting NDR could have been sent to the unsuspecting sender's e-mail address. It is difficult to avoid this situation. A domain name service (DNS) mail exchanger (MX) record for a domain points to a receiving e-mail system where that domain is not accepted. The administrator responsible for the specific domain name must correct the DNS MX record or configure the receiving e-mail system to accept messages sent to that domain, or both. For more information about how to accept messages for a domain, see Managing Accepted and Remote Domains. A sending e-mail system or client that should use the receiving e-mail system to relay messages does not have the correct permissions to do this. For more information about transport permissions, see Understanding Permissions.

5.7.1

Client was not authenticated

The sending e-mail system did not authenticate with the receiving e-mail system. The receiving e-mail system requires authentication before message submission.

This error occurs when the receiving server must be authenticated before message submission, and the sending e-mail system has not authenticated with the receiving e-mail system. The sending e-mail system administrator must configure the sending e-mail system to authenticate with the receiving e-mail system for delivery to be successful. This error can also occur if you try to accept anonymous messages from the Internet by using a Hub Transport server that has not been configured to do this. We recommend that you put an Edge Transport server in a perimeter network between the Hub Transport server and the Internet. For more information, see the following topics: Configure Internet Mail Flow Directly Through a Hub Transport Server Configure Internet Mail Flow Through a Subscribed Edge Transport Server

5.7.3

Not Authorized

The sender prohibited reassignment to the alternate recipient.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Supported Locales for Use with System Messages


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-03-22 The following table lists the supported language locales available for use together with the New-SystemMessage and Set-SystemMessage cmdlets.

Language code af am-ET ar as-IN bg bn-BD bn-IN bs-Cyrl-BA bs-Latn-BA ca cs cy-GB da de el en es et eu fa fi fil-PH fr ga-IE gl gu ha-Latn-NG he hi hr hu

Language Afrikaans Amharic (Ethiopia) Arabic Assamese (India) Bulgarian Bengali (Bangladesh) Bengali (India) Bosnian (Cyrillic, Bosnia, and Herzegovina) Bosnian (Latin, Bosnia, and Herzegovina) Catalan Czech Welsh (Great Britain) Danish German Greek English Spanish Estonian Basque Persian Finnish Filipino (Philippines) French Irish (Ireland) Galician Gujarati Hausa (Latin, Nigeria) Hebrew Hindi Croatian Hungarian

hy id ig-NG is it iu-Latn-CA ja ka kk km-KH kn ko kok ky lb-LU lo-LA lt lv mi-NZ mk ml-IN mr ms ms-BN mt-MT ne-NP nl nn-NO no nso-ZA or-IN pa pl ps-AF pt pt-PT qut-GT quz-PE

Armenian Indonesian Igbo (Nigeria) Icelandic Italian Inuktitut (Latin, Canada) Japanese Georgian Kazakh Khmer (Cambodia) Kannada Korean Konkani Kyrgyz Luxembourgish (Luxembourg) Lao (Lao People's Democratic Republic) Lithuanian Latvian Maori (New Zealand) Macedonian Malayalam (India) Marathi Malay Malay (Brunei Darussalam) Maltese (Malta) Nepali (Nepal) Dutch Norwegian (Nynorsk) Norwegian Sesotho sa Leboa (South Africa) Oriya (India) Punjabi Polish Pashto (Afghanistan) Portuguese Portuguese (Portugal) K'iche (Guatemala) Quechua (Peru)

ro ru rw-RW si-LK sk sl sq sr sr-Cyrl-CS sv sw ta te th tn-ZA tr tt uk ur uz vi wo-SN xh-ZA yo-NG zh-Hans zh-Hant zh-HK zu-ZA

Romanian Russian Kinyarwanda (Rwanda) Sinhala (Sri Lanka) Slovak Slovenian Albanian Serbian Serbian (Cyrillic, Serbia) Swedish Kiswahili Tamil Telugu Thai Setswana (South Africa) Turkish Tatar Ukrainian Urdu Uzbek Vietnamese Wolof (Senegal) isiXhosa (South Africa) Yoruba (Nigeria) Chinese (Simplified) Chinese (Traditional) Chinese (Hong Kong) isiZulu (South Africa)

You can use the New-SystemMessage cmdlet to create customized delivery status notification (DSN) and quota messages in various languages. For more information about how to create customized DSNs, see Create a Custom DSN Message. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

DSN Message Identity


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-18 You can identify a customized delivery status notification (DSN) message based on its syntax. The identity is the customized DSN message's GUID or a string that consists of the following values:

Locale This variable specifies the locale of the language that the DSN message is displayed in. For a list of locale codes that you can use with the NewSystemMessage command, see Supported Locales for Use with System Messages. Internal or External This variable specifies whether the DSN message is sent only to senders who are part of the internal Microsoft Exchange Server 2010 organization or also to senders outside the Exchange 2010 organization. You can use the Internal option when you want to include a specific e-mail contact or resolution in DSN messages sent to internal senders, but don't want to expose that information to senders outside your organization. DSN code This variable specifies the DSN code of the customized DSN message. The syntax of the DSN message identity is <Locale>\<Internal or External>\<DSN code>. For each DSN code, you can create more than one customized DSN message, which can target internal senders or external senders, and different locales. For example, the following table shows some of the possible configurations for the DSN code 5.1.2 and the corresponding DSN message identities.

Example DSN configurations and identities


DSN configuration Display DSN messages to internal senders with an English (en) locale Display DSN messages to external senders with an English (en) locale Display DSN messages to internal senders with a Japanese (ja) locale Display DSN messages to external senders with a Japanese (ja) locale 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

DSN identity En\Internal\5.1.2 En\External\5.1.2 Ja\Internal\5.1.2 Ja\External\5.1.2

DSN Message Text


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-25 You can include text in a customized delivery status notification (DSN) message in Microsoft Exchange Server 2010, and you can format that text in HTML. You can include any information that you want to display to the recipient of the DSN message. For example, you can include a detailed description of the DSN, contact information for your help desk, and a link to your support department's Web site. Each DSN message can contain a maximum of 512 characters. Because DSN messages can be displayed in HTML, you can embed HTML formatting tags in the DSN text. For example, if you want to make some text in your DSN message bold, enclose the text in <B> and </B> HTML tags. The following table provides some examples of valid HTML tags that can be used in DSN message text.

Valid HTML tags for use in DSN messages


HTML tag <B> </B> <A HREF="url"> </A> <BR> <EM> </EM> <P> </P> Note: By default, Exchange 2010 sends HTML DSN messages, but you can configure whether Exchange 2010 sends HTML DSN messages to internal senders, external senders, or both. To configure this behavior, modify the InternalDsnSendHtml parameter and the ExternalDsnSendHtml parameter with the Set-TransportServer command. If the InternalDsnSendHtml parameter is set to $false, Exchange 2010 suppresses HTML tags in DSN messages sent to internal senders. If the ExternalDsnSendHtml parameter is set to $false, Exchange 2010 suppresses HTML tags in DSN messages sent to external senders. The following characters that Exchange 2010 uses in DSN message text have special meanings: Description Bold begin Bold end Hyperlink begin Hyperlink end Link break Italic begin Italic end Paragraph begin Paragraph end

Greater than sign (>) Less than sign (<) Ampersand (&) Quotation marks (") These characters are used to determine where HTML tags begin and end, and where text that should be displayed to senders starts and stops. If you want to display these characters in your DSN messages, you must use the escape codes in the following table. For example, if you want to display the message "Please contact the Help Desk at <1234>.", you must add "Please contact the Help Desk at &lt;1234&gt;." to the DSN message text.

DSN message character escape codes


Escape code &lt; &gt; &quot; &amp; Important: If you include an HTML tag in your DSN message text that contains quotation marks ("), such as <A HREF="url">, you must use single quotation marks (') around the whole DSN message text. You will receive an error message if you use double quotation marks around the whole DSN message text and around an HTML tag. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Character < > " &

Understanding DNS Query Failure Sensitivity


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-23 You can adjust the DNS query sensitivity for slightly faster message delivery when DNS errors are encountered for the destination domain. However, depending on the DNS errors, this adjustment may cause delivery failures in certain circumstances.

DNS Queries and Remote Message Delivery


In a typical Microsoft Exchange Server 2010 organization, an Edge Transport server that's subscribed to the organization is responsible for delivering messages to external recipients. This Edge Transport server is responsible for accepting the outgoing messages from the Hub Transport server in the organization. The subscribed Edge Transport server must be able to find a destination messaging server that accepts mail for the external recipients. Depending on the destination, the messages are put in one or more remote delivery queues as they await delivery to the remote recipients. For more information about delivery queues, see Understanding Transport Queues. The Edge Transport server queries the configured external DNS servers to find the DNS records that are required to deliver the message. The DNS servers that are configured for external DNS lookups are queried in the order in which they're listed. If one of the DNS servers is unavailable, the query goes to the next DNS server on the list. The DNS servers are queried for the following information:

Mail exchange (MX) records for the domain part of the external recipient The MX record contains the fully qualified domain name (FQDN) of the messaging server that's responsible for accepting messages for the domain, and a preference value for that messaging server. A lower preference value indicates a preferred messaging server. The preference value is important if the domain has more than one MX record. To optimize fault tolerance, most organizations use multiple messaging servers and multiple MX records that have different preference values. Address (A) records for the destination messaging servers Every messaging server that's used in an MX record should have a corresponding A record. The A record is used to find the IP address of the destination messaging server. The subscribed Edge Transport server uses the IP address to open an SMTP connection with the destination messaging server. Although it's technically possible to use the FQDN of a canonical name (CNAME) record in an MX record, this practice violates RFC 974, RFC 1034, RFC 1912, and RFC 2181, and is therefore not supported by most messaging servers. The required combination of iterative DNS queries and recursive DNS queries that start with a root DNS server is used to resolve the FQDN of the messaging server that's found in the MX record into an IP address. In Exchange 2010, there's a DNS query limit that's not configurable of 5 seconds for each DNS server, and a one-minute limit for the entire DNS query.

Potential DNS Problems


Even when the external DNS settings on the Microsoft Exchange Transport server are configured correctly, problems with the DNS records for a specific domain or problems with any of the DNS servers that are used to find the authoritative DNS server for a specific domain may still occur. Generally, these problems are beyond your control and need to be resolved by the parties that own those DNS servers. These DNS-related errors may be caused by one or more of the following conditions:

Invalid DNS records for the destination domain Problems with DNS server utilization Problems with DNS server replication In Exchange 2010, when a DNS query results in errors, the query continues to the next DNS server only if that DNS server hasn't already returned an error for the current query. Exchange 2010 also includes a parameter in the EdgeTransport.exe.config application configuration file that's named DnsFaultTolerance. This parameter has the following values:

Lenient When the DNS query encounters a combination of valid MX records and invalid MX records, the DNS query continues until the DNS query time-out value of one minute is reached. The invalid MX records are discarded, and the valid MX record that has the lowest preference value is used to deliver the message to the destination messaging server. Normal When the DNS query first encounters an invalid MX record, any resolved MX records that have a preference value that's greater than or equal to the invalid MX records are immediately discarded. The remaining MX record that has the lowest preference value is used to deliver the message to the destination messaging server without waiting for the whole DNS query to time out. Although this behavior may result in faster message delivery, the potential drawback of this behavior is the DNS query may have no valid MX records if the following conditions are true: The invalid MX record is the first MX record for the destination domain. The valid MX records have the same precedence value as the invalid MX records. The default value of the DnsFaultTolerance parameter on a Hub Transport server or Edge Transport server in Exchange 2010 is Lenient. In both Normal mode and Lenient mode, the results of the DNS query for an invalid MX record are never cached. The next time that a DNS query is executed, it will try to resolve the MX records for the destination domain. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Domain Security


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Domain Security refers to the set of functionality in Microsoft Exchange Server 2010 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as Domain Secured in the Outlook and Microsoft Office Outlook Web App interface. Domain Security uses mutual Transport Layer Security (TLS) authentication to provide session-based authentication and encryption. Mutual TLS authentication differs from TLS as it's usually implemented. Typically, when TLS is implemented, the client verifies that the connection securely connects to the intended server by validating the server's certificate. This is received as part of TLS negotiation. In this scenario, the client authenticates the server before the client transmits data. However, the server doesn't authenticate the session with the client. With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that's provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2010 environment, Outlook 2007 displays a Domain Secured icon. Important: It's beyond the scope of this topic to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and digital certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this topic. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Validation of TLS Certificates


To understand the overall security and resulting trustworthiness of any mutual TLS transmission, you must understand how the underlying TLS certificate is validated. Exchange 2010 includes a set of cmdlets to create, request, and manage TLS certificates. By default, these certificates are self-signed. A self-signed certificate is a certificate that's signed by its own creator. In Exchange 2010, the self-signed certificate is created by the computer running Microsoft Exchange by using the underlying Microsoft Windows Cryptography API (CAPI). Because the certificates are self-signed, the resulting certificates are less trustworthy than certificates that are generated by public key infrastructure (PKI) or a third-party certification authority (CA). Therefore, we recommend that you use self-signed certificates for internal mail only. Alternatively, if the receiving organizations with which you exchange domain-secured e-mail manually add your self-signed certificate to the trusted root certificate store in each of their inbound Edge Transport servers, the self-signed certificates are trusted explicitly. For connections that traverse the Internet, it's a best practice to generate TLS certificates with a PKI or third-party CA. Generating TLS keys with a trusted PKI or thirdparty CA reduces the overall management of Domain Security. For more information about the options regarding trusted certificates and Domain Security, see Using PKI on the Edge Transport Server for Domain Security. You can use the Exchange 2010 certificate cmdlets to generate certificate requests for your own PKI or for third-party CAs. For more information, see Understanding TLS Certificates. For more information about how to configure Domain Security, see the following:

Using Domain Security: Configuring Mutual TLS Domain Security White Paper

Using Exchange Hosted Services


Message-level security is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware Hosted Archive, which helps them satisfy retention requirements for compliance Hosted Encryption, which helps them encrypt data to preserve confidentiality Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.

Resources
Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001. Adams, Carlisle and Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996. Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Using Domain Security: Configuring Mutual TLS


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 This topic explains how to configure mutual Transport Layer Security (TLS) for Domain Security, the set of functionality in Microsoft Exchange Server 2010 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME and other message-level security solutions. For the purposes of this scenario, this topic explains how Exchange administrators at a fictitious company, Contoso, configure their Exchange 2010 environment to exchange domain-secured e-mail with their partner, Woodgrove Bank. Contoso administrators want to make sure that all e-mail sent to and received from Woodgrove Bank is protected with mutual TLS. Also, they want to configure Domain Security functionality so that all mail to and from Woodgrove Bank is rejected if mutual TLS can't be used. Contoso has an internal public key infrastructure (PKI) that generates certificates. The PKI's root certificate has been signed by a major third-party certification authority (CA). Woodgrove Bank uses the same third-party CA to generate their certificates. Therefore, both Contoso and Woodgrove Bank trust the other's root CAs. To set up mutual TLS, Exchange administrators at Contoso perform the following procedures: Step 1: Generate a certificate request for TLS certificates Step 2: Import certificates to Edge Transport servers Step 3: Configure outbound Domain Security Step 4: Configure inbound Domain Security Step 5: Test domain-secured mail flow

Prerequisites

This topic assumes that you have read and understood Generate Request for Third-Party Certificate Services. The Microsoft Exchange EdgeSync service must be fully deployed for Domain Security. Generally, configuration changes that are made to Domain Security functionality that don't use the ExchangeCertificate cmdlets are made within the organization and synchronized to Edge Transport servers by using the Microsoft Exchange EdgeSync service. Before you can successfully run mutual TLS on an Edge Transport server, you must configure the computer and PKI environment so that certificate validation and certificate revocation list checking are operable. For more information, see Using PKI on the Edge Transport Server for Domain Security. Even though individual configuration steps within this scenario can be accomplished with lesser rights, to complete the entire end-to-end scenario tasks, your account needs to be a member of the Organization Management management role group.

Step 1: Generate a Certificate Request for TLS Certificates


Contoso has an internal PKI that's subordinated to a third-party CA. In this scenario, subordination refers to the fact that the CA that's deployed by Contoso in the corporate infrastructure contains a root certificate that has been signed by a public third-party CA. By default, the public third-party CA is one of the trusted root certificates in the Microsoft Windows certificate store. Therefore, any client that includes the same third-party CA in its trusted root store and that connects to Contoso can authenticate to the certificate that's presented by Contoso. Contoso has two Edge Transport servers that require TLS certificates: mail1.contoso.com and mail2.mail.contoso.com. Therefore, the Contoso e-mail administrator must generate two certificate requests, one certificate request for each server. The following example shows the commands that the administrator uses to generate the base64-encoded PKCS#10 certificate requests. The Contoso administrator must run this command for CN=mail1.contoso.com.

$Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail1" -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com Set-Content -Path "C:\Certificates\mail1-request.req" -Value $Data1

The Contoso administrator must run this command for CN=mail2.mail.contoso.com.

$Data2 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail2" -SubjectName "DC=com,DC=Contoso,CN=mail2.mail.contos Set-Content -Path "C:\Certificates\mail2-request.req" -Value $Data2

For detailed syntax and parameter information, see New-ExchangeCertificate. Important: The specific details of the certificate or certificate request that you create depends on many variables. If you're generating a request, make sure that you work closely

with the CA or the PKI administrator who will issue your certificate. For more information about how to create a certificate request for TLS, see Generate Request for Third-Party Certificate Services. Return to top

Step 2: Import Certificates to Edge Transport Servers


After the Contoso administrator generates the certificate requests, the CA administrator for Contoso then uses the requests to generate the certificates for the servers. The resulting certificates must be issued as either a single certificate or a certificate chain and copied to the appropriate Edge Transport servers. Important: Do not use the Certificate Manager snap-in in the Microsoft Management Console (MMC) to import the certificates for TLS on the Exchange server. Using the Certificate Manager snap-in to import certificates on Exchange servers doesn't bind the request that's created in this procedure to the issued certificate. Therefore TLS might fail. You can use the Certificate Manager snap-in to import certificates and keys that are stored as .pfx files into the local computer store. When you import the certificate to the Edge Transport server, you must also enable the certificate for the SMTP service. The Contoso administrator runs the following command on each Edge Transport server, one time for each respective certificate.

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificates\mail1-certificate.pfx -Encoding Byte -ReadCount 0)) | Enable-Exchan

The preceding example imports and enables the TLS certificate by pipelining the certificate to the Enable-ExchangeCertificate cmdlet. You can also enable the certificate after you import it. If you do, you will need to specify the thumbprint of the certificate that you want to enable. For detailed syntax and parameter information, see the Import-ExchangeCertificate and Enable-ExchangeCertificate topics.

Transporting Certificates and Related Keys


When you receive a certificate from your PKI or CA provider, convert the issued certificate to a .pfx (PKCS#12) file so that you can back it up as part of a disaster contingency. A .pfx file contains the certificate and related keys. In some cases, you may want to transport the certificate and keys to move them to other computers. For example, if you have multiple Edge Transport servers where you expect to send and receive e-mail that's domain secured, you can create a single certificate that will work for all servers. In this case, you must have the certificate imported and enabled for TLS on each Edge Transport server. As long as you keep a copy of the .pfx file securely archived, you can always import and enable the certificate. The .pfx file contains the private key so it's important to physically protect the file by keeping it on storage media in a secure location. It's important to understand that the Import-ExchangeCertificate cmdlet always marks the imported private key from the .pfx file as non-exportable. This functionality is by design. When you use the Certificate Manager snap-in in MMC to import a .pfx file, you can specify private key exportability and strong-key protection. Important: Do not enable strong-key protection on certificates that are intended for TLS. Strong-key protection prompts the user every time that the private key is accessed. With Domain Security, the user is the SMTP service on the Edge Transport server. Return to top

Step 3: Configure Outbound Domain Security


You must perform three steps to configure outbound Domain Security:

1. Run the Set-TransportConfig cmdlet to specify the domain with which you want to send domain-secured e-mail. 2. Run the Set-SendConnector cmdlet to set the DomainSecureEnabled property on the Send connector that will send mail to the domain with which you want to send domain-secured e-mail. 3. Run the Get-SendConnector cmdlet to verify the following: The Send connector that will send mail to the domain with which you want to send domain-secured e-mail routes mail with Domain Name System (DNS). The FQDN is set to match either the Subject Name or the Subject Alternative Name of certificates that you're using for Domain Security. Because the changes that you make in these three steps are global, you must make the changes on an internal Exchange server. The configuration changes that you make will be replicated to the Edge Transport servers by using the Microsoft Exchange EdgeSync service.

Step 3a: Specify the Sender Domain in Transport Configuration


It's relatively straightforward to specify the domain with which you want to send domain-secured e-mail. The Contoso administrator runs the following command on an internal Exchange 2010 server.

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

The TLSSendDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSSendDomainSecureList with the new value that's supplied in the cmdlet. Therefore, if you have other domains already configured and want to add a new domain, you need to either include the existing domain in the list or use a temporary variable. The following example shows how to add the woodgrovebank.com domain to

the TLSSendDomainSecureList parameter without overwriting any existing values.

$TransportConfig = Get-TransportConfig $TransportConfig.TLSSendDomainSecureList += "woodgrovebank.com" Set-TransportConfig -TLSSendDomainSecureList $TransportConfig.TLSSendDomainSecureList

For detailed syntax and parameter information, see Set-TransportConfig.

Step 3b: Configure the Default Send Connector


Contoso will use the default DNS-routed Send connector named Internet to send domain-secured e-mail to their partners. Because their default DNS-routed Send connector is a default Internet Send connector, it uses DNS to route mail and doesn't use a smart host. The FQDN is already set to mail.contoso.com. Because the certificates that the Contoso administrator created set the DomainName parameter of the New-ExchangeCertificate to mail.contoso.com, the Send connector can use the certificates without additional configuration. If you've configured a subdomain for testing, you may have to update the FQDN of your Send connector to match the certificate that you've created (for example, subdomain.mail.contoso.com). On the other hand, if you've created a certificate that contains the subdomain in the Subject or Subject Alternative name fields, you don't have to update the FQDN of the Send connector. Therefore, the only configuration that the Contoso administrator must make to the Send connector is to set the DomainSecureEnabled parameter. To do this, the Contoso administrator runs the following command on an internal Exchange 2010 server for the Internet Send connector.

Set-SendConnector Internet -DomainSecureEnabled:$true

For detailed syntax and parameter information, see Set-SendConnector.

Step 3c: Verify the Send Connector Configuration


After completing the configuration changes, the Contoso administrator needs to verify that the Send connector being used for Domain Security is configured correctly. To do so, the Contoso administrator needs to run the following command.

Get-SendConnector Internet | Format-List Name,DNSRoutingEnabled,FQDN,DomainSecureEnabled

This command will list the relevant parameters configured for Domain Security, allowing the Contoso administrator to verify the configuration. For detailed syntax and parameter information, see Get-SendConnector. Return to top

Step 4: Configure Inbound Domain Security


You must perform two steps to enable inbound Domain Security:

1. Run the Set-TransportConfig cmdlet to specify the domain from which you want to receive domain-secured e-mail. 2. On the Edge Transport server, use the Exchange Management Shell or the Exchange Management Console (EMC) to enable Domain Security on the Receive connector from which you want to receive domain-secured e-mail. Because Domain Security requires mutual TLS authentication, TLS must also be enabled on the Receive connector.

Step 4a: Specify the Recipient Domain in Transport Configuration


It's relatively straightforward to specify the domain with which you want to receive domain-secured e-mail. To specify the domain, the Contoso administrator runs the following command in the Shell on an internal Exchange 2010 server or management workstation.

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

The TLSReceiveDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSReceiveDomainSecureList parameter with the new value supplied by the Set-TransportConfig cmdlet. Therefore, if you have other domains already configured and want to add a new domain, you need to either include the existing domain in the list or use a temporary variable. The following example shows how to add the woodgrovebank.com domain to the TLSReceiveDomainSecureList parameter without overwriting any existing values.

$TransportConfig = Get-TransportConfig $TransportConfig.TLSReceiveDomainSecureList += "woodgrovebank.com" Set-TransportConfig -TLSReceiveDomainSecureList $TransportConfig.TLSReceiveDomainSecureList

For detailed syntax and parameter information, see Set-TransportConfig.

Step 4b: Configure the Receive Connector


You must configure the Receive connector on each Edge Transport server that accepts mail from the domain from which you want to receive domain-secured e-mail. The Contoso environment is configured to have a single Internet Receive connector, with an Identity parameter value of Internet, on both Edge Transport servers. Therefore, to enable TLS while mail is sent to or received from Woodgrove Bank, the Contoso administrator must make sure that TLS is enabled on the default Internet Receive connector on both Edge Transport servers. To do so, the Contoso administrator runs the following command on both mail1.contoso.com and mail2.mail.contoso.com.

Set-ReceiveConnector Internet -DomainSecureEnabled $true -AuthMechanism TLS

For detailed syntax and parameter information, see Set-ReceiveConnector. You can also use the EMC to configure the Receive connector using the following steps.

1. On the Edge Transport server, open the EMC, click Edge Transport, and then in the result pane, click the Receive Connectors tab. 2. Select the Receive connector that accepts mail from the domain from which you want to receive domain-secured e-mail, the connector Internet in this case, and then click Properties in the action pane. 3. On the Authentication tab, select Transport Layer Security (TLS) and Enable Domain Security (Mutual Auth TLS), and then click OK. Be aware that specifying the authentication mechanism as TLS doesn't force TLS on all inbound connections. TLS will be forced for connections from Woodgrove Bank for the following reasons:

Woodgrove Bank is specified in the Set-TransportConfig cmdlet on the TLSReceiveDomainSecureList parameter. The DomainSecureEnabled parameter is set to $true on the Receive connector. Other senders that aren't listed on the TLSReceiveDomainSecureList parameter in the Set-TransportConfig cmdlet will only use TLS if TLS is supported by the sending system. Return to top

Step 5: Testing Domain-Secured Mail Flow


After you've configured domain-secured e-mail, you can test the connection by reviewing the performance logs and the protocol logs. Messages that have successfully authenticated over the domain-secured mail flow path are displayed in Outlook as Domain Secure messages.

Performance Counters
The Domain Security feature includes the following set of performance counters under MSExchange Secure Mail Transport:

Domain-Secured Messages Received Domain-Secured Messages Sent Domain-Secured Outbound Session Failures You can create a new counter log file for domain-secured mail flow with these performance counters to monitor the number of messages sent and received and also to monitor failed mutual TLS sessions. For more information about how to create and configure counter logs, see the Help file that's included with the Performance Logs and Alerts MMC snap-in.

Protocol Logs
You can review the send and receive protocol logs to determine whether TLS negotiation has been successful. To view detailed protocol logs, you must set the protocol logging level to Verbose on the connectors that your organization uses to send and receive domain secured e-mail. To accomplish this, the Contoso administrator runs the following on both Edge Transport servers.

Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose

To enable protocol logging on the Send connector, the Contoso administrator runs the following on an internal Exchange server or management workstation. The configuration change is then replicated to the Edge Transport servers using the Microsoft Exchange EdgeSync service.

Set-SendConnector Internet -ProtocolLoggingLevel Verbose

For detailed syntax and parameter information, see the Set-ReceiveConnector and Set-SendConnector topics. For more information about how to view protocol logs, see Configure Protocol Logging.

Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Using PKI on the Edge Transport Server for Domain Security


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Domain Security relies on mutual Transport Layer Security (TLS) for authentication. Successful mutual TLS authentication relies on a trusted, validated X.509 certificate chain for the TLS certificates that are used for Domain Security. Therefore, before you can successfully deploy Domain Security, you must configure your Edge Transport server and your X.509 public key infrastructure (PKI) to accommodate certificate trusting and certificate validation. Important: It's beyond the scope of this topic to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and X.509 certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this topic.

Configuring Root Certification Authorities


To validate a given X.509 certificate, you must trust the root certification authority (CA) that issued the certificate. A root CA is the most trusted CA, which is at the top of a CA hierarchy. The root CA has a self-signed certificate. When you run an application that relies on certificate authentication, each certificate must have a certificate chain that ends in a certificate in the trusted root container of the local computer. The trusted root container contains certificates from root certification authorities. To successfully send domain-secured e-mail, you must be able to validate the receiving server's X.509 certificate. Similarly, when someone sends domain-secured e-mail to your organization, the sending server must be able to validate your certificate. There are two types of trusted root CAs that you can use to implement Domain Security: Built-in third-party root CAs and private root CAs.

Third-Party Root Certification Authorities


Microsoft Windows includes a set of built-in third-party root CAs. If you trust the certificates issued by these third-party root CAs, this means you can verify certificates issued by these CAs. If your organization and your partner organizations are using the default Windows installation and trust the built-in third-party root CAs, trust is automatic. In this scenario, additional trust configuration is not required.

Private Trusted Root Certification Authorities


A private trusted root CA is a root CA that has been deployed by a private or internal PKI. For example, when your organization or the organization that you exchange domain-secured e-mail with has deployed an internal PKI with its own root certificate, you must make additional trust configurations. When private root CAs are used, you must update the Windows trusted root certificate store on the Edge Transport server for Domain Security to function correctly. You can configure trust in two ways: direct root trust and cross-certification. You must understand that whenever the transport service picks a certificate, it validates the certificate before it uses it. Therefore, if you're using a private root CA to issue your certificates, you must include the private root CA in the trusted root certificate store on each Edge Transport server that sends or receives domain-secured e-mail.

Direct Root Trust


If you want to trust a certificate that has been issued by a private root CA, you can manually add that root certificate to the trusted root certificate store on the Edge Transport server computer. For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in Microsoft Management Console (MMC).

Cross-Certification
Cross-certification occurs when one CA signs a certificate that is generated by a different CA. Cross-certification is used to build trust from one PKI with another PKI. In the context of Domain Security, if you have your own PKI, instead of using direct manual trust for a root authority of a partner with an internal PKI, you might create a cross-certificate for the partner CA under your root authority. In this case, trust is established because the cross-certificate ultimately chains back to your trusted root. You must understand that if you have an internal PKI and are using cross-certification, you must manually update the root certificate store on each Edge Transport server that receives domain-secured e-mail so that each Edge Transport server can validate certificates when they receive e-mail from partners that are trusted through cross-certificates. For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in MMC.

Configuring Access to the Certificate Revocation List


Whenever the Transport service retrieves a certificate, it validates the certificate chain and validates the certificate. Validation of the certificate is a process in which many

attributes of the certificate are confirmed. Most of these attributes can be confirmed on the local computer by the application that requests the certificate. For example, the intended use of the certificate, the expiration dates on the certificate, and similar attributes are verifiable outside the context of a PKI. However, verification that the certificate has not been revoked must be validated with the CA that issued the certificate. Therefore, most CAs make a certificate revocation list (CRL) available to the public to validate the revocation status. To successfully use Domain Security, CRLs for CAs that you use or are used by your partners must be available to the Edge Transport servers that send and receive domain-secured e-mail. If the revocation check fails, the receiving Exchange server issues a temporary protocol rejection of the message. A transient revocation failure can occur. For example, the Web server that is used to publish the CRL can fail. Or, general network connectivity issues between the Edge Transport server and the CRL distribution point could fail the revocation check. Therefore, transient revocation failures only cause temporary mail delivery delays because the sending server will retry later. However, CRL validation is required for successful domain-secured e-mail transmission. You must enable the following scenarios:

Your Edge Transport servers must be able to access CRLs for external CAs Each partner with which you exchange domain-secured e-mail must have publicly available CRLs that your organization's Edge Transport server can contact. In some cases, CRLs are only available with Lightweight Directory Access Protocol (LDAP). In most cases, with public CAs, CRLs are published via HTTP. Make sure that the appropriate outbound ports and proxies are configured to let the Edge Transport server contact the CRL. You can determine which protocol a given CRL distribution point accepts by opening a certificate in MMC and viewing the CRL Distribution Points field. You must make the CRL for the CA that issues your certificates publicly available You must understand that even when an Edge Transport server retrieves a certificate from your own organization, it validates the certificate chain to validate the certificate. Therefore, the CRL for your CA must be available to your own Edge Transport servers. In addition, all partners that you exchange domain-secured e-mail with must be able to access the CRL for the CA that issues your certificates.

Configuring Proxy Settings for WinHTTP


Exchange 2010 transport servers rely on the underlying Microsoft Windows HTTP Services (WinHTTP) to manage all HTTP and HTTPS traffic. Both Hub Transport servers and Edge Transport servers may use HTTP to access updates for Microsoft Exchange 2010 Standard Anti-spam Filter Updates and for CRL validation. For more information, see Configure Proxy Settings for WinHTTP.

Testing the PKI and Proxy Configuration


To verify your PKI and proxy configuration for a specific Edge Transport server, use Certutil.exe to verify the certificate chain for your Edge Transport server certificate. Certutil.exe is a command-line tool that is installed as part of Certificate Services in Windows Server 2008 operating systems. For more information, see Test PKI and Proxy Configuration.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Test PKI and Proxy Configuration


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 To verify your public key infrastructure (PKI) and proxy configuration for a specific Edge Transport server, use Certutil.exe to verify the certificate chain for your Edge Transport server certificate. Certutil.exe is a command-line tool installed as part of Certificate Services in the Windows Server 2008 operating system. For more information, see Certutil. Before you can run Certutil to verify the certificate chain for a specific certificate, the certificate must first be in file (.cer) format. Therefore, you must first export the certificate, but not the private keys, to the DER (.cer) file format. The first procedure in this topic shows you how to add the Certificate Manager snap-in to the Microsoft Management Console (MMC). The second procedure explains how to use the Certificate Manager to export a certificate. The third procedure shows how you can run the Certutil command to verify the certificate chain.

Step 1: Add Certificate Manager to the Microsoft Management Console


To perform this procedure, the account you use must be delegated membership in the local Administrators group.

1. 2. 3. 4. 5. 6. 7.

Click Start, click Run, type mmc, and then click OK. On the File menu, click Add/Remove Snap-in. In the Add/Remove Snap-in box, click Add. In the Available Snap-ins list, click Certificates, and then click Add. Click Computer Account, and then click Next. Click the Local computer (the computer this console is running on) option, and then click Finish. Click OK.

Step 2: Export the certificate


To perform this procedure, the account you use must be delegated membership in the local Administrators group.

1. 2. 3. 4. 5. 6. 7. 8.

Open the Certificate Manager that you created in Step 1. Expand the Certificates (Local Computer) folder and the Personal folder, and then click the Certificates folder. In the details pane, right-click the certificate that you will use for Domain Security, click All Task, and then select Export. The Certificate Export Wizard will open. On the Welcome page, click Next. On the Export Private Key page, select No, do not export the private key, and then click Next. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next. On the File to Export page, enter the path and file name where you want to save the exported certificate, and then click Next. On the Finish page, verify the settings and then click Finish.

Step 3: Verify the certificate chain for the certificate


To perform this procedure, the account you use must be delegated membership in the local Administrators group. On the Edge Transport server, open a Command Prompt window, and type the following command.

Certutil -verify c:\CertificateName.cer

In this example, CertificateName is the Edge Transport server certificate that you exported in the previous procedure.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Edge Subscriptions


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-02-01 This topic provides detailed information about Edge Subscriptions and the EdgeSync synchronization process. Edge Subscriptions are used to populate the Active Directory Lightweight Directory Services (AD LDS) instance on the Microsoft Exchange Server 2010 Edge Transport server role with Active Directory data. In Exchange 2010, the Edge Transport server role is deployed in your organization's perimeter network. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow and provides SMTP relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they're processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow. Although creating an Edge Subscription is optional, subscribing an Edge Transport server to the Exchange organization provides a simpler management experience for the administrator and enhances the available anti-spam features. You must create an Edge Subscription if you plan to use recipient lookup or safelist aggregation, or if you plan to help secure SMTP communications with partner domains by using mutual Transport Layer Security (TLS). Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Edge Subscription Process Microsoft Exchange EdgeSync Service Managing Edge Subscriptions

Edge Subscription Process

In a typical deployment scenario, the computer that has the Edge Transport server role installed doesn't have access to Active Directory. All the configuration and recipient information that the Edge Transport server has to process messages is stored in AD LDS. Creating an Edge Subscription establishes secure, automatic replication of information from Active Directory to AD LDS. The Edge Subscription process provisions the credentials that are used to establish a secure LDAP connection between Hub Transport servers and a subscribed Edge Transport server. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers then performs periodic one-way synchronization to transfer data to AD LDS and keep that data up to date. This process reduces the administration that you must perform in the perimeter network by letting you perform required configuration on the Hub Transport server role and then write that information to the Edge Transport server. You subscribe an Edge Transport server to the Active Directory site that contains the Hub Transport servers that will directly exchange messages with your Edge Transport servers. The Edge Subscription process creates an Active Directory site membership affiliation for the Edge Transport server. The site affiliation enables Hub Transport servers in the Exchange organization to relay messages to the Edge Transport server for delivery to the Internet without having to configure explicit Send connectors. One or more Edge Transport servers can be subscribed to a single Active Directory site. However, an Edge Transport server can't be subscribed to more than one Active Directory site. If you have more than one Edge Transport server deployed, each server can be subscribed to a different Active Directory site. Each Edge Transport server requires an individual Edge Subscription. To deploy an Edge Transport server and subscribe it to an Active Directory site, follow these steps:

1. 2. 3. 4.

Install the Edge Transport server role. Verify that the Hub Transport servers and the Edge Transport server can locate one another by using Domain Name System (DNS) name resolution. Configure the objects and settings to be replicated to the Edge Transport server. On the Edge Transport server, create and export an Edge Subscription file. For more information about this step, see Create an Edge Subscription File on an Edge Transport Server. 5. Copy the Edge Subscription file to a Hub Transport server or a file share that's accessible from the Active Directory site that has your Hub Transport servers. 6. Import the Edge Subscription file to your Active Directory site to which you want to subscribe your Edge Transport server. For more information about this step, see Import an Edge Subscription File to an Active Directory Site. The following figure illustrates the Edge Subscription process.

Configuration Changes Made When a New Edge Subscription Is Created


When you run the New-EdgeSubscription cmdlet on the Edge Transport server to create an Edge Subscription file, the following actions occur:

An AD LDS account is created. This account is called the EdgeSync bootstrap replication account (ESBRA). These credentials are used to authenticate the first EdgeSync connection to the Edge Transport server. The account is configured to expire 1,440 minutes (24 hours) after it's created. Therefore, you must complete the subscription process before that time expires. If the ESBRA expires before the Edge Subscription process is complete, you must run the NewEdgeSubscription cmdlet on the Edge Transport server again to create an Edge Subscription file. The ESBRA credentials are retrieved from AD LDS and written to the Edge Subscription file. The public key for the Edge Transport server's self-signed certificate is also exported to the Edge Subscription file. The credentials that are written to the Edge Subscription file are specific to the server from which the file is exported. Any previously created configuration objects in a class that will now be replicated to AD LDS from Active Directory are deleted from AD LDS and the Exchange Management Shell commands used to configure those objects are disabled. You can still use the cmdlets that let you view those objects. The following cmdlets are disabled on the Edge Transport server when you run the New-EdgeSubscription cmdlet: Set-SendConnector New-SendConnector Remove-SendConnector New-AcceptedDomain Set-AcceptedDomain Remove-AcceptedDomain New-MessageClassification Set-MessageClassification Remove-MessageClassification New-RemoteDomain Set-RemoteDomain Remove-RemoteDomain When you import the Edge Subscription file on the Hub Transport server by running the New-EdgeSubscription cmdlet in the Shell or by using the New Edge Subscription wizard in the Exchange Management Console, the following actions occur:

The Edge Subscription is created, establishing a record of an Edge Transport server that has been joined to an Exchange organization and to which the Microsoft Exchange EdgeSync service will propagate configuration data. This step creates the edge configuration object in Active Directory. Each Hub Transport server in the Active Directory site receives notification from Active Directory that a new Edge Transport server has been subscribed. The Hub Transport server retrieves the ESBRA from the Edge Subscription file. The Hub Transport server then encrypts the ESBRA by using the public key of the Edge Transport server's self-signed certificate. The encrypted credentials are then written to the edge configuration object. Each Hub Transport server also encrypts the ESBRA by using its own public key and then stores the credentials in its own configuration object. EdgeSync replication accounts (ESRAs) are created in Active Directory for each Edge Transport-Hub Transport server pair. Each Hub Transport server stores its ESRA credentials as an attribute of the Hub Transport server configuration object. Send connectors are automatically created to relay messages outbound from the Edge Transport server to the Internet, and inbound from the Edge Transport server to the Exchange organization. The Microsoft Exchange EdgeSync service that runs on Hub Transport servers uses the ESBRA credentials to establish a secure LDAP connection between a Hub Transport server and the Edge Transport server and performs the initial replication of data. The following data is replicated to AD LDS: Topology data Configuration data Recipient data ESRA credentials The Microsoft Exchange Credential Service that runs on the Edge Transport server installs the ESRA credentials. These credentials are used to authenticate and secure later synchronization connections. The EdgeSync synchronization schedule is established. The Microsoft Exchange EdgeSync service that's running on the Hub Transport servers in the Active Directory site to which the Edge Transport server is subscribed will now perform one-way replication of data from Active Directory to AD LDS on a regular schedule. You can also use the Start-EdgeSynchronization cmdlet in the Shell to override the EdgeSync synchronization schedule and immediately start synchronization. For more information about ESRA accounts and how they're used to help secure the EdgeSync synchronization process, see Understanding Edge Subscription Credentials.

Send Connectors Created During Edge Subscription Process


By default, when you complete the Edge Subscription process by importing the Edge Subscription file to a Hub Transport server, the Send connectors that are required to enable end-to-end mail flow between the Internet and the Exchange organization are created automatically. Any existing Send connectors on the Edge Transport server are deleted. Even though that's the recommended method, you can also select to suppress automatic creation of Send connectors and configure Send connectors manually. For more information about manually configuring Send connectors, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync. The Edge Subscription process provisions the following Send connectors:

A Send connector that's configured to relay e-mail messages from the Exchange organization to the Internet A Send connector that's configured to relay e-mail messages from the Edge Transport server to the Exchange organization Also, by subscribing an Edge Transport server to the Exchange organization, you enable Hub Transport servers that are located in the Active Directory site to which the Edge Transport server is subscribed to use the intra-organization Send connector to relay messages to that Edge Transport server.

Automatically Create a Send Connector to Send Messages to the Internet


By default, when you run the New-EdgeSubscription cmdlet in the Shell on the Hub Transport server, the CreateInternetSendConnector parameter is set to $true. This creates the Send connector that's required to send messages to the Internet. The following table shows the default configuration of this Send connector. Automatic Internet Send connector configuration

Parameter Name

Value EdgeSync - <Site Name> to Internet

Address Space Source Servers

SMTP:*;100 Edge Subscription name Note: The name of the Edge Subscription is the same as the name of the subscribed Edge Transport server.

Enabled DNS Routing Enabled Domain Secure Enabled (Mutual Auth TLS)

True True True

If more than one Edge Transport server is subscribed to the same Active Directory site, additional Send connectors to the Internet aren't created. Instead, all Edge Subscriptions are added to the same Send connector as source servers. This configuration causes outbound connections to the Internet to be load balanced between the subscribed Edge Transport servers. This Send connector is configured to send e-mail messages from the Exchange organization to all remote SMTP domains. It will use DNS routing to resolve domain names to MX resource records. You can modify the configuration of this connector manually. However, if you must route outbound e-mail through a smart host, for example, you can suppress creation of this connector and manually configure a Send connector to the Internet. Note: A Send connector that's configured to use a smart host to route e-mail must have the DNSRoutingEnabled parameter set to $false. If the DNSRoutingEnabled parameter is set to $false, the DomainSecureEnabled parameter must also be set to $false.

Automatically Create an Inbound Send Connector


By default, when you run the New-EdgeSubscription cmdlet in the Shell on the Hub Transport server, the CreateInboundSendConnector is parameter set to $true. This creates the Send connector that's required to send messages to the Exchange organization. The following table shows the configuration of this Send connector. Automatic inbound Send connector configuration

Parameter Name Address Space Source Servers Enabled DNS Routing Enabled Smart Hosts

Value EdgeSync - Inbound to <Site Name> SMTP:--;1 Edge Subscription name True False --

The -- placeholder in the address space for the inbound Send connector represents the authoritative and internal relay accepted domains for the Exchange organization and is the literal character displayed. Any messages that the Edge Transport server receives for authoritative and internal relay accepted domains are routed to this Send connector and relayed to the smart hosts. The -- placeholder in the list of smart hosts represents all the Hub Transport servers that are located in the subscribed Active Directory site and is the literal character displayed. Hub Transport servers that are added to an Active Directory site after an Edge Subscription has been established don't participate in the EdgeSync synchronization process. However, they are automatically added to the list of smart hosts for the inbound Send connector. If more than one Hub Transport server is located in the subscribed Active Directory site, inbound connections will be load balanced across the smart hosts. You can't modify the address space or list of smart hosts for the automatically created inbound Send connector. However, you can set the value of the CreateInboundSendConnector parameter to $false when creating an Edge Subscription, and manually configure a Send connector from the Edge Transport server to the Exchange organization.

Intra-Organization Send Connector


The intra-organization Send connector is an implicit and hidden Send connector that's automatically computed by Exchange 2010 and enables Hub Transport servers in the same organization to relay messages to each other without using explicit Send connectors. Because a configuration object that has an Active Directory site association exists in Active Directory for an Edge Subscription, the intra-organization Send connector will also be used to relay messages to that Edge Transport server. Only Hub Transport servers that are located in the same Active Directory site to which the Edge Transport server is subscribed can send and receive e-mail directly to or from the subscribed Edge Transport server. If you have a multiple site forest and Exchange 2010 is deployed in more than one site, the Hub Transport servers in non-subscribed sites will route outbound e-mail to the subscribed site. A Hub Transport server in the subscribed site will route outbound e-mail to the Edge Transport server.

Creating Additional Send Connectors After Edge Subscription is Completed

After an Edge Transport server is subscribed to an Active Directory site, the tasks for creating and modifying Send connectors are disabled on the Edge Transport server. If you want to create a Send connector for which the Edge Transport server is a source server, you create the Send connector inside the Exchange organization. You can specify one or more Edge Subscriptions as the source server for a Send connector. You can't specify both Hub Transport servers and Edge Subscriptions as source servers for the same Send connector. The Send connector will be replicated to the AD LDS instance on the Edge Transport server that's configured as a source server the next time that configuration data is synchronized by the EdgeSync synchronization process. If you list more than one Edge Subscription as a source server, connections to that Send connector will be load balanced between the subscribed Edge Transport servers. However, the Edge Transport servers have to be subscribed to the same Active Directory site for load balancing to occur. If Edge Subscriptions in different Active Directory sites are configured as source servers on the same Send connector, Hub Transport servers will route only to the closest source server. You have to create Send connectors manually in the following scenarios:

You've suppressed automatic creation of the Internet or inbound Send connectors. You've accepted domains that are configured as external relay domains.

Suppressing Automatic Creation of Send Connectors


Depending on the topology of your Exchange organization, you may decide to suppress automatic creation of Send connectors. The following scenarios provide examples of topologies that require that you suppress automatic creation of Send connectors.

Partitioning Mail Flow


You may decide to partition the inbound and outbound mail processing between two Edge Transport servers. In this scenario, one Edge Transport server is responsible for processing outbound mail flow and a second Edge Transport server is responsible for processing inbound mail flow. To achieve this scenario, you configure the Edge Subscriptions as follows:

For the Edge Transport server that processes only outbound mail flow, run the following command in the Shell on the Hub Transport server.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A"

For the Edge Transport server that processes only inbound mail flow, run the following command in the Shell on the Hub Transport server.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A"

Routing Outbound E-Mail to a Smart Host


If your Exchange organization routes all outbound e-mail through a smart host, the default automatically created Send connector to the Internet won't have the correct configuration. In this scenario, you run the following command in the Shell on the Hub Transport server to suppress automatic creation of the Send connector to the Internet.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\EdgeServerSubscription.xml" -Encoding Byte -ReadCount 0)) -Site "Site-A" -Creat

After the Edge Subscription process is complete, manually create a Send connector to the Internet. Create the Send connector inside the Exchange organization and select the Edge Subscription as the source server for the connector. Select the Custom usage and configure one or more smart hosts. The Send connector will be replicated to the AD LDS instance on the Edge Transport server the next time that EdgeSync synchronizes configuration data. You can also force EdgeSync synchronization to immediately start by running the Start-EdgeSynchronization cmdlet in the Shell on a Hub Transport server. The following code provides an example of how to use the Shell to configure a Send connector for a subscribed Edge Transport server to route messages for all Internet address spaces through a smart host. This task is run inside the Exchange organization, not on the Edge Transport server.

New-SendConnector -Name "EdgeSync - Site-A to Internet" -Usage Custom -AddressSpaces SMTP:*;100 -DNSRoutingEnabled $false -SmartHosts 192.168.1

Important: This example doesn't specify any smart host authentication mechanism. Make sure that you configure the correct authentication mechanism and provide all necessary credentials when you create a smart host connector in your own Exchange organization.

Configuring Send Connectors for External Relay Domains


If you've accepted domains in your Exchange organization that are configured as external relay domains, you have to manually create a Send connector for those address spaces. Messages that are being delivered to external relay domains are relayed by the Edge Transport server. The Edge Subscription process doesn't automatically create and configure Send connectors for external relay domains. Therefore, you have to configure Send connectors for those domains and specify one or more Edge Subscriptions as the source server for those Send connectors.

The DNS MX resource record for an external relay domain resolves to your Edge Transport server. Configure a Send connector that relays e-mail to an external relay domain to use a smart host for routing. If you configure the Send connector for an external relay domain to use DNS routing, a routing loop will occur. For more information about external relay domains, see Understanding Accepted Domains. Return to top

Microsoft Exchange EdgeSync Service


After you subscribe an Edge Transport server to an Active Directory site, the EdgeSync service that runs on the Hub Transport servers will replicate configuration and recipient data to the Edge Transport servers using the Microsoft Exchange EdgeSync service. The service replicates the following data from Active Directory to AD LDS:

Send connector configuration Accepted domains Remote domains Message classifications Safe Senders Lists Blocked Senders Lists Recipients List of send and receive domains used in domain secure communications with partners List of SMTP servers listed as internal in your organization's transport configuration List of Hub Transport servers in the subscribed Active Directory site For more information about the data that's replicated to AD LDS and how it's used, see EdgeSync Replication Data. The Microsoft Exchange EdgeSync service uses a secure LDAP channel to transfer this data. A mutually authenticated and authorized secure LDAP channel is established from the Hub Transport server to the Edge Transport server. To replicate data to AD LDS, the Hub Transport server binds to a global catalog server to retrieve updated data. The Microsoft Exchange EdgeSync service initiates a secure LDAP session between a Hub Transport server and the subscribed Edge Transport server over the non-standard TCP port 50636. The following figure illustrates the EdgeSync synchronization process.

When you first subscribe an Edge Transport server to an Active Directory site, the initial replication that populates AD LDS with data from Active Directory can take some time, depending on the quantity of data in the directory service. After the initial replication is complete, the EdgeSync service only synchronizes the new and changed objects and removes any objects that have been deleted from Active Directory.

Synchronization Schedule
Different types of data synchronize on different schedules. The EdgeSync synchronization schedule specifies the maximum length of time between EdgeSync synchronization intervals. EdgeSync synchronization occurs at the following intervals:

Configuration data is scheduled to be synchronized at 3-minute intervals. Recipient data is scheduled to be synchronized at 5-minute intervals. Topology data is reloaded every 5 minutes. You use the Set-EdgeSyncServiceConfig cmdlet to configure the EdgeSync synchronization schedule intervals. If you use the Start-EdgeSynchronization cmdlet in the Shell on the Hub Transport server to force Edge Subscription synchronization to occur immediately, you override the timer that determines the next time that EdgeSync synchronization is scheduled to occur.

Selection of Hub Transport Server


A subscribed Edge Transport server is associated with a particular Active Directory site. If more than one Hub Transport server exists in the site, any of them can replicate data to the subscribed Edge Transport servers. To avoid contention among the Hub Transport servers when synchronizing, the selection of the preferred Hub Transport server occurs as follows:

1. The first Hub Transport server in the Active Directory site to perform a topology scan and discover the new Edge Subscription performs the initial replication. Because this discovery is based on the timing of the topology scan, any Hub Transport server in the site may perform the initial replication. 2. The Hub Transport server that performs the initial replication establishes an EdgeSync lease option and sets a lock on the Edge Subscription. The lease option establishes that Hub Transport server as the preferred server to provide synchronization services to that Edge Transport server. The lock prevents the Microsoft Exchange EdgeSync service on another Hub Transport server from taking over the lease option. 3. The EdgeSync lease option lasts for one hour. No other Microsoft Exchange EdgeSync service can take over the option from another Hub Transport server during this one-hour period unless a manual synchronization occurs before this period expires. If the preferred Hub Transport server isn't available to provide the Microsoft Exchange EdgeSync service when manual synchronization is performed, after a five-minute wait, the lock is released and another Microsoft Exchange EdgeSync service takes over the lease option and performs synchronization. 4. If manual synchronization isn't performed, synchronization occurs based on the EdgeSync synchronization schedule. If the preferred server isn't available when scheduled synchronization occurs, after a five-minute wait, the lock is released and another Microsoft Exchange EdgeSync service takes over the lease option and performs synchronization. This method of locking and leasing prevents more than one instance of the Microsoft Exchange EdgeSync service from pushing data to the same Edge Transport

server at the same time. Note: If you have both Exchange 2010 and Exchange Server 2007 Hub Transport servers in the Active Directory site to which your Edge Transport server is subscribed, Exchange 2010 Hub Transport servers will always take precedence over Exchange 2007 Hub Transport servers. Note: When an Edge Transport server is subscribed to an Active Directory site, all the Hub Transport servers that are installed in that Active Directory site at that time can participate in the EdgeSync synchronization process. If one of those servers is removed, the Microsoft Exchange EdgeSync service that's running on the remaining Hub Transport servers will continue the data synchronization process. However, if new Hub Transport servers are installed in the Active Directory site, they won't participate in the EdgeSync synchronization process automatically. To enable those Hub Transport servers to participate in the EdgeSync synchronization process, you have to subscribe the Edge Transport server again. The following table lists the EdgeSync properties that are related to the locking and leasing process. You can use the Set-EdgeSyncServiceConfig cmdlet to configure these properties. EdgeSync lease properties

Property name Lock duration

Value

Description

5 minutes

This setting determines for how long a particular Microsoft Exchange EdgeSync service will acquire a lock. If the Microsoft Exchange EdgeSync service on the Hub Transport server that's holding this lock doesn't respond, it will take five minutes for the Microsoft Exchange EdgeSync service on another Hub Transport server to take over the lease. Forcing EdgeSync synchronization doesn't override this value. This setting determines for how long a Microsoft Exchange EdgeSync service can declare a lease option on an Edge Transport server. If the Microsoft Exchange EdgeSync service holding the lease is unavailable and doesn't restart during this option period, no other Microsoft Exchange EdgeSync service will take over the lease option, unless you force EdgeSync synchronization. This setting determines how frequently the lock field is updated when a Microsoft Exchange EdgeSync service has acquired a lock to an Edge Transport server.

Option duration

1 hour

Lock renewal

1 minute

Preparing to Run the EdgeSync Service


Before you can subscribe your Edge Transport server to your Exchange organization, you must make sure that your infrastructure and your Hub Transport servers are prepared for the EdgeSync service. The following list summarizes the things you need to do to prepare for EdgeSync synchronization:

Verify that the perimeter network firewall that separates the Edge Transport server from the Exchange organization is configured to enable communications through the correct ports. The Edge Transport server uses non-standard LDAP ports. You can modify the ports that are used by AD LDS by using the ConfigureAdam.ps1 script that's provided with Exchange 2010 if your environment requires specific ports. For more information, see Modify AD LDS Configuration. However, don't modify the ports after you create the Edge Subscription. If you modify the ports after you create the Edge Subscription, you must remove the Edge Subscription and then create a subscription. By default, the following LDAP ports are used to access AD LDS: LDAP Port 50389/TCP is used locally to bind to the AD LDS instance. This port doesn't have to be open on the perimeter network firewall. Secure LDAP Port 50636/TCP is used for directory synchronization from Hub Transport servers to AD LDS. This port must be open for successful EdgeSync synchronization. Verify that DNS host name resolution is successful from the Edge Transport server to the Hub Transport servers, and from the Hub Transport servers to the Edge Transport server. License the Edge Transport server. The licensing information for the Edge Transport server is captured when the Edge Subscription is created and is shown in the EMC for the Exchange organization. For subscribed Edge Transport servers to appear as licensed, they must be subscribed to the Exchange organization after the license key is applied on the Edge Transport server. If the license key is applied on the Edge Transport server after you perform the Edge Subscription process, the licensing information isn't updated in the Exchange organization, and you must resubscribe the Edge Transport server. Configure the following settings for propagation to the Edge Transport server role: Internal SMTP servers Use the Set-TransportConfig cmdlet to configure the InternalSMTPServers parameter. This parameter specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. Accepted domains Configure all authoritative domains, internal relay domains, and external relay domains. Remote domains Configure remote domain settings. Return to top

Managing Edge Subscriptions


This section provides background information about various Edge Subscription management tasks. For step-by-step instructions, see Managing Edge Subscriptions.

Adding an Edge Transport Server


You can subscribe one or more Edge Transport servers to a single Active Directory site. If you deploy additional Edge Transport servers in your perimeter network and subscribe them to the same Active Directory site where an Edge Subscription already exists, the following actions occur:

A new Edge Subscription object is created in Active Directory. Additional ESRA accounts are created for each Hub Transport server in the Active Directory site. These accounts are replicated to AD LDS and used by the EdgeSync synchronization process during synchronization with the new server. The new Edge Subscription is added to the source server list of the automatic Send connector to the Internet. Messages submitted to that connector for processing will be load balanced between the subscribed Edge Transport servers. An inbound Send connector from the Edge Transport server to the Exchange organization is automatically created.

EdgeSync synchronization to the Edge Transport server starts. For detailed steps about creating an Edge Subscription, see the following topics:

Create an Edge Subscription File on an Edge Transport Server Import an Edge Subscription File to an Active Directory Site

Adding or Removing a Hub Transport Server


If a Hub Transport server is added to the Active Directory site to which an Edge Transport server is already subscribed, it doesn't automatically participate in the EdgeSync synchronization process. To enable a newly deployed Hub Transport server to participate in the EdgeSync synchronization process, you must resubscribe each Edge Transport server to the Active Directory site. Removing a Hub Transport server from an Active Directory site where an Edge Transport server is subscribed won't affect EdgeSync synchronization, unless that Hub Transport server is the last Hub Transport server in that site. If you remove all Hub Transport servers from the Active Directory site where an Edge Transport server is subscribed, the subscribed Edge Transport servers are orphaned.

Resubscribing an Edge Transport Server


Occasionally you may have to resubscribe an Edge Transport server to an Active Directory site. When the Edge Subscription is re-created, new credentials are generated and the complete Edge Subscription process must be followed. This process is used in the following scenarios:

New Hub Transport servers have been deployed in the subscribed Active Directory site, and you want the new server to participate in EdgeSync synchronization. The license key for the Edge Transport server was applied after the Edge Subscription was created. The licensing information for the Edge Transport server is captured when the Edge Subscription is created and is shown in the EMC for the Exchange organization. For subscribed Edge Transport servers to appear as licensed, they must be subscribed to the Exchange organization after the license key is applied on the Edge Transport server. If the license key is applied on the Edge Transport server after you perform the Edge Subscription process, the licensing information isn't updated in the Exchange organization and you must resubscribe the Edge Transport server. The ESRA credentials are compromised. Important: To resubscribe an Edge Transport server, export a new Edge Subscription file on the Edge Transport server and then import the XML file on a Hub Transport server. You must resubscribe the Edge Transport server to the same Active Directory site to which it was originally subscribed. You don't have to first remove the original Edge Subscription. The resubscription process will overwrite the existing Edge Subscription.

Removing an Edge Subscription


There are some scenarios where you may have to remove an Edge Subscription from the Exchange organization or from both the Exchange organization and the Edge Transport server. If the Edge Transport server will be resubscribed to the Exchange organization, don't remove the Edge Subscription from the Edge Transport server. When you remove the Edge Subscription from an Edge Transport server, all replicated data is deleted from AD LDS. This can take a long time if you have lots of recipient data. The following list provides examples of situations that require you to remove the Edge Subscription.

You no longer want the Edge Transport server to participate in the EdgeSync synchronization process. In this scenario, you must remove the Edge Subscription from both the Edge Transport server and from the Exchange organization. An Edge Transport server is being decommissioned. In this scenario, you must remove the Edge Subscription from the Exchange organization only. If you uninstall the Edge Transport server role from the computer, the AD LDS instance and all Active Directory data that's stored in AD LDS is also removed. You want to change the Active Directory site association for the Edge Subscription. In this scenario, you must remove the Edge Subscription from only the Exchange organization. After the Edge Subscription is removed from the Exchange organization, you can resubscribe the Edge Transport server to a different Active Directory site. When you remove the Edge Subscription from the Exchange organization, the effect is as follows:

Synchronization of information from Active Directory to AD LDS stops. The ESRA accounts are removed from both Active Directory and AD LDS. The computer that has the Edge Transport server role installed is removed from the source server list of any Send connector. The automatic inbound Send connector from the Edge Transport server to the Exchange organization is removed from AD LDS. When you remove the Edge Subscription from an Edge Transport server, the effect is as follows:

You can no longer use the Edge Transport server features that rely on Active Directory data. Replicated data is removed from AD LDS. The tasks that were disabled when the Edge Subscription was created are enabled again to allow for local configuration. For step-by-step instructions about how to remove an Edge Subscription, see Remove an Edge Subscription.

Verifying EdgeSync Results


You can use the Test-EdgeSynchronization diagnostic cmdlet to verify that the edge synchronization is working. This cmdlet provides a report of the synchronization status of subscribed Edge Transport servers. It can be run manually or called by Microsoft System Center Operations Manager 2007. When the task is called by System Center Operations Manager 2007, alerts are generated if an Edge Transport server isn't synchronized.

The output of this cmdlet lets you view which objects haven't been synchronized to the Edge Transport server. The task compares the data that's stored in Active Directory and the data that's stored in AD LDS. Any inconsistencies in data are reported in the results output by this command. You can use the ExcludeRecipientTest parameter with the Test-EdgeSynchronization cmdlet to exclude validation of recipient data synchronization. If you include this parameter, only the synchronization of configuration objects is validated. Validating that recipient data is synchronized will take longer than validating only configuration data. For detailed steps, see Verify EdgeSync Results for a Recipient. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

EdgeSync Replication Data


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The computer that has the Edge Transport server role installed doesn't have access to Active Directory. To perform recipient lookup and safelist aggregation tasks, and to implement domain security by using mutual Transport Layer Security (TLS) authentication, the Edge Transport server requires data that resides in Active Directory. This data is replicated to the Edge Transport server using the EdgeSync process and the Edge Transport server stores all replicated information in Active Directory Lightweight Directory Services (AD LDS). This topic focuses on the data that's replicated from Active Directory to the AD LDS instance on a Microsoft Exchange Server 2010 Edge Transport server when the Edge Transport server is subscribed to an Active Directory site. To learn more about the EdgeSync process and Edge Subscriptions, see Understanding Edge Subscriptions. The following data are replicated from Active Directory to AD LDS:

Edge Subscription information Configuration information Recipient information Topology information The following sections describe these types of data and the way they're used by the Edge Transport server. Looking for management tasks related to managing transport servers? See Managing Transport Servers.

Edge Subscription Information


Exchange 2010 extends both the Active Directory and AD LDS schemas to provide attributes on the ms-Exch-ExchangeServer object to represent the data needed to control the EdgeSync synchronization process. These attributes provide the following three functions that are important to the EdgeSync synchronization process:

They provide automatic provisioning and maintenance of the credentials that are used to help secure the LDAP connection between a Hub Transport server and a subscribed Edge Transport server. They arbitrate the synchronization lock and lease process that makes sure that only one Hub Transport server at a time will try to synchronize with an individual Edge Transport server. For more information about the lock and lease process, see Understanding Edge Subscriptions. They optimize the EdgeSync synchronization process to maintain a record of the current synchronization status and avoid excessive manual synchronization. The following table lists the schema extensions that are specific to Edge Subscriptions. The values assigned to these attributes are maintained by the Edge Subscription and EdgeSync synchronization process. You shouldn't manually edit these attributes by using editing tools, such as Ldp.exe or Active Directory Service Interfaces (ADSI) Edit.

Edge Subscription schema extensions


Attribute name ms-ExchServerEKPKPublicKey ms-ExchEdgeSyncCredential Description

This attribute represents the current public key for the certificate being used by the server. This value is stored by both Edge Transport servers and Hub Transport servers. The public key is used to encrypt the credentials that are used to authenticate the server during LDAP and SMTP communication.

This attribute represents the list of credentials that the Microsoft Exchange EdgeSync service uses to establish an authenticated LDAP session to AD LDS. On Hub Transport servers, this attribute contains only the credentials that the Hub Transport server uses to authenticate to the subscribed Edge Transport servers. On Edge Transport servers, this attribute contains the credentials of each Hub Transport server in the subscribed Active Directory site that participates in the EdgeSync synchronization process. This attribute is only present on Hub Transport servers that run the EdgeSync synchronization process and on subscribed Edge Transport servers. This attribute is used to arbitrate between Hub Transport servers when more than one Hub Transport server tries to replicate to the same Edge Transport server.

ms-ExchEdgeSyncLease ms-ExchEdgeSyncStatus

This attribute is only present in AD LDS on the Edge Transport server object. This attribute tracks the status of replication to an AD LDS instance and includes information about replication.

Configuration Information
When you subscribe an Edge Transport server to the organization, you can manage the configuration objects that are common to the Edge Transport server and the Exchange organization from inside the organization. These changes are then replicated to the Edge Transport server by using the Microsoft Exchange EdgeSync service. This process helps maintain a consistent configuration across all servers involved in message processing. A subset of the configuration data for the Exchange organization must also be maintained on the Edge Transport server. During the EdgeSync synchronization process, the configuration data that the Edge Transport server needs is written to the configuration partition of AD LDS. The configuration data written to AD LDS includes the

following:

Hub Transport servers The fully qualified domain name (FQDN) of each Hub Transport server in the subscribed Active Directory site is made available to the local AD LDS store on the Edge Transport server. This information is used to derive a list of smart host servers for the inbound Send connector. Accepted domains All authoritative, internal relay, and external relay domains configured for the Exchange organization are written to AD LDS. Having the accepted domains available to the Edge Transport server enables the Exchange organization to perform domain filtering and reject invalid SMTP traffic into their organization as early as possible. For more information about accepted domains, see Understanding Accepted Domains. Message classifications If message classifications are available on the Edge Transport server, transport agents and content conversion can act on message classifications in the perimeter network. For example, the Attachment Filter agent can apply the Attachment Removed classification when it removes an attachment. Therefore, informational text will be displayed to a Microsoft Outlook user or a Microsoft Office Outlook Web App user to tell the recipient what happened. Agents that are developed for use by third-party applications can use message classifications in a similar manner. Also, message classifications may have to be translated by the Edge Transport server from a GUID in an X-header to Transport Neutral Encapsulation Format (TNEF) as a localized recipient description. Remote domains All remote domain policies configured for the Exchange organization are written to AD LDS. Remote domain policies control out-of-office message settings and message format settings for a remote domain. For more information about remote domains, see Understanding Remote Domains. Send connectors By default, Send connectors required to enable end-to-end mail flow between the Exchange organization and the Internet are automatically created. Any existing Send connectors on the Edge Transport server are deleted. If you want to configure additional Send connectors, you configure the Send connector inside the Exchange organization and select the Edge Subscription as the source server for the connector. For more information, see Understanding Edge Subscriptions. Internal SMTP servers The value for the InternalSMTPServers attribute is stored on the TransportConfig object for both the Exchange organization and the local Edge Transport server. During the EdgeSync synchronization process, the value that's stored on the local Edge Transport server object is overwritten with the value that's stored on this object for the Exchange organization. This attribute specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. Domain Secure lists The TLSReceiveDomainSecureList and the TLSSendDomainSecureList attributes are stored on the TransportConfig object for both the Exchange organization and the local Edge Transport server. During the EdgeSync synchronization process, the value that's stored on the local Edge Transport server object is overwritten with the value that's stored on this object for the Exchange organization. These attributes specify the list of remote domains that are configured for mutual TLS authentication.

Recipient Information
The recipient information that's replicated to AD LDS includes only a subset of the recipient attributes. Only the data that the Edge Transport server must have to perform certain anti-spam tasks is replicated. The recipient information replicated to AD LDS includes the following:

Recipients The list of recipients in the Exchange organization is replicated to AD LDS. Each recipient is identified by the GUID assigned to it in Active Directory. If you configure a recipient's user account to deny receipt of mail from outside the organization, the recipient isn't replicated to AD LDS. If you disable or delete the mailbox for a recipient, it isn't replicated to AD LDS. Proxy addresses All proxy addresses assigned to each recipient are replicated to AD LDS as hashed data. This is a one-way hash that uses Secure Hash Algorithm (SHA)-256. SHA-256 generates a 256-bit message digest of the original data. Storing proxy addresses as hashed data helps secure this information in case the Edge Transport server or AD LDS is compromised. Proxy addresses are referenced when the Edge Transport server performs the recipient lookup antispam task. Safe Senders List, Blocked Senders List, and Safe Recipients List The Safe Senders Lists, Blocked Senders Lists and Safe Recipients Lists that are defined in each recipient's Outlook instance are aggregated and replicated to AD LDS. These settings are stored on the mailbox store where the recipient's mailbox resides. An Outlook user's safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders List, and external contacts. Having safelist collection data available in AD LDS enables the Edge Transport server to screen senders appropriately, reducing the operational overhead involved with filtering mail. This information is sent as hashed data. Important: Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the AD LDS instance on the Edge Transport server, the content filtering functionality doesn't act on safe recipient data. Per recipient anti-spam settings By using the Set-Mailbox cmdlet, you can assign anti-spam threshold settings per recipient that differ from the organizationwide anti-spam settings. If you configure per recipient anti-spam settings, these settings override the organization-wide settings. By replicating these settings to AD LDS, the per recipient settings can be considered before the message is relayed to the Exchange organization. This information is sent as hashed data.

Topology Information
The topology information includes notification of newly subscribed Edge Transport servers or removed Edge Subscriptions. This data is refreshed every five minutes.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Edge Subscription Credentials


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 This topic explains how the Edge Subscription process provisions the credentials that are used to help secure the EdgeSync synchronization process in Microsoft Exchange Server 2010 and how the Microsoft Exchange EdgeSync service uses those credentials to establish a secure LDAP connection between a Hub Transport server and an Edge Transport server. To learn more about the Edge Subscription process, see Understanding Edge Subscriptions. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Edge Subscription Process EdgeSync Replication Accounts Authenticating Initial Replication Authenticating Scheduled Synchronization Sessions Renewing EdgeSync Replication Accounts

Edge Subscription Process

The Edge Transport server is subscribed to an Active Directory site to establish a synchronization relationship between the Hub Transport servers in an Active Directory site and the subscribed Edge Transport server. The credentials that are provisioned during the Edge Subscription process are used to help secure the LDAP connection between a Hub Transport server and an Edge Transport server in the perimeter network. When you run the New-EdgeSubscription cmdlet in the Exchange Management Shell on an Edge Transport server, the EdgeSync bootstrap replication account (ESBRA) credentials are created in the Active Directory Lightweight Directory Services (AD LDS) directory on the local server and then written to the Edge Subscription file. These credentials are used only to establish the initial synchronization and will expire 1,440 minutes (24 hours) after the Edge Subscription file is created. If the Edge Subscription process isn't completed within that time, you must run the New-EdgeSubscription cmdlet in the Shell on the Edge Transport server again to create an Edge Subscription file. The following table describes the data contained in the Edge Subscription XML file.

Edge Subscription file contents


Subscription data EdgeServerName EdgeServerFQDN Description The NetBIOS name of the Edge Transport server. The name of the Edge Subscription in Active Directory will match this name. The fully qualified domain name (FQDN) of the Edge Transport server. The Hub Transport servers in the subscribed Active Directory site must be able to locate the Edge Transport server by using Domain Name System (DNS) to resolve the FQDN. The public key of the Edge Transport server's self-signed certificate. The name assigned to the ESBRA. The ESBRA account has the following format: ESRA.Edge Transport server name. ESRA means EdgeSync replication account. The password assigned to the ESBRA. The password is generated by using a random number generator and is stored in the Edge Subscription file in clear text. The creation date of the Edge Subscription file. The length of time that these credentials will be valid before they expire. The ESBRA account is valid for only 24 hours. The secure LDAP port to which the EdgeSync service binds when synchronizing data from Active Directory to AD LDS. By default, this is TCP port 50636. The licensing information for the Edge Transport server. After an Edge Transport server is subscribed to Active Directory, the licensing information about the Edge Transport server is displayed in the Exchange Management Console for the Exchange organization. You must license the Edge Transport server before you create the Edge Subscription for this information to be displayed correctly. The version number of the Edge Subscription file. The version of Exchange Server that is installed on the Edge Transport server.

EdgeCertificateBlob ESRAUsername

ESRAPassword

EffectiveDate Duration AdamSslPort

ProductID

VersionNumber SerialNumber Important:

The ESBRA credentials are written to the Edge Subscription file in clear text. You must protect this file throughout the subscription process. After the Edge Subscription file is imported to your Exchange organization, you should immediately delete the Edge Subscription file from the Edge Transport server, the network

share you used to import the file to your Exchange organization, and any removable media. Return to top

EdgeSync Replication Accounts


EdgeSync replication accounts (ESRA) are an important part of EdgeSync security. Authentication and authorization of the ESRA is the mechanism used to help secure the connection between an Edge Transport server and a Hub Transport server. The ESBRA contained in the Edge Subscription file is used to establish a secure LDAP connection during the initial synchronization. After the Edge Subscription file is imported to a Hub Transport server in the Active Directory site to which the Edge Transport server is being subscribed, additional ESRA accounts are created in Active Directory for each Edge Transport-Hub Transport server pair. During initial synchronization, the newly created ESRA credentials are replicated to AD LDS. These ESRA credentials are used to help secure later synchronization sessions. Each EdgeSync replication account is assigned the properties described in the following table.

Ms-Exch-EdgeSyncCredential properties
Property name TargetServerFQDN SourceServerFQDN EffectiveTime ExpirationTime UserName Password Type String String DateTime (UTC) DateTime (UTC) String Byte Description The Edge Transport server that will accept these credentials. The Hub Transport server that will present these credentials. This value is empty if the credential is the bootstrap credential. When to start using this credential. When to stop using this credential. The user name that's used to authenticate. The password that's used to authenticate. The password is encrypted by using ms-Exch-EdgeSync-Certificate.

The following sections of this topic describe how the ESRA credentials are provisioned and used during the EdgeSync synchronization process.

Provisioning the EdgeSync Bootstrap Replication Account


When the New-EdgeSubscription cmdlet is run on the Edge Transport server, the ESBRA is provisioned as follows:

A self-signed certificate (Edge-Cert) is created on the Edge Transport server. The private key is stored in the local computer store and the public key is written to the Edge Subscription file. The ESBRA (ESRA.Edge) is created in AD LDS, and the credentials are written to the Edge Subscription file. The Edge Subscription file is exported by copying it to removable media. The file is now ready to import to a Hub Transport server.

Provisioning EdgeSync Replication Accounts in Active Directory


When the Edge Subscription file is imported on a Hub Transport server, the following steps occur to establish a record of the Edge Subscription in Active Directory and to provision additional ESRA credentials.

1. An Edge Transport server configuration object is created in Active Directory. The Edge-Cert certificate is written to this object as an attribute. 2. Every Hub Transport server in the subscribed Active Directory site receives an Active Directory notification that a new Edge Subscription has been registered. As soon as the notification is received, each Hub Transport server retrieves the ESRA.Edge account and encrypts the account by using the Edge-Cert public key. The encrypted ESRA.Edge account is written to the Edge Transport server configuration object. 3. Each Hub Transport server creates a self-signed certificate (Hub-Cert). The private key is stored in the local computer store and the public key is stored in the Hub Transport server configuration object in Active Directory. 4. Each Hub Transport server encrypts the ESRA.Edge account by using the public key of its own Hub-Cert certificate and then stores it in its own configuration object. 5. Each Hub Transport server generates an ESRA for each existing Edge Transport server configuration object in Active Directory (ESRA.Hub.Edge). The account name is generated by using the following naming convention: ESRA.<Hub Transport server NetBIOS Name>.<Edge Transport server NetBIOS Name>.<Effective Date UTC Time> Example: ESRA.Hub.Edge.01032010 The password for ESRA.Hub.Edge is generated by a random number generator and is encrypted by using the public key of the Hub-Cert certificate. The generated password has the maximum length allowed for Microsoft Windows Server. 6. Each ESRA.Hub.Edge account is encrypted by using the public key of the Edge-Cert certificate and is stored on the Edge Transport server configuration object in Active Directory. The following sections of this topic explain how these accounts are used during the EdgeSync synchronization process. Return to top

Authenticating Initial Replication


The ESBRA account, ESRA.Edge, is used only when establishing the initial synchronization session. During the first EdgeSync synchronization session, the additional ESRA accounts, ESRA.Hub.Edge, are replicated to AD LDS. These accounts are used to authenticate later EdgeSync synchronization sessions.

The Hub Transport server that performs the initial replication is determined randomly. The first Hub Transport server in the Active Directory site to perform a topology scan and discover the new Edge Subscription performs the initial replication. Because this discovery is based on the timing of the topology scan, any Hub Transport server in the site may perform the initial replication. The Microsoft Exchange EdgeSync service initiates a secure LDAP session from the Hub Transport server to the Edge Transport server. The Edge Transport server presents its self-signed certificate and the Hub Transport server verifies that the certificate matches the certificate that's stored on the Edge Transport server configuration object in Active Directory. After the Edge Transport server's identity is verified, the Hub Transport server provides the credentials of the ESRA.Edge account to the Edge Transport server. The Edge Transport server verifies the credentials against the account that's stored in AD LDS. The Microsoft Exchange EdgeSync service on the Hub Transport server then pushes the topology, configuration, and recipient data from Active Directory to AD LDS. The change to the Edge Transport server configuration object in Active Directory is replicated to AD LDS. AD LDS receives the newly added ESRA.Hub.Edge entries and the Microsoft Exchange Credential Service creates the corresponding AD LDS account. These accounts are now available to authenticate later scheduled EdgeSync synchronization sessions.

Microsoft Exchange Credential Service


The Microsoft Exchange Credential Service is part of the Edge Subscription process. It runs only on the Edge Transport server. This service creates the reciprocal ESRA accounts in AD LDS so that a Hub Transport server can authenticate to an Edge Transport server to perform EdgeSync synchronization. The Microsoft Exchange EdgeSync service doesn't communicate directly with the Microsoft Exchange Credential Service. The Microsoft Exchange Credential Service communicates with AD LDS and installs the ESRA credentials whenever the Hub Transport server updates them. Return to top

Authenticating Scheduled Synchronization Sessions


After initial EdgeSync synchronization finishes, the EdgeSync synchronization schedule is established and data that has changed in Active Directory is regularly updated in AD LDS. A Hub Transport server initiates a secure LDAP session with the AD LDS instance on the Edge Transport server. AD LDS proves its identity to that Hub Transport server by presenting its self-signed certificate. The Hub Transport server presents its ESRA.Hub.Edge credentials to AD LDS. The ESRA.Hub.Edge password is encrypted by using the Hub Transport server's self-signed certificate's public key. This means that only that particular Hub Transport server can use those credentials to authenticate to AD LDS. Return to top

Renewing EdgeSync Replication Accounts


The password for the ESRA account must comply with the local server's password policy. To prevent the password renewal process from causing temporary authentication failure, a second ESRA.Hub.Edge account is created seven days before the first ESRA.Hub.Edge account expires with an effective time that's three days before the first ESRA expiration time. As soon as the second ESRA account becomes effective, EdgeSync stops using the first account and starts to use the second account. When the expiration time for the first account is reached, those ESRA credentials are deleted. This renewal process will continue until the Edge Subscription is removed. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Edge Transport Server Cloned Configuration


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 The Microsoft Exchange Server 2010 Edge Transport server role stores its configuration information in Active Directory Lightweight Directory Services (AD LDS). You can install more than one Edge Transport server in the perimeter network and use Domain Name System (DNS) round robin, a simple mechanism that's used by DNS servers to share and distribute loads for network resources, to help balance network traffic among the Edge Transport servers. To make sure that all Edge Transport servers that you deploy are using the same configuration information, you can use the provided cloned configuration scripts in the Exchange Management Shell to duplicate the configuration of a source server to a target server. You use cloned configuration to deploy new Edge Transport servers based on a configured source server. The configuration information for the source server is duplicated and then exported to an XML file. The XML file is then imported to the target server. This topic provides an overview of the cloned configuration process. For detailed steps about configuring your Edge Transport servers using cloned configuration, see Configure Edge Transport Server Using Cloned Configuration.

Cloned Configuration and EdgeSync


Run the EdgeSync process after you import the cloned configuration. To perform recipient lookup and message security tasks, the computer that has the Edge Transport server role installed requires data that resides in Active Directory. EdgeSync is a collection of processes that are run on a computer that has the Hub Transport server role installed to establish one-way replication of recipient and configuration information from Active Directory to the AD LDS instance on an Edge Transport server. The Microsoft Exchange EdgeSync service copies only the information that's required for the Edge Transport server to perform anti-spam tasks and the information about the connector configuration that's required to enable end-to-end mail flow. The Microsoft Exchange EdgeSync service performs scheduled updates so that the information in AD LDS remains current. Cloned configuration doesn't duplicate the Edge Subscription settings of a server. The certificates that are used by the Microsoft Exchange EdgeSync service aren't cloned. You must run the EdgeSync process separately for each Edge Transport server. The Microsoft Exchange EdgeSync service overwrites any settings that are included in both cloned configuration information and in EdgeSync replication information. These settings include Send connectors, Receive connectors, accepted domains, and remote domains.

Cloned Configuration Process


The cloned configuration process consists of three steps:

1. Export the configuration on the source server. In this step, you run the ExportEdgeConfig.ps1 script to export the source server's configuration information to an intermediate XML file. 2. Validate the configuration on the target server. In this step, you run the ImportEdgeConfig.ps1 script. This script checks the existing information in the intermediate XML file to see whether the settings that were exported are valid for the target server and then creates an answer file. The answer file specifies the server-specific information that's used during the next step when you import the configuration on the target server. The answer file contains entries for each source server setting that isn't valid for the target server. You can modify these settings so that they're valid for the target server. If all settings are valid, the answer file contains no entries. 3. Import the configuration on the target server. In this step, the ImportEdgeConfig.ps1 script uses the intermediate XML file and the answer file to clone an existing configuration or to restore the server to a specific configuration. These steps are described in detail in the following sections.

Step 1: Export the Configuration


After you install and configure the Edge Transport server role, run the ExportEdgeConfig.ps1 script. This script retrieves the source server's configuration information and stores the information in an intermediate XML file. The following information is exported from the source server and stored in the intermediate XML file:

Transport server-related information and log file path information. The following file paths are exported: ReceiveProtocolLogPath SendProtocolLogPath MessageTrackingLogPath PickupDirectoryPath RoutingTableLogPath Transport agent-related information that includes the status and priority settings of each transport agent. All Send connector-related information. If any Send connectors are configured to use credentials, the password is written to the intermediate XML file as an encrypted string. You can use the -key parameter with the ImportEdgeConfig.ps1 and ExportEdgeConfig.ps1 scripts to specify the 32-byte string to use for password encryption and decryption. If you don't use the -key parameter, a default encryption key is used. Receive connector-related information. To modify the local network binding and port properties, you must modify the configuration information in the answer file that's created in the validate configuration step. Accepted domain configuration. Remote domain configuration. Anti-spam features configuration settings. The following information is exported: IP Allow list information. Only the IP Allow list entries that were manually configured by the administrator are exported. IP Block list information. Content filter configuration. Recipient filter configuration.

Address rewrite entries. Attachment filter entries.

Step 2: Validate the Configuration


The target server is an Exchange 2010 server that has a clean installation of the Edge Transport server role. Run the ImportEdgeConfig.ps1 script on the target server to validate the existing information in the intermediate XML file and to create the answer file. The answer file specifies the server-specific information that's used during the next step in the cloned configuration process when you import the configuration on the target server. The answer file contains entries for each source server setting that isn't valid for the target server. You can modify these settings so that they're valid for the target server. If all settings are valid, the answer file contains no entries. The intermediate XML file can be used for different target servers. The answer file is specific to a target server. The ImportEdgeConfig.ps1 script performs the following tasks during this step:

The script verifies that the data paths and log paths can be created on the target server. If the paths can't be created, a blank path is inserted into the answer file. For each Send connector in the XML file, the script adds a blank entry for the source IP address in the answer file. For each Receive connector in the XML file, the script adds a blank entry for the local network bindings in the answer file. You must manually modify the answer file to provide the following information about server-specific settings:

Fill in the data paths and log paths. If these paths are left blank in the answer file, the paths that are configured in the intermediate XML file are used in the next step when you import the configuration on the target server. For each Send connector entry, fill in the source IP address. If this field is left blank, an error occurs in the import configuration step. For each Receive connector entry, fill in the local network bindings. If the local network bindings are left blank, an error occurs in the next step when you import the configuration on the target server.

Step 3: Import the Configuration


Perform this step on any target server to clone the configuration of an existing Edge Transport server or to restore the server to a specific configuration. Run the ImportEdgeConfig.ps1 script to validate and import the new configuration. After you run this script, the target server's configuration matches the settings in the intermediate XML file and the answer file. Important: It's a best practice to back up the existing server configuration before you run the import configuration process, so that if the cloning operation fails, the server can be restored to the previous stable state. This step uses the server-specific information that's provided in the answer file. If a setting isn't specified in the answer file, the data in the intermediate XML file is used. Before the script modifies the configuration, the script validates the data in the intermediate XML file and the answer file. The following configuration settings of the target server are modified during the import configuration step:

The transport agent configuration is modified. The existing connectors on the target server are removed, and the connectors that are present in the intermediate XML file are added. The existing accepted domains are removed, and the accepted domain entries in the intermediate XML file are added. The existing remote domains are removed, and the remote domain entries in the intermediate XML file are added. The existing IP Allow list entries are removed, and the IP Allow list entries in the intermediate remote domains file are added. The existing IP Block list entries are removed, and the IP Block list entries in the intermediate remote domains file are added. The following anti-spam configuration is cloned to the target server: Content filter configuration Recipient filter configuration Address rewrite entries Attachment filter entries

Transport Configuration Information


The settings of the transport configuration object define server-wide e-mail transport settings for an Edge Transport server. When you import the intermediate XML file to the target server, all the settings of the transport configuration object except for the following are imported:

General names and creation dates from the exported XML file Send connector information Receive connector information Attachment filter entries The MaxDumpsterSizePerStorageGroup attribute entry After the import process is complete, you may also configure the settings by using the Set-TransportConfig cmdlet. For more information, see Set-TransportConfig. The following table describes the attributes that are associated with the transport configuration object and the default values. You configure this object on both Hub Transport servers and Edge Transport servers. However, many attributes apply only to Hub Transport servers and configuring those attributes on an Edge Transport server will have no effect.

Transport configuration attributes and default values


Attribute Description Default value

ClearCategories GenerateCopyOfDSNFor

This attribute specifies whether to clear Microsoft Office Outlook categories during content conversion. This attribute specifies the delivery status notification (DSN) codes that cause the DSN message to be copied to the postmaster e-mail address. DSN codes are entered as x.y.z and are separated by commas.

True 5.4.8, 5.4.6, 5.4.4, 5.2.4, 5.2.0, 5.1.4 Null

InternalSMTPServers

This attribute specifies a list of internal SMTP server IP addresses or IP address ranges that should be ignored by Sender ID and connection filtering. This attribute specifies the e-mail address to which journal reports are sent if the journaling mailbox is unavailable. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum size of the transport dumpster on a Hub Transport server. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies how long an e-mail message should remain in the transport dumpster on a Hub Transport server. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum message size that can be received by recipients in the organization. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum number of recipients that are allowed in a single e-mail message. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the maximum message size that can be sent by senders in the organization. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies the remote domains that will use mutual Transport Layer Security (TLS) authentication through Receive connectors configured to support Domain Security. Multiple domains may be separated by commas. The wildcard character (*) isn't supported in the domains that are listed in this attribute. This attribute specifies the remote domains that will use mutual TLS authentication when e-mail is sent through a Send connector configured to support Domain Security and the address space of the target domain. Multiple domains may be separated by commas. The wildcard character (*) isn't supported in the domains that are listed in this attribute. This attribute verifies that e-mail clients that are submitting messages from mailboxes on Mailbox servers are using encrypted MAPI submission. This attribute doesn't apply to the configuration of an Edge Transport server. The valid values for this attribute are $true or $false. This attribute specifies whether Unified Messaging voice mail is journaled by the Journaling agent. This attribute doesn't apply to the configuration of an Edge Transport server. This attribute specifies whether Xexch50 authentication should be enabled for backward compatibility with Exchange Server 2003 servers.

JournalingReportNdrTo

Null

MaxDumpsterSizePerStorageGroup

18 MB

MaxDumpsterTime

7.00:00:00

MaxReceiveSize

10 MB

MaxRecipientEnvelopeLimit

5,000

MaxSendSize

10 MB

TLSReceiveDomainSecureList

Null

TLSSendDomainSecureList

Null

VerifySecureSubmitEnabled

False

VoicemailJournalingEnabled

True

Xexch50Enabled

True

Note: If the Edge Transport server is subscribed to the Exchange organization later, the value of the InternalSMTPServers attribute is overwritten during the EdgeSync process. For more information, see Understanding Edge Subscriptions.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding the EdgeTransport.exe.Config File


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-11-09 The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. By default, it's located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted. The default value is enforced if either of the following conditions is true:

A configuration option is missing. A configuration option is present and contains the default value. The following example shows the typical structure of the EdgeTransport.exe.config file: <configuration> <runtime> <gcServer enabled="true" /> </runtime> <appSettings> <add key="Configuration Option" value="Value" /> ... </appSettings> </configuration> You can add new configuration options or modify existing configuration options in the <appSettings> section.

Note: The parameter names in the <add key=../> section are case sensitive. 2010 Microsoft Corporation. All rights reserved.
2013 Microsoft. All rights reserved.

Understanding Exchange 2010 Support for X.400 Authoritative Domains


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-18 This topic describes the support that Microsoft Exchange Server 2010 provides for X.400 domains. Exchange 2010 enables the configuration of one or more X.400 authoritative domain namespaces by using Exchange Management Shell commands. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents X.400 Addresses Configuring X.400 Authoritative Domains Recipient Resolution and Routing for X.400 Authoritative Domains

X.400 Addresses

An X.400 address is an address that's defined as part of a suite of e-mail standards that are defined by International Telecommunication Union - Telecommunication [Standardization Sector] (ITU-T) recommendations. An X.400 address uses a hierarchical naming system and consists of a series of attributes, the sum of which form the X.400 address. Some attributes in the address specify the organization. Other attributes specify the recipient. The sum of all the organizational attributes specifies a unique node in the X.400 address hierarchy. Exchange 2010 doesn't support the following X.400 scenarios:

Sharing an X.400 address node with another e-mail system. In Exchange 2010, you can share an SMTP domain namespace by configuring an internal relay accepted domain. You can't use this configuration for an X.400 namespace. Exchange 2010 must be authoritative for the X.400 domain. Alternatively, the X.400 domain must be configured as an external relay subdomain of an authoritative X.400 domain. Configuring an X.400 authoritative domain on the Edge Transport server. Configuring an X.400 authoritative domain in the Exchange Management Console. You must use the Shell to configure X.400 authoritative domains. Routing or relaying directly to an X.400 message transfer agent (MTA). Exchange 2010 must route through a source server that's running Microsoft Exchange Server 2003 and hosting an X.400 connector, or through a third-party Exchange 2010 X.400 connector. Return to top

Configuring X.400 Authoritative Domains


You configure an X.400 authoritative domain on the Hub Transport server role. When an organization is configured as authoritative for a particular domain, it's assumed that the organization hosts all the mailboxes for recipients in that domain. After you create an X.400 authoritative domain name, you can create an e-mail address policy that specifies that domain in the e-mail proxy address. The Exchange organization accepts e-mail that's addressed to recipients who have been assigned an X.400 e-mail proxy address that uses the X.400 authoritative domain namespace. Any X.400 recipient addresses in the authoritative namespace that don't resolve to a mailbox or a contact in Active Directory are treated as an error and cause messages to result in a non-delivery report (NDR). If the message that causes the error is a delivery status notification (DSN), such as an NDR, it's deleted. Exchange 2010 supports non-authoritative X.400 domains if they're a subdomain of an authoritative domain. You use the X400ExternalRelay parameter of the NewX400AuthoritativeDomain cmdlet to define any exceptions where the Exchange organization isn't authoritative for a subdomain of the authoritative X.400 domain. By default, the value of the X400ExternalRelay parameter is set to $false. Therefore, a recipient resolution failure for an e-mail message that's sent to a recipient in the X.400 subdomain results in an NDR. If the value of the X400ExternalRelay parameter is set to $true, Exchange doesn't treat recipient resolution failures as an error and routes messages that are addressed to a recipient in the X.400 subdomain to an external address.

Defining an X.400 Namespace


By default, when you configure an X.400 authoritative domain, the Exchange organization is considered authoritative for all X.400 addresses in the hierarchy. An X.400 address consists of a series of attributes that define organizational components and specify recipients. The X.400 namespace that's specified in the X400DomainName parameter can only include the X.400 organizational components. The following table lists the attributes that you can use to define an X.400 domain namespace in Exchange 2010. The attributes are listed in hierarchical order.

X.400 organizational components


Attribute abbreviation Organizational component Required/Optional Maximum character length 2

Country The value of the Country attribute is the two-letter country/region designation from International Organization for Standardization (ISO) 3166. This attribute identifies the country or region of the X.400 domain

Required

namespace. A ADMD The value of the Administration Management Domain (ADMD) typically identifies a public mail service provider. Valid values are decided on a country or regional basis. PRMD The value of the Private Management Domain (PRMD)defines the top level domain in the namespace of the Exchange organization. Organization The value of the Organization attribute is unique within the context of the PRMD or of the ADMD if there is no PRMD. Organizational unit 1 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 2 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 3 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Organizational unit 4 The value of each organizational unit identifies a unique address element within the scope of the immediately superior address element in the hierarchy. Required 16

Optional

16

Optional

64

OU1

Optional

64

OU2

Optional

64

OU3

Optional

64

OU4

Optional

64

When you specify the X.400 namespace, the address attributes must be separated by semicolons and the address must be enclosed in quotation marks ("), as in the following example.

"C=US;A=ATT;P=Contoso;O=Example"

X.400 domain names can only include the following ASCII characters:

A to Z a to z 09 These punctuation and special characters: (space) ' () + , - . / : = ? The inclusion of a wildcard character, such as an asterisk (*), isn't supported in the X.400 authoritative namespace. Each attribute can appear only one time in the X.400 namespace. Any address in the hierarchy that's subordinate to the defined organizational components must resolve to a recipient or contact in Active Directory, unless an exception has been defined for a subdomain by specifying the X400ExternalRelay parameter as $true. If the categorizer can't resolve a recipient, an NDR is generated for a message. If the message is a DSN, it's deleted. For example, if you've configured an X.400 authoritative domain as "C=US;A=ATT;O=Contoso", the Exchange organization is also considered authoritative for the X.400 namespace "C=US;A=ATT;O=Contoso;OU1=Tailspin Toys". If all the recipients for Tailspin Toys are located in another organization, each of those recipients must be represented as a contact in the Active Directory of the Contoso organization. If you can't do this, the Tailspin Toys namespace must be defined as an external relay subdomain. Return to top

Recipient Resolution and Routing for X.400 Authoritative Domains


To determine how to handle routing of e-mail messages, the Exchange 2010 categorizer compares the recipient addresses to the list of domains for which the Exchange organization is authoritative. This enables the categorizer to determine when to route an X.400 addressed message to an external system and when to generate an NDR for a message if the recipient isn't found in the authoritative namespace. If a message is being sent to a recipient address in an X.400 domain for which the Exchange organization is authoritative, the message is delivered to valid recipients, In addition, an NDR is returned to the sender for any recipient that doesn't appear in Active Directory. If a message is being sent to an X.400 domain for which the Exchange organization isn't authoritative, the message is routed externally through an X.400 connector. After an X.400 authoritative namespace has been defined, the Exchange organization is assumed to be responsible for message delivery to all recipients that have email proxy addresses that match the namespace. Therefore, X.400 addressed messages that are received by an Exchange 2010 Hub Transport server are processed as follows:

If the recipient address resolves to a recipient in Active Directory, the message is delivered. An NDR is returned to the sender if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address matches an X.400 namespace for which Exchange is authoritative. The e-mail is a message. The e-mail is deleted if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address matches an X.400 namespace for which Exchange is authoritative. The e-mail is a DSN. The e-mail is routed to an X.400 connector if all the following conditions are true: The recipient address doesn't resolve to a recipient in Active Directory. The recipient address doesn't match an X.400 namespace for which Exchange is authoritative. The e-mail is routed to an X.400 connector. Although you can configure recipients to receive e-mail that's addressed to an X.400 namespace, Exchange 2010 doesn't provide native transport support for X.400. To

send or receive X.400 e-mail messages to or from remote X.400 domains, you must maintain one or more X.400 connectors on an Exchange 2003 server, or configure a Foreign connector to the X.400 backbone. Exchange 2010 doesn't have an X.400 MTA. Therefore, Exchange 2010 can't convert messages to the X.400 format. An X.400 connector that's hosted on an Exchange 2003 server or a Foreign connector must process the message so that conversion to an X.400 message occurs. To transport X.400 messages, Exchange 2010 routes the message over SMTP as a MIME-encapsulated Transport Neutral Encapsulation Format (TNEF) message. For more information about how to create an X.400 connector on Exchange 2003, see How to Create an X.400 Connector. For more information about how to create a Foreign connector, see Create a Foreign Connector. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Foreign Connectors


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-01-26 A Foreign connector can only be installed on a computer that's running Microsoft Exchange Server 2010 and that has the Hub Transport server role installed. A Foreign connector uses a Drop directory to send messages to a local messaging server that doesn't use SMTP as its primary transport mechanism.

Overview of Foreign Connectors


Exchange 2010 Hub Transport servers require Foreign connectors to deliver messages to foreign gateway servers that don't use SMTP to transmit messages. Thirdparty fax gateway servers are examples of foreign gateway servers. A Foreign connector controls outbound connections from the Hub Transport server to the foreign gateway server. The outbound messages are put in a Drop directory on the Hub Transport server or in a network file share on a remote server. Each Foreign connector uses its own Drop directory. The foreign gateway server must be configured to obtain messages from the Drop directory that's specified for that Foreign connector. Foreign connectors that are created on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in the organization. In Active Directory, a Foreign connector is created as an object in the connections container. When a Hub Transport server in the organization routes messages to an address space configured on a Foreign connector, the message is delivered to a source Hub Transport server for that Foreign connector to be relayed to the destination domain. You can specify several different Hub Transport servers in your organization as source servers for a Foreign connector. This provides fault tolerance for the Foreign connector. If a Hub Transport server that contains the Foreign connector is unavailable, the messages that are destined for the Foreign connector's address space are relayed by using any of the other defined and available Hub Transport servers. To provide this fault tolerance, you must make sure that the Drop directory that's specified by the Foreign connector is accessible by all Hub Transport servers that are designated as source servers for that Foreign connector. Foreign gateway servers can send messages into the Exchange 2010 organization by using the Replay directory that exists on the Hub Transport server. Correctly formatted e-mail message files that you copy to the Replay directory are submitted for delivery. For more information about the Replay directory, see Understanding the Pickup and Replay Directories.

Defining the Usage of a Foreign Connector by Using Address Spaces and Connector Scope
The address space for a Foreign connector specifies the recipient domains to which the Foreign connector will route e-mail. You can specify SMTP address spaces or non-SMTP address spaces. In Exchange 2010, the complete syntax for specifying an address space is as follows.

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

You can use the scope of a Foreign connector to control the visibility of the Foreign connector within the Exchange organization. By default, all Foreign connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Foreign connector so that it's only usable by other Hub Transport servers that exist in the same Active Directory site. The connector scope is specified by using the IsScopedConnector parameter in the New-ForeignConnector cmdlet or the Set-ForeignConnector cmdlet. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization. When the value of this parameter is $true, the connector can only be used by Hub Transport servers in the same Active Directory site.

Foreign Connector DSN Handling


When a message is sent with a delivery confirmation request to an address that's serviced by a Foreign connector, the sender should be notified if the recipient's messaging server can't correctly process the delivery confirmation request. A Relayed delivery status notification (DSN) notifies the sender that the recipient's messaging system is unable to forward delivery confirmation requests. By default, Relayed DSN messages aren't generated for messages sent to the address spaces that are serviced by a Foreign connector. DSN messages are defined in RFC 1894. For more information about DSN messages, see Managing Delivery Status Notifications.

Delivery Agent Connectors


Exchange 2010 introduces a new feature called Delivery Agent connector, which is also used to route messages to foreign systems that don't use the SMTP protocol. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management of Foreign connectors, thereby eliminating the need for storing messages on the file system in a Drop directory. They provide greater control over the message delivery to the foreign systems. To learn more, see Understanding Delivery Agents.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Group Metrics


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-07-07 Group metrics is the collection of the following data about distribution groups and dynamic distribution groups in your organization:

Number of members Number of members who are external to your organization Group metrics data is used to support MailTips in Microsoft Exchange Server 2010. MailTips are informative messages displayed to senders while they're composing messages. For more information about MailTips, including a full list of MailTips available in Exchange 2010, see Understanding MailTips. Group metrics data is used when deciding whether to display the following MailTips:

Large Audience This MailTip is displayed when a sender adds a distribution group whose membership count is considered a large audience as configured in your organization. By default, any message addressed to more than 25 recipients is considered a large audience. External Recipients This MailTip is displayed when a sender adds a distribution group that has members who are external to your organization. Determining these characteristics of distribution groups and dynamic distribution groups isn't a simple task. MailTips are evaluated every time a recipient is added to a message composed by a user. Calculating this information while senders compose messages isn't feasible because it would delay the display of MailTips, and it could have an adverse performance impact depending on the size of your organization. To provide this valuable information to senders without an adverse performance impact, Exchange calculates group metrics data as a background process that can be scheduled to run during nonbusiness hours. When evaluating recipients for MailTips, Exchange reads the group metrics data. Looking for management tasks related to MailTips? See Managing MailTips.

Group Metrics Generation and Distribution


By default, group metrics data is generated on the same Mailbox server that generates the offline address book (OAB). This is the case even if you explicitly disable group metrics generation on that server using the Set-MailboxServer cmdlet. The Mailbox server generates full group metrics data for all distribution groups and dynamic distribution groups every Sunday, and incremental updates for any groups that were modified since the last full generation. The day of the full group metrics data generation is fixed, but you can configure the time it's generated daily. By default, group metrics data is generated daily at a random time within two hours of midnight. The following files are associated with group metrics:

GroupMetrics-<date>T<time>.bin This binary file is the main group metrics data file. It contains the membership and external members count for all distribution groups and dynamic distribution groups in your organization. The date and time sections of the file name are separated by hyphens. For example, a group metrics data file created on January 18, 2010 at 20:00 (8:00 P.M.) has the following file name: GroupMetrics-2010-01-18T20-00-00.bin. GroupMetrics-<servername>.xml This XML file contains information about the Mailbox server configured to generate the group metrics data. This file is required by the Microsoft Exchange File Distribution service, and it points to the binary file that needs to be distributed. ChangedGroups.txt This file contains the list of groups that were updated the last time group metrics data was generated. Group metrics data won't be generated by default in the following scenarios:

You don't use OABs in your organization, or you use only public folders for OAB distribution. The server responsible for OAB generation is a server running Microsoft Exchange Server 2007 with the Mailbox server role installed. If any of these scenarios apply to you, you must configure an Exchange 2010 Mailbox server manually to start generating group metrics. For detailed steps, see Configure Group Metrics. The group metrics data is distributed to the Client Access servers using the Microsoft Exchange File Distribution service. The Microsoft Exchange File Distribution service queries Active Directory for a list of Mailbox servers that have group metrics generation enabled, and then copies the group metrics data from the closest Mailbox server every eight hours.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Header Firewall


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-27 In Microsoft Exchange Server 2010, header firewall is a mechanism that removes specific header fields from inbound and outbound messages. Computers that are running Exchange 2010 that have the Hub Transport server role or the Edge Transport server role installed insert custom X-header fields into the message header. An X-header is a user-defined, unofficial header field that exists in the message header. X-headers aren't specifically mentioned in RFC 2822, but the use of an undefined header field starting with X- has become an accepted way to add unofficial header fields to a message. Messaging applications, such as anti-spam, antivirus, and messaging server applications may add their own X-headers to a message. X-header fields are usually preserved but ignored by messaging servers and clients that don't use them. The X-header fields contain details about the actions that are performed on the message by the transport server, such as the spam confidence level (SCL), content filtering results, and rules processing status. Revealing this information to unauthorized sources could pose a potential security risk. Header firewall prevents the spoofing of these X-headers by removing them from inbound messages that enter the Exchange organization from untrusted sources. Header firewall prevents the disclosure of these X-headers by removing them from outbound messages that will go to untrusted destinations outside the Exchange organization. Header firewall also prevents the spoofing of standard routing headers that are used to track the routing history of a message. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010 Header Firewall for Organization X-Headers and Forest X-Headers Header Firewall for Routing Headers Header Firewall and Earlier Versions of Exchange

Custom Organization X-Headers and Forest X-Headers That Are Used in Exchange 2010

Organization X-headers start with X-MS-Exchange-Organization-. Forest X-headers start with X-MS-Exchange-Forest-. The following table describes some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 organization.

Some of the organization X-headers and forest X-headers that are used in messages in an Exchange 2010 organization
X-header X-MS-ExchangeForestRulesExecuted X-MS-ExchangeOrganizationAntispam-Report X-MS-ExchangeOrganizationAuthAs X-MS-ExchangeOrganizationAuthDomain X-MS-ExchangeOrganizationAuthMechanism X-MS-ExchangeOrganizationAuthSource X-MS-ExchangeOrganizationJournal-Report X-MS-ExchangeOrganizationOriginalArrivalTime X-MS-ExchangeDescription This X-header lists the transport rules that were performed on the message.

This X-header is a summary report of the anti-spam filter results that have been applied to the message by the Content Filter agent.

This X-header is always present when the security of a message has been evaluated. This X-header specifies the authentication source. The possible values are Anonymous, Internal, External, or Partner.

This X-header is populated during Domain Secure authentication. The value is the fully qualified domain name (FQDN) of the remote authenticated domain.

This X-header specifies the authentication mechanism for the submission of the message. The value is a 2-digit hexadecimal number.

This X-header specifies the FQDN of the server computer that evaluated the authentication of the message on behalf of the organization.

This X-header identifies journal reports in transport. As soon as the message leaves the transport server, the header becomes X-MS-JournalReport.

This X-header identifies the time when the message first entered the Exchange organization.

This X-header identifies the original sender of a quarantined message when it first entered the Exchange organization.

OrganizationOriginal-Sender X-MS-ExchangeOrganizationOriginalSize X-MS-ExchangeOrganizationOriginal-Scl X-MS-ExchangeOrganization-PCL X-MS-ExchangeOrganizationQuarantine This X-header identifies the original size of a quarantined message when it first entered the Exchange organization.

This X-header identifies the original SCL of a quarantined message when it first entered the Exchange organization.

This X-header identifies the phishing confidence level. The possible phishing confidence level values are from 1 through 8. A larger value indicates a suspicious message. For more information, see Understanding Anti-Spam Stamps. This X-header indicates that the message has been quarantined in the spam quarantine mailbox and a delivery status notification (DSN) has been sent. Alternatively, it indicates that the message was quarantined and released by the administrator. This X-header field prevents the released message from being submitted to the spam quarantine mailbox again. For more information, see Release Quarantined Messages from the Spam Quarantine Mailbox. This X-header identifies the SCL of the message. The possible SCL values are from 0 through 9. A larger value indicates a suspicious message. The special value -1 exempts the message from processing by the Content Filter agent. For more information, see Understanding Content Filtering. This X-header contains the results of the Sender ID agent. The Sender ID agent uses the sender policy framework (SPF) to compare the message's source IP address to the domain that's used in the sender's e-mail address. The Sender ID results are used to calculate the SCL of a message. For more information, see Understanding Sender ID.

X-MS-ExchangeOrganization-SCL

X-MS-ExchangeOrganizationSenderIdResult Return to top

Header Firewall for Organization X-Headers and Forest X-Headers


Exchange 2010 applies header firewall to organization X-headers and forest X-headers that exist in messages in the following ways:

Permissions that can be used to preserve or remove specific X-headers in messages are assigned to Send connectors or Receive connectors. Header firewall is automatically implemented for X-headers in messages during other types of message submission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-headers in Messages
Header firewall for organization X-headers and forest X-headers that exist in inbound messages consists of two specific permissions that are assigned to a Receive connector that's configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Receive connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved. If the permissions aren't applied to the Receive connector, header firewall is applied to the message. The organization X-headers or forest X-headers are removed from the message. The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector.

Header firewall permissions for organization X-headers and forest X-headers that are available on a Receive connector for inbound messages
By default, the security principals that have the permission assigned Permission group that has the security principals as members ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector

Permission

Description

Ms-ExchAcceptHeadersOrganization

Internal

Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only

This permission applies to organization X-headers. Organization Xheaders start with X-MS-Exchange-Organization-. If this permission isn't granted, the receiving server removes any organization headers from the message.

Ms-ExchAcceptHeadersForest

Hub Transport servers Edge

ExchangeServers

Internal

This permission applies to forest X-headers. Forest X-headers start with X-MS-Exchange-Forest-. If this permission isn't granted, the receiving server removes any forest headers from the message.

Transport servers Exchange Servers Note: On Hub Transport servers only

If you want to apply header firewall to organization X-headers and forest X-headers in a custom Receive connector scenario, use any of the following methods:

Create a Receive connector and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see Create an SMTP Receive Connector. Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission from a security principal that's configured on the Receive connector. This method doesn't work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see RemoveADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Headers-Organization permission and the Ms-Exch-Accept-Headers-Forest permission to a security principal that's configured on the Receive connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-Headers in Outbound Messages
Header firewall for organization X-headers and forest X-headers that exist in outbound messages consists of two specific permissions that are assigned to a Send connector that's configured on a Hub Transport server or an Edge Transport server:

If the permissions are assigned to the Send connector, header firewall isn't applied to the message. The organization X-headers or forest X-headers in the message are preserved. If the permissions aren't applied to the Send connector, header firewall is applied to the message. The organization X-headers and forest X-headers are removed from the message. The following table describes the header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector.

Header firewall permissions for organization X-headers and forest X-headers that are available on a Send connector for outbound messages
By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange Server 2003 bridgehead servers

Permission

Description

Ms-ExchSendHeadersOrganization

This permission applies to organization X-headers. Organization X-headers start with X-MS-Exchange-Organization-. If this permission isn't granted, the sending server removes any organization headers from the message.

Ms-ExchSendHeadersForest

Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy

This permission applies to forest X-headers. Forest X-headers start with X-MSExchange-Forest-. If this permission isn't granted, the sending server removes any forest headers from the message.

Interop universal security group Exchange 2003 bridgehead servers If you want to apply header firewall for organization X-headers or forest X-headers in a custom Send connector scenario, use the any of the following methods:

Create a Send connector and select a usage type other than Internal or Partner. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from the connector. For more information, see Configure Send Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Organization permission and the Ms-Exch-Send-Headers-Forest permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Organization X-Headers and Forest X-Headers from Other Message Sources
Messages can enter the Exchange 2010 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for organization X-headers and forest X-headers is applied to messages originating from these other message sources as described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for organization X-headers and forest X-headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Understanding the Pickup and Replay Directories. Replay directory The Replay directory is used to resubmit messages that have been exported from Exchange 2010 message queues. How header firewall for organization X-headers and forest X-headers is applied in these messages is controlled by the X-CreatedBy: header field in the message file: If the value of this header field is MSExchange14, header firewall isn't applied to the message. If the value of X-CreatedBy: isn't MSExchange14, header firewall is applied. If the X-CreatedBy: header field doesn't exist in the message file, header firewall is applied. For more information about the Replay directory, see Understanding the Pickup and Replay Directories. Drop directory The Drop directory is used by Foreign connectors on Hub Transport servers to send messages to messaging servers that don't use SMTP to transfer messages. Header firewall for organization X-headers and forest X-headers is always applied to message files before they're put in the Drop directory. For more information about Foreign connectors, see Understanding Foreign Connectors. Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. For outgoing messages that are created and submitted from mailboxes, header firewall for organization X-headers and forest X-headers is always applied. For incoming messages, header firewall for organization X-headers and forest X-headers is selectively applied. The X-headers that are specified in the following list aren't blocked by header firewall for inbound messages to mailbox recipients: X-MS-Exchange-Organization-SCL X-MS-Exchange-Organization-AuthDomain X-MS-Exchange-Organization-AuthMechanism X-MS-Exchange-Organization-AuthSource X-MS-Exchange-Organization-AuthAs X-MS-Exchange-Organization-OriginalArrivalTime X-MS-Exchange-Organization-OriginalSize For more information about the store driver, see Understanding Transport Pipeline. DSN messages Header firewall for organization X-headers and forest X-headers is always applied to the original message or the original message header that's attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications. Agent submission Header firewall for organization X-headers and forest X-headers isn't applied to messages that are submitted by agents. Return to top

Header Firewall for Routing Headers


Routing headers are standard SMTP header fields that are defined in RFC 2821 and RFC 2822. Routing headers stamp a message by using information about the different messaging servers that were used to deliver the message to the recipient. The available routing headers are described in the following list:

Received: A different instance of this header field is added to the message header by every messaging server that accepted and forwarded the message to the recipient. The Received: header typically includes the name of the messaging server and a date-timestamp. Resent-*: Resent header fields are informational header fields that can be used to determine whether a message has been forwarded by a user. The following resent header fields are available: Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc:, and Resent-MessageID:. The Resent 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. Routing headers that are inserted into messages can be used to misrepresent the routing path that a message traveled to reach a recipient. Exchange 2010 uses two different ways to apply header firewall to routing headers that exist in messages:

Permissions are assigned to Send connectors or Receive connectors that can be used to preserve or remove routing headers in messages. Header firewall is automatically implemented for routing headers in messages during other types of message submission.

How Header Firewall Is Applied to Routing Headers in Inbound Messages


Receive connectors have the Ms-Exch-Accept-Headers-Routing permission that's used to accept or reject any routing headers that exist in an inbound message:

If this permission is granted, all routing headers are preserved in the inbound message. If this permission isn't granted, all routing headers are removed from the inbound message. The following table describes the default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector.

Default application of the Ms-Exch-Accept-Headers-Routing permission on a Receive connector


By default, the security principals that have the permission assigned Anonymous user account Authenticated user accounts Permission group that has the security principals as members Anonymous ExchangeUsers ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector Internet Client (unavailable on Edge Transport servers) Internal

Hub Transport servers Edge Transport servers Exchange Servers Note: Hub Transport servers only Externally Secured servers

Exchange Legacy Interop universal security group Partner Server account

ExchangeLegacyServers Partner

Internal

Internet Partner The Ms-Exch-Accept-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom Receive connector scenario, follow these steps:

1. Perform one of the following actions: Create a Receive connector and select the usage type Custom. Don't assign any permission groups to the Receive connector. You can't modify the assigned permissions or the group membership of a permission group. Modify an existing Receive connector, and set the PermissionGroups parameter to the value None. 2. Use the Add-ADPermission cmdlet to add the appropriate security principals that are required on the Receive connector. Make sure that no security principals have the Ms-Exch-Accept-Headers-Routing permission assigned to them. If it's necessary, use the Add-ADPermission cmdlet to deny the Ms-Exch-AcceptHeaders-Routing permission to the security principal that you want to configure to use the Receive connector. For more information, see the following topics:

Create an SMTP Receive Connector Configure Receive Connector Properties Add-ADPermission Remove-ADPermission

How Header Firewall Is Applied to Routing Headers in Outbound Messages


Send connectors have the Ms-Exch-Send-Headers-Routing permission that's used to allow or remove any routing headers that exist in an outbound message:

If this permission is granted, all routing headers are preserved in the outbound message. If this permission isn't granted, all routing headers are removed from the outbound message. The following table describes the default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector.

Default application of the Ms-Exch-Send-Headers-Routing permission on a Send connector


By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange 2003 bridgehead servers

Anonymous User Account Partner Servers

Internet Partner

The Ms-Exch-Send-Headers-Routing permission is assigned to all usage types except Custom. If you want to apply header firewall to routing headers in a custom

Send connector scenario, use the any of following methods:

Create a Send connector and select the usage type Custom. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Headers-Routing permission from the connector. For more information, see Configure Send Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Headers-Routing permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission.

How Header Firewall Is Applied to Routing Headers from Other Message Sources
Messages can enter the Exchange 2010 transport pipeline on a Hub Transport server or an Edge Transport server without using Send connectors or Receive connectors. Header firewall for routing headers is applied to the other message sources that are described in the following list:

Pickup directory The Pickup directory is used by administrators or applications to submit message files. Header firewall for routing headers is always applied to the message files in the Pickup directory. For more information about the Pickup directory, see Understanding the Pickup and Replay Directories. Store driver The store driver exists on Hub Transport servers to transport messages to and from mailboxes on Mailbox servers. Header firewall for routing headers is always applied to all messages that are sent from mailboxes on Mailbox servers. Header firewall for routing headers isn't applied to incoming messages for delivery to mailbox recipients. For more information about the store driver, see Understanding Transport Pipeline. DSN messages Header firewall for routing headers is always applied to the original message or the original message header that's attached to the DSN message. For more information about DSN messages, see Managing Delivery Status Notifications. Replay directory, Drop directory, and agent submission Header firewall for routing headers isn't applied to messages that are submitted by the Replay directory, the Drop directory, or agents. Return to top

Header Firewall and Earlier Versions of Exchange


Exchange 2003 and earlier versions of Exchange don't use the organization X-headers or forest X-headers. Exchange 2010 treats versions of Exchange earlier than Exchange 2007 as untrusted message sources. Header firewall is applied to all organization X-headers and forest X-headers in messages coming from servers that are running earlier versions of Exchange. Header firewall for organization X-headers and forest X-headers is also applied to messages that are delivered to servers that are running earlier versions of Exchange that exist in the Exchange organization. Earlier versions of Exchange use the proprietary verb X-EXCH50 to transmit information about messages and recipients that can't be included in the e-mail message. The information is transmitted as the Exch50 binary large object (BLOB). The Exch50 BLOB is a collection of binary data that's stored as a single object. Exch50 contains data such as the SCL, address rewriting information, and other MAPI properties that don't have MIME representation. Because X-EXCH50 is a proprietary Extended Simple Mail Transfer Protocol (ESMTP) verb, Exch50 data can't be propagated by a server that doesn't have Exchange installed. For more information, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence. Routing group connectors between servers that have Exchange 2010 or Exchange 2003 installed are automatically configured to support sending and receiving Exch50 data. Send connectors and Receive connectors have permissions that enable the Exch50 command. The following table describes the permissions that allow the Exch50 command on a Receive connector for inbound messages. If one of these permissions isn't granted, and a message is sent that contains the Exch50 command, the server accepts the message, but doesn't include the Exch50 command.

Permissions that allow the Exch50 command on a Receive connector for inbound messages
Permission By default, the security principals that have the permission assigned Permission group that has the security principals as members ExchangeServers By default, the usage type that assigns the permission groups to the Receive connector Internal

Ms-ExchAcceptExch50

Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers

Ms-ExchAcceptExch50

Exchange Legacy Interop universal security group

ExchangeLegacyServers

Internal

If you want to block the Exch50 command in a custom Receive connector scenario, use the any of following methods:

Create a Receive connector and select a usage type other than Internal. The Receive connector usage type can only be set when you create the connector. For more information, see Create an SMTP Receive Connector. Modify an existing Receive connector and remove the ExchangeServers permission group. For more information, see Configure Receive Connector Properties. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Accept-Exch50 permission from a security principal that's configured on the Receive connector. This method doesn't work if the permission has been assigned to the security principal by using a permission group. You can't modify the assigned permissions or the group membership of a permission group. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Accept-Exch50 permission to a security principal that's configured on the Receive connector. For more information, see Add-ADPermission. The following table describes the permission that allows the Exch50 command on a Send connector for outbound messages. If this permission isn't granted and a

message is sent that contains the Exch50 command, the server sends the message, but doesn't include the Exch50 command.

Permission that allows the Exch50 command on a Send connector for outbound messages
Permission By default, the security principals that have the permission assigned By default, the usage type that assigns the security principals to the Send connector Internal Hub Transport servers Edge Transport servers Exchange Servers Note: On Hub Transport servers only Externally Secured servers Exchange Legacy Interop universal security group Exchange 2003 bridgehead servers If you want to block the Exch50 command in a custom Send connector scenario, you can use the any of following methods:

Ms-Exch-SendExch50

Create a Send connector and select a usage type other than Internal. The Send connector usage type can only be set when you create the connector. For more information, see Create an SMTP Send Connector. Remove a security principal that assigns the Ms-Exch-Send-Exch50 permission from the connector. Use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Exch50 permission from one of the security principals that's configured on the Send connector. For more information, see Remove-ADPermission. Use the Add-ADPermission cmdlet to deny the Ms-Exch-Send-Exch50 permission to one of the security principals that's configured on the Send connector. For more information, see Add-ADPermission. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding SMTP Failover and Load Balancing in Transport


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-13 When you have multiple Hub Transport servers in your organization, Exchange automatically distributes the mail traffic among all the Hub Transport servers in your organization. The load distribution is successful in distributing the load evenly when all servers are available. However, when one or more servers are unavailable, the load distribution may become uneven among the remaining servers, especially if your organization is distributed across multiple Active Directory sites. In Microsoft Exchange Server 2010 Service Pack 1 (SP1), several improvements were made to the decision-making mechanism for distributing the load among Hub Transport servers. Looking for management tasks related to message routing? See Managing Message Routing. Contents Exchange Server 2010 RTM Behavior Exchange 2010 SP1 Improvements Windows Network Load Balancing or Third-Party Load Balancing Solutions with Transport Servers

Exchange Server 2010 RTM Behavior


In the release to manufacturing (RTM) version of Exchange 2010, when a transport server needs to route several messages to the same destination, the server initially determines the next hop for those messages. If there are multiple target servers for that next hop, it load balances the connection used to deliver messages equally among the target servers using the round robin manner provided by enhanced Domain Name System (DNS). For example, consider a topology where you have two Active Directory sites with three Hub Transport servers in each (as shown in the following figure). When a Hub Transport server in Site A, for example Hub02, needs to send messages to Site B, the next hop for that message is Site B. There are three possible targets in the next hop: Hub04, Hub05, and Hub06. The server will distribute the number of connections evenly across those three targets as shown in the following figure. This action results in an even distribution of messages across the connections over time.

Similarly, the Hub Transport servers in Site B will distribute the number of messages sent to recipients in Site A evenly across Hub01, Hub02, and Hub03. Also, because Edge01 is subscribed to Site A, the targets for the next hop for messages sent to the Internet are Hub01, Hub02, and Hub03. A problem arises if one or more of the servers are unavailable in the next hop. For example, assume that Hub04 in Site B is unavailable for scheduled maintenance. The servers in Site A don't maintain availability status of each server in Site B. The servers in Site A will distribute the load destined for Site B among the three Hub Transport servers in that site. However, approximately one third of those connections would be sent to Hub04 but won't succeed. These connections will fail over to the next available server, and one of the Hub Transport servers in Site B will process substantially more load than the other server as shown in the following figure.

This undesirable behavior may occur whenever there's an unavailable server in the next hop that typically has more than two targets. The next hop could be another Active Directory site as shown in the preceding example, or a connector that has multiple Hub Transport servers listed as the source server (for example, the Send connector to the subscribed Edge Transport server in the topology shown in the preceding figures). This isn't an issue for mail submissions from Mailbox servers. The mail submission service will detect unavailable Hub Transport servers in a site, and won't attempt to deliver to those servers. In the example shown previously, although one of the Hub Transport servers in Site B may have a heavier load from intersite traffic, the load generated by Mailbox servers in Site B will be evenly split between Hub05 and Hub06. Return to top

Exchange 2010 SP1 Improvements


To address the issue described in the previous section, a new component called Healthy Server Selector was added in Exchange 2010 SP1. Healthy Server Selector maintains a list of servers that are unavailable. This list is used by enhanced DNS to filter out any unavailable servers when applying round robin logic for load balancing. To demonstrate how Healthy Server Selector helps with load balancing, consider the problematic condition shown in the preceding figure. In Exchange 2010 SP1, enhanced DNS will first compile the list of potential targets in the next hop, Site B. It will then ask Healthy Server Selector to filter the list. Healthy Server Selector will report that Hub04 for the next hop Site B is unhealthy. Enhanced DNS will remove Hub04 from the list of potential targets for the next hop Site B, and will use round robin load balancing only between Hub05 and Hub06 as shown in the following figure.

Healthy Server Selector


In its simplest form, Healthy Server Selector tracks servers deemed unhealthy so that those servers aren't included in round robin load balancing. From a Healthy Server Selector perspective, a definition of an unhealthy server is one to which a connection attempt returns any Windows sockets (Winsock) error code. For each unhealthy server, Healthy Server Selector keeps the following information:

Server IP address Retry count Last retry time

Retry Behavior
When a server is marked as unhealthy, Healthy Server Selector will ensure that connections to that specific server are tried again to detect when that server comes online. Healthy Server Selector uses the following settings to determine how frequently connections will be retried to an unhealthy server:

QueueGlitchRetryInterval and QueueGlitchRetryCount These settings determine how many times and at what interval Healthy Server Selector retries connections to a specific server when it's first marked unhealthy. These settings are configured in the EdgeTransport.exe.config file. The default values for these settings are 1 minute and 4 retry attempts. These values mean that a connection to an unhealthy server will be attempted every minute four times in a default configuration. TransientFailureRetryInterval and TransientFailureRetryCount If the unhealthy server is unavailable, these settings are used by Healthy Server Selector to determine the frequency of the next set of retry attempts. These settings are configured for each transport server. The default values are 5 minutes (10 minutes on an Edge Transport server) and 6 retry attempts. These values mean that a connection to an unhealthy server will be attempted every five minutes six times after the first four minutes in a default configuration. OutboundConnectionFailureRetryInterval If the unhealthy server is unavailable, Healthy Server Selector will continue to retry the connection by the frequency specified in this parameter. This setting is configured for each transport server. The default value is 10 minutes (30 minutes on an Edge Transport server). This means that a connection will be attempted to an unhealthy server every 10 minutes after the first 34 minutes in a default configuration. For step-by-step instructions about how to configure these settings, see Configure Message Retry, Resubmit, and Expiration Intervals. When it's time to retry a connection, Healthy Server Selector allows only one connection attempt to the unhealthy server. If that connection succeeds, the SMTP outbound component will notify Healthy Server Selector that the connection is successful. At that point, Healthy Server Selector removes the server from the list of

unhealthy servers.

Healthy Server Selector and Shadow Redundancy


The shadow redundancy component of transport includes a heartbeat feature. The heartbeat is a simple SMTP connection used to query the status of messages previously submitted to a target server. Healthy Server Selector filtering won't prevent the Shadow Redundancy Manager from issuing heartbeat connection attempts. If a server has shadow messages that were submitted to a server that's unhealthy, it will attempt to make heartbeat connections to that server. If a heartbeat connection succeeds to an unhealthy server, that target server is immediately removed from the list of unhealthy servers by Healthy Server Selector. To learn more about shadow redundancy and the heartbeat, see Understanding Shadow Redundancy.

Diagnostic Information
In Exchange 2010 SP1, the connectivity logs include diagnostic information for Healthy Server Selector and the enhanced load balancing features. When a server is added to the unhealthy servers list by Healthy Server Selector, the event is logged in the connectivity log. To locate this event, search for the phrase MarkedUnhealthy in the connectivity log. On the line that contains this phrase, you can find the following information:

Target host IP address Target host fully qualified domain name (FQDN) Winsock error received Status: MarkedUnhealthy Current failure count Next retry time From this entry, you can identify the reason for the failure by evaluating the Winsock error code. For a complete list of Winsock error codes and their definitions, see Windows Sockets Error Codes. You can also determine how many connection attempts have failed and the next scheduled retry attempt to the target server by analyzing the Current Failure Count and Next Retry Time fields. You must have connectivity logging enabled on your transport servers to be able to see this diagnostic information. Connectivity logging is disabled by default on Hub Transport and Edge Transport servers. For more information about configuring connectivity logging, see Configure Connectivity Logging. Return to top

Windows Network Load Balancing or Third-Party Load Balancing Solutions with Transport Servers
As discussed earlier in this topic, Exchange 2010 automatically load balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load balancing of messages received from non-Exchange sources such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. If you have one or more of these mail sources, you may choose to load balance incoming SMTP traffic using a unified SMTP namespace (such as smtp.contoso.com) that distributes external e-mail messages across the transport servers within the organization. Windows Network Load Balancing (NLB) or a hardware-based load balancing solution from a third-party vendor are both supported. For a list of load balancers that have been tested by the vendor and reviewed by Microsoft to meet Exchange 2010 requirements, see Microsoft Unified Communications Load Balancer Deployment. Important: Using a load balancing solution to handle message traffic between the Exchange servers in your organization isn't supported. You must exclude message traffic between Exchange servers from any load balancing solution you deploy in your environment.

Load Balancing Inbound Internet Messages Among Your Edge Transport Servers
The most common situation is handling incoming messages from the Internet. You don't need to deploy a load balancing solution to distribute the load across your Edge Transport servers. You can accomplish this by using DNS round robin and mail exchange records (MX records) that have the same preference value, as shown in the following figure.

If you choose to use Windows NLB or a hardware load balancing solution to distribute incoming Internet messages, you need to publish a single MX record that points to your load balancing solution. The load balancer will distribute incoming messages to all the Edge Transport servers listed in its configuration, as shown in the following figure.

Load Balancing Non-Exchange Messages Among Your Hub Transport Servers


Exchange 2010 uses Receive connectors to accept incoming messages. By default, when an Exchange 2010 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. When a POP or IMAP client submits an e-mail message to an Exchange 2010 Hub Transport server, the message is submitted over TCP port 587 by default. This means e-mail messages submitted from POP or IMAP clients are processed by a separate Receive connector named Default Client Receive connector. If you plan on placing a load balancing solution in front of your Hub Transport servers, you should create a separate Receive connector for that purpose and make sure that only traffic processed by that particular connector is subject to load balancing. This can be achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector. In addition, the Exchange Server authentication option should be disabled on the Receive connector to ensure Exchange traffic doesnt route over it. The following figure shows a configuration where a load balancer is used to distribute messages received from POP3 or IMAP4 clients and non-Exchange SMTP servers among two Hub Transport servers.

Windows Network Load Balancing


Windows NLB is the most common software load balancer used for Exchange servers. There are some limitations associated with deploying Windows NLB with Exchange 2010 Hub Transport servers:

Windows NLB can't be used on Exchange servers where the Hub Transport and Mailbox server roles coexist and the server also participates in a database availability group (DAG). This is because the Windows NLB feature is incompatible with Windows failover clustering. If you use an Exchange 2010 DAG and you want to use Windows NLB, you need to have the Hub Transport server role and the Mailbox server role running on separate computers. In addition, Windows NLB impacts message routing when the DAG member and Hub Transport server role coexist on the same server. To learn more, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. We don't recommend putting more than eight Hub Transport servers in an array that's load balanced by Windows NLB. If you need to load balance more than eight Hub Transport servers, you should deploy a hardware-based solution. Windows NLB doesn't detect service outages. It only detects server outages by IP address. If the Exchange Transport service fails, but the server is still functioning, Windows NLB wont detect the failure and will still route incoming e-mail messages to that Hub Transport server. Manual intervention is required to remove the Hub Transport server experiencing the outage from the load balancing pool. Windows NLB configuration can result in port flooding, which can overwhelm networks. This is because Windows NLB has been designed in such a way that it simultaneously delivers all incoming client packets to all switch ports. Although this behavior enables Windows NLB to deliver very high throughput, it may cause high switch occupancy. For detailed steps about configuring Windows NLB, see Configure Windows Network Load Balancing for Hub Transport Servers.

Hardware Load Balancing


If you have more than eight Hub Transport servers for which you want to load balance non-Exchange message traffic, you need a more scalable load balancing solution. Although there are robust software load balancing solutions available, a hardware load balancing solution provides the most capacity. Unlike Windows NLB, which only detects server outages by IP address, a hardware load balancer can be configured to detect the failure of the Exchange Transport service and can route incoming e-mail messages to other Hub Transport servers without any manual intervention. For detailed steps about configuring a hardware load balancing solution, see Configure Hardware Load Balancing for Hub Transport Servers.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding MailTips
Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 MailTips are informative messages displayed to users while they're composing a message. Microsoft Exchange Server 2010 analyzes the message, including the list of recipients to which it's addressed, and if it detects a potential problem, it notifies the user with MailTips prior to sending the message. With the help of the information provided by MailTips, senders can adjust the message they're composing to avoid undesirable situations or non-delivery reports (NDRs). The following unproductive messaging scenarios are common in any messaging environment:

NDRs resulting from messages that violate restrictions configured in an organization such as message size restrictions or maximum number of recipients per message. NDRs resulting from messages sent to recipients that don't exist, recipients that are restricted, or users whose mailboxes are full. Sending messages to users with Automatic Replies configured. All of these scenarios involve the user sending a message, expecting it to be delivered, and instead receiving a response stating that the message isn't delivered. Even in the best-case scenario, like the automatic reply, these events result in lost productivity. In the case of an NDR, this scenario could result in a costly call to the Help desk. There are also several scenarios where sending a message won't result in an error, but can have undesirable, even embarrassing consequences:

Messages sent to extremely large distribution groups. Messages sent to inappropriate distribution groups. Messages inadvertently sent to recipients outside your organization. Selecting Reply to All to a message that was received as a Bcc recipient. All of these problematic scenarios can be mitigated by informing users of the possible outcome of sending the message as they're composing the message. For example, if senders know that the size of the message they're trying to send exceeds the corporate policy, they won't attempt to send the message. Similarly, if senders are notified that the message they're sending will be delivered to people outside the organization, they're more likely to ensure that the content and the tone of the message are appropriate. By addressing the scenarios listed earlier, MailTips can help you to:

Reduce the cost of processing and storing messages by preventing NDRs. Reduce the volume of Help desk calls caused by NDRs. Increase productivity by avoiding communications that won't succeed, for example, breaking the cycle of sending an e-mail message, receiving an automatic reply, and then redirecting the message. Inform your users as they compose e-mail messages about various policies configured in your organization that impose limits on the messages sent. Direct your users to the correct distribution groups. Reduce the risk of inadvertent disclosure of information to people outside your organization. Important: MailTips aren't designed to enforce specific policies. They simply inform the senders about the nature of the message they're composing so they can make necessary adjustments. Looking for management tasks related to MailTips? See Managing MailTips.

MailTips in Exchange 2010


The following table provides a list of MailTips in Exchange 2010.

Exchange 2010 MailTips


MailTip Invalid Internal Recipient Scenario The Invalid Internal Recipient MailTip is displayed if the sender adds a recipient that appears to be internal to the organization but doesn't exist in Active Directory. This could happen if the sender addresses a message to a user who is no longer with the company but whose address resolves due to name resolution cache or an entry in the sender's Contacts folder. It can also happen if the sender types an SMTP address with a domain for which Exchange is authoritative and the address doesn't resolve to an existing recipient. The MailTip indicates the invalid recipient and gives the sender the option to remove the recipient from the message. The Mailbox Full MailTip is displayed if the sender adds a recipient whose mailbox is full and your organization has implemented a Prohibit Receive restriction for mailboxes over a specified size. The MailTip indicates the recipient whose mailbox is full and gives the sender the option to remove the recipient from the message. The MailTip is accurate at the time of display. If the message isn't immediately sent, the MailTip is updated every two hours. This also applies to messages that were saved in the Drafts folder and reopened after two hours. The Automatic Replies MailTip is displayed if the sender adds a recipient who has turned on Automatic Replies. The MailTip indicates the recipient has Automatic Replies turned on and also displays the first 250 characters of the automatic reply configured by the recipient. The MailTip is accurate at the time of display. If the message isn't immediately sent, the MailTip is updated every two hours. This also applies to messages that were saved in the Drafts folder and reopened after two hours. If part of your user mailboxes are hosted on Exchange Online and you're in a coexistence with Exchange Online scenario, the setting on the remote domain object that represents the remote part of your organization has a direct effect on how this MailTip is processed.

Mailbox Full

Automatic Replies

In Exchange 2010, users can configure different Automatic Replies for internal and external senders. If the remote domain is configured as an internal domain (by setting the IsInternal parameter on the remote domain object to $true), the internal automatic reply is returned to all users in the organization regardless of where their mailbox resides. However, if the remote domain isn't configured as an internal domain, the internal automatic reply is returned to all users whose mailboxes are in the local domain and the external automatic reply is returned to users whose mailboxes are in the remote domain. Custom A custom MailTip is displayed if the sender adds a recipient for whom a customized MailTip is configured. A custom MailTip can be useful for providing specific information about a recipient. For example, you can create a custom MailTip for a distribution group explaining its purpose to reduce its misuse. By default, custom MailTips aren't displayed if the sender isn't allowed to send to that recipient. In that case, the Restricted Recipient MailTip is displayed. However, you can change this configuration and have the custom MailTip also display. For more information about configuring custom MailTips, see Configure Custom MailTips for Recipients. The Restricted Recipient MailTip is displayed if the sender adds a recipient for which delivery restrictions are configured prohibiting this sender from sending messages. The MailTip indicates the recipient to which the sender isn't allowed to send messages and gives the sender the option to remove the recipient from the message. It also clearly informs the sender that the message won't be delivered if sent. If the restricted recipient is an external recipient, or if it's a distribution group that contains external recipients, this information is also provided to the sender. However, the following MailTips, if applicable, are suppressed: Automatic Replies Mailbox Full Custom MailTip Moderated Recipient Oversize Message

Restricted Recipient

External Recipients

The External Recipients MailTip is displayed if the sender adds a recipient that's external, or adds a distribution group that contains external recipients. This MailTip informs senders if a message they're composing will leave the organization, helping them make the correct decisions about wording, tone, and content. By default, this MailTip is turned off. You can turn it on using the Set-OrganizationConfig cmdlet. For details, see Configure Organizational Settings for MailTips. If part of your user mailboxes are hosted on Exchange Online and you're in coexistence with an Exchange Online scenario, the setting on the remote domain object that represents the remote part of your organization has a direct effect on how this MailTip is processed. If the remote domain is configured as an internal domain (by setting the IsInternal parameter on the remote domain object to $true), any recipients in this remote domain will be treated as internal and therefore the External Recipients MailTip won't be displayed. However, if the remote domain isn't configured as an internal domain, the recipients in that domain will be considered external and this MailTip will be displayed when a message is being composed to those recipients. Note: This MailTip isn't evaluated when composing a message to a distribution group in the remote domain.

Large Audience

The Large Audience MailTip is displayed if the sender adds a distribution group that has more than the large audience size configured in your organization. By default, Exchange displays this MailTip for messages to distribution groups that have more than 25 members. For information about configuring the large audience size for your organization, see Configure Organizational Settings for MailTips. The size of distribution groups isn't calculated each time. Instead, the distribution group information is read from the group metrics data. For more information about group metrics, see Understanding Group Metrics. The Moderated Recipient MailTip is displayed if the sender adds a recipient that's moderated. The MailTip indicates which recipient is moderated and informs the sender that this may result in delay of the delivery. If the sender is also the moderator, this MailTip isn't displayed. It's also not displayed if the sender has been explicitly allowed to send messages to the recipient (by adding the sender's name to the Accept Messages Only From list for the recipient). The Reply-All on Bcc MailTip is displayed if the sender receives a Bcc copy of a message and selects Reply to All. When a user selects Reply to All to such a message, the fact that the user received a Bcc of that message is revealed to the rest of the audience to which the message was sent. In almost all cases, this is an undesirable situation, and this MailTip informs the user of this condition. Note: This MailTip is only supported in Microsoft Office Outlook Web App.

Moderated Recipient

Reply-All on Bcc

Oversize Message

The Oversize Message MailTip is displayed if the message the sender is composing is larger than configured message size limits in your organization. The MailTip is displayed if the message size violates one of the following size restrictions: Maximum send size setting on the sender's mailbox Maximum receive size setting on the recipient's mailbox Maximum message size restriction for the organization Maximum Request Length setting (for Outlook Web App only) Note: Due to the complexity of the implementation, the message size limits on the connectors in your organization aren't taken into account. Note: This MailTip isn't displayed in Outlook Web App.

MailTips Architecture
MailTips are implemented as a Web service in Exchange 2010. When a sender is composing a message, the client software makes an Exchange Web service call to the

server running Exchange 2010 with the Client Access server role installed to get the list of MailTips. The Exchange 2010 server responds with the list of MailTips that apply to that message, and the client software displays the MailTips to the sender. The following messaging clients support MailTips:

Outlook Web App Microsoft Outlook 2010 The following actions by the sender trigger MailTips to be evaluated or updated:

Add a recipient Add an attachment Reply or reply to all Open a message, which is already addressed to recipients, from the Drafts folder The client caches the MailTips so removing and adding the same recipient won't result in the client querying the Client Access server again. When the Client Access server is queried, it compiles the list of applicable MailTips and returns them all in one batch. As a result, all MailTips are displayed to the user at the same time and don't arrive one at a time, distracting the sender. The Client Access server uses the following sources to compile MailTips for a specific message:

Active Directory Recipient mailboxes Local group metrics data Each time a sender adds a recipient to a message, a sequence of events occurs to evaluate MailTips, as shown in the following figure.

As shown in the preceding figure:

1. The mail client queries the Web service on the Client Access server for MailTips that apply to the recipients in the message. 2. The Client Access server gathers MailTip data: a. The Client Access server queries Active Directory and reads group metrics data. b. If the recipient is a mailbox that's located on a Mailbox server in the local site, the Client Access server queries the Mailbox server to gather the Automatic Replies and Mailbox Full MailTips. If the recipient's mailbox is in another site, the Client Access server requests MailTips information from the Client Access server in the remote site. c. The Client Access server in the remote site queries the local Mailbox server for MailTip data. d. The remote Client Access server proxies the results back to the requesting Client Access server. 3. The Client Access server returns MailTip data back to the client.

Limits on MailTips
MailTips are subject to the following restrictions:

MailTips aren't supported when working in offline mode with Outlook. When a message is addressed to a distribution group, the MailTips for individual recipients that are members of that distribution group aren't evaluated. However, if any of the members is an external recipient, the External Recipients MailTip is displayed, which shows the sender the number of external recipients in the distribution group. If the message is addressed to more than 200 recipients, individual mailbox MailTips aren't evaluated due to performance reasons. Custom MailTips are limited to 250 characters. If the sender starts composing a message and leaves it open for an extended period of time, the Automatic Replies and Mailbox Full MailTips are evaluated every two hours.

MailTips in Complex Topologies


MailTips that rely on the recipients' mailbox data are evaluated by making a connection to the Mailbox servers that hold those recipients. The Mailbox Full and Automatic Replies MailTips are in this category. For these MailTips, the Client Access server directly queries the Mailbox server using RPC, but only if the recipients are in the same site. For recipients that reside in other sites or forests, this information is gathered via server-to-server Web requests between Client Access servers.

MailTips over Organization Relationships


Microsoft Exchange Server 2010 Service Pack 1 (SP1) allows you to configure organization relationships with Exchange Online or other organizations. Establishing an organization relationship allows you to enhance the user experience when dealing with the other organization with features including sharing free/busy data between the two organizations, configuring secure message flow, and enabling message tracking across the two organizations. For more information about organization relationships, see Understanding Federation. When MailTips are enabled over an organization relationship, the local Client Access servers will proxy the Client Access servers in the remote organization. The behavior is similar to how mailbox-specific MailTips are handled for users in remote Active Directory sites. The one difference is the Client Access servers will proxy all MailTips types over an organization relationship, not just the mailbox-specific MailTips. You have granular control over which MailTip types are returned over an organization relationship in addition to just allowing or preventing returning MailTips. The following two sections explain these settings in detail.

Controlling the MailTips Access Level


There may be many reasons to establish an organization relationship. Depending on the specific situation, you may want to restrict certain types of MailTips. Specifically, you can either allow all MailTips to be returned or only a limited set that would prevent NDRs. You can configure this setting with the MailTipsAccessLevel parameter of the Set-OrganizationRelationship cmdlet. The following table shows which MailTips are returned over the organization relationship.

MailTip Large Audience Automatic Replies

All Yes

Limited No

Yes If the remote domain of the recipient is specified as internal, the internal automatic reply is displayed. Otherwise, the external automatic reply is displayed. Yes

Yes The external automatic reply is displayed.

Moderated Recipient Oversize Message Restricted Recipient Mailbox Full Custom MailTips External Recipients

No

Yes

Yes

Yes

Yes

Yes

No

Yes

No

Yes If the remote domain of the recipient is specified as internal, this MailTip is suppressed. Otherwise, the external MailTip is returned.

Yes If the remote domain of the recipient is specified as internal, this MailTip is suppressed. Otherwise, the external MailTip is returned.

For detailed steps about how to configure MailTips access levels, see Configure Organizational Settings for MailTips.

Controlling the MailTips Access Scope


When you enable MailTips over an organization relationship and set the access level to All, the recipient-specific MailTips, Mailbox Full, Automatic Replies, and custom MailTips, are returned for all users. However, you may only want to allow these MailTips for a specific set of users. For example, if you set up an organization relationship with a partner, you may want to allow these MailTips only for the users that work with that partner. To achieve this, you need to first create a group and add all users for whom you want to share recipient-specific MailTips to that group. You can then specify that group on the organization relationship. After you implement this restriction, your Client Access servers will first verify whether the recipient for whom they received a MailTips query is part of this group. If the recipient is a member of this group, the Client Access servers will proxy back all MailTips including the recipient-specific MailTips. Otherwise they won't include the recipient-specific MailTips in their response. For detailed steps about how to configure MailTips access levels, see Configure Organizational Settings for MailTips.

Performance and Scalability


The following table lists some of the common performance concerns regarding MailTips and how these concerns are addressed.

Common performance concerns for MailTips


Performance concerns Discovering the size of distribution groups and dynamic distribution groups, and whether they include external recipients, seems like an expensive operation. Discovering the delivery restrictions for all recipients in a message with a large number of recipients can be resource- intensive. Mitigation of concern Distribution groups and dynamic distribution groups aren't evaluated when a message is being composed. This information is calculated daily by the group metrics generation service and is distributed to all Client Access servers. For more information, see Understanding Group Metrics. Delivery restrictions aren't evaluated if a message has more than 200 recipients. Also, delivery restrictions aren't evaluated for the members of distribution groups and dynamic distribution groups. This is done only for recipients that are explicitly added to the message. If a user expands a distribution group, delivery restrictions for all members will be evaluated, as long as the total number of recipients doesn't exceed 200. If the requested information isn't returned within 10 seconds, the operation times out. Exchange won't display any new MailTips to the sender after 10 seconds.

It may take a long time to collect information from various sites in complex topologies.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-04-12 The primary task of Hub Transport and Edge Transport servers in your organization is to route messages received from users and external sources to their ultimate destinations. This topic explains how Microsoft Exchange Server 2010 routes messages in your organization. Looking for management tasks related to managing transport servers? See Managing Transport Servers. Contents Overview of Message Routing in Exchange 2010 Routing Components Using Active Directory Sites for Routing Exchange 2010 Routing Tables Receiving Messages for Routing Routing Messages Rerouting and the Unreachable Queue

Overview of Message Routing in Exchange 2010

Routing decisions are made during message categorization. The categorizer is a component of the Microsoft Exchange Transport service that processes all incoming messages and determines what to do with the messages based on information about the intended recipients. The categorizer processes messages in several dependent phases and also uses other components of the Microsoft Exchange Transport service during message processing. After a message is received by an Exchange 2010 transport server, and after the preliminary processing that occurs during SMTP Receive is complete, the message is delivered to the Submission queue. Messages move from the Submission queue through the categorizer in the following phases:

1. Agent processing of submitted messages Some agent processing on the Hub Transport server occurs when the message is received for categorization. The agents that are applied during this phase include the optional Microsoft Forefront Protection for Exchange Server antivirus agent and the Journaling agent. 2. Recipient resolution During this phase, the recipient's e-mail address is resolved to determine whether the recipient has a mailbox in the Exchange organization or an external e-mail address. 3. Routing After information about the recipient is resolved, the routing component of the categorizer determines the ultimate destination for the message and the route to that destination, selects the next segment, or hop, for message relay, and resolves the next hop information to a list of physical servers and IP addresses. 4. Content conversion Before a message is relayed to its next hop, content conversion occurs so that the message is sent in a format that's readable by the recipient. Content conversion transforms e-mail messages from one format to another format for mail flow or storage, such as MAPI to MIME, or UUENCODE to base64 encoded, or for appropriate rendering that's specific to an e-mail client, such as HTML, rich text format (RTF), or plain text. 5. Agent processing of routed messages After the routing decisions for a particular message are made, the Transport Rules agent and the Journaling agent are applied on the Hub Transport server. The Journaling agent is applied both when the message is submitted and when it's routed so that any changes that are made to the message by the Transport Rules agent, for example, when it modifies a delivery address or applies a message-specific journaling requirement, don't bypass the Journaling agent. 6. Message packaging and DSN generation The final categorized message is assembled and moved to a delivery queue. A delivery status notification (DSN) may also be generated during this phase. Messages are next processed by SMTP Send, the store driver, delivery agents, or the foreign gateway connection handler. The component that's used depends on the ultimate destination. A delivery queue is dynamically generated for each hop. The messages are queued in these delivery queues after a routing decision is made. If a route can't be found for a recipient, the messages are queued to the Unreachable queue. The following figure shows how message processing occurs in the different routing phases and how messages are queued for delivery to the next hop destination. Routing context in mail flow

Return to top

Routing Components
To make routing decisions, Exchange 2010 must access configuration information that's stored in Active Directory. On an Edge Transport server, configuration information is stored in and accessed from the Active Directory Lightweight Directory Services (AD LDS) instance on the local server. Microsoft Windows and Exchange 2010 services work together to create mappings of the configuration data. These mappings are cached in routing tables. Exchange 2010 references these tables when it makes routing decisions. The cache is updated when the routing topology changes. The Exchange services that are used during message transport are common to both the Hub Transport server role and the Edge Transport server role. However, the Edge Transport server role doesn't cache information about the Active Directory topology. The following configuration and service components are important to message routing:

Active Directory sites An Active Directory site represents the routing boundary for Hub Transport servers. A Hub Transport server delivers directly to Mailbox servers, distribution group expansion servers, and to source servers for connectors in the local Active Directory site and to Edge Transport servers subscribed to that site. However, a Hub Transport server must relay messages to another Hub Transport server for recipients, expansion servers, and connectors that are located in remote Active Directory sites. The Hub Transport server role must be deployed in every Active Directory site that contains other Exchange 2010 server roles. Active Directory IP site links Active Directory IP site links define logical paths between Active Directory sites. Exchange 2010 references the IP site link objects to determine the least-cost routing path of remote Active Directory sites. Send connectors Send connectors are used for sending messages to other SMTP hosts. The address space configuration on Send connectors are used to make routing decisions. When a message is delivered to an external domain, the routing destination is typically a Send connector. An Exchange organization that accepts messages for more than one e-mail domain may decide to create Send connectors that are dedicated to each address space. For more information about Send connector selection for routing messages to external domains, see External Message Routing. Delivery agents Delivery agents are used to route messages to foreign systems that don't use SMTP protocol for message transfer. The address space and protocol configuration of delivery agents are used when making routing decisions. Foreign connectors Foreign connectors use drop directories to send messages to foreign systems that don't use SMTP protocol for message transfer. Exchange uses the configuration of Foreign connectors when making routing decisions. Routing groups Routing groups represent a routing boundary for Exchange Server 2003. If Exchange 2010 is deployed in an existing Exchange 2003 organization, routing must consider the location of servers within routing groups to deliver a message to a mailbox or a connector that resides on Exchange 2003. To implement compatibility with Exchange 2003, all computers running Exchange 2010 deployed in the organization belong to a single, global routing group. Routing group connectors Routing group connectors define logical paths between Exchange routing groups. If Exchange 2010 is deployed in an existing Exchange 2003 organization, messages are routed between server versions through routing group connectors. When the first Hub Transport server is deployed, the setup process prompts you to create a routing group connector from the global Exchange 2010 routing group to a legacy routing group. For more information about message routing in an environment where more than one version of Exchange is deployed, see Internal Message Routing. Microsoft Exchange Transport service The Microsoft Exchange Transport service is the SMTP provider for Exchange 2010 and controls every component of message processing, from SMTP IN to SMTP OUT. A series of configurable SMTP Receive agents are triggered at various SMTP events. The Microsoft Exchange Transport service enables these agents to process messages as they pass through SMTP transport and perform anti-spam, antivirus, and other tasks before messages are submitted to the categorizer. The Microsoft Exchange Transport service also uses the topology discovery module for Exchange topology discovery. Microsoft Exchange Active Directory Topology service The Microsoft Exchange Active Directory Topology service is responsible for locating the domain controllers and global catalog servers that Exchange 2010 can use to retrieve configuration and recipient data from Active Directory. The Microsoft Exchange Active Directory Topology service is also responsible for keeping Active Directory site affinity for an Exchange 2010 server up to date. Routing tables The routing tables hold the information that the routing component uses to make routing decisions. The routing table is composed of a map of topology components and their relationship to one another. DNS Exchange 2010 uses an enhanced Domain Name System (DNS) client, a component of the Microsoft Exchange Transport service, to resolve the next hop selection to a list of target server names. The standard DNS client is used to resolve that list of server names to IP addresses. Enhanced DNS also provides loadbalancing functionality for Exchange 2010 transport servers by using round robin. SMTP SMTP is used for communication when messages are relayed between SMTP servers. An SMTP server can be a Hub Transport server, Edge Transport server, Exchange 2003 server, or a smart host. A Hub Transport server uses remote procedure call (RPC) to deliver messages directly to Mailbox servers that have the same Active Directory site membership as the Hub Transport server. Return to top

Using Active Directory Sites for Routing


An Active Directory site is a logical configuration component that's based on the physical aspects of the network. The primary purpose for creating an Active Directory site is to define which subnets in the network are connected in a way that optimizes control of Active Directory replication traffic. The Active Directory site represents a routing boundary for Exchange 2010. Computers that have the Hub Transport server role installed make routing decisions based on the Active Directory site topology.

Determining Site Membership


By default, an Active Directory forest contains only one Active Directory site. The default name for this Active Directory site is Default-First-Site-Name. If no other Active Directory sites are created, all domain member computers in the forest are members of Default-First-Site-Name. You don't have to configure a subnet-to-site

association. If additional Active Directory sites are created, you must specify the subnets that are assigned to that Active Directory site. Each Active Directory site is associated with one or more IP subnets. An administrator assigns Active Directory site membership to computers that are configured as domain controllers and global catalog servers. Other domain member computers, such as Exchange servers, are assigned Active Directory site membership automatically when they're configured to use an IP address that's in an IP subnet that's associated with an Active Directory site. Computers that have the same Active Directory site membership are presumed to have good network connectivity. A server is always a member of a single Active Directory site. When an application can determine the Active Directory site membership of the computer where it's installed and of other computers in the forest, and then use that information to control communication flow, it's a site-aware application. When site-aware applications must use the services of another server, such as a domain controller or global catalog server, priority is given to the servers that have the same Active Directory site membership as the computer that's requesting those services. Exchange 2010 is a site-aware application and uses the Active Directory topology for message routing and to communicate with the services that are running on computers that have other Exchange 2010 server roles installed. The Active Directory site isn't only the routing boundary. It's also the service discovery boundary. Determining site membership for a domain member computer depends on a series of DNS queries to compare the local IP address to defined subnets and then determine the appropriate site membership association. To reduce the overhead that's associated with DNS queries, the Exchange 2010 Active Directory schema additions include the msExchServerSite attribute for the Exchange server object. The value of this attribute is the distinguished name of the Active Directory site of an Exchange server. This attribute is a property of each Exchange server object. When site membership affinity is stored as an attribute of the server object, the current topology can be read directly from Active Directory instead of relying on DNS queries and a site membership association is enabled for a non-domain computer, such as a subscribed Edge Transport server. The value for the msExchServerSite attribute is populated and kept up to date by the Microsoft Exchange Active Directory Topology service. When a Windows-based computer starts, the Net Logon service determines site membership for the computer. The Net Logon service uses that information to locate domain controllers that are located in the same Active Directory site as the local computer and then directs authorization and authentication requests to those servers. The Microsoft Exchange Active Directory Topology service uses the DsGetSiteName API call to retrieve the site membership value from the Net Logon service and writes the Active Directory site's distinguished name to the msExchServerSite attribute for the Exchange server object in Active Directory. The following table shows how an organization might define Active Directory sites. In this example, three Active Directory sites are defined, and each Active Directory site is associated with more than one IP subnet. Example of an Active Directory site-to-subnet association

Active Directory site name Site A

Associated IP subnets 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 192.168.6.0/24

Site B

Site C

If a server named HubTransportA has the IP address of 192.168.1.1, it's a member of Site A. By changing the IP address of a server, you may change its site membership. If you change the IP address of HubTransportA to 192.168.2.1, it won't change the server's Active Directory site membership because that subnet is also associated with Site A. However, if you move the server and the IP address changes to 192.168.3.1, the server would be considered a member of Site B. A change in site membership can also occur if you change the association of subnets to Active Directory sites. For example, if you remove the subnet 192.168.3.0 from association with Site B and associate it with Site A, the site membership of a server that has the IP address of 192.168.3.1 also changes to Site A. Whenever a change in site membership occurs, Exchange 2010 must update its configuration data so that the change is considered when Exchange 2010 makes routing decisions. Some latency occurs between the time that a change in an Active Directory site membership occurs and the topology change is fully propagated. The following communication must occur in the following order to propagate topology changes:

1. The change in site membership is written to a domain controller. The updated information replicates between the domain controllers in each Active Directory site in the forest. The time that's required for the change to propagate fully throughout the forest depends on the Active Directory replication topology and schedule as defined by site links. 2. The Net Logon service runs on all Windows-based computers and polls frequently for changes in Active Directory site membership. The Net Logon service polls at five-minute intervals. Therefore, the change is detected by the Net Logon service within five minutes of the local domain controller receiving the update. 3. The Microsoft Exchange Active Directory Topology service queries the Net Logon service at 15-minute intervals to determine the Active Directory site membership of the local Exchange server. If a change is detected, the Microsoft Exchange Active Directory Topology service updates the MsExchServerSite attribute. 4. The changed site attribute value of the Exchange server configuration object is then replicated throughout the organization. The Exchange servers in the organization detect this change. Then the routing tables are updated with the new Active Directory site membership attribute value. Some latency occurs between the time that an Active Directory site membership change takes effect and the time that the updated information is available to another Exchange 2010 server. For more information about how Exchange 2010 handles these types of configuration changes, see "Rerouting and the Unreachable Queue" later in this topic.

IP Site Links
Site links are logical paths between Active Directory sites. A site link object represents a set of sites that can communicate at a uniform cost through a specified intersite transport. Site links don't correspond to the actual path taken by network packets on the physical network. However, the cost assigned to the site link by the administrator typically relates to the underlying network reliability, speed, and available bandwidth. For example, the Active Directory administrator would assign a lower cost to a network connection with a speed of 100 megabits per second (Mbps) than to a network connection with a speed of 10 Mbps. By default, all site links are transitive. This means that if Site A has a link to Site B, and Site B has a link to Site C, Site A is transitively linked to Site C. The transitive link between Site A and Site C is also known as a site-link bridge. An Active Directory site link can be configured to use either IP or SMTP as the transport protocol for communication. An SMTP site link is limited in the types of data that can be replicated by using that protocol and is designed to provide a store and forward mechanism for replication between Active Directory sites that don't have

a reliable network link. An IP site link isn't limited in the types of data that can be replicated across it. Exchange 2010 uses only IP site links to determine its routing topology. The cost that's assigned to the IP site link will be considered by the routing component of Exchange 2010 when calculating a routing table. These costs are used to calculate the least-cost routing path to the ultimate destination for a message. Every Active Directory site must be associated with at least one IP site link. There is a single default IP site link named DEFAULTIPSITELINK. When you create an Active Directory site, you must associate that site to an IP site link. You can create additional IP site links to implement the desired topology, or you can associate every Active Directory site to the DEFAULTIPSITELINK. Each Active Directory site that's part of an IP site link can communicate directly with every other site in that link at a uniform cost. In the following figure, four Active Directory sites are configured in the forest. Every site has been associated with the DEFAULTIPSITELINK. Therefore, each Active Directory site communicates directly with every other site by using the same cost metric. More than one communication path is indicated, but only a single IP site link is defined. Full mesh topology with a single IP site link

In the following figure, four Active Directory sites are configured in the forest. In this topology, the administrator has configured IP site links to create a hub-and-spoke topology of Active Directory sites. Each spoke site can communicate directly with the central site, and the spoke sites can communicate with one another by using the transitive IP site links. Hub-and-spoke topology of Active Directory IP site links

It's important to note that Exchange uses site links only when determining the least-cost path, but will always try to deliver messages directly to the destination Hub Transport server. For example, if a user in Site B in the topology shown in the preceding figure sends a message to another user in Site C, the Hub Transport server in Site B will connect directly to the Hub Transport server in Site C. If you want to force messages to go through Site A, you must enable that site as a hub site. For more information about hub sites, see "Implementing Hub Sites" later in this topic. An Active Directory administrator implements the topology that best represents the connectivity and communication requirements of the forest. Because the same topology is used by Exchange 2010, you must make sure that the current topology supports efficient messaging communication. The default cost for a site link is 100. A valid site link cost can be any number from 1 through 99,999. If you specify redundant links, the link with the lowest cost assignment is always preferred. An Exchange organization administrator can assign an Exchange-specific cost to an IP site link. If an Exchange cost is assigned to an IP site link, it will be used by Exchange 2010. Otherwise, the Active Directory cost is used. For more information about how to set an Exchange cost on an IP site link, see "Controlling IP Site Link Costs" later in this topic. An administrator who has membership in the Enterprise Administrators group can create additional IP site links. For more information about Active Directory site configuration, see Designing the Site Topology.

Controlling IP Site Link Costs


Active Directory IP site links costs are based on relative network speed compared to all network connections in the WAN and are designed to produce a reliable and efficient replication topology. Therefore, in most cases, the existing IP site link costs should work well for Exchange 2010 message routing. However, if after documenting the existing Active Directory site and IP site link topology, you verify that the Active Directory IP site link costs and traffic flow patterns aren't optimal for Exchange 2010, you can make adjustments to the costs evaluated by Exchange. Changing the cost assigned to the IP site link by using Active Directory tools would impact the entire environment. Instead, use the Set-AdSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link. For example, to set a different cost on the IP site link SITELINKAB for message routing purposes, run the following command in the Shell.

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

When an Exchange cost is assigned to an IP site link, the Exchange cost overrides the Active Directory cost for message routing purposes, and routing only considers the Exchange cost when it evaluates the least-cost routing path. Adjusting IP site link costs can be useful when the message routing topology has to diverge from the Active Directory replication topology. Exchange costs can be used to force all message routes to use a hub site. Exchange costs can also be used to control where messages are queued when communication to an Active

Directory site fails. The following figure shows an Active Directory topology with four sites. Topology with Exchange costs configured on IP site links

In the preceding figure, the network connection between Site C and Site D is a low bandwidth connection that's only used for Active Directory replication and shouldn't be used for message routing. However, the Active Directory IP site link costs cause that link to be included in the least-cost routing path from any other Active Directory site to Site D. Therefore, messages are delivered to the Site D queue in Site C. The Exchange administrator prefers that the least-cost routing path include Site B instead so that if Site D is unavailable, the messages will queue at Site B. Configuring a high Exchange cost on the IP site link between Site C and Site D prevents that IP site link from being included in the least-cost routing path to Site D. Exchange 2010 provides support for configuration of a maximum message size limit on an Active Directory IP site link. By default, Exchange 2010 doesn't impose a maximum message size limit on messages that are relayed between Hub Transport servers in different Active Directory sites. If you use the Set-AdSiteLink cmdlet to configure a maximum message size on an Active Directory IP site link, routing generates a non-delivery report (NDR) for any message that has a size larger than the maximum message size limit that's configured on any Active Directory site link in the least-cost routing path. This configuration is useful for restricting the size of messages that are sent to remote Active Directory sites that must communicate over low-bandwidth connections. For more information, see Understanding Message Size Limits.

Implementing Hub Sites


In your Exchange organization, you may have to force all message delivery to be relayed through a particular Active Directory site. In this scenario, connectivity may prevent direct SMTP relay between sites. Therefore, messages must be relayed through an interim site before they're sent to their destination. Because of an Exchange organization's internal policies, an administrator may also want to relay all messages through a particular site. You can use Shell cmdlets to designate an Active Directory site as a hub site. By designating an Active Directory site as a hub site, you cause additional overall overhead because more servers are involved in message delivery. For example, consider a message that's sent from Site A to Site E. If the least-cost routing path is Site A-Site B-Site C-Site D-Site E, and you designate Site C as a hub site, the message is relayed from Site A to Site C and then relayed from Site C to Site E. You use the Set-AdSite cmdlet to specify an Active Directory site as a hub site. Whenever a hub site exists along the least-cost routing path for message delivery, the messages queue and are processed by the Hub Transport servers in the hub site before they're relayed to their ultimate destination. After the least-cost routing path is chosen, routing determines whether there's a hub site along that routing path. If a hub site is configured, messages stop at a Hub Transport server in the hub site before they're relayed to the target destination. If there's more than one hub site along the least-cost routing path, messages stop at each hub site along the routing path. This variation to direct relay routing only is in effect when the hub site is located along the least-cost routing path. The following figure shows the correct use of a hub site. In this diagram, Site B is configured as a hub site. Messages that are relayed from Site A to Site D are relayed to Site B before they're delivered to Site D. Message delivery with a hub site

The following figure shows how IP site link costs affect routing to a hub site. In this scenario, Site B has been designated as a hub site. However, because it doesn't

exist along the least-cost routing path between any other sites, queuing at Site B before delivery to the destination doesn't occur. An Active Directory site is never used as a hub site if it isn't on the least-cost routing path between two other sites. Misconfigured hub site

You can configure any Active Directory site as a hub site. However, for this configuration to work correctly, you must have deployed at least one Hub Transport server in the hub site.

Topology Discovery
The Exchange 2010 topology relies on the Active Directory site topology and doesn't have its own configuration. The Active Directory topology is made available to Exchange 2010 by the following required elements:

The Microsoft Exchange Active Directory Topology service The topology discovery module inside the Microsoft Exchange Transport service The Microsoft Exchange Active Directory Topology service runs on all Exchange 2010 server roles, except the Edge Transport server role. These Exchange 2010 servers use the Microsoft Exchange Active Directory Topology service to discover the domain controllers and global catalog servers that can be used by the Exchange servers to read and write Active Directory data. Exchange 2010 binds to the identified directory servers whenever Exchange has to read from or write to Active Directory. The topology discovery module is part of the Microsoft Exchange Transport service and provides information about the Active Directory topology to Exchange servers. This API discovers the Exchange servers and roles in the organization and determines their relationship to the Active Directory configuration objects. Configuration data is retrieved from Active Directory and then cached so that it can be accessed by the Exchange services that are running on that computer. The topology discovery module performs the following steps to generate an Exchange routing topology:

1. Data is read from Active Directory. All the following objects are retrieved: Active Directory sites. IP site links. All Exchange servers. This includes information about the Exchange 2010 server roles deployed on those servers. 2. The data that's retrieved in step 1 is used to create the initial topology and to begin linking and mapping the related configuration objects. 3. Exchange servers are matched to Active Directory sites by retrieving the site attribute value from the Exchange server object that's stored in Active Directory. 4. Routing tables are updated with the collection of information retrieved. This process makes every Exchange 2010 server aware of the other Exchange servers in the organization and of how close the Exchange servers are to one another. Return to top

Exchange 2010 Routing Tables


When the Microsoft Exchange Transport service starts, it calculates a set of routing tables that's based on the snapshot of information that's retrieved from Active Directory or, on an Edge Transport server, from AD LDS. The configuration information that's stored in AD LDS includes available connectors and accepted domains, but doesn't include topology data. The routing component refers to the routing tables to determine how to route messages to recipients. When configuration changes are made, the routing tables are rebuilt. The new routing tables are used to route new incoming messages. Messages in remote delivery queues are also rerouted if the routing component determines that they're affected by the configuration changes. For more information about message rerouting, see "Rerouting and the Unreachable Queue" later in this topic. The following configuration data is retrieved from Active Directory and made available to the routing component of Hub Transport servers:

Active Directory sites Active Directory IP site links Exchange servers and their relationship to Active Directory sites SMTP connectors Non-SMTP connectors Note: Non-SMTP connectors include Exchange 2010 delivery agent connectors, Foreign connectors, and in coexistence scenarios, any non-SMTP connectors hosted

by Exchange 2003. Routing groups Routing group connectors Mailbox stores (private message databases (MDBs)) Public folder stores (public MDBs) Public folder hierarchies Based on this data, the routing component of the Microsoft Exchange Transport service populates routing tables to help streamline routing decisions. The routing table correlates the data to create a topology map. This topology map contains the following elements:

Linked connectors map This map correlates the identifiers of Receive connectors on the local server to the linked Send connector. Server map All Exchange 2010 and Exchange 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the server map. This map correlates the distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. Legacy server map All Exchange Server 2007 Hub Transport servers, Edge Transport servers, Mailbox servers, and Exchange 2003 servers in the organization are contained in the legacy server map. This map correlates the legacy distinguished name of each Exchange server to server routing data. This includes the total cost to reach that server. This map supports store override functionality. Store override functionality is specific to public folders. For more information, see "Routing to Public Folders" in Internal Message Routing. MDB map All MDBs in the organization are contained in the MDB map. This map correlates the distinguished name of each MDB to server routing data. This includes the total cost to reach that server. Active Directory site map This map correlates each Active Directory site to a structure that contains the least-cost routing path from the local site to every other site. The map includes any hub sites along the least-cost routing path. Each routing path hop also identifies all Hub Transport servers in that site that will be used by the enhanced DNS component. Routing groups map This map associates the total cost and first hop routing group connector for the least-cost routing path from the Exchange 2010 routing group to each legacy routing group. Send connectors map This map identifies the Send connectors configured in the organization and the source servers for each connector. The routing tables are built every time that a transport server is started and recalculated when configuration changes are received. Configuration changes can be detected in any of the following ways:

Active Directory change notifications There is a delay between the time that a notification is received and the time that the change is written to the routing tables. This delay lets the routing component batch the changes and process more than one change in a single operation. By default, each notification causes the routing component to delay processing by five seconds. For example, if five notifications are received exactly one second after the previous notification, routing delays processing the change for a total of nine seconds. Configuration reloading caused by service control commands The routing component reloads the configuration data when the Microsoft Exchange Transport service is restarted. Periodic reload to track changes that aren't supported by Active Directory notifications By default, routing will periodically reload the configuration data to make sure that all changes are tracked. The configuration reload occurs at six-hour intervals. The information in the routing tables is logged to routing logs. By default, these logs are located in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing folder. A new log is generated every time that the routing tables are calculated. If for some reason the Hub Transport server is unable to contact Active Directory, routing continues to make routing decisions based on the currently cached data, even though that data may not be up to date. For more information, see Understanding Routing Table Logging. Return to top

Receiving Messages for Routing


A message can arrive at a Hub Transport server in any of the following ways:

E-mail is received from an Internet-facing SMTP server for delivery to a recipient in the Exchange organization or to a recipient in an internal relay accepted domain. E-mail is received from another Hub Transport server in the Exchange organization for delivery to a recipient mailbox that's located on a Mailbox server in that Active Directory site. E-mail is received from SMTP clients. These are typically POP3 or IMAP4 users that may exist in your environment. E-mail is received from Pickup and Replay directories on a Hub Transport server. These directories are typically used by Foreign connectors to transmit messages to your Exchange infrastructure. E-mail is retrieved from an Exchange 2010 Mailbox server by the Hub Transport server. E-mail is received from an Exchange 2007 or Exchange 2003 server for delivery to a recipient mailbox that's located on an Exchange 2010 Mailbox server. Processing of all e-mail that's received by a Hub Transport server for categorization begins in the Submission queue.

Receiving Messages from Edge Transport Servers, Other Exchange Hub Transport Servers, and SMTP Clients
In this scenario, messages are received from Edge Transport servers, Hub Transport servers, or other third-party SMTP hosts by using standard SMTP connections. The remote host initiates an SMTP connection and transfers the messages to the Hub Transport server. Hub Transport servers use Receive connectors for accepting incoming SMTP connections. Each Hub Transport server has two Receive connectors created during setup. One of these connectors is used to receive authenticated SMTP connections from other Exchange servers. The second one is used to receive SMTP connections from SMTP clients used by POP3 or IMAP4 users in your organization. These two Receive connectors have different permissions configured that are appropriate for their intended use. To learn more about Receive connectors, see Understanding Receive Connectors. By default, Hub Transport servers don't accept unauthenticated anonymous connections. If you need to enable this functionality, we recommend that you create a separate Receive connector to handle the anonymous connections. For more information, see Allow Anonymous Relay on a Receive Connector.

Collecting Messages from Pickup and Replay Directories


Messaging systems that don't use SMTP as the transfer protocol can be connected to your Exchange organization using Foreign connectors. When a message is sent to an Exchange user from a remote system, the Foreign connector writes that message to a special directory on the Hub Transport server called the Pickup directory.

The Hub Transport server periodically checks the Pickup directory for new messages. When it detects a new message, the Hub Transport server then converts the message to an Exchange e-mail message and routes it as a regular message. To learn more about how the Pickup and Replay directories are used, see Understanding the Pickup and Replay Directories.

Retrieving Messages from a Mailbox Server


In this scenario, the Microsoft Exchange Mail Submission service that runs on Mailbox servers notifies a Hub Transport server that's located in the same Active Directory site that messages are ready for retrieval from a sender's outbox. Each Mailbox server maintains a list of Hub Transport servers that are located in the same Active Directory site. This list of Hub Transport servers is known as the submission server list. The server discovery process repeats every ten minutes to keep the list up to date. If more than one Hub Transport server is located in the same Active Directory site as the Mailbox server that's submitting a notification that mail is ready for retrieval, the following process is used to select the server:

If the local Mailbox server is also running the Hub Transport server role and it is not participating in a database availability group (DAG), the local server is notified. If the local Microsoft Exchange Transport service isn't running or the local Hub Transport server can't process new mail submissions because of back pressure, another available Hub Transport server is notified. For more information about back pressure, see Understanding Back Pressure. If the local Mailbox server is also running the Hub Transport server role and is also participating in a DAG, it first tries to notify any Hub Transport server in the site before notifying the local Hub Transport server. This is done to avoid having redundant copies of messages on the same server hardware. To learn more about coexisting Mailbox and Hub Transport server roles when using DAGs, see Hub Transport and Mailbox Server Roles Coexistence When Using DAGs. If the local Mailbox server isn't running the Hub Transport server role, notifications are load balanced among Hub Transport servers by using round robin. If the selected Hub Transport server can't be contacted, the Microsoft Exchange Mail Submission service fails over to a different Hub Transport server in the same Active Directory site. The failing server is marked as inactive, and the next Hub Transport server in the submission server list is selected. If no Hub Transport servers in the local Active Directory site are available, the submission server list is empty. In this case, an event is logged and mail submission notifications are temporarily stopped. Hub Transport servers that are marked as inactive are retried after five minutes. By default, the Microsoft Exchange Mail Submission service load balances notification events across the Hub Transport servers in a site so that each Hub Transport server receives an equal distribution of notification events to process. In some circumstances, providing an equal distribution may not be an optimal solution. Not all Hub Transport servers have the same capacity, and some messages require additional processing. For example, a message that has a large attachment or many recipients takes longer for a Hub Transport server to process than a small message that's addressed to only one recipient. If you want to create a static list of Hub Transport servers that a Mailbox server should notify, you can use the Set-MailboxServer cmdlet in the Shell. Use the SubmissionServerOverrideList parameter to specify a list of Hub Transport servers that the local Mailbox server will notify when it has mail for retrieval. For more information about how to configure this setting, see Set-MailboxServer. After a Hub Transport server receives a mail submission notification from a Mailbox server, it uses the store driver to retrieve the message from the mailbox database and put it in the Submission queue on the Hub Transport server. The transfer of the message from the Mailbox server to the Hub Transport server happens by using Exchange RPC.

Receiving Messages from Legacy Exchange Servers


Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. All messages sent from Exchange 2007 recipients are first picked up from the Mailbox servers by Exchange 2007 Hub Transport servers and are then relayed to Exchange 2010 Hub Transport servers. To learn more about message routing when coexisting with Exchange 2007, see Upgrade from Exchange 2007 Transport. As opposed to Active Directory sites, Exchange 2003 uses routing groups to route messages. Routing groups are connected to each other using routing group connectors. To support coexistence between these two routing topologies, all Exchange 2010 servers are automatically added to a single routing group when Exchange 2010 is installed in an Exchange 2003 organization. All messages that originate on Exchange 2003 mailboxes are delivered to the Exchange 2010 environment through the routing group connectors between the Exchange 2010 routing group and the Exchange 2003 routing groups. To learn more about message routing when coexisting with Exchange 2003, see Upgrade from Exchange 2003 Transport. Return to top

Routing Messages
After a Hub Transport server or an Edge Transport server receives a message, it determines the ultimate destination and uses the Exchange topology and connector configurations to determine the least-cost routing path. After the routing path is determined, the message is delivered to the next hop on the routing path. Although this topic explains how Exchange makes routing decisions in general, the following two topics provide additional information about specific routing scenarios. The internal message routing topic discusses message delivery to Mailbox servers, public folders, and legacy servers. The external message routing topic discusses routing messages to recipients that are outside your Exchange organization. The topic also discusses the roles of Send connectors, delivery agent connectors, and Foreign connectors.

Internal Message Routing External Message Routing

Determining the Ultimate Destination


The previous section described the various sources from which a Hub Transport server can receive messages. When a message is received by a Hub Transport server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. A single, deterministic route is selected. That route isn't recalculated unless the routing configuration changes. From the perspective of the sending server, each delivery queue represents the destination for a particular message. When the Hub Transport server or Edge Transport server selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is being sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving server also performs message categorization and queues the

message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination. The destination for a message can be classified as one of the following delivery types:

DNS connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use DNS to resolve the recipient addresses. Smart host connector delivery The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the local server is a source server. The connector is configured to use a smart host for delivery. SMTP relay in an Active Directory site to an Edge Transport server The messages are queued for delivery to an external recipient by using an SMTP Send connector for which the source server is an Edge Transport server that's subscribed to the local Active Directory site. SMTP relay in an Active Directory site to a Hub Transport server The messages are queued for delivery to a Hub Transport server that's located in the same Active Directory site as the local server. The destination server can be an Exchange 2007 Hub Transport server, the source server for a Send connector, a delivery agent connector or Foreign connector, the source server of a routing group connector, or a distribution group expansion server. SMTP relay to a remote Active Directory site The messages are queued for delivery to a Hub Transport server that's located in a remote Active Directory site. The ultimate destination server in the remote Active Directory site can be any of the following: The source server for a connector that's configured to transport messages for external recipients The source server for a routing group connector A distribution group expansion server A Mailbox server that's located in the remote Active Directory site The messages are delivered to one of the Hub Transport servers in the destination site. The receiving server relays the message within the Active Directory site if it's necessary. SMTP relay to a legacy routing group The messages are queued for delivery to the first hop routing group connector used to reach an Exchange 2003 routing group. The ultimate destination server can be any of the following: The source server for a connector An expansion server An Exchange 2003 bridgehead server that delivers messages addressed to mailbox recipients that are located in the routing group MAPI delivery The messages are queued for delivery to a recipient's mailbox, a public folder, or a public folder store that's located on a Mailbox server that's located in the local Active Directory site. Non-SMTP gateway delivery The messages are queued for delivery to an external recipient by using a delivery agent connector or Foreign connector for which the local server is a source server. This delivery type is used only when the messages are being delivered to delivery agent connectors or the Foreign connector drop directory on the local server. Unreachable A route to the recipient couldn't be determined and the messages are located in the Unreachable queue.

Determining the Least-Cost Routing Path


The least-cost routing path to the remote Active Directory site is determined by the calculation of all the costs assigned to the Active Directory IP site links that exist between the two sites. The links are bridged, and a direct connection occurs. Exchange 2010 Hub Transport servers always select a single, deterministic least-cost routing path. Availability of the underlying connection or destination server is never a consideration in routing path selection, and no alternative routing path is considered. The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. In Exchange 2010, backoff is a mechanism used to deliver messages at an interim hop along the least-cost routing path when direct relay fails for any reason, such as network issues or servers going offline. The routing component tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. First, a connection attempt is made to each Hub Transport server in the destination Active Directory site. If no Hub Transport servers in the Active Directory site respond, the least-cost routing path is checked to determine how to start backing off from the delivery site. The goal is to deliver the message as close as possible to the destination and queue it at a Hub Transport server in that Active Directory site. Depending on the individual message routing scenario, the following factors may influence the selection of a least-cost routing path:

Linked connectors If the Receive connector that the message is received on is linked to a Send connector, messages are routed to that Send connector regardless of cost. This configuration always takes precedence. The cost assigned to the IP site links and routing group connectors that must be traversed to reach the destination If more than one routing path exists between a source server and a destination server, the routing path with the lowest aggregate cost is selected. The address space assigned to a Send connector The Send connector with the most specific address space match to the destination is selected. The cost assigned to the address space configured on a Send connector If more than one Send connector is assigned the same address space, the routing component compares the cost assigned to the address space. The Send connector with the lowest cost is selected. Connector scope A connector may be limited to use by Exchange 2010 servers that are located in the same Active Directory site as the source transport servers for the connector. In earlier versions of Exchange, the connector scope could be limited to servers that have the same routing group membership. Message size restrictions The message size constraint specified on a connector must be larger than the size of the message being routed. Connectors with a message size restriction that's less than the size of the message are eliminated from routing consideration. The proximity of the destination to the sending server Routing will prefer the server that's closest, in this order: local server, server in the same Active Directory site, or server in a remote Active Directory site or routing group. The name assigned to an Active Directory site If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the Active Directory sites that precede the target site along each routing path. The routing path where the Active Directory site nearest to the destination is lowest in alphanumeric order is used. The name assigned to a routing group connector If more than one routing path results in the same aggregate cost, the routing component makes an alphanumeric comparison of the name of the routing group connectors that come before the target destination along each routing path. The routing path where the routing group connector nearest to the destination is lowest in alphanumeric order is used. The connector state The Exchange 2010 routing component only considers enabled connectors when it calculates the routing path. However, earlier versions of Exchange don't consider connector state. The following logic is used to select the routing path:

1. First, calculate the least-cost routing path by adding the cost of the IP site links and of any routing group connectors that must be traversed to reach the destination. If the destination is a connector, the cost assigned to the address space is added to the cost to reach the selected connector. If multiple routing paths are possible, only the routing path with the lowest aggregate cost is used. 2. If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used. 3. If more than one routing path is still available, the name assigned to the Active Directory sites or routing group connectors before the destination are considered. The routing path where the Active Directory site nearest the destination is lowest in alphanumeric order is used. If the site nearest the destination is the same for all routing paths being evaluated, an earlier site name is considered. The following figure shows the routing topology for an Exchange organization. This topology is used in the following examples to demonstrate the logic used by the

routing algorithm to select the least-cost routing path. Exchange 2010 routing topology

Example 1 A message that's being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D. Example 2 A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops. Example 3 A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of 10. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E. After the least-cost routing path has been determined, the Exchange 2010 routing component doesn't consider alternative routing paths.

Next Hop Selection


Exchange 2010 Hub Transport servers don't relay to each Active Directory site along the least-cost routing path. After the routing path is determined, the message is relayed directly from the source server to the next hop. The next hop selection tries to deliver the messages as close as possible to the ultimate destination. Additional intrasite relay may be required to arrive at the ultimate destination. When routing to legacy routing groups, direct relay to the Active Directory site where the source server for the first hop routing group connector resides occurs. After the message is relayed to the legacy environment, standard legacy routing occurs. The following figure shows a simple Exchange topology and illustrates many of the Exchange routing components. Exchange topology and routing components

Using the preceding figure as a reference, a message that's sent from Mailbox1 in Site A, to the external recipient joe@contoso.com is processed as follows:

1. The Microsoft Exchange Mailbox Submission service that's running on Mailbox1 notifies an Exchange 2010 Hub Transport server that's located in the same Active Directory site of the new mail item for transport. 2. Using RPC, the store driver component on an Exchange 2010 Hub Transport server in the same Active Directory site retrieves the message and puts it in the Submission queue on the local server. 3. From the Submission queue, the message moves through categorization. The categorizer first performs recipient resolution and determines that

joe@contoso.com is an external recipient. 4. The routing component selects the best connector through which to route the message and calculates the least-cost routing path to that connector. In this example, a Send connector has the address space *.contoso.com and is the connector selected by the routing component. All the source servers for this Send connector are located in Site B. 5. The routing component determines the next hop required to reach a source server for the Send connector. The Hub Transport server in Site A queues the message for SMTP delivery to Site B. 6. If the receiving server in Site B is a source server for the Send connector, it queues the message for delivery to that Send connector. If the receiving server isn't a source server for the *.contoso.com Send connector, the message is relayed by using SMTP to a Hub Transport server in Site B that's the source server for the connector. The following table provides additional examples of the next hop selection for several recipients based on the topology shown in the preceding figure. It isn't a complete list of all routing possibilities. It simply provides examples that are most common in a topology like the one shown in the preceding figure. Examples of next hop selection in the preceding figure

Receiving server Hub1 Hub1 Hub1 Hub1 Hub1 Hub3 Hub4 Hub4 Hub4 Hub4 Edge1

Ultimate destination Mailbox1 Mailbox2 Mailbox3 Mailbox4 Recipient@fourthcoffee.com Mailbox1 Mailbox1 Mailbox4 Recipient@contoso.com Recipient@fourthcoffee.com Recipient@fourthcoffee.com

Next hop Mailbox1 Hub3 Site B Routing group connector Edge1 Hub1 or Hub2 Site A Site A Contoso SMTP Host Site A Fourth Coffee SMTP Host

Queue delivery type MAPI delivery SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a legacy routing group SMTP relay to Edge Transport SMTP relay in an Active Directory site SMTP relay to a remote Active Directory site SMTP relay to a remote Active Directory site Smart host delivery SMTP relay to a remote Active Directory site DNS delivery

After the least-cost routing path has been calculated and the next hop destination has been chosen, Exchange 2010 routing tries to relay the message directly to the destination, unless a hub site is configured along the least-cost routing path.

Queue at Point of Failure


The least-cost routing path calculation is used to determine a backoff path when message delivery to the next hop fails. Exchange 2010 tries to deliver messages as close to the destination as possible by backing off, hop by hop, along the least-cost routing path until a connection is made. This behavior is known as queue at point of failure. When the messages are queued at the point in the delivery path where communication failed, it not only speeds up delivery after the problem is resolved, but it will also help you determine why the message delivery failed. In the topology shown in the following figure, if a message is being delivered from Site A to Site D, the least-cost routing path may be Site A-Site B-Site C-Site D. Delivery will first be tried directly from Site A to Site D. If no Hub Transport server in Site D responds, delivery will be tried to the Hub Transport servers in Site C. This process continues until a Hub Transport server accepts the message. If all intermediate sites are unavailable, the message will be queued at the source site. If the message is queued in Site C, you can start investigating the failure at the Hub Transport servers in Site D or the network connectivity between Site C and Site D. Queue at point of failure

When the message is queued at the point of failure, the queue is put in a retry state and delivery attempts continue based on the message retry intervals until delivery succeeds or the message expires. The queue is automatically resubmitted for categorization again after a default interval of 12 hours. Queues that have a connector as the next hop destination aren't automatically resubmitted unless a configuration change that causes resubmission occurs. For more information, see Message Rerouting and the Unreachable Queue. You can use the Mail Flow Troubleshooter to help diagnose problems with mail flow. This tool is a component of the Microsoft Exchange Troubleshooting Assistant and can be run from the Toolbox of the Exchange Management Console. In more complex topologies, the least-cost routing path between two Active Directory sites can contain many intermediate Active Directory sites. If a network issue occurs somewhere early along the routing path, it may be too inefficient to back off site by site from the end and try to deliver to every one of the intermediate sites. If the routing path is longer than four hops, binary backoff is implemented until four or fewer sites are remaining. Binary backoff means that the next connection attempt is made at the halfway point in the routing path. For example, if the least-cost routing path from Active Directory Site A to Site G is A - B - C - D - E - F - G and the network failure occurs at the link between Site B and Site C, the first connection attempt is made to all Hub Transport servers in Site G. When the connection attempt fails, the next attempt is made to all Hub Transport servers in Site D. This is halfway to Site G. When that connection attempt fails, connection attempts are

made to Site C, and Site B because they're closer than four links to the source site. The message will eventually be queued on a Hub Transport server in Site B until the B-C link connectivity is restored.

Delayed Fan-Out
A single e-mail message can be addressed to more than one recipient. These recipients may have internal mailboxes, or they may be external recipients. To route a single message to more than one recipient, the following steps occur:

1. Recipient resolution Each recipient of the message is resolved to a delivery destination. 2. Routing The least-cost routing path for each recipient is determined. This includes whether a hub site is configured. 3. Message splitting To route the message to recipients that have different delivery locations, the message must be split into multiple copies. After each recipient has been resolved and a routing path to each delivery destination is determined, Exchange 2010 compares the routing path for each recipient. To preserve bandwidth, the bifurcation, or splitting of the message into multiple copies, doesn't occur until a fork in the routing path is encountered. For example, if multiple recipients of a single message share part or all of the least-cost routing path, a single copy of the message is sent until the message reaches the point in the routing path where a fork occurs. When the divergence in routing paths occurs, the message splits to create a separate copy for each recipient. In the following figure, a single message is sent from Site A to recipients in Site C, Site D, and Site E. The least-cost routing path is shared until the message reaches Site B. In this scenario, a single copy of the message that contains all recipients is relayed to Site B. This represents the first fork in the routing path. From Site B, a single message copy is routed to the recipient in Site D, and a single copy is relayed to Site C. In Site C, the message splits again. A copy of the message is delivered to the recipient in Site C. And, a copy of the message is relayed to Site E for delivery to the recipient in that site. Delayed message fan-out

Return to top

Rerouting and the Unreachable Queue


If routing is unable to determine a route for a valid recipient for any reason, the messages are put in the Unreachable queue. Messages in this queue are rerouted when configuration changes are processed and routing tables are recalculated. Messages aren't rerouted in the following scenarios. Instead, an NDR is returned to the sender. The following scenarios result in a message being routed to the Unreachable queue:

The recipient is a non-SMTP address and a matching connector for the address space can't be found. The message doesn't meet the message size restrictions of any matching connector. Not all configuration changes require resubmission of the messages in the queue. For example, a change to the list of smart hosts for a connector doesn't cause messages to be rerouted. For more information about how messages are rerouted, see Message Rerouting and the Unreachable Queue. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

External Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Microsoft Exchange Server 2010 handles the routing of messages to external recipients. An external recipient is any message recipient that doesn't have a mailbox in the Exchange organization. Exchange uses Send connectors to route messages to external SMTP domains. If the external recipient isn't on an SMTP messaging system, a Delivery Agent connector or a Foreign connector is used instead. For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Send Connectors Delivery Agent Connectors Foreign Connectors Connector Considerations Selecting the Routing Path to an External Recipient Routing Examples

Send Connectors

To route messages to external SMTP domains, you must configure at least one Send connector to relay messages to the Internet. You can configure a Send connector and define the address space as the asterisk (*) wildcard character. The * character indicates that the Send connector can be used to relay messages to all external SMTP addresses. You can also configure Send connectors to relay messages to specific address spaces when Send connector restrictions, such as message size, vary for those external domains. When you configure a Send connector, you must select at least one source server for that Send connector. The source servers are the transport servers associated with that connector to handle message delivery. The source server for a Send connector can be a Hub Transport server, an Edge Transport server, or an Edge server subscribed to an Active Directory site. You can configure more than one source server for a Send connector to provide load balancing and fault tolerance for the address spaces defined on that Send connector. However, each Exchange 2010 source transport server you specify must be in the same Active Directory site. For more information about how to configure your Exchange organization to send and receive Internet e-mail, see Managing Message Routing. When Exchange is processing a message sent to an external recipient, the routing component of the Microsoft Exchange Transport service must select the best Send connector through which to route the message, and then calculate the least cost routing path to reach that Send connector. To learn more about Send connectors, see Understanding Send Connectors. Return to top

Delivery Agent Connectors


Delivery Agent connectors are used to route messages addressed to messaging systems that don't use SMTP. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management for non-SMTP messages, thereby eliminating the need for storing messages on the file system in the Drop and Pickup directories. For more information, see Understanding Delivery Agents. Return to top

Foreign Connectors
Foreign connectors are used to send messages to third-party messaging systems. Each Foreign connector uses a Drop directory configured on the source Hub Transport servers for receiving messages. The foreign gateway server must be configured to obtain messages from the Drop directory specified for that Foreign connector. For more information about Foreign connectors, see Understanding Foreign Connectors. Return to top

Connector Considerations
Restrictions applied to the connectors may eliminate a specific connector from routing consideration. The following configuration options on connectors can determine whether those connectors are considered when making routing decisions. For more information about configuring connectors, see Managing Connectors.

Connector State
You can disable and enable any connector in your organization. If a connector is disabled, it's not considered when routing messages. For example, if an Exchange 2010 Send connector is disabled, messages aren't routed to that connector. Note: Exchange Server 2003 doesn't detect the disabled state of connectors. Therefore, if Exchange 2003 is deployed in the same organization, it may route to that connector.

Connector Scope
Routing only considers connectors in scope for the sending server. By default, no scope limitation is applied to connectors, and they are available to all Hub Transport servers in the organization. However, you can specify a local scope for a connector. If you configure a connector as scoped, the availability of that connector is limited to Hub Transport servers located in the same Active Directory site as the source servers for the connector. Scoped connectors aren't considered when routing by Hub Transport servers in other Active Directory sites.

Address Space
The address space for a connector specifies the following:

Recipient domains to which this connector routes e-mail Address space type Cost assigned to the address space for that connector When you create a Send connector, the address space type is always configured as SMTP by default. Even though you can also specify a non-SMTP address space for a Send connector, the messages are still sent using SMTP. If you need to use a different transport protocol for transmitting messages to their destination, you must use a Delivery Agent connector or a Foreign connector. When the Microsoft Exchange Transport service selects a connector for routing, it only considers connectors that have a matching address space for the destination domain. You can use the wildcard character * in an address space to indicate all domains, all domains that have a particular top-level domain, such as *.com, or a second-level domain and all its subdomains, such as *.contoso.com. When you configure a connector for a particular domain, e-mail sent to that domain is always routed through that connector. If more than one connector matches the address space for the destination recipient domain, the connector with the more precise address match is selected. For example, if Send connector C1 is configured to have the address space *.contoso.com and Send connector C2 is configured to have the address space northamerica.contoso.com, e-mail addressed to user@europe.subdomain.contoso.com is routed to Send connector C1 and e-mail addressed to user@northamerica.contoso.com is routed to Send connector C2. Even though the latter address matches the address spaces on both connectors, the address space of C2 is a better match.

Message Size Restrictions


A message size restriction on a connector may also remove that connector from consideration during routing path selection if the message being routed is larger than the size restriction configured on that Send connector.

Cost
Connector cost is used to set selection priority when more than one connector is configured for the same address space. During routing, when the connector selection is made, the lowest cost routing path to the destination is selected. By adjusting connector costs, you can control the preferred routing path for mail flow in your organization and to the Internet. When you create a connector, the default cost is set to 1. Return to top

Selecting the Routing Path to an External Recipient


When a message is sent to an external recipient, Exchange 2010 will always select a single connector through which to send the message. The selected connector must meet the message size constraints. After Exchange 2010 has eliminated all connectors whose message size restrictions are less than the size of the message being routed, routing applies the following criteria to determine which connector it will select:

1. From the list of all the connectors configured in the Exchange organization, Exchange narrows the list to connectors that satisfy all the following criteria: In the scope for the local server Enabled With an address space that matches the recipient's e-mail domain 2. From the resulting list, Exchange selects the connector with the most specific address space match. If more than one connector meets the address space match criteria, Exchange 2010 routing evaluates the following criteria to select a connector:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the IP site links between the source Active Directory site and the Active Directory site that contains the source servers for the connector, and the cost assigned to the connector. The connector with the lowest aggregate cost is selected. If more than one connector has the same cost, the selection process continues to the next step. 2. Proximity The source server that has the closest proximity to the routing server is selected. This means that the local server is chosen over another Hub

Transport server in the same Active Directory site, and a server in the local Active Directory site is chosen over a source server in a remote Active Directory site. If more than one connector matches the criteria, the selection process continues to the next step. 3. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected.

Routing Path Selection When Coexisting with Exchange 2003


In a coexistence scenario, the selection varies slightly depending on whether the source server for the selected connector is an Exchange 2010 or Exchange 2003 server. If more than one connector meets the address space match criteria, and they are all are hosted on servers running Exchange 2003, the following selection method is used:

1. Connector cost The cost of the connector is the sum of the cost assigned to all the routing group connectors between the routing server and the routing group that contains the source servers for the connector and the cost assigned to the connector. 2. Alphanumerically lower connector name If more than one routing path has the same cost and proximity, the connector with the name that has the lowest alphanumeric value is selected. If more than one connector meets the address space match criteria, and they are spread across Exchange 2010 and Exchange 2003, Exchange 2010 will always prefer Exchange 2010 connectors. When a connector is selected, if there are legacy servers listed as source servers as well as Exchange 2010 servers, messages are routed to the Exchange 2010 servers. When all things are equal, Exchange 2010 will always route the messages to other Exchange 2010 servers. After a connector is selected by using the previous criteria, there may be more than one routing path to reach the Active Directory site where the source server for the selected connector is located. In this case, the lowest cost routing path to the connector is calculated by using the logic used for intra-organizational routing. For more information, see Internal Message Routing.

Handling Messages That Can't Be Routed


If no connector satisfies all criteria required to select a connector according to the logic described earlier, one of the following actions occurs:

If there is no matching connector for an SMTP address space, the recipient is marked as unreachable and the message is routed to the Unreachable queue. If the message size exceeds the connector size restriction for all connectors, a non-delivery report (NDR) is returned to the sender. If there is no matching connector for a non-SMTP address space, an NDR is returned to the sender. Return to top

Routing Examples
The following examples illustrate how messages are routed to external recipients.

Example 1: Selecting a Connector Based on Address Space Match


In this topology, a message is being routed from Active Directory Site A to the external recipient, john@subdomain.contoso.com. The following figure shows that two connectors can route messages to this address space.

The following table shows the configuration of two Send connectors in an Exchange 2010 topology.

Examples of Send connector configurations


Send connector name C1 C2 Address space *.contoso.com subdomain.contoso.com Connector cost 1 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

In this scenario, the message is routed by using C2 because the most specific address space match is chosen. C1 has a lower routing cost, and the source servers are located in the same site as the Hub Transport server processing the message. However, the address space match takes priority over the other factors.

Example 2: Selecting a Connector Based on Proximity

In this scenario, a message is being routed by a Hub Transport server located in Active Directory Site A to the external recipient, john@subdomain.contoso.com, as shown in the following figure.

The following assumptions apply:

The routing server isn't listed as a source server for any Send connector. The IP site link between Site A and Site B is assigned a cost of 5. Two Send connectors can route messages to the address space. The following table shows the connector configuration.

Alternative Send connector configuration


Send connector name C1 C2 Address space subdomain.contoso.com subdomain.contoso.com Address space cost 15 10 Source servers Hub Transport servers in Active Directory Site A Hub Transport servers in Active Directory Site B Message size restrictions None None

Because both connectors have the same address space match, the connector cost is evaluated next. The cost assigned to connector C2 is added to the cost of the IP site link between Active Directory Site A and Site B, for a combined cost of 15. The source servers for connector C1 are located in the local Active Directory site. Therefore, the IP site link cost to reach the connector is 0, for a total cost of 15. In this scenario, both connectors match the address space equally and have an equal cost. Routing selects connector C1 because it has a closer proximity.

Example 3: Selecting a Connector Based on Exchange Version


In the next example, a message is being relayed from Active Directory Site A to the external recipient, john@contoso.com, as shown in the following figure.

The following assumptions apply:

There are two Send connectors that match the destination address space equally. The source servers for the routing group connector between Exchange 2003 and Exchange 2010 are located in Site A. The routing group connector has a routing cost of 5. The IP site link between Site A and Site B is assigned a cost of 5. The source server for one of the Send connectors is an Exchange 2003 server located in routing group 1. The following table shows the connector configuration.

Connectors configured on different versions of Exchange


Connector name C1 C2 Address space *.contoso.com *.contoso.com Address space cost 10 1 Source servers Hub Transport servers in Active Directory Site B Exchange 2003 bridgehead servers in routing group 1 Message size restrictions None None

In this scenario, the aggregate cost of using connector C1 is 15, which is the sum of the IP site link cost and the Send connector cost. The aggregate cost of using connector C2 is 6, which is the sum of the routing group connector cost and the Send connector cost. However, even though C1 has a lower routing cost, Exchange will still route the message to the Exchange 2010 connector. Return to top

2010 Microsoft Corporation. All rights reserved.

2013 Microsoft. All rights reserved.

Message Rerouting and the Unreachable Queue


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 In Microsoft Exchange Server 2010, there are message routing scenarios where a message that isn't delivered is put in the Unreachable queue or rerouted. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. The decision to reroute a message occurs during the message delivery phase in the SMTP Send connector process. If there are configuration changes that require a message in the queue to be resubmitted, the message is resubmitted for categorization in the message delivery phase and rerouted with the new configuration information. Depending on the type of configuration change, some or all resubmitted messages may be sent to the Unreachable queue or to a different delivery queue. For more information about how the least-cost routing path is computed, see Understanding Message Routing. For more information about how the categorizer works, see Understanding Transport Pipeline. Looking for management tasks related to message routing? See Managing Message Routing.

Message Rerouting
There are two types of message delivery in Exchange:

Local delivery refers to delivery of messages sent to a recipient with a mailbox in the same Active Directory site as the Hub Transport server on which categorization occurred. Remote delivery refers to delivery of messages to recipients in other Active Directory sites of the Exchange organization and to external recipients. Remote delivery queues are the main focus of message rerouting. Remote delivery can be affected by configuration changes in various ways. The routing component of the categorizer tries to detect whether messages in a queue must be rerouted during enhanced Domain Name System (DNS) resolution. During enhanced DNS resolution, routing tries to detect if a queue has to be rerouted. In this phase, the NextHopSolutionKey attribute is resolved to a list of targets. This enables routing to automatically detect any configuration changes that invalidate or modify the NextHopSolutionKey attribute. If routing detects that configuration changes require rerouting of messages in a queue, the messages in the affected queue are resubmitted to the categorizer and the least cost path is recalculated, taking the new configuration changes into account. The store driver, which delivers inbound messages to the Exchange databases, may also reroute messages. It resubmits a message for rerouting if either of the following conditions is true:

The message is in a MAPI delivery queue, and the next hop has been selected, but the message hasn't been delivered. The destination mailbox is moved to another Mailbox server. If a Mailbox server is unavailable when the store driver tries to deliver the messages to that Mailbox server, the store driver puts the message queue in a retry state. If continued attempts to contact the Mailbox server are unsuccessful, when the retry interval expires, all messages in the queue are resubmitted to the categorizer. If a message is located in a non-SMTP gateway delivery queue (a queue being routed to a Delivery Agent connector or a Foreign connector), the foreign gateway connection handler determines whether the configuration change requires rerouting. The foreign gateway connection handler is a component of the Microsoft Exchange Transport service that manages delivery of messages to Delivery Agent connector queues and Foreign connector Drop directories. For example, deleting or disabling a Foreign connector requires rerouting messages to another connector. The following list summarizes the types of configuration changes that affect message routing. Each configuration change is discussed in detail later in this topic:

Invalid next hop The next hop for the message has been deleted or modified, therefore invalidating the previously calculated routing path. The next hop for a message may be an Active Directory site, a connector, or a transport server (either a Hub Transport server or Edge Transport server). Changes to next hop The configuration of the next hop has changed in a way that affects connectivity. For example, changes to the list of Hub Transport servers in the remote Active Directory site cause the next hop connection to be modified. Less preferred routing paths When configuration changes occur along a previously computed routing path, messages already routed are delivered if the routing path is reachable. But new messages are rerouted with the updated configuration changes. Unavailable next hop Network connectivity or target server availability cause the next hop to be unavailable for connectivity. However, the next hop doesn't change. An example is when the Hub Transport servers in an Active Directory site are offline. Additional scenarios where rerouting occurs In some cases, configuration changes may be caused when DNS MX resource record resolution fails for a DNS connector or a smart host connector. Configuration changes that cause message rerouting or delay When specific configuration changes are detected during the message delivery phase, routing actions occur, and messages are rerouted or delivery is delayed.

Invalid Next Hop


Configuration changes can invalidate a previously calculated next hop. In these circumstances, the routing component of the categorizer can detect the configuration change and reroute to compensate for that change.

Delivery to an SMTP Connector on the Local Computer


When a message is being delivered to an SMTP connector on the local computer, the server that received the message for relay to its destination is also the source server for the Send connector through which the message is routed. This kind of delivery occurs when either of the following conditions is true:

The message was received on a linked Receive connector. The recipient has an external address, and a source server for the selected connector is the local computer.

If the Send connector selected by the routing component of the categorizer is deleted or disabled, the configuration change is detected during the message delivery phase. This causes all messages in the queue to be categorized again. If the configuration of the Send connector is changed to remove the local server as a source server of the connector, the configuration change is detected during the message delivery phase, and all messages in the queue are categorized again. A change of the address resolution method of the Send connector causes the queue to be rerouted. A Send connector can be configured to use DNS to resolve MX records and route messages automatically or it can be configured to route all messages through one or more smart hosts. If you change the address resolution of a Send connector, the messages routed through that Send connector are rerouted.

SMTP Relay in an Active Directory Site


SMTP message relay in an Active Directory site occurs in the following scenarios:

The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Hub Transport server located in the local Active Directory site. The recipient has an external address, and at least one of the source servers for the Send connector is an Exchange 2010 Edge Transport server subscribed to the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2007 in the local Active Directory site. The recipient's mailbox is located on a server that runs Exchange Server 2003, and at least one of the source servers for the selected routing group connector is an Exchange 2010 Hub Transport server in the local Active Directory site. The recipient is a distribution group, and the expansion server for the group is an Exchange 2010 Hub Transport server in the local Active Directory site. In the first four scenarios, if the Send connector is deleted or disabled, the configuration change is detected during the message delivery phase, and the queue is resubmitted. In the last scenario, the messages are queued for delivery to an expansion server and the NextHopSolutionKey attribute contains the fully qualified domain name (FQDN) of the expansion server for the distribution group. If the Hub Transport server role is uninstalled from the specified expansion server, that configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to a Remote Active Directory Site


When a message is being delivered to a remote Active Directory site, the next hop is a different Active Directory site than the Hub Transport server processing the message. This kind of delivery occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder, and the destination computer is an Exchange 2010 server in a remote Active Directory site. The recipient is an external address, and the source servers of the Send connector selected for that address are Exchange 2010 servers in a remote Active Directory site. The recipient is an external address, and the source servers of the Foreign connector selected by the routing component of the categorizer are Exchange 2010 servers in a remote Active Directory site. The recipient is a distribution group, and the expansion server is an Exchange 2010 Hub Transport server in a remote Active Directory site. The recipient's mailbox is located on an Exchange 2003 server, and the closest Hub Transport server listed as a source server for the selected routing group connector is located in a remote Active Directory site. In these scenarios, if the remote Active Directory site is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

SMTP Relay to an Exchange 2003 Server


When a message is being delivered to an Exchange 2003 server, the Exchange 2010 Hub Transport server relays the message through a routing group connector to an Exchange 2003 server. This delivery type occurs in the following scenarios:

The recipient is a resolved user, mailbox database, or public folder located on an Exchange 2003 server. The recipient is an external address, and the source servers for the SMTP connector selected for that address are Exchange 2003 servers. The recipient is an external address, and the source servers for the selected Foreign connector for that address are Exchange 2003 servers. The recipient is a distribution group, and the designated expansion server is an Exchange 2003 server. In these scenarios, if the routing group connector is deleted, the configuration change is detected during the message delivery phase, and the queue is resubmitted.

Changes to Next Hop


In some scenarios, the next hop isn't invalidated. However, it's modified in a way that affects the connection to a next hop target. Such configuration changes are automatically detected during the message delivery phase, and messages are delivered to the new targets. The following types of changes cause an update of the list of next hop targets:

Changes to the target server list of a routing group connector. Changes to the list of Hub Transport servers in the remote Active Directory site. Changes to the list of Hub Transport servers or Edge Transport servers in the local Active Directory site. The introduction of hub sites along a previously calculated routing path. When this change is detected during the message delivery phase, the IP address list returned to the resolve request is adjusted so that the message is sent to the hub site.

Less Preferred Routing Paths


If a configuration change causes the previously calculated routing path to become less preferred or removes the routing path from consideration, the routing path is still reachable and the messages can still be delivered along the previously calculated routing path. The following configuration changes are in this category:

Message size restrictions are added along the routing path. This causes messages that exceed the size limit to be routed along a different routing path. A routing path with better cost or proximity is created. The address space of the connector changes. Other connector-related changes occur, such as the enabling of a connector or modification of the scope for a connector. For example, if a connector whose scope is changed from global to scoped is in the local Active Directory site, the change has no effect. If the connector is in a remote Active Directory site, the change isn't detected during the message delivery phase because the messages are queued to the remote Active Directory site instead of to the connector. As the routing path tries to SMTP-relay to a Mailbox server in the remote Active Directory site, the Mailbox server moves from a remote Active Directory site to a local Active Directory site. The routing path is trying to reach the expansion server for a distribution group when it's no longer an expansion server. In these scenarios, existing messages are delivered along the already calculated routing path. Because the routing path exists and is reachable, messages already routed are unaffected by these configuration changes. However, newly submitted messages are routed by using the updated configuration.

Unavailable Next Hop


In this scenario, a configuration change or network connectivity change doesn't invalidate the next hop to which messages are routed but a configuration change or network connectivity change makes the next hop unavailable. This means that an SMTP connection can't be established to the next hop target for some reason. Possible reasons are as follows:

An attempt is made to establish an SMTP connection with a currently offline Hub Transport server in the local site. A remote Active Directory site has unavailable or offline Hub Transport servers. A remote routing group has unavailable or offline Exchange 2003 bridgehead servers. Remote domains are unavailable because of network connectivity issues. Message delivery failures caused by network connectivity problems aren't detected by the routing component of the categorizer. When an SMTP connection can't be established to the next hop target, the SMTP Send connector retries the queue. The MaxIdleTimeBeforeResubmit parameter, which is located in the EdgeTransport.exe.config file, has a default value of 12 hours. After the configurable retry interval (MaxIdleTimeBeforeResubmit) has expired without successfully establishing a connection, all messages from the delivery queue are resubmitted to the Submission queue. If the connectivity problem still exists, this process is repeated. If the connectivity problem is resolved, messages are delivered as soon as message retry is successful. Or, a configuration change that modifies the next hop destination may resolve the problem. For example, if the problem is caused by all the Hub Transport servers in a destination site being offline, and you move mailboxes to a server in a different site, the next hop would change to the new site. Note: The automatic resubmission from the message delivery queue to the Submission queue only happens for queues that aren't connector queues. Connector queues remain in retry mode until the problem is fixed, or the messages expire and a non-delivery report (NDR) is sent.

Additional Scenarios Where Rerouting Occurs


In addition to the scenarios described earlier in this section, the following scenarios cause messages to be rerouted during the message delivery phase:

DNS MX resolution fails for a DNS connector. If the DNS MX resolution fails because the authoritative host for the MX record wasn't found, an NDR for the messages in the queue is sent immediately. If other types of failures exist, the queue is put into retry mode until a connection is established or the messages expire. DNS MX resolution fails for a smart host connector. The queue is put into retry mode until the messages expire.

Configuration Changes That Cause Message Rerouting or Delay


The following table summarizes the routing actions taken when specific configuration changes are detected during the message delivery phase, and messages are rerouted or delivery is delayed.

Configuration changes that cause message rerouting and delay


Routing scenario Message is routed to a DNS connector configured on the local server. Configuration change The connector is deleted. The connector is changed to a smart host connector. The connector is modified to remove the local server from the source server list. A fatal DNS MX resolution failure occurs. A DNS MX resolution failure that isn't fatal occurs. Routing action The queue is resubmitted. The queue is resubmitted. The queue is resubmitted. Configuration change and routing action

An NDR is sent. The queue is retried until messages

expire. The connector is disabled. The queue is resubmitted.

Message is routed to a smart host connector configured on the local server. Configuration change The connector is deleted. The connector is modified to remove the local server from the source server list. The connector is changed to a DNS connector. The smart host list for the connector is modified. Any DNS MX resolution failure occurs. The connector is disabled. The SMTP server is offline or the destination isn't running an SMTP server. Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted.

The updated smart hosts list is automatically detected and used during the message delivery phase. The queue is retried until messages expire. The queue is resubmitted. The queue is retried until messages expire.

Message is routed to a connector with a source Hub Transport server or Edge Transport server in the local Active Directory site.

Configuration change The connector is deleted. The source server list for the connector is modified to remove or add Hub Transport or Edge Transport servers in the local Active Directory site. The source server list for the connector is modified to remove all Hub Transport or Edge Transport servers in the local Active Directory site.

Routing action The queue is resubmitted. Changes to source servers in the local site are automatically detected and used during the message delivery phase. The queue is resubmitted.

Message is routed to an expansion server for a distribution group in the local Active Directory site. Configuration change The server is no longer configured for the Hub Transport server role. Routing action The queue is resubmitted.

Message is routed to a transport server in the local Active Directory site. Configuration change The server is offline or the Microsoft Exchange Transport service isn't running. Routing action The queue is resubmitted after an interval.

Message is routed to a remote Active Directory site. Configuration change The remote Active Directory site is deleted. The link to the remote Active Directory site is deleted. Therefore, the site is unreachable from the local site. The list of Hub Transport servers in the remote Active Directory site changes. All Hub Transport servers in the remote Active Directory site are removed. Hub sites are introduced along the routing path of the destination Active Directory site. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase so that the messages are relayed to the hub site. The queue is resubmitted after an interval.

All Hub Transport servers in the remote

Active Directory site are offline. The remote site is the delayed fan-out point, and all Hub Transport servers in the site are offline. The queue is resubmitted after an interval.

The message is routed to an Exchange 2003 server in a remote routing group. Configuration change The connector is deleted. The source Hub Transport server list for the connector changes to remove the local server from the list. The target bridgehead server list for the connector is changed by removing or adding bridgehead servers in the remote routing group. All Exchange 2003 bridgehead servers in the remote routing groups are offline. Routing action The queue is resubmitted. The queue is resubmitted.

Changes are automatically detected and used during the message delivery phase. The queue is retried until messages expire.

The message is routed to a destination, and there are configuration changes, but the destination is still reachable.

Configuration change The routing path becomes less preferred because a new routing path appears with a reduced cost or closer proximity, or both.

Routing action Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase. Changes are automatically detected and used during the message delivery phase.

The routing path is removed for a message because maximum message size restrictions are added along the path.

A previously disabled routing path comes into consideration with a reduced cost because the connector is enabled, put back in scope, or has no message size restrictions. The connector address space changes.

The connector is changed to add local Hub Transport or Edge Transport servers to the source server list.

The message is relayed to a Mailbox server in the remote Active Directory site, while the Mailbox server housing the destination mailbox database is moved to a different site. The message is relayed to a distribution group expansion server when it's no longer an expansion server. (The distribution group's HomeMTA attribute is modified.)

The message is routed by using MAPI delivery to a Mailbox server. Configuration change The mailbox moves to a different Mailbox server. The Mailbox server is offline. Routing action The store driver detects the change and resubmits the messages. The queue is retried and resubmitted after an interval.

The message is routed by using a non-SMTP gateway to a non-SMTP connector configured on the local server.

Configuration change A Foreign connector is deleted. A Foreign connector is modified to remove the local server from the source server list. The connector is disabled. The Drop directory isn't found.

Routing action The queue is resubmitted. The queue is resubmitted.

The queue is resubmitted. The queue is retried until

messages expire.

Unreachable Queue
The Unreachable queue contains messages that can't be routed to their destinations. Typically, an unreachable destination is caused by misspelled e-mail addresses, or configuration changes that have modified the routing path for delivery. Regardless of destination, all messages that have unreachable recipients reside in this queue. The decision to put a message in the Unreachable queue is made during the routing phase of categorization. If a routing path can't be calculated for a message during the routing phase, the message is sent to the Unreachable queue. Messages in the Unreachable queue are rerouted after configuration changes are processed. There is only one Unreachable queue for each Exchange 2010 transport server. During categorization, messages are put in the Unreachable queue when the following conditions are true:

The recipient is a valid Active Directory recipient object. However, a routing path can't be calculated for that recipient. The recipient is an external SMTP address and a matching connector can't be found for the address space. A matching connector may also be ignored by the routing component of the categorizer because it's disabled or configured incorrectly. The recipient is a distribution group. The expansion server for the distribution group is invalid or doesn't have the Hub Transport server role installed. The recipient is an SMTP address recipient of a message received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because it's disabled or configured incorrectly in some way. In the following scenarios, messages aren't put in the Unreachable queue, and NDRs are sent instead:

The routing path can't be calculated for a recipient because constraints, such as message size restrictions, prevent delivery of the message using the single, deterministic route calculated by the categorizer. The recipient is a non-SMTP address and a matching connector can't be found. Or the matching connector is disabled or configured incorrectly. The recipient is a non-SMTP address recipient received on a Receive connector linked to a Send connector that's ignored by the routing component of the categorizer because the Send connector is disabled or configured incorrectly. Messages in the Unreachable queue are resubmitted to the categorizer when the routing tables are rebuilt because of configuration changes. The old routing tables and new routing tables are compared. The Unreachable queue is resubmitted only if the old routing tables and new routing tables aren't the same.

Scenarios Where Messages Are Put in the Unreachable Queue


This section describes some scenarios where messages are put in the Unreachable queue.

Routing group connector between an Exchange 2010 organization and Exchange 2003 organization doesn't exist A routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups hasn't been configured, or the last routing group connector between the Exchange 2010 routing group and Exchange 2003 routing groups has been removed. No routing group connector exists to provide a routing path to the Exchange 2003 recipients. To resolve this problem, first verify that the routing group connector is missing. If that's the case, you can create a routing group connector. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. If a routing group connector does exist, the message is in the Unreachable queue for some other reason. Check the configuration of the routing group connector.

Destination Active Directory site doesn't have Hub Transport servers The destination Active Directory site has no Hub Transport servers. In this scenario, messages to recipients in that site are sent to the Unreachable queue. To resolve this problem, deploy a Hub Transport server in the Active Directory site. For more information, see Overview of the Hub Transport Server Role.

Active Directory site link doesn't exist between two Active Directory sites An Active Directory site link has been removed and as a result, a disconnected Active Directory site contains Exchange 2010 servers. To resolve this problem, create an Active Directory site link by using Active Directory Sites and Services.

Other issues When a message is put in the Unreachable queue, the last error message specifies why the message was placed in the Unreachable queue. If more than one recipient of the same message is routed to the Unreachable queue, but for different reasons, the last error available on each recipient specifies the reason for each. When inconsistencies are found during routing table computation, events are logged in the Application log of Windows Event Viewer. The last error message and these events can help you determine the configuration error and make corrections so that messages in the Unreachable queue can be routed successfully. You can also manually force the messages in queues to be resubmitted. For more information, see Resubmit Messages in Queues.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Internal Message Routing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-12-07 Internal message delivery involves a routing process that relays e-mail in the following ways:

From a server running Microsoft Exchange Server 2010 that has the Hub Transport server role installed to an Exchange Server 2007 or Exchange 2010 Hub Transport server in a different Active Directory site From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server located in the same Active Directory site From an Exchange 2010 Hub Transport server to a Hub Transport server running Exchange 2007 for delivery to a recipient mailbox located on an Exchange 2007 server From an Exchange 2010 Hub Transport server to a server running Exchange Server 2003 for delivery to a recipient mailbox located on an Exchange 2003 server From an Exchange 2010 Hub Transport server to an Exchange 2010 Mailbox server for delivery to a mail-enabled public folder For more information about how Exchange makes routing decisions, see Understanding Message Routing. Looking for management tasks related to message routing? See Managing Message Routing. Contents Routing Messages for Delivery to Exchange 2010 Servers Routing Messages for Delivery to Exchange 2007 Servers Routing Messages for Delivery to Exchange 2003 Servers Routing to Public Folders

Routing Messages for Delivery to Exchange 2010 Servers

In Exchange 2010, after a message is received by the Hub Transport server, the message is added to the Submission queue. Messages move from the Submission queue through the categorizer. When the message is categorized, a recipient's e-mail address is resolved to an object in Active Directory. This query determines the mailbox associated with that e-mail address and which Mailbox server is hosting that mailbox. After information about the recipient is resolved, the next step is resolving the Mailbox server to an Active Directory site. This Active Directory site information is stamped on the message as the NextHopSolutionKey attribute. The enhanced DNS component of the Microsoft Exchange Transport service accesses the topology information to determine which Hub Transport servers are located in the same site as the destination Mailbox server. A list of Hub Transport servers in the Active Directory site is then referenced to determine where to route the message. If the destination Mailbox server is located in the same site as the querying Hub Transport server, that Hub Transport server queues the message for local delivery. If the destination Mailbox server is located in a different site, the local Hub Transport server queues the message for remote delivery to that Active Directory site. A message queued for local delivery is submitted to the destination mailbox store by the store driver. The message is transferred from the Hub Transport server to the Mailbox server by using an Exchange remote procedure call (RPC). A message queued for delivery to a remote Active Directory site is transferred by using SMTP. Before the message is relayed, the routing component of the categorizer selects the least cost routing path. The method for determining the least-cost routing path is explained in detail in "Determining the Least-Cost Routing Path" in Understanding Message Routing. Return to top

Routing Messages for Delivery to Exchange 2007 Servers


Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can't pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly, Exchange 2007 Hub Transport servers can't communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site. When a Hub Transport server queries Active Directory to determine the Mailbox server hosting the destination mailbox, it also retrieves the version of the Mailbox server. If the Mailbox server is an Exchange 2007 server that's in the same site as the Hub Transport server, the Hub Transport server will relay the message to an Exchange 2007 Hub Transport server in the same Active Directory site. The process of using the version information to make routing decisions is called versioned routing and is explained in detail in Upgrade from Exchange 2007 Transport. If the Mailbox server is in a different Active Directory site, the message is queued for delivery to that remote site and is transferred by using SMTP. Return to top

Routing Messages for Delivery to Exchange 2003 Servers


The routing topology and components of Exchange 2010 differ significantly from those of Exchange 2003 but generally correlate in the following ways:

The Active Directory site in Exchange 2010 correlates to routing groups in Exchange 2003. IP site links in Exchange 2010 correlate to the concept of routing group connectors in Exchange 2003. The functionality of the Hub Transport server role in Exchange 2010 correlates to the functionality of a dedicated bridgehead server in Exchange 2003. However, each Exchange version differs in the method used to determine routing paths. For more information about the routing differences, see Upgrade from Exchange 2003 Transport. A message relayed from a Hub Transport server to an Exchange 2003 server for delivery to a recipient mailbox located on an Exchange 2003 server must be relayed across a routing group connector. All Exchange 2010 servers are associated with a single routing group named Exchange Routing Group (DWBGZMFD01QNBJR) for the purposes of routing to earlier versions of Exchange when Exchange 2010 coexists in the same organization with Exchange 2003. Placement of Exchange 2010 and earlier versions of Exchange in the same routing group isn't supported. Therefore, at least one routing group connector will always separate Exchange 2010 servers from Exchange 2003 servers. When an Exchange 2010 Hub Transport server determines the least-cost routing path to an Exchange 2003 server, the routing component of the Microsoft Exchange Transport service uses the following algorithm to select the least-cost routing path to a computer running Exchange 2003:

1. Examine all possible routing paths across routing group connectors and select the routing path that has the least total cost. 2. If more than one routing path has the same cost, examine all possible routing paths across IP site links to reach the first routing group connector and select the routing path that has the lowest total IP site link cost. 3. If more than one routing path has the same routing group cost and has the same IP site link cost, select the routing path that includes the least number of hops. 4. If more than one routing path has the same routing group cost, the same IP site link cost, and the same number of hops, select the routing path where the name of the last Active Directory site before the destination site has the lowest alphanumeric value. The following figure shows an example of a routing topology where Exchange 2010 and Exchange 2003 coexist.

In this example, a message is being routed from a Hub Transport server in Site A to an Exchange 2003 server located in routing group 2. Two possible routing paths exist to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 20. This routing path has a total cost of 30. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this example, Option 2 has a lower total routing group connector cost, and the message is routed from the Hub Transport server in Site A, to a Hub Transport server in Site C where it's queued for delivery by using routing group connector C1. The previous example shows how the routing decisions may not result in optimal routing due to the assigned costs on the routing group connectors. To maintain optimal routing, you may need to modify the routing group connector costs you have in your organization. The following figure shows the same topology, but with the cost of routing group connector 2-3 changed to 10.

Again, two possible routing paths are available to reach routing group 2:

Option 1: From routing group connector A3 at a cost of 10, to routing group connector 2-3 at a cost of 10. This routing path has a total cost of 20. Option 2: From routing group connector C1 at a cost of 10, to routing group connector 1-2 at a cost of 10. This routing path has a total cost of 20. In this scenario, both options have the same total routing group connector cost. Routing next evaluates the cost of the IP site links that must be crossed to reach the first routing group connector. From Site A, the IP site link cost to reach routing group connector A3 is zero, and the cost to reach routing group connector C1 is 20. Therefore, the routing path described in Option 1 is selected. Return to top

Routing to Public Folders


Public folders can be mail-enabled in Exchange. Users can send messages to mail-enabled public folders just like any other recipient. When a Hub Transport server receives a message sent to a mail-enabled public folder, the following routing process applies:

1. The categorizer must determine which public folder hierarchy in which the public folder resides. 2. The categorizer looks up the homeMDB attribute for the public folder. The homeMDB attribute identifies the public folder hierarchy where the destination public folder is located. 3. Based on the routing table calculations performed by the Microsoft Exchange Transport service, and described in "Selecting the Destination Public Folder Database" later in this topic, the preferred public folder database is used to determine which public folder hierarchy contains a replica of the destination public folder. If the preferred public folder database is located in the same Active Directory site as the routing Hub Transport server, message processing proceeds as described in step 4 in this section. If the preferred public folder database is located in a remote Active Directory site, the message is relayed to that site by using the least cost routing path. The message categorization process described in step 1 and step 2 earlier in this section are repeated by the Hub Transport server that receives the message in the remote site. If the preferred public folder database is located on an Exchange 2007 or Exchange 2003 server, the message is relayed to the Exchange 2007 Hub Transport server or the Exchange 2003 bridgehead server, and message delivery is determined by the earlier version of Exchange. 4. The Hub Transport server establishes a connection to the store driver on the Mailbox server that contains the preferred public folder database. The public folder database is queried to determine whether content for the public folder is available. The identity of the destination folder is referenced by the legacyExchangeDN attribute, and content availability is determined by the value of the IsContentAvailable attribute. The store driver either accepts the message for delivery, or if the folder contents aren't available locally, the store driver responds with a list of alternative servers that contain a replica of that public folder. The behavior of returning an alternative list of servers is known as store override. The alternative list of servers that contain the public folder replica is listed in the same order provided in client folder referrals, and the top entry is chosen by transport. This referral is provided to routing as the destination to which the message should be routed. For more information about client folder referrals, see Configure Public Folder Referrals. 5. If store override occurs, the Hub Transport server uses the routing table to determine the least cost routing path to the server that contains the preferred public folder replica and routes the message to that destination. 6. The message is delivered to the public folder store.

Selecting the Destination Public Folder Database


Public folders are stored in databases created on Mailbox servers. For efficiency and fault tolerance, you can replicate the content in your public folders to multiple Mailbox servers. Public folder content exists only in Exchange databases configured to have a replica of a specific folder, whereas the hierarchy is replicated to all public folder databases. Content and hierarchy information are replicated separately. Public folder hierarchies are retrieved when routing tables are calculated. The top-level hierarchy object has a list of all the public folder databases to which that hierarchy is replicated. This list of public folder databases is stored as the msExchOwningPFTreeBL attribute in Active Directory. The msExchOwningPFTreeBL attribute always lists the most recently added public folder databases at the top of the list. In Exchange 2010, the preferred public folder hierarchy database is selected by using the following criteria:

1. Ranking by the age of the public folder database By default, public folder databases that have an age threshold of less than two days aren't considered unless the age of all public folder databases is less than the threshold or the age is unknown. 2. Proximity Thelocal server is preferred. If the local server doesn't contain a replica of the public folder database, a server in the same Active Directory site is preferred. If the local Active Directory site doesn't contain a replica of the public folder database, a server in a remote Active Directory site or routing group is selected as the preferred destination. 3. Cost If more than one remote Active Directory site or routing group contains a replica of the public folder database, the server in the Active Directory site or routing group that has the least cost routing path from the local Active Directory site is selected as the preferred destination. If more than one server still meets the criteria, the first server in the replica list returned by Active Directory is selected. After the hierarchy is read, Exchange then determines which public folder databases have replicas of the content. To make sure that correct message delivery can occur to the public folder replica, a preferred public folder database is selected by the routing component of the Microsoft Exchange Transport service from the msExchOwningPFTreeBL list. This selection is made by using the following evaluation process:

1. If only a single instance of a public folder database exists, the server that hosts that database is selected. 2. If the list contains any public folder databases located on servers running Exchange 2007 or Exchange Server 2003, these public folder databases are removed from consideration as the preferred public folder database if a replica also exists on an Exchange 2010 Mailbox server. 3. If more than one Exchange 2010 public folder database is available, the following criteria are used to select a preferred public folder database: a. Ranking by the age of the public folder database The older a public folder database is, the more likely it is to have a replica of the target public folder. Therefore, all public folder databases listed in the msExchOwningPFTreeBL list are ranked according to their date of creation by using a configurable number of days as a baseline. The age ranking for each public folder database can be one of the following, listed from best to worst: More than baseline days old Less than baseline days old Unknown The public folder database that has the best age rating is selected as the preferred public folder database. By default, the baseline age for public folder replicas is two days (48 hours). You can modify this value by editing the PFReplicaAgeThreshold key in the EdgeTransport.exe.config file. This file is located in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin directory on a computer running Exchange 2010. b. Proximity If more than one public folder database has the best age rating, the Mailbox server that has the best proximity rating is selected. The proximity rating for each public folder database can be one of the following, listed from best to worst: Local server If the local server contains a replica of the public folder database, it's selected as the preferred destination for routing to public folders contained in that hierarchy. Server located in the local Active Directory site If more than one server on the list is located in the local Active Directory site, the first server on the list is selected as the preferred destination for routing to public folders contained in that hierarchy.

Server located in a remote Active Directory site If the list contains servers from multiple remote Active Directory sites, the server in the Active Directory site that has the least cost routing path from the local Active Directory site is selected as the preferred destination for routing to public folders contained in that hierarchy. If there is more than one server in that site that has a replica of the public folder database, the first server on the list is selected. If more than one remote Active Directory site has the same value for the least cost routing path, the first server on the list is selected. 4. If no public folder database replica is located on an Exchange 2010 Mailbox server, a public folder database located on an Exchange 2007 server is selected as the preferred destination. If there are no Exchange 2007 servers, a public folder database located on an Exchange 2003 computer is selected as the preferred destination for routing to public folders contained in that hierarchy. In either case, the destination public folder database is selected by the age ranking of the public folder database. The age ranking is determined by using the same method as for an Exchange 2010 server. If more than one public folder database has the same age ranking, the first server on the list is selected. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Using Exchange 2010 Transport to Relay Application Server SMTP Traffic


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-01-16 In Microsoft Exchange Server 2010, the Receive connector and load-balancing concepts remain the same as in Exchange Server 2007. Heres a quick review of those concepts. In Exchange 2007, Receive connectors are used to accept incoming messages. By default, when an Exchange Server 2007 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named Default Receive connector. In addition, Exchange 2007 automatically load-balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load-balancing of messages received from non-Exchange sources, such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients. For more information about how you configure load balancing for messages received from non-Exchange sources, see Understanding SMTP Failover and Load Balancing in Transport. If you place a load-balancing solution in front of your Hub Transport servers, you need to create a separate Receive connector for that purpose and make sure that only traffic processed by that specific connector is subject to load balancing. This is achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector.

Changes in Behavior with Exchange 2010


Exchange 2010 introduces the shadow redundancy feature which provides redundancy for messages for the entire time theyre in transit. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. Because shadow redundancy is an Exchange 2010 feature, shadow redundancy is only supported by Exchange 2010 servers. If an Exchange 2010 transport server receives messages from a previous version of Exchange Server or a non-Exchange source, the source server cant send the expected XSHADOW command. Therefore, shadow redundancy isnt used. Non-Exchange sources include external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization or line-of-business (LOB) applications the source server. However, when an Exchange 2010 transport server receives a message from a non-Exchange 2010 source, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the sending server until it verifies that the message has been successfully delivered to all next hops internally. This way, if the Exchange 2010 server fails, the sending server assumes that the message was never delivered to Exchange and attempts delivery again. The delayed acknowledgement time-out is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds. For more information about shadow redundancy, see Understanding Shadow Redundancy. Customers who have upgraded from Exchange 2007 to Exchange 2010 and use dedicated Receive connectors for the purpose of relaying messages from sources such as line-of-business (LOB) applications may see a significant decrease in SMTP throughput. This decrease in throughput is because of the default delayed acknowledgement time-out of 30 seconds configured for a Receive connector. To increase the SMTP throughput for the relay Receive connector, we recommend you either lower the time-out value for the delayed acknowledgement attribute or disable it completely. Whether you should lower or disable the time-out value depends on the amount of messages that go through the relay Receive connector. A good approach is to first lower the value and then verify whether SMTP throughput still suffers and, if it does, then disable the feature completely. Important: Although disabling delayed acknowledgements for a Receive connector increases SMTP throughput, it also means that you no longer benefit from the features provided by shadow redundancy. For this reason, we recommend the use of storage hardware redundancy for transport servers for which delayed acknowledgements are disabled.

Use the Shell to configure the maximum acknowledgement delay on a Receive connector
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Receive connectors" entry in the Transport Permissions topic. Note: You can't use the Exchange Management Console to configure the maximum acknowledgement delay on a Receive connector. This example lowers the time-out value for a Receive connector named SMTP Application relay from 30 to 15 seconds.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

This example disables delayed acknowledgement on the Receive connector.

Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0

Important: It isnt possible to disable shadow redundancy for a Receive connector. Instead, you must do this on the Exchange organization level. For detailed syntax and parameter information, see Set-TransportConfig.

Message Throttling Policy Considerations


When relaying application server SMTP traffic through an Exchange 2010 transport server, there are Receive connector specific message throttling policy options that may need to be adjusted, so the overall SMTP throughput doesnt suffer. For example, the MessageRateLimit parameter specifies the maximum number of messages that a Receive connector accepts from a single IP address per minute. On Hub Transport servers, this parameter is set to a value of Unlimited, which means SMTP throughput wont be affected. But, for an Edge Transport server, its set to accept 600 messages per minute. Depending on the relay application server SMTP traffic in your specific environment, you may need to raise this limit. This example raises the message rate limit for a Receive connector named SMTP Application relay from 600 to 2000.

Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000

Another Receive connector specific option that can have an impact on overall SMTP throughput from a relay application server is expressed in the value of the MessageRateSource parameter. With this parameter, you specify how the message submission rate is calculated. It can be set to None, IPAddress, User, or All. By default, the parameter is set to IPAddress, which means the message submission rate is calculated for sending hosts. If this parameter has a negative impact on SMTP throughput from your relay application servers, you should consider setting the value to None. This example disables the MessageRateSource parameter for a Receive connector named SMTP Application relay.

Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None

If youre planning to use a dedicated transport server for relay application server SMTP traffic, you should also consider increasing the maximum number of connections that a Receive connector will serve at the same time from a single IP address. This is done using the MaxInboundConnectionPercentagePerSource parameter. The value for this parameter is expressed as the percentage of available remaining connections on a Receive connector. By default, the value is set to 2 percent. This example changes the value of MaxInboundConnectionPercentagePerSource for a Receive connector named SMTP Application relay from 2 to 30 percent.

Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30

For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Message Size Limits


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2013-07-01 You can apply message size limits to individual messages that move through the Microsoft Exchange Server 2010 organization. You can restrict the total size of a message or the size of the individual components of a message, such as the message header, the message attachments, and the number of recipients. You can apply limits globally for the whole Exchange 2010 organization, or specifically for a particular connector or user object. As you plan the message size limits for your Exchange 2010 organization, consider the following questions:

What size limits should I impose on all incoming messages? What size limits should I impose on all outgoing messages? Does my Exchange 2010 organization have a mailbox quota? How do the message size limits that I have chosen relate to the mailbox quota size? Are there users in my Exchange 2010 organization who must send or receive messages that are larger than the specified allowed size? Does my Exchange 2010 network topology include other messaging systems or distinctly separate business units that have different message size limits? This topic provides guidance to help you answer these questions. Looking for management tasks related to Transport servers? See Managing Transport Servers.

Types of Message Size Limits


Following are the basic categories of the size limits available for individual messages:

Message header size limits These limits apply to the total size of all message header fields that are present in a message. The size of the message body or attachments isnt considered. Because the header fields are plain text, the size of the header is determined by the number of characters in each header field and by the total number of header fields. Each character of text consumes 1 byte. Note: Some third-party firewalls or proxy servers apply their own message header size limits. These third-party firewalls or proxy servers may have difficulty processing messages that contain attachment file names that are greater than 50 characters or attachment file names that contain non-US-ASCII characters. Message size limits These limits apply to the total size of a message, which includes the message header, the message body, and any attachments. Message size limits may be imposed on incoming messages or outgoing messages. For internal message flow, Exchange 2010 uses the custom X-MS-ExchangeOrganization-OriginalSize: message header to record the original message size of the message as it enters the Exchange 2010 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. Attachment size limits These limits apply to the maximum allowed size of a single attachment within a message. The message may contain many attachments that greatly increase the overall size of the message. However, an attachment size limit applies to the size of an individual attachment only. Recipient limits These limits apply to the total number of message recipients. When a message is first composed, the recipients exist in the To:, Cc:, and Bcc: header fields. When the message is submitted for delivery, the message recipients are converted into RCPT TO: entries in the message envelope. A distribution group is counted as a single recipient during message submission.

Scope of Limits
Following are the basic categories for the scope of the limits available for individual messages:

Organizational limits These limits apply to all Exchange 2010 and Exchange 2007 servers that exist in the organization. The specified message limits apply to all Exchange 2010 and Exchange 2007 servers that have the Hub Transport server role installed. On an Edge Transport server, the specified limits apply to the specific server. Global limits Global limits are used when Exchange Server 2003 servers coexist with your Exchange 2010 deployment. The global limits are stored in a different location in Active Directory than the organizational limits and are primarily used by Exchange Server 2003 servers. In an environment where you have both Exchange 2010 and Exchange Server 2003 servers in the same organization, changes that you make to the organizational limits are automatically copied to the corresponding global limits. In Exchange 2010, you can modify the organizational limits by using the Set-TransportConfig cmdlet in the Exchange Management Shell, or by configuring the Hub Transport server organization configuration properties in the Exchange Management Console. Connector limits These limits apply to any messages that use the specified Send connector, Receive connector, Delivery Agent connector, or Foreign connector for message delivery. Connectors are defined on Hub Transport servers or Edge Transport servers. Active Directory site links Hub Transport servers use Active Directory sites and the costs that are assigned to the Active Directory IP site links to determine the least-cost routing path from each Hub Transport server in the organization to every other Hub Transport server in the organization. You can assign specific message size limits to the Active Directory site links in your organization. For example, you may want to apply a lower message size limit to an Active Directory site link that represents a connection to a remote office with a low-bandwidth connection. Any messages that exceed the maximum message size limit on any Active Directory site link included in the least-cost routing path won't be delivered and will generate a delivery status notification (DSN) with a value of 5.3.4. For more information about message routing in Exchange 2010, see Planning to Use Active Directory Sites for Routing Mail. Routing group connectors A routing group connector is used to send and receive messages between Exchange 2010 Hub Transport servers and Exchange Server 2003 bridgehead servers when the organization is running more than one version of Microsoft Exchange. Any messages that exceed the maximum message size limit on any routing group connector won't be delivered. They will generate a DSN with the value of 5.3.4. For more information about routing group connectors, see Upgrade from Exchange 2003 Transport. Server limits These limits apply to a specific Hub Transport server or Edge Transport server. You can set the specified message limits independently on each Hub Transport server or Edge Transport server. If you are using Outlook Web App, the maximum HTTP request size limit setting on the Client Access servers also controls the size of messages that Outlook Web App users can send. For more information, see Configure Maximum Message Size in Outlook Web App. User limits These limits apply to a specific user object, such as a mailbox, contact, distribution group, or public folder.

Organizational Limits
The following table shows the organizational limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

Organizational limits
Size limit Default value in Exchange 2010 10 MB Shell configuration EMC configuration

Maximum size for messages received

Cmdlet: SetTransportConfig Parameter: MaxReceiveSize

Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Global Settings > Transport Settings > General tab Organization Configuration > Hub Transport > Transport Rules New Transport Rule wizard or Edit Transport Rule wizard

Maximum size for messages sent

10 MB

Cmdlet: SetTransportConfig Parameter: MaxSendSize

Maximum number of recipients per message Note: When a message is first processed by a Hub Transport server, an X-header named X-MSExchange-Organization-OriginalSize: is inserted into the message header. Any Hub Transport servers that are involved in the future delivery of the message will use this value for the message size. Conversion encoding and agent processing can increase the size of the message as it flows through the Exchange organization.

5000

Cmdlet: SetTransportConfig Parameter: MaxRecipientEnvelopeLimit

Maximum attachment size in Transport rules that apply to all Hub Transport servers in the organization

Not configured

Cmdlets: NewTransportRule, SetTransportRule Parameter: AttachmentSizeOver

Global Limits
The following table shows the global limits, including information about where to configure the limits in Exchange System Manager in Exchange Server 2003.

Global limits
Size limit Maximum size for messages received Default value 10240 KB (10 MB) Exchange System Manager configuration

delivContLength in Active Directory Incoming message size in Exchange System Manager Global Settings

Maximum size for messages sent

10240 KB (10 MB)

submissionContLength in Active Directory Outgoing message size in Exchange System Manager Global Settings

Maximum number of recipients per message

5000

msExchRecipLimit in Active Directory Maximum number of recipients in Exchange System Manager Global Settings

Connector Limits
The following table shows the connector limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange

Management Console (EMC).

Connector limits
Size limit Maximum header size through a Receive connector Default value 64 KB Shell configuration Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxHeaderSize Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxMessageSize EMC configuration N/A

Maximum message size through a Receive connector

10 MB

Server Configuration > Hub Transport > Receive Connectors > Receive Connector properties > General tab Edge Transport > Receive Connectors > Receive Connector properties > General tab N/A

Maximum number of recipients per message through a Receive connector

200 for the Default Client Receive connector 5,000 for the Default Receive connector on Hub Transport servers 200 for the Default Receive connector on Edge Transport servers Note: If the number of recipients is exceeded for an anonymous sender, the message is accepted for the first 200 recipients. Most SMTP messaging servers detect that a recipient limit is in effect. The SMTP messaging server continues to resend the message in groups of 200 recipients until the message is delivered to all recipients.

Cmdlets: NewReceiveConnector, SetReceiveConnector Parameter: MaxRecipientsPerMessage

Maximum message size through a Send connector

10 MB

Cmdlets: NewSendConnector, SetSendConnector Parameter: MaxMessageSize

Organization Configuration > Hub Transport > Send Connectors > Send Connector properties > General tab Edge Transport > Send Connectors > Send Connector properties > General tab N/A

Maximum message size through an Active Directory site link Maximum message size through a routing group connector Maximum message size through a delivery agent connector

Unlimited

Cmdlet: Set-AdSiteLink Parameter: MaxMessageSize

Unlimited

Cmdlet: SetRoutingGroupConnector Parameter: MaxMessageSize Cmdlets: NewDeliveryAgentConnector, SetDeliveryAgentConnector Parameter: MaxMessageSize Cmdlet: SetForeignConnector Parameter: MaxMessageSize

N/A

Unlimited

N/A

Maximum message size through a foreign connector

Unlimited

N/A

Server Limits
The following table shows the server limits, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

Server limits

Size limit

Default value Not configured

Shell configuration

EMC configuration

Transport rule on an Edge Transport server that only applies to the specific server

Cmdlets: New-TransportRule, SetTransportRule Parameter: AttachmentSizeOver Cmdlet: Set-TransportServer Parameter: PickupDirectoryMaxHeaderSize Cmdlet: Set-TransportServer Parameter: PickupDirectoryMaxRecipientsPerMessage

Edge Transport > Transport Rules New Transport Rule wizard or Edit Transport Rule wizard Not applicable

Maximum header size for messages in the pickup directory

64 KB

Maximum number of recipients per message for messages in the pickup directory

100

Not applicable

In addition, you can configure the maximum HTTP request length on your Client Access servers that service Microsoft Office Outlook Web App clients. The value configured for this setting will also affect the message size users can submit. For example, if you set this value lower than other message size limits in your organization, your users will not be able to send large messages using Outlook Web App even though they can send the same message using Outlook. You can configure this setting by modifying the maxRequestLength parameter in the web.config file on your Client Access servers. By default, this file is located in the <Exchange install directory>\V14\ClientAccess\Owa folder. The default value is 30000 KB.

User Limits
The following table shows message size limits that you can configure at the recipient level, including information about how to configure the limits in the Exchange Management Shell or the Exchange Management Console (EMC).

User limits
Size Limit Default value Unlimited Shell configuration EMC configuration

Maximum message size that can be sent by this recipient

Cmdlets: Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailUser Set-MailPublicFolder Parameter: MaxSendSize

For mailboxes: Recipient Configuration > Mailbox Properties > Mail Flow Settings tab For mail public folders: Public Folder Management Console > Public Folder properties > Mail Flow Settings tab Note: This setting isn't configurable using the EMC for other recipient types.

Maximum message size that can be sent to this recipient

Unlimited

Cmdlets: Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailUser Set-MailPublicFolder Parameter: MaxReceiveSize Cmdlets: Set-Mailbox, Set-MailUser Parameter: RecipientLimits Cmdlet: Set-MailUser Parameter: MaxRecipientsPerMessage

For all recipient types except Mail Public Folders: Recipient Configuration > Recipient Properties > Mail Flow Settings tab For Mail Public Folders: Public Folder Management Console > Public Folder properties > Mail Flow Settings tab

Maximum number of recipients per message sent by this recipient

Unlimited

N/A

Order of Precedence for Message Size Limits


You can set different message size limits at different levels in the Exchange organization. As a message is routed through your Transport infrastructure, it may be subjected to several different message size restrictions. You should plan your message size restrictions in a way that makes sure that messages in the transport pipeline are rejected as early as possible if they violate message size limits. Generally speaking, you should set more restrictive limits at the points where messages enter your infrastructure. For example, any message size restrictions on your Edge server Receive connectors that receive messages from the Internet should be less than or equal to the message size restrictions you configure for your internal Exchange organization. It would be a waste of system resources for the Edge Transport server to accept and process a message from the Internet that would be rejected by your Hub Transport servers. Make sure that your organization, server, and connector limits are configured in a way that minimizes any unnecessary processing of messages. One exception to this approach is the user limits. User level limits take precedence over other message size restrictions. Therefore, you can configure a user to exceed the default message size limits for your organization. For example, you can allow a specific group of user mailboxes to send larger messages than the rest of the organization by configuring custom send and receive limits for those users. The exceptions for the user limits only apply to message exchanges between authenticated users. If a message is sent to or received by a recipient on the Internet, the organizational limits will be applied. For example, assume that you have an organizational message size restriction of 10 MB, but you have configured the users in your marketing department to send and receive messages up to 50 MB. These users will be able to exchange large messages with each other, but they still wont be able to

receive large messages from Internet users because such messages will be coming from unauthenticated senders.

Messages Exempt from Size Limits


The following list shows the types of messages generated by a Hub Transport server or an Edge Transport server and exempted from all message size limits:

System messages Agent-generated message Delivery status notification (DSN) messages Journal report messages Quarantined messages Important: Even though they are generated by the system, non-delivery reports (NDRs) are not exempt from message size limits. However, these messages are still subject to the organizational value for maximum number of recipients in a message. This value is set by the MaxRecipientEnvelopeLimit parameter that you can configure by using the Set-TransportConfig cmdlet in the Shell.

Differences in Message Size Limits Between Exchange 2003 and Exchange 2010
The primary difference in message size limits between Exchange Server 2003 and Exchange Server 2010 is in the handling of recipient limits. Exchange 2003 treats each member of an expanded distribution list as one recipient. Exchange 2010 treats a distribution group as one recipient. This change was implemented to avoid the partial message delivery scenarios that may occur in Exchange 2003. Partial message delivery occurs in Exchange 2003 if the number of individual recipients and the recipients that are contained within the distribution list exceeds the specified recipient limit. The total number of message recipients isn't known until after distribution list expansion. Message delivery occurs as the distribution list is expanded until the number of recipients reaches the specified limit. The remaining recipients do not receive the message, but at least the sender receives a non-delivery report (NDR) for each unsuccessful delivery. However, if delivery failure reporting is disabled for the distribution list, the remaining recipients wouldn't receive the message, and the sender would not know who did not receive the message.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Message Throttling


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-11-07 This topic explains the message throttling options that are available in Microsoft Exchange Server 2010. It also describes enhancements to the message throttling functionality that are included in Service Pack 1 (SP1) of Microsoft Exchange Server 2010. Message throttling refers to a group of limits that are set on the number of messages and connections that can be processed by a computer that is running Exchange 2010 with either the Hub Transport server role or the Edge Transport server role installed. These limits prevent the accidental or intentional exhaustion of system resources on the transport server. For more information about management tasks related to managing transport servers, see Managing Transport Servers. Contents Message Throttling Scope Message Throttling Options on Transport Servers Message Throttling Option on Send Connectors Message Throttling Options on Receive Connectors Message Throttling Policies

Message Throttling Scope


Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and SMTP session time-out values. These limits work together to protect a Hub Transport server or Edge Transport server from being overwhelmed by accepting and delivering messages. Although a large backlog of messages and connections may be waiting to be processed, the message throttling limits enable the transport server to process the messages and connections in an orderly manner. In addition to message throttling, with Exchange 2010 you can also put size limits on the individual components of messages, such as the number of recipients, the size of the message header, or the size of individual attachments. For more information about message size limits, see Understanding Message Size Limits. Another Exchange 2010 feature that helps avoid overwhelming the system resources of an Exchange 2010 transport server is back pressure. Back pressure is a system resource monitoring feature on Hub Transport servers and Edge Transport servers. When a monitored system resource, such as hard disk utilization or memory utilization, exceeds the specified threshold, the Exchange transport server reduces the rate at which it accepts new connections and messages, and focuses on delivering existing messages. When the utilization of the monitored system resources returns to normal levels, the Exchange transport server slowly increases the rate at which it accepts new connections and then establishes a normal level. For more information, see Understanding Back Pressure.

Message Throttling Enhancements in Exchange 2010 SP1


Exchange 2010 SP1 includes additional features that enhance the message throttling functionality. These enhancements address the following issues that administrators may experience in a messaging environment:

Because more resources are required to send messages that have large attachments or that are sent to multiple recipients, other message delivery operations may experience increased latency. A high rate of mailbox delivery operations may reduce the user interactive mailbox experience. For example, users may experience slow refresh or update times when they access their mailboxes. No centralized method is available to control how a specific user may inadvertently affect the resources of a Transport server. Such an effect may occur if the user sends messages that have high delivery costs in terms of number of recipients or total message size or both. To provide more consistent message throughput and predictable message delivery latency, Exchange 2010 SP1 establishes an accumulated cost for messages. This cost is based on the following criteria:

Message size Number of recipients Frequency of transmission Transport servers that run on Exchange 2010 SP1 track the average delivery cost of messages that are sent by individual users. By using message costs, Exchange 2010 SP1 provides a group of settings that can control the effect that a user or connection has on an Exchange organization. This group of settings is known as a throttling policy. When a user repeatedly sends costly messages, such as messages that have large attachments or messages that are sent to many recipients, the Exchange 2010 SP1-based transport servers use a throttling policy to assign a lower priority to higher-cost messages from the user while continuing to deliver lowercost messages. This new behavior adds a quality of service aspect to the message throttling functionality in Exchange 2010. Note: Message throttling doesnt affect the message priority from a users perspective. Messages still retain the original priority set by the user. For example, messages retain a setting of Important or Urgent, and so on. To support this new functionality, Exchange 2010 SP1 uses the following mechanisms:

Internal prioritization agent This agent is triggered on the OnResolvedMessage event and assigns a lower priority to messages from the same sender that have a high accumulated cost. This cost is measured over a period of one minute and affects messages that have more than 500 P1 and P2 recipients or that are larger than 1 megabyte (MB). Quota-based priority queuing for the MapiDelivery queue type This mechanism causes Exchange to deliver messages in a normal-priority queue more frequently than messages in a low-priority queue. By default, the normal-to-low message ratio is 20:1. However, new messages from a lower priority queue are never delivered sooner than new items from a higher priority queue. For example, consider the following scenario:

1. Twenty normal priority messages are delivered. By default, the next delivered message is a lower priority message. 2. Two new messages are received by the Transport server: One message from a higher priority queue and one message from a lower priority queue. In this scenario, the message from the higher priority queue is delivered first. Then, the message from the lower priority queue is delivered. Throttle concurrent connections based on messaging database health This mechanism monitors the health of the Exchange messaging database (MDB) health and throttles concurrent connections to Exchange transport servers based on an assigned Health Measure value. The MDB is monitored by the Resource Health Monitor API on the Hub Transport server and is assigned a health value from -1 through 100. This value is based on the RPC performance statistics that are included with each RPC response from the Store.exe process. The Resource Health framework uses both the Requests/Second rate performance counter and the Average RPC Latency performance counter to calculate a health value for the database. To help maintain a consistent interactive user experience, Exchange reduces the number of concurrent connections as the health value decreases. The following health value ranges are available: -1: This value indicates that the MDB health state is unknown. This value is assigned when the database starts. In this scenario, the database is considered healthy. 0: This value is assigned if the database is in an unhealthy state. In this state, the database should not be contacted. 1 through 99: These values represent a fair health state. A lower value represents a less healthy database. 100: This value represents a healthy database. The Microsoft Exchange Throttling service in Exchange 2010 SP1 provides the framework for mail flow throttling. This service is installed when you install the Mailbox Server role. The Exchange 2010 Throttling service keeps track of mail flow throttling settings for a specific user and caches the throttling information in memory. Mail flow throttling settings are also known as a budget. Restarting the Exchange 2010 Throttling service also resets mail flow throttling budgets. You can use the throttling policy cmdlets that are available in Exchange 2010 SP1 to configure individual budget settings for a throttling policy. A budget is the amount of access that a user or application may have for a specific setting. A budget represents how many connections a user may have or how much activity a user may be permitted for each one-minute period. For example, a budget may be configured to set the amount of time that a user may spend using a specific feature in Exchange, such as ActiveSync, Outlook Web App, or Exchange Web Services. This threshold is stored in a throttling policy and defines the budget. Time settings for a budget are set as a percentage of one minute. Therefore, a threshold of 100 percent represents 60 seconds. For example, assume that you want to specify Outlook Web App policy settings that limit the amount of time during which a user may run Outlook Web App code on a Client Access server and the amount of time the user may communicate with the Client Access server to 600 milliseconds over a one-minute period. To accomplish this, you need to set the value to 1 percent of one minute (600 milliseconds) for both of the following parameters:

OWAPercentTimeInCAS: 1 OWAPercentTimeInMailboxRPC: 1 A user who has this policy applied has a budget of OWAPercentTimeInCAS of 600 milliseconds and of OWAPercentageTimeInMailboxRPC of 600 milliseconds. In this scenario, when the user is logged into Outlook Web App, the user can run Client Access code for up to 600 milliseconds. After the 600 millisecond-period, the connection is considered over budget and the Exchange server doesnt allow any further Outlook Web App action until one minute after the budget limit is reached. After the one-minute period, the user can run Outlook Web App client access code for another 600 milliseconds. These Exchange 2010 SP1 features, together with the features in the release to manufacturing (RTM) version of Exchange 2010, let an Exchange administrator maintain a consistent user experience without having to deploy more servers than are required to meet the normal workload.

Message Throttling Options on Transport Servers


You can set the message throttling options at the following locations:

On the transport server On a Send connector On a Receive connector You can set all the message throttling options that are available on Hub Transport servers or Edge Transport servers in the Exchange Management Shell. You can also set some of the same options by configuring the transport server properties in the Exchange Management Console (EMC). The following table shows the message throttling options that are available on Hub Transport servers or Edge Transport servers.

Message throttling options on Hub Transport or Edge Transport servers


Source SetTransportServer Parameter MaxConcurrentMailboxDeliveries Description This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to deliver messages to mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the delivery of messages to any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxDeliveries parameter is 20. This parameter specifies the maximum number of delivery threads that the Hub Transport server can have open at the same time to accept messages from mailboxes. The store driver on the Hub Transport server is responsible for delivering messages to and from Mailbox servers. This limit applies to the acceptance of new messages from any mailboxes in the Exchange organization. The default value of the MaxConcurrentMailboxSubmissions parameter is 20. This parameter specifies the maximum rate at which new inbound connections can be opened to the Hub Transport server or the Edge Transport server. These connections are opened to any Receive connectors that exist on the server. The default value for the MaxConnectionRatePerMinute parameter is 1200 connections per minute. This parameter specifies the maximum number of concurrent outbound connections that the Hub Transport server or Edge Transport server can have open at the same time. The outbound connections occur by using the Send connectors that exist on the server. The value that's specified by the MaxOutboundConnections parameter applies to all the Send connectors that exist on the transport server. The default value of the MaxOutboundConnections parameter is 1000. If you enter a value of unlimited, no limit is imposed on the number of outbound connections.

SetTransportServer

MaxConcurrentMailboxSubmissions

SetTransportServer

MaxConnectionRatePerMinute

SetTransportServer or Transport server properties

MaxOutboundConnections

This value can also be configured using the EMC. SetTransportServer or Transport server properties MaxPerDomainOutboundConnections This parameter specifies the maximum number of connections that an Internet-facing Hub Transport server or Edge Transport server can have open to any single remote domain. The outbound connections to remote domains occur by using Send connectors that exist on the server. The default value of the MaxPerDomainOutboundConnections parameter is 20. If you enter a value of unlimited, no limit is imposed on the number of outbound connections per domain. This value can also be configured using the EMC. PickupDirectoryMaxMessagesPerMinute This parameter specifies the rate of message processing for both the Pickup directory and Replay directory. Each directory can independently process message files at the rate that's specified by the PickupDirectoryMaxMessagesPerMinute parameter. By default, the Pickup directory can process 100 messages per minute, and the Replay directory can process 100 messages per minute at the same time. The Pickup directory and the Replay directory scan for new message files once every 5 seconds, or 12 times per minute. This 5-second polling interval isn't configurable. This means the maximum number of messages that can be processed during each polling interval is the value that you assign to the PickupDirectoryMaxMessagesPerMinute parameter divided by 12 (PickupDirectoryMaxMessagesPerMinute/12). By default, a maximum of just over eight messages can be processed during each 5-second polling interval.

SetTransportServer

For more information, see the following topics:

Configure Edge Transport Server Properties Configure Hub Transport Server Properties Set-TransportServer

Message Throttling Option on Send Connectors


The following table shows the message throttling option that's available on Send connectors that are configured in your organization or an Edge Transport server. You must use the Shell to configure this option.

Message throttling option available on Send connectors


Source SetSendConnector Parameter ConnectionInactivityTimeOut Description This parameter specifies the maximum time that an open SMTP connection with a destination messaging server can remain idle before the connection is closed. The default value is 10 minutes.

For more information, see Set-SendConnector.

Message Throttling Options on Receive Connectors


The following table shows the message throttling options that are available on Receive connectors that are configured on a Hub Transport server or an Edge Transport server. You must use the Shell to configure these options.

Message throttling options available on Receive connectors


Source SetReceiveConnector Parameter ConnectionInactivityTimeOut Description This parameter specifies the maximum time that an open SMTP connection with a source messaging server can remain idle before the connection is closed. The default value for a Receive connector that's configured on a Hub Transport server is 5 minutes. The default value for a Receive connector that's configured on an Edge Transport server is 1 minute. This parameter specifies the maximum time that an SMTP connection with a source messaging server can remain open, even if the source messaging server is transmitting data. The default value for a Receive connector that's configured on a Hub Transport server is 10 minutes The default value for a Receive connector that's configured on an Edge Transport server is 5 minutes. The value specified by the ConnectionTimeout parameter must be larger than the value specified by the ConnectionInactivityTimeout parameter. This parameter specifies the maximum number of inbound SMTP connections that this Receive connector allows at the same time. The default value is 5000. This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The value is expressed as the percentage of available remaining connections on a Receive connector. The maximum number of connections that are permitted by the Receive connector is defined by the MaxInboundConnection parameter. The default value of the MaxInboundConnectionPercentagePerSource parameter is 2 percent. This parameter specifies the maximum number of SMTP connections that a Receive connector allows at the same time from a single source messaging server. The default value is 100. This parameter specifies the maximum number of SMTP protocol errors that a Receive connector allows before the Receive connector closes the connection with the source messaging server. The

SetReceiveConnector

ConnectionTimeOut

SetReceiveConnector SetReceiveConnector

MaxInboundConnection

MaxInboundConnectionPercentagePerSource

SetReceiveConnector SetReceiveConnector

MaxInboundConnectionPerSource

MaxProtocolErrors

default value is 5. SetReceiveConnector TarpitInterval This parameter specifies the delay that's used in tarpitting. Tarpitting is the practice of artificially delaying SMTP responses for specific SMTP communication patterns that indicate a directory harvest attack or other unwelcome messages. A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization to use as a target for unsolicited commercial e-mail. The delay that's specified by the TarpitInterval parameter only applies to anonymous connections. The default value of the TarpitInterval parameter is 5 seconds. For more information, see Understanding Recipient Filtering.

For more information, see Set-ReceiveConnector.

Message Throttling Policies


In Exchange 2010 SP1, each mailbox has a ThrottlingPolicy setting. The default value for this setting is $Null. You can use the Set-Mailbox command together with the ThrottlingPolicy parameter to configure a throttling policy for a mailbox. A default throttling policy exists to provide a default set budget configuration for users who connect to Exchange. To configure customized budget settings for one or more users, create a new throttling policy. Then, apply the policy to the appropriate user or group. Important: We recommend that you do not modify the default throttling policy. You can set all the message throttling options that are available on Mailbox servers in the Exchange Management Shell. The following cmdlets are available to manage throttling policies:

Get-ThrottlingPolicy Remove-ThrottlingPolicy New-ThrottlingPolicy Set-ThrottlingPolicy For more information, see Understanding Client Throttling Policies. You can use the New-ThrottlingPolicy and Set-ThrottlingPolicy cmdlets to configure how much activity a user can perform against Exchange over a specific connection or time period. These settings make up a users budget. You can establish throttling policies to control access to the following Exchange features:

Exchange ActiveSync Exchange Web Services Outlook Web App Unified Messaging IMAP4 POP3 Outlook client connections (MAPI or RPC connections) Mail flow settings PowerShell commands CPU usages For more information about the policy settings available for use with the throttling policy cmdlets, see New-ThrottlingPolicy and Set-ThrottlingPolicy. For more information about how to configure Transport servers, see the following topics:

Configure Edge Transport Server Properties Configure Hub Transport Server Properties Set-TransportServer

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Moderated Transport


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-08-05 Using the moderated transport feature in Microsoft Exchange Server 2010, you can require all e-mail messages sent to specific recipients be approved by moderators. You can configure any type of recipient as a moderated recipient, and Exchange 2010 Hub Transport servers will ensure that all messages sent to those recipients go through an approval process. In any type of organization, you may need to restrict access to specific recipients. The most common scenario is the need to control messages sent to large distribution groups. Depending on your organization's requirements, you may also need to control the messages sent to executive mailboxes or partner contacts. You can use moderated recipients to accomplish these tasks. Note: Previous versions of Exchange don't support moderated recipients. If a message sent to a moderated distribution group is expanded on a Hub Transport server running Exchange Server 2007, it will be delivered to all members of that distribution group, bypassing the moderation process. If you have Exchange 2007 Hub Transport servers in your Exchange 2010 organization, and you want to use moderated distribution groups, you must designate an Exchange 2010 Hub Transport server as the expansion server for the moderated distribution groups. Doing this ensures that all messages sent to the distribution group are moderated. Moderated transport relies on the Exchange 2010 approval framework. For more information about the approval framework, see Understanding Approval Framework. Looking for management tasks related to transport servers? See Managing Transport Servers.

Moderated Transport
The moderated transport application consists of the following components:

Categorizer The transport categorizer initiates the approval process. When the categorizer detects a moderated recipient while processing a message, it reroutes the message to the arbitration mailbox. Store driver The store driver processes the messages that the categorizer marks for moderation. When the store driver encounters such a message, it stores the original message in the arbitration mailbox and sends approval requests to the moderators. When a moderator responds with a decision, the store driver marks that decision on the message that's stored in the arbitration mailbox. If an approved message is submitted again by the Information Assistant, the store driver removes the approval workflow wrappers so the message that's delivered is identical to the original message submitted by the sender. Information Assistant The Information Assistant process monitors the arbitration mailbox. The Information Assistant resubmits any approved messages to the submission queue for delivery to the intended recipients, or it deletes rejected messages. The Information Assistant is also responsible for sending rejection notifications to the sender. In addition, it cleans up the arbitration mailbox by deleting any stale or orphaned messages from the arbitration mailbox. For example, if a moderator simply deletes an approval request instead of making a decision, the corresponding message waiting for approval in the arbitration mailbox needs to be removed by the Information Assistant. Arbitration mailbox The arbitration mailbox is used to store the original message that's awaiting approval. By default, one arbitration mailbox is created for moderated transport during setup. It's used for all moderated recipients. You can add additional arbitration mailboxes for load balancing purposes. If you're using multiple arbitration mailboxes, you need to specify which mailbox to use for each moderated recipient.

Message Flow for Moderated Recipients


When a user sends a message to a recipient for whom message moderation is enabled, the message follows a path to its destination, as shown in the following figure and described in the following steps.

1. 2. 3. 4. 5. 6.

The sender creates a message and sends it to the moderated recipient. The categorizer intercepts the message, marks it for moderation, and then reroutes it to the arbitration mailbox. The store driver stores the message in the arbitration mailbox and sends an approval request to the moderator. The moderator uses the buttons in the approval request to either accept or reject the message. The store driver marks the moderator's decision on the original message stored in the arbitration mailbox. The Information Assistant reads the approval status on the message stored in the arbitration mailbox, and then processes the message depending on the moderator's decision: a. If the moderator has approved the message, the Information Assistant resubmits the message to the submission queue, and the message is delivered to

the recipient. b. If the moderator has rejected the message, the Information Assistant deletes the message from the arbitration mailbox and notifies the sender that the message was rejected. Note: If the moderator doesn't respond to the message within five days, the Information Assistant will delete the message from the arbitration mailbox and notify the sender that their message has expired.

Handling Multiple Moderated Recipients


It's possible to send a message to a group of recipients that includes both moderated recipients and recipients that aren't moderated. In this case, a separate approval process occurs for each moderated recipient. Consider a message that's sent to 12 recipients, one of which is a moderated distribution group. The categorizer splits this message into two messages. One message is delivered immediately to the 11 recipients that aren't moderated, and the second message is submitted to the approval process for the moderated distribution group. If a message is intended for more than one moderated recipient, a separate copy is created for each moderated recipient and is submitted to the approval process. A moderated distribution group may contain other moderated recipients. In this case, after the message to the distribution group is approved, a separate approval process occurs for each moderated recipient that's a member of the distribution group. However, you can also enable the automatic approval of the distribution group members after the message to the moderated distribution group is approved. To do this, you set the BypassNestedModerationEnabled parameter of the moderated distribution group to $true. For more parameter and syntax information, see Set-DistributionGroup.

Bypassing Moderation
Messages from moderators are delivered to the moderated recipient immediately, bypassing the approval process. By definition, a moderator has the authority to determine what messages are appropriate for a moderated recipient. Moderation is also bypassed for owners of distribution groups and dynamic distribution groups. The owner of a distribution group can be responsible for managing the distribution group membership, but may not be able to moderate messages sent to it. For example, the account provisioning staff may be the owners of a distribution group called All Employees, but only specific people in human resources may have moderator rights for the same distribution group.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding the Pickup and Replay Directories


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2009-10-14 By default, the Pickup and Replay directories exist on every computer running Microsoft Exchange Server 2010 that has the Hub Transport server role or the Edge Transport server role installed. Correctly formatted e-mail message files that you copy to the Pickup or Replay directories are submitted for delivery. The Pickup directory is used by administrators for mail flow testing, or by applications that must create and submit their own messages. The Replay directory receives messages from foreign gateway servers and can also be used to resubmit messages that administrators export from the queues of Exchange 2010 servers. Looking for management tasks related to Pickup and Relay directories? See Managing Connectors. Contents Anatomy of an E-Mail Message File How the Pickup Directory Processes Messages How the Replay Directory Processes Messages Security Considerations for the Pickup and Replay Directories Permissions for the Pickup and Replay Directories

Anatomy of an E-Mail Message File

A standard SMTP e-mail message consists of a message envelope and message content. The message envelope contains information required for transmitting and delivering the message. The message content contains message header fields (collectively called the message header) and the message body. The message envelope is described in RFC 2821, and the message header is described in RFC 2822. When a sender composes an e-mail message and submits it for delivery, the message contains the basic information required to comply with SMTP standards, such as a sender, a recipient, the date and time that the message was composed, an optional subject line, and an optional message body. This information is contained in the message itself and, by definition, is contained in the message header. The sender's messaging server generates a message envelope for the message by using the sender and recipient information found in the message header and transmits the message to the Internet for delivery to the recipient's messaging server. Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message. Each server involved in the transmission of the message may insert message header fields related to the server's role in delivering the message or other applicationspecific message header fields into the message header. When the recipient opens the message by using an e-mail client, the e-mail client displays some of the more relevant information from the message header, such as the sender, the recipients, and the subject together with the message body. Return to top

How the Pickup Directory Processes Messages


A correctly formatted .eml message file copied to the Pickup directory is processed for submission in the following steps:

1. The Pickup directory is checked for new message files every five seconds. You can't modify this polling interval. You can adjust the rate of message file processing by using the PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportServer cmdlet. The default value is 100 messages per minute. Files that can't be opened are left in the Pickup directory and are reevaluated at the next poll. 2. Limits put on message files in the Pickup directory, such as the maximum header size and the maximum number of recipients, are checked. By default, the maximum header size is 64 kilobytes (KB), and the maximum number of recipients is 100. You change these limits by using the Set-TransportServer cmdlet. 3. The file is renamed from <filename>.eml to <filename>.tmp. If the <filename>.tmp file already exists, the file is renamed as <filename><datetime>.tmp. If the file renaming fails, an event log error is generated, and the pickup process proceeds to the next file. 4. After the .tmp file is successfully converted into an e-mail message, a delete on close command is issued to the .tmp file. The .tmp file appears to remain in the Pickup directory, but the file can't be opened. 5. After the message is successfully queued for delivery, a close command is issued, and the .tmp file is deleted from the Pickup directory. If the deletion fails, an event log error is generated. If the Microsoft Exchange Transport service is restarted when there are .tmp files in the Pickup directory; all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.

Requirements for Message Files in the Pickup Directory


A message file copied to the Pickup directory must meet the following requirements for successful delivery:

The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported. The message file must have an .eml file name extension. At least one e-mail address must exist in the Sender or From message header fields in the message header. If a single e-mail address exists in both the Sender and From fields, the e-mail address in the From field is used as the originator of the message in the message envelope. Only one e-mail address can exist in the Sender field. Multiple e-mail addresses aren't allowed. The Sender field is optional if only one e-mail address exists in the From field. Multiple e-mail addresses are allowed in the From field, but a single e-mail address must also exist in the Sender field. The address in the Sender field is then

used as the originator of the message in the message envelope. At least one e-mail address must exist in the To, Cc, or Bcc fields. A blank line must exist between the message header and the message body. This example shows a plain text message that uses acceptable formatting for the Pickup directory.

To: mary@contoso.com From: bob@fabrikam.com Subject: Message subject This is the body of the message.

MIME content is also supported in Pickup directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Pickup directory.

To: mary@contoso.com From: bob@fabrikam.com Subject: Message subject MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit <HTML><BODY> <TABLE> <TR><TD>cell 1</TD><TD>cell 2</TD></TR> <TR><TD>cell 3</TD><TD>cell 4</TD></TR> </TABLE> </BODY></HTML>

Modifications to the Message Header That Are Made to Message Files in the Pickup Directory
The Pickup directory removes any of the following message header fields from the message header:

Received Resent-* Bcc Note: Any e-mail addresses found in the optional Bcc message header fields in the message header are correctly processed. After the Bcc recipients are promoted to invisible message envelope recipients, they are removed from the message header to protect their identity. If a message contains only Bcc recipients, the value of Undisclosed Recipients is added to the To field in the message header. The Pickup directory adds its own Received header field to a message as part of the message submission process. The Received header field is applied in the following format.

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

The Pickup directory modifies the following message header fields if they're missing or malformed:

Message-Id If the Message-Id field is missing or empty, the Pickup directory adds a Message-Id field by using the format <GUID>@<defaultdomain>. Date If the Date field is missing or malformed, the Pickup directory adds the date and time of message processing by the Pickup directory.

Failures in Pickup Directory Message Processing


A message file copied to the Pickup directory may not be successfully queued for delivery. The following categories of message submission failure can occur:

Delivery failures A correctly formatted message file together with a valid sender that can't be successfully submitted for delivery by the Pickup directory generates a non-delivery report (NDR). Malformed content or Pickup directory message restriction violations could also cause the Pickup directory to generate an NDR. When an NDR is generated during Pickup directory message processing, the original message file is attached to the NDR message, and the message file is deleted from the Pickup directory. Note: A correctly formatted message submitted by the Pickup directory may later experience a delivery failure and be returned to the sender with an NDR. This kind of failure may be caused by transmission issues unrelated to the Pickup directory, such as messaging server failures or routing failures along the delivery path of the message. Badmail A message classified as badmail has serious problems that prevent the Pickup directory from submitting the message for delivery. The other condition that causes badmail is when the message is formatted correctly, but the recipients aren't valid, and an NDR message can't be sent to the sender because the sender isn't valid. Message files determined to be badmail are left in the Pickup directory and are renamed from <filename>.eml to <filename>.bad. If the <filename>.bad file

already exists, the file is renamed to <filename><datetime>.bad. If badmail exists in the Pickup directory, an event log error is generated, but the same badmail messages don't generate repeated event log errors. Note: Always compose and save message files in a different location before you copy them into the Pickup directory for delivery. The Pickup directory polls for new messages every five seconds. Therefore, if you try to compose and save the message files in the Pickup directory itself, the Pickup directory may try to process the message files before you finish composing them. Return to top

How the Replay Directory Processes Messages


A correctly formatted .eml message file copied to the Replay directory is processed for submission in the following steps:

1. The Replay directory is checked for new message files every five seconds. You can't modify this polling interval. You can adjust the rate of message file processing by using the PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportServer cmdlet. The default value is 100 messages per minute. Files that can't be opened are left in the Replay directory and are reevaluated at the next poll. 2. The file is renamed from <filename>.eml to <filename>.tmp. If the <filename>.tmp file already exists, the file is renamed as <filename><datetime>.tmp. If the file renaming fails, an event log error is generated, and the Replay process proceeds to the next file. 3. After the .tmp file is successfully converted into an e-mail message, a delete on close command is issued to the .tmp file. The .tmp file appears to remain in the Replay directory, but the file can't be opened. 4. After the message is successfully queued for delivery, a close command is issued, and the .tmp file is deleted from the Replay directory. If the deletion fails, an event log error is generated. If the Microsoft Exchange Transport service is restarted when there are .tmp files in the Replay directory, all .tmp files are renamed as .eml files and are reprocessed. This could lead to duplicate message transmission.

Requirements for Message Files in the Replay Directory


The Replay directory is used to resubmit exported Exchange messages and to receive messages from foreign gateway servers. These messages are already formatted for the Replay directory. There is little or no need for an administrator or other application to compose and submit new message files by using the Replay directory. The Pickup directory should be used to create and submit new message files. The Replay directory messages make extensive use of X-Headers. X-Headers are user-defined, unofficial message header fields that exist in the message header. XHeaders aren't specifically mentioned in RFC 2822, but the use of an undefined message header field starting with "X-" has become an accepted way to add unofficial message header fields to a message. The Exchange 2010-specific X-Headers used in the message files in the Replay directory can actually set delivery information that normally exists in the message envelope. This feature is required to preserve original message information when you use the Replay directory to process exported messages from another Exchange server. A message file copied to the Replay directory must meet the following requirements for successful delivery:

The message file must be a text file that complies with the basic SMTP message format. MIME message header fields and content are supported. The message file must have an .eml file name extension. X-Headers must occur before all regular header fields. A blank line must exist between the header fields and the message body. The X-Headers described in the following list are required by messages in the Replay directory:

X-Sender This X-Header replaces the From message header field requirement in a typical SMTP message. One X-Sender field that contains one e-mail address must exist. The Replay directory ignores the From message header field if it's present, although the recipient's e-mail client displays the value of the From message header field as the sender of the message. Other parameters usually exist in the X-Sender field, as shown in the following example.

X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>

Note: These parameters are message envelope values that are ordinarily generated by the sending server. You may see parameters similar to this in exported message files. RET specifies whether the whole message or only the headers should be returned to the sender if the message can't be delivered. RET can have a value of HDRS or FULL. ENVID is a message envelope identifier. BODY specifies the text encoding of the message. auth specifies an authentication mechanism to the messaging server as described in RFC 2554. X-Receiver This X-Header replaces the To message header field requirement in a typical SMTP message. At least one X-Receiver field that contains one email address must exist. Multiple X-Receiver fields are allowed for multiple recipients. The Replay directory ignores the To message header fields if they're present, although the recipient's e-mail client displays the values of the To message header fields as the recipients of the message. Other optional parameters may exist in the X-Receiver fields, as shown in the following example.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com

Note: These parameters are message envelope values that are ordinarily generated by the sending server. You may see parameters similar to this in exported message files. These parameters are related to delivery status notification (DSN) messages as described in RFC 1891. NOTIFY can have a value of NEVER, DELAY, or FAILURE. ORcpt preserves the original recipient of the message. The X-Headers described in the following list are optional for message files in the Replay directory:

X-CreatedBy Used for header firewall functionality. If this X-Header exists, it must not be blank. If the X-CreatedBy field doesn't exist, it's added with a value of Unspecified. Typically, the value of this field is MSExchange14, but it also may contain the non-SMTP address space type set on a Send connector, such as Notes. X-EndOfInjectedXHeaders Size in bytes of all the X-Headers present. This X-Header may be used as a marker to indicate the last X-Header before the regular message header fields start. X-ExtendedMessageProps Extended message properties for the message. X-HeloDomain HELO/EHLO domain string presented during the initial SMTP protocol conversation. X-LegacyExch50 Used to preserve custom properties generated by Exchange Server 2003 if Exchange 2003 servers are present. X-Source Used by Queue Viewer under the MessageSourceName column. If the value of this X-Header isn't specified, the value of Replay is used. Other possible values for this X-Header are Smtp Receive Connector and Smtp Send Connector. X-SourceIPAddress IP address of the sending server. This field is 0.0.0.0 if no IP address is specified. This example shows a plain text message that uses acceptable formatting for the Replay directory.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345AB auth=<someAuth> Subject: Optional message subject This is the body of the message.

MIME content is also supported in Replay directory message files. MIME defines a broad range of message content that includes languages that can't be represented in 7-bit ASCII text, HTML, and other multimedia content. A complete description of MIME and its requirements is beyond the scope of this topic. This example shows a simple MIME message that uses acceptable formatting for the Replay directory.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth> To: mary@contoso.com From: bob@fabrikam.com Subject: Optional message subject MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit <HTML><BODY> <TABLE> <TR><TD>cell 1</TD><TD>cell 2</TD></TR> <TR><TD>cell 3</TD><TD>cell 4</TD></TR> </TABLE> </BODY></HTML>

Modifications to the Message Header That Are Made to Message Files in the Replay Directory
The Replay directory deletes the Bcc message header field from the message file. The Replay directory adds its own Received message header field to a message as part of the message submission process. The Received message header field is applied in the following format.

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

The Replay directory modifies the following message header fields in the message header:

Message-ID If this message header field is missing or empty, the Replay directory adds a Message-ID message header field by using the format <GUID>@<defaultdomain>. Date If this message header field is missing or malformed, the Replay directory adds the Date message header field using the date and time of message processing by the Replay directory.

Failures in Replay Directory Message Processing


Any problems converting a message file into an e-mail message causes the Replay directory to consider the message undeliverable (badmail). A badmail message file has serious problems, such as a missing sender, missing recipients, or formatting problems. Message files determined to be badmail are left in the Replay directory and are renamed from <filename>.eml to <filename>.bad. If the <filename>.bad file already exists, the file is renamed to <filename><datetime>.bad. If badmail exists in the Replay directory, an event log error is generated, but the same badmail messages don't generate repeated event log errors. Return to top

Security Considerations for the Pickup and Replay Directories


The following list describes security concerns that are common to the Pickup directory and the Replay directory:

Any security checks configured on a Receive connector, such as anti-spam, antivirus, sender filtering, or recipient filtering actions, aren't performed on messages submitted through the Pickup directory or the Replay directory. A compromised Pickup directory or Replay directory can act as an open relay. This enables messages to be resubmitted or relayed by using a different server to mask the true source of the messages. The following list describes additional security concerns that apply to the Replay directory:

The X-Headers used by the Replay directory allow for the manual creation of the message envelope. The information in the X-Sender and X-Receiver fields can be completely different from the To or From message header fields displayed by e-mail clients. Such an impersonation of a sender and a domain is frequently called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message. If the X-CreatedBy field has the value of MSExchange14, the destination is considered trustworthy, and a header firewall isn't applied. A header firewall is a way for Exchange to preserve X-Headers in messages transmitted between trusted Exchange 2010 servers or to remove potentially revealing X-Headers from messages transmitted to untrusted destinations outside the Exchange organization. These X-Headers can be used to share Exchange 2010 information such as spam confidence level (SCL), message signing, or encryption between authorized Exchange 2010 servers. Revealing this information to unauthorized sources could pose a potential security risk. Tighter security should be applied to the Replay directory because of the additional security risks associated with the Replay directory. Users or applications that must generate and submit messages can be granted access to the Pickup directory, but they shouldn't require access to the Replay directory. Both the Pickup directory and the Replay directory are enabled by default on all Hub Transport servers and Edge Transport servers. If the Pickup directory or the Replay directory isn't required on a specific Hub Transport server or Edge Transport server in your organization, you can disable the Pickup directory or the Replay directory on that server. For more information, see the following topics:

Configure the Pickup Directory Configure the Replay Directory Return to top

Permissions for the Pickup and Replay Directories


The following permissions are required on the Pickup and Replay directories:

Administrator: Full Control System: Full Control Network Service: Read, Write, and Delete Subfolders and Files By default, the Microsoft Exchange Transport service uses the security credentials of the Network Service user account to manage the location and permissions of the Pickup and Replay directories. The Network Service account requires these permissions on the Pickup directory so that .eml files can be opened, renamed to .tmp and deleted, or renamed to .bad if the message is classified as badmail. You can move the location of these directories by using the PickupDirectoryPath and ReplayDirectoryPath parameters on the Set-TransportServer cmdlet. Successfully changing the location of the Pickup directory depends on the rights granted to the Network Service account at the new directory locations, and whether the new directories already exist. If the directory doesn't exist, and the Network Service account has the rights required to create folders and apply permissions at the new location, the directory is created, and the correct permissions are applied to it. If the new directory already exists, the existing folder permissions aren't checked. Whenever you move the directory locations by using the PickupDirectoryPath or ReplayDirectoryPath parameter with the Set-TransportServer cmdlet, always verify that the new directory exists and that the new directory has the correct permissions applied to it. Return to top

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Priority Queuing


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2011-02-25 Priority queuing is a feature of Microsoft Exchange Server 2010 that enables the sender-defined priority of a message to influence the processing of the message by a server running Exchange that has the Hub Transport server role installed. The message priority is assigned by the sender in Microsoft Outlook when the sender creates and sends the message. The sender can set any of the following message priority values in Outlook:

Low importance Normal importance High importance The default priority for a message created in Outlook or Microsoft Office Outlook Web App is Normal priority. The message priority is stored in the X-Priority header field in the message header. Every message sent or received in an Exchange 2010 organization must be categorized on a Hub Transport server before it can be routed and delivered. The categorizer on a Hub Transport server picks up one message at a time from the Submission queue and performs recipient resolution, routing resolution, and content conversion on the message before putting the message in a delivery queue. For more information, see Understanding Transport Pipeline. Delivery queues are dynamically created based on the destination of a message. Mailbox delivery queues are created for messages destined for Mailbox servers that exist in the same Active Directory site as the Hub Transport server. Remote delivery queues are created for messages destined for Mailbox servers that exist in a different Active Directory site than the Hub Transport server, and for remote domains. For more information, see Understanding Transport Queues. All messages that have the same destination are put in the same delivery queue. Priority queuing affects the transmission of messages from a delivery queue to the destination messaging server. When priority queuing is enabled, High priority messages are transmitted to their destinations before Normal priority messages, and Normal priority messages are transmitted to their destinations before Low priority messages. The prioritized delivery of messages based on the message priority can help you define specific service level agreement (SLA) requirements for message delivery times.

Options for Configuring Priority Queuing


All configuration options for priority queuing are available in the EdgeTransport.exe.config application configuration file located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory. For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File. Many configuration options available are unrelated to priority queuing. Any configuration options that don't involve back pressure are outside the scope of this topic.

Enabling or Disabling Priority Queuing


The PriorityQueuingEnable parameter enables or disables priority queuing on a Hub Transport server. The default value is False. To enable priority queuing, set the PriorityQueuingEnable parameter value to True in the EdgeTransport.exe.config file and restart the Microsoft Exchange Transport service.

Configuring the Maximum Size of a High Priority Message


The MaxHighPriorityMessageSize parameter controls the maximum allowed size of a High priority message. The default value is 250 kilobytes (KB). If a High priority message is larger than the value of the MaxHighPriorityMessageSize parameter, the message is automatically downgraded from High priority to Normal priority. When you enter a value, qualify the value with one of the following units:

KB (kilobytes) MB (megabytes) GB (gigabytes) The value of the MaxHighPriorityMessageSize parameter should be significantly less than the value of the MaxMessageSize parameter on the Set-TransportConfig cmdlet. The default value of the MaxMessageSize parameter is 10 MB. A smaller value in the MaxHighPriorityMessageSize parameter helps ensure consistent and predictable delivery times for High priority messages.

Configuring the Delay Notification Time-Out Based on the Message Priority


After each message delivery failure, the Hub Transport server generates a delay delivery status notification (DSN) message and queues it for delivery to the sender of the undeliverable message. This delay DSN message is sent only after a specified delay notification time-out interval, and only if the failed message wasn't successfully delivered during that time. This delay prevents the sending of unnecessary delay DSN messages that may be caused by temporary message transmission failures. The following table shows the delay DSN notification time-out options based on the message priority.

Delay DSN notification time-out options based on the message priority


Parameter name LowPriorityDelayNotificationTimeout Default value 8:00:00 (8 hours)

NormalPriorityDelayNotificationTimeout HighPriorityDelayNotificationTimeout

4:00:00 (4 hours) 00:30:00 (30 minutes)

To specify a value for a delay notification time-out, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. If the value is less than 1 day, you can omit the day part of the time span.

Configuring the Message Expiration Time-Out Based on the Message Priority


The message expiration time-out specifies the maximum length of time that a Hub Transport server tries to deliver a failed message. If the message can't be successfully delivered before the expiration time-out interval has passed, a non-delivery report (NDR) that contains the original message or the message headers is delivered to the sender. The following table shows the message expiration time-out options based on the message priority.

Message expiration time-out options based on the message priority


Parameter name LowPriorityMessageExpirationTimeout NormalPriorityMessageExpirationTimeout HighPriorityMessageExpirationTimeout Default value 2.00:00:00 (2 days) 2.00:00:00 (2 days) 8:00:00 (8 hours)

To specify a value for a message expiration time-out, enter the value as a time span: dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. If the value is less than 1 day, you can omit the day part of the time span.

Configuring the Maximum Number of Connections Per Domain Based on the Message Priority
The maximum number of connections per domain specifies the maximum number of connections that a Hub Transport server can have open to any single remote domain. The outgoing connections to remote domains occur by using the remote delivery queues and Send connectors that exist on the Hub Transport server. The following table shows the maximum number of connections per domain options based on the message priority.

Maximum number of connections per domain options based on the message priority
Parameter name MaxPerDomainLowPriorityConnections MaxPerDomainNormalPriorityConnections MaxPerDomainHighPriorityConnections Default value 2 15 3

The sum of the MaxPerDomainLowPriorityConnections parameter, the MaxPerDomainNormalPriorityConnections parameter, and the MaxPerDomainNormalPriorityConnections parameter should be less than or equal to the value of the MaxPerDomainOutboundConnections parameter on the SetTransportServer cmdlet. The default value of the MaxPerDomainOutboundConnections parameter is 20.

How Priority Queuing Affects Other Message Limits on Hub Transport Servers
All messages that pass through a Hub Transport server are subject to a variety of message retry, resubmit, and expiration limits. For more information, see Understanding Transport Queues. Some message limits available in the Set-TransportServer cmdlet have corresponding priority queuing message limits available in the EdgeTransport.exe.config configuration file. The following table shows these corresponding message limits.

Message limits in the Set-TransportServer cmdlet that correspond to priority queuing message limits in the EdgeTransport.exe.config configuration file
Source Set-TransportServer EdgeTransport.exe.config Set-TransportServer EdgeTransport.exe.config Parameter DelayNotificationTimeOut NormalPriorityDelayNotificationTimeout MessageExpirationTimeOut NormalPriorityMessageExpirationTimeout Default value 4:00:00 (4 hours) 4:00:00 (4 hours) 2.00:00:00 (2 days) 2.00:00:00 (2 days)

When priority queuing is disabled, all the priority queuing message limits that exist in the EdgeTransport.exe.config configuration file are ignored. All the message limits on the Set-TransportServer cmdlet apply to all messages that travel through the Hub Transport server. When priority queuing is enabled, the priority queuing message limits in the EdgeTransport.exe.config configuration file override the corresponding message limits in

the Set-TransportServer cmdlet. All other message limits in the Set-TransportServer cmdlet still apply to Low priority, Normal priority, and High priority messages that travel through the Hub Transport server.

User Settings for Priority Queuing


The Set-Mailbox cmdlet in the Exchange Management Shell has the DowngradeHighPriorityMessagesEnabled parameter. The default value is False. When this parameter is set to True, any High priority messages sent from the mailbox are automatically downgraded to Normal priority. For more information, see SetMailbox.

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Receive Connectors


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2012-07-23 Receive connectors are configured on computers that are running Microsoft Exchange Server 2010 and that have the Hub Transport server role or Edge Transport server role installed. Receive connectors represent a logical gateway through which all inbound messages are received. This topic provides an overview of Receive connectors and how the configuration of Receive connectors affects individual message processing.

Overview of Receive Connectors


Exchange 2010 transport servers require Receive connectors to receive messages from the Internet, from e-mail clients, and from other e-mail servers. A Receive connector controls inbound connections to the Exchange organization. By default, the Receive connectors that are required for internal mail flow are automatically created when the Hub Transport server role is installed. The Receive connector that's capable of receiving mail from the Internet and from Hub Transport servers is automatically created when the Edge Transport server role is installed. However, end-to-end mail flow is possible only after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual connector configuration to establish end-to-end mail flow. In Exchange 2010, the Receive connector is a receive listener. This means that the connector is listening for inbound connections that match the settings of the Receive connector. A Receive connector listens for connections that are received through a particular local IP address and port, and from a specified IP address range. You create Receive connectors when you want to control which servers receive messages from a particular IP address or IP address range, and when you want to configure special connector properties for messages that are received from a particular IP address, such as a larger message size, more recipients per message, or more inbound connections. Receive connectors are scoped to a single server and determine how that specific server listens for connections. When you create a Receive connector on a Hub Transport server, the Receive connector is stored in Active Directory as a child object of the server on which it's created. When you create a Receive connector on an Edge Transport server, the Receive connector is stored in Active Directory Lightweight Directory Services (AD LDS). If you need additional Receive connectors for specific scenarios, you can create them by using the Exchange Management Console (EMC) or the Exchange Management Shell. Each Receive connector must use a unique combination of IP address bindings, port number assignments, and the remote IP address ranges from which mail will be accepted by this connector.

Default Receive Connectors Created During Setup


Certain Receive connectors are created by default when you install a Hub Transport or Edge Transport server role.

Default Receive Connectors Created on a Hub Transport Server


When you install the Hub Transport server role, two Receive connectors are created. No additional Receive connectors are needed for typical operation, and in most cases the default Receive connectors don't require a configuration change. The usage type and configuration of these connectors are described in the following table.

Default Receive connector configuration on Hub Transport servers


Connector name and usage type Client Servername This Receive connector accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. Configuration

Status: Enabled. Protocol logging level: None. Connector fully qualified domain name (FQDN): Servername.forestroot.extension Bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server. Port: 587. This is the default port for receiving messages from all non-MAPI clients for SMTP relay. Remote server IP address range: 0.0.0.0255.255.255.255 IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 IPv6. The Hub Transport server accepts mail that's sent from any IP address. Available authentication methods: Transport Layer Security (TLS), Basic authentication, Exchange Server authentication, Integrated Windows authentication. Permission groups: Exchange users.

Default Servername This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers you have.

Status: Enabled. Protocol logging level: None. Connector FQDN: Servername.forestroot.extension Local server Receive connector bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server. Port: 25. Remote server IP address range: 0.0.0.0255.255.255.255 IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 IPv6.. The Hub Transport server accepts mail that's sent from any IP address. Available authentication methods: TLS, Basic authentication, Integrated Windows authentication. Permission groups: Exchange users, Exchange servers, Legacy Exchange servers.

Note: Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type.

Default Receive Connector Created on an Edge Transport Server


During installation, one Receive connector is created. This Receive connector is configured to accept SMTP communications from all IP address ranges and is bound to all IP addresses of the local server. It's configured to have the Internet usage type, and therefore, the connector accepts anonymous connections. In a typical installation, no additional Receive connectors are required. If you use EdgeSync, you don't need to make any configuration changes because the Edge Subscription process automatically configures permissions and authentication mechanisms. Anonymous sessions and authenticated sessions are granted different permission sets. If you don't use EdgeSync, we recommend that you modify the settings of this Receive connector and create an additional Receive connector of the Internal usage type. To complete Receive connector configuration, follow these steps:

1. Modify the settings of the default Receive connector Set the local network bindings to the IP address of only the Internet-facing network adapter. 2. Create a Receive connector Select Internal as the connector usage type. Set the local network bindings to the IP address of only the organization-facing network adapter. Configure the remote network settings to receive mail from the remote IP addresses that are assigned to the Hub Transport servers. Note: Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type. 3. Determine whether Basic authentication is desired If you want to support Basic authentication, create a local user account and grant the necessary permissions by using the Add-ADPermission cmdlet. For more information, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync.

Receive Connector Usage Types


The usage type determines the default security settings for the connector. The security settings for a Receive connector specify the permissions that are granted to sessions that connect to the Receive connector and the supported authentication mechanisms. When you use the EMC to configure a Receive connector, the New SMTP Receive Connector wizard prompts you to select the usage type for the connector. You can use two different methods to specify the usage type:

Use the Usage parameter with the desired value, such as Usage Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, the command will fail. Use the switch parameter for the desired usage type, such as Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, you're prompted for the missing parameter values so the command can continue.

Permission Groups
A permission group is a predefined set of permissions that's granted to well-known security principals and assigned to a Receive connector. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID). Permission groups are only available for Receive connectors. The use of permission groups simplifies the configuration of permissions on Receive connectors. The PermissionGroups property defines the groups or roles that can submit messages to the Receive connector and the permissions that are assigned to those groups. The set of permission groups is predefined in Exchange 2010. This means that you can't create additional permission groups. Also, you can't modify the permission group members or the associated permissions. The following table lists the available permission groups and identifies the security principals and the permissions that are granted when that permission group is configured for a Receive connector. Receive connector permission groups

Permission group name Anonymous

Associated security principals (SIDs) Anonymous user account

Permissions granted

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-Accept-Headers-Routing

ExchangeUsers

Authenticated user accounts

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Bypass-Anti-Spam Ms-Exch-Accept-Headers-Routing

ExchangeServers

Hub Transport servers Edge Transport servers Exchange Servers (Hub Transport server only)

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient

Externally Secured servers

Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50 Ms-Exch-Accept-Headers-Organization Note: This permission isn't granted to Externally Secured servers. Ms-Exch-Accept-Headers-Forest Note: This permission isn't granted to Externally Secured servers.

ExchangeLegacyServers

Exchange Legacy Interop security group

Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50

Partner

Partner Server account

Ms-Exch-SMTP-Submit Ms-Exch-Accept-Headers-Routing

Receive Connector Usage Types


The usage type determines the default permission groups that are assigned to the Receive connector and the default authentication mechanisms that are available for session authentication. A Receive connector always responds to a request from a sender to use TLS. The following table describes the available usage types and default settings. Receive connector usage types

Usage type Client (unavailable on Edge Transport servers)

Default permission groups ExchangeUsers

Default authentication mechanism TLS Basic authentication plus TLS Integrated Windows authentication None Exchange Server authentication

Custom Internal

None ExchangeServers ExchangeLegacyServers (This permission group is unavailable on Edge Transport servers.) AnonymousUsers Partner Partner

Internet

None or Externally Secured

Partner

Not applicable. This usage type is selected when you establish mutual TLS with a remote domain.

The Receive connector permissions and authentication mechanisms are discussed later in this topic.

Receive Connector Usage Scenarios


Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:

Add-ADPermission Remove-ADPermission The following table lists common connection scenarios and the usage type for each scenario. Receive Connector usage scenarios

Connector scenario

Usage type

Comment

Edge Transport server receiving e-mail from the Internet Hub Transport server receiving e-mail from the Internet Edge Transport server receiving e-mail from an Exchange Server 2003 bridgehead server Hub Transport server receiving e-mail submissions from a client application that uses POP3 or IMAP4 Hub Transport server receiving e-mail from a Hub Transport server Hub Transport server receiving e-mail from an Exchange 2003 bridgehead server in the same forest

Internet

A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. This isn't a recommended configuration. For more information, see Configure Internet Mail Flow Directly Through a Hub Transport Server. In this scenario, the Exchange 2003 bridgehead server is configured to use the Edge Transport server as a smart host for a Send connector.

Internet

Internal

Client

This Receive connector is automatically created on every Hub Transport server when the role is installed. By default, this Receive connector is configured to receive e-mail through TCP port 587.

Internal

You don't have to configure Receive connectors between Hub Transport servers within the same organization. This usage type can be used to configure a cross-forest Receive connector. This is an optional configuration. Transport between Exchange 2010 and earlier versions of Exchange is accomplished through two-way routing group connectors. If you create SMTP connectors to Exchange 2003 routing groups, a routing group connector must also exist. For more information, see Create Additional Routing Group Connectors from Exchange 2010 to Exchange 2003. A Receive connector that's configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. You can create another connector and configure it to receive e-mail only from the Exchange organization. For detailed configuration steps, see Configure Cross-Forest Connectors.

Internal

Edge Transport server receiving e-mail from a Hub Transport server

Internal

Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from a Hub Transport server in a second forest Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from an Exchange 2003 bridgehead server in a second forest Hub Transport server receiving e-mail from a third-party message transfer agent (MTA) Edge Transport server receiving e-mail from a third-party MTA

Custom

Custom

For detailed configuration steps, see Configure Cross-Forest Connectors.

Internal

Specify the IP address range from which messages will be accepted and set the authentication mechanism to either Basic authentication or Externally Secured.

Custom

Use the Add-ADPermission cmdlet to set the extended rights. Specify the IP address range from which messages will be accepted and set the authentication mechanism to Basic authentication. You can also select the Internal usage type and set Externally Secured as the authentication method. No additional permissions configuration is required if you select this option. The Edge Transport server can accept e-mail from an external relay domain and then relay to the destination recipient domain. Specify the IP address range from which messages will be accepted, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights. Mutual TLS authentication functions correctly only if the following conditions are true: The value of the DomainSecureEnabled parameter is set to $true. The value of the AuthMechanism parameter contains TLS and doesn't contain External. The TLSReceiveDomainSecureList parameter in the Transport configuration contains at least one domain that's serviced by this Receive connector. The wildcard character (*) isn't supported in domains that are configured for mutual TLS authentication. The same domain must also be defined on the corresponding Send connector, and in the value of the TLSSendDomainSecureList parameter in the Transport configuration. For more information, see Set-ReceiveConnector.

Edge Transport server receiving e-mail from an external relay domain

Custom

Edge Transport server receiving e-mail from a domain to which you have established mutual TLS authentication

Partner

Edge Transport server receiving connections from Microsoft Exchange Hosted Services server Hub Transport server receiving connections from an Exchange Hosted Services server

Custom

The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to ExchangeServers. The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to ExchangeServers.

Custom

Receive Connector Permissions


Receive connector permissions are assigned to security principals when you specify the permission groups for the connector. When a security principal establishes a session with a Receive connector, the Receive connector permissions determine whether the session is accepted and how the received messages are processed. The following table describes the permissions that can be assigned on a Receive connector to security principals. You can set Receive connector permissions by using the EMC or by using the PermissionGroups parameter with the Set-ReceiveConnector cmdlet in the Shell. To modify the default permissions for a Receive connector, you can also use the Add-ADPermission cmdlet.

Receive connector permissions

Receive connector permission ms-Exch-SMTPSubmit ms-Exch-SMTPAccept-AnyRecipient ms-Exch-SMTPAccept-Any-Sender ms-Exch-SMTPAcceptAuthoritativeDomain-Sender ms-Exch-SMTPAcceptAuthentication-Flag ms-Exch-AcceptHeaders-Routing ms-Exch-AcceptHeadersOrganization ms-Exch-AcceptHeaders-Forest ms-Exch-AcceptExch50 ms-Exch-BypassMessage-SizeLimit Ms-Exch-BypassAnti-Spam

Description

The session must be granted this permission or it will be unable to submit messages to this Receive connector. If a session doesn't have this permission, the MAIL FROM and AUTH commands will fail. This permission allows the session to relay messages through this connector. If this permission isn't granted, only messages that are addressed to recipients in accepted domains are accepted by this connector.

This permission allows the session to bypass the sender address spoofing check.

This permission allows senders that have e-mail addresses in authoritative domains to establish a session to this Receive connector.

This permission allows Exchange 2003 servers to submit messages from internal senders. Exchange 2010 will recognize the messages as being internal. The sender can declare the message as trusted. Messages that enter your Exchange system through anonymous submissions will be relayed through your Exchange organization with this flag in an untrusted state. This permission allows the session to submit a message that has all received headers intact. If this permission isn't granted, the server will strip all received headers. This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with X-MSExchange-Organization-. If this permission isn't granted, the receiving server will strip all organization headers.

This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn't granted, the receiving server will strip all forest headers. This permission allows the session to submit a message that contains the XEXCH50 command. This command is needed for interoperability with Exchange 2003. The XEXCH50 command provides data such as the spam confidence level (SCL) for the message. This permission allows the session to submit a message that exceeds the message size restriction configured for the connector.

This permission allows the session to bypass anti-spam filtering.

Local Network Settings


In the EMC, you use the local network settings for a Receive connector to specify the IP address and port through which the transport server accepts connections. In the Shell, use the Bindings parameter to specify the local IP address and port of the transport server through which the Receive connector accepts connections. These settings bind the Receive connector to a particular network adapter and TCP port on the transport server. By default, a Receive connector is configured to use all available network adapters and TCP port 25. If a transport server has multiple network adapters, you may want a Receive connector to be bound to a particular network adapter, or to accept connections through an alternative port. For example, you may want to configure one Receive connector on the Edge Transport server to accept anonymous connections through the external network adapter. A second Receive connector can be configured to accept connections from only Hub Transport servers through the internal network adapter. Note: If you choose to bind a Receive connector to a specific local IP address, that IP address must be valid for the Hub Transport server or Edge Transport server on which the Receive connector is located. If you specify an invalid local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted. Instead of binding the Receive connector to a specific IP address, you can bind the Receive connector to all available IP addresses on the Hub Transport server or Edge Transport server. Specify the IP address of the network adapter when you configure Receive connector bindings. If the Receive connector is configured to accept connections through a port other than the default, the sending client or server must be configured to send to that port and any firewalls between the message sender and the receiving server must allow network traffic through that port. The Local Network Settings page of the New SMTP Receive Connector wizard in the EMC includes an option to Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-ReceiveConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the receiving server if you configure this property on a Receive connector. The FQDN value is displayed to connected messaging servers whenever a destination server name is required, as in the following examples:

In the default SMTP banner of the Receive connector In the most recent Received: header field in the incoming message when the message enters the Hub Transport server or Edge Transport server During TLS authentication

Note: Dont modify the FQDN value on the default Receive connector named Default <Server Name> that's automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the Default <Server Name> Receive connector, internal mail flow between Hub Transport servers will fail.

Remote Network Settings


In the EMC, you use the remote network settings for a Receive connector to specify the IP address ranges from which this Receive connector accepts connections. In the Shell, you use the RemoteIPRanges parameter to specify the IP address ranges from which this Receive connector accepts connections. By default, Receive connectors are created on Hub Transport servers and Edge Transport servers that allow connections from 0.0.0.0255.255.255.255, or from every IP address. Note: In Exchange 2010 , the IPv6 address range 0000:0000:0000:0000:0000:0000:0.0.0.0ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 also exists in the default Receive connectors on a Hub Transport server. If you're configuring a Receive connector for a specific scenario, set the remote network settings to only the IP addresses of the servers that should be allowed the permissions and configuration settings for the Receive connector. Multiple Receive connectors can have overlapping remote IP address ranges as long as one range is completely overlapped by another. When remote IP address ranges overlap, the remote IP address range that has the most specific match to the connecting server's IP address is used. The IP address or IP address range for the remote servers from which the Receive connector will accept inbound connections is entered in one of the following formats:

IP address 192.168.1.1 IP address range 192.168.1.10-192.168.1.20 IP address together with subnet mask 192.168.1.0(255.255.255.0) IP address together with subnet mask by using Classless Interdomain Routing (CIDR) notation 192.168.1.0/24

Receive Connector Authentication Settings


In the EMC, you use the authentication settings for a Receive connector to specify the authentication mechanisms that are supported by the Exchange 2010 transport server. In the Shell, you use the AuthMechanisms parameter to specify the supported authentication mechanisms. You can configure more than one authentication mechanism for a Receive connector. For the authentication mechanisms that are automatically configured for each usage type, see the table labeled "Receive connector usage types" earlier in this topic. The following table lists the available authentication mechanisms for a Receive connector. Receive connector authentication mechanisms

Authentication mechanism None TLS Integrated BasicAuth BasicAuthRequireTLS ExchangeServer ExternalAuthoritative

Description

No authentication. Advertise STARTTLS. Requires availability of a server certificate to offer TLS. NTLM and Kerberos (Integrated Windows authentication). Basic authentication. Requires an authenticated logon. Basic authentication over TLS. Requires a server certificate. Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI). The connection is considered externally secured by using a security mechanism that's external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN). Alternatively, the servers may reside in a trusted physically controlled network. The ExternalAuthoritative authentication method requires the ExchangeServers permission group. This combination of authentication method and security group permits the resolution of anonymous sender e-mail addresses for messages that are received through this connector. This replaces the Resolve anonymous senders function in Exchange Server 2003.

Additional Receive Connector Properties


The property configuration for a Receive connector defines how e-mail is received through that connector. Not all properties are available in the EMC. For more information about the properties that can be configured by using the Shell, see Set-ReceiveConnector.

Using a Receive Connector for Anonymous Relay


Anonymous relay on Internet SMTP messaging servers is a serious security deficiency that could be exploited by unsolicited commercial e-mail senders, or spammers, to hide the source of their messages. Therefore, restrictions are placed on Internet-facing messaging servers to prevent relaying to unauthorized destinations. In Exchange 2010, relaying is typically handled by using accepted domains. Accepted domains are configured on the Edge Transport server or Hub Transport server. The accepted domains are additionally classified as internal relay domains or external relay domains. For more information about accepted domains, see Understanding Accepted Domains.

You can also restrict anonymous relay based on the source of the incoming messages. This method is useful when an unauthenticated application or messaging server must use a Hub Transport server or an Edge Transport server as a relay server. When you create the Receive connector that's configured to allow anonymous relay, you should place the following restrictions on the Receive connector:

Local network settings Restrict the Receive connector to listen only on the appropriate network adapter on the Hub Transport server or Edge Transport server. Remote network settings Restrict the Receive connector to accept connections only from the specified server or servers. This restriction is necessary, because the Receive connector is configured to accept relay from anonymous users. Restricting the source servers by IP address is the only measure of protection that's allowed on this Receive connector. To grant the relay permission to anonymous users on the Receive connector, you can use either of the strategies described later in this topic. Each strategy has advantages and disadvantages. For step by step instructions for both approaches, see Allow Anonymous Relay on a Receive Connector.

Granting Relay Permission to Anonymous Connections


This strategy involves the following tasks:

Creating a Receive connector with the usage type set to Custom. Adding the Anonymous permission group to the Receive connector. Assigning the relay permission to the Anonymous Logon security principal on the Receive connector. The Anonymous permission group grants the following permissions to the Anonymous Logon security principal on the Receive connector:

Ms-Exch-Accept-Headers-Routing Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-SMTP-Submit However, to allow anonymous relay on this Receive connector, you must also grant the following permission to the Anonymous Logon security principal on the Receive connector:

Ms-Exch-SMTP-Accept-Any-Recipient The advantage of this strategy is that it grants the minimum required permissions to relay to the specified remote IP addresses. The disadvantages of this strategy are as follows:

Additional configuration steps are required to grant the necessary permissions. The messages that originate from the specified IP addresses are treated as anonymous messages. Therefore, the messages don't bypass anti-spam checks, don't bypass message size limit checks, and anonymous senders can't be resolved. The process of resolving anonymous senders forces an attempted match between the anonymous sender's e-mail address and the corresponding display name in the global address list (GAL).

Configuring the Receive Connector as Externally Secured


This strategy involves the following tasks:

Creating a Receive connector with the usage type set to Custom. Adding the ExchangeServers permission group to the Receive connector. Adding the ExternalAuthoritative authentication mechanism to the Receive connector. The ExchangeServers permission group is required when you select the ExternalAuthoritative authentication mechanism. This combination of authentication method and permission group grants the following permissions to any incoming connection that's permitted on the Receive connector:

Ms-Exch-Accept-Headers-Routing Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-SMTP-Submit Ms-Exch-Accept-Exch50 Ms-Exch-Bypass-Anti-Spam Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-SMTP-Accept-Authentication-Flag The advantages of this strategy are as follows:

Ease of configuration The messages that originate from the specified IP addresses are treated as authenticated messages. The messages bypass anti-spam checks, bypass message size limit checks, and can resolve anonymous senders. The disadvantage of this strategy is that the remote IP addresses are considered completely trustworthy. The permissions that are granted to the remote IP addresses allow the remote messaging server to submit messages as if they originated from internal senders within your Exchange organization.

New Features in Exchange 2010 Service Pack 1


In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Receive connectors. This section provides an overview of these new features.

Bare Line Feed Control


When a mail server establishes an SMTP session, it issues SMTP commands to send messages. After specifying the sender and recipient information, the sending server transmits the contents of the message using the DATA command. The content that is transmitted after issuing the DATA command is known as the data stream. The data stream is terminated by a special sequence of characters: a carriage return line feed (CRLF), followed by a period, followed by another CRLF. Line feed LF characters that arent immediately preceded by carriage return CR characters are known as bare line feeds. Bare line feeds arent allowed in SMTP communications. Although it may be possible for a message containing a bare line feed to be delivered successfully, such messages don't adhere to the SMTP protocol standards and may cause problems with messaging servers. In Exchange 2010 SP1, you can configure your Receive connectors to reject any messages that contain bare line feeds in their data stream. This behavior is controlled by the BareLineFeedRejectionEnabled parameter of the Set-ReceiveConnector cmdlet. By default, this setting is disabled to maintain backwards compatibility. For more information about configuring this parameter, see Set-ReceiveConnector.

Extended Protection Capability


Windows offers channel binding to protect NTLM authentication over encrypted channels from authentication relay attacks. In Exchange 2010, all services provided by Exchange have been updated to support Extended Protection for Authentication. To support this feature in Transport, the Receive connectors have been updated. You can allow, require, or disable Extended Protection for Authentication on your Receive connectors. You can use the ExtendedProtectionPolicy and ExtendedProtectionTlsTerminatedAtProxy parameters of the Set-ReceiveConnector cmdlet to control how your Transport servers handle extended protection. You can configure a Receive connector to allow or require extended protection. When you configure a Receive connector to require extended protection, any incoming connections from hosts that don't support extended protection will be rejected. To maintain backwards compatibility, the extended protection is disabled by default. For more information about configuring extended protection on your Receive connectors, see Set-ReceiveConnector. To learn more about extended protection, see the following resources:

Microsoft Knowledge Base article 973811, Microsoft Security Advisory: Extended protection for authentication MSDN Library topic, Integrated Windows Authentication with Extended Protection

2010 Microsoft Corporation. All rights reserved.


2013 Microsoft. All rights reserved.

Understanding Recipient Resolution


Exchange 2010 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2 Topic Last Modified: 2010-01-25 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 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 2010 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's responsible for recipient resolution is frequently called the resolver. Contents Top-Level Resolution Expansion Bifurcation and Controlling Recipient Expansion Recipient Resolution Diagnostics

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 objects 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 among 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 isn't 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's encapsulated inside a valid SMTP address. Exchange 2010 supports encapsulated addresses that use the Internet Mail Connector Encapsulated Address (IMCEA) encapsulation method. This encapsulation 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 2010 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's 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 Understanding Accepted Domains. The maximum length for an SMTP e-mail address in Exchange 2010 is 571 characters. This limit includes the following:

315 characters for the name part of the address 255 characters for the domain name

The at sign (@) character that separates the name part of the address from the domain name Currently, Exchange 2010 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's used to query Active Directory. Any encapsulated addresses are unencapsulated before they're 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's 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 2010 recipient types, see Understanding Recipients.

Recipient objects in Active Directory


Active Directory recipient type DistributionGroup Description

Any mail-enabled group object. The distribution group object types are as follows: MailUniversalDistributionGroup A universal distribution group object MailUniversalSecurityGroup A universal security group (USG) object that has an e-mail address MailNonUniversalGroup A local security group object or global security group object that has an e-mail address

DynamicDistributionGroup

An object that has the Active Directory class msExchDynamicDistributionList. For more information, see Create a 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 Create a Mail 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 Create a 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 Understanding the Microsoft Exchange Recipient. 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 2010 organization. A user object that has an e-mail address and that's located in the Microsoft Exchange System Objects container. There should be one system mailbox for each mailbox database in the Exchange 2010 organization.

Mailbox MailUser MailContact

MailPublicFolder MicrosoftExchangeRecipient

PublicDatabase SystemAttendantMailbox

SystemMailbox

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 LDAP filter that's 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's used in the message doesn't match the primary SMTP address of the corresponding Active Directory object, the categorizer rewrites the email 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's used for the sender message size restriction is the value of the X-MS-Exchange-Organization-OriginalSize: header field in the message header. Exchange 2010 uses this header field to record the original message size of the message when it entered the Exchange 2010 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's 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. Return to top

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 isn't 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. 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 an alternative delivery address is specified in the ForwardingAddress parameter 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 $true and 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 mailenabled 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's 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 $true or $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 $true or $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 the Disposition-Notification-To: header field are compatible with many different message servers. MDN settings can also be defined by using MAPI properties in Microsoft Outlook and Exchange. 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 won't 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 specific 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 isn't set. Alternatively, report redirection is set to the message sender. Report redirection is set to the distribution group manager, and the delivery report message isn't an NDR. When a delivery report message is sent to a distribution group, the following setting causes 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 isn't 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 aren't modified. If report redirection isn't 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 Set-DistributionGroup SetDynamicDistributionGroup Set-Mailbox Set-MailContact Set-MailPublicFolder Set-MailUser Set-TransportConfig Parameter MaxReceiveSize Description The MaxReceiveSize parameter specifies the size that's used for message restrictions that are configured for recipients is the value of the X-MS-Exchange-OrganizationOriginalSize: header field in the message header. Exchange 2010 uses this header field to record the original message size of the message when it entered the Exchange 2010 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