Encrypted end-to-end email delivery between secure email clusters

Abstract

The described systems and procedures enable seamless end-to-end email delivery between secure email clusters without requiring prior sharing of encryption keys or protocol configurations. The solution can receive a request to deliver an email to a recipient, identified by the recipient's domain. The solution can send an initial query to a Domain Name Service (DNS) to retrieve one or more records corresponding to the recipient's domain. The one or more records can identify a key service. In response to a second query, the solution can obtain a key from the key service to encrypt the email. The solution can then encrypt at least a portion of the email based on the key and deliver the encrypted email to the recipient.

Description

[0001] This disclosure generally relates to systems and methods for providing secure end-to-end email delivery, including, but not limited to, end-to-end delivery of seamlessly encrypted emails.

[0002] Businesses, such as corporations, organizations, or corporations, may support email systems to provide email services to their users. These systems may incorporate different architectures, configurations, settings, and protocols depending on preference and design. Email delivery between different businesses may utilize different email infrastructures, which may interoperate to provide services to users.

[0003] Sending emails securely from a sender to a recipient can be challenging. Unlike other messaging solutions, emails can route messages through email servers such as SMTP (Simple Mail Transfer Protocol) servers or MTAs (Mail Transport Agents). SMTP and MTAs, in turn, can communicate with each other across the network and different corporate domains. To ensure secure email communication between a sender and one or more recipients, the systems can share user-generated encryption keys before the email exchange. The systems can also link the encryption / decryption operations with the email client, assuming the sender and recipient have already exchanged encryption keys.The systems can also generate a symmetric key from the sender's inbox password and then send a link to the recipient to access the symmetric key for decryption. However, all of these approaches require additional steps to either exchange encryption keys in advance or negotiate the encryption and decryption protocols in advance, which can lead to challenges and inefficiencies.

[0004] This solution overcomes these challenges by making the encryption / decryption process seamless for end users and completing secure email exchanges without requiring any further user steps to encrypt or decrypt the email. For example, this solution enables seamless end-to-end email delivery between secure corporate email clusters without requiring prior sharing of encryption keys or protocol configurations.

[0005] At least one aspect is directed to a method. The method may include a mail transport agent (MTA) of a sender receiving a request to transmit an email to a recipient. The recipient may be identified by a domain of the recipient. The method may include the sender's MTA sending a first query to a domain name service (DNS) to retrieve one or more records corresponding to the recipient's domain. The one or more records may identify a key service. The method may include the MTA receiving a key to encrypt the email from the key service in response to a second query to the key service. The method may include either the sender or the MTA encrypting at least a portion of the email based on at least the key. The method may include transmitting the encrypted email to the recipient.

[0006] The method may include the sender's MTA intercepting an RCPT_TO command for the email. The intercepted RCPT_TO command may be configured to transmit the first query to the DNS and the second query to the key service. The method may include a record of the one or more records, which may include at least one of: a time-to-live (TTL) value, a class of the record, a type of the record, a priority of the recipient, a weight of the recipient, and a port identifier.

[0007] The method may include, in response to the first query, the MTA receiving from the DNS a first record from the one or more records identifying the key service. The MTA may, in response to the first query, receive a second record from the one or more records identifying a provisioning service. The method may include, in response to the configuration, the MTA identifying a configuration for encrypting the email by the sender. The MTA may, in response to the configuration, send the second query to the key service to request the key.

[0008] The method may include the MTA identifying a configuration for the sender to encrypt the email and the recipient to decrypt the email using the key. The method may include the sender, in response to the configuration, generating the key for a session between the sender and the recipient. The method may include the MTA identifying a configuration for caching the key. The MTA may, in response to the configuration for caching the key, cache the key on a caching server.

[0009] The method may include determining, based on a configuration of a delivery service, that a location to encrypt the email is either the sender or the MTA, and encrypting the at least one portion of the email by the sender or the MTA in response to the determined location. The method may include determining, based on a configuration of a delivery service, that a hash value should be included in the email. The MTA may include, in response to the configuration, the hash value in a header of the email to be transmitted.

[0010] The method may include the sender's DNS being configured to receive from a second DNS of the recipient a first record of the one or more records corresponding to the recipient's domain and transmit to the second DNS a second record of the one or more records corresponding to a second domain of the sender.

[0011] At least one aspect is directed to a system. The system may include at least one processor coupled to a data store. The at least one processor may be configured to receive a request to transmit an email to a recipient identified by a recipient's domain. The at least one processor may be configured to send a first query to a Domain Name Service (DNS) to retrieve one or more records corresponding to the recipient's domain, wherein the one or more records identify a key service. The at least one processor may be configured to receive a key for encrypting the email from the key service in response to a second query to the key service. The at least one processor may be configured to encrypt at least a portion of the email based at least on the key.The at least one processor may be configured to transmit the encrypted email to the recipient.

[0012] The system may include at least one processor configured to intercept an RCPT_TO command for the email. The intercepted RCPT_TO command may be configured to transmit the first request to the DNS and the second request to the key service. The one or more records may include at least one of: a time-to-live (TTL) value, a class of the record, a type of the record, a priority of the recipient, a weight of the recipient, and a port identifier.

[0013] The system may include at least one processor configured to receive, in response to the first query from the DNS, a first record of the one or more records identifying the key service. The at least one processor may receive, in response to the first query, a second record of the one or more records identifying a provisioning service. The system may include the at least one processor configured to identify a configuration for encrypting the email by a sender of the email and, in response to the configuration, transmit the second query to the key service to request the key.

[0014] The system may include at least one processor configured to identify a configuration for encrypting the email by a sender of the email and for decrypting the email by the recipient using the key. The at least one processor may be configured to generate the key for a session between the sender and the recipient in response to the configuration. The at least one processor may be configured to identify a configuration for caching the key and, in response to the configuration, to cache the key on a cache server.

[0015] The system may include at least one processor configured to determine, according to a configuration of a delivery service, that the location to encrypt the email is either the sender or the MTA. The at least one processor may be configured to encrypt the at least one portion of the email by the sender or the MTA, either by a sender of the email or by a mail transport agent (MTA) responsive to the determined location. The at least one processor may be configured to determine, based on a configuration of a delivery service, that a hash value should be included in the email and, in response to the configuration, to insert the hash value into a header of the email to be transmitted.

[0016] At least one aspect is directed to a non-transitory computer-readable medium storing instructions that, when executed by at least one processor of a service, cause the at least one processor to receive a request to transmit an email to a recipient identified by a domain of the recipient. The instructions, when executed, may cause the at least one processor to transmit a first query to a Domain Name Service (DNS) to retrieve one or more records corresponding to the domain of the recipient. The one or more records may identify a key service. The instructions, when executed, may cause the at least one processor to receive from the key service, in response to a second query to the key service, a key to encrypt the email.The instructions, when executed, may cause the at least one processor to encrypt at least a portion of the email based at least on the key. The instructions, when executed, may cause the at least one processor to transmit the encrypted email to the recipient.

[0017] According to one aspect, a method is provided comprising: Receipt of a request to transmit an email to a recipient identified by a recipient domain by a sender's Mail Transport Agent (MTA); transmitting, by the sender's MTA, a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Receiving a key to encrypt the email by the MTA from the key service in response to a second challenge transmitted to the key service using the RCPT_TO command; Encryption of at least one section of the email by the sender or the MTA based on at least the key; and Transferring the encrypted email to the recipient.

[0018] Advantageously, the method further comprises: The sender's MTA intercepts the RCPT_TO command for the email and, in response to the intercepted RCTP_TO command, transmits the first query to the DNS and the second query to the key service. Advantageously, a data record of the one or more data records comprises at least one of: a time-to-live (TTL) value, a class of the data record, a type of the data record, a priority of the receiver, a weight of the receiver, and a port identifier.

[0019] Advantageously, the method further comprises: Receiving, by the MTA, from the DNS in response to the first query, a first record of the one or more records identifying the key service; and Receiving, by the MTA, a second set of records from the one or more records identifying a provisioning service in response to the first query.

[0020] Advantageously, the method further comprises: Identifying a configuration for encrypting the email by the sender through the MTA; and The MTA transmits the second challenge to the key service in response to the configuration, with the second challenge requesting the key.

[0021] Advantageously, the method further comprises: Identifying a configuration for encrypting the email by the sender and decrypting the email by the recipient using the key by the MTA; and Generation of the key for a session between the sender and the receiver by the sender in response to the configuration.

[0022] Advantageously, the method further comprises: Identifying a configuration for caching the key by the MTA; and Caching the key on a cache server by the MTA in response to the key caching configuration.

[0023] Advantageously, the method also comprises Determining, according to a configuration of a provisioning service, that a location to encrypt the email is one of the sender and the MTA; and Encryption of at least one portion of the email by the sender or the MTA in response to the determined location.

[0024] Advantageously, the method further comprises: Determining, based on a configuration of a provisioning service, that a hash value should be included in the email; and Insertion of the hash value into a header of the email to be transmitted by the MTA in response to the configuration.

[0025] Advantageously, the DNS corresponds to the sender and is configured to receive from a second DNS of the recipient a first record of the one or more records corresponding to the domain of the recipient and to transmit to the second DNS a second record of the one or more records corresponding to a second domain of the sender.

[0026] According to one aspect, a system is provided comprising: at least one processor coupled to a data memory and configured to: to receive a request to transmit an email to a recipient identified by a recipient's domain; transmitting a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Received from the key service in response to a second request to the key service, using the RCPT_TO command, for a key to encrypt the email; Encrypting at least a portion of the email based on the key; and Transferring the encrypted email to the recipient.

[0027] Advantageously, the at least one processor is configured to intercept the RCPT_TO command for the email and, in response to the intercepted RCPT_TO command, transmit the first query to the DNS and the second query to the key service.

[0028] Advantageously, the one or more data records comprise at least one of: a time-to-live (TTL) value, a class of the data record, a type of the data record, a priority of the receiver, a weight of the receiver, and a port identifier.

[0029] Advantageously, the at least one processor is configured to: in response to the first query, receive from the DNS a first record of the one or more records identifying the key service; and in response to the first query, receive a second record from the one or more records that identifies a provisioning service.

[0030] Advantageously, the at least one processor is configured to: to identify an email encryption configuration by an email sender; and in response to the configuration, send the second query to the key service, where the second query requests the key.

[0031] Advantageously, the at least one processor is configured to: to identify a configuration for encrypting the email by a sender of the email and for decrypting the email by the recipient using the key; and in response to the configuration, to generate the key for a session between the sender and the receiver.

[0032] Advantageously, the at least one processor is configured to: identify a configuration for caching the key; and in response to the configuration, to store the key on a cache server.

[0033] Advantageously, the at least one processor is configured to: to determine, according to a configuration of a provisioning service, that a location to encrypt the email is either the sender or the MTA; and Encrypting at least one portion of the email by the sender or a mail transport agent (MTA) in response to the determined location.

