Message transfer agent architecture for electronic mail delivery system

Abstract

To provide a fast, reliable, and managed electronic mail delivery service by using a mail transfer agent (MTA) and a proxy server.SOLUTION: In an electronic mail message delivery system including the MTA and the proxy server, the MTA selects an e-mail message for processing, determines a sender and an intended recipient associated with the email message, identifies a pool of source Internet Protocol addresses available for the e-mail message based on the sender, selects a particular source IP address from the pool, identifies a particular proxy server configured to handle the selected particular source IP address, communicates information including the particular source IP address and the destination IP address to the particular proxy server, and sends the e-mail message to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Non-Provisional Application No. 17 / 345,520, filed June 11, 2021, entitled "Message Transfer Agent Architecture for Email Delivery Systems." The contents of U.S. Non-Provisional Application No. 17 / 345,520 are incorporated herein by reference in their entirety for all purposes. [Background technology]

[0002] background Several cloud service providers offer cloud-based email delivery services that provide a fast and reliable solution for customers of these services to send large volumes of email to targeted recipients. These emails may include marketing emails, transactional emails, alert emails, confirmation emails, and other types of email. An example of such an email delivery service is the Oracle Cloud Infrastructure (OCI) Email Delivery Service offered by Oracle Corporation. The OCI Email Delivery Service provides a platform that uses key deliverability metrics to ensure customers' email sending ratings are the best possible.

[0003] Due to the increasing popularity of email delivery services, the volume of email processed by these services continues to grow rapidly. Existing architectures implementing these services require improvement to make the services scalable, resilient, and reliable. Summary of the Invention [Problem to be solved by the invention]

[0004] Quick Overview The present disclosure relates generally to cloud-based email delivery services and more particularly, but not exclusively, to an improved architecture using mail transfer agents (MTAs) and proxy servers that improves the scalability and reliability of systems implementing email delivery services.

[0005] In a specific embodiment, an email message delivery system that provides an email delivery service is disclosed. The email message delivery system includes an MTA and a proxy server. The MTA selects a first email message to process from a message queue. The message queue includes a set of email messages received from a set of senders. The set of senders corresponds to a set of subscribers (tenants or customers) of the email delivery service. The MTA determines a sender associated with the first email message and determines a recipient of the first email message. Based on the determined sender for the first email message, the MTA identifies source Internet Protocol (IP) addresses, including an IP address that can be used as a source IP address for the first email message. The MTA selects a specific source IP address from the source IP addresses and determines a destination IP address for the recipient of the email message. The MTA identifies a specific proxy server configured to handle the selected specific source IP address from a set of one or more proxy servers, establishes a connection to the proxy server, and communicates information including the specific source IP address and destination IP address to the specific proxy server. The MTA connects the proxy server between the specific source IP address and the destination IP address. The established connection is then used to send the first email message to the destination IP address.

[0006] In certain examples, determining a sender of the first email message includes the MTA determining a user associated with the sender of the first email message and authorized to send the first email message, where the user associated with the sender is determined based at least in part on a "From" field of the first email message. In certain examples, a recipient of the first email message is determined based on a "To" field of the first email message.

[0007] In a particular example, the MTA selects a particular source IP address from the source IP addresses by determining a set of active source IP addresses from the source IP addresses, and selecting a particular source IP address from the set of active source IP addresses. In a particular example, the MTA uses a selection technique for selecting a particular source IP address from the set of active source IP addresses. In a particular example, the selection technique is a round-robin technique.

[0008] In a particular example, a first set of sender source IP addresses are assigned to a first proxy server in the set of proxy servers, and a second set of sender source IP addresses are assigned to a second proxy server in the set of proxy servers. In a particular example, a first proxy server in the set of proxy servers is configured to handle the set of source IP addresses, the first source IP address in the set being associated with a first sender, and the second source IP address in the set being associated with a second sender. In a particular example, the first sender is different from the second sender.

[0009] In a particular example, the MTA identifies a subset of email messages from the email messages associated with the sender and transmits the subset of email messages to the destination IP address using a connection established by the proxy server between the particular source IP address and the destination IP address. In a particular example, the number of messages in the subset of messages is determined based on a message limit associated with the recipient domain, the message limit specifying the number of messages that can be transmitted using the connection established by the proxy server.

[0010] In a particular example, the MTA receives a message from the proxy server indicating that a connection between a particular source IP address and a destination IP address has been successfully established by the proxy server. In a particular example, the proxy server is a Transmission Control Protocol (TCP) proxy server. In a particular example, the MTA and the proxy server are implemented on a single computer system.

[0011] Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, etc. These exemplary embodiments are mentioned not to limit or define the disclosure, but to provide examples to aid in understanding the disclosure. Additional embodiments are described in the detailed description, and further description is provided therein. [Brief explanation of the drawings]

[0012] [Figure 1] 1 illustrates a computing environment including an electronic mail message delivery system (EMDS) that includes improved functionality for efficiently processing and delivering electronic mail messages to a set of recipients, according to certain embodiments. [Figure 2] 2 is an exemplary diagram of the contents of a message queue within the MTA shown in FIG. 1 in accordance with certain embodiments. [Figure 3]1 illustrates an example process performed by an MTA in cooperation with a proxy server to process email messages received by an EMDS for delivery to intended recipients, according to certain embodiments. [Figure 4] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 5] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 6] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 7] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 8] 1 illustrates an exemplary computer system in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0013] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and descriptions are not intended to be limiting. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0014] This disclosure relates generally to cloud-based email delivery services and more particularly, but not exclusively, to an improved architecture using mail transfer agents (MTAs) and proxy servers that improves the scalability and reliability of systems implementing email delivery services.

[0015] A cloud-based email delivery service provides a fast and reliable managed solution for sending large volumes of email that are delivered to a set of intended recipients. A cloud-based email delivery service can be implemented using one or more cloud-based email delivery systems. A cloud-based email delivery system (EMDS) typically includes a set of message submission agents (MSAs) and message transfer agents (MTAs) configured to receive email messages from various tenants or customers of the email delivery service and deliver the email messages to the intended recipients. As described herein, a customer or tenant of the EMDS can represent one or more "senders" of email messages. Various email message delivery protocols can be used to communicate the email messages to the intended recipients. In one embodiment, Simple Message Transfer Protocol (e.g., SMTP) is used to communicate the email messages to the intended recipients.

[0016] To handle outbound message flow, an MSA in an email delivery system typically receives email messages from senders and routes the email messages to an MTA, referred to as the "outbound MTA," as the email message is sent outbound from the email delivery system. A selection technique is used to select the outbound MTA from among multiple available MTAs. In certain implementations, the outbound MTA may be selected randomly. Other implementations may use round-robin selection techniques, least recently used techniques, or other more advanced selection techniques. However, having separate MSA and MTA layers typically increases the additional overhead required to implement such an architecture. This results in an inefficient use of email delivery service resources in terms of additional hardware. Additionally, using multiple MTA tiers requires that the correct set of IP addresses be used to perform the correct routing of messages to the MTA that is connected.

[0017] The email message delivery system described in this disclosure offers several technological advances and / or improvements over traditional cloud-based message delivery services. The email message delivery system described in this disclosure provides a fast, reliable, managed email delivery service by implementing a robust infrastructure of network elements (e.g., MTAs and MSAs) configured to achieve higher operational efficiency and reduce the overall overhead of email processing. Instead of having two separate MSA and MTA layers, where each component in each layer requires its own dedicated resources, resulting in inefficient use of resources and more complex management of multiple email message queues, a new architecture is described that includes an MTA and a proxy server. The MTA is configured to provide the combined functionality of a traditional MSA and MTA.

[0018] In certain implementations, a proxy server may be implemented as a Transmission Control Protocol (TCP) proxy server that acts as an intermediate network entity between a source entity, e.g., a source MTA, and a connection endpoint, where the connection endpoint facilitates delivery of the email message to the intended recipient. To increase the scalability and fault tolerance of the system, the pool of source IP addresses assigned to a particular sender may be distributed across multiple proxy servers. In certain implementations, the IP addresses in the pool of source IP addresses for a particular sender may be divided into non-overlapping address ranges, and each range may be assigned to a separate proxy server, thereby distributing the addresses across multiple proxy servers. This distribution improves the fault tolerance of the EMDS system. If a proxy server serving a particular sender's IP address goes down, another proxy server or servers may still be able to serve the sender and continue delivering email to that sender. From the proxy server's perspective, the source IP addresses designated or assigned to that proxy server may be for only the sender or for multiple senders.

[0019] The new and improved architecture including MTAs and proxy servers further enables resource sharing between the MTAs and proxy servers, resulting in more efficient resource use. In certain implementations, both MTAs and proxy servers can share the same hardware resources. For example, one or more MTAs and one or more proxy servers may be hosted and run by the same computer system. The architecture described herein also simplifies recovery when a proxy server goes down. First, proxy servers are simple and uncomplicated components (e.g., implemented using very few lines of code), reducing their failure rate. However, if a proxy server goes down, the MTA simply stops using that proxy server. The MTA may use and select source IP addresses assigned to other functioning proxy servers to send email messages. When the proxy server starts up again or becomes operational again, the MTA may be restarted using the source IP address assigned to that proxy server.

[0020] Rather than previously requiring the maintenance of multiple email message queues, with a different queue for each sender, the improved architecture described herein allows the MTA to maintain a single message queue that can contain email messages received from multiple different senders and addressed to multiple different recipients. Thus, the MTA does not need to maintain separate message queues for different senders. Furthermore, messages addressed to various recipients can be routed through a single MTA message queue. Thus, the number of message queues an MTA needs to maintain is reduced to a single message queue. This simplifies the recovery procedure if an MTA goes down. If an MTA goes down or becomes inoperable, email messages in the in-memory MTA's message queue can be easily remounted on another MTA without regard to the specific email message or the sender of the email message. Because only a single queue needs to be managed per MTA, the latency between initial transmission and first delivery attempt is also significantly reduced. This metric may be particularly useful for financial services that may utilize email delivery services to distribute buy or sell recommendations and are particularly sensitive to delays.

