Message forwarding agent architecture for email delivery systems

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 and priority of U.S. Non - Provisional Application No. 17 / 345,520, filed on June 11, 2021, entitled "Message Transfer Agent Architecture for Email Delivery Systems". The content of U.S. Non - Provisional Application No. 17 / 345,520 is hereby incorporated by reference in its entirety for all purposes.

Background Art

[0002] Background Some 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 emails to intended recipients. These emails can include marketing emails, transactional emails, alert emails, confirmation emails, and other types of emails. An example of such an email delivery service is the Oracle Cloud Infrastructure (OCI) email delivery service provided by Oracle Corporation. The OCI email delivery service provides a platform that uses key deliverability metrics to make the transmission of customers' emails as good as possible.

[0003] With the increasing popularity of email delivery services, the volume of emails processed by these services continues to increase rapidly. Existing architectures implementing these services need improvement to make the services scalable, resilient, and reliable.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Brief Summary This disclosure generally relates to a cloud-based email delivery service. More specifically, it describes, but is not limited to, an improved architecture using a Mail Transfer Agent (MTA) and a proxy server that improves the scalability and reliability of the system implementing the email delivery service.

[0005] In a particular embodiment, an email message delivery system is disclosed that provides an email delivery service. 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 the sender associated with the first email message and determines the recipient of the first email message. Based on the sender determined for the first email message, the MTA identifies a source Internet Protocol (IP) address, including an IP address that can be used as the source IP address of the first email message. The MTA selects a specific source IP address from the source IP addresses and determines the destination IP address of the recipient of the email message. The MTA identifies a specific proxy server from a set of one or more proxy servers that is configured to handle the selected specific source IP address, 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 specific source IP address and destination IP address to the proxy server. Therefore, the established connection is used to send the first email message to the destination IP address.

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

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

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

[0009] In a specific example, the MTA identifies a subset of email messages from the email messages associated with the sender and sends this subset to the destination IP address using a connection established by a proxy server between a specific source IP address and a destination IP address. In a specific example, the number of messages in the subset is determined based on a message limit associated with the recipient's domain, which specifies the number of messages that can be sent using the connection established by the proxy server.

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

[0011] This specification describes various embodiments, including methods, systems, and non-temporary computer-readable storage media for storing programs, code, or instructions executable by one or more processors. These exemplary embodiments are mentioned not to limit or define this disclosure, but to provide examples to aid in understanding this disclosure. Additional embodiments are described in the detailed description, where further descriptions are provided. [Brief explanation of the drawing]

[0012] [Figure 1] This describes a computing environment that includes an email message delivery system (EMDS) with improved capabilities for efficiently processing and delivering email messages to a set of recipients, according to a specific embodiment. [Figure 2] This is an illustrative diagram of the contents of the message queue in the MTA shown in Figure 1, according to a specific embodiment. [Figure 3]This document provides an example of a process performed by an MTA in cooperation with a proxy server to process email messages received by EMDS and delivered to target recipients, according to a specific embodiment. [Figure 4] This block diagram shows one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 5] This block diagram shows another pattern for implementing cloud infrastructure as a service system, with at least one embodiment. [Figure 6] This block diagram shows another pattern for implementing cloud infrastructure as a service system, with at least one embodiment. [Figure 7] This block diagram shows another pattern for implementing cloud infrastructure as a service system, with at least one embodiment. [Figure 8] This shows an exemplary computer system in which various embodiments may be implemented. [Modes for carrying out the invention]

[0013] Detailed explanation In the following description, certain details are included to provide a complete understanding of a particular embodiment for illustrative purposes. However, it will be apparent that various embodiments can be carried out without these specific details. The figures and descriptions are not intended to be limiting. The term “exemplary” is used herein to mean “serving as an example, illustration, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous over other embodiments or designs.

[0014] This disclosure relates, in general terms, to a cloud-based email delivery service. More specifically, it describes, but is not limited to, an improved architecture using a mail transfer agent (MTA) and proxy server that enhances the scalability and reliability of the system implementing the email delivery service.

[0015] Cloud-based email delivery services provide a fast and reliable management solution for sending large volumes of email to be delivered to a set of target 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 sending agents (MSAs) and message forwarding agents (MTAs) configured to receive email messages from various tenants or customers of the email delivery service and deliver those email messages to target recipients. As described herein, an EMDS customer or tenant can represent one or more “senders” of an email message. Various email message delivery protocols can be used to communicate email messages to target recipients. In one embodiment, a simple message forwarding protocol (e.g., SMTP) is used to communicate email messages to target recipients.

[0016] To handle outbound message flows, an MSA in an email delivery system typically receives an email message from the sender and routes that email message to an MTA, called an "outbound MTA," as the email message is sent outbound from the email delivery system. Selection techniques are used to select the outbound MTA from among several available MTAs. In certain implementations, the outbound MTA may be selected randomly. Other implementations may use round-robin selection techniques, longest unused techniques, or other more advanced selection techniques. However, separating the MSA layer and the MTA layer usually requires additional implementations of such architectures. Furthermore, in terms of hardware, the use of resources for email delivery services becomes inefficient. In addition, using multiple MTA layers requires the correct set of IP addresses to be connected to the MTA and to perform accurate routing of messages.

[0017] The email message delivery system described in this disclosure offers several technological advancements and / or improvements over traditional cloud-based message delivery services. The email message delivery system described in this disclosure provides a fast, reliable, and managed email delivery service by implementing a robust infrastructure of network elements (e.g., MTA and MSA) 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 of each layer requires its own dedicated resources, leading to inefficient use of resources and greater complexity in managing multiple email message queues, a new architecture is described that includes an MTA and a proxy server. The MTA is configured to provide a combination of traditional MSA and MTA functionality.

[0018] In certain implementations, the proxy server may be implemented as a Transmission Control Protocol (TCP) proxy server that functions as an intermediate network entity between a source entity, such as a source MTA, and a connection endpoint. Here, the connection endpoint facilitates the delivery of email messages to the intended recipient. To enhance the scalability and fault tolerance of the system, a pool of source IP addresses assigned to a particular sender may be distributed across multiple proxy servers. In certain implementations, the IP addresses within the pool of source IP addresses for a particular sender may be divided into non-overlapping address ranges, with each range being assigned to a separate proxy server, thereby distributing the addresses across multiple proxy servers. This distribution improves the fault tolerance of the EMDS system. Even if the proxy server providing services to a particular sender's IP address goes down, it is still possible for one or more other proxy servers to provide services to the sender and continue the delivery of emails to that sender. From the perspective of a proxy server, the source IP address designated or assigned to that proxy server may be for only one sender or for multiple senders.

[0019] The new and improved architecture, including the MTA and proxy server, further enables the sharing of resources between the MTA and the proxy server, resulting in more efficient use of resources. In certain implementations, both the MTA and the proxy server can share the same hardware resources. For example, one or more MTAs and one or more proxy servers may be hosted and run on the same computer system. The architecture described herein also simplifies recovery in the event of a proxy server failure. Firstly, the proxy server is a simple and uncomplicated component (e.g., implemented using very few lines of code), thus reducing its failure rate. However, if the 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. Once the proxy server is started up again or becomes operational again, the MTA may restart using the source IP addresses assigned to that proxy server.