[0034] Advantageously, the at least one processor is configured to: determine, based on a configuration of a provisioning service, that a hash value should be included in the email; and In response to the configuration, insert the hash value into a header of the email to be transmitted.

[0035] According to one aspect, a non-transitory computer-readable medium is provided that stores instructions that, when executed by at least one processor of a service, cause the at least one processor to: Receiving a request to transmit an email to a recipient identified by a recipient's domain; transmitting a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Received from the key service in response to a second request for a key to encrypt the email, transmitted to the key service using the RCPT_TO command; Encrypting at least a portion of the email based on the key; and Transferring the encrypted email to the recipient.

[0036] These and other aspects and features of the present embodiments will become apparent to those skilled in the art upon review of the following description of certain embodiments in conjunction with the accompanying figures. Fig. Figure 1 is a block diagram of a system for providing seamless end-to-end email delivery across secure email clusters without prior key sharing or protocol configurations. Fig. Figure 2 is a block diagram illustrating an architecture for a computer system that may be used to implement elements of the systems and methods described and illustrated herein. Fig. Figure 3 is a flowchart of a method for setting up a system and providing seamless end-to-end email encryption and delivery between secure email clusters. Fig. Figure 4 illustrates a flowchart of a method for providing seamless end-to-end email encryption and delivery between secure email clusters without prior sharing of keys or protocol configurations. DESCRIPTION IN DETAIL

[0037] The present embodiments will now be described in more detail with reference to the drawings, which serve to illustrate the embodiments and to enable those skilled in the art to practice the embodiments and alternatives that will be apparent to those skilled in the art. The following figures and examples are not intended to limit the scope of the present embodiments to a single embodiment, but other embodiments are possible by replacing some or all of the elements described or depicted, or those that will be apparent to a person of ordinary skill in the art. Certain elements of the present embodiments may be implemented partially or entirely using known components.Only those portions of such known components necessary for understanding the present embodiments are described, and detailed descriptions of other portions of such known components are omitted so as not to obscure the present embodiments. The embodiments described in the illustrated contexts are not limited to these. For example, embodiments described as being implemented in software are not limited to such implementation alone, but may include embodiments implemented in hardware, or combinations of software and hardware, and vice versa, as would be apparent to one skilled in the art, unless otherwise stated herein.In the present description, an embodiment showing a single component should not be considered limiting; rather, the present disclosure is intended to encompass other embodiments incorporating a plurality of the same component, and vice versa, unless expressly stated otherwise herein. Furthermore, applicants do not intend to attribute any unusual or special meaning to any term in the description or claims unless expressly stated as such. Further, the present embodiments include present and future known equivalents to the known components referenced herein for purposes of illustration.

[0038] Providing secure email transmission between organizations can be challenging. Because different organizations may employ customized or personalized email systems (e.g., personalized servers, policies, configurations, or encryption / decryption techniques), exchanging emails between such disparate corporate domains can be challenging. To ensure secure client communication, different email systems may share user-generated encryption keys prior to email exchange. Sometimes, email systems may rely on the email client to resolve the encryption and decryption operations, assuming that the sender and recipient have already exchanged encryption keys.In some cases, email systems can generate a symmetric key from the sender's inbox password and then send a link to the recipient to access the symmetric decryption key. However, these approaches either require exchanging encryption keys in advance or negotiating the encryption and decryption protocols in advance, which can be difficult under certain conditions and introduce inefficiencies into the system.

[0039] This solution overcomes these challenges by enabling seamless end-to-end email delivery between secure email clusters of different organizations without relying on encryption key sharing or prior protocol configurations.

[0040] Fig. Figure 1 shows an example system 100 for providing seamless end-to-end email delivery across secure email clusters without prior key sharing or protocol configurations. System 100 may include a first entity 102a (e.g., a sender's secure corporate email cluster) communicating with a second entity 102b (e.g., a recipient's secure corporate email cluster) over a network 106. Each of the first unit 102a and the second unit 102b may include one or more Mail Transport Agents (MTAs) 110a or 110b, User Provisioning Services (UPSs) 120a or 120b, Key Services (KSs) 130a or 130b, Domain Name Services (DNSs) 140a or 140b, cache servers 150a or 150b, and user devices 160a or 160b.

[0041] In example system 100, a first entity 102a may include an MTA 110a, a UPS 120a, a key service (KS) 130a, a DNS 140a, a cache server 150a, and a user device 160a. MTA 110a may include one or more encryption functions 116a and SMTP functions 112a, which may include one or more RCPT_TO commands or hooks 114a. Each UPS 120a may include one or more UPS records 122a and configurations (e.g., policies) 124a. Each KS 130a may include one or more KS records 132a and encryption keys 134a. Each DNS 140a may include one or more UPS records 122a and KS records 132a. Each user device 160a may include one or more encryption functions 116a and email applications 162a for generating emails 164a using recipient information 166a.Similarly, a second unit 102b may include an MTA 110b, a UPS 120b, a key service (KS) 130b, a DNS 140b, a cache server 150b, and a user device 160b. MTA 110b may include one or more encryption functions 116b and SMTP functions 112b, which may include one or more RCPT_TO commands or hooks 114b. Each UPS 120b may include one or more UPS records 122b and configurations (e.g., policies) 124b. Each KS 130b may include one or more KS records 132b and encryption keys 134b. Each DNS 140b may include one or more UPS records 122b and KS records 132b. Each user device 160b may include one or more encryption functions 116b and email applications 162b for generating emails 164b using recipient information 166b. The generated emails 164 (e.g.,164a or 164b) may be transmitted over the network 106 between the first unit 102a and the second unit 102b. The system 100 may include features or components as discussed in Request for Comments (RFC) 5322 and RFC 2822 on the Internet Message Format, both of which are incorporated by reference in their entirety and for all purposes.

[0042] Entities 102, including first entity 102a and second entity 102b, may comprise any group or collection of interconnected servers and / or services for providing secure and reliable email communications, e.g., a secure email cluster. An entity 102 may comprise an organization's network or system for enabling email services. Entities 102 may include components such as mail transfer agents 110, also referred to as mail transport agents 110, (e.g., SMTP servers or services), user provisioning services (UPS) 120, query public key (QPK) 130 systems, and domain name systems (DNS) 140, which may cooperate to ensure the confidentiality, integrity, and availability of email messages. Certain data, such as encryption keys 134 or recipient information 166, may be cached on a cache server 150 for improved and efficient access.A unit 102 (e.g., a secure email cluster) may employ or provide various encryption methods or techniques, authentication mechanisms, spam filters, and other security measures. Unit 102 may include measures to protect sensitive data, prevent unauthorized access, and provide email services. Unit 102 may provide features such as high availability, load balancing, redundancy, and scalability.

[0043] Network 106 may include any type of communications network over which two email clusters can exchange emails and data. Network 106 may be a global network of interconnected computers and devices that enables information sharing and communication between various computing devices worldwide. Network 106 may be established over various types of networks, such as local area networks (LANs), wide area networks (WANs), or the Internet. Network 106 may support various communications protocols for email exchange, including Simple Mail Transfer Protocol (SMTP) for transferring messages between mail servers, Internet Protocol (IP) for addressing and forwarding data packets, Transmission Control Protocol (TCP) for reliable and orderly delivery of data, or any other type of protocol.For example, the network 106 may use protocols such as Ethernet for LAN connections, Virtual Private Networks (VPNs) for secure communication over public networks, and Domain Name System (DNS) for resolving domain names into IP addresses.

[0044] The domain can include any portion of an email address (e.g., one or more characters) that represents a specific company responsible for managing email communications for that address. For example, the domain can include a group of characters located after the "@" symbol in an email address that represents a specific organization, institution, or service responsible for managing email communications within that website or domain. The domain can correspond to, refer to, or include a system that provides email services for a particular domain name, such as facilitating the receipt and sending of emails using a particular domain name.

[0045] Mail transport agents (MTAs) 110, also referred to as mail transfer agents 110, including the first MTA 110a and the second MTA 110b, may comprise any combination of hardware and software for facilitating the transmission and delivery of email messages between mail servers, for example, via the SMTP protocol. MTA 110 may be provided as a service (e.g., as functionality in a cloud or VPN) or as a server (e.g., an SMTP server). MTA 110 may include any computer code or function for routing and transferring email messages between different mail servers in an email communication process. MTA 110 may include functionality that enables or supports the transmission and delivery of email messages between mail servers, for example, by leveraging SMTP rules and protocols to facilitate the exchange of emails between different systems.For example, when an email is sent, the sender's MTA 110 can receive the message from the sender's email client and verify the sender's identity through authentication. MTA 110 can then perform spam, virus, and sender reputation checks. MTA 110 can determine the recipient's mail server via DNS and establish an SMTP connection with the recipient's MTA to transfer the email for delivery. The recipient's MTA 110 can, for example, receive the email, perform validation and processing, and store the email in the recipient's mailbox for retrieval by their email client.

[0046] Each MTA 110 may include any number of Simple Mail Transfer Protocol (SMTP) functions 112, including SMPTP functions 112a and SMTP functions 112b. SMTP functions 112 may include functions to initiate the email transfer process, functions to establish a connection with the recipient's mail server, or functions to verify sender and recipient addresses. SMTP functions 112 may include functions to forward the email message, error handling and notification, and to ensure reliable and secure delivery of email messages. SMTP functions 112 may include an RCPT_TO command or a function that can be configured, modified, or hooked (e.g., RCPT_TO command 114) to perform a specific set of tasks.

[0047] The SMTP functions 112 may include a modified or hooked SMTP Hello (HELO) command, which can be used by an SMTP client (e.g., the sender) to initiate a connection with the receiving mail server, specifying its domain name as an argument. The SMTP functions 112 may include a modified or hooked SMTP EHLO command, which may include an extended version of the HELO command that initiates a connection and provides information about the sender's capabilities. For example, the SMTP function 112 containing a HELO or EHLO may be configured to indicate to the user device (160alb) whether the server supports end-to-end email encryption.

[0048] The SMTP functions 112 may include an SMTP DATA function 112, which may be configured to receive emails and headers sent from the user device (e.g., 160a / b). For example, if the user policy (e.g., 124a / b), such as ENCRYPT_LOCATION, is set to "REMOTE," the encryption function 116a or 116 may be executed using the hooked SMTP data function 112. For example, the encryption function 116a may be identified within the SMTP data function 112.

[0049] The RCPT_TO command 114 may include any combination of hardware and software configured to use special (e.g., hooked) queries to DNS 140 and KS 130 to seamlessly enable or encrypt secure end-to-end email delivery. The RCPT_TO command 114 may include a mechanism or feature (e.g., specific instructions, settings, or commands) that allows for customization or interception of the SMTP's RCPT_TO command during the email delivery process. For example, the RCPT_TO command 114 may include or enable modification or analysis of the way the email is processed. The RCPT_TO command 114 may include additional (e.g., customized) logic or instructions that can be implemented before the email server processes the RCPT_TO command and proceeds with the delivery process.