[0021] Referring now to the drawings, FIG. 1 illustrates a computing environment including an electronic mail message delivery system (EMDS) including improved functionality for efficiently processing and delivering electronic mail messages to a set of recipients, according to certain embodiments. The EMDS 102 may be implemented by one or more computing systems executing computer-readable instructions (e.g., code, programs) to implement the EMDS 102. As shown in FIG. 1, the EMDS 102 includes various systems and subsystems, including a load balancer 108, a set of one or more message transfer agents (MTAs) 110A, 110B, and 110C, and a set of one or more proxy servers 112A, 112B, and 112C. The systems and subsystems illustrated in FIG. 1 may be implemented using software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the computing system, hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device).

[0022] The EMDS 102 can be implemented in a variety of different configurations. In particular embodiments, the EMDS 102 can be implemented on one or more servers in a cloud provider network, and its email message delivery services can be provided to cloud service subscribers on a subscription basis. The computing environment 100 shown in FIG. 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, in some implementations, the EMDS 102 can be implemented using more or fewer subsystems than those shown in FIG. 1, can combine two or more subsystems, or can have a different configuration or arrangement of the subsystems.

[0023] In particular embodiments, the EMDS 102 provides a fast and reliable message delivery service for sending bulk email messages (also referred to herein as messages or emails) to a set of recipients. The email messages can be generated by various sources 104A-104N. A source (e.g., 104A) can represent a system of an entity, such as a customer or tenant (e.g., an organization, business, or individual) of a cloud provider, that subscribes to the services provided by the EMDS 102 to process and deliver email messages to the set of recipients. In particular examples, the EMDS 102 can receive email messages from sources 104A-104N for delivery to the set of recipients. As an example, email message 105A from source 104A can include bulk (e.g., billions) solicited commercial email (e.g., marketing emails, newsletters, coupons, invitations, etc.) or transactional email for delivery to the set of recipients. Each email message can be customized to be delivered to a specific recipient within the set of recipients. As another example, an email message from a source may include a general solicited commercial email message sent by a user of the source for delivery to a set of recipients. As used herein, a user refers to a user of the EMDS. It may refer to an end user, business owner, or marketer associated with a source (e.g., 104A) that interacts with EMDS 102 to utilize the email delivery services provided by 102.

[0024] In a particular example, a user associated with source 104A can interact with EMDS 102 using a user device communicatively coupled to the EMDS, perhaps via public network 106 (e.g., the Internet). The user device can be of various types, including, but not limited to, a mobile phone, a tablet, a desktop computer, etc. For example, the user can interact with EMDS 102 using a user interface (UI) (which may be a graphical user interface (GUI)) of an application executed by the user device. This interaction can include, for example, a user (e.g., an administrator of an organization) setting up various configuration parameters via the UI to enable users of the organization to interact with EMDS 102. For example, through the UI, a user can set up an approved sender list (by identifying the "From:" addresses of all users in the tenant who send email), request the creation of a pool of source IP addresses to be used to identify users in that organization, set up the communication protocol (e.g., Simple Mail Transfer Protocol (SMTP)) and user credentials for users to send email through EMDS 102, specify limits on the maximum number of outbound connections that a source IP address can support simultaneously (i.e., the maximum number of outbound connections that that IP address can have open to a single recipient domain at the same time), and specify message limits on the number of messages that can be sent to a recipient domain over a single connection.

[0025] In certain instances, the number of IP addresses to add to the pool of IP addresses can directly correlate to an organization's message sending volume requirements. Typically, organizations that send a large number of messages per day can have an IP pool with more IP addresses. Additionally, connection limits specified by the recipient domain, which may be the message recipient's email service (inbox) provider (e.g., Gmail®, Yahoo®, Microsoft®, etc.), can affect the number of IP addresses added to the pool. For example, connection limits can specify a limit on the number of simultaneous connections that a single source IP can open to a recipient domain or a limit on the number of messages that can be sent to a recipient domain over a single connection.

[0026] Creating IP pools for an organization using EMDS102 also helps protect the organization's overall reputation and can lead to improved message deliverability. An organization with a good sending reputation may require fewer IPs to deliver emails, as opposed to an organization that generates a large number of spam reports or has poor user engagement. In some cases, an organization may want to create separate IP pools. Separate IP pools allow an organization to send different types of email (monthly newsletters, promotional emails, or transactional emails) through separate sets of IP addresses. For example, an organization could use a "newsletter" pool for monthly newsletters and a "transactional" pool for emails. In this way, each pool of IPs can maintain its own reputation and is not affected by IPs in another pool.

[0027] After configuring the EMDS 102 as described above, an end user associated with a source (e.g., 104A) can send, via a user device, email messages to the EMDS 102 for delivery to a set of one or more recipients. In a particular example, the user can utilize an email client application (e.g., a mail user agent) installed on the device to create the email message. The mail user agent (MUA) can then process the email message before sending it to the EMDS 102. The message may be formatted into an appropriate format. In particular examples, the MUA may utilize a transmission protocol (e.g., SMTP, HTTP, or other protocol) to send the message to the EMDS 102. In particular implementations, email messages may be automatically sent to the EMDS via an application installed on the user's device.

[0028] In certain embodiments, the load balancer 108 in the EMDS 102 may be configured to receive email messages 105A-105N from sources 104A-104N and select an MTA from the set of MTAs 110A-110N in the EMDS 102 to process the email messages. As described herein, an MTA may be a network element (e.g., a mail server) in the EMDS 102 configured to receive email messages from various sources and forward the email messages to the appropriate end user or destination. At each MTA, email messages received by the MTA for processing are queued in the MTA's message queue. Typically, new email messages are added to the end or tail of the message queue, and email messages are retrieved from the beginning or head of the queue for processing by the MTA. In certain embodiments, the MTA may include a queue manager responsible for performing tasks related to managing the MTA message queues, including performing tasks such as adding messages to queues and selecting messages from queues for processing. The MTA message queues may contain email messages from multiple different senders, and the email messages may be destined for different recipients.

[0029] Figure 2 is an exemplary diagram of the contents of message queues within the MTAs shown in Figure 1, according to certain embodiments. The embodiment shown in Figure 2 illustrates the contents of message queue 113A of MTA 110A. Message queue 113A can store email messages from multiple senders and multiple email messages from the same sender. By way of example, message queue 113A may store email messages from multiple senders (M1, S1), (M2, S2), (M3, S3), (M4, S4), (M5, S1), (M6, S5), (M7, S5), and the email messages may be directed to different recipients.

[0030] Returning to the description of FIG. 1, in certain implementations, each MTA (e.g., 110A, 110B, or 110C) may include a message transmission agent (MSA) (not shown in FIG. 1), which may be a computer program or software agent implemented within the MTA that receives email from mail user agents (MUAs) on users' devices and cooperates with the mail transfer agent (MTA) to deliver the email to a set of recipients. The MTA may perform additional tasks. These tasks include, but are not limited to, monitoring the flow of outgoing email, delivering outgoing email, queuing, throttling, scheduling email messages, connection management, and tracking email delivery status.

[0031] Load balancer 108 can use various techniques to select an MTA from the set of MTAs 110A, 110B, and 110C to process email messages. For example, in one technique, load balancer 108 can use a round-robin scheduling process to select an MTA to efficiently distribute the processing of email messages across each MTA in the set of MTAs. For example, using round-robin scheduling, load balancer 108 may select a first MTA (e.g., 110A) in the set of MTAs to process and deliver a first batch (e.g., the first 1000) of messages received from a source to a set of recipients, a second batch (e.g., the second 1000) of messages received from a source to a set of recipients, and a third MTA (e.g., 110B) to process and deliver a second batch (e.g., the second 1000) of messages received from a source to a set of recipients. A second MTA (e.g., 110B) and a third MTA (e.g., 110C) within the set of MTAs may be selected to process a third batch (e.g., a third 1000) of messages received from the source and deliver them to the set of recipients.

[0032] A selected MTA (e.g., 110A) receives email messages and adds them to its message queue 113A for further processing. Once a certain number of messages (e.g., a batch of email messages) have been received and stored in the message queue 113A, the MTA begins processing the messages stored in its message queue 113A. The MTA periodically attempts to send all messages stored in the message queue to the end user (recipient) or destination until the message queue is empty. If the recipient's server does not respond, the MTA repeatedly attempts to send the email message to the recipient. If the email message fails to be delivered for a certain period of time (e.g., a certain number of days), the MTA returns the email message to the host (the message sender).

[0033] In particular embodiments, processing an email message by an MTA may include the MTA selecting an email message for processing from its message queue, and the MTA determining a sender and intended recipient associated with the first email message. The MTA then identifies a pool of source IP addresses that can be used as the source IP address of the email message based on the sender, and selects a specific source IP address from the pool of source IP addresses. The MTA then identifies a specific proxy server from the set of proxy servers 112A-112C that is configured to handle the selected specific source IP address, and communicates information including the specific source IP address and destination IP address to the specific proxy server. The MTA then sends the email message to the destination IP address using the connection established by the proxy server between the specific source IP address and the destination IP address.

