Message Transfer Agent Architecture for Email Delivery System

Abstract

An email message delivery system is described that uses an MTA and a proxy server to provide fast, reliable, and managed email delivery services. An email message is selected by the MTA for processing. The MTA determines a sender and intended recipient associated with the email message. The MTA then identifies a pool of source Internet Protocol addresses available for the email message based on the sender and selects a specific source IP address from the pool. The MTA then identifies a specific proxy server configured to handle the selected specific source IP address and communicates information to the specific proxy server including the specific source IP address and the destination IP address. The MTA then transmits 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.

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 an Email Delivery System". 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 delivery metrics to make the transmission of customers' emails as optimal as possible.

[0003] With the increasing popularity of email delivery services, the volume of emails processed by these services has been continuing 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 cloud-based email delivery services. More particularly, without limitation, an improved architecture using a mail transfer agent (MTA) and a proxy server that improves the scalability and reliability of a system implementing an email delivery service will be described.

[0005] In certain embodiments, an email message delivery system that provides an email delivery service is disclosed. The email message delivery system includes an MTA and a proxy server. The MTA selects a first email message to process from a message queue. The message queue includes a set of email messages received from a set of senders. The set of senders corresponds to a set of subscribers (tenants or customers) of the email delivery service. The MTA determines the sender associated with the first email message and determines the recipient of 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 based on the sender determined for the first email message. The MTA selects a particular source IP address from the source IP address and determines the destination IP address of the recipient of the email message. The MTA identifies a particular proxy server configured to handle the selected particular source IP address from a set of one or more proxy servers, establishes a connection to the proxy server, and communicates information including the particular source IP address and the destination IP address to the particular proxy server. The MTA transmits the first email message to the destination IP address using the connection established by the proxy server between the particular source IP address and the destination IP address.

[0006] In certain examples, determining the sender of the first email message involves the MTA determining the user associated with the sender of the first email message and having the authority to send the first email message, and the user associated with the sender is determined at least in part 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 certain examples, the MTA selects a particular source IP address from the source IP address by determining a set of active source IP addresses from the source IP address and selecting a particular source IP address from the set of active source IP addresses. In certain examples, the MTA uses a selection technique for selecting a particular source IP address from the set of active source IP addresses. In certain examples, the selection technique is a round-robin technique.

[0008] In certain examples, the first set of the sender's source IP addresses is assigned to the first proxy server within the set of proxy servers, and the second set of the sender's source IP addresses is assigned to the second proxy server within the set of proxy servers. In certain examples, the first proxy server within the set of proxy servers is configured to handle the set of source IP addresses, the first source IP address within the set is associated with the first sender, and the second source IP address within the set is associated with the second sender. In certain examples, the first sender is different from the second sender.

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

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

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

Brief Description of the Drawings

[0012]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

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

[0014] This disclosure generally relates to cloud-based email delivery services. More specifically, but not by way of limitation, an improved architecture using a mail transfer agent (MTA) and a proxy server that improves the scalability and reliability of a system implementing an email delivery service will be described.

[0015] Cloud-based email delivery services provide a fast and reliable management solution for sending large volumes of email to a set of intended recipients. Cloud-based email delivery services can be implemented using one or more cloud-based email delivery systems. A cloud-based email delivery system (EMDS) typically includes a set of a message sending agent (MSA) and a message transfer agent (MTA) configured to receive email messages from various tenants or customers of the email delivery service and deliver those email messages to the intended recipients. As described herein, a customer or tenant of an EMDS can represent one or more "sendors" of an email message. Various email message delivery protocols can be used to communicate an email message to an intended recipient. In one embodiment, the Simple Message Transfer Protocol (e.g., SMTP) is used to communicate an email message to an intended recipient.

[0016] To process an outbound message flow, the MSA within an email delivery system typically receives an email message from a sender and routes that email message to an MTA called an "outbound MTA" for the email message to be sent outbound from the email delivery system. Selection techniques are used to select an outbound MTA from among the multiple available MTAs. In certain implementations, the outbound MTA can be randomly selected. In other implementations, round-robin selection techniques, longest unused techniques, or other more advanced selection techniques may be used. However, separating the MSA layer and the MTA layer typically results in inefficient use of resources of the email delivery service in terms of the additional hardware necessary for implementing such an architecture. Further, to use multiple MTA layers, it is necessary to perform accurate routing of messages to the MTA to which the correct set of IP addresses is connected.

[0017] The email message delivery system described in this disclosure provides several technological advancements and / or improvements over conventional cloud-based message delivery services. The email message delivery system described in this disclosure implements a robust infrastructure of network elements (e.g., MTAs and MSAs) configured to achieve higher operating efficiency and reduce the overall overhead of email processing, thereby providing a fast and reliable managed email delivery service. Instead of providing two separate MSA layers and MTA layers where each component of each layer requires its own dedicated resources, which results in inefficient use of resources and more complex management of multiple email message queues, a new architecture including an MTA and a proxy server is described. The MTA is configured to provide a combined function of a conventional MSA and MTA.

