Abstract: Real-time diagnostics may be provided. A plurality of data feeds may be aggregated from at least one of a plurality of nodes. Upon determining that at least one element of at least one of the data feeds meets a trigger condition, an action associated with the trigger condition may be executed.

Abstract: An example method for migrating communication data from a source server to a target server includes obtaining, using a computing device, a set of credentials to access the source server, and accessing the source server using the set of credentials. The method also includes requesting, automatically by the computing device, a directory structure associated with communication data from the source server, populating, by the computing device, the target server using the directory structure, requesting the communication data from the source server, and populating the target server with the communication data.

Abstract: Conditional deferred queuing may be provided. Upon receiving a message, one or more throttle conditions associated with the message may be identified. A lock associated with the throttle condition may be created on the message until the throttle condition is satisfied. Then, the lock on the message may be removed and the message may be delivered.

Abstract: Message prioritization may be provided. First, a message may be received and a priority level may be calculated for the message. If the message is not rejected for having a priority lower than a predetermined threshold, the message may be placed in a first priority queue. Next, the message may be de-queued from the first priority queue based upon the calculated priority level for the message. Distribution group recipients corresponding to the message may then be expanded and the priority level for the message may be re-calculated based upon the expanded distribution group recipients. Next, the message may be placed in a second priority queue. The message may then be de-queued from the second priority queue based upon the re-calculated priority level for the message and delivered.

Abstract: Address book data available to a user such as contact information, group information, resource information, and similar data, are retrieved from a plurality of sources by a third party service. The retrieved data is customized for consistent presentation and provided to the user without the user's application having to communicate with individual data sources for retrieving the data.

Abstract: Architecture that protects side effect messages by associating the side effect messages with a primary (redundant) message that was received by a transport mechanism (e.g., a message transport agent). Side effect messages are considered “side effects” of a primary message that caused generation of the side effect messages. The primary message is only considered fully delivered after the primary message and all associated side effect messages are delivered, after which the source of the primary message is ACK'd (sent an “ACKnowledgement” message). Hence, in case of hardware failures after the primary message was delivered, but before delivery of side effect messages, the redundancy approach used triggers re-delivery of the primary message and re-generation and delivery of the side effect messages.

Abstract: A root cause for a failed attempted delivery of a message is attempted to be determined before sending a non-delivery report (NDR) for the failed message. When a message fails without a known cause, the root cause is determined using the context of the message. For a given context, the root cause may be determined by a single failure or it may be determined by the relative number of failed messages of same context. While determining the root cause of the problem, any messages failing delivery are deferred from being delivered, as is generation of the corresponding NDR(s), to allow time for corrective action to occur. If the problem is resolved within a predetermined time period, the deferred messages are delivered without having to issue NDR(s).

Abstract: A computing device includes a registered target software process including at least one software component configured to support functionality of the at least one target software and identifiable by a unique component identification parameter, and a first communication module configured to receive a data access request comprising a request to access internal process data of the at least one software component. The process also includes an access manager module linked to the at least one software component and the first communication module, the access manager being configured to receive the data access request from the first communication module and call an interface implementation of the software component that executes the targeted data access request and returns requested internal process data to the access manager, wherein the internal process data is retrieved as the at least one software components is executing on the computing device.

Abstract: A status of connectivity between servers of different sites (locations) is used to infer whether a network or a server failure has occurred such that data between the servers can be routed more efficiently reducing unnecessary network traffic due to duplicate messages. Servers may be grouped based on location or other characteristics and connectivity status determined based on the communication status of individual servers and their respective groups.

Abstract: Architecture for enabling messages to be routed between network servers based on message requirements related to version, capabilities, and features, for example. The message requirements designate delivery over a transport path compatible with the message requirements. The message requirements can include a particular version or other features related to different software applications that require compatibility in message handling. Routing information is maintained related to a transport server or other network transport entity compatible with the message requirements and through which the message can be routed. The message is routed to the compatible transport server for delivery to the destination while avoiding delivery to transport servers incompatible with the message requirements.

Abstract: Transport pipeline decryption may be provided. Consistent with embodiments of the invention, a protected message may be received and decrypted. The decrypted message may be provided to pipeline agents, such as anti-virus, anti-spam, journaling, and/or policy enforcement agents. The message may then be re-encrypted and delivered.

Abstract: A status of connectivity between servers of different sites (locations) is used to infer whether a network or a server failure has occurred such that data between the servers can be routed more efficiently reducing unnecessary network traffic due to duplicate messages. Servers may be grouped based on location or other characteristics and connectivity status determined based on the communication status of individual servers and their respective groups.

Abstract: Business to business secure mail may be provided. Consistent with embodiments of the invention, a protected message may be received. The recipient may request a token from a trust broker, submit the token to an authorization server associated with the sender, receive a user license from the authorization server; and decrypt the protected message using the user license. The protected message may restrict actions that may be taken by the recipient, such as forwarding to other users.

Abstract: Architecture that facilitates transport high availability for messaging services by providing the ability of a receiving entity (e.g., receiving message transfer agent (MTA)) to detect if a sending entity (e.g., sending MTA or client) is a legacy sending entity. When the receiving entity detects that the sending entity is a legacy system, by advertising transport high availability capability to the sending entity, if the sending entity does not opt-in to this capability, the receiving entity keeps the sending entity client “on hold”, that is, waiting for an acknowledgement (ACK) until the receiving entity delivers the message to the next hops (immediate destinations). This approach maintains at least two copies of the message until the message is successfully delivered (to the next hop(s)). Hence, if the legacy sending entity or the receiving entity fails, the message is still delivered successfully.

Abstract: Architecture that protects side effect messages by associating the side effect messages with a primary (redundant) message that was received by a transport mechanism (e.g., a message transport agent). Side effect messages are considered “side effects” of a primary message that caused generation of the side effect messages. The primary message is only considered fully delivered after the primary message and all associated side effect messages are delivered, after which the source of the primary message is ACK'd (sent an “ACKnowledgement” message). Hence, in case of hardware failures after the primary message was delivered, but before delivery of side effect messages, the redundancy approach used triggers re-delivery of the primary message and re-generation and delivery of the side effect messages.

Abstract: Architecture for messaging server extensibility without the need to update or make changes to the messaging server by routing selected messages to a remote location for processing by custom code or third-party code. The messaging server routes the selected messages based server analysis of the messages and in view of configuration data (or conditions) for routing messages. The remote location processes the message and can instruct the messaging server to accept, reject, or redirect the message. Additionally, the remote location can modify the message and instruct the messaging server to process the modified message. The hosted organization can configure triggers to have the messaging server call to a web service with the messages, which extends the functionality of the messaging server.

Abstract: Address book data available to a user such as contact information, group information, resource information, and similar data, are retrieved from a plurality of sources by a third party service. The retrieved data is customized for consistent presentation and provided to the user without the user's application having to communicate with individual data sources for retrieving the data.

Abstract: Architecture for efficiently ensuring that data is stored to the desired destination datastore such as for replication processes. A copy of data (e.g., messages) sent to a datastore for storage is stored at an alternate location until a received signal indicates that the storage and replication was successful. As soon as the feedback signal is received, the copy is removed from the alternate location, and hence, improves input/output (I/O) and storage patterns. The feedback mechanism can also be used for monitoring the status of data transport associated with log shipping, for example, and taking the appropriate actions when storage (e.g., replication) is not being performed properly.