[0034] In certain implementations, a pool of source IP addresses assigned to a sender can be distributed across a set of proxy servers. One or more IP addresses from the pool can be assigned to a first proxy server in the set of proxy servers, and a different set of IP addresses from the pool can be assigned to a second proxy server in the set of proxy servers. In certain examples, each proxy server in the set of proxy servers can be bound to a set of one or more source IP addresses, and a particular source IP address in the set of one or more source IP addresses can be associated with a particular sender. For example, in the embodiment shown in FIG. 1, the first proxy server 112A can be bound to a set of source IP addresses, and a first source IP address in the set can be associated with a first sender, and a second source IP address in the set can be associated with a second sender, which may be different from the second sender. In certain examples, the assignment of IP addresses associated with a sender to different proxy servers can be performed by an administrator of the EMDS when the sender subscribes to services provided by the EMDS. Details regarding the processing performed by the MTA and proxy servers to process and deliver email messages to a set of one or more recipients are described below with respect to the flowcharts shown in Figures 2 and 3 and the accompanying description.

[0035] The computing environment 100 further comprises one or more relay MTAs 114 and recipient systems 118. The relay MTAs 114 and recipient systems 118 may be communicatively connected to the EMDS 102 via one or more communication networks 106 (e.g., the Internet). In certain examples, an email message may be relayed by a source MTA (e.g., 110A) to another MTA (referred to herein as a "source MTA") before being delivered to the intended recipient. The relay MTA 114 may relay, or forward, the email message to a different MTA (also called a relay MTA, but which may not be implemented within the EMDS). When the relay MTA 114 receives an email message, it prepends a receipt trace header field to the message's headers, thereby building a continuous record of the MTAs handling the message. The selection of the relay MTA for the next hop (route) may be determined as part of the configuration of the MTAs for processing email messages by an administrator of the EMDS 102. Upon receiving the message, the relay MTA 114 may deliver the message to a user on its system or pass the message to another relay MTA identified in the route. Eventually, the message arrives at the MTA that is its final destination. If the message is addressed to a user on the system, the MTA passes it to the recipient system 118 for final delivery. The recipient system 118 may represent the email service (inbox) provider of the recipient of the email message (e.g., Gmail®, Yahoo®, Microsoft®, etc.). The recipient system 118 may store the message in the message store 116 until the intended recipient is ready to retrieve it. The recipient can contact the recipient system 118 using an MUA on the recipient's device to retrieve the message from the message store. If the recipient system successfully authenticates the requester, it forwards the user's message to the user's MUA. In a particular example, the recipient may be an end user who receives legitimate solicited commercial email messages (e.g., email messages containing advertising, sales content, etc.) from various sources 104A-104N.

[0036] FIG. 3 illustrates an example process 300 performed by an MTA in cooperation with a proxy server to process email messages received by the EMDS and delivered to intended recipients, according to certain embodiments. The process illustrated in FIG. 3 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores), hardware, or a combination thereof, of the respective systems. The software may be stored in a non-transitory storage medium (e.g., a memory device). The process 300 illustrated in FIG. 3 and described below is exemplary and not limiting. While FIG. 3 illustrates various processing steps occurring in a particular order or sequence, this is not intended to be limiting. In certain alternative embodiments, steps may be performed in some different order, or some steps may be performed in parallel. In certain embodiments, such as the embodiment illustrated in FIG. 1, the process illustrated in FIG. 3 may be performed by components of the EMDS 102, such as an MTA (e.g., MTA 110A) and a proxy (e.g., proxy 112A).

[0037] The process shown in Figure 3 assumes that the EMDS has received a set of email messages to be delivered to intended recipients. The email messages may be received from one or more different customers (i.e., senders) or subscribers of the email delivery services provided by the EMDS. The received email messages are forwarded to one or more MTAs in the EMDS for processing. At each MTA, the email messages received by the MTA for processing are queued in the MTA's message queue. As previously mentioned, the MTA message queue may contain email messages from multiple different senders, and the email messages may be destined for different recipients.

[0038] For example, in the embodiment shown in Figure 1, EMDS 102 can receive email messages from multiple senders. Within EMDS 102, load balancer 108 can be used to distribute email messages to different MTAs 110A, 110B, and 110C, and email messages can be queued in message queues of the individual MTAs. For example, in Figure 1, email messages received by MTA 110A for processing are queued in message queue 113A of MTA 110A. It can be done.

[0039] The process shown in Figure 3 may begin when an email message is selected from the head of a message queue for processing by an MTA at block 302. For example, in Figure 1, MTA 110A may select the email message at the head of message queue 113A for processing.

[0040] At block 304, for the email message selected at 302, the MTA determines the sender and intended recipient of the selected email message. For example, in Figure 1, MTA 110A may determine the sender and intended recipient of the email message selected for processing from message queue 113A.

[0041] Each email message contains multiple fields, such as a "From" field that identifies a user associated with the sender of the email message, a "To" field that identifies the intended recipient of the email message, and a "Body" field that contains the content of the email. As part of processing 304, the MTA may parse the selected email message to determine the user of the email message from the "From" field of the email message and the intended recipient of the email message from the "To" field. In certain implementations, the MTA may parse a string in the "From" field to determine users associated with the sender who are authorized to send the email message. For example, the "From" field may contain a string in the format "user1@abccompany.com," where "user1" may identify a user associated with the sender of the email message. The portion of the string after the "@" symbol identifies a domain name or fully qualified domain name associated with the sender. The MTA may identify the sender of the email message based on the domain name. In the example of user1@abcompany.com, the sender may be identified as ABC Company.

[0042] In particular examples, after determining the sender of an email message, the MTA can begin an authorization process based on prior authentication to determine a list of all possible From addresses that the sender is authorized to use. The MTA then checks messages from the sender to ensure that an authorized From address is used. In particular embodiments, a check may also be performed to verify that the sender is authorized to send email messages to the domain corresponding to the "To" field of the email message.

[0043] In block 306, based on the message sender selected in 304, the MTA identifies a pool of source IP addresses, which pool includes IP addresses that can be used as source IP addresses for email messages. In certain examples, the pool of source IP addresses for the sender and the users associated with the sender may be pre-assigned by the EMDS. For example, this may be done when the sender subscribes to the email delivery service and provides a list of authorized users to the EMDS.

[0044] In certain implementations, a sender may identify a particular pool of source IP addresses. For example, in Figure 1, MTA 110A may identify a pool of source IP addresses based on the sender determined for the email message in 304. In other embodiments, the sender determined for the email message may be used to identify the pool of source IP addresses. In certain implementations, the pool of source IP addresses may be shared among senders.

[0045] In block 308, the MTA selects a source IP address from the pool of source IP addresses identified in block 306 for sending the email message selected in block 302. The MTA selects a specific source IP address to be used as the source IP address. The MTA can select a specific source IP address from the pool of source IP addresses using various selection techniques. In a particular implementation, the MTA may first determine a set of active IP addresses from the pool of IP addresses. If an IP address has not expired and is still functional, it is considered active. Active IP addresses represent source IP addresses that can continue to be used to send email. For example, an IP address in the pool of IP addresses determined in 306 may not be active or available because the source IP address exceeds the connection rate limit for a particular recipient of the email message, the proxy server serving that IP address has been marked as failed or inactive, delivery of email messages using that IP address has previously failed, etc. As part of processing 308, the MTA may filter out inactive addresses from the pool of addresses determined in 306.

[0046] After the active set of IP addresses is identified, the MTA may use a selection technique to select a single source IP address from the set of active addresses. In particular implementations, the selection technique may include randomly selecting an IP address from the set of active IP addresses. In some other embodiments, a round-robin selection technique or a least recently used technique may be used to select a single IP address from the set of active addresses. In still other implementations, the single address may be selected based on a reputation associated with the set of active addresses. For example, the IP address with the highest reputation may be selected. For example, in the embodiment shown in FIG. 1, MTA 110A may identify a set of active source IP addresses and then select a single source IP address from that set using, for example, a round-robin selection scheme (or some other selection technique).

[0047] At block 310, the MTA identifies a proxy server that is pre-configured to handle the source IP address selected at block 308. In a typical scenario, the proxy server may be selected from among multiple proxy servers based on the source IP address. In a particular implementation, the proxy server may be implemented as a TCP proxy server that acts as an intermediary network entity between the source entity, e.g., the source MTA, and a connection endpoint that facilitates delivery of the email message to the intended recipient.

[0048] In certain implementations, the source IP addresses managed by the EMDS for various senders may be pre-specified or pre-assigned to a set of MTAs. For example, in FIG. 1, the source IP addresses handled by the EMDS 102 may be allocated among proxy servers 112A, 112B, and 112C. To increase the scalability and fault tolerance of the system, the pool of source IP addresses for a particular sender may be distributed among multiple proxy servers. In certain implementations, the IP addresses in the pool of source IP addresses for a particular sender may be divided into non-overlapping address ranges, and each range may be assigned to a separate proxy server, thereby distributing the addresses among multiple proxy servers. This distribution improves the fault tolerance of the EMDS system. If a proxy server serving a particular sender's IP address goes down, one or more other proxy servers are still available to serve the sender and continue delivering email to that sender. From the perspective of a proxy server, the source IP addresses specified or assigned to that proxy server may be for only the sender or for multiple senders.

[0049] For example, in FIG. 1, as part of the process at 310, MTA 110A selects The MTA 110A may determine that the received source IP address is mapped to or assigned to proxy server-1 112A. In response, the MTA 110A may select 310 proxy server-1 112A. The selected proxy server may be running on the same computer machine that runs the MTA, or may be running on another computer system.