[0050] The RCPT_TO command 114 may include a function (e.g., a command or an instruction) to query a DNS to retrieve service records using, based on, or corresponding to a recipient domain. In response to such a request, the DNS may provide the requested service records. The RCPT_TO command 114 may include the functionality to query the UPS 120 to determine, based on configurations or policies 124, whether to acquire, use, or generate an encryption key 134 (e.g., a symmetric per-session encryption key or a recipient public key). The RCPT_TO command 114 may include the functionality to verify a particular encryption strategy against UPS records 122 or KS records 132 of a particular recipient. The RCPT_TO command 114 may query recipient information 116 (e.g.,Recipient's domain name, IP address, or other user-specific information), UPS records 122, KS records 132, or encryption keys 134 of a recipient stored in KS 130 or cached in cache server 150.

[0051] The RCPT_TO command 114 can contain all the functionality of an RCPT_TO command of the SMTP protocol. For example, the RCPT_TO command 114 can contain a command used during the email delivery process to specify the recipient(s) of an email message. When a sender initiates an email transmission, the RCPT_TO command 114 can be used to specify the destination email address(es) to which the email should be delivered. Multiple RCPT_TO commands 114 (e.g., RCPT_TO hooks) can be used in a single email transaction to specify multiple recipients.

[0052] For example, the RCPT_TO command 114 can be used to query DNS 140 to retrieve UPS records 122 and KS records 132 (e.g., QPK records). The query UPS endpoints can be parsed from the DNS response 140 to query UPS 120 to retrieve user policies 124 and KS 130 (e.g., QPK) to retrieve public keys 134. The RCPT_TO command 114 can then determine, depending on the policy 124, where the actual encryption function 116 should be executed, e.g., whether the encryption function 116 should be executed in the MTA 110 or in the user device 160.

[0053] Encryption functions 116, including encryption functions 116a and 116b, may include any combination of hardware and software that encrypts at least a portion of an email. Encryption function 116 may include functionality that applies cryptographic techniques to secure the contents of an email message. Encryption function 116 may take a plaintext email as input and convert it into an encrypted form using encryption algorithms and keys. Encryption function 116 may convert an original message into an unreadable format that can only be decrypted with the appropriate decryption key:

[0054] The encryption function 116 may use or provide asymmetric encryption, also known as public-key encryption, in which a pair of mathematically related keys, a public key and a private key, can be used to encrypt or decrypt the email. For example, a sender may use the recipient's public key to encrypt the email and ensure that only the recipient with the corresponding private key can decrypt and read the message. The encryption function 116 may use, utilize, or provide symmetric encryption, in which a shared secret key can be used to encrypt and decrypt the email. For example, the encryption function 116 may use an Advanced Encryption Standard (AES) algorithm with a shared key to encrypt the email.

[0055] When a user device 160 decides to send an email to a recipient, the user device 160 may begin an SMTP conversation with MTA 110. The first command in the conversation may include an EHLO SMTP function 112, which may initiate the execution of the EHLO or HELO hooked function to send the following response to the user device 160: EHLO semc.mail.company.com 250-semc.mail.company.com says hello 250-ENHANCED STATUS CODES 250-PIPELINING 250-CHUNKING 250-E2ENCRYPT (RSAIPUBLIC_KEY) 250-E2ENCRYPT_PUBLICKEY_CACHE 250-E2ENCRYPT_DIGEST 250-CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED

[0056] For example, the user device's responses may include: E2ENCRYPT, E2ENCRYPT_PUBLICKEY_CACHE, E2ENCRYPT_DIGEST, and CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED. This may indicate that the server supports end-to-end email encryption, can cache the recipient's public keys, can perform message digest functions if the sender shares their private key, and can also retrieve the recipient's user policy using DNS queries to retrieve SRV records for the recipient's domain. If the server does not respond with these details, the user device 160 may determine that the server is unable to perform end-to-end email encryption.

[0057] For example, a user device 160 may then initiate an RCPT_TO command 114, which may trigger an RCPT_TO hook (e.g., 112 or 114), which may implement a DNS query 140 on the sender's email server or MTA 110 to retrieve UPS endpoint details by querying UPS records 122, which may return a DNS SRV record. The DNS SRV record may contain, for example: _ups._http.ups.semc.company.com 86400 IN SRV 5 5 443 ups.semc.company.com

[0058] From the DNS query response, the RCPT_TO hook (e.g., 112 or 114) can read the endpoint for UPS 120. The following attributes can be parsed from the above response: service_name=ups protocol=http name=ups.semc.company.com TTL=86400 class=IN typ=SRV priority=5 weight=5 port=443 target=ups.semc.company.de

[0059] The RCPT_TO hook (e.g., 112 or 114) can then use this retrieved endpoint to make a network call to the UPS 120. Through the network call, the RCPT_TO hook (e.g., 112 or 114) can retrieve recipient policy information 124; such as: ENCRYPT_LOCATION (REMOTE / SENDER) ENCRYPT_CONTENT (BODY-ONLY, SUBJECT-BODY, ATTACHMENT-ONLY, BODY-ATTACHMENT, SUBJECT-BODY-ATTACHMENT, NONE) ENCRYPT_STRATEGY (symmetric / asymmetric) DIGITAL_SIGNING (true / false) CACHING_STRATEGY (whether user policies and keys should be cached for future use) CACING_TTL DECRYPT_LOCATION (REMOTE / RECIPIENT)

[0060] An RCPT_TO hook (e.g., 112 or 114) can make a network call to retrieve the sender's policies from the UPS 120, as well as the sender's and receiver's public encryption keys. The RCPT_TO hook can first locate the receivers, e.g., the KS 130. To do this, the RCPT_TO hook 112 or 114 can perform a DNS query to retrieve SRV records 132 for the receiver domain. This can be the second query, although all SRV records (e.g., from the UPS 120 and the KS 130) can be retrieved with a single DNS query. The queried KS record 132 can contain the following information:_qpk._http.qpk.semc.company.com 86400 IN SRV 5 5 443 qpk.semc.company.com

[0061] From this DNS query response, the RCPT__TO hook 112 or 114 can read the endpoint for the KS 130 to establish a connection by parsing the following attributes from the response: service_name=qpk protocol-http name=qpk.semc.company.com TTL=86400 class=IN type=SRV priority=5 weight=5 port=443 target=qpk.semc.company.com

[0062] The RCPT_TO command 114 (e.g., RCPT_TO hook 112 or 114) can use the retrieved endpoint to make network calls to KS 130. For example, the RCPT_TO hook 112 or 114 can call both the sender KS 130a and the receiver KS (e.g., 130b) to retrieve both the sender's and receiver's public keys. For example, an RCPT_TO hook (e.g., 112 or 114) can decide to cache the sender's and receiver's public keys (134a / b) retrieved from QPKS (130a / b) in the cache server (150a), depending on the user policy CACHING_STRATEGY. For example, cached keys can reduce future network calls to retrieve sender and receiver public keys (134a / b). Subsequent public sender and recipient keys (134a / b) can be retrieved from the cache server (150a) until CACHE_TTL expires for these cache key entries. Once the RCPT_TO hook (e.g.112a or 114a) has retrieved the sender and recipient public keys (134a / b) from the QPKS (130a / b), the RCPT_TO hook can decide where the encryption function should be executed. If the user policy (124b) retrieved from the UPS (120b) specifies ENCRYPT_LOCATION=REMOTE, then the encryption function (116a) can be executed within the MTA (110a). If the user policy (124b) retrieved from the UPS (120b) specifies ENCRYPT_LOCATION=SENDER, the encryption function (116a) can be executed within the user device (160a).

[0063] User Provisioning Services (UPS) 120, including UPS 120a and UPS 120b, may comprise any combination of hardware and software (e.g., a system or platform) that enables centralized management and provisioning of user accounts, roles, and permissions within an organization's network or system. UPS 120 may be deployed as a service (e.g., in a cloud or VPN) or as a server. UPS 120 may include, utilize, or provide centralized control over user access, authentication, and authorization processes. UPS 120 may facilitate the creation, modification, and deletion of user accounts and enable administrators to manage user permissions, roles, and privileges.UPS 120 can be integrated with various identity management systems and directories to streamline user provisioning workflows and ensure that users have appropriate access to resources based on their roles and responsibilities.

[0064] UPS records 122, also referred to as service records for user provisioning services (e.g., including UPS records 122a and UPS records 122b), may include any type and form of records or information that may be used to facilitate the delivery of an email 164. The provisioning service may include a service, such as a computer program or function, that provides UPS records 122 and / or key service records 132 in response to requests (e.g., RCPT_TO requests). For example, a UPS record 122 (e.g., an SRV record of the UPS 120) may include DNS-related data that may be used to provide information about endpoints of the UPS for email delivery purposes.For example, a UPS record 122 may specify the location and configuration details of UPS 120 servers so that email clients and servers can recognize and connect to the designated UPS 120 for managing user accounts. An example UPS record 122 may be "_ups._http.ups.semc.company.com 86400 IN SRV 5 5 443 ups.semc.company.com," which may indicate that the UPS 120 for the domain "semc.company.com" can be reached via the host "ups.semc.company.com" on port 443. The priority and weight values ​​of the UPS record 122 may both be set to "5" and used to determine the order of preference among multiple UPS servers 120. The UPS record 122 may contain a TTL (Time-to-live) value (e.g., a parameter for determining the time that data such as a record, a service, or an encryption key can be on the network before being discarded), a class of the record (e.g.,the protocol family to which the record belongs), a type of record (e.g., A vs. AAAA record, mail exchange, or canonical name), a priority of the recipient, a weight of the recipient, and a port identifier.

[0065] Configurations 124 (e.g., policies), including configurations / policies 124a and configurations / policies 124b, may contain any policies or rules to define or prescribe the handling of emails or services, such as security measures, operating procedures, and acceptable practices for handling emails 164 within a facility 102. Configurations 124 may contain rules and policies for handling the encryption / decryption of emails 164 according to or based on asymmetric and symmetric encryption. For example, a configuration 124 may prescribe that a particular type of encryption / decryption be used for a particular recipient (e.g., symmetric encryption or asymmetric encryption).For example, configuration 124 may be for asymmetric encryption and specify information or data for accessing a pair of mathematically related keys (public and private) that can be used to implement the encryption. For example, configuration 124 may be for symmetric encryption and reference or specify information or data for accessing a specific session-based symmetric key to be used by both the sender and the recipient for email 164. Configurations 124 may define or prescribe the use of specific encryption algorithms (e.g., RSA, AES), key lengths, and certificate management. Configurations 124 may define or prescribe the choice of encryption location for a specific recipient (e.g., at the sender or at the MTA 110).

[0066] Key Services (KS) 130, including KS 130a and KS 130b, may include any combination of hardware and software, e.g., centralized or distributed services or servers, to store and provide KS records 132 or encryption keys 134 for sending a specific email 164. KS 130, such as a Query Public Key (QPK), may include a component that provides Key Service (KS) records 132 and encryption keys 134 to specific users (e.g., recipients) within an email system. For example, when queried by an RCPT_TO command 114 or other mechanism, the QPK service may retrieve the KS records 132, which may contain information about the encryption keys 134 associated with individual users. These encryption keys 134 can be used for various purposes, e.g. to secure email communication through asymmetric encryption.

[0067] KS records 132, also referred to as encryption key service records (e.g., including KS records 132a and KS records 132b), may contain any type and form of information or data to facilitate the encryption of an email 164. The KS record 132 may be accessed in response to a query from an RCPT_TO command 114 and may contain information about the location and configuration of a KS 130 for encryption purposes within an email infrastructure. An example of a KS record 132 might be: "_qpk -tcp.qpk.semc.company.com 86400 IN SRV 5 5 5001 qpk.semc.company.com", which might indicate that the KS 130 for the domain "semc.company.com" is reachable under the host name "qpk.semc.company.com" via TCP on port 5001.The priority and weight values ​​of the KS record 132 can both be set to "5" to specify or specify the order of preference and load balancing among multiple KS 130 servers or services. For example, a KS record 132 can contain or specify a TTL value (e.g., a parameter for determining the time that data such as a record, service, or encryption key can be on the network before it is discarded), a class of the record (e.g., the protocol family to which the record belongs), a type of record (e.g., A vs. AAAA record, mail exchange, or canonical name), a recipient priority, a recipient weight, and a port identifier.

[0068] The encryption keys 134, including encryption keys 134a and 134b, may contain any cryptographic values ​​or data that can be used to secure and protect data (e.g., email 164) during the encryption and decryption process. The encryption key 134 may contain an asymmetric key pair, which may consist of a public and a private key. The public key may be freely shared on the network and used by the sender to encrypt data. The corresponding private key may be kept confidential by the recipient and may be used by the recipient to decrypt the data. The encryption code 134 may be a symmetric encryption code.For example, the encryption key 134 may contain a single secret key that can be used for both encryption and decryption and can be shared by the sender and receiver. With AES encryption, for example, a session-based symmetric key can be generated for a specific email communication session between a sender and a receiver. This session-based key is used to encrypt and decrypt the messages exchanged during that session, ensuring secure and efficient communication between the two parties. The encryption keys 134 may include hashes, e.g., hash values ​​encrypted with hash keys, which can be inserted into the header of the email 164 to be transmitted.

[0069] Domain Name Service (DNS) 140, including DNS 140a and DNS 140b, may comprise a hierarchical naming system server or service that translates domain names into IP addresses so that users can access specific network destinations (e.g., email recipient devices, websites, and services) using human-readable domain names instead of numeric IP addresses. DNS 140 may be configured to contain and provide UPS records 122 and KS records 132. DNS 140 may act as a central information repository that enables the resolution of domain names to their corresponding IP addresses for users of device 102 (e.g., senders or recipients of emails 164).

[0070] The DNS 140 server may be configured to store and provide (e.g., upon query from an RCPT_TO command 114) UPS records 122, which may contain details about the location and configuration of UPS 120 servers for user provisioning purposes. DNS 140 may be configured to store and provide (e.g., upon query from an RCPT_TO command 114) KS records 132, which may contain information about the location and configuration of the KS 130 for encryption-related operations. When queried, e.g., by an RCPT_TO hook, DNS 140 may respond by providing the requested service records (e.g., the UPS records 122 and KS records 132).

[0071] The cache server 150, including cache server 150a and cache server 150b, may be any server that stores or stores frequently retrieved data or content in its data store for rapid retrieval. The cache server 150 may act as an intermediary between the clients and the original data source, such as an MTA 110 that provides email services to users. The cache server 150 may store encryption keys 134, KS records 132, and UPS records 122. When a user requests information (e.g., the RCPT_TO command 114 requests an encryption key 134), the cache server 150 may check whether it has a cached copy of the requested encryption key 134. If present, the cache server 150 may forward the requested encryption key 134 to the requester or the intended recipient.

[0072] User devices 160, including user device 160a and user device 160b, may include any network device that a user (e.g., the sender of the email) can use to compose and send the email 164 to the recipient. The user device 160 may be a smartphone, a computer (e.g., a laptop or workstation), a tablet, or other computing device. The user device 160 may include and provide (e.g., run or launch) an email application 162, e.g., an email client. The user device 160 may include an encryption function 166 to provide encryption functions and may include or store recipient information 166 (e.g., the recipient's domain name, the recipient's subdomain, the IP address, the MAC address, or other information or data to identify the recipient). Recipient information 166 may, for example, be a recipient's email address, such as "user@recipient.com", which may contain a local component of the email address (e.g., the "user") and a domain (e.g., "recipient.com").

[0073] Fig. 2 shows a block diagram of an example computer system 200, which may also be referred to as computer system 200. Computer system 200 may include or be used to implement any computations or processing (e.g., instructions, protocols, or data processing) described herein. Computer system 200 may be included and executed in any device (e.g., server) or service of a first entity 102a or a second entity 102b. Computer system 200 may be used to operate an MTA 110, a UPS 120, a KS 130, a DNS 140, a cache server 150, or a user device 160, and may implement any functionality described herein.

[0074] The computer system 200 may include at least one data bus 205 or other communication component for transmitting information and at least one processor 210 or processing circuitry connected to the data bus 205 for processing information. The computing system 200 may include one or more processors 210 or processing circuitry coupled to the data bus 205 to exchange or process data or information. The computer system 200 may include one or more main data memories 215, such as random access memory (RAM), dynamic RAM (DRAM), or other dynamic memory device connectable to the data bus 205 to store information and instructions to be executed by the processor(s) 210. The main data memory 215 may be used to store information (e.g.Data, computer code, instructions, or instructions) used during the execution of instructions by the processor(s) 210.

[0075] Computer system 200 may include one or more read-only memories (ROMs) 220 or other static storage devices connected to bus 205 to store static information and instructions for processor(s) 210. Memory 225 may comprise any storage device, such as a solid-state device, a magnetic disk, or an optical disk, that may be connected to data bus 205 to permanently store information and instructions.

[0076] Computer system 200 may be connected via data bus 205 to one or more output devices 235, such as speakers or displays (e.g., liquid crystal display or active matrix display) for displaying or providing information to a user. Input devices 230, such as keyboards, touchscreens, or voice interfaces, may be connected to data bus 205 to transmit information and commands to processor(s) 210. Input device 230 may include, for example, a touchscreen display (e.g., output device 235). Input device 230 may include a cursor control, such as a mouse, trackball, or cursor direction keys, for transmitting direction information and command selections to processor(s) 210 for controlling cursor movement on a display.

[0077] Computer system 200 may include input / output ports 240, also referred to as I / O ports 240, which comprise physical interfaces that facilitate or enable communication between external or peripheral devices and processor(s) 210 and / or memory 215. I / O ports 240 may be connected to data bus 205 and enable the transfer of data between processor(s) 210, memory 215, and external devices (e.g., keyboards, mice, printers, and external storage devices). Computer system 200 may also include one or more network interfaces 245 coupled via data buses 205. Network interfaces 245 may comprise any physical or virtual components that enable communication between computer system 200 and external networks (e.g., the Internet).The network interface 245 may enable the transfer of data between the processor(s) 210, the memories 215, and any external networks.

[0078] The operations, systems, and methods described herein may be implemented by computer system 200 in response to processor 210 executing an arrangement of instructions contained in main data memory 215. Such instructions may be read into main data memory 215 from another computer-readable medium, such as storage device 225. Execution of the arrangement of instructions contained in main data memory 215 causes computer system 200 to perform the example operations described herein. One or more processors 210 in a multiprocessor arrangement may also be used to execute the instructions contained in main data memory 215. Hard-wired circuitry may be used instead of, or in combination with, software instructions with the systems and methods described herein.The systems and methods described herein are not limited to any particular combination of hardware circuitry and software.

[0079] Although in Fig. 2 an example computer system has been described, the subject matter, including the operations described in this application, may be implemented in other types of digital electronic circuits or in computer software, firmware, or hardware, including the structures disclosed in this application and their structural equivalents, or in combinations of one or more of them.

[0080] In one example, a system 100 may include one or more processors 210 coupled to data storage 215 and configured (e.g., via instructions or commands stored in data storage 215) to receive a request to transmit an email 164a to a recipient identified by a domain of the recipient. The domain of the recipient may be included in recipient information 166a and may identify the domain name of the service or location to which the email 164a is to be transmitted. The request may be received from a user device 160 of a sender at a first device 102 to which the sender's user device 160 is connected.

[0081] One or more processors 210 may be configured to transmit a first query (e.g., an SMTP protocol query from an RCPT_TO command 114) to a DNS 140 to retrieve one or more records (e.g., UPS records 122 or KS records 132). The one or more records (e.g., 122 or 132) may correspond to, reference, or indicate the recipient's domain. The one or more records (e.g., 122 or 132) may identify a KS 130. The identified KS 130 may be a KS 130 that corresponds to or is associated with the recipient's domain.

[0082] One or more processors 210 may be configured to receive an encryption key 134a for encrypting the email 164 from the KS 130 in response to a second query (e.g., from the RCPT_TO command 114) to the KS 130. The received encryption key 134a may be a key corresponding to the recipient's domain and may be identified (e.g., by the DNS 140) in response to the recipient's recipient information 166a.

[0083] One or more processors 210 may be configured to encrypt at least a portion of the email 164a according to, at least based on, or using the encryption key 134a. For example, the one or more processors 210 may encrypt a payload of the email (e.g., the text written by the user), a portion of the payload, or the entire email 164a. One or more processors 210 may transmit the encrypted email 164a to the recipient. The email may be transmitted from the first device 102a (e.g., the sender) over the network 106 to the second device 102b of the recipient.

[0084] The one or more processors 210 may be configured to intercept an RCPT_TO command 114a for the email 164a. The intercepted RCPT_TO command 114 may be configured to transmit the first query to the DNS 140 and also the second query to the KS 130. The RCPT_TO command 114 may be hooked or configured to implement the first and second queries as part of seamless email delivery without prior exchange of encryption keys or prior negotiation of encryption or decryption protocols. The one or more records in the DNS 140 may include a time-to-live (TTL) value, a class of the record, a type of the record, a recipient priority, a recipient weight, and a port identifier.

[0085] The one or more processors 210 may be configured to receive from the DNS 140, in response to the first query, a first record (e.g., KS record 132) of the one or more records. The first record may identify the KS 130 for providing the encryption keys 134a to the intended recipient (e.g., identified in the recipient information 166a). The one or more processors 210 may be configured to receive, in response to the first query, a second record (e.g., UPS record 122) of the one or more records that identifies a provisioning service (e.g., UPS 120). The identified UPS 120 and the KS 130 may correspond to, be referenced by, or relate to the recipient information 166a, including, for example, a domain (e.g.,a domain name) of the recipient's email address, on the basis of which the MTA 110 and / or DNS 140 can identify the UPS 120 and the KS 130.

[0086] The one or more processors 210 may be configured to identify a configuration 124a (e.g., a policy) for encrypting the email by a sender of the email 164a. The configuration 124a may be a configuration indicating that the sender device (e.g., the user device 160a) should encrypt at least a portion of the email 164a. The configuration 124a may specify the type of encryption (e.g., symmetric or asymmetric), as well as whether the encryption key 134a should be generated for a session between the sender and the recipient. The one or more processors 210 may be configured to, in response to the configuration 124a, send the second request to the key service 130 to request the encryption key 134a.

[0087] The one or more processors 210 may be configured to identify a configuration 124a for encrypting the email 164a by a sender (e.g., at the first device 102a) of the email and for decrypting the email by the recipient (e.g., at the second device 102b) using the encryption key 134a. The one or more processors 210 may be configured to generate the encryption key 134a for a session between the sender and the recipient in response to the configuration 124a.

[0088] Once the recipient MTA (e.g., 110b) receives the email from the sender, it can send the encrypted email to the recipient user device (e.g., 160b). The decryption process can run on the recipient user device (e.g., 160b). The decryption process can first check the X-E2ENCRYPT-SUPPORTED: TRUE header. If this is set to true, the recipient user device 160b or its MTA can determine that the message was encrypted end-to-end. The user device 160b can then determine or identify the encryption strategy based on the ENCRYPT_STRATEGY header. If ENCRYPT_STRATEGY = ASSYMETRIC_PUBLIC_KEY, the user device 160b can decrypt the message using the recipient's private key (e.g., based on the recipient information 166b). The user device 160b can decrypt all portions of the email that were encrypted based on the value of the X-ENCRYPT_CONTENT header.For example, if ENCRYPT_STRATEGY = PER_SESSION_SYMMETRIC_KEY, the device can read and encrypt the value of the X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY header. To implement retrieval, the symmetric key can decrypt the portions of the email that were encrypted based on the value of the X-ENCRYPT_CONTENT header. For example, if the X-E2ENCRYPT-DIGITALLY-SIGNED header is present and set to "true," the decryptor calculates the message digest of the encrypted sections and compares the message digest with the digest value in the X-E2ENCRYPT-DIGITAL-SIGNATURE header, completing the decryption process.

[0089] The one or more processors 210 may be configured to identify a configuration for caching the encryption key 134a. The one or more processors 210 may be configured to cache the encryption key 134a on a cache server 150a in response to the configuration 124a. The one or more processors 210 may be configured to determine, according to a configuration 124a of a UPS 120a, that a location to encrypt the email 164a is either the sender (e.g., user device 160) or the MTA 110. The one or more processors 210 may be configured to encrypt the at least one portion of the email by a sender (e.g., user device 160) of the email 164a or an MTA 110 in response to the determined location.The one or more processors 210 may be configured to determine, based on a configuration 124a of a UPS 120a, that a hash value should be included in the email 164a. The one or more processors 210 may be configured to insert the hash value into a header of the email 164a to be transmitted in response to the configuration 124a.

[0090] Fig. 3 is a flowchart of a method 300 for setting up a system and providing seamless end-to-end email encryption and delivery between secure email clusters. The method 300 may include steps 305-355, which may be performed by an example system 100 whose components may utilize the capabilities of the computer system 200. At 305, administrators may set up their respective DNS services. At 310, the DNS services may synchronize their data with the DNSs of other entities. At 315, user provisioning may be implemented. At 320, the user may set up the encryption-related configurations (e.g., policies). At 325, the user may compose an email for transmission to the recipient. At 330, a configured RCPT_TO command (e.g., RCPT_TO hook) may send an initial request to the DNS. At 335, a configured RCPT_TO command (e.g.,RCPT_TO hook) sends a second query to the KS service to obtain an encryption key for the email. At 340, the key may be accessed through a cache server, depending on the cache configuration. At 345, the email may be encrypted at the location specified by the encryption location configuration. At 350, the sender's MTA may forward the email to the recipient's MTA. At 355, the recipient's MTA may deliver the email to the recipient's user.

[0091] Before performing actions 305-355, both the sending and receiving entities (e.g., domains) can be individually configured to support various functions or features. For example, a Query Public Key (QPK) service can be configured to support querying and retrieving user public keys via standard queryable network interfaces, such as HTTP / DNS / RPC. Thus, the Query Public Key (QPK) service can be either a REST, HTTP, or RPC service.

[0092] For example, the facilities can be configured to allow users to generate their own cryptographic key pairs using self-signed key generation tools within the User Provisioning Service, or to allow users to generate self-signed cryptographic key pairs via the User Provisioning Service and upload them to the QPK Service. Sender and recipient domains could also, for example, host their own corporate PKI (Public Key Infrastructure) to generate cryptographic key pairs. An corporate PKI can allow senders and recipients to include or support signed cryptographic key pairs, ensuring that the keys are verifiable during the encryption process.

[0093] DNS servers, for example, can be configured to publish multiple records. For example, a DNS server can publish MX records that specify the domain's inbound and outbound email servers / MTAs. DNS servers can publish SRV records that specify the endpoint of the domain's QPK (Query Public Key) service. An example SRV record might be: "_qpk._tcp.qpk.semc.company.com 86400 IN SRV 5 5 5001 qpk.semc.company.com"

[0094] For example, both senders and recipients can be configured to include or support email servers / MTAs connected to the sender's and recipient's logical corporate domains for sending / receiving emails. Both senders and recipients can be configured to include or support email servers / MTAs connected to the sender's and recipient's logical corporate domains for sending / receiving emails, and can be configured to support extension services in the form of SMTP hooks.

[0095] For example, senders and recipients can be configured to support an EHLO hook as shared-library / jar / sar-file, which, depending on the email server, can be used to send / receive / forward emails, and which would support / add the following to the HELO / EHLO response. For example, senders and recipients can be configured to support the string "CLUSTER-TYPE_END-TO-END-ENCRYPTION" or "CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED." In other words, the sender and recipient entities can communicate to the connecting mail clients that this MTA supports end-to-end encryption. For example, the string "CLUSTER-TYPE_END-TO-END-ENCRYPTION" can indicate that the server supports end-to-end encryption, but encryption / decryption is performed server-side. This ensures that existing AS / AV / DLP workloads on the server run as usual.For example, the string "CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED" can indicate that the server supports end-to-end encryption and the user-configured policies decide where the encryption is performed (e.g. server-side / client-side).

[0096] For example, sender and recipient units can be configured to support the RCPT_TO hook, which can be published as a shared-library / jar / sar-file depending on the email server used to send / receive / forward emails. The library supports extracting the recipient domain from the recipient's email address, querying the recipient domain's SRV record to retrieve the QPK server's endpoint, and making a network call to the recipient domain's QPK REST / HTTP / RPC API address on the Internet to retrieve the recipient's public key.

[0097] Depending on the sender's encryption policy, the units can be configured to cache the recipient's public key in the email server / MTA session and / or send it to the client as an RCPT_TO hook response. For example, the RCPT_TO hook can be configured to handle a setting such as "ENCRYPT_LOCATION=REMOTE, CACHING_STRATEGY=NONE," a setting such as "ENCRYPT_LOCATION=SENDER, CACHING_STRATEGY=NONE," a setting such as "ENCRYPT_LOCATION=REMOTE, CACHING_STRATEGY=CACHE," or a setting such as "ENCRYPT_LOCATION=SENDER, CACHING_STRATEGY=NONE." Depending on the sender's encryption strategy (ENCRYPTION_STRATEGY), the RCPT_TO hook can decide whether to apply public key encryption or generate a random symmetric key per session.

[0098] For example, a User Provisioning / Registration Service (UPS) can be configured to allow new users / domain administrators to create a new email account, set encryption policies for each user, create or upload a public / private key pair for new users, store users' public keys in the corporate domain's QPK service, set encryption / decryption policies for end users, and provide user management interfaces to the QPK service. Units can be configured to support a Secure Email Client (SEC), which allows a user to generate public / private key pairs and add their private cryptographic key to the client, as well as upload the user's public cryptographic key to the QPK service.

[0099] At 305, the administrator of each unit 102 can insert a KS record and a UPS record into the DNS of the respective unit. For example, an administrator can add or configure a KS record (e.g., QPK Endpoint Service record) in the DNS, such as: _qpk._tcp.gpk.semc.company.com 86400 IN SRV 5 5 5001 qpk.semc.company.com. For example, the administrator can add a UPS record (e.g., UPS Endpoint Service record) to the DNS, such as: _ups._http.ups.semc.company.com 86400 IN SRV 5 5 443 ups.semc.company.com.

[0100] At 310, the DNS of each entity may set up, synchronize, and configure its own DNS to include the UPS records and KS records of other DNSs. For example, a DNS of the first entity may synchronize its service records (e.g., UPS records and KS records) with a second DNS of the second entity, and vice versa. For example, the DNS protocol may synchronize records between the DNS servers of the sender and recipient domains using standard, pre-existing cross-network operations. This may apply to the sender.com and recipient.com domains, as well as to any other domains and entities.

[0101] For example, an administrator of a secure email cluster can set up an MX record in DNS that contains or specifies the hostname and IP address of the outgoing mail server, as well as an SRV record that contains the endpoint address of the QPK server. For example, the administrator can include "_qpk._tcp.qpk.semc.company.com 86400 IN SRV 5 5 5001 qpk.semc.company.com." For example, the administrator can include "qpk._http.qpk.semc.company.com 86400 IN SRV 5 5 443 qpk.semc.company.com." For example, the administrator can include "_qpk._rpc.qpk.semc.company.com 86400 IN SRV 5 5 9001 qpk.semc.company.com." For example, an administrator can include a TXT / SRV record that contains or specifies the endpoint address of the User Provisioning / Registration Service, e.g., "_ups._http.ups.semc.company.com 86400 IN SRV 5 5 443 ups.semc.company.com."

[0102] At 315, user provisioning may occur at the originating location. For example, a user may create a new email account on a user device and register it with the UPS. The user may generate encryption keys to use for their emails (e.g., for emails the user will receive). For example, the user may configure or generate an asymmetric key pair containing a public key and a private key for the user. The user may upload the public key to the key service (e.g., QPK) via the UPS. For example, the KS may receive the user's encryption keys from the UPS once the user has generated the keys.

[0103] For example, a new user can register with the Secure Email Cluster using the User Provisioning Service (UPS). The user can be prompted to upload either their existing self-signed or any commercial / open, externally hosted PKI-signed public cryptographic key to the User Provisioning Service (UPS), or to create a new self-signed cryptographic key pair using the tools provided in the User Provisioning Service (UPS). A cryptographic key pair can be generated, for example, by the hosted Public Key Infrastructure (PKI) of the optional user domain, if the user's SEMC has one. The private cryptographic key can remain with the user or be securely returned to them, depending on how the key pair is generated. The public cryptographic key can be stored in either the User Provisioning Service (UPS) or the Query Public Key (QPK) Service.

[0104] At 320, the user can set up the encryption-related configurations (e.g., policies). The configurations may include an encryption location configuration to determine the location where encryption is performed, e.g., at the sender or at the MTA (e.g., ENCRYPT LOCATION configuration). The configuration may include an encryption content configuration to define or identify the content to be encrypted (e.g., ENCRYPT-CONTENT configuration). The configuration may include an encryption strategy configuration to identify or define the type of configuration to be performed (e.g., asymmetric or symmetric) (e.g., ENCRYPT-STRATEGY configuration). The configuration may include a digital signature configuration to determine digital signatures, e.g., whether the message should be digitally signed so the recipient can verify it (e.g., DIGITAL-SIGNING configuration).The configuration can include a caching strategy that specifies how and on which cache server caching should be performed (e.g., CACHING_STRATEGY configuration). The configuration can include a cache time-to-life (TTL) strategy to determine or specify the length of time a specific encryption key should be stored in the cache (e.g., CACHE_TTL configuration).

[0105] The user may be required to specify encryption / decryption policies in the User Provisioning Service (UPS). A sample policy might include ENCRYPT_CONTENT with the following values ​​or settings: "BODY-ONLY" to specify that encryption applies only to the body of the email, "SUBJECT-BODY" to encrypt the subject and body of the email, "ATTACHMENT-ONLY" to encrypt only the attachment of the email, "BODY-ATTACHMENT" to encrypt the body and attachment, "SUBJECT-BODY-ATTACHMENT" to encrypt the subject, body, and attachment, or "NONE" to specify no encryption for the email.The policy may include "ENCRYPT_LOCATION", for which example settings or values ​​can be specified as "REMOTE" to indicate that encryption should occur in the email delivery hook on the sender's email server / MTA, or "SENDER" to indicate that encryption should occur in the email client, provided the email client supports public key encryption.

[0106] An example policy might include "ENCRYPT_STRATEGY," whose values ​​can be "ASSYMETRIC_PUBLIC_KEY" to specify that the recipient's public key should be used for encryption, or "PER_SESSION_SVMMETRIC_KEY" to generate a symmetric key per session. An example policy might include "DIGITAL_SIGNING," whose values ​​or settings can be "TRUE" to specify that the email content summary is signed with the sender's private key before encryption, or "FALSE" to specify that the email content summary is not signed.

[0107] A sample policy might include "CACHING_STRATEGY," for which possible values ​​or settings might be "CACHE" to indicate that the recipient keys are cached in an external cache server, if available, or "NOCACHE" to indicate that the recipient keys are not cached and would be retrieved each time. A sample policy might include "DECRYPT_LOCATION," for which possible values ​​might be "REMOTE," indicating that decryption would occur in the recipient's MTA. This would allow existing anti-spam, anti-virus, and / or data loss prevention (DLP) workloads to scan the email. Enabling this setting would prompt the user to upload their private key, which would be stored with a one-way symmetric key in the recipient domain's Query Public Key (QPK) service.The recipient's MTA can access the private key during mail delivery and decrypt the message in the MTA. Another value or setting may include "RECIPIENT" to indicate that decryption occurs in the recipient's client. The recipient's private key may not be stored in the recipient domain's Query Public Key (QPK) service.

[0108] At 325, the user can create an email to be sent to the recipient. For example, a sender email address (e.g., user@sender.company.com) with a sender domain (e.g., company.com) can connect to its MTA to send the email to a recipient domain email address (user@recipient.company.com) with a recipient domain (e.g., company.com).

[0109] At 330, an RCPT_TO command modified or hooked to query DNS and key services may send a query to the sender's DNS at the MTA (e.g., SMTP server) to retrieve service records (e.g., KS records or UPS records) for the recipient domain. For example, an RCPT_TO command may query a DNS service for service records for the domain recipient.com. In response to this query from the hooked RCPT_TO command, the DNS may respond with the requested service records. For example, the DNS response may contain: "_qpk._http.qpk.semc.company.com 86400 IN SRV 5 5 443 qpk.semc.company.com" (e.g. KS record) and "_ups._http.ups.semc.company.com 86400 IN SRV 5 5 443 ups.semc.company.com" (e.g. UPS record).

[0110] At 335, the configured RCPT_TO command (e.g., RCPT_TO hook) for user@sender.semc.company.com can query the retrieved KS service endpoint for the recipient's public key. In some examples, depending on the encryption configuration / policy, e.g., the ENCRYPT_STRATEGY configuration, the RCPT_TO command (e.g., RCPT_TO hook) can decide whether to generate an additional symmetric key per session. For example, if ENCRYPT STRATEGY is configured for an asymmetric public key, no symmetric key is generated per session; instead, the public key is used to encrypt at least part of the email. For example, if ENCRYPT_STRATEGY is configured for a symmetric key per session, one symmetric key is generated per session. This key can be encrypted with the sender's public key.

[0111] At 340, the hooked RCPT_TO command can decide, depending on the sender's CACHING_STRATEGY configuration, whether the receiver's public key and / or symmetric key should be cached per session. In some cases, there may be no caching strategy, and no caching is performed (e.g., there is no cache server).

[0112] At 345, depending on the sender's ENCRYPT_LOCATION configuration, the hooked RCPT_TO command either keeps the recipient's public key and / or the symmetric key in the MTA SMTP session or sends it to the Tile client. The sender can receive an RCPT_TO response. If the ENCRYPT LOCATION configuration identifies the sender as a location, the sender's user device can encrypt the sections of the email designated for encryption using either the recipient's public key or the per-session symmetric key. If the ENCRYPT LOCATION configuration identifies the location as a remote location, the sender can send the email in cleartext to the MTA, and the MTA can perform encryption using the recipient's key or the per-session symmetric key it possesses in its current session.The symmetric key per session can be encrypted with the recipient's public key, and the encrypted symmetric key is added as an email header. The email header can be, for example, X-E2ENCRYPTPER_SESSION_SYMMETRIC_KEY.

[0113] If a DIGITAL_SIGNING configuration is enabled, the sender can generate a checksum before sending the email to the MTA and encrypt it with the sender's private key. The sender can include a header in the message, such as "X-E2ENCRYPT-DIGITAL-SIGNATURE:<base64_encoded_sender_private_key_encrypted_message_digest> The header can be read by the recipient, and the base64 decoded and encrypted message digest would be decrypted by the recipient's email client using the sender's public key. At this point, the email can be encrypted.

[0114] At 350, the MTA of the sender entity can forward the encrypted email to the MTA of the recipient entity. For example, the MTA corresponding to user@sender.semc.company.com can forward the email to the MTA of user@recipient.semc.company.com.

[0115] At 355, the MTA of the domain user@recipient.semc.company.com can deliver the encrypted email to the intended user. The recipient's email application can read the X-E2ENCRYPT-SUPPORTED header. If the header's value is set to true, the recipient can determine that this email contains ciphertext that should be decrypted. The recipient's email application can then read the X-E2ENCRYPT header. If the header contains or references an ENCRYPT_STRATEGY that identifies an asymmetric public key, the recipient device can decrypt the message using the recipient's private key.If the header contains or references an ENCRYPT STRATEGY configuration that specifies the use of a per-session symmetric key, the recipient's email client can read the X-E2ENCRYPTPER _SESSION_SYMMETRIC _KEY header and decrypt the email using the per-session symmetric key.

[0116] In an example scenario or use case, both the sender and recipient endpoints can include their own Secure Email Clusters (SEMCs) with CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED. A sender can send an EHLO to outgoing mail servers / MTAs in their Secure Email Cluster (SEMC). The sender's mail server / MTA's EHLO SMTP hook can respond with the following content, including the fact that the cluster supports end-to-end encrypted email: EHLO secure.mail.company.com 250-secure.mail.company.com says hello . 250-ENHANCEDSTATUCODES 250-PIPELINING 250-CHUNKING 250-E2ENCRYPT (RSA|PUBLIC_KEY) 250-E2ENCRYPT_PUBLICKEY_CACHE 250-E2ENCRYPT_DIGEST 250-CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED

[0117] The server's SMTP hook EHLO can respond by specifying that the server supports CLUSTER-TYPE END-TO-END-ENCRYPTION_USER_POLICY_BACKED. Email clients that support end-to-end email encryption can acknowledge the EHLO response and initialize the appropriate encryption / decryption libraries depending on the sender's ENCRYPT_LOCATION policy. If the sender's ENCRYPT_LOCATION policy is "REMOTE," no encryption libraries may be initialized on the client. If the sender's ENCRYPT_LOCATION policy is "SENDER," the appropriate encryption libraries can be initialized by parsing the EHLO response line "250-E2ENCRYPT (RSA|PUBLIC_KEY)."

[0118] Additionally, the sender can send an RCPT_TO to the outgoing mail server / MTA in the Secure Email Cluster (SEMC). The RCPT_TO SMTP hook of the sender's mail server / MTA, as part of its Secure Email Cluster (SEMC), can extract the domain from the recipient address, query DNS to retrieve the recipient domain's SRV record containing the query public key (QPK) server's endpoint, query the query public key (QPK) server to retrieve the endpoint address from which to retrieve the recipient's public key, or remember that the SRV record resembles "_qpk._http.qpk.semc.company.com 86400 IN SRV 5 5 443 qpk.semc.company.com."

[0119] Depending on the configured sender policy, ENCRYPT_LOCATION, the entity can perform one of the following actions. For example, if ENCRYPT_LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", then the entity can hold the recipient's public key in the current SMTP session. If ENCRYPT_LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", then the entity can generate a random symmetric key and hold the recipient's public key and this generated random symmetric key in the current SMTP session. If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", the entity can send the recipient's public key as part of the RCPT_TO response.If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", the entity can generate a random symmetric key, encrypt this random symmetric key with the sender's public key, and send the random symmetric key encrypted with the sender's public key to the client using the "X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY" header. The entity can keep the recipient's public key and the generated random symmetric key in the current SMTP session.

[0120] For example, the sender can use the DATA command to send email content to the recipient. Depending on the configured sender policy, ENCRYPT_LOCATION performs one of the following actions. If ENCRYPT_LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", the server can receive the data from the client and encrypt the sender's DATA with the recipient's public key of the SMTP session. If the server supports message digests and digital signing of messages, it can create a digest of the message before encryption and encrypt the message digest with the recipient's public key. If ENCRYPT_LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", the server can receive the data from the client and encrypt the sender's data with the symmetric random key stored in the session.If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", the client can encrypt the sender data before actually sending the data to the server using the recipient's public key, which is returned as part of the RCPT_TO hook response. If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", the client can decrypt the per-session symmetric key, which was returned to the client as the RCPT_TO hook response, using the sender's private key, which only the sender has access to. The client can encrypt the sender data before sending the data to the server using the per-session symmetric key.

[0121] For example, for ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", if the sender's policy DIGITAL_SIGNING is configured to true, then the following header can be added "X-E2ENCRYPT-DIGITAL-SIGNATURE: <base64_encoded_sender_private__key_encrypted_message_digest>". For example, for ENCRYPT _LOCATION = "SENDER" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", if the DIGITAL_SIGNING policy configured as sender is set to true, the following header can be added "X-E2ENCRYPT-DIGITAL-SIGNATURE:<base64_encoded_sender_private_key_encrypted_message_digest> For example, if ENCRYPT_LOCATION = "SENDER", if the client successfully encrypts the content, an additional header "X-E2ENCRYPT-CLIENT: TRUE" can be inserted into the message. For example: ENCRYPT_LOCATION = "SENDER", if the client cannot encrypt the content, an additional header "X-E2ENCRYPT-CLIENT: FALSE" can be inserted into the message.

[0122] The actual content to be encrypted may depend on the ENCRYPT_CONTENT policy configured by the sender. Once the server has the encrypted content, it can insert additional headers into the email so that the recipient can apply decryption rules to the message. If ENCRYPT_LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY," the following headers can be added: "X-E2ENCRYPT-SUPPORTED: TRUE", "X-E2ENCRYPT: ENCRYPT_LOCATION = REMOTE, ENCRYPT_LIB = (RSA|PUBLIC_KEY)", or "ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", ENCRYPT_CONTENT = BODY-ONLY."

[0123] If the sender policy DIGITAL_SIGNING is configured, then a header “X-E2ENCRYPT-DIGITAL-SIGNATURE: <base64_encoded_sender_private_key_encrypted_message_digest>" must be added. If ENCRYPT _LOCATION = "REMOTE" and ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", then the following headers can be added: "X-E2ENCRYPT-SUPPORTED: TRUE", "X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY: <base64_encoded_recipient_public_key_encrypted_per_session_symmetric_key> ", "X-E2ENCRYPT: ENCRYPT_LOCATION = REMOTE, ENCRYPT_LIB = (RSA|PUBLIC_KEY|PER_SESSION_SYMMETRIC), ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", ENCRYPT_CONTENT = BODY-ONLY".

[0124] If the DIGITAL_SIGNING sender policy is configured, the following header can be added: “X-E2ENCRYPT-DIGITAL-SIGNATURE: <base64_encoded_sender_private_key_encrypted_message_digest>". If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", then the following headers can be added: "X-E2ENCRYPT-SUPPORTED: TRUE", "X-E2ENCRYPT: ENCRYPT_LOCATION=SENDER, ENCRYPT_LIB=(RSA|PUBLIC_KEY), ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", ENCRYPT_CONTENT=BODY-ONLY".

[0125] If ENCRYPT_LOCATION = "SENDER" and ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", then the following headers can be added: "X-E2ENCRYPT-SUPPORTED: TRUE", "X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY:<base64_encoded_recipient_public_key_encrypted_per_session_symmetrie_key> ", "X-E2ENCRYPT: ENCRYPT_LOCATION = SENDER, ENCRYPT_LIB = (RSA|PUBLIC_KEY|PER_SESSION_SYMMETRIC)", "ENCRYPT_STRATEGY = "PER_SESSION_SYMMETRIC_KEY", ENCRYPT CONTENT=BODY-ONLY." If the sender policy DIGITAL_SIGNING is configured, the following header can be added: "X-E2ENCRYPT-DIGITAL-SIGNATURE:<base64_encoded_sender_private_key_encrypted_message_digest> “.

[0126] If the client fails to encrypt the data for any reason, the header value for X-E2ENCRYPT-SUPPORTED may be false. This may mean that the recipient is informed that, despite encryption attempts, the client was unable to encrypt the data for some unknown reason, and that the forwarded email is in plaintext. The header values ​​in this case may look like this: "X-E2ENCRYPT-CLIENT: FALSE," which can be set by the client if it cannot encrypt the data, or "X-E2ENCRYPT-SUPPORTED: FALSE," which may mean that the server reads the X-E2ENCRYPT-CLIENT header and, if it is false, sets X-E2ENCRYPT-SUPPORTED to false.Die Header-Werte können beinhalten „X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY: <base64_encoded_recipient_public_key_encrypted_per_session_symmetric_key>“, „X-E2ENCRYPT: ENCRYPT_LOCATION=SENDER, ENCRYPT_LIB=(RSA|PUBLIC_KEY|PER_SESSION_SYMMETRIC), ENCRYPT_STRATEGY = „PER_SESSION_SYMMETRIC_KEY“, ENCRYPT_CONTENT = BODY-ONLY".

[0127] For ASSYMETRIC_PUBLIC_KEY-based encryption, when the client cannot encrypt the data, these headers can have the following values: "X-E2ENCRYPT-CLIENT: FALSE", which can be set by the client if it does not encrypt the data, "X-E2ENCRYPT-SUPPORTED: FALSE", where the server reads the X-E2ENCRYPT-CLIENT header and, if it is false, sets X-E2ENCRYPT-SUPPORTED to false, "X-E2ENCRYPT: . ENCRYPT_LOCATION=SENDER, ENCRYPT_LIB = (RSA|PUBLIC_KEY|PER_SESSION_SYMMETRIC), ENCRYPT_STRATEGY = "ASSYMETRIC_PUBLIC_KEY", ENCRYPT_CONTENT=BODY-ONLY". The recipient can read the header when receiving the email. Check X-E2ENCRYPT-SUPPORTED and, if set to false, do not attempt decryption.

[0128] The sender's email server (MTA) can forward the encrypted email to the recipient's email server (MTA) using its existing standard email delivery procedures. Meanwhile, the email content can be encrypted, and the email can contain additional headers that allow the recipient to apply appropriate decryption policies.

[0129] In an example scenario or use case, a sender may be within a Secure Email Cluster, while the recipient uses an email domain that does not match the Secure Email Cluster. The sender can send an EHLO to the outgoing mail server / MTA in their Secure Email Cluster (SEMC). The EHLO SMTP hook of the sender's mail server / MTA can respond with the following content, including the fact that the cluster supports end-to-end encrypted email: EHLO secure.mail.company.com 250-secure.mail.company.com says hello 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250-E2ENCRYPT (RSA|PUBLIC_KEY) 250-E2ENCRYPT_PUBLICKEY_CACHE 250-E2ENCRYPT_DIGEST 250-CLUSTER-TYPE_END-TO-END-ENCRYPTION_USER_POLICY_BACKED

[0130] The server's EHLO SMTP hook can indicate in response that the server supports end-to-end encryption. Email clients that support end-to-end email encryption can acknowledge the EHLO response and initialize the appropriate encryption / decryption libraries based on the sender's ENCRYPT_LOCATION policy. If the sender's ENCRYPT_LOCATION policy is "SERVER," no encryption libraries may be initialized on the client. If the sender's ENCRYPT_LOCATION policy is "CLIENT," the appropriate encryption libraries can be initialized by parsing the EHLO response line "250-E2ENCRYPT (RSA|PUBLIC_KEY)."

[0131] The sender can send an RCPT_TO to an outgoing mail server / MTA in the Secure Email Cluster (SEMC). The RCPT_TO SMTP hook of the sender's mail server / MTA, as part of its Secure Email Cluster (SEMC), can do the following: extract the domain from the recipient address, query DNS to retrieve the recipient domain's SRV record, which contains the Query Public Key (QPK) service endpoint. Because the recipient domain might not match a Secure Email Cluster (SEMC), no such QPK will be retrieved.

[0132] In some examples or use cases, the email is not encrypted because the recipient domain does not support end-to-end email encryption. The sender's email server (MTA) can forward the encrypted email to the recipient's email server (MTA) using existing standard email delivery processes.

[0133] In some examples or use cases, the sender can send an EHLO to the outgoing mail server / MTA in their Secure Email Cluster (SEMC). The sender's mail server / MTA's EHLO SMTP hook can respond with the following content, including the fact that the cluster supports end-to-end encrypted email: EHLO secure.mail.company.com 250-secure.mail.company.com says hello 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250-E2ENCRYPT (RSA|PUBLIC_KEY) 250-E2ENCRYPT_PUBLICKEY_CACHE 250-E2ENCRYPT_DIGEST 250-CLUSTER-TYPE_END-TO-END-ENCRYPTION

[0134] The server's EHLO SMTP hook can respond that the server supports CLUSTER-TYPE_END-TO-END-ENCRYPTION. This can mean that the Secure Email Cluster performs encryption and decryption exclusively on the respective servers, and that users are not allowed to specify policies for the encryption / decryption location. The workflow can run assuming "ENCRYPT_LOCATION=REMOTE" and "DECRYPT_LOCATION=REMOTE." Users can set DIGITAL_SIGNING=TRUE.

[0135] In some examples or use cases, a recipient may be located in a Secure Email Cluster. Once a message is received from the recipient's domain, a decryption process can be initiated. The decryption process can first check the following header: "X-E2ENCRYPT-SUPPORTED: TRUE". If the value is set to TRUE, it can check for the presence of the X-E2ENCRYPT-DIGITAL-SIGNATURE header. If the message is digitally signed, the decryption process can proceed to determine the message digest sent by the sender by base64 decoding the header value, retrieving the sender's public key by querying DNS and the sender's Query Public Key (QPK) service endpoint address using SRV records, and decrypting the encrypted digest using the sender's public key.

[0136] The decryption process can read the X-E2ENCRYPT header. If the header contains ENCRYPT_STRATEGY=ASSYMETRIC_PUBLIC_KEY, it can decrypt the message using the recipient's private key. Which parts of the message should be decrypted can be determined from the value in the X-E2ENCRYPT header. This header contains an attribute called ENCRYPT_CONTENT=BODY-ONLY, which can be used to decide whether decryption should be performed. Otherwise, if the ENCRYPT_STRATEGY header contains PER_SESSION_SYMMETRIC_KEY, the recipient's email client can read the X-E2ENCRYPT-PER_SESSION_SYMMETRIC_KEY header.

[0137] The recipient's email client can decrypt the header value using base64 and decrypt the key with the recipient's private key. The recipient's email client can decrypt the message using the symmetric key. Which parts of the message should be decrypted can be determined from the X-E2ENCRYPT header value ENCRYPT_CONTENT=BODY-ONLY.

[0138] After the message is decrypted, the decryption process can again compute a message digest. If the message was digitally signed and the X-E2ENCRYPT-DIGITAL-SIGNATURE header is present in the message, the digest retrieved in the previous step is compared with the digest generated by decryption. If the digests match, the message can be forwarded. Otherwise, the message can be flagged. If the recipient policy is DECRYPT_LOCATION = REMOTE, the decryption process can be performed on the recipient domain's MTA. If the recipient policy is DECRYPT_LOCATION = RECIPIENT, the decryption process can be performed on the recipient's email client.

[0139] Fig.4 shows a flowchart of a method 400 for providing seamless end-to-end email encryption and delivery between secure email clusters without prior key sharing or protocol configurations. The method 400 may include steps 405-425, which may be performed by the example system 100, whose components may utilize features of the computer system 200. At 405, a request to transmit an email may be received. At 410, a first query may be transmitted to a DNS. At 415, an encryption key may be received in response to a second query. At 420, the email may be encrypted. At 425, the email may be transmitted.

[0140] At 405, an MTA of a first entity (e.g., a secure email cluster of the sender) may receive a request to transmit an email. The method may include a mail transport agent (MTA) of a sender organization (e.g., the first entity) receiving a request to transmit an email to a recipient. The MTA may include an SMTP server that includes or provides any number of SMTP functions. The recipient may be identified by a domain of the recipient, an email address of the recipient, or other recipient information. The request may be received by a user device of the sender, which sends the email to the recipient.

[0141] The first request can be sent in response to the user composing, completing, or sending the email at the user device. The first request can be sent to the MTA or UPS of the first entity. The first request can be sent in response to the user device sending the email. The first request can cause the MTA to trigger the SMTP protocol's RCPT_TO command.

[0142] At 410, a configured RCPT_TO command (e.g., RCPT_TO hook) may send a first request to a DNS. The method may include the sender's MTA sending a first query to a Domain Name Service (DNS). The first query may be to retrieve one or more records corresponding to the recipient's domain. The one or more records may identify a key service. The sender's MTA (e.g., the first entity) may intercept an RCPT_TO command for the email. The intercepted RCPT_TO command may be configured (e.g., hooked, modified, or crafted) to transmit the first query to the DNS. The first query may include an SMTP query to instruct the DNS to provide the service records to the MTA. The service records may include the key service (KS) records. The service records may include the user provisioning service (UPS) records.The service records can contain: a time-to-live (TTL) value, a class of the record, a type of the record, a priority of the receiver, a weight of the receiver and a port identifier.

[0143] The sender's DNS may be configured to receive from a second recipient's DNS a first record of the one or more records corresponding to a user's domain. The user may be a sender or a recipient. The sender's DNS may be configured to transmit to the second recipient's DNS a second record of the one or more records corresponding to a second domain of the sender. The sender's and recipient's DNS (e.g., two separate secure email clusters) may exchange their service records to synchronize the service records they may provide in response to queries from the configured (e.g., hooked) RCPT_TO command.

[0144] The sender's MTA can intercept an RCPT_TO command for the email. The intercepted RCPT_TO command can be configured to transmit both the first query to the DNS and the second query to the key service. For example, the RCPT_TO command can be configured to send the first query to the DNS to collect or receive the service records (e.g., KS records or USP records) and then, based on the user information (e.g., the user's domain) contained in the service records, request the appropriate encryption key to encrypt the email.