[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, where 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 that provides services to the IP address of a particular sender 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 a single sender or for multiple senders.

[0019] The newly improved architecture, including the MTA and proxy server, further enables sharing 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 can be hosted and run by the same computer system. The architecture described herein also simplifies recovery in the event that the proxy server goes down. First, the proxy server is a simple and not complex component (e.g., implemented using very few lines of code), so its failure rate is reduced. However, if the proxy server goes down, the MTA simply stops using that proxy server. The MTA can use and select the source IP address assigned to another functioning proxy server to send email messages. When the proxy server restarts or becomes operational again, the MTA can be restarted using the source IP address assigned to that proxy server.

[0020] Rather than requiring the maintenance of multiple email message queues that use different queues for each sender, as has been the case heretofore, in the improved architecture described herein, the MTA is able to maintain a single message queue that can include email messages received from multiple different senders and addressed to multiple different recipients. Thus, the MTA does not need to maintain separate message queues for different senders. Further, messages addressed to 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 one message queue. This simplifies the recovery procedure in the event that the MTA goes down. When 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 a particular email message or the sender of the email message. Since there is only one queue that needs to be managed per MTA, the latency between the initial send and the first delivery attempt is also significantly reduced. This metric can be used to distribute purchase or sell recommendation information using an email delivery service and can be particularly useful for financial services that are especially sensitive to latency.

[0021] Referring now to the drawings, FIG. 1 shows a computing environment including an Electronic Mail Message Delivery System (EMDS) with improved functionality for efficiently processing and delivering electronic mail messages to a set of recipients, according to a particular embodiment. EMDS 102 can be implemented by one or more computing systems that execute computer-readable instructions (e.g., code, programs) to implement EMDS 102. As shown in FIG. 1, 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] EMDS 102 can be implemented in a variety of different configurations. In a particular embodiment, EMDS 102 can be implemented on one or more servers of a cloud provider network, and its electronic mail message delivery service can be provided on a subscription basis to subscribers of the cloud service. The computing environment 100 shown in FIG. 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, in some implementations, EMDS 102 can be implemented using more or fewer subsystems than those shown in FIG. 1, two or more subsystems can be combined, or different configurations or arrangements of the subsystems may be used.

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

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

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

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

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

[0028] In certain embodiments, the load balancer 108 within the EMDS 102 can be configured to receive the email messages 105A - 105N from the sources 104A - 104N and select an MTA from the set of MTAs 110A - 110N within the EMDS 102 to process the email messages. As described herein, an MTA can be a network element (e.g., a mail server) within the EMDS 102 configured to receive email messages from various sources and forward the email messages to the appropriate end user or destination. In each MTA, the email messages received by the MTA for processing are queued in the MTA's message queue. Typically, a new email message is added to the end or tail of the message queue, and the email message is retrieved from the start 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 the management of the MTA message queue, including tasks such as adding messages to the queue and selecting messages from the queue for processing. The MTA message queue can include email messages from multiple different senders, and the email messages can be sent to different recipients.

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

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

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

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

[0033] In certain embodiments, processing of an email message by the MTA can include the MTA selecting an email message for processing from its message queue, and the MTA determining the sender and intended recipient associated with the first email message. Next, the MTA identifies a pool of source IP addresses that can be used as the source IP address for the email message based on the sender, and selects a specific source IP address from the pool of source IP addresses. Next, the MTA identifies a specific proxy server configured to handle the selected specific source IP address from the set of proxy servers 112A - 112C, and communicates information including the specific source IP address and the destination IP address to the specific proxy server. Next, the MTA 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, the pool of source IP addresses assigned to senders can be distributed across an entire set of proxy servers. One or more IP addresses from the pool can be assigned to a first proxy server within the set of proxy servers, and a different set of P addresses from the pool can be assigned to a second proxy server within the set of proxy servers. In a particular example, each proxy server within the set of proxy servers may be bound to one or more sets of source IP addresses, and a particular source IP address within one or more sets of source IP addresses may be associated with a particular sender. For example, in the embodiment shown in FIG. 1, the first proxy server 112A may be bound to a set of source IP addresses, the first source IP address within the set may be associated with a first sender, the second source IP address within the set may be associated with a second sender, and the first sender may be different from the second sender. In a particular example, the assignment of different proxy servers of IP addresses associated with a sender may be performed by an administrator of the EMDS when the sender subscribes to services provided by the EMDS. Details regarding the processing performed by the MTA and proxy servers to process and deliver an email message to one or more recipients of the set are described below with respect to the flowcharts shown in FIGS. 2 and 3 and the accompanying description.

[0035] Computing environment 100 further includes one or more relay MTAs 114 and recipient systems 118. The relay MTA 114 and recipient system 118 can be communicatively connected to the EMDS 102 via one or more communication networks 106 (e.g., the Internet). In a particular example, an email message can be relayed, i.e., transferred, by a source MTA (e.g., 110A) to another MTA (also referred to herein as a relay MTA, which may not be implemented within the EMDS) before being delivered to the intended recipient. When the relay MTA 114 receives an email message, it adds a received trace header field to the beginning of the message's header, thereby building a sequential record of the MTAs handling the message. The selection of the relay MTA for the next hop (route) can be determined as part of the configuration of the MTAs for processing email messages by the administrator of the EMDS 102. The relay MTA 114, upon receiving a message, can deliver the message to a user on its system or pass the message to another relay MTA identified within the route. Eventually, the message arrives at the MTA that is the final destination. If the message is addressed to a user on the system, the MTA passes it to the recipient system 118 for final delivery. The recipient system 118 can represent an email service (inbox) provider for the recipient of the email message (e.g., Gmail (registered trademark), Yahoo (registered trademark), Microsoft (registered trademark), etc.). The recipient system 118 can store the message in the message store 116 until the intended recipient is ready to retrieve the message. The recipient can use an MUA on the recipient's device to contact the recipient system 118 and retrieve the message from the message store. The recipient system transfers the user's messages to the user's MUA upon successful authentication of the requester. In a particular example, the recipient can be an end user who receives legitimate solicitation-type commercial email messages (e.g., email messages including advertisements, sales content, etc.) from various sources 104A - 104N.

