Here is a brief overview of MailTips features that were added in Exchange 2010 SP1:

• MailTips access control over organizational relationships   You have granular control over the way MailTips are shared between your organization and other organizations with which you configured an organizational sharing relationship. You can control the types of MailTips that are shared and even designate a specific group of users for which to return MailTips.
  
  
• MailTips monitoring and troubleshooting   Several new monitoring capabilities for MailTips were added in Exchange 2010 SP1. New capabilities include changes to event log entries, alerts, and performance monitor counters.
  
  

For more information, see Understanding MailTips.

Here is a brief overview of message tracking features that were added in Exchange 2010 SP1:

• Improved error messages for delivery reports   There may be situations where a user attempts to access delivery reports for a specific message but is unable to view the report. For example, a user may attempt to access delivery reports for a message immediately after sending it, but before the tracking information for that message is inserted into the logs. In these types of scenarios, the messages displayed to the users have been greatly improved, providing specific explanations as to why the information isn't available.
  
  
• Message tracking monitoring and troubleshooting   Several new monitoring capabilities for message tracking were added in Exchange 2010 SP1. These include new event log entries, alerts, and performance monitor counters.
  
  
• Message tracking trace levels   When you're troubleshooting message tracking, you can now request complete logs of every operation that was executed by a Client Access server processing a delivery report request.
  
  

For more information, see Understanding Message Tracking.

Transport servers in Exchange 2010 SP1 keep track of the current state of the overall Exchange organization and modify the way they handle messages accordingly. This allows the Transport servers to respond proactively to potentially problematic situations, improving the reliability of the overall message delivery.

In Exchange 2010 SP1, Transport servers maintain a running average delivery cost of messages sent by individual senders. If a user keeps sending costly messages, such as those addressed to large audiences or tha have large attachments, Transport servers start to give priority to other messages that have a lower cost before it processes messages from that sender. For example, if a user is sending multiple messages that have 10MB attachments, Transport starts to first process other messages that don’t have attachments before it handles additional messages from this particular sender.

Transport also keeps track of the RPC utilization of mailbox servers. A Hub Transport server makes RPC connections to a mailbox server for message delivery. If a Hub Transport server detects that a mailbox server is under RPC resource pressure, it scales back the RPC sessions that it opens to that mailbox server. This way, interactive client connections to the mailbox server take precedence over message delivery when it comes to utilizing RPC resources on a mailbox server.

Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on Hub Transport and Edge Transport servers In Exchange 2010. Exchange Transport can detect when vital resources, such as available hard disk space and memory, are under pressure, and take action to try to prevent service unavailability. All configuration options for back pressure are available in the EdgeTransport.exe.config application configuration file.

In Exchange 2010 Service Pack 1, the default values in EdgeTransport.exe.config are revised for following parameters:

• SmtpStartThrottlingDelayInterval: decreased from 10 seconds to 1 second
  
  
• SmtpStepThrottlingDelayInterval: decreased from 5 seconds to 1 second
  
  

For more information about the EdgeTransport.exe.config file, see Understanding the EdgeTransport.exe.Config File.

For more information about back pressure configuration, see Understanding Back Pressure.

For more information about throttling, see Understanding Message Throttling.

Exchange 2010 introduced the shadow redundancy feature to minimize the loss of any message during delivery after it enters the Exchange organization. Exchange Transport servers achieve this by using the shadow redundancy SMTP protocol extension.

However, in any organization Exchange Transport servers need to communicate with other third-party SMTP servers that may not support the shadow redundancy protocol. This is especially true with Edge Transport servers that handle message traffic with various hosts on the Internet. When receiving messages from hosts that don't support shadow redundancy in Exchange 2010 RTM, Transport servers delay sending acknowledgement to incoming messages until they verify final delivery within the organization. However, when a specific threshold was reached, the Transport server issued an acknowledgement even if final delivery wasn't verified. This presented a scenario where messages received from hosts that don't support shadow redundancy can be lost in transit.

To address this issue, a new feature called shadow redundancy promotion is introduced in Exchange 2010 SP1. When faced with the scenario described above, instead of issuing an acknowledgment without delivery confirmation, a Transport server now routes the message to any other Transport server within the site so that the message is protected by shadow redundancy.

There are additional details about how this scenario works. To learn more, see Understanding Shadow Redundancy.

Exchange 2010 SP1 improves the way Transport servers detect unhealthy servers and use enhanced DNS. Enhanced DNS distributes the load evenly when all servers are healthy, but in the case of an unavailable server, the load distribution among the remaining healthy servers may not be evenly balanced.

To address this issue, each Exchange 2010 SP1 Transport server maintains a list of unavailable servers. When routing a message, each server uses this information to filter out the known unavailable servers from the set of target servers. For example, assume that a Hub Transport server needs to route several messages to another Active Directory site which has three Hub Transport servers (Hub1, Hub2, and Hub3). If the server knows that Hub2 is unavailable, it'll remove that server from the list of possible targets and only route to Hub1 and Hub3. It'll assume only two servers, Hub1 and Hub3, exist in the remote Active Directory site when load balancing messages.

As a result, Exchange 2010 SP1 Transport servers always distribute the load evenly between healthy servers and avoid any servers that are unavailable for any reason. For more information, see Understanding SMTP Failover and Load Balancing in Transport.

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. For more information, see Microsoft Knowledge Base article 968389, 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. For more information, see Understanding Receive Connectors.

With Exchange 2010 SP1, several new features were added to the Send connectors. Most changes are to support coexistence with Exchange Online. In addition, the ability to downgrade connection failures was added to the Send connectors.

You may have dedicated Send connectors that are responsible for transmitting messages over well-defined communication channels that are expected to always be available, such as a Send connector dedicated to send messages to Exchange Online. On such connections, many of the typical errors that are possible on ordinary destinations on the Internet aren't expected. In this scenario, you may want to treat any communication errors as transient as opposed to issuing non-delivery reports (NDRs). With Exchange 2010 SP1, you can configure a Send connector to downgrade authentication and name resolution errors, which would normally result in an NDR, to transient errors. In these cases, Exchange will attempt delivery again instead of issuing an NDR.

For more information, see Understanding Send Connectors.