[0145] The MTA may receive from the DNS, in response to the initial query, a first record of the one or more records identifying the key service or UPS service. The key service's service record may contain, for example, "_qpk._tcp.qpk.semc.company.com 86400 IN SRV 5 5 5001 qpk.semc.company.com," which may indicate that the key service for the domain "semc.company.com" is reachable at the hostname "qpk.semc.company.com" via TCP on port 5001. The priority and weight values ​​of the KS record may both be set to a value such as "5" to establish or specify the order of preference and load balancing among multiple KS servers or services. For example, a KS record can contain a TTL (Time-to-live) value (e.g., a parameter to determine the time that data such as a record, a service, or an encryption key can be on the network before it is discarded), a class of the record (e.g.,the protocol family to which the record belongs), a type of record (e.g., A vs. AAAA record, mail exchange, or canonical name), a priority of the recipient, a weight of the recipient, and a port identifier.

[0146] The MTA may, in response to the first query, receive a second record of the one or more records that identifies a provisioning service (e.g., UPS). The UPS resource may contain information or data indicating that the UPS service is reachable for the domain "semc.company.com" at the host name "ups.semc.company.com" over TCP on port 5001. The priority and weight values ​​of the UPS record may both be set to a value such as "5" to establish or indicate the order of preference and load balancing among multiple UPS servers or services. For example, a UPS record may contain a time-to-live (TTL) value (e.g., a parameter for determining the time that data such as a record, service, or encryption key can remain on the network before being discarded), a class of record (e.g., the protocol family to which the record belongs), a type of record (e.g., A- vs.AAAA record, mail exchange, or canonical name), a recipient priority, a recipient weight, and a port identifier.