[0020] Instead of requiring the maintenance of multiple email message queues, each using a different queue for each sender, as was previously necessary, 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. Therefore, the MTA does not need to maintain separate message queues for different senders. Furthermore, messages addressed to various recipients can be contained within a single MTA message queue. It has become possible to pass through. Therefore, the number of message queues that the MTA needs to maintain is reduced to one message queue. This simplifies the recovery procedure when the MTA goes down. When the MTA goes down or becomes inoperable, the email messages in the message queue of the MTA in memory can be easily remounted to another MTA without caring about specific email messages or the senders of the email messages. Since there is only one queue that needs to be managed for each MTA, the waiting time between the first transmission and the first delivery attempt is also significantly reduced. This metric can be used to distribute purchase or sale recommendation information using the email delivery service and can be particularly useful for financial services that are particularly susceptible to the impact of delays.

[0021] Referring now to the drawings, FIG. 1 shows a computing environment including an email message delivery system (EMDS) that includes improved functionality for efficiently processing email messages and delivering them to a set of recipients, according to a particular embodiment. The EMDS 102 can be implemented by one or more computing systems that execute 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 shown in FIG. 1 can be implemented using software (e.g., code, instructions, programs) executed by one or more processing devices (e.g., processors, cores) of a computing system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., a memory device).

[0022] EMDS102 can be implemented in a variety of different configurations. In certain embodiments, EMDS102 may be implemented on one or more servers in a cloud provider network, and its email message delivery service may be provided to subscribers of the cloud service on a subscription basis. The computing environment 100 shown in Figure 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, substitutions, and modifications. For example, in some implementations, EMDS102 may be implemented using more or fewer subsystems than those shown in Figure 1, and two or more subsystems may be combined, or have different configurations or arrangements of subsystems.

[0023] In certain embodiments, EMDS102 provides a fast and reliable message delivery service for sending large volumes of email messages (also referred to herein as messages or emails) to a set of recipients. Email messages can be generated by various sources 104A–104N. A source (e.g., 104A) may represent a system of an entity such as a customer or tenant of a cloud provider (e.g., an organization, company, or individual), and the cloud provider subscribes to the service provided by EMDS102 to process email messages and deliver them to a set of recipients. In certain examples, EMDS102 can receive email messages from sources 104A–104N for delivery to a set of recipients. For example, an email message 105A from source 104A may include a large volume (e.g., billions) of solicited commercial emails (e.g., marketing emails, newsletters, coupons, invitations, etc.) or transactional emails for delivery to a set of recipients. Each email message can be customized to be delivered to specific recipients within the set of recipients. As another example, an email message from a source may include a typical petition-type commercial email message sent by the source's user for delivery to a set of recipients. When used herein, the user is an EMDS This may refer to an end user, business owner, or marketing person associated with a source (e.g., 104A) that interacts with EMDS102 in order to use the email delivery service provided by 102.

[0024] In a specific example, a user associated with source 104A may interact with EMDS102 using a user device that is communicably coupled to EMDS, possibly via a public network 106 (e.g., the Internet). The user device could be a variety of types, including but not limited to mobile phones, tablets, and desktop computers. For example, a user might interact with EMDS102 using the user interface (UI) (which may be a graphical user interface (GUI)) of an application running on the user device. This interaction might involve, for example, a user (e.g., an organizational administrator) setting up various configuration parameters via the UI to enable users within the organization to interact with EMDS102. For example, a user can use the UI to set up an authorized sender list (by identifying the "From:" addresses of all users sending email within the tenant), request the creation of a pool of source IP addresses used to identify users in that organization, set up a communication protocol (e.g., Simple Mail Transfer Protocol (SMTP)) and user authentication information for users to send email via EMDS102, specify a limit 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 open simultaneously to a single recipient domain), and specify a message limit on the number of messages that can be sent to a recipient domain in a single connection.