[0036] Figure 3 shows an example of process 300 executed by an MTA in cooperation with a proxy server to process email messages received by an EMDS and delivered to a target recipient, according to a particular embodiment. The processes shown in Figure 3 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing devices (e.g., processors, cores), hardware, or combinations thereof of each system. The software may be stored in a non-transitory storage medium (e.g., a memory device). The process 300 shown in Figure 3 and described below is exemplary and not limiting. Figure 3 shows various processing steps performed in a particular order or sequence, but is not limited thereto. In certain alternative embodiments, the steps may be performed in any different order or some steps may be performed in parallel. In certain embodiments, such as the embodiment shown in Figure 1, the processes shown in Figure 3 may be performed by components of the EMDS 102, such as an MTA (e.g., MTA 110A) and a proxy (e.g., proxy 112A).

[0037] The processes shown in Figure 3 assume that the EMDS has received a set of email messages to be delivered to the target recipient. The email messages may be received from one or more different customers (i.e., senders) or subscribers of the email delivery service provided by the EMDS. The received email messages are transferred to one or more MTAs of the EMDS for processing. At each MTA, the email messages received by the MTA for processing are queued in the MTA's message queue. As described above, the MTA message queue may contain email messages from multiple different senders, and the email messages may be sent to different recipients.

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

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

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

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

[0042] In a particular example, after determining the sender of the email message, the MTA can start the permission process based on prior authentication and determine a list of all possible "From" addresses permitted for use by the sender. Next, the MTA checks the message from the sender to confirm that a permitted "From" address is being used. In a particular embodiment, a check may also be performed to confirm whether the sender is permitted to send the email message to the domain corresponding to the "To" field of the email message.

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

[0044] In certain implementations, the sender can identify a particular pool of source IP addresses. For example, in FIG. 1, the MTA 110A can identify a pool of source IP addresses based on the sender determined for the email message at 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, the pool of source IP addresses can be shared among senders.

[0045] At block 308, the MTA selects a particular source IP address to be used as the source IP address for sending the selected e-mail message at 302 from the pool of source IP addresses identified at block 306. The MTA can select a particular source IP address from the pool of source IP addresses using various selection techniques. In a particular implementation, the MTA may first determine a set of active IP addresses from the pool of IP addresses. An IP address is considered active if its expiration date has not passed and it is still functional. Active IP addresses represent source IP addresses that can continue to be used for sending e-mail. For example, an IP address within the pool of IP addresses determined at 306 may not be active or may not be available because the source IP address exceeds connection speed limits for a particular recipient of the e-mail message, the proxy server providing service to that IP address has failed or been marked as inactive, the delivery of an e-mail message using that IP address has failed in the past, etc. As part of the processing at 308, the MTA can filter out and exclude non-active addresses from the pool of addresses determined at 306.

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

[0047] In block 310, the MTA identifies a proxy server that is pre-configured to handle the source IP address selected in block 308. In a common scenario, the proxy server can be selected from among a plurality of proxy servers based on the source IP address. In certain implementations, the proxy server can be implemented as a TCP proxy server that functions as an intermediary network entity between a source entity, such as the source MTA, and a connection endpoint, which facilitates the delivery of an email message to a target recipient.

[0048] In certain implementations, the source IP addresses managed by the EMDS for different senders can be pre-specified or pre-assigned to a set of MTAs. For example, in FIG. 1, the source IP addresses handled by the EMDS 102 can be assigned among the proxy servers 112A, 112B, and 112C. To enhance the scalability and fault tolerance of the system, the pool of source IP addresses for a particular sender can be distributed across multiple proxy servers. In certain implementations, the IP addresses within the pool of source IP addresses for a particular sender can be divided into non-overlapping address ranges, each range can 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 the proxy server providing services to the IP address of a particular sender goes down, one or more other proxy servers can continue to be used to provide services to the sender and continue to deliver emails to that sender. From the perspective of a proxy server, the source IP address specified or assigned to that proxy server can be for only one sender or for multiple senders.

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

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

[0051] At block 314, the MTA connects to the proxy server and then sends a connection request to the proxy server identified at 310, where the connection request includes the source IP address selected at 308 and the destination IP address determined at 312. The connection request can also include an instruction to request that the proxy server set up a connection between the source IP address and the destination IP address.

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

[0053] At 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 FIG. 1, proxy server-1 112A can determine the source IP address and the destination IP address received in the connection request and establish a connection between the source IP address and the destination IP address.

[0054] At 320, the proxy server can send status information regarding the connection established at 318 to the MTA that received the connection request. For example, in FIG. 1, proxy server-1 112A can send the status information to MTA 110A. The status can indicate the success or failure of the connection setup. If it fails, the MTA and the proxy server can perform some error correction procedure.

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

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