[0050] At 312, the MTA determines a destination IP address for the email message to be sent based on the intended recipient of the email message identified at 304. The destination IP address determined at 312 corresponds to the IP address of a network endpoint to which the email message is to be sent to facilitate communication of the email message to the intended recipient. For example, as described above, the intended recipient of the email message may be identified in a "To" field of the email message. For example, the "To" field may include a string of the form "recipient@xyz.com," where "recipient" identifies a username and "xyz.com" identifies a domain name. The domain name "xyz.com" itself includes a first portion, "xyz," that identifies an organization and a second portion, ".com," that identifies a top-level domain (TLD) (a TLD can be .com, .org, .edu, .net, .gov, etc.). As part of the processing at 312, the MTA may determine a destination IP address to which the email message should be sent based on the username and domain of the intended recipient of the email message. For example, the MTA may resolve the domain name to determine the fully qualified domain name of a mail exchange server in the Domain Name System (DNS). The domain's DNS server responds with any mail exchange (MX) records that list the mail exchange server for that domain (e.g., a relay MTA (e.g., 114) run by the recipient's ISP). In 312, the IP address of that relay MTA is determined as the destination IP address.

[0051] In block 314, the MTA connects to the proxy server and then sends a connection request to the proxy server identified in 310, where the connection request includes the source IP address selected in 308 and the destination IP address determined in 312. The connection request may also include instructions requesting the proxy server to set up a connection between the source IP address and the destination IP address.

[0052] The proxy server receives the connection request from the MTA in block 316. For example, in Figure 1, proxy server-1 112A may receive the connection request from MTA 110A.

[0053] In block 318, the proxy server establishes a connection between the source IP address received in the connection request and the destination IP address received in the connection request. For example, in Figure 1, proxy server-1 112A may determine the source IP address and destination IP address received in the connection request and establish a connection between the source IP address and the destination IP address.

[0054] At 320, the proxy server may send status information about the connection established at 318 to the MTA that received the connection request. For example, in FIG. 1, proxy server-1 112A may send status information to MTA 110A. The status may indicate success or failure of the connection setup. In case of failure, the MTA and proxy server may perform some error correction procedures.

[0055] In block 322, the MTA sends the email message selected in 302 using the connection established by the proxy server in 318. The source IP address of the email becomes the source of the email, and the email is sent to the destination IP address. The email is sent, and the destination IP address is that of an endpoint (e.g., a relay MTA) that facilitates communication of the email message to the intended recipient. For example, in FIG. 1, MTA 110A can send a selected email message to relay MTA 114 via a connection established by proxy server-1 112A. In a particular implementation, the email message can be sent using Simple Mail Transfer Protocol (SMTP). A relay MTA that receives an email message on a remote system operating outside the control of EMDS can forward the message to a message store associated with the intended recipient (e.g., message store 116 in FIG. 1) or may forward it to another intermediate network entity, such as another relay MTA. In this manner, the email message is communicated via one or more relay MTAs to the intended recipient's message store. The message store may be, for example, an inbox associated with the intended recipient of the email message.

[0056] In certain embodiments, at 322, the MTA may send multiple email messages over the connection established by the proxy server. These email messages may include, for example, email messages from the same sender addressed to the same recipient. In some other embodiments, these multiple email messages may include email messages from the same sender addressed to the same domain (e.g., "xyz.com"), possibly addressed to different recipients in that common domain. In certain embodiments, the MTA may examine the email messages in its message queue to determine whether the multiple email messages can be sent over the connection established by the proxy server. The MTA may identify and remove these multiple email messages from the message queue to form a job that includes the multiple email messages. The email messages in the job may be sent at 322 using the connection established by the proxy server at 318.

[0057] In certain examples, the number of messages that can be added to a job may be determined at least in part based on a message limit on the number of messages that can be sent to a recipient's domain over a single connection. The MTA then retrieves the messages from the queue in the order they were received in the queue and sends the multiple messages to the recipients using the connection established by the MTA's proxy server. After sending a certain number of messages over the connection, in certain embodiments, the MTA may disconnect from the proxy server, and the proxy server may disconnect from the remote system, at block 324.

[0058] In certain implementations, the MTA is also configured to handle error conditions in which the proxy server is unable to establish a connection between the source IP address and the destination IP address. According to one error handling technique, after a certain number of retries by the proxy server to establish the connection, the proxy server can return an error code to the MTA in block 318 indicating that the connection could not be established. The MTA can then select a different source IP address for the email message and request the proxy server to establish a connection between the new source IP address and the destination IP address corresponding to the recipient.

[0059] In still other situations, after the MTA sends the email message at 322, the MTA may receive an error code indicating that the email message could not be delivered to the intended recipient. This could be because there is a reputation problem associated with the source IP address used to send the email message, causing the email message to be rejected by the recipient's email system, the source IP address used to send the email message exceeds the connection rate limit of the particular recipient system (inbox provider), a proxy server connection at that source IP address is failing, the recipient is no longer able to receive email at that source IP, or other reasons related to destination IP address issues, network issues, etc. This may be due to network issues. Connection rate limits specify the maximum number of simultaneous connections that can be established to the recipient's system's mailbox provider using a source IP address. In such situations, EMDS may use various retry techniques. For example, according to one technique, a particular email message that could not be successfully sent is returned to a message queue or a retry queue. When an email message is selected from the queue for sending, a new source IP address is selected for the email message that is different from the previously selected source IP address. The email message is then sent using the new source IP address.

[0060] In certain embodiments, the MTA proxy server architecture described in this disclosure provides greater operational efficiency and efficient resource management. In certain implementations, both MTAs and proxy servers can share the same hardware resources. For example, one or more MTAs and one or more proxy servers may be hosted and executed by the same computer system. For example, in the embodiment shown in FIG. 1, MTA 110A and proxy server-1 112A are hosted and executed by the same computing system 120. Resources of computer system 120, such as memory resources, processing resources, and network resources, may be shared by MTA 110A and proxy server-1 112A. Similarly, MTA 110B and proxy server-2 112B are on the same computer system 122, and MTA 110C and proxy server-3 112C are on computer system 124. The configuration shown in FIG. 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. Other implementations are possible, for example, multiple proxy servers run by the same computer system, multiple MTAs run by the same computer system, or each MTA and proxy server is implemented on a separate computer system.

[0061] In embodiments disclosed herein, the message queue maintained by the MTA can contain email messages from different senders and addressed to different recipients. The MTA does not need to maintain separate message queues for different senders. Furthermore, messages intended for various recipients now pass through a single MTA message queue. Thus, the number of message queues the MTA needs to maintain is reduced to a single message queue. This simplifies recovery procedures in the event that an MTA goes down. If an MTA goes down or becomes inoperable, email messages in the in-memory MTA's message queue can be easily remounted on another MTA without regard to the particular email message or the sender of the email message.

[0062] The architecture embodiments described herein also simplify recovery when a proxy server goes down. First, proxy servers are simple, uncomplicated components (e.g., very few lines of code), reducing their failure rate. However, if a proxy server goes down, the MTA simply stops using that proxy server. The MTA may stop using the source IP addresses assigned to that proxy server. For example, as part of the processing of 308 in FIG. 3, the MTA may filter out source IP addresses assigned to the down proxy server or source IP addresses tagged by the MTA as non-functional or inoperable. The MTA may use and select source IP addresses assigned to other functional proxy servers to send email messages. When the proxy server comes back up or becomes operational again, the MTA may be restarted using the source IP addresses assigned to that proxy server.

[0063] Example architecture The term cloud services is generally used to refer to services that a cloud service provider (CSP) makes available to users or customers on demand (e.g., via a subscription model) using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premises servers and systems. Therefore, customers can use cloud services provided by the CSP without having to separately purchase hardware and software resources for the service. Cloud services are designed to give subscribing customers easy and scalable access to applications and computing resources without requiring the customer to invest in procuring the infrastructure used to deliver the service.

[0064] There are several cloud service providers offering different types of cloud services, which come in a variety of different types or models, including Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS).

[0065] A customer can subscribe to one or more cloud services offered by a CSP. A customer can be any entity, such as an individual, an organization, or a business. When a customer subscribes or registers for a service offered by a CSP, a tenant or account is created for the customer. The customer can then access one or more subscribed cloud resources associated with the account through this account.

[0066] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to deliver virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, cloud computing providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, and platform virtualization (e.g., hypervisor layer)). In some cases, IaaS providers can also offer various services (e.g., billing, monitoring, logging, load balancing, and clustering) that accompany these infrastructure components. Therefore, these services can be policy-driven, allowing IaaS users to implement policies that drive load balancing to maintain application availability and performance.

[0067] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet and use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log into an IaaS platform and create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions, such as balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0068] In most cases, cloud computing models require the participation of a cloud provider. A cloud provider can be, but does not have to be, a third-party service that specializes in providing (e.g., providing, renting, or selling) IaaS. An entity can deploy a private cloud to provide its own infrastructure services provider. You can also choose to become a provider.

[0069] In some examples, IaaS deployment is the process of placing a new application, or a new version of an application, onto a prepared application server, etc. This can also include the process of preparing the server (e.g., installing libraries, daemons, etc.), which is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer can be responsible for handling things like (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand)).

[0070] In some cases, IaaS provisioning may even refer to obtaining computers or virtual hosts for use and installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0071] In some cases, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning an initial set of infrastructure before anything can run. Second, there's the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the various components described in the configuration files.

[0072] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potentially on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) that are provisioned to define how the network's inbound and / or outbound traffic is configured. Other infrastructure elements, such as load balancers, databases, etc., may also be provisioned. The infrastructure may evolve in stages as more infrastructure elements are desired or added.