[0025] In certain cases, the number of IP addresses added to an IP address pool can directly correlate to an organization's message sending volume requirements. Organizations that send a large volume of messages per day can typically create IP pools with more IP addresses. Furthermore, connection limits specified by the recipient's domain (which may be the recipient's email service (inbox) provider, e.g., Gmail®, Yahoo®, Microsoft®) can also affect the number of IP addresses added to the pool. For example, connection limits might specify a limit on the number of simultaneous connections 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 can also help protect the organization's overall reputation and potentially lead to improved message deliverability. Organizations with a good sending reputation may require fewer IPs to deliver emails, in contrast to organizations that generate a large number of spam reports or have poor user engagement. In some cases, organizations may want to create separate IP pools. Using separate IP pools allows organizations 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 IP pool can maintain its own reputation and is not affected by IPs in other pools.

[0027] After configuring EMDS102 as described above, an end user associated with a source (e.g., 104A) can send email messages to EMDS102 via the user device for delivery to one or more recipients in a set. In a specific example, the user can compose email messages using an email client application (e.g., Mail User Agent) installed on the device. The Mail User Agent (MUA) then processes the email before sending it to EMDS102. Messages may be formatted in an appropriate format. In certain examples, the MUA can send messages to the EMDS102 using a transmission protocol (e.g., SMTP, HTTP, or other protocols). In certain implementations, email messages may be automatically sent to the EMDS via an application installed on the user's device.

[0028] In certain embodiments, a load balancer 108 within EMDS 102 may be configured to receive email messages 105A-105N from sources 104A-104N and select an MTA from a set of MTAs 110A-110N within EMDS 102 to process the email messages. As described herein, an MTA may be a network element within EMDS 102 (e.g., a mail server) configured to receive email messages from various sources and forward those email messages to the appropriate end users or destinations. In 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 taken 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 queue, including performing tasks such as adding messages to the queue and selecting messages from the queue to process. The MTA message queue may contain email messages from multiple different senders, and the email messages may be sent to different recipients.

[0029] Figure 2 is an illustrative diagram of the contents of a message queue in the MTA shown in Figure 1, according to a specific embodiment. The embodiment shown in Figure 2 shows 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. For 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 sent to different recipients.

[0030] Returning to the explanation of Figure 1, in a particular implementation, each MTA (e.g., 110A, 110B, or 110C) may include a Message Sending Agent (MSA) (not shown in Figure 1), which may be a computer program or software agent implemented within the MTA that receives email from the user's device's mail user agent (MUA) and works with the MTA to deliver the email to a set of recipients. The MTA may perform additional tasks. These tasks may include, but are not limited to, monitoring the flow of outgoing email, delivering outgoing email, queuing, throttling, scheduling, connection management, and tracking the email delivery status of email messages.

[0031] The load balancer 108 can use various methods to select an MTA from a set of MTAs 110A, 110B, and 110C to process email messages. For example, one method allows the load balancer 108 to select an MTA using a round-robin scheduling process, efficiently distributing the processing of email messages across each MTA in the set of MTAs. For example, using round-robin scheduling, the load balancer 108 might use the first MTA (e.g., 110A) in the set of MTAs to process the first batch of messages received from the source (e.g., the first 1000) and deliver them to the set of recipients, the second MTA (e.g., the second 1000) to process the second batch of messages received from the source and deliver them to the set of recipients, and so on. You can select two MTAs (e.g., 110B) and a third MTA in the set of MTAs (e.g., 110C) to process a third batch of messages received from the source (e.g., a third batch of 1000) and deliver them to a set of recipients.

[0032] The selected MTA (e.g., 110A) receives an email message and adds it 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 that 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 an email message fails to be delivered for a certain period (e.g., a certain number of days), the MTA returns the email message to the host (the sender of the message).

[0033] In certain embodiments, the processing of an email message by the MTA may include the MTA selecting an email message to process from its message queue, and the MTA determining the sender and 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 configured to handle the selected specific source IP address from a set of proxy servers 112A-112C, 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 P 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 may be bound to one or more sets of source IP addresses, and a particular source IP address in one or more sets of source IP addresses may be associated with a particular sender. For example, in the embodiment shown in Figure 1, the first proxy server 112A may be bound to a set of source IP addresses, the first source IP address in the set may be associated with a first sender, the second source IP address in the set may be associated with a second sender, and the first sender may be different from the second sender. In certain examples, the assignment of IP addresses associated with a sender to different proxy servers may be performed by the EMDS administrator when the sender subscribes to the services provided by EMDS. Details regarding the processes performed by the MTA and proxy server to process email messages and deliver them to one or more recipients in a set are described below with reference to the flowcharts shown in Figures 2 and 3 and their accompanying descriptions.

[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 communicably connected to EMDS 102 via one or more communication networks 106 (e.g., the Internet). In a particular example, an email message may be delivered by one MTA (e.g., 110A) to another MTA (specified) before being delivered to the target recipient. Messages can be relayed, or forwarded, to a relay MTA (also called a relay MTA, but not always implemented within EMDS). When a relay MTA 114 receives an email message, it adds a receive trace header field to the beginning of the message header, thereby building a sequential record of the MTAs handling the message. The selection of the relay MTA for the next hop (route) may be determined by the EMDS 102 administrator as part of the configuration of the MTAs for processing email messages. When a relay MTA 114 receives a message, it can deliver the message to a user on its system, or it can pass the message to another relay MTA identified in the route. Finally, the message arrives at the final destination MTA. 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 target recipient is ready to retrieve the message. The recipient can contact the recipient system 118 using the 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 receiving legitimate petition-type commercial email messages (e.g., email messages containing advertisements, sales content, etc.) from various sources 104A-104N.

[0036] Figure 3 shows an example of a process 300 executed by the MTA in cooperation with a proxy server to process email messages received by EMDS and delivered to target recipients, according to a particular embodiment. The process shown in Figure 3 may be implemented by 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-temporary storage medium (e.g., a memory device). The process 300 shown in Figure 3 and described below is illustrative and not limiting. Figure 3 shows, but is not limited to, various processing steps performed in a particular order or sequence. In a particular alternative embodiment, the steps may be performed in some different order, and some steps may be performed in parallel. In a particular embodiment, such as the embodiment shown in Figure 1, the process shown in Figure 3 may be executed by components of EMDS 102, such as the MTA (e.g., MTA 110A) and a proxy (e.g., proxy 112A).

[0037] The process shown in Figure 3 assumes that EMDS has received a set of email messages to be delivered to the target recipients. These email messages may be received from one or more different customers (i.e., senders) or subscribers of the email delivery service provided by EMDS. The received email messages are forwarded to one or more MTAs of EMDS for processing. Each MTA queues the email messages it receives for processing into its message queue. As mentioned earlier, the MTA message queue may contain email messages from multiple different senders, and these email messages may be sent to different recipients.

[0038] For example, in the embodiment shown in Figure 1, EMDS102 can receive email messages from multiple senders. Within EMDS102, a load balancer 108 can be used to distribute email messages to different MTAs 110A, 110B, and 110C, and the email messages can be queued in the message queues of each MTA. For example, in Figure 1, email messages received by MTA 110A for processing are queued in MTA 110A's message queue 113A. It is possible to do so.

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

[0040] In block 304, for the email messages selected in 302, the MTA determines the sender and recipients of the selected email messages. For example, in Figure 1, the MTA 110A can determine the sender and recipients of the email messages selected to be processed from message queue 113A.

[0041] Each email message contains multiple fields, including an "From" field that identifies the user associated with the sender of the email message, an "To" field that identifies the recipient of the email message, and a "Body" field that contains the content of the email. As part of processing 304, the MTA can parse selected email messages to determine the user of the email message from the "From" field and the recipient of the email message from the "To" field. In certain implementations, the MTA may parse the string in the "From" field to determine the user associated with a sender authorized to send email messages. For example, the "From" field may contain a string in the format "user1@abccompany.com", where "user1" may identify the user associated with the sender of the email message. The part of the string after the "@" symbol identifies the 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 user1@abcompany.com, the sender may be identified as ABC Company.

[0042] In certain examples, after determining the sender of an email message, the MTA may initiate an authorization process based on prior authentication and determine a list of all possible sender addresses that the sender is permitted to use. The MTA then checks the message from the sender to confirm that an authorized sender address is being used. In certain embodiments, checks may also be performed to determine whether the sender is permitted 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 that can be used as source IP addresses for email messages. In certain examples, a pool of source IP addresses for senders and users associated with those senders may be pre-assigned by EMDS. For example, this can be done when a sender subscribes to the email delivery service and provides EMDS with a list of authorized users.

[0044] In certain implementations, a sender can identify a specific pool of source IP addresses. For example, in Figure 1, the MTA 110A can 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 can be used to identify a pool of source IP addresses. In certain implementations, a pool of source IP addresses may be shared among senders.

[0045] In block 308, the MTA selects the source IP address from the pool of source IP addresses identified in block 306 to send the email message selected in block 302. Select a specific source IP address to be used. The MTA can select a specific source IP address from a pool of source IP addresses using various selection techniques. In certain implementations, the MTA may first determine a set of active IP addresses from the pool of IP addresses. An IP address is considered active if it has not expired and is still functioning. 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 be inactive or unavailable because the source IP address exceeds the connection speed limit for a particular recipient of an email message, the proxy server serving that IP address is marked as failed or inactive, or email message delivery using that IP address has failed in the past. As part of processing 308, the MTA may filter out inactive addresses from the pool of addresses determined in 306.

[0046] After an active set of IP addresses is identified, the MTA can use selection techniques to select a single source IP address from that set. In certain 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 the longest unused technique can be used to select a single IP address from the set of active addresses. In yet another implementation, the single address may be selected based on its rating associated with the set of active addresses. For example, the IP address with the highest rating may be selected. For example, in the embodiment shown in Figure 1, the MTA 110A identifies an active set of source IP addresses and can then select a single source IP address from that set using, for example, a round-robin selection method (or some other selection technique).

[0047] In block 310, the MTA identifies a proxy server pre-configured to handle the source IP address selected in block 308. In a typical scenario, the proxy server may be selected from among several proxy servers based on the source IP address. In a specific implementation, the proxy server may be implemented as a TCP proxy server acting as an intermediary network entity between the source entity, e.g., the source MTA, and the connection endpoint, where the connection endpoint facilitates the delivery of email messages to the target recipient.

[0048] In certain implementations, source IP addresses managed by EMDS for various senders may be pre-specified or pre-assigned to a set of MTAs. For example, in Figure 1, source IP addresses handled by EMDS 102 may be assigned among proxy servers 112A, 112B, and 112C. To enhance the system's scalability and fault tolerance, a pool of source IP addresses for a particular sender may be distributed across multiple proxy servers. In certain implementations, the IP addresses within a pool of source IP addresses for a particular sender may be divided into non-overlapping address ranges, 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. Even if a proxy server serving a particular sender's IP address goes down, one or more other proxy servers can continue to serve the sender, allowing email delivery to that sender to continue. From the perspective of a proxy server, the source IP addresses specified or assigned to that proxy server may be for a single sender or for multiple senders.

[0049] For example, in Figure 1, as part of the processing of 310, MTA110A is selected in 308. It can be determined that the source IP address is mapped to proxy server-1 112A or assigned to proxy server-1 112A. Accordingly, MTA110A can select proxy server-1 112A in 310. The selected proxy server may be running on the same computer machine running the MTA or on another computer system.

[0050] In 312, the MTA determines the destination IP address to which the email message will be sent, based on the target recipient of the email message identified in 304. The destination IP address determined in 312 corresponds to the IP address of the network endpoint to which the email message will be sent, in order to facilitate communication of the email message to the target recipient. For example, as described above, the target recipient of an email message may be identified in the “To” field of the email message. For example, the “To” field may contain a string in the format “recipient@xyz.com”, where “recipient” identifies the username and “xyz.com” identifies the domain name. The domain name “xyz.com” itself contains a first part “xyz” that identifies the organization and a second part “.com” that identifies the top-level domain (TLD) (TLDs can be .com, .org, .edu, .net, .gov, etc.). As part of the processing of 312, the MTA may determine the destination IP address to which the email message will be sent, based on the username and domain of the target recipient of the email message. For example, an MTA can resolve a domain name to determine the fully qualified domain name of a mail exchange server within the Domain Name System (DNS). The DNS server for the domain responds with any mail exchange (MX) records listing the mail exchange servers for that domain (e.g., a relay MTA run by the recipient's ISP (e.g., 114)). 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 an instruction to the proxy server to set up a connection between the source IP address and the destination IP address.

[0052] In block 316, the proxy server receives a connection request from the MTA. For example, in Figure 1, proxy server-1 112A can receive a connection request from MTA110A.

[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 can 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] In 320, the proxy server can send status information about the connection established in 318 to the MTA that received the connection request. For example, in Figure 1, proxy server-1 112A can send status information to MTA 110A. The status may indicate the success or failure of the connection setup. If it fails, the MTA and proxy server can perform some error correction procedure.

[0055] In block 322, the MTA sends the selected email message in 302 using the connection established in 318 by the proxy server. The source IP address of the email becomes the source of the email, and the email is sent to the destination IP address. An email is sent, and the destination IP address is that of an endpoint (e.g., a relay MTA) that facilitates the communication of the email message to the target recipient. For example, in Figure 1, MTA 110A can send a selected email message to relay MTA 114 via a connection established by proxy server 112A. In certain implementations, email messages may be sent using the 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 target recipient (e.g., message store 116 in Figure 1) or to another intermediate network entity, such as another relay MTA. In this way, an email message is communicated to the target recipient's message store via one or more relay MTAs. The message store may be, for example, the inbox associated with the target recipient of the email message.

[0056] In certain embodiments, at 322, the MTA can send multiple email messages over a connection established by the proxy server. These email messages may include, for example, email messages from the same sender to the same recipient. In some other embodiments, these multiple email messages may include email messages from the same sender to the same domain (e.g., "xyz.com") and possibly to different recipients within that common domain. In certain embodiments, the MTA can examine the email messages in its message queue to determine whether multiple email messages can be sent over a connection established by the proxy server. The MTA may identify and remove these multiple email messages from the message queue to form a job containing 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 a particular example, the number of messages that can be added to a job may be determined at least in part 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 messages from the queue in the order they were received and sends multiple messages to the recipient using the connection established by the MTA's proxy server. After sending a certain number of messages over the connection, in a particular embodiment, in block 324, the MTA may disconnect from the proxy server, and the proxy server may disconnect from the remote system.

[0058] In certain implementations, the MTA is also configured to handle error conditions where 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 connection establishment retries by the proxy server, the proxy server may return an error code to the MTA in block 318 indicating that it was unable to establish the connection. 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 other situations, after an MTA sends an email message via 322, the MTA may receive an error code indicating that it was unable to deliver the email message to the intended recipient. This could be due to a problem with the evaluation of the source IP address used to send the email message, the email message being rejected by the recipient's email system, the source IP address exceeding the connection speed limit of a particular recipient system (inbox provider), a failed proxy server connection on that source IP address, the recipient no longer being able to receive email on that source IP, or other issues with the destination IP address, network issues. This could be due to connection rate limiting. Connection rate limiting specifies the maximum number of simultaneous connections that can be established to the recipient's system 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 sent successfully is returned to the message queue or retry queue. When the email message is selected from the queue for sending, a new source IP address different from the previously selected source IP address is selected for the email message. The email message is then sent using the new source IP address.

[0060] In certain embodiments, the MTA proxy server architecture described herein provides better operational efficiency and efficient resource management. In certain implementations, both the MTA and the proxy server can share the same hardware resources. For example, one or more MTAs and one or more proxy servers may be hosted and run on the same computer system. For example, in the embodiment shown in Figure 1, MTA 110A and proxy server-1 112A are hosted and run on 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 Figure 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, such as multiple proxy servers running on the same computer system, multiple MTAs running on the same computer system, or each of the MTA and proxy servers being implemented on separate computer systems.

[0061] In embodiments disclosed herein, the message queue maintained by the MTA may include email messages from different senders 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 that the MTA needs to maintain is reduced to a single message queue. This simplifies the recovery procedure in the event of an MTA failure. If the MTA goes down or becomes inoperable, the email messages in the MTA's message queue in memory can be easily remounted to another MTA without concern for specific email messages or the senders of those email messages.

[0062] The architectural embodiments described herein also simplify recovery in the event of a proxy server failure. Firstly, the proxy server is a simple and uncomplicated component (e.g., with very few lines of code), thus reducing its 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 process in Figure 3, 308, the MTA may filter out source IP addresses assigned to the downed 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. Once the proxy server is started up again or becomes operational again, the MTA may restart using the source IP addresses assigned to that proxy server.

[0063] Architecture example The term "cloud service" is generally used to refer to services that are made available on demand (e.g., via a subscription model) by a cloud service provider (CSP) 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 purchase hardware and software resources for the service separately. Cloud services are designed to allow subscribers to easily and scalably access applications and computing resources without the customer having to invest in procuring the infrastructure used to deliver the service.

[0064] There are several cloud service providers that offer various types of cloud services. Cloud services come in many different types or models, such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS).

[0065] Customers can subscribe to one or more cloud services provided by the CSP. Customers can be any entity, such as an individual, organization, or company. When a customer subscribes to or registers for a service provided by the CSP, a tenant or account is created for that customer. The customer can then access one or more subscribed cloud resources associated with that 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 provide computing resources that are virtualized over a public network (such as the internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer)). In some cases, the IaaS provider can also provide various services that accompany these infrastructure components (e.g., billing, monitoring, logging, load balancing, and clustering). Therefore, since these services can be policy-driven, IaaS users may be able 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 install the rest of their application stack using the cloud provider's services. For example, a user can log into an IaaS platform and create virtual machines (VMs), install operating systems (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on those VMs. The customer can then use the provider's services to perform various functions such as balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0068] In most cases, the cloud computing model requires the participation of a cloud provider. The cloud provider may, but does not have to be, a third-party service specializing in providing IaaS (e.g., providing, renting, selling). Entities can deploy a private cloud to provide their own infrastructure services. You can also choose to become a provider.