[0058] In certain implementations, the MTA is also configured to handle error conditions where the proxy server cannot 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 can return an error code indicating that the connection could not be established to the MTA at block 318. 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 yet other situations, after the MTA sends an email message at 322, the MTA can receive an error code indicating that the email message could not be delivered to the intended recipient. This can be due to problems with the evaluation associated with 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 used to send the email message exceeding the connection speed limit of a particular recipient system (receiving tray provider), the proxy server connection failing at that source IP address, the recipient being unable to receive emails at that source IP anymore, or other reasons related to the destination IP address or network problems. The connection rate limit specifies the maximum number of simultaneous connections that can be established to the mailbox provider of the recipient's system using the source IP address. In such situations, the EMDS can 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 an 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 in this disclosure provides better operating 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 can be hosted and executed by the same computer system. For example, in the embodiment shown in FIG. 1, MTA 110A and proxy server-1 112A are hosted and executed by the same computing system 120. Resources of the computer system 120, such as memory resources, processing resources, and network resources, can be shared by MTA 110A and proxy server-1 112A. Similarly, MTA 110B and proxy server-2 112B are on the same computer system 122, and MTA 110C and proxy server-3 112C are on computer system 124. The configuration shown in FIG. 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, other implementations are possible, such as multiple proxy servers being executed by the same computer system, multiple MTAs being executed by the same computer system, and each of the MTA and the proxy server being implemented on a separate computer system.

[0061] In the embodiments disclosed herein, the message queue maintained by the MTA can include email messages addressed to different recipients from different senders. The MTA does not need to maintain separate message queues for different senders. Further, messages intended for different recipients 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 when the MTA goes down. When 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 the email messages.

[0062] Embodiments of the architecture described herein also simplify recovery when the proxy server goes down. First, since the proxy server is a simple and not complex component (e.g., very few lines of code), its failure rate is reduced. However, when the proxy server goes down, the MTA simply stops using that proxy server. The MTA may stop using the source IP address assigned to that proxy server. For example, as part of the processing of 308 in FIG. 3, the MTA may filter out and exclude the source IP address assigned to the downed proxy server, or the source IP address tagged as non-functional or inoperable by the MTA. The MTA may use and select the source IP address assigned to another functioning proxy server to send email messages. When the proxy server restarts or becomes operable again, the MTA may be restarted using the source IP address assigned to that proxy server.

[0063] Architecture Example The term cloud service is generally used to refer to services that can be used by users or customers on demand (e.g., via a subscription model) using systems and infrastructure (cloud infrastructure) provided by a cloud service provider (CSP). Usually, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premises servers and systems. Thus, customers can utilize cloud services provided by the CSP without having to purchase hardware and software resources for the service individually. Cloud services are designed to enable subscribing customers to easily and scalably access applications and computing resources without the customer having to invest in the procurement of the infrastructure used for the provision of the service.

[0064] There are several cloud service providers that offer different types of cloud services. Cloud services have various 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 a CSP. Customers can be any entity such as an individual, an organization, or a company. When a customer subscribes or registers for a service provided by a CSP, a tenant or account is created for that customer. Subsequently, the customer can access the one or more subscribed cloud resources associated with that account via this account.

[0066] As described above, Infrastructure as a Service (IaaS) is one of the specific types of cloud computing. IaaS can be configured to provide computing resources that are virtualized via a public network (such as the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (such as servers, storage devices, network nodes (such as hardware), deployment software, platform virtualization (such as the hypervisor layer), etc.). In some cases, the IaaS provider can also provide various services associated with these infrastructure components (such as billing, monitoring, logging, load balancing, and clustering, etc.). Therefore, since these services can be policy-driven, IaaS users may be able to implement a policy to promote load balancing and maintain the availability and performance of applications.

[0067] In some cases, IaaS customers can access resources and services via a wide area network (WAN) such as the Internet and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create a virtual machine (VM), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software on that VM. Subsequently, the customer can use the provider's services to perform various functions such as balancing network traffic, troubleshooting application problems, 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 be a third-party service specializing in the provision (e.g., offering, renting, selling) of IaaS, but this is not necessary. An entity can also choose to deploy a private cloud and become its own infrastructure service provider.

[0069] In some examples, an IaaS deployment is the process of placing a new application, or a new version of an application, on 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 a cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer can be responsible for handling the operating system (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand), etc.).

[0070] In some examples, IaaS provisioning can even refer to obtaining the computers or virtual hosts to be used and installing the necessary libraries or services on them. In most cases, the deployment does not include provisioning and it may be necessary to perform provisioning first.

[0071] In some cases, there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything can be executed. Second, after everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, deleting services, etc.). In some cases, these two challenges can be addressed by making it possible to declaratively define the infrastructure configuration. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they all interact) can be declaratively described. 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, the infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs), also known as the core network, which are potentially on-demand pools of configurable and / or shared computing resources. In some examples, there can also be one or more receive / send traffic group rules that are provisioned to define how incoming and / or outgoing network traffic is set up, and one or more virtual machines (VMs). Other infrastructure elements such as load balancers, databases, etc. can also be provisioned. As more infrastructure elements are desired or added, the infrastructure can evolve incrementally.

[0073] In some cases, continuous deployment techniques may be used to enable the deployment of infrastructure code across various virtual computing environments. Further, the techniques described enable infrastructure management within these environments. In some examples, a service team can write code that is desirable to deploy to one or more, but in many cases, many different production environments (e.g., spanning different geographical locations and in some cases worldwide). However, in some cases, it may be necessary to first set up the infrastructure on which to deploy the code. In some cases, provisioning can be done manually, provisioning tools can be utilized to provision resources, and / or deployment tools can be utilized to deploy the code after the infrastructure has been provisioned.