[0147] At 415, an encryption key may be received in response to a second query of the configured RCPT_TO command (e.g., RCPT_TO hook). The method may include the sender's MTA receiving a key for encrypting the email in response to a second query to the key service. The second query may be a query sent by the RCPT_TO hook to a key service identified by the RCPT_TO hook based on the content of the service records received in response to the first query.

[0148] The key may contain the recipient's public key, which the sender (e.g., the user device or the sender's MTA) can use to encrypt the email sent to the recipient. The key may be a symmetric key, which both the sender and the recipient can use to encrypt and decrypt the same email. The key may be an encryption key generated for a specific session between the sender and the recipient. For example, the key service may generate a key for a session between the sender and the recipient that responds to the second request.

[0149] At 420, the sender or the MTA, depending on the configuration / policy, may encrypt the email. The method may include either the sender or the MTA encrypting at least a portion of the email based on the key. For example, the MTA, the RCPT_TO command, or the UPS may identify a configuration (e.g., a policy) for encryption of the email by the sender and decryption of the email by the recipient using the key. The configuration may correspond to or identify symmetric encryption of the email. Depending on this configuration, the sender may generate the key for a session between the sender and the recipient.

[0150] The MTA can determine a configuration (e.g., a policy) for encrypting the email from the sender. This configuration may correspond to or identify an asymmetric encryption configuration. In response to this configuration, the MTA can transmit the second challenge to the key service and request the key. The key may contain the recipient's public key, which the sender can use to encrypt the email.