[0069] In some cases, IaaS deployment is the process of deploying a new application, or a new version of an application, to a prepared application server, etc. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may be responsible for handling things like the 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 acquiring the computers or virtual hosts to be used and installing the necessary libraries or services on them. In most cases, provisioning is not included in the deployment and 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 doing anything. Second, there's the challenge of evolving 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 declaratively defining the configuration of the infrastructure. In other words, the infrastructure (e.g., what 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 all work together) can be described declaratively. In some cases, once the topology is defined, a workflow can be generated to create and / or manage the various components described in the configuration files.

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

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

[0074] Figure 4 is a block diagram 400 showing an example pattern of an IaaS architecture according to at least one embodiment. A service operator 402 can be communicatively coupled to a secure host tenant 404 which may include a virtual cloud network (VCN) 406 and a secure host subnet 408. In some examples, the service operator 402 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays), running software such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS, WindowsPhone, Android, BlackBerry 8, PalmOS, as well as the internet, email, short message service (SMS), Blackberry®, or other valid communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, 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 one 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 game system (e.g., a Microsoft Xbox game console with or without Kinect® gesture input device), and / or a personal messaging device that can communicate via a network that has access to the VCN406 and / or the Internet.

[0075] VCN406 may include a local peering gateway (LPG) 410 that can communicately connect to Secure Shell (SSH) VCN412 via LPG410 included in SSHVCN412. SSHVCN412 may include an SSH subnet 414, and SSHVCN412 may communicately connect to control plane VCN416 via LPG410 included in control plane VCN416. Furthermore, SSHVCN412 may communicately connect to data plane VCN418 via LPG410. Control plane VCN416 and data plane VCN418 may be included in a service tenant 419 owned and / or operated by an IaaS provider.