[0074] FIG. 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 that can include a virtual cloud network (VCN) 406 and a secure host subnet 408. In some examples, the service operator 402 can use one or more client computing devices, which can be a portable handheld device (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or a wearable device (e.g., Google Glass® head-mounted display), software running such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and Internet, email, short message service (SMS), BlackBerry®, or other valid communication protocols. Alternatively, the client computing device can be a general-purpose personal computer and / or a laptop computer that runs various versions of, for example, Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing device can be a workstation computer that runs any of various commercially available UNIX® or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect (registered trademark) gesture input device), and / or a personal messaging device that can communicate via a network that can access the VCN406 and / or the Internet.

[0075] The VCN406 can include a Local Peering Gateway (LPG) 410 that can communicatively couple to a Secure Shell (SSH) VCN412 via the LPG410 included in the SSH VCN412. The SSH VCN412 can include an SSH subnet 414, and the SSH VCN412 can communicatively couple to a control plane VCN416 via the LPG410 included in the control plane VCN416. Also, the SSH VCN412 can communicatively couple to a data plane VCN418 via the LPG410. The control plane VCN416 and the data plane VCN418 can be included in a service tenant 419 that can be owned and / or operated by an IaaS provider.

[0076] The control plane VCN416 can include a control plane demilitarized zone (DMZ) layer 420 that functions as a border network (e.g., a part of an enterprise network between an enterprise intranet and an external network). DMZ-based servers have limited responsibilities and can help prevent intrusions. Further, the DMZ layer 420 can include one or more load balancer (LB) subnets 422, a control plane application layer 424 that can include an application subnet 426, and a control plane data layer 428, which can 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 to an Internet gateway 434 that can be included in the control plane VCN416. The application subnet 426 can be communicatively coupled to the DB subnet 430 included in the control plane data layer 428, as well as to a service gateway 436 and a network address translation (NAT) gateway 438. The control plane VCN416 can include a service gateway 436 and a NAT gateway 438.

[0077] The control plane VCN416 can include a data plane mirror application layer 440 that can include an application subnet 426. The application subnet 426 included in the data plane mirror application layer 440 can include a virtual network interface controller (VNIC) 442 that can execute a computing instance 444. The computing instance 444 can be communicatively coupled to the application subnet 426 included in the data plane mirror application layer 440 to the application subnet 426 that can be included in the data plane application layer 446.

[0078] The data plane VCN 418 can 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 can include an LB subnet 422 that can be communicatively coupled to an app subnet 426 of the data plane application layer 446 and an Internet gateway 434 of the data plane VCN 418. The app subnet 426 can be communicatively coupled to a service gateway 436 of the data plane VCN 418 and a NAT gateway 438 of the data plane VCN 418. The data plane data layer 450 can also include a DB subnet 430 that can be communicatively coupled to the app subnet 426 of the data plane application layer 446.

[0079] The Internet gateway 434 of the control plane VCN 416 and the data plane VCN 418 can be communicatively coupled to a metadata management service 452 that 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 VCN 416 and the data plane VCN 418. The service gateway 436 of the control plane VCN 416 and the data plane VCN 418 can be communicatively coupled to a cloud service 456.

[0080] In some examples, the service gateway 436 of the control plane VCN 416 or the data plane VCN 418 can make an application programming interface (API) call to the cloud service 456 without going through the public Internet 454. The API call 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, the secure host tenant 404 can be directly connected to the service tenant 419 or otherwise isolated. The secure host subnet 408 can communicate with the SSH subnet 414 via the LPG 410, which can enable two-way communication via a system that would otherwise be isolated. Connecting the secure host subnet 408 to the SSH subnet 414 can provide the secure host subnet 408 with access to other entities within the service tenant 419.

[0082] The control plane VCN 416 can enable users of the service tenant 419 to set up or provision desired resources. The desired resources provisioned within the control plane VCN 416 can be deployed or used within the data plane VCN 418. In some examples, the control plane VCN 416 can be separated from the data plane VCN 418, and the data plane mirror application layer 440 of the control plane VCN 416 can communicate with the data plane application layer 446 of the data plane VCN 418 via the VNIC 442 that 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 can make requests, such as create, read, update, or delete (CRUD) operations, via the public Internet 454 that can communicate requests to the metadata management service 452. The metadata management service 452 can communicate requests to the control plane VCN 416 via the Internet gateway 434. This request can be received by the LB subnet 422 included in the control plane DMZ layer 420. The LB subnet 422 can determine that the request is valid, and in response to this determination, the LB subnet 422 can send the request to the app subnet 426 included in the control plane app layer 424. If the request is verified and a call to the public Internet 454 is required, the call to the public Internet 454 can be sent to the NAT gateway 438 that can make the call to the public Internet 454. Memory that may be desired to be stored by the request can be stored in the DB subnet 430.

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

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

[0086] In other embodiments, the LB subnet 422 included in the control plane VCN 416 can be configured to receive signals from the service gateway 436. In this embodiment, the control plane VCN 416 and the data plane VCN 418 can be configured to be invoked by the customers of the IaaS provider without invoking the public Internet 454. Since the databases used by the customers can be controlled by the IaaS provider and stored in the service tenant 419 that can be isolated from the public Internet 454, the customers of the IaaS provider may desire this embodiment.

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