[0073] In some cases, continuous deployment techniques may be used to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques enable infrastructure management within these environments. In some examples, a service team may write code that is desirably deployed to one or more, but often many, different production environments (e.g., across various different geographic locations, possibly spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning can be done manually, utilizing provisioning tools to provision resources and / or deployment tools to deploy the code after the infrastructure has been provisioned.

[0074] 4 is a block diagram 400 illustrating an example IaaS architecture pattern, according to at least one embodiment. A service operator 402 can be communicatively coupled to a secure host tenant 404, which can include a virtual cloud network (VCN) 406 and a secure host subnet 408. In some examples, the service operator 402 can use one or more client computing devices, which can be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, PalmOS, and other enabled communication protocols. Alternatively, the client computing devices can be general-purpose personal computers, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing device may be a workstation computer running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network with access to VCN 406 and / or the Internet.

[0075] VCN 406 may include a local peering gateway (LPG) 410 that may be communicatively coupled to a secure shell (SSH) VCN 412 via an LPG 410 included in SSH VCN 412. SSH VCN 412 may include an SSH subnet 414, which may be communicatively coupled to a control plane VCN 416 via an LPG 410 included in control plane VCN 416. SSH VCN 412 may also be communicatively coupled to a data plane VCN 418 via LPG 410. Control plane VCN 416 and data plane VCN 418 may be included in a service tenant 419, which may be owned and / or operated by the IaaS provider.

[0076] The control plane VCN 416 may include a control plane demilitarized zone (DMZ) tier 420 that serves as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers have limited responsibility and may help prevent breaches. Additionally, the DMZ tier 420 may include one or more load balancer (LB) subnets 422, a control plane app tier 424 that may include app subnets 426, and a control plane data tier 428, which may include database (DB) subnets 430 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 422 included in the control plane DMZ tier 420 may be communicatively coupled to the app subnet 426 included in the control plane app tier 424 and an Internet gateway 434 that may be included in the control plane VCN 416, and the app subnet 426 may be communicatively coupled to the control plane data tier 428. The control plane VCN 416 may be communicatively coupled to a DB subnet 430 included in the data layer 428, as well as to a service gateway 436 and a network address translation (NAT) gateway 438. The control plane VCN 416 may include the service gateway 436 and the NAT gateway 438.

[0077] The control plane VCN 416 can include a data plane mirror app layer 440, which can include an app subnet 426. The app subnet 426 included in the data plane mirror app layer 440 can include a virtual network interface controller (VNIC) 442 on which a compute instance 444 can run. The compute instance 444 can communicatively couple the app subnet 426 of the data plane mirror app layer 440 to the app subnet 426, which can be included in the data plane app layer 446.

[0078] Data plane VCN 418 may include a data plane app layer 446, a data plane DMZ layer 448, and a data plane data layer 450. Data plane DMZ layer 448 may include a LB subnet 422, which may be communicatively coupled to an app subnet 426 of data plane app layer 446 and an internet gateway 434 of data plane VCN 418. App subnet 426 may be communicatively coupled to a service gateway 436 of data plane VCN 418 and a NAT gateway 438 of data plane VCN 418. Data plane data layer 450 may also include a DB subnet 430, which may be communicatively coupled to app subnet 426 of data plane app layer 446.

[0079] The internet gateways 434 of the control plane VCNs 416 and data plane VCNs 418 may be communicatively coupled to a metadata management service 452, which may be communicatively coupled to the public internet 454. The public internet 454 may be communicatively connected to the NAT gateways 438 of the control plane VCNs 416 and data plane VCNs 418. The service gateways 436 of the control plane VCNs 416 and data plane VCNs 418 may be communicatively coupled to cloud services 456.

[0080] In some examples, a service gateway 436 in a control plane VCN 416 or a data plane VCN 418 can make application programming interface (API) calls to a cloud service 456 without traversing the public internet 454. An API call from a service gateway 436 to a cloud service 456 can be one-way: the service gateway 436 can make an API call to the cloud service 456, and the cloud service 456 can send the requested data to the service gateway 436. However, the cloud service 456 may not be able to initiate the API call to the service gateway 436.

[0081] In some examples, secure host tenant 404 can be directly connected to service tenant 419 or can be otherwise separate. Secure host subnet 408 can communicate with SSH subnet 414 through LPG 410, which can enable bidirectional communication through otherwise separate systems. Connecting secure host subnet 408 to SSH subnet 414 can give secure host subnet 408 access to other entities within service tenant 419.

[0082] The control plane VCN 416 may enable users of service tenants 419 to set up or provision desired resources. Desired resources provisioned in CN 416 may be deployed or used in data plane VCN 418. In some examples, control plane VCN 416 may be separate from data plane VCN 418, and data plane mirror app layer 440 of control plane VCN 416 may communicate with data plane app layer 446 of data plane VCN 418 via VNIC 442, which may be included in data plane mirror app layer 440 and data plane app layer 446.

[0083] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, over the public internet 454, which may communicate the request to a metadata management service 452. The metadata management service 452 may communicate the request to the control plane VCN 416 via an internet gateway 434. The request may be received by a LB subnet 422 included in the control plane DMZ layer 420. The LB subnet 422 may determine that the request is valid, and in response to this determination, the LB subnet 422 may send the request to an app subnet 426 included in the control plane app layer 424. If the request is validated and a call to the public internet 454 is required, the call to the public internet 454 may be sent to a NAT gateway 438, which may make the call to the public internet 454. Memory that may be desirable to store with the request may be stored in the DB subnet 430.

[0084] In some examples, data plane mirror app layer 440 can facilitate direct communication between control plane VCN 416 and data plane VCN 418. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources included in data plane VCN 418. Via VNIC 442, control plane VCN 416 can communicate directly with resources included in data plane VCN 418, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to resources included in data plane VCN 418.

[0085] In some embodiments, control plane VCN 416 and data plane VCN 418 can be included in service tenant 419. In this case, a user or customer of the system cannot own or operate either control plane VCN 416 or data plane VCN 418. Instead, an IaaS provider can own or operate control plane VCN 416 and data plane VCN 418, which can both be included in service tenant 419. This embodiment can enable network isolation that can prevent users or customers from interacting with the resources of other users or other customers. This embodiment also allows users or customers of the system to store databases privately without having to rely on the public internet 454 for storage, which may not have the desired level of threat protection.

[0086] In another embodiment, LB subnet 422 included in control plane VCN 416 may be configured to receive signals from service gateway 436. In this embodiment, control plane VCN 416 and data plane VCN 418 may be configured to be called by customers of the IaaS provider without calling the public internet 454. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored in service tenant 419, which may be controlled by the IaaS provider and isolated from the public internet 454.

[0087] FIG. 5 is a block diagram 500 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 502 (e.g., service operator 402 of FIG. 4) provides a secure host tenant 504 (e.g., secure host tenant 504 of FIG. 4). 4 ) and a secure host subnet 508 (e.g., secure host subnet 408 in FIG. 4 ). VCN 506 may include a local peering gateway (LPG) 510 (e.g., LPG 410 in FIG. 4 ), which may be communicatively coupled to a secure shell (SSH) VCN 512 (e.g., SSH VCN 412 in FIG. 4 ) via LPG 410 included in SSH VCN 512. SSH VCN 512 may include SSH subnet 514 (e.g., SSH subnet 414 in FIG. 4 ), which may be communicatively coupled to a control plane VCN 516 (e.g., control plane VCN 416 in FIG. 4 ) via LPG 510 included in control plane VCN 516. The control plane VCN 516 may be included in a service tenant 519 (e.g., service tenant 419 in FIG. 4), and the data plane VCN 518 (e.g., data plane VCN 418 in FIG. 4) may be included in a customer tenant 521, which may be owned or operated by a user or customer of the system.

[0088] The control plane VCN 516 may include a control plane DMZ layer 520 (e.g., control plane DMZ layer 420 of FIG. 4) that may include a LB subnet 522 (e.g., LB subnet 422 of FIG. 4), a control plane app layer 524 (e.g., control plane app layer 424 of FIG. 4) that may include an app subnet 526 (e.g., app subnet 426 of FIG. 4), and a control plane data layer 528 (e.g., control plane data layer 428 of FIG. 4) that may include a database (DB) subnet 530 (e.g., similar to DB subnet 430 of FIG. 4). The LB subnet 522 included in the control plane DMZ layer 520 can be communicatively coupled to an app subnet 526 included in the control plane app layer 524 and to an Internet gateway 534 (e.g., Internet gateway 434 in FIG. 4 ) that may be included in the control plane VCN 516, and the app subnet 526 can be communicatively coupled to a DB subnet 530 included in the control plane data layer 528, as well as to a service gateway 536 (e.g., service gateway in FIG. 4 ) and a network address translation (NAT) gateway 538 (e.g., NAT gateway 438 in FIG. 4 ). The control plane VCN 516 can include the service gateway 536 and the NAT gateway 538.

[0089] The control plane VCN 516 can include a data plane mirror app layer 540 (e.g., data plane mirror app layer 440 of FIG. 4 ), which can include an app subnet 526. The app subnet 526 included in the data plane mirror app layer 540 can include a virtual network interface controller (VNIC) 542 (e.g., VNIC 442) on which a computing instance 544 (e.g., similar to computing instance 444 of FIG. 4 ) can run. The computing instance 544 can facilitate communication between the app subnet 526 and the app subnet 526 of the data plane mirror app layer 540, which can be included in the data plane app layer 546 (e.g., data plane app layer 446 of FIG. 4 ), via the VNIC 542 included in the data plane mirror app layer 540 and the VNIC 542 included in the data plane app layer 546.