[0076] The control plane VCN 416 may include a control plane demilitarized zone (DMZ) layer 420 that functions as a perimeter network (e.g., part of the corporate network between the corporate intranet and the external network). DMZ-based servers have limited liability and can help deter breaches. Furthermore, the DMZ layer 420 may include a control plane application layer 424 that may include one or more load balancer (LB) subnets 422, an application subnet 426, and a control plane data layer 428, which may include a database (DB) subnet 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 layer 420 can be communicatively coupled to the application subnet 426 included in the control plane application layer 424 and an internet gateway 434 that may be included in the control plane VCN 416, and the application subnet 426 is a control plane data subnet. The DB subnet 430 included in the T layer 428 can be communicatively coupled to the service gateway 436 and the network address translation (NAT) gateway 438. The control plane VCN 416 can include the service gateway 436 and the NAT gateway 438.

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

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

[0079] The Internet gateway 434 of the control plane VCN416 and the data plane VCN418 can be communicatively coupled to a metadata management service 452, which can be communicatively coupled to the public internet 454. The public internet 454 can be communicatively connected to the NAT gateway 438 of the control plane VCN416 and the data plane VCN418. The service gateway 436 of the control plane VCN416 and the data plane VCN418 can be communicatively coupled to a cloud service 456.

[0080] In some cases, a service gateway 436 of the control plane VCN416 or data plane VCN418 can make application programming interface (API) calls to a cloud service 456 without going through the public internet 454. API calls from the service gateway 436 to the 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 an API call to the service gateway 436.

[0081] In some examples, a secure host tenant 404 can connect directly to a service tenant 419, or it may be isolated otherwise. A secure host subnet 408 can communicate with an SSH subnet 414 via an LPG 410, which can enable bidirectional communication through systems that would otherwise be isolated. Connecting the secure host subnet 408 to the SSH subnet 414 allows the secure host subnet 408 to access other entities within the service tenant 419.

[0082] Control plane VCN416 allows users of service tenant 419 to set up or provision the desired resources. The desired resources provisioned within CN416 can be deployed or used within the data plane VCN418. In some examples, the control plane VCN416 can be separated from the data plane VCN418, and the data plane mirror application layer 440 of the control plane VCN416 can communicate with the data plane application layer 446 of the data plane VCN418 via a VNIC442 which can be included in the data plane mirror application layer 440 and the data plane application layer 446.

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

[0084] In some examples, the data plane mirror application layer 440 can facilitate direct communication between the control plane VCN416 and the data plane VCN418. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN418. Through VNIC442, the control plane VCN416 can communicate directly with the resources contained in the data plane VCN418, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to the resources contained in the data plane VCN418.

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

[0086] In another embodiment, the LB subnet 422 included in the control plane VCN 416 may be configured to receive signals from the service gateway 436. In this embodiment, the control plane VCN 416 and the data plane VCN 418 may be configured to be invoked by the IaaS provider's customers without calling the public internet 454. The IaaS provider's customers may prefer this embodiment because the database used by the customer may be controlled by the IaaS provider and stored in a service tenant 419 which can be isolated from the public internet 454.