[0088] The control plane VCN 516 can include a control plane DMZ layer 520 (e.g., the control plane DMZ layer 420 in FIG. 4) that can include an LB subnet 522 (e.g., the LB subnet 422 in FIG. 4), a control plane application layer 524 (e.g., the control plane application layer 424 in FIG. 4) that can include an application subnet 526 (e.g., the application subnet 426 in FIG. 4), and a control plane data layer 528 (e.g., the control plane data layer 428 in FIG. 4) that can include a database (DB) subnet 530 (similar to the DB subnet 430 in FIG. 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., the Internet gateway 434 in FIG. 4) that can 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., the service gateway in FIG. 4) and a network address translation (NAT) gateway 538 (e.g., the NAT gateway 438 in FIG. 4). The control plane VCN 516 can include the service gateway 536 and the NAT gateway 538.

[0089] The control plane VCN516 can include a data plane mirror application layer 540 (e.g., the data plane mirror application layer 440 of FIG. 4) that can include an application subnet 526. The application subnet 526 included in the data plane mirror application layer 540 can include a virtual network interface controller (VNIC) 542 (e.g., the VNIC 442) that can execute a computing instance 544 (similar to the computing instance 444 of FIG. 4). The computing instance 544 can facilitate communication between the application subnet 526 of the data plane mirror application layer 540 and the application subnet 526, which can be included in a data plane application layer 546 (e.g., the data plane application layer 446 of FIG. 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 VCN516 can be communicatively coupled to a metadata management service 552 (e.g., the metadata management service 452 of FIG. 4), which can be communicatively coupled to a public internet 554 (e.g., the public internet 454 of FIG. 4). The public internet 554 can be communicatively coupled to a NAT gateway 538 included in the control plane VCN516. The service gateway 536 included in the control plane VCN516 can be communicatively coupled to a cloud service 556 (e.g., the cloud service 456 of FIG. 4).

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

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

[0093] In some embodiments, a customer of an IaaS provider can apply a filter to the data plane VCN 518. In this embodiment, the customer can determine what the data plane VCN 518 can access, and the customer can restrict access from the data plane VCN 518 to the public Internet 554. The IaaS provider may not be able to apply filters or control access of the data plane VCN 518 to an external network or database. Applying customer filters and controls to the data plane VCN 518 included in the customer tenant 521 can help isolate the data plane VCN 518 from other customers and the public Internet 554.

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

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

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

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

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

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

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

[0101] In some examples, a customer of the IaaS provider can permit the IaaS provider temporary network access and request features to be added to the data plane layer app 646. The code that executes the features can be executed on the VMs 666(1) to (N), and the code cannot be configured to execute elsewhere on the data plane VCN 618. Each of the VMs 666(1) to (N) can be connected to one customer tenant 670. Each of the containers 671(1) to (N) included in the VMs 666(1) to (N) can be configured to execute the code. In this case, there may be double isolation (e.g., code execution in the containers 671(1) to (N), the containers 671(1) to (N) can be included in at least the VMs 666(1) to (N) included in the untrusted app subnet 662), which can help prevent bad or unwanted code from damaging the IaaS provider's network or another customer's network. The containers 671(1) to (N) may be communicatively coupled to the customer tenant 670 and may be configured to send or receive data from the customer tenant 670. The containers 671(1) to (N) may not be configured to send or receive data from any other entity within the data plane VCN 618. When the code execution is complete, the IaaS provider can force-terminate the containers 671(1) to (N) or otherwise discard them.

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

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

[0104] FIG. 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 of FIG. 4) can be communicatively coupled to a secure host tenant 704 (e.g., secure host tenant 404 of FIG. 4), which can include a virtual cloud network (VCN) 706 (e.g., VCN 406 of FIG. 4) and a secure host subnet 708 (e.g., secure host subnet 408 of FIG. 4). The VCN 706 can include an LPG 710 (e.g., LPG 410 of FIG. 4) that can be communicatively coupled to an SSH VCN 712 (e.g., SSH VCN 412 of FIG. 4) via the LPG 710 included in the SSH VCN 712. The SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 414 of FIG. 4), and the SSH VCN 712 can be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 416 of FIG. 4) via the LPG 710 included in the control plane VCN 716 and can be communicatively coupled to a data plane VCN 718 (e.g., data plane 418 of FIG. 4) via the LPG 710 included in the data plane VCN 718. The control plane VCN 716 and the data plane VCN 718 can be included in a service tenant 719 (e.g., service tenant 419 of FIG. 4).

[0105] The control plane VCN 716 can include a control plane DMZ layer 720 (e.g., the control plane DMZ layer 420 in FIG. 4) that can include an LB subnet 722 (e.g., the LB subnet 422 in FIG. 4), a control plane application layer 724 (e.g., the control plane application layer 424 in FIG. 4) that can include an application subnet 726 (e.g., the application subnet 426 in FIG. 4), and a control plane data layer 728 (e.g., the control plane data layer 428 in FIG. 4) that can include a DB subnet 730 (e.g., the DB subnet 630 in FIG. 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, can be communicatively coupled to an Internet gateway 734 (e.g., the Internet gateway 434 in FIG. 4) that can be included in the control plane VCN 716, 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 a service gateway 736 (e.g., the service gateway in FIG. 4) and a network address translation (NAT) gateway 738 (e.g., the NAT gateway 438 in FIG. 4). The control plane VCN 716 can include the service gateway 736 and the NAT gateway 738.

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

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

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

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

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

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

[0112] In certain embodiments, the IaaS systems described herein can include a suite of application, middleware, and database service offerings provided 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) provided by the present assignee.