[0090] An internet gateway 534 included in the control plane VCN 516 can be communicatively coupled to a metadata management service 552 (e.g., metadata management service 452 in FIG. 4), which can be communicatively coupled to the public internet 554 (e.g., public internet 454 in FIG. 4). The public internet 554 can be communicatively coupled to a NAT gateway 538 included in the control plane VCN 516. A service gateway 536 included in the control plane VCN 516 can be communicatively coupled to a cloud service 556 (e.g., cloud service 456 in FIG. 4). can be combined with

[0091] In some examples, the data plane VCN 518 can be included in a customer tenant 521. In this case, the IaaS provider can provide a control plane VCN 516 for each customer, and the IaaS provider can set up a unique compute instance 544 for each customer that is included in the service tenant 519. Each compute instance 544 may enable communication between the control plane VCN 516 included in the service tenant 519 and the data plane VCN 518 included in the customer tenant 521. The compute instance 544 may enable resources provisioned in the control plane VCN 516 included in the service tenant 519 to be deployed or otherwise used in the data plane VCN 518 included in the customer tenant 521.

[0092] In another example, a customer of the IaaS provider may have a database that resides in customer tenant 521. In this example, control plane VCN 516 may include data plane mirror app tier 540, which may include app subnet 526. Data plane mirror app tier 540 may reside in data plane VCN 518, but data plane mirror app tier 540 need not reside in data plane VCN 518. That is, data plane mirror app tier 540 is accessible to customer tenant 521, but data plane mirror app tier 540 may not reside in data plane VCN 518 or may be owned or operated by the IaaS provider's customer. Data plane mirror app tier 540 may be configured to make calls to data plane VCN 518, but may not be configured to make calls to any entities included in control plane VCN 516. A customer may desire to deploy or otherwise use resources in data plane VCN 518 that are provisioned in control plane VCN 516, and data plane mirror app tier 540 can facilitate the customer's desired deployment or other use of the resources.

[0093] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 518. In this embodiment, the customer can determine what the data plane VCN 518 can access, and the customer can restrict access from the data plane VCN 518 to the public internet 554. The IaaS provider may not be able to apply filters or control the data plane VCN 518's access to external networks or databases. Applying customer filters and controls to the data plane VCN 518 contained in the customer tenant 521 can help isolate the data plane VCN 518 from other customers and the public internet 554.

[0094] In some embodiments, cloud services 556 can be called by service gateway 536 to access services that may not reside on the public internet 554, on control plane VCN 516, or on data plane VCN 518. The connection between cloud services 556 and control plane VCN 516 or data plane VCN 518 may not be live or continuous. Cloud services 556 may reside on a separate network owned or operated by the IaaS provider. Cloud services 556 may be configured to receive calls from service gateway 536 or may not be configured to receive calls from the public internet 554. Some cloud services 556 may be isolated from other cloud services 556, and control plane VCN 516 may be isolated from cloud services 556 that may not be in the same region as control plane VCN 516. For example, control plane VCN 516 may be located in "Region 1," and cloud service "Deployment 4" may be located in Region 1. Deployment 4 may be located in "Region 2." If a call to Deployment 4 is made by service gateway 536 included in control plane VCN 516 in Region 1, the call may be sent to Deployment 4 in Region 1. In this example, control plane VCN 516, or Deployment 4 in Region 1, may not be communicatively coupled to or in communication with Deployment 4 in Region 2.

[0095] 6 is a block diagram 600 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 602 (e.g., service operator 402 in FIG. 4 ) can be communicatively coupled to a secure host tenant 604 (e.g., secure host tenant 404 in FIG. 4 ), which can include a virtual cloud network (VCN) 606 (e.g., VCN 406 in FIG. 4 ) and a secure host subnet 608 (e.g., secure host subnet 408 in FIG. 4 ). VCN 606 can include an LPG 610 (e.g., LPG 410 in FIG. 4 ) that can be communicatively coupled to an SSH VCN 612 via an LPG 610 included in SSH VCN 612 (e.g., SSH VCN 412 in FIG. 4 ). SSH VCN 612 can include an SSH subnet 614 (e.g., SSH subnet 414 in FIG. 4 ), and SSH VCN 612 can be communicatively coupled to a control plane VCN 616 via an LPG 610 included in the control plane VCN 616 (e.g., control plane VCN 416 in FIG. 4 ), and can be communicatively coupled to a data plane VCN 618 via an LPG 610 included in the data plane VCN 618 (e.g., data plane 418 in FIG. 4 ). The control plane VCN 616 and the data plane VCN 618 can be included in a service tenant 619 (e.g., service tenant 419 in FIG. 4 ).

[0096] The control plane VCN 616 may include a control plane DMZ layer 620 (e.g., control plane DMZ layer 420 of FIG. 4 ) that may include a load balancer (LB) subnet 622 (e.g., LB subnet 422 of FIG. 4 ), a control plane app layer 624 (e.g., control plane app layer 424 of FIG. 4 ) that may include an app subnet 626 (e.g., similar to app subnet 426 of FIG. 4 ), and a control plane data layer 628 (e.g., control plane data layer 428 of FIG. 4 ) that may include a DB subnet 630. The LB subnet 622 included in the control plane DMZ layer 620 may be communicatively coupled to an app subnet 626 included in the control plane app layer 624 and to an Internet gateway 634 (e.g., Internet gateway 434 in FIG. 4 ) that may be included in the control plane VCN 616, and the app subnet 626 can be communicatively coupled to a DB subnet 630, a service gateway 636 (e.g., service gateway in FIG. 4 ), and a network address translation (NAT) gateway 638 (e.g., NAT gateway 438 in FIG. 4 ) included in the control plane data layer 628. The control plane VCN 616 may include the service gateway 636 and the NAT gateway 638.

[0097] The data plane VCN 618 may include a data plane app layer 646 (e.g., data plane app layer 446 in FIG. 4 ), a data plane DMZ layer 648 (e.g., data plane DMZ layer 448 in FIG. 4 ), and a data plane data layer 650 (e.g., data plane data layer 450 in FIG. 4 ). The data plane DMZ layer 648 may include a LB subnet 622, which may be communicatively coupled to a trusted app subnet 660 and an untrusted app subnet 662 of the data plane app layer 646 and to an Internet gateway 634 included in the data plane VCN 618. The trusted app subnet 660 may be communicatively coupled to a service gateway 636 included in the data plane VCN 618, a NAT gateway 638 included in the data plane VCN 618, and a DB subnet 630 included in the data plane data layer 650. The untrusted app subnet 662 may be communicatively coupled to a service gateway 636 included in the data plane VCN 618, a NAT gateway 638 included in the data plane VCN 618, and a DB subnet 630 included in the data plane data layer 650. The data plane data layer 650 may include a DB subnet 630 that may be communicatively coupled to a service gateway 636 included in the data plane VCN 618 and a DB subnet 630 included in the data plane data layer 650. The data plane data layer 650 may include a DB subnet 630 that may be communicatively coupled to a service gateway 636 included in the data plane VCN 618.

[0098] The untrusted app subnet 662 may include one or more primary VNICs 664(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 666(1)-(N). Each tenant VM 666(1)-(N) may be communicatively coupled to a respective app subnet 667(1)-(N), which may be included in a respective container egress VCN 668(1)-(N), which may be included in a respective customer tenant 670(1)-(N). Each secondary VNIC 672(1)-(N) may facilitate communication between the untrusted app subnet 662 included in the data plane VCN 618 and the app subnet included in the container egress VCN 668(1)-(N). Each container egress VCN 668(1)-(N) may include a NAT gateway 638 that can be communicatively coupled to the public internet 654 (e.g., public internet 454 in FIG. 4 ).

[0099] An internet gateway 634 included in the control plane VCN 616 and in the data plane VCN 618 can be communicatively coupled to a metadata management service 652 (e.g., metadata management system 452 of FIG. 4 ), which can be communicatively coupled to the public internet 654. The public internet 654 can be communicatively coupled to a NAT gateway 638 included in the control plane VCN 616 and in the data plane VCN 618. A service gateway 636 included in the control plane VCN 616 and in the data plane VCN 618 can be communicatively coupled to cloud services 656.

[0100] In some embodiments, data plane VCN 618 can be integrated with customer tenants 670. This integration may be useful or desirable for an IaaS provider's customers, such as when support is needed during code execution. A customer may provide code to run that may be destructive, communicate with other customer resources, or cause other undesirable effects. Accordingly, the IaaS provider can decide whether to run code provided to the IaaS provider by the customer.

[0101] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be added to the data plane layer app 646. The code that performs the functionality may run in VMs 666(1)-(N), and the code cannot be configured to run elsewhere on the data plane VCN 618. Each VM 666(1)-(N) may be connected to one customer tenant 670. Each container 671(1)-(N) contained in a VM 666(1)-(N) may be configured to run code. In this case, double isolation may exist (e.g., code execution in container 671(1)-(N) may be contained in at least one VM 666(1)-(N) contained in the untrusted app subnet 662), which may help prevent errant or unwanted code from damaging the IaaS provider's network or damaging another customer's network. Containers 671(1)-(N) may be communicatively coupled to customer tenants 670 and may be configured to send or receive data from customer tenants 670. Containers 671(1)-(N) may not be configured to send or receive data from any other entities in data plane VCN 618. When code execution is complete, the IaaS provider kills containers 671(1)-(N). or may be disposed of in any other way.

[0102] In some embodiments, trusted app subnet 660 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 660 may be communicatively coupled to DB subnet 630 and configured to perform CRUD operations within DB subnet 630. Untrusted app subnet 662 may be communicatively coupled to DB subnet 630, but in this embodiment, the untrusted app subnet may be configured to perform read operations on DB subnet 630. Containers 671(1)-(N) that may be included in each customer's VMs 666(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet 630.

[0103] In other embodiments, the control plane VCN 616 and the data plane VCN 618 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 616 and the data plane VCN 618. However, communication can occur indirectly through at least one method. The LPG 610 may be established by an IaaS provider that can facilitate communication between the control plane VCN 616 and the data plane VCN 618. In another example, the control plane VCN 616 or the data plane VCN 618 can make a call to a cloud service 656 through a service gateway 636. For example, a call from the control plane VCN 616 to the cloud service 656 may include a request for a service that can communicate with the data plane VCN 618.

[0104] 7 is a block diagram 700 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 702 (e.g., service operator 402 of FIG. 4 ) can be communicatively coupled to a secure host tenant 704 (e.g., secure host tenant 404 of FIG. 4 ), which can include a virtual cloud network (VCN) 706 (e.g., VCN 406 of FIG. 4 ) and a secure host subnet 708 (e.g., secure host subnet 408 of FIG. 4 ). VCN 706 can include an LPG 710 (e.g., LPG 410 of FIG. 4 ) that can be communicatively coupled to an SSH VCN 712 (e.g., SSH VCN 412 of FIG. 4 ) via an LPG 710 included in the SSH VCN 712. SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 414 in FIG. 4 ), which can be communicatively coupled to a control plane VCN 716 via an LPG 710 included in the control plane VCN 716 (e.g., control plane VCN 416 in FIG. 4 ) and can be communicatively coupled to a data plane VCN 718 via an LPG 710 included in the data plane VCN 718 (e.g., data plane 418 in FIG. 4 ). The control plane VCN 716 and the data plane VCN 718 can be included in a service tenant 719 (e.g., service tenant 419 in FIG. 4 ).