[0087] Figure 5 is a block diagram 500 showing another pattern example of an IaaS architecture according to at least one embodiment. A service operator 502 (e.g., service operator 402 in Figure 4) is a secure host tenant 504 (e.g., secure host tenant in Figure 4). VCN 506 can be communicatively coupled to a control plane VCN 516 (e.g., VCN 406 in Figure 4), which may include a virtual cloud network (VCN) 506 (e.g., VCN 406 in Figure 4) and a secure host subnet 508 (e.g., secure host subnet 408 in Figure 4). VCN 506 may include a local peering gateway (LPG) 510 (e.g., LPG 410 in Figure 4), which may be communicatively coupled to a secure shell (SSH) VCN 512 (e.g., SSHVCN 412 in Figure 4) via LPG 410 contained in SSHVCN 512. SSHVCN 512 may include an SSH subnet 514 (e.g., SSH subnet 414 in Figure 4), which may be communicatively coupled to a control plane VCN 516 (e.g., control plane VCN 416 in Figure 4) via LPG 510 contained in control plane VCN 516. The control plane VCN516 may be included in a service tenant 519 (for example, service tenant 419 in Figure 4), and the data plane VCN518 (for example, data plane VCN418 in Figure 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 VCN516 may include a control plane DMZ layer 520 (e.g., control plane DMZ layer 420 in Figure 4) which may include an LB subnet 522 (e.g., LB subnet 422 in Figure 4), a control plane application layer 524 (e.g., control plane application layer 424 in Figure 4) which may include an application subnet 526 (e.g., application subnet 426 in Figure 4), and a control plane data layer 528 (e.g., control plane data layer 428 in Figure 4) which may include a database (DB) subnet 530 (e.g., similar to DB subnet 430 in Figure 4). The LB subnet 522 included in the control plane DMZ layer 520 can be communicatively coupled to the application subnet 526 included in the control plane application layer 524 and to an internet gateway 534 (e.g., internet gateway 434 in Figure 4) which may be included in the control plane VCN 516. The application subnet 526 can be communicatively coupled to the DB subnet 530 included in the control plane data layer 528, as well as to a service gateway 536 (e.g., service gateway in Figure 4) and a network address translation (NAT) gateway 538 (e.g., NAT gateway 438 in Figure 4). The control plane VCN 516 may include the service gateway 536 and the NAT gateway 538.

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

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

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

[0092] In another example, an IaaS provider's customer might have a database residing within customer tenant 521. In this example, control plane VCN 516 could include a data plane mirror app tier 540 that could include app subnet 526. The data plane mirror app tier 540 could reside within data plane VCN 518, but does not have to. That is, the data plane mirror app tier 540 can access customer tenant 521, but does not have to reside within data plane VCN 518 and may be owned or operated by the IaaS provider's customer. The data plane mirror app tier 540 may be configured to make calls to data plane VCN 518, but does not have to be configured to make calls to any entity contained within control plane VCN 516. A customer might want to deploy or otherwise use resources in data plane VCN 518 that are provisioned within control plane VCN 516, and the data plane mirror app tier 540 can facilitate the customer's desired deployment or other use of resources.

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

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

[0095] Figure 6 is a block diagram 600 illustrating another pattern example of an IaaS architecture according to at least one embodiment. A service operator 602 (e.g., service operator 402 in Figure 4) can be communicatively coupled to a secure host tenant 604 (e.g., secure host tenant 404 in Figure 4), which may include a virtual cloud network (VCN) 606 (e.g., VCN406 in Figure 4) and a secure host subnet 608 (e.g., secure host subnet 408 in Figure 4). The VCN 606 may include an LPG 610 (e.g., LPG410 in Figure 4) which can be communicatively coupled to the SSHVCN 612 (e.g., SSHVCN412 in Figure 4) via an LPG 610 contained within the SSHVCN 612. SSHVCN612 may include SSH subnet 614 (e.g., SSH subnet 414 in Figure 4), and SSHVCN612 may be communicatively coupled to control plane VCN616 (e.g., control plane VCN416 in Figure 4) via LPG610 included in control plane VCN616, and may be communicatively coupled to data plane VCN618 (e.g., data plane 418 in Figure 4) via LPG610 included in data plane VCN618. Control plane VCN616 and data plane VCN618 may be included in service tenant 619 (e.g., service tenant 419 in Figure 4).

[0096] The control plane VCN616 may include a control plane DMZ layer 620 (e.g., control plane DMZ layer 420 in Figure 4) which may include a load balancer (LB) subnet 622 (e.g., LB subnet 422 in Figure 4), a control plane application layer 624 (e.g., control plane application layer 424 in Figure 4) which may include an application subnet 626 (e.g., similar to application subnet 426 in Figure 4), and a control plane data layer 628 (e.g., control plane data layer 428 in Figure 4) which may include a DB subnet 630. The LB subnet 622 included in the control plane DMZ layer 620 may be communicatively coupled to the application subnet 626 included in the control plane application layer 624 and to an internet gateway 634 (e.g., internet gateway 434 in Figure 4) which may be included in the control plane VCN 616. The application subnet 626 may be communicatively coupled to the DB subnet 630, service gateway 636 (e.g., service gateway in Figure 4), and network address translation (NAT) gateway 638 (e.g., NAT gateway 438 in Figure 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 VCN618 can include the data plane application layer 646 (e.g., data plane application layer 446 in Figure 4), the data plane DMZ layer 648 (e.g., data plane DMZ layer 448 in Figure 4), and the data plane data layer 650 (e.g., data plane data layer 450 in Figure 4). The data plane DMZ layer 648 may include the LB subnet 622, which can be communicatively coupled to the trusted application subnet 660 and untrusted application subnet 662 of the data plane application layer 646, and the internet gateway 634 included in the data plane VCN618. The trusted application subnet 660 can be communicatively coupled to the service gateway 636 included in the data plane VCN618, the NAT gateway 638 included in the data plane VCN618, and the DB subnet 630 included in the data plane data layer 650. The untrusted application subnet 662 is included in the data plane The data plane can be communicatively coupled to the service gateway 636 included in VCN618 and the DB subnet 630 included in the data plane data layer 650. The data plane data layer 650 can include the DB subnet 630 which can be communicatively coupled to the service gateway 636 included in the data plane VCN618.

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

[0099] The Internet gateway 634, included in the control plane VCN616 and the data plane VCN618, can communicate with a metadata management service 652 (for example, the metadata management system 452 in Figure 4), which can communicate with the public internet 654. The public internet 654 can communicate with a NAT gateway 638, included in the control plane VCN616 and the data plane VCN618. The service gateway 636, included in the control plane VCN616 and the data plane VCN618, can communicate with a cloud service 656.

[0100] In some embodiments, the data plane VCN618 can be integrated with the customer tenant 670. This integration may be beneficial or desirable for the IaaS provider's customer, such as when support at code execution is required. The customer may provide execution of potentially destructive code, code that may communicate with other customer resources, or code that may cause other undesirable effects. In response, the IaaS provider can decide whether to execute the code provided to the IaaS provider by the customer.

[0101] In some examples, an IaaS provider's customer may request temporary network access from the IaaS provider to add functionality to a dataplane tier application 646. The code that performs the functionality can run in VM666(1)~(N), and the code cannot be configured to run anywhere else on the dataplane VCN618. Each VM666(1)~(N) can connect to one customer tenant 670. Each container 671(1)~(N) contained within VM666(1)~(N) may be configured to run code. In this case, a double isolation may exist (e.g., code execution in container 671(1)~(N), which may be contained in at least VM666(1)~(N) that are in an untrusted application subnet 662), which may help prevent incorrect or undesirable code from damaging the IaaS provider's network or another customer's network. Containers 671(1)-(N) may be communicatively coupled to customer tenant 670 and may be configured to send or receive data from customer tenant 670. Containers 671(1)-(N) may not be configured to send or receive data from any other entities in the data plane VCN618. Once code execution is complete, the IaaS provider terminates containers 671(1)-(N). Alternatively, it can be disposed of by other means.

[0102] In some embodiments, a trusted application subnet 660 may execute code owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 660 may be communicatively coupled to a DB subnet 630 and configured to perform CRUD operations within the DB subnet 630. An untrusted application subnet 662 may be communicatively coupled to the DB subnet 630, but in this embodiment, the untrusted application subnet may be configured to perform read operations within the DB subnet 630. Containers 671(1)-(N), which may be included in each customer's VM666(1)-(N) and capable of executing code from the customer, do not necessarily have to be communicatively coupled to the DB subnet 630.

[0103] In other embodiments, the control plane VCN616 and the data plane VCN618 do not have to be directly communicatively coupled. In this embodiment, direct communication between the control plane VCN616 and the data plane VCN618 is not required. However, communication can be performed indirectly through at least one method. The LPG610 may be established by an IaaS provider that can facilitate communication between the control plane VCN616 and the data plane VCN618. In another example, the control plane VCN616 or the data plane VCN618 can make a call to a cloud service 656 via a service gateway 636. For example, a call from the control plane VCN616 to the cloud service 656 may include a request for a service that can communicate with the data plane VCN618.

[0104] Figure 7 is a block diagram 700 showing another pattern example of an IaaS architecture according to at least one embodiment. A service operator 702 (e.g., service operator 402 in Figure 4) can be communicatively coupled to a secure host tenant 704 (e.g., secure host tenant 404 in Figure 4), which may include a virtual cloud network (VCN) 706 (e.g., VCN406 in Figure 4) and a secure host subnet 708 (e.g., secure host subnet 408 in Figure 4). The VCN 706 may include an LPG 710 (e.g., LPG410 in Figure 4) which can be communicatively coupled to SSHVCN 712 (e.g., SSHVCN 412 in Figure 4) via an LPG 710 contained in SSHVCN 712. SSHVCN712 may include SSH subnet 714 (e.g., SSH subnet 414 in Figure 4), and SSHVCN712 may be communicatively coupled to control plane VCN716 (e.g., control plane VCN416 in Figure 4) via LPG710 included in control plane VCN716, and may be communicatively coupled to data plane VCN718 (e.g., data plane 418 in Figure 4) via LPG710 included in data plane VCN718. Control plane VCN716 and data plane VCN718 may be included in service tenant 719 (e.g., service tenant 419 in Figure 4).

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

[0106] The data plane VCN 718 can include a data plane application layer 746 (e.g., data plane application layer 446 in Figure 4), a data plane DMZ layer 748 (e.g., data plane DMZ layer 448 in Figure 4), and a data plane data layer 750 (e.g., data plane data layer 450 in Figure 4). The data plane DMZ layer 748 may include an LB subnet 722, which can be communicatively coupled to a trusted application subnet 760 (e.g., trusted application subnet 660 in Figure 6), an untrusted application subnet 762 in the data plane application layer 746 (e.g., untrusted application subnet 662 in Figure 6), and an internet gateway 734 included in the data plane VCN 718. The trusted application subnet 760 can be communicatively coupled to a service gateway 736 included in the data plane VCN 718, 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 application subnet 762 can communicate with the service gateway 736 included in the data plane VCN 718 and the DB subnet 730 included in the data plane data layer 750. The data plane data layer 750 may include the DB subnet 730 which can communicate with the service gateway 736 included in the data plane VCN 718.

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

[0108] The Internet gateway 734, included in the control plane VCN716 and the data plane VCN718, can communicate with a metadata management service 752 (for example, the metadata management system 452 in Figure 4), which can communicate with the public internet 754. The public internet 754 can communicate with a NAT gateway 738, included in the control plane VCN716 and the data plane VCN718. The service gateway 736, included in the control plane VCN716 and the data plane VCN718, can communicate with a cloud service 756.

[0109] In some cases, the pattern shown by the architecture in block diagram 700 of Figure 7 can be considered an exception to the pattern shown by the architecture in block diagram 600 of Figure 6, and may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in isolated areas). Each customer's VM76 Each container 767(1)-(N) contained within 6(1)-(N) is accessible to the customer in real time. Each container 767(1)-(N) may be configured to make calls to each secondary VNIC 772(1)-(N) contained in the application subnet 726 of the data plane application layer 746, which may be contained in the container exit VCN 768. The secondary VNICs 772(1)-(N) may send calls to the NAT gateway 738, which can send calls to the public internet 754. In this example, the containers 767(1)-(N) accessible to the customer in real time can be isolated from the control plane VCN 716 and isolated from other entities contained in the data plane VCN 718. The containers 767(1)-(N) may also be isolated from resources from other customers.

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

[0111] It should be understood that the IaaS architectures 400, 500, 600, and 700 shown in the figures may have components other than those shown. Furthermore, the embodiments shown in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown, may combine two or more components, or may have different configurations or arrangements of components.

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

[0113] Figure 8 shows an exemplary computer system 800 in which various embodiments can be implemented. System 800 can be used to implement any of the computer systems described above. As shown in the figure, computer system 800 includes a processing unit 804 that communicates with several 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 communication subsystem 824. The storage subsystem 818 includes a tangible computer-readable storage medium 822 and system memory 810.

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

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

[0116] In various embodiments, the processing unit 804 can execute various programs in response to program code and can maintain multiple concurrently running programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 804 and / or the storage subsystem 818. Through appropriate programming, the processor 804 can provide the various functions described above. The computer system 800 may further include a processing accelerator 806 which may include a digital signal processor (DSP), a dedicated processor, etc.

[0117] The I / O subsystem 808 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice and trackballs, touchpads and 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 may also include motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor, which allow the user to control and interact with input devices, such as the Microsoft Xbox® 360 game controller, through a natural user interface using gestures and voice commands. User interface input devices may also include eye gesture recognition devices, such as the Google Glass® blink detector, which detects eye activity from the user (e.g., blinking while taking photos and / or selecting menus) and translates eye gestures as input to an input device (e.g., Google Glass®). Furthermore, the user interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., 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 graphics 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 rangefinders, and eye-tracking devices. Furthermore, user interface input devices may also include, for example, computer-controlled devices. Medical imaging input devices such as fluoroscopy, magnetic resonance imaging, oscillating emission computed tomography, and medical ultrasound equipment may be included. User interface input devices may also include audio input devices such as MIDI keyboards and digital musical instruments.

[0119] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 800 to a user or another computer. For example, user interface output devices include, but are not limited to, a variety of display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0120] The computer system 800 may include a storage subsystem 818 having software elements that are shown to be currently located in the system memory 810. The system memory 810 can store program instructions that can be loaded and executed on the processing unit 804, as well as data generated during the execution of these programs.