[0113] FIG. 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 device 804 that communicates with a number of peripheral subsystems via a bus subsystem 802. These peripheral subsystems can include a processing acceleration device 806, an I / O subsystem 808, a memory subsystem 818, and a communication subsystem 824. Memory subsystem 818 includes a tangible computer-readable storage medium 822 and system memory 810.

[0114] The bus subsystem 802 provides a mechanism that enables the various components and subsystems of the computer system 800 to communicate with each other as intended. Although 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, a peripheral bus, and a local bus, using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. This can be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0115] The processing device 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 device 804. These processors may include a single-core processor or a multi-core processor. In certain embodiments, the processing device 804 may be implemented as one or more independent processing devices 832 and / or 834 having a single-core processor or a multi-core processor included in each processing device. In other embodiments, the processing device 804 may be implemented as a quad-core processing device formed by integrating two dual-core processors on a single chip.

[0116] In various embodiments, the processing device 804 can execute various programs in response to program code and can maintain multiple concurrent programs or processes. At any time, some or all of the program code to be executed can exist in the processor 804 and / or the memory subsystem 818. Through appropriate programming, the processor 804 can provide the various functions described above. The computer system 800 can further include a processing acceleration device 806 that can include a digital signal processor (DSP), an application specific processor, and the like.

[0117] The I / O subsystem 808 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen incorporated in a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices can include, for example, a motion sensing and / or gesture recognition device such as a Microsoft Kinect (registered trademark) motion sensor, and a user can control and interact with an input device such as a Microsoft Xbox (registered trademark) 360 game controller through a natural user interface using gestures and voice commands. User interface input devices can also include an eye gesture recognition device such as a Google Glass (registered trademark) blink detector that detects a user's eye activity (e.g., a "blink" during photo taking and / or menu selection) and converts the eye gesture into an input to the input device (e.g., Google Glass (registered trademark)). Further, the user interface input device may include a voice recognition sensing device that enables a user to interact with a voice recognition system (e.g., a Siri (registered trademark) navigator) through voice commands.

[0118] The user interface input device may include, but is not limited to, a three-dimensional (3D) mouse, a joystick or a pointing stick, a game pad and a graphic tablet, and audio / visual devices such as a speaker, a digital camera, a digital video camera, a portable media player, a web camera, an image scanner, a fingerprint scanner, a barcode reader, a 3D scanner, a 3D printer, a laser range finder, and a gaze tracking device. Further, the user interface input device may include, for example, a medical image input device such as computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasonic examination devices. The user interface input device may also include, for example, an audio input device such as a MIDI keyboard, a digital musical instrument, etc.

[0119] The user interface output device may include a non-visual display such as a display subsystem, an indicator light, or an audio output device. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, etc. Generally, the use of the term "output device" is intended to include any possible type of device and mechanism for outputting information from the computer system 800 to the user or another computer. For example, the user interface output device includes, but is not limited to, monitors, printers, speakers, headphones, automotive navigation systems, plotters, voice output devices, and modems, and various display devices for visually transmitting text, graphics, and audio / video information.

[0120] The computer system 800 can include a storage subsystem 818 having software elements shown as currently disposed within the system memory 810. The system memory 810 can store program instructions loadable and executable on the processing device 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), flash memory, etc.). RAM is typically immediately accessible to the processing device 804 and / or contains data and / or program modules that are currently being operated on and executed by the processing device 804. In some implementations, the system memory 810 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) that includes basic routines useful for transferring information between elements within the computer system 800, such as during startup, may typically be stored in the ROM. By way of non-limiting example, the system memory 810 also shows an application program 812 that may include a client application, a web browser, a middle-tier application, a relational database management system (RDBMS), etc., program data 814, and an operating system 816. By way of example, the operating system 816 may include various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux operating systems, various commercially available UNIX (registered trademark) or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems such as iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 8OS, and Palm (registered trademark) OS operating systems.

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

[0123] The memory subsystem 800 may also include a computer-readable storage medium reader 820 that can be further connected to a 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 persistently containing, storing, transmitting, and acquiring computer-readable information, in addition to remote, local, fixed, and / or removable storage devices.

[0124] The computer-readable storage medium 822 that includes code or a portion of the code can include any suitable medium known or used in the art, including storage media and communication media implemented by any method or technology for storing and / or transmitting information, such as volatile and non-volatile, removable and non-removable media, but not limited thereto. This can 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 can also include intangible computer-readable media such as data signals, data transmissions, or any other medium that can be used to transmit desired information and can be accessed by the computing system 800.

[0125] As an example, the computer-readable storage medium 822 can include a hard disk drive that reads from or writes to a removable non-volatile magnetic medium, a magnetic disk drive that reads from or writes to a removable non-volatile magnetic disk, and an optical disk drive that reads from or writes to a removable non-volatile optical disk such as a CDROM, DVD, Blu-Ray (registered trademark) disk, or other optical medium. The computer-readable storage medium 822 may include, but is not limited to, a Zip (registered trademark) drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, etc. The computer-readable storage medium 822 may also include a solid state drive (SSD) based on non-volatile memory such as a flash memory-based SSD, an enterprise flash drive, a solid state ROM, etc., an SSD based on volatile memory such as solid state RAM, dynamic RAM, static RAM, etc., a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD that combines DRAM and flash memory-based SSDs. Disk drives and the computer-readable media associated with them can provide non-volatile storage of 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 can include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using advanced data network technologies such as cellular phone technology, 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution)), WiFi (IEEE802.11 family standards, or other mobile communication technologies, or any combination thereof), a Global Positioning System (GPS) receiver component, and / or other components. In some embodiments, the communication subsystem 824 can provide a wired network connection (e.g., Ethernet) in addition to, or instead of, the wireless interface.