[0105] The control plane VCN 716 may include a control plane DMZ layer 720 (e.g., control plane DMZ layer 420 in FIG. 4 ) that may include a LB subnet 722 (e.g., LB subnet 422 in FIG. 4 ), a control plane app layer 724 (e.g., control plane app layer 424 in FIG. 4 ) that may include an app subnet 726 (e.g., app subnet 426 in FIG. 4 ), and a control plane data layer 728 (e.g., control plane data layer 428 in FIG. 4 ) that may include a DB subnet 730 (e.g., DB subnet 630 in FIG. 6 ). The LB subnet 722 included in the control plane DMZ layer 720 may be communicatively coupled to the app subnet 726 included in the control plane app layer 724, and may be communicatively coupled to an Internet gateway 734 (e.g., Internet gateway 434 in FIG. 4 ), which may be included in the control plane VCN 716. In this case, the app subnet 726 can be communicatively coupled to a DB subnet 730 included in a control plane data layer 728, and can be communicatively coupled to a service gateway 736 (e.g., the service gateway in FIG. 4) and a network address translation (NAT) gateway 738 (e.g., the NAT gateway 438 in FIG. 4). The control plane VCN 716 can include the service gateway 736 and the NAT gateway 738.

[0106] The data plane VCN 718 may include a data plane app layer 746 (e.g., data plane app layer 446 in FIG. 4 ), a data plane DMZ layer 748 (e.g., data plane DMZ layer 448 in FIG. 4 ), and a data plane data layer 750 (e.g., data plane data layer 450 in FIG. 4 ). The data plane DMZ layer 748 may include a LB subnet 722, which may be communicatively coupled to a trusted app subnet 760 (e.g., trusted app subnet 660 in FIG. 6 ), and may be communicatively coupled to an untrusted app subnet 762 (e.g., untrusted app subnet 662 in FIG. 6 ) of the data plane app layer 746 and an Internet gateway 734 included in the data plane VCN 718. The trusted app subnet 760 may be communicatively coupled to a service gateway 736 included in the data plane VCN 718, and may be communicatively coupled to a NAT gateway 738 included in the data plane VCN 718 and a DB subnet 730 included in the data plane data layer 750. The untrusted app subnet 762 can be communicatively connected to a service gateway 736 included in the data plane VCN 718 and a DB subnet 730 included in the data plane data layer 750. The data plane data layer 750 can include a DB subnet 730 that can be communicatively coupled to a service gateway 736 included in the data plane VCN 718.

[0107] The untrusted app subnet 762 can include primary VNICs 764(1)-(N), which can be communicatively coupled to tenant virtual machines (VMs) 766(1)-(N) residing in the untrusted app subnet 762. Each tenant VM 766(1)-(N) can execute code within a respective container 767(1)-(N) and can be communicatively coupled to an app subnet 726, which can be included in a data plane app layer 746, which can be included in a container egress VCN 768. Each secondary VNIC 772(1)-(N) can facilitate communication between the untrusted app subnet 762, which is included in the data plane VCN 718, and the app subnet, which is included in the container egress VCN 768. The container egress VCN can include a NAT gateway 738, which can be communicatively coupled to the public internet 754 (e.g., public internet 454 in FIG. 4 ).

[0108] An internet gateway 734 included in the control plane VCN 716 and included in the data plane VCN 718 can be communicatively coupled to a metadata management service 752 (e.g., metadata management system 452 of FIG. 4 ), which can be communicatively coupled to the public internet 754. The public internet 754 can be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716 and included in the data plane VCN 718. A service gateway 736 included in the control plane VCN 716 and included in the data plane VCN 718 can be communicatively coupled to cloud services 756.

[0109] In some instances, the pattern illustrated by the architecture of block diagram 700 of FIG. 7 may be considered an exception to the pattern illustrated by the architecture of block diagram 600 of FIG. 6 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in disconnected areas). Each container 767(1)-(N) included in control plane VCN 716 can be accessed in real time by a customer. Containers 767(1)-(N) can be configured to make calls to a respective secondary VNIC 772(1)-(N) included in app subnet 726 of data plane app layer 746, which can be included in container egress VCN 768. Secondary VNICs 772(1)-(N) can send calls to NAT gateway 738, which can send the calls to public Internet 754. In this example, containers 767(1)-(N) that are accessible in real time by a customer can be isolated from control plane VCN 716 and can be isolated from other entities included in data plane VCN 718. Containers 767(1)-(N) can be isolated from resources from other customers.

[0110] In another example, a customer can invoke cloud service 756 using container 767(1)-(N). In this example, the customer can execute code within container 767(1)-(N) that requests a service from cloud service 756. Container 767(1)-(N) can send the request to secondary VNICs 772(1)-(N), which can send the request to a NAT gateway that can send the request to public internet 754. Public internet 754 can send the request to LB subnet 722, which is included in control plane VCN 716, via internet gateway 734. In response to determining that the request is valid, the LB subnet can send the request to app subnet 726, which can send the request to cloud service 756 via service gateway 736.

[0111] It should be understood that the IaaS architectures 400, 500, 600, 700 depicted in the figures may have components other than those shown. Additionally, the depicted embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In other embodiments, the IaaS system may have more or fewer components than depicted, may combine two or more components, or may have a different configuration or arrangement of components.

[0112] In certain embodiments, the IaaS system described herein may include a suite of application, middleware, and database service products that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0113] 8 illustrates an exemplary computer system 800 upon which various embodiments may be implemented. System 800 may be used to implement any of the computer systems described above. As shown, computer system 800 includes a processing unit 804 that communicates with a number of peripheral subsystems via a bus subsystem 802. These peripheral subsystems may include a processing accelerator 806, an I / O subsystem 808, a storage subsystem 818, and a communications subsystem 824. Storage subsystem 818 includes a tangible computer-readable storage medium 822 and a system memory 810.

[0114] Bus subsystem 802 provides a mechanism that allows the various components and subsystems of computer system 800 to communicate with each other as intended. Although bus subsystem 802 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 802 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Examples include: For example, such architectures may include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0115] Processing unit 804 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 800. One or more processors may be included in processing unit 804. These processors may include single-core processors or multi-core processors. In particular embodiments, processing unit 804 may be implemented as one or more independent processing units 832 and / or 834, with a single-core processor or a multi-core processor included in each processing unit. In other embodiments, processing unit 804 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0116] In various embodiments, processing unit 804 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any time, some or all of the program code being executed may reside in processor 804 and / or in memory subsystem 818. Through appropriate programming, processor 804 may provide the various functions described above. Computer system 800 may further include a processing accelerator 806, which may include a digital signal processor (DSP), a special purpose processor, or the like.

[0117] The I / O subsystem 808 can include user interface input devices and user interface output devices. User interface input devices can include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices can include, for example, motion sensing and / or gesture recognizers such as a Microsoft Kinect® motion sensor, allowing users to control and interact with input devices such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and voice commands. User interface input devices can also include eye gesture recognizers such as a Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" while taking a picture and / or selecting a menu) and translates the eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include voice recognition sensing devices that allow a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0118] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include, for example, computer The user interface input devices may include medical imaging input devices such as computed tomography, magnetic resonance imaging, positional emission tomography, medical ultrasound, etc. The user interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, etc.

[0119] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat-panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 800 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, voice output devices, and modems.

[0120] Computer system 800 may include a storage subsystem 818 that comprises software elements shown as currently located in system memory 810. System memory 810 may store program instructions that are loadable and executable on processing unit 804, as well as data generated during the execution of these programs.

[0121] Depending on the configuration and type of computer system 800, system memory 810 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 804. In some implementations, system memory 810 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, the basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 800, such as during start-up, may typically be stored in ROM. By way of example and not limitation, system memory 810 also illustrates application programs 812, program data 814, and operating system 816, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc. By way of example, operating system 816 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 8 OS, and Palm® OS operating systems.

[0122] The storage subsystem 818 may also provide a tangible computer-readable storage medium for storing the basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in the storage subsystem 818. These software modules or instructions may be executed by the processing unit 804. The storage subsystem 818 may also provide a repository for storing data used in accordance with the present disclosure. Chicken can also be provided.