[0121] Depending on the configuration and type of the computer system 800, the system memory 810 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM) or flash memory). RAM typically contains data and / or program modules that are immediately accessible to the processing unit 804 and / or currently operating and executing by the processing unit 804. In some implementations, the system memory 810 may contain 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), which contains basic routines that help transfer information between elements within the computer system 800, such as during startup, may typically be stored in ROM. As an example, and not an limitation, the system memory 810 also refers to application programs 812, program data 814, and the operating system 816, which may include client applications, web browsers, middle-tier applications, and relational database management systems (RDBMS). For 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.

[0122] The storage subsystem 818 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of several embodiments. When executed by the processor, software (programs, code modules, instructions) that provides the above-described functionality 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 this disclosure. We can also provide chicken.

[0123] The storage subsystem 800 may also include a computer-readable storage medium reader 820 which can be further connected to the computer-readable storage medium 822. Together, and optionally in combination with the system memory 810, the computer-readable storage medium 822 can comprehensively represent a storage medium for temporarily and / or more permanently storing, storing, transmitting, and retrieving computer-readable information, in addition to remote, local, fixed, and / or removable storage devices.

[0124] Computer-readable storage media 822 containing code or a portion of code may also include any suitable media known or used in the art, including, but not limited to, storage and communication media such as volatile and non-volatile, removable and non-removable media, implemented in any way or technique 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 technologies, CD-ROM, digital versatile disk (DVD), or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This may also include intangible computer-readable media such as any other media that can be used to transmit data signals, data transmissions, or desired information and are accessible by the computing system 800.

[0125] As an example, the computer-readable storage medium 822 may include a hard disk drive that reads or writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads or writes to a removable non-volatile magnetic disk, and an optical disk drive that reads or writes to a removable non-volatile optical disk such as a CD-ROM, DVD, Blu-ray® disc, or other optical medium. The computer-readable storage medium 822 may also include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, and digital videotapes. The computer-readable storage medium 822 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, and static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and associated computer-readable media can provide non-volatile storage for computer-readable instructions, data structures, program modules, and other data for the computer system 800.

[0126] The communication subsystem 824 provides an interface to other computer systems and networks. The communication subsystem 824 functions as an interface for sending and receiving data between the computer system 800 and other systems. For example, the communication subsystem 824 can enable the computer system 800 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 824 may include radio frequency (RF) transceiver components for accessing radio voice and / or data networks (e.g., using advanced data network technologies such as cellular technology, 3G, 4G, or EDGE (Enhanced Data Rate for Global Evolution)), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global The system may include GPS receiver components and / or other components. In some embodiments, the communication 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 communication subsystem 824 may also receive input 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 can use the computer system 800.

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

[0129] Furthermore, the communication 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 have no explicit end and may be essentially unlimited. 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, and automotive traffic monitoring.

