Microsoft Technology Licensing, LLC

Gregory Gourevitch

Wilbert De Graaf

Todd Carlyle Luttinen

Victor Boctor

Lizhuang Zhao

Victor William Habib Boctor

David Alexander Blyth

Abhishek Kumar Agrawal

Wayne Merl Cranston

Vikram Kakumani

Ravi Kiran Reddy Poluri

Faina Sigalov

Yehia Ali Zayour

Arunkumar Chacko

Shubhankar Sanyal

Krishnan Rangarajan

Atapattuge D Samith Gunasekara

Fabio Santos

Bruce Taimana

Puneet Soti

David William Fantham

Deepika Gakhar

Una Sai Prasad Patro

Alex Dubovik

The technology described herein helps improve email security within a multi-tenant email service. In particular, the technology described herein helps make it more difficult for a first tenant of the email service to impersonate a second tenant of the email service by validating the sending domain before the email leaves the multi-tenant email service. In particular, the technology runs a sending-side source validation on an email. If the source validation fails, the email is still sent, but using a source IP address that will cause the email to fail a receiving-side email authentication tests, such as the sender policy framework (SPF) email authentication test. In contrast, if the source validation passes, the email is sent using a source IP address that will cause the email to pass the receiving-side email authentication tests.

Email security in a multi-tenant email service

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.

Using e-mail message characteristics for prioritization

Embodiments maintain filtering criteria for classifying electronic messages in a multi-tenant environment, including maintaining global filtering criteria for all tenants, as well as tenant-level filtering criteria for each tenant. For each tenant, feedback regarding a messaging campaign is identified. When the messaging campaign has not been categorized, and the feedback signals the messaging campaign as undesirable, the tenant-level filtering criteria for the tenant is updated to signal the messaging campaign as undesirable. When the messaging campaign has previously been categorized as undesirable, and the feedback signals the messaging campaign as desirable, the tenant-level filtering criteria for the tenant is updated to signal the messaging campaign as desirable. A reputation score for each tenant is also calculated. The global filtering criteria is updated to signal desirability of the messaging campaign when a threshold number of tenants, each having a threshold reputation score, reach a consensus regarding desirability of the messaging campaign.

User-feedback-based tenant-level message filtering

An application such as a mail transfer agent (MTA) enforces a resource quota within a multi-tenant environment. An email associated with a tenant is managed based on decisions evaluating the email against a queue quota and an association between the email and an email storm. The email is also managed based on another decision evaluating the email against a processing quota. In addition, the email is managed based on a cross MTA aggregate of usage information associated with the first, second, and third decisions.

Enforcing resource quota in mail transfer agent within multi-tenant environment

A simple mail transfer protocol ('SMTP') computer fails to deliver a multi-recipient e-mail to another SMTP computer. The SMTP computer generates a multi-line SMTP response including a per-recipient delivery status for each recipient of the multi-recipient e-mail message. The multi-line SMTP response may include a line for each recipient of the e-mail message. The multi-line SMTP response alternatively may include a line only for recipients for which delivery of the e-mail message has failed.

Communicating per-recipient delivery statuses of multi-recipient messages in multiline simple mail transfer protocol responses

Latency information is collected for each message as it moves through an organization. The latency information includes latency information for components processing the message. When the message is routed to the next server within the organization, the collected latency information for the server sending the message is included with the message. The collected latency information is written to a message tracking log when it either is delivered within the organization or when the message leaves the organization. The message tracking log may then be viewed such that the collected latency information may be viewed and analyzed.

Detailed end-to-end latency tracking of messages

A client computer sends an extended simple mail transfer protocol extended hello command to a server computer. In response, the server computer sends an advertisement to the client computer to identify a capability to receive message context information. The client computer, in turn, analyzes the capability advertisement to determine if it has any blobs associated with the capability identified in the capability advertisement to send. If the client computer has one or more blobs to send, the client computer sends a parameter in a MAIL command to the server computer specifying that the client computer will utilize the capability identified in the capability advertisement and specifying an order in which to expect the blobs if the client computer intends to send more than one blob. The client computer sends the blob(s) to the server computer after receiving an indication that the server computer is ready to receive the blob(s).

Transferring message context information using extended simple mail transfer protocol binary data chunking

A system is provided for applying optimized selection to route an email message over a network to a recipient mailbox. An email message may be enabled to be transmitted through a plurality of servers to a destination recipient mailbox server. An external message transfer agent may receive the email message using Simple Mail Transfer Protocol (SMTP) and may transmit the received email message to a proxy transport server. The proxy transport server may apply a selection for an optimal store-and-forward (SAF) transport server to which to route the email message. The selection may provide for identifying available SAF transport servers, organizing the SAF transport servers into server groups, and selecting the optimal SAF transport server belonging to a server group where a recipient mailbox server is located. The proxy transport server may transmit the email message to the SAF transport server for delivering the message to the recipient mailbox.

Optimized routing for proxy use

Trusted e-mail communication may be provided. A message source organization may be validated. When a message is received from the validated message source organization for a recipient organization, a determination may be made as to whether the recipient organization supports an attribution data extension. If so, the message may be transmitted to the recipient organization with an attribution element associated with the message source organization.

Trusted e-mail communication in a multi-tenant environment

A system is provided for enabling a source MTA to communicate with a target MTA via an SMTP proxy using SMTP commands for transmitting email messages in a networked environment. An email message may be received by a source mail transport agent (MTA) and the source MTA may route the incoming email message to a target MTA via an SMTP proxy. The SMTP proxy may serve as an intermediary proxy server for enabling the source MTA to communicate with an external and internal target MTA. The SMTP proxy may connect to a target MTA via a connection command, and the SMTP proxy may implement custom SMTP commands to communicate additional information about the source MTA to the target MTA. The system may additionally enable the SMTP proxy to perform actions designated by the SMTP commands and to communicate the result of the SMTP proxy's actions back to the source MTA.

Enabling communication between source and target mail transfer agents

A system is provided for storing messaging data at a mail transport agent in a network environment. An email message may be transmitted over a network from a sender client to a recipient server through a plurality of mail transport agents (MTA). An MTA may receive an email message and may store messaging data for the email message in a data store associated with the MTA. The MTA may partition the messaging data into generations representing a defined time frame for the date and time that an email message was received. The MTA may enable a search operation to be performed on the stored generations for retrieving and replaying messaging data to a downstream recipient server. The MTA may continually clean the data store by deleting from the data store a generation of data that has expired and outlived the predefined hold period.

Growing community of inventors

Redmond, WA, United States of America

Gregory Gourevitch