[0151] The MTA may determine, according to a configuration (e.g., a policy) of a provisioning service, that a location to encrypt the email is either the sender or the MTA. The sender or the MTA may encrypt at least that portion of the email in response to the determined location. The configuration may, for example, be a configuration to determine the location of encryption. The configuration may identify the location of the sender (e.g., the user device) or the MTA as the location of encryption. According to the configuration, the sender or the MTA may perform the encryption using the encryption key received in response to the second challenge.

[0152] The MTA may determine, based on a configuration (e.g., a policy) of a delivery service, that a hash value should be included in the email. The configuration may be a configuration for a hash value to be included in the email. In response to this configuration, the MTA may generate the hash value generated for the email (e.g., using an encryption key) and include it in the header of the email being transmitted.

[0153] At 425, the MTA may transmit the encrypted email to the MTA of the second entity (e.g., the recipient's secure email cluster). The method may include transmitting the encrypted email to the recipient. The method may include the MTA of the sending entity (e.g., the first entity) sending the email to the MTA of the receiving entity (e.g., the second entity). The MTA may transmit the email in response to the full encryption of the email.

[0154] The MTA can specify a configuration (e.g., a policy) for caching the key. For example, an encryption key caching configuration can identify the key as one of the keys stored in the cache. Depending on the key caching configuration, the MTA can cache the key on a cache server. The cached encryption key can be cached for future use if needed.

[0155] As used herein, the phrase "at least one of" preceded by a list of items, separated by the terms "and" or "or," modifies the list as a whole, rather than each individual item in the list (i.e., each item). The phrase "at least one of" does not require the selection of at least one of the listed items; rather, the phrase allows for a meaning that includes at least one of the items and / or at least one combination of the items. For example, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refer, respectively, to only A, only B, or only C, and / or to any combination of A, B, and C.In cases where a selection of “at least one of each of A, B and C” or alternatively “at least one of A, at least one of B and at least one of C” is intended, it is explicitly described as such.

Claims

[1] Method comprising: Receipt of a request to transmit an email to a recipient identified by a recipient domain by a sender's Mail Transport Agent (MTA); transmitting, by the sender's MTA, a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Receiving a key to encrypt the email by the MTA from the key service in response to a second challenge transmitted to the key service using the RCPT_TO command; Encryption of at least one section of the email by the sender or the MTA based on at least the key; and Transferring the encrypted email to the recipient. [2] The method of claim 1, further comprising: The sender's MTA intercepts the RCPT_TO command for the email and, in response to the intercepted RCTP_TO command, transmits the first query to the DNS and the second query to the key service. [3] The method of claim 1, wherein a record of the one or more records comprises at least one of: a time-to-live (TTL) value, a class of the record, a type of the record, a priority of the receiver, a weight of the receiver, and a port identifier. [4] The method of claim 2, further comprising: Receiving, by the MTA, a first record of the one or more records identifying the key service from the DNS in response to the first query; and Receiving, by the MTA, a second set of records from the one or more records identifying a provisioning service in response to the first query. [5] The method of claim 1, further comprising: Identifying a configuration for encrypting the email by the sender through the MTA; and The MTA transmits the second challenge to the key service in response to the configuration, with the second challenge requesting the key. [6] The method of claim 1, further comprising: Identifying a configuration for encrypting the email by the sender and decrypting the email by the recipient using the key by the MTA; and Generation of the key for a session between the sender and the receiver by the sender in response to the configuration. [7] The method of claim 1, further comprising: Identifying a configuration for caching the key by the MTA; and Caching the key on a cache server by the MTA in response to the key caching configuration. [8] The method of claim 1, further comprising Determining, according to a configuration of a provisioning service, that a location to encrypt the email is one of the sender and the MTA; and Encryption of at least one portion of the email by the sender or the MTA in response to the determined location. [9] System comprising: at least one processor coupled to a data memory and configured to: to receive a request to transmit an email to a recipient identified by a recipient's domain; transmitting a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Received from the key service in response to a second request to the key service, using the RCPT_TO command, for a key to encrypt the email; Encrypting at least a portion of the email based on the key; and Transferring the encrypted email to the recipient. [10] Non-transitory computer-readable medium storing instructions that, when executed by at least one processor of a service, cause the at least one processor to: Receiving a request to transmit an email to a recipient identified by a recipient's domain; transmitting a first query to a Domain Name Service (DNS) using a Simple Mail Transfer Protocol (SMTP) RCPT_TO command to retrieve one or more records corresponding to the recipient's domain, the one or more records identifying a key service; Received from the key service in response to a second request for a key to encrypt the email, transmitted to the key service using the RCPT_TO command; Encrypting at least a portion of the email based on the key; and Transferring the encrypted email to the recipient.

Images