[0123] Storage subsystem 800 may also include a computer-readable storage medium reader 820 that may further connect to computer-readable storage medium 822. Together, and optionally in combination with system memory 810, computer-readable storage medium 822 may comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0124] The computer-readable storage medium 822 containing the code or portions of code may include any suitable medium known or used in the art, including, but not limited to, storage and communication media such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or other tangible computer-readable medium. This may also include intangible computer-readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by computing system 800.

[0125] By way of example, the computer-readable storage medium 822 may include a hard disk drive that reads from or writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from or writes to a removable, non-volatile magnetic disk, and an optical disk drive that reads from or writes to a removable, non-volatile optical disk, such as a CD-ROM, DVD, or Blu-Ray® disk, or other optical media. The computer-readable storage medium 822 may include, but is not limited to, a Zip® drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, etc. The computer-readable storage medium 822 may also include a solid-state drive (SSD) based on non-volatile memory, such as a flash memory-based SSD, an enterprise flash drive, an SSD based on volatile memory, such as solid-state RAM, dynamic RAM, or static RAM, such as solid-state ROM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD that uses a combination of DRAM and a flash memory-based SSD. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 800.

[0126] The communications subsystem 824 provides an interface to other computer systems and networks. The communications subsystem 824 serves as an interface for transmitting data to and receiving data from the computer system 800 to other systems. For example, the communications subsystem 824 may enable the computer system 800 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 824 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution)), WiFi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), global mobile communications, or any combination thereof. It may include a GPS receiver component, and / or other components. In some embodiments, the communications subsystem 824 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0127] In some embodiments, the communications subsystem 824 may also receive incoming communications in the form of structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc., on behalf of one or more users who may use the computer system 800.

[0128] As an example, the communications subsystem 824 may be configured to receive data feeds 826 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0129] Additionally, the communications subsystem 824 may be configured to receive data in the form of a continuous data stream, which may include an event stream 828 of real-time events and / or event updates 830, which may be continuous or essentially unlimited with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0130] The communications subsystem 824 may also be configured to output structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 800.

[0131] The computer system 800 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

[0132] Due to the ever-changing nature of computers and networks, the description of computer system 800 shown in the figure is intended as a specific example only. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware may also be used, or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other approaches and / or methods for implementing various embodiments.

[0133] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are within the scope of the present disclosure. The embodiments are not limited to operation in any particular data processing environment, but may freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments can be used individually or in combination.

[0134] Furthermore, while embodiments have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform particular operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication; different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0135] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made without departing from the broader spirit and scope of the appended claims. Accordingly, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the following claims.

[0136] Use of the terms “a,” “an,” “the,” and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) should be construed to cover both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The terms “comprise,” “have,” “include,” and “contain” should be construed as open-ended terms (i.e., meaning “including, but not limited to”) unless otherwise noted. The term “connected” should be construed as partially or wholly contained within, attached to, or joined to, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each separate value falling within that range, unless otherwise stated herein, and each separate value is incorporated into the specification as if it were set forth individually herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended solely to better illustrate embodiments and do not impose limitations on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0137] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0138] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art will be able to adopt such variations as appropriate, and the present disclosure may be practiced in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, this disclosure includes any combination of the above-described elements in all possible variations thereof.

[0139] All references, including publications, patent applications, and patents, cited in this specification are herein incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0140] In the foregoing specification, aspects of the disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure can be used individually or in any combination. Moreover, embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. an email message delivery system providing email delivery services, running a message transfer agent (MTA) and a proxy server; the MTA selecting a first email message to process from a message queue, the message queue including a plurality of email messages received from a plurality of senders, the plurality of senders corresponding to a plurality of subscribers to the email delivery service; the MTA determining a sender associated with the first email message; the MTA determining a recipient of the first email message; the MTA identifying a plurality of source Internet Protocol (IP) addresses, including an IP address usable as a source IP address of the first email message, based on the determined sender of the first email message; the MTA selecting a specific source IP address from the plurality of source IP addresses; the MTA determining a destination IP address of the recipient of the email message; the MTA identifying, from a set of one or more proxy servers, a particular proxy server configured to handle the selected particular source IP address; the MTA communicating information including the specific source IP address and the destination IP address to the specific proxy server; the MTA sending the first email message to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.

2. 2. The method of claim 1, wherein the step of the MTA determining the sender of the first email message includes the step of the MTA determining a user associated with the sender of the first email message who is authorized to send the first email message, the user associated with the sender being determined based at least in part on a "From" field of the first email message.

3. The method of claim 1 , wherein the recipient of the first email message is determined based at least in part on a “To” field of the first email message.

4. 2. The method of claim 1, wherein the step of the MTA selecting the specific source IP address from the plurality of source IP addresses comprises the steps of the MTA determining a set of active source IP addresses from the plurality of source IP addresses and selecting the specific source IP address from the set of active source IP addresses.

5. 5. The method of claim 4, further comprising the step of the MTA using a selection technique to select the particular source IP address from the set of active source IP addresses.

6. A first set of the plurality of source IP addresses of the sender is assigned to a first proxy server in the set of proxy servers, and a second set of the plurality of source IP addresses of the sender is assigned to a second proxy server in the set of proxy servers. The method of claim 1 , wherein

7. 2. The method of claim 1, wherein a first proxy server in the set of proxy servers is configured to handle a set of source IP addresses, a first source IP address in the set associated with a first sender of the plurality of senders, and a second source IP address in the set associated with a second sender of the plurality of senders, the first sender being different from the second sender.

8. the MTA identifying a subset of email messages from the plurality of email messages associated with the sender; 2. The method of claim 1, further comprising: the MTA sending the subset of email messages to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.

9. 9. The method of claim 8, wherein the number of messages in the subset of messages is determined based at least in part on a message limit associated with the recipient's domain, the message limit specifying the number of messages that can be sent using the connection established by the proxy server.

10. 2. The method of claim 1, wherein the step of the MTA sending the first email message to the destination IP address includes receiving a message from the proxy server indicating that the connection between the particular source IP address and the destination IP address has been successfully established by the proxy server.

11. The method of claim 1 , wherein the proxy server is a Transmission Control Protocol (TCP) proxy server.

12. The method of claim 1 , wherein the MTA and the proxy server are implemented on a single computer system.

13. An email delivery system that provides an email delivery service, Memory and one or more processors configured to perform a process, the process comprising: the email delivery system running a message transfer agent (MTA) and a proxy server; the MTA selecting a first email message to process from a message queue, the message queue including a plurality of email messages received from a plurality of senders, the plurality of senders corresponding to a plurality of subscribers to the email delivery service; the MTA determining a sender associated with the first email message; the MTA determining a recipient of the first email message; the MTA identifying a plurality of source Internet Protocol (IP) addresses, including an IP address usable as a source IP address of the first email message, based on the determined sender of the first email message; the MTA selecting a particular source IP address from the plurality of source IP addresses; the MTA determining a destination IP address of the recipient of the email message; the MTA identifying a particular proxy server from a set of one or more proxy servers that is configured to handle the selected particular source IP address; the MTA communicating to the particular proxy server information including the particular source IP address and the destination IP address; and the MTA sending the first email message to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.

14. 14. The system of claim 13, wherein the MTA selecting the specific source IP address from the plurality of source IP addresses comprises the MTA determining a set of active source IP addresses from the plurality of source IP addresses and selecting the specific source IP address from the set of active source IP addresses.

15. 14. The system of claim 13, wherein a first set of the plurality of source IP addresses of the sender is assigned to a first proxy server in the set of proxy servers, and a second set of the plurality of source IP addresses of the sender is assigned to a second proxy server in the set of proxy servers.

16. 14. The system of claim 13, wherein a first proxy server in the set of proxy servers is configured to handle a set of source IP addresses, a first source IP address in the set associated with a first sender of the plurality of senders, and a second source IP address in the set associated with a second sender of the plurality of senders, the first sender being different from the second sender.

17. 14. The system of claim 13, wherein the MTA sending the first email message to the destination IP address includes receiving a message from the proxy server indicating that the connection between the particular source IP address and the destination IP address has been successfully established by the proxy server.

18. A non-transitory computer-readable medium having stored thereon program code executable by one or more processing units to perform operations, the program code comprising: The email delivery service runs a message transfer agent (MTA) and a proxy server; the MTA selecting a first email message to process from a message queue, the message queue including a plurality of email messages received from a plurality of senders, the plurality of senders corresponding to a plurality of subscribers to the email delivery service; the MTA determining a sender associated with the first email message; the MTA determining a recipient of the first email message; the MTA identifying a plurality of source Internet Protocol (IP) addresses, including an IP address usable as a source IP address of the first email message, based on the determined sender of the first email message; the MTA selecting a particular source IP address from the plurality of source IP addresses; the MTA determining a destination IP address of the recipient of the email message; the MTA identifying a particular proxy server from a set of one or more proxy servers that is configured to handle the selected particular source IP address; the MTA communicating to the particular proxy server information including the particular source IP address and the destination IP address; the MTA sending the first email message to the destination IP address using a connection established by the proxy server between the particular source IP address and the destination IP address.

19. the MTA identifying a subset of email messages from the plurality of email messages associated with the sender; 20. The non-transitory computer-readable medium of claim 18, further comprising: the MTA sending the subset of email messages to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.

20. 20. The non-transitory computer-readable medium of claim 19, wherein the number of messages in the subset of messages is determined based at least in part on a message limit associated with the recipient's domain, the message limit specifying the number of messages that can be sent using the connection established by the proxy server.

Images