[0127] In some embodiments, the communication subsystem 824 can 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]

[0129] As an example, the communication subsystem 824 can be configured to receive the data feed 826 in real time from users of other communication services such as social networks and / or web feeds such as Twitter (registered trademark) feeds, Facebook (registered trademark) updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.Furthermore, 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 essentially unlimited with no explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0130] 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 computer system 800.

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

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

[0133] Although specific embodiments have been described, various modifications, changes, alternative structures, and equivalents are also included within the scope of the present disclosure. Embodiments are not limited to operating within a specific particular data processing environment and can operate freely within multiple data processing environments. Further, although embodiments have been described using a specific series of transactions and steps, it will be apparent to one of ordinary skill in the art that the scope of the present disclosure is not limited to the series of transactions and steps described. The various features and aspects of the above-described embodiments 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 only hardware, or only software, or combinations thereof. The various processes described herein can be implemented on the same processor or by arbitrarily combining different processors. Thus, if a component or module is described as being configured to perform a particular operation, such a configuration can be achieved, for example, by designing an electronic circuit that performs 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 can use different techniques, or pairs of the same process can use different techniques at different times.

[0135] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. However, it is obvious that additions, subtractions, deletions, and other modifications and changes can be made without departing from the broader spirit and scope set forth in the claims. Thus, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are included within the scope of the following claims.

[0136] In the context of describing the disclosed embodiments (in particular, in the context of the following claims), the use of the terms "a", "an", "the", and similar referents should be construed to cover both the singular and the plural forms, unless otherwise indicated herein or clearly contradicted by the context. The terms "comprising", "having", "including", and "containing" should be construed as open-ended terms (i.e., meaning "including, but not limited to") unless otherwise noted. The term "connected" should be construed as being partially or wholly internally contained, attached, or coupled, even if something intervenes. The recitation of a range of values herein is merely intended to serve as a shorthand method of referring individually to each separate value within the range, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by the context. The use of any examples, or exemplary language (e.g., "such as") provided herein is merely for the purpose of better illustrating the embodiments and does not impose a limitation on the scope of the disclosure unless otherwise claimed. No language in this specification should be construed as indicating that any non-claimed element is essential to the practice of the disclosure.

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

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

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

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

Claims

1. An e-mail message delivery system that provides an e-mail delivery service includes steps of executing a message transfer agent (MTA) and a proxy server, The MTA includes a step of selecting a first e-mail message to be processed from a message queue, where the message queue includes a plurality of e-mail messages received from a plurality of senders, and the plurality of senders correspond to a plurality of subscribers of the e-mail delivery service. The MTA includes a step of determining a sender associated with the first e-mail message. The MTA includes a step of determining a recipient of the first e-mail message. The MTA includes a step of identifying a plurality of source Internet Protocol (IP) addresses including an IP address that can be used as a source IP address of the first e-mail message based on the sender determined for the first e-mail message. The MTA includes a step of selecting a specific source IP address from the plurality of source IP addresses. The MTA includes a step of determining a destination IP address of the recipient of the e-mail message. The MTA includes a step of identifying a specific proxy server configured to handle the selected specific source IP address from a set of one or more proxy servers. The MTA includes a step of communicating information including the specific source IP address and the destination IP address to the specific proxy server. The MTA includes a step of transmitting the first e-mail message to the destination IP address using a connection established by the proxy server between the specific source IP address and the destination IP address. A method.

2. The step in which the MTA determines the sender of the first email message includes the step in which the MTA determines a user associated with the sender of the first email message who is permitted to send the first email message, and the user associated with the sender is determined at least partially based on the "From" field of the first email message. The method according to claim 1.

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

4. The step in which the MTA selects the specific source IP address from the plurality of source IP addresses includes the step in which the MTA determines a set of active source IP addresses from the plurality of source IP addresses and the step of selecting the specific source IP address from the set of active source IP addresses. The method according to any one of claims 1 to 3.

5. The method according to claim 4 further includes the step in which the MTA uses a selection technique for selecting the specific source IP address from the set of active source IP addresses.

6. A first set of the plurality of source IP addresses of the sender is assigned to a first proxy server within the set of proxy servers, and a second set of the plurality of source IP addresses of the sender is assigned to a second proxy server within the set of proxy servers. The method according to any one of claims 1 to 5.

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

8. The step in which the MTA identifies a subset of email messages from the plurality of email messages associated with the sender, The step in which the MTA uses the connection established by the proxy server between the specific source IP address and the destination IP address to send the subset of email messages to the destination IP address. The method according to any one of claims 1 to 7 further includes this step.

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

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

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

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

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

14. The system according to claim 13, wherein the MTA selecting the 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 the specific source IP address from the set of active source IP addresses.

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

16. The system according to any one of claims 13 to 15, wherein a first proxy server within the set of proxy servers is configured to handle a set of source IP addresses, a first source IP address within the set is associated with a first sender among the plurality of senders, a second source IP address within the set is 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 transmitting the first email message to the destination IP address includes receiving, from the proxy server, a message indicating that the connection between the specific source IP address and the destination IP address has been successfully established by the proxy server.

18. A program for causing a computer to execute the method according to any one of claims 1 to 12.

Images