[0130] The communication 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 can communicate with one or more streaming data source computers coupled to the computer system 800.

[0131] The computer system 800 may be one of various types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0132] Due to the constantly changing nature of computers and networks, the description of the computer system 800 shown in the figure is intended only as a specific example. Many other configurations are possible with more or fewer components than the system shown in the figure. For example, customized hardware may also be used, or certain elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connections to other computing devices, such as network input / output devices, may be used. Based on the disclosures and teachings provided herein, those skilled in the art will understand other techniques and / or methods for implementing various embodiments.

[0133] While specific embodiments have been described, various modifications, changes, alternative structures, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within a specific, particular data processing environment, but can freely operate within multiple data processing environments. Furthermore, while the embodiments have been described using a specific set of transactions and steps, it will be apparent to those skilled in the art that the scope of this disclosure is not limited to the described set of transactions and steps. The various features and aspects of the embodiments described above can be used individually or in combination.

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

[0135] Therefore, the specification and drawings should be considered illustrative, not restrictive. However, it is clear that additions, subtractions, deletions, and other modifications and changes can be made without departing from the broader intent and scope set forth in the claims. Thus, while specific embodiments of disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are included in the following claims.

[0136] In the context describing the disclosed embodiments (particularly in the context of the following claims), the use of the terms “a,” “an,” “the,” and similar reference subjects should be construed to cover both singular and plural forms unless otherwise indicated herein or otherwise clearly inconsistent with the context. The terms “include,” “have,” “contain,” and “contain” should be construed as unrestricted terms (i.e., “include but not limited to”) unless otherwise specified herein. The term “connected” should be construed to be included, attached, or combined with, even if something is intervening within it. The descriptions of value ranges herein are merely intended to serve as a simplified way of referring individually to each individual value within that range unless otherwise indicated herein, and each individual value is incorporated into the specification as if it were individually described herein. All methods described herein may be performed in any appropriate order unless otherwise indicated herein or otherwise clearly inconsistent with the context. Any examples or exemplary language provided herein (e.g., "etc.") are for illustrative purposes only and, unless otherwise requested, do not limit the scope of this disclosure. Nothing in this specification should be construed as indicating that any unclaimed element is essential for the practice of this disclosure.

[0137] Disjunctive expressions, such as the phrase "at least one of X, Y, or Z," are intended to be understood in context to be generally used to indicate that an item, term, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specified. Therefore, such disjunctive expressions are not, and should not, be intended to mean that a particular embodiment requires the presence of at least one X, at least one Y, or at least one Z, respectively.

[0138] Preferred embodiments of the present disclosure, including the best known modes for carrying out the present disclosure, are described herein. Variations of these preferred embodiments will be apparent to those skilled in the art by reading the preceding description. Those skilled in the art should be able to adopt such variations as needed, and the present disclosure can also be carried out in ways other than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents of the subject matter described in the claims appended herein, as permitted by applicable law. Furthermore, unless otherwise indicated herein, any combination of the elements described above in all possible modifications is incorporated herein.

[0139] All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent that each reference is incorporated by reference to the same extent that it is incorporated in whole herein, as is indicated individually and specifically.

[0140] While aspects of the disclosure are described in the aforementioned specification with reference to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the aforementioned disclosure can be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, the specification and drawings should be considered illustrative and not restrictive.

Claims

1. The email message delivery system that provides email delivery services runs a message transfer agent (MTA) and a proxy server. The MTA includes the step of selecting a first email message to process from a message queue, wherein the message queue includes a plurality of email messages received from a plurality of senders. The MTA identifies a plurality of source IP addresses, including IP addresses that can be used as the source Internet Protocol (IP) address of the first email message, based on the sender determined for the first email message. The MTA selects a specific source IP address from the plurality of source IP addresses, The MTA takes the step of determining the destination IP address of the recipient of the first email message, The MTA includes the step of identifying a first proxy server from a set of one or more proxy servers configured to handle the selected specific source IP address, wherein the first set of the plurality of source IP addresses of the sender is assigned to the first proxy server in the set of proxy servers. The MTA communicates information including the specific source IP address and the destination IP address to the first proxy server. A method comprising the step of the MTA sending the first email message to the destination IP address using a connection established by the first proxy server between the specific source IP address and the destination IP address.

2. The method according to 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 is determined at least in part on the “From” field of the first email message.

3. The method according to claim 1 or 2, wherein the recipient of the first email message is determined at least in part on the "To" field of the first email message.

4. The method according to any one of claims 1 to 3, wherein the step of the MTA selecting a specific source IP address from the plurality of source IP addresses includes the steps of the MTA determining a set of active source IP addresses from the plurality of source IP addresses, and selecting a specific source IP address from the set of active source IP addresses.

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

6. The method according to any one of claims 1 to 5, wherein 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.

7. The method according to any one of claims 1 to 6, wherein the first proxy server in the set of proxy servers is configured to handle a set of source IP addresses, the first source IP address in the set is associated with a first sender among the plurality of senders, and the second source IP address in the set is associated with a second sender among the plurality of senders, and the first sender is different from the second sender.

8. The MTA includes the step of identifying a subset of email messages from the plurality of email messages associated with the sender, The method according to any one of claims 1 to 7, further comprising the step of the MTA sending the subset of email messages to the destination IP address using the connection established by the first proxy server between the specific source IP address and the destination IP address.

9. The method according to claim 8, wherein the number of messages in the subset of messages is determined 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 first proxy server.

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

11. The method according to any one of claims 1 to 10, wherein the proxy server is a Transmission Control Protocol (TCP) proxy server.

12. The method according to any one of claims 1 to 11, wherein the MTA and the proxy server are implemented on the same computer system.

13. An email distribution system that provides an email distribution service, Memory and Includes one or more processors configured to perform a process, the process being: The aforementioned email distribution system runs a message transfer agent (MTA) and a proxy server, The MTA includes selecting a first email message to process from a message queue, wherein the message queue includes multiple email messages received from multiple senders. The MTA identifies a plurality of source IP addresses, including IP addresses that can be used as the source Internet Protocol (IP) address of the first email message, based on the sender determined for the first email message. The MTA selects a specific source IP address from the multiple source IP addresses, The MTA determines the destination IP address of the recipient of the first email message, The MTA includes identifying a first proxy server from a set of one or more proxy servers configured to handle the selected specific source IP address, wherein the first set of the multiple source IP addresses of the sender is assigned to the first proxy server in the set of proxy servers. The MTA communicates information including the specific source IP address and the destination IP address to the first proxy server, An email delivery system comprising the MTA sending the first email message to the destination IP address using a connection established by the first proxy server between the specific source IP address and the destination IP address.

14. The system according to claim 13, wherein the MTA's selection of a specific source IP address from the plurality of source IP addresses includes the MTA determining a set of active source IP addresses from the plurality of source IP addresses and selecting a specific source IP address from the set of active source IP addresses.

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

16. The system according to any one of claims 13 to 15, wherein the first proxy server in the set of proxy servers is configured to handle a set of source IP addresses, the first source IP addresses in the set are associated with a first sender among the plurality of senders, the second source IP addresses in the set are associated with a second sender among the plurality of senders, and the first sender is different from the second sender.

17. The system according to any one of claims 13 to 16, 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 specific source IP address and the destination IP address has been successfully established by the first proxy server.

18. A program for causing a computer to perform the method described in any one of claims 1 to 12 Ram.

Images