Preventing DKIM playback

Abstract

A method (800) for protecting a message includes obtaining, at a first message server (160), a message (152) for a user (12) of a message service hosted by the first message server, the message including a header (310) including a digital signature (330) signed by an author of the message and a list of one or more recipients (312) of the message. The method includes determining that a domain name system (DNS) TXT record associated with the message (720) includes a delegation policy (722) that indicates that a second message server declares all intended recipients of the message. In response, the method includes determining that the digital signature of the author is valid and the user is a declarative recipient of the message. The method includes indicating that the message is authentic in response to determining that the digital signature is valid and the user is the declarative recipient of the message.

Description

Technical Field

[0001] The present disclosure relates to DomainKeys Identified Mail (DKIM) signatures. Background Art

[0002] DomainKeys Identified Mail (DKIM) is an email authentication standard or method designed to provide authenticity of messages (i.e., to ensure that the message has not been altered in transit). It uses public key cryptography to sign some or all messages with a private key. The recipient of the message can verify the authenticity of the message using the sender's corresponding public key (e.g., by looking up the sender's public key published via the Domain Name System (DNS)). Although DKIM provides authenticity protection, it is still vulnerable to replay attacks and generally compromises mail and forwarding lists. Summary of the invention

[0003] One aspect of the present disclosure provides a computer-implemented method for protecting a message, which, when executed by data processing hardware, causes the data processing hardware to perform an operation. The operation includes obtaining, at a first message server, a message for a user of a message service hosted by the first message server. The message comes from a second message server hosting a second message service. The message includes a header, and the header includes a digital signature signed by an author of the message and a list of one or more recipients of the message. The operation includes determining that a Domain Name System (DNS) TXT record associated with the message includes a delegation policy indicating that the header declares all intended recipients of the message. In response to determining that the DNS TXT record includes a delegation policy, the operation includes determining that the author's digital signature is valid, and determining that the user is a declared recipient of the message using the list of one or more recipients. In response to determining that the author's digital signature is valid and the user is a declared recipient of the message, the operation includes indicating that the message is authentic.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, the operations further include obtaining, at the first message server, a second message intended for a second user of a third message service hosted by a third message server; indicating via an authenticated reception chain (ARC) header that the third message server failed to declare all recipients of the message; and transmitting the second message to the third message server.

[0005] In some examples, the operations further include receiving, at the first message server from a third message server, a second message for a user of a message service hosted by the first message server; determining that the second message is an indirect message; and in response to determining that the second message is an indirect message, applying an indirect message policy to the second message. In some of these examples, determining that the second message is an indirect message includes determining an inconsistency between a DomainKeys Identified Mail (DKIM) authentication and a Sender Policy Framework (SPF) authentication. In some of these examples, the indirect message policy includes one of rejecting the second message or quarantining the second message.

[0006] Optionally, the operations further include obtaining a second message at the first messaging server, the second message intended for a second user of a third messaging service hosted by a third messaging server, the second message including a second header; updating the second header based on the third messaging server to indicate all intended recipients of the second message; and transmitting the second message to the third messaging server. Updating the second header may include adding a forward to declaration.

[0007] In some implementations, the operations further include receiving, at the first message server, from a third message server, a second message for a user of a message service hosted by the first message server; retrieving domain information associated with the third message server; and determining that the second message is authentic based on the domain information. In some of these implementations, retrieving the domain information includes retrieving a public key certificate associated with the third message server. In at least one of these implementations, the domain information includes a threshold number of message recipients, and determining that the second message is authentic includes determining that a number of recipients receiving the second message satisfies the threshold number of message recipients.

[0008] Another aspect of the present disclosure provides a system for protecting messages. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include obtaining a message for a user of a message service hosted by the first message server at a first message server. The message comes from a second message server hosting a second message service. The message includes a header, and the header includes a digital signature signed by an author of the message and a list of one or more recipients of the message. The operations include determining that a domain name system (DNS) TXT record associated with the message includes a delegation policy indicating that the header declares all intended recipients of the message. In response to determining that the DNS TXT record includes a delegation policy, the operations include determining that the author's digital signature is valid, and determining that the user is a declared recipient of the message using a list of one or more recipients. In response to determining that the author's digital signature is valid and the user is a declared recipient of the message, the operations include indicating that the message is authentic.

[0009] This aspect may include one or more of the following optional features. In some implementations, the operations further include obtaining, at the first message server, a second message intended for a second user of a third message service hosted by a third message server; indicating via an authenticated reception chain (ARC) header that the third message server failed to declare all recipients of the message; and transmitting the second message to the third message server.

[0010] In some examples, the operations further include receiving, at the first message server from a third message server, a second message for a user of a message service hosted by the first message server; determining that the second message is an indirect message; and in response to determining that the second message is an indirect message, applying an indirect message policy to the second message. In some of these examples, determining that the second message is an indirect message includes determining an inconsistency between a DomainKeys Identified Mail (DKIM) authentication and a Sender Policy Framework (SPF) authentication. In some of these examples, the indirect message policy includes one of rejecting the second message or quarantining the second message.

[0011] Optionally, the operations further include obtaining a second message at the first messaging server, the second message intended for a second user of a third messaging service hosted by a third messaging server, the second message including a second header; updating the second header based on the third messaging server to indicate all intended recipients of the second message; and transmitting the second message to the third messaging server. Updating the second header may include adding a forward to declaration.

[0012] In some implementations, the operations further include receiving, at the first message server from a third message server, a second message for a user of a message service hosted by the first message server; retrieving domain information associated with the third message server; and determining that the second message is authentic based on the domain information. In some of these implementations, retrieving the domain information includes retrieving a public key certificate associated with the second message server. In at least one of these implementations, the domain information includes a threshold number of message recipients, and determining that the second message is authentic includes determining that a number of recipients receiving the second message satisfies the threshold number of message recipients.

[0013] The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a schematic diagram of an example system for protecting messages.

[0015] Figure 2 is a schematic diagram of a system for distributing messages to private and non-private recipients.

[0016] Figure 3 is a schematic diagram of a message header of a message.

[0017] Figure 4 is a schematic diagram of a challenge system for challenging the sender of a message.

[0018] Figure 5 is a diagram of a message header used to track message changes.

[0019] Figure 6 is a schematic diagram of a user interface of a user device for tracking message changes.

[0020] Figure 7 Figure 1 is a diagram of a DNS TXT record used to track messages.

[0021] Figure 8 is a flow diagram of an example arrangement of operations of a method for protecting a message.

[0022] Fig. 9 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0023] Like reference numbers in the various drawings indicate like elements. DETAILED DESCRIPTION

[0024] DomainKeys Identified Mail (DKIM) is an email authentication standard or method designed to provide authenticity of messages (i.e., to ensure that the message has not been altered in transit). It uses public key cryptography to sign some or all messages with a private key. Recipients of the message can verify the authenticity of the message using the corresponding public key of the sender (e.g., by looking up the sender's public key published via the Domain Name System (DNS)). While DKIM provides authenticity protection, it is still vulnerable to replay attacks and often compromises mail and forwarding lists. In a replay attack, a malicious user sends a message (e.g., spam) through a message transfer agent (MTA), which digitally signs the message, relying on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own reputation, and then resends the message to a large number of intended recipients. Recipients observe a valid signature from a well-known domain, which increases their trust in the message and increases the likelihood of delivery and presentation to the user.

[0025] Because DKIM (and Simple Mail Transfer Protocol (SMTP)) allow emails to be sent to recipients not specified in the message body or headers, DKIM cannot provide replay protection. Furthermore, because DKIM works by signing both the header and body of a message, any modification to the header or body breaks the cryptographic signature. Thus, forwarding an email that, for example, modifies the subject of the message (e.g., by adding "Fwd:" to the front) will cause DKIM to fail.

[0026] The implementation of this article relates to a message protocol that improves replay protection of standards such as DKIM and / or provides forwarding / mailing list modification functions. The protocol may include an explicit statement of all recipients, even traditionally "hidden" recipients, such as blind carbon copy (BCC) recipients. When a user receives a message and verifies via the header of the message that the user is not the declared recipient of the message, the user may receive an alert about a potential replay attack. In some examples, the protocol includes sending a challenge request to the sender of the message. The challenge request questions the sender to verify that the sender is the author of the email by signing another message with the same key used to sign the original message. In some implementations, the protocol includes a function that allows the header and / or body of the message to be changed while still maintaining the authenticity of the original email. For example, the message server changes the subject of the message (e.g., by adding "Fwd: " to the subject of the message) and then digitally signs the edited message. The message server may transmit the message with the original signature, the new signature, and a description of the changes, so that the recipient can verify the original message and the edits via the original signature and the new signature.

[0027] Reference now Figure 1In some implementations, the example message protection system 100 includes a remote system 140 that communicates with one or more user devices 10 via a network 112. The remote system 140 can be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic resources 142, which include computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). A data repository 150 (i.e., a remote storage device) can be overlaid on the storage resources 146 to allow one or more of the clients (e.g., user devices 10) or computing resources 144 to use the storage resources 146 scalably. The data repository 150 is configured to store a plurality of messages 152, 152a-152n. In some examples, the messages 152 include emails, but any other kind of communication (e.g., any text, audio, and / or video messages) can also be stored. The data repository 150 can store any number of messages 152 at any point in time.

[0028] The remote system 140 executes a message server 160. The message server 160 (e.g., an email server or mail server) is configured to receive messages 152 from users 12 (via user devices 10) and deliver messages 152 to other users 12. For example, the message server 160 includes an email server that sends and receives emails. The message server 160 can use any conventional technology to send and receive messages 152 (e.g., SMTP, Post Office Protocol Version 3 (POP3), Internet Message Access Protocol (IMAP), HTTPS API, custom protocols, etc.), and can include any number of subcomponents (e.g., incoming message servers, outgoing message servers, list servers, policies, webmail servers, etc.).

[0029] The message server 160 is configured to receive messages 152 from user devices 10 associated with corresponding users 12 via, for example, a network 112. The user device 10 may correspond to any computing device such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). The user device 10 includes computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware). In some implementations, the first user device 10, 10a of the first user 12, 12a executes a message client 180. The user 12 may draft a message 152 using a web browser, a standalone application executed on the user device 10, or any other suitable means and transmit the message to the message server. For example, the user 12 interacts with the message client 180 (e.g., via a graphical user interface executed on the user device 10) to send and receive messages 152 from the message server 160. The message client 180 may be executed locally on the user device 10 (eg, as a stand-alone application), or may be executed on a remote system 140 and accessed by the user device 10 via the network 112 (eg, using a browser).

[0030] The message server 160 obtains a message 152 to be delivered to a first user 12a. Here, the first user 12a is a client or a client of a message service hosted by the message server 160. The message 152 is obtained from, for example, a second user 12, 12b using a second user device 10, 10b. The second user 12b may use a different message server 160 or the same message server 160 as the first user 12a. The message 152 includes a header 310 and a body 320. The header 310 includes information for message delivery, while the body 320 includes communication information of the message 152. The header 310 includes a list of one or more intended recipients 312 of the message 152. The list of recipients 312 indicates one or more users 12 of the message 152 that are intended to be sent by the original author of the message 152. The body 310 may also include various other information (e.g., sender information, subject, etc.). The header 310 also includes a cryptographically based digital signature 330 signed by the author of the message 152 (e.g., the second user 12b). As used herein, a message signed by the author of message 152 includes a message signed by an agent of the author (e.g., a messaging service on behalf of the author, such as by message server 160). In some examples, message 152 is digitally signed using the DKIM email security standard. Digital signature 330 may sign only header 310, or a combination of header 310 and body 320. Digital signature 330 provides authenticity of header 310 and / or body 320. That is, digital signature 330 allows mathematical verification that the signed data (e.g., header 310) has not changed since digital signature 330 was applied, and that digital signature 330 was applied by a known sender.

[0031] In some implementations, the digital signature 330 employs asymmetric encryption. For example, the author of the message 152 uses the private key 172PRK to "sign" (i.e., encrypt) the header 310 (e.g., a hash value of the header). The digital signature 330 is verified (e.g., by the message server 160) by using the public key 172PK associated with the private key 172PRK used by the digital signature 330. For example, upon receiving the message 152 with the digital signature 330, the message server 160 verifies or authenticates the digital signature 330 by retrieving the public key 172PK (e.g., using a domain name system (DNS)). Once the digital signature 330 is verified and / or authenticated, the message server 160 can be reasonably certain that the owner of the private key 172PRK signed the message 152 and that the message 152 has not been altered during transmission.

[0032] In some implementations, the message server 160 uses the list of one or more intended recipients 312 to determine whether the first user 12a is the stated recipient 312 of the message 152. That is, the message server 160 determines whether the identity or address (e.g., email address) of the first user 12a appears in the list of intended recipients 312 within the header 310 of the message 152. When the digital signature 330 of the author of the message 152 is valid and the user 12 is a stated recipient on the list of one or more recipients 312 of the message 152, in some implementations, the message server 160 indicates that the message 152 is authentic. For example, the message server 160 delivers the message 152 to the first user device 10a of the first user 12a. Additionally or alternatively, the message server 160 classifies, forwards, or otherwise processes the message 152 as if the message 152 were authentic. When the digital signature 330 of the author of the message 152 is valid, but the user 12 is not a declared recipient on the list of one or more recipients 312 of the message 152, the message server 160 can determine an indication of a replay attack. In this scenario, the message server 160 can indicate that the message is untrue. For example, the message server 160 warns the first user 12a (e.g., the message 152 may be a replay attack). In some examples, the message server 160 isolates the message 152 (e.g., by routing the message 152 to a spam folder or otherwise designating the message 152 as untrue and / or spam) or delivers the message 152 with a potentially dangerous alert or notification. In other examples, the message server 160 completely discards the message 152. Additionally or alternatively, the message server 160 marks the message 152, categorizes the message, or takes any other action to indicate that the message 152 is or may be untrue.

[0033] Reference now Figure 2By ensuring that the user 12 is the intended recipient 312 of the message 152, the message server 160 reduces exposure to replay attacks. However, in some scenarios, explicitly stating all intended recipients 312 in the header 310 of the message 152 lacks the desired privacy. For example, when the intended recipients 312 are included on the blind carbon copy (BCC) field of an email, the author typically wants other recipients (i.e., on the "TO" field or the carbon copy (CC) field) to be unaware of the recipients on the BCC field. In order to explicitly state all recipients 312 while maintaining privacy, in some implementations, the message server 160 receives the message 152 from the first user device 10a of the first user 12a for transmission to both the first recipient 312, 312a and the second recipient 312, 312b. In this example, the first recipient 312a is a non-private recipient 312 (eg, included in a "TO" or "CC" field of the email), while the second recipient 312b is a private recipient 312 (eg, included in a "BCC" field of the email).

[0034] In some examples, the message server 160 generates a first header 310, 310a that includes a first recipient 312a (i.e., a non-private recipient 312) and a second header 310, 310b that includes a second recipient 312b (i.e., a private recipient 312). Although in this example, there is a single non-private recipient 312 and a single private recipient 312, the message 152 may include any number of non-private recipients 312 and private recipients 312. The message server 160 may generate a single header 310 that includes each non-private recipient 312 and a separate header for each private recipient 312. For example, for ten non-private recipients 312 and ten private recipients, the message server 160 generates eleven headers 310 (one header 310 for the ten non-private recipients 312 and a separate header 310 for each private recipient 312). The non-private recipient 312 may or may not be included on the header 310 of the private recipient 312 .

[0035] continue Figure 2In the example of , the message server 160 digitally signs the first header 310a with the digital signature 330 of the author of the message 152 (i.e., the first user 12a in this example). The message server 160 digitally signs the second header 310b with the digital signature 330 (i.e., another digital signature using the same private key 172PRK). The message server 160 transmits the message 152 with the first header 310a to the first recipient 312a, and also transmits the message 152 with the second header 310b to the second recipient 312b. When the first recipient 312a receives the message 152 (e.g., from a separate message server 160 or the same message server 160 or any other conventional means for receiving messages 152), the first recipient 312a can verify via the first header 310a that they are the claimed recipient 312 and are unaware that the second recipient 312b received the same message 152. Likewise, when the second recipient 312b receives the message 152, the second recipient 312b can verify via the second header 310b that they are the stated recipient 312, without revealing the second recipient 312b to the first recipient 312a. In addition to the second recipient 312b, the second header 310b can also include the first recipient 312a (because the first recipient 312a is non-private).

[0036] Reference now Figure 3 In some implementations, the message 152 includes a plurality of headers 310, 310A-N, wherein subsequent headers 310 following the first header are digitally signed by a subsequent distributor of the message 152. The subsequent headers 310 include a list of one or more subsequent recipients 312 of the message. In these implementations, the message server 160 determines whether the user 12 receiving the message 152 is a declared recipient of the one or more subsequent recipients 312 of the message. For example, and as Figure 3As shown, the first user 12 sends a message 152 having a first header 310A to the second user 12 (i.e., jsmith@example.com). The first header includes a first digital signature 330, 330a. Here, the first user 12 sends the message 152 from the first message server 160, 160a to the second message server 160, 160b associated with the second user 12. The first header 310A declares the second user 12 as the intended recipient 312. The second user 12 then forwards the message 152 to the third user (i.e., tjones@example.com) and the fourth user 12 (i.e., rbaker@example.com) by sending the message 152 to the third message server 160, 160c. In addition to the first header 310A, the second user 12 also includes a second header 310B in the message 152. The second header 310B is digitally signed by the second user 12 using the second digital signature 330, 330b, and includes the third user 12 and the fourth user 12 as intended recipients 312. In this scenario, after receiving the message 152, the third user 12 verifies that the third user 12 is the intended recipient 312 of the second header 310B. The third user 12 can further verify (i.e., via the first header 310A) that the sender of the message 152 (i.e., the second user 12 that digitally signed the second header 310B) is the intended recipient 312 of the original message.

[0037] This process may be repeated any number of times (adding a layer to the header 310 each time) for forwarding the message 152 to other recipients 312. For example, the third user 12 and / or the fourth user 12 forwards the message 152 to the fifth user 12 using the first header 310A, the second header 310B, and the third header 310 (not shown) including the new recipient. The third header 310 is digitally signed by the distributor so that subsequent recipients 312 can verify the "chain" of headers 310 back to the original author of the message 152. In some implementations, the subsequent headers 310 include an increment (e.g., an instance number or set number of the Authenticated Receive Chain (ARC) protocol) indicating the number of times the message 152 has been forwarded. For example, the second header 310B includes an increment indicating that the message 152 has been forwarded once (e.g., i=1), while the third header 310 includes an increment indicating that the message 152 has been forwarded twice (e.g., i=2). Additionally or alternatively, the message server 160 uses the ARC header to assist in detecting replay attacks or other inauthentic messages 152. Each ARC set includes three headers: an ARC-Seal header, an ARC-Authentication-Results header, and an ARC-Message-Signature header. In some implementations, the message 152 was originally written using only the ARC-Seal header and the ARC-Message-Signature header (i.e., without the ARC-Authentication-Results header). In these implementations, the forwarded message 152 (i.e., when the forwarder is not the original author of the message 152) includes all three headers, and the final recipient 312 of the message 152 includes only the ARC-Seal header and the ARC-Message-Signature header (i.e., without the ARC-Authentication-Results header). In this scenario, when the message server 160 determines that the forwarded message 152 includes an intermediary with only the first two headers (i.e., the ARC-Seal header and the ARC-Message-Signature header), the message server 160 can mark the message as potentially inauthentic.

[0038] When a sender that implements the enhanced security protocol as discussed herein (i.e., "aware") sends a message 152 to an unaware recipient (i.e., a recipient that does not implement the enhanced security protocol) and thus captures a DKIM replay sample there, a malicious actor (e.g., a spammer) may attempt to exploit this. In some implementations, this is mitigated by identifying the unknown recipient, but declaring the recipient 312 in all cases and signing that recipient. If the message 152 is captured by a spammer and replayed, the domain of the unknown forwarder can be adjusted instead of the domain of the innocent originator. In these implementations, the domains that are protected against DKIM replay are protected, while the unknown domains or message servers 160 that are still subject to DKIM replay will be affected.

[0039] For example, a first messaging server 160 sends a message 152 to a second messaging server 160, which is known to the first messaging server 160 but unknown to the second messaging server 160. Even though the recipient 312 using the second messaging server 160 has been declared in the "to" or "cc" field, the first messaging server 160 can also add a forwarded-to header to indicate that the message is sent to a user 12 on an unknown domain. It is worth noting that if the recipient 312 is instead a member of the "to" or "cc" field, and the message is sent to a known messaging server 160, the transmitting messaging server 160 does not need to add a forwarded-to header in front.

[0040] Thus, in some examples, first message server 160 obtains message 152 intended for a user of a messaging service hosted by second message server 160. Message 152 includes header 310. First message server 160 updates header 310 based on second message server 160 to indicate all intended recipients of announcement message 152. Message server 160 may transmit message 152 to second message server 160. Optionally, first message server 160 updates header 310 by adding a forward to announcement.

[0041] Reference now Figure 4In some implementations, after receiving the message 152, the message server 160, 160A sends a challenge request 410 to the sender (e.g., another message server 160, 160B) that challenges the sender of the message 152 that digitally signed the digital signature 330 of the message 152. For example, the challenge request 410 includes a token or value for causing the sender to digitally sign using the same private key 172PRK that was used to sign the digital signature 330 of the message 152. The token may contain a hash value of the message 152 that was just sent, a recipient domain, and / or a timestamp to bind the signature to the message 152. For example, the hash value identifies the message 152, the recipient domain identifies the recipient 312, and the timestamp indicates the time when the transaction or message 152 occurred to prevent replay of the signature. The sender (i.e., the message server 160B in this example) transmits a challenge response 420 that includes a second digital signature 330 executed by the same private key 172PRK that was used to sign the digital signature 330 of the message 152. A valid challenge response 420 confirms to the message server 160A that the sender is the same entity that signed the message 152, thereby greatly reducing the possibility of a replay attack. That is, when the message server 160A receives the challenge response 420 from the sender of the message 152, the message server 160A verifies that the sender of the message 152 is the author of the message 152 in some implementations. When the challenge response 420 is invalid or not provided, the message server 160A may alert the first user 12a and / or discard or quarantine the message 152. The message server 160 may combine the explicit statement of the recipient 312 described above (see Figures 1 to 3 ) or alternatively issue a challenge response 420.

[0042] Therefore, the challenge protocol described herein allows the system 100 to determine and prove to the outside that the token signer (i.e., the sender being challenged) is the sender domain, and ensures that the message is not the result of a replay attack. The signature provided in the challenge response 420 ensures that the sender-recipient participates in the SMTP delivery transaction. This evidence is particularly important for generating a transaction chain that forms a path from the original sender to the final recipient. Path formation may rely on the recipient domain path to detect replay attacks or other unauthentic messages 152. For example, the system 100 expands the explicit recipient declaration to find matching sender and recipient domain information. For example, the message server 160 matches the domain of the address (e.g., email address) of the declared recipient 312 specified by the author of the message 152 with the domain of the recipient specified by the header of the message 152 (e.g., ARC-Seal header). When these domains match, the message server 160 can determine that the message 152 is authentic, and when they do not match, the message server 160 can determine that the message 152 may be unauthentic. Additionally or alternatively, message server 160 employs other protections to prevent replay attacks, such as sender Internet Protocol (IP) confirmation. In this example, message server 160 verifies whether the author's IP address (e.g., stored in the header 310 of the message) matches the sender's IP address.

[0043] In some implementations, the system includes a sender IP confirmation method. In these implementations, the message server 160 attempts to use the recipient domain defined by the sender and then matches it using a message authentication method (e.g., Sender Policy Framework (SPF)) with a declared IP list for verification. Intercepted messages that do not match the correct IP may be marked (e.g., indicated as inauthentic). This technique forces malicious actors to identify themselves in the path, which is very advantageous. Therefore, this technique is useful for building reputation.

[0044] Reference now Figure 5In some implementations, recipient 312 of message 152 performs one or more modifications to message 152 and distributes message 152 to subsequent recipients. For example, message server 160 may receive message 152, add "Fwd:" to the subject line, and distribute message 152 to multiple users according to a mailing list or forwarding list. Such modifications to the subject line (or any other modifications to the subject line or body of message 152) typically violate DKIM and other security standards. The modification may modify the header of message 152, the footer of message 152, or any other part of message 152. In order to be able to modify message 152 while still providing authenticity verification, message server 160 may add modification 510 to message 152. In some examples, modification 510 must follow one or more rules, such as modification 510 must be added in front of the subject line. After adding modification 510, message server 160 determines the length of modification 510. For example, length 520 is in bytes or characters. The message server 160 then generates the second header 310 including the length 520 of the modification 510. The message server 160 may transmit the message 152, the first header 310, and the second header 310 to one or more recipients 312.

[0045] In some implementations, the message server 160 of the recipient 312 verifies the authenticity of the message 152 by verifying the contents of the second header 310, then removing the modification 510 from the message 152 based on the length 520 and verifying the contents of the original header 310. In this way, the message server can "expand" the header 310 and the modification and preserve the encrypted digital signature 330 until the original message 152 is verified as an authentic message from the original author. The message server 160 can remove the modification 510 from the message 152 during verification based on established rules (e.g., the modification 510 can only be added to the front of the subject line or the modification 510 can only be added to the footer of the message 152, etc.) or based on additional contextual information in the header 310. For example, in addition to or in lieu of the length 520 of the modification 510, the header 310 includes an offset or other information identifying the location of the modification 510 in the message 152. Message server 160 may deliver modified message 152 to intended recipient 312 , with modification 510 included within message 152 (ie, modification 510 is not permanently deleted from message 152 ).

[0046] Here, schematic diagram illustration 500 includes a first message server 160A transmitting a message 152 to a second message server 160B. Message 152 includes a message body 320 and a header 310 having a subject line of length 520, 520A of six. Second message server 160B prepends "Fwd:" to the subject line of message 152. "Fwd:" represents a modification 510 of length 520, 520B of four. In this example, second message server 160B generates another header 310 indicating the length 520B of modification 510 and digitally signs the new header 310. Second message server 160B then transmits message 152 to third message server 160C, where the process can repeat until all intended recipients 312 receive message 152.

[0047] Some implementations herein help to tolerate forwarder modifications. Tolerating forwarder modifications is useful when, for example, the forwarder does not implement the same protocol but still provides useful verification results. In some examples, the message 152 implements Multipurpose Internet Mail Extensions (MIME), and the message server 160 adds modifications 510 to one or more MIME parts and tracks the modifications 510 in the header 310 via the length 520 and hash value of the MIME part. The MIME part can form a tree structure with leaf nodes and non-leaf nodes. The header 310 can indicate the length 520 of each node, as well as any other information related to the node (e.g., hash value, content type, length of child nodes, etc.). In this way, the message server 160 can easily add multiple modifications 510 throughout the message 152 (e.g., in the body 320 of the message 152), while still allowing the final recipient 312 to verify both the authenticity and the modifications 510 of the original message 152. In some implementations, the remote system 140, the message server 160, or other computing device extends similar modification tracking to Hypertext Markup Language (HTML).

[0048] Reference now Figure 6, schematic diagram legend 600 includes a user device 10 executing a graphical user interface (GUI) 610 for display on a screen 620 of the user device 10. Here, the GUI 610 visually indicates to a user 12 of the user device 10 modifications 510 made to a message 152 received by the user 12. In this example, a first user 12a (i.e., jsmith@example.com) has forwarded a message 152 originally written by a third user 12c (i.e., rbaker@example.com) to a second user 12b (i.e., tjones@example.com). Here, the first user 12a makes a first modification 510, 510a that adds "Fwd:" to the front of the subject line of the message 152, and a second modification 510, 510b that adds "FYI" to the body 320 of the message 152. In some implementations, the GUI 610 displays one or more visual indications 630 of the modifications 510. For example, visual indication 630 includes highlighting, outlining, bolding, or any other method of drawing attention to and defining modification 510. Message server 160 or message client 180 may add visual indication 630 to message 152 based on one or more headers 310 of message 152 (i.e., by "expanding" modification 510 as described above).

[0049] Although the implementations herein describe operations performed by a message server 160 executing at a remote system 140 and a message client 180 executing at a user device 10, this is not limiting, and any action may be performed by a message server 160 and / or a message client 180. In some examples, the message server 160 executes on the user device 10. The message server 160 may communicate with other message servers 160 of other remote systems 140 (e.g., when one user 12 sends a message 152 to another user 12 utilizing a different messaging service). In some examples, the same message server 160 transmits messages 152 between users 12 (e.g., when the users 12 share the same messaging service).

[0050] Reference now Figure 7 , some message senders (e.g., user 12) may not have the resources or capabilities to implement or use a message client 180 and / or message server 160 that implements the enhanced secure messaging protocol described herein. As described below, participating message servers 160 may perform various actions to deal with non-participating message servers 160 and / or encourage participation.

[0051] In some scenarios, the message sender may delegate the specification to other message servers 160 that do implement the message protocol. To this end, in some implementations, and as illustrated in schematic diagram legend 700, a first message server 160, 160D receives a message 152 for a user 12, 12d of a message service hosted by the message server 160D. The first user 12d interacts with the message service via a first user device 10, 10d. The message 152 comes from a second message server 160, 160E that hosts a second message service and is written by a second user 12, 12e using a second user device 10, 10e. The message 152 includes a header 310 that includes a digital signature 330 signed by the author of the message 152 and a list of one or more recipients 312 of the message 152. In these implementations, the first messaging server 160 determines that a DNS TXT record 720 associated with the message 152 (e.g., associated with the domain of the second user 12 e) includes a delegation policy 722 indicating that the header 310 declares all intended recipients 312 of the message 152. For example, the DNS TXT record 720 includes a flag (e.g., a delegation flag) set to true or “1.” The DNS TXT record 720 may be hosted by a DNS server 710 or the like that is in communication with the first messaging server 160D (e.g., via the Internet).

[0052] In response to determining that the DNS TXT record 720 includes the delegation policy 722, the message server 160 determines that the digital signature 330 of the author (i.e., the second user 12b) is valid, and determines that the user 12d is the stated recipient 312 of the message 152 using the list of one or more recipients 312. In response to determining that the digital signature 330 is valid and that the user 12d is the stated recipient 312 of the message 152, the first message server 160D indicates that the message 152 is authentic. For example, the first message server 160D delivers the message 152 to the user device 10d of the user 12d. Additionally or alternatively, the first message server 160D classifies, forwards, or otherwise processes the message 152 as if the message 152 is authentic. In this way, even if the second message server 160E is unaware of or otherwise does not participate in the enhanced protocols discussed herein, the author or sender of the message 152 can delegate (e.g., via the DNS TXT record 720) to other message servers 160 that do participate in verifying that the recipients 312 are listed in the header 310.

[0053] When the digital signature 330 of the author of the message 152 is valid, but the user 12 is not a declared recipient 312 on the list of one or more recipients 312 of the message 152, the message server 160 can determine an indication of a replay attack. In this scenario, the first message server 160D can indicate that the message is untrue. For example, the first message server 160D warns the user 12d (e.g., the message 152 may be a replay attack). In some examples, the first message server 160D isolates the message 152 (e.g., by routing the message 152 to a spam folder or otherwise designating the message 152 as untrue and / or spam) or delivers the message 152 with a potentially dangerous alert or notification. In other examples, the first message server 160D completely discards the message 152. Additionally or alternatively, the first message server 160D marks the message 152, classifies the message 152, or takes any other action to indicate that the message 152 is or may be untrue.

[0054] In some implementations, when a first message server 160 receives a message 152 from a second message server 160 that is unaware of or does not participate in the enhanced security protocols discussed herein, the first message server 160 may indicate via an ARC header (e.g., an ARC-Seal header) that the second message server 160 failed to declare all recipients 312 of the message 152 processed by the message server 160.

[0055] This enables participating message servers 160 to build a sender signature assurance (SSA) chain, even if some of the message servers 160 in the chain do not participate in the enhanced protocol scheme. That is, participating message servers 160 can provide information about "neighboring" (i.e., adjacent in the chain) non-participating or local message servers 160. This information may include an SPF claimed responsible address (PRA) domain. This information may be included as part of the SSA chain information and at the same time define the appropriate message servers 160 as non-participating. For example, participating message servers 160 use an ARC domain path (ADP) to specify non-participating message servers 160 to help rebuild the SSA chain. For example, the non-participating message server 160 is specified by a recipient address of a fully qualified domain name (FQDN).

[0056] A large number of mail senders and other business-to-consumer (B2C) senders often send messages (e.g., emails) directly to their users. In some implementations, the message server 160 modifies the domain-based message authentication, reporting, and compliance (DMARC) policy so that a direct flow is specified and a policy can be applied to an indirect flow. In order to specify a direct flow, both DKIM and SPF email authentication must pass and the authenticated domains must be aligned. To improve applicability, the policy can specify which domains they must be aligned with. If the flow is indirect, a policy can be applied to the flow. An indirect flow means that only one of DKIM or SPF passes, or if both pass, neither DKIM nor SPF complies with DMARCRFC822 from the domain or the sending domain. The policy can be a rejection, quarantine, or application of a new policy, which will optionally be provided on a best effort basis, but when a replay attack is suspected, a rejection or quarantine policy is applied. This helps to increase the coverage of senders that are considered consistent with both SPF and DKIM, thereby directly forwarding the flow.

[0057] That is, in some implementations, the first message server 160 receives a message 152 for a user of a message service hosted by the first message server from the second message server 160. The message server 160 may determine that the message 152 is an indirect message (e.g., by determining an inconsistency between the DKIM authentication and the SPF authentication), and in response to determining that the message 152 is an indirect message, the message server 160 may apply an indirect message policy to the message. The indirect message policy may include one of rejecting the second message or quarantining the second message.

[0058] Optionally, the message server 160 initializes the reputation of the new sender via a certificate containing third-party verification information. For example, an X.509 field describes the purpose of the sender, such as a mailbox provider, an inbound gateway, or a bank, and is then used to initialize the reputation. This information can be used as an identity to link the certificate and the sending domain together, so that a previous reputation on one domain can be linked to another domain (e.g., an uninitialized domain). In some examples, the certificate includes the sender's domain and a public key for DKIM signing (using traditional DKIM or as described herein). Such a certificate can be placed directly in a DKIM TXT record as a new tag (e.g., "xloc="). The value can include a URL from which the certificate can be obtained. For example, a certificate is obtained via TLS 1.2.

[0059] Reference again Figure 1Based on this, in some implementations, the first message server 160 receives a message 152 for a user 12 of a message service hosted by the first message server 160 from the second message server 160. The first message server 160 may retrieve domain information 154 associated with the second message server 160 and determine that the message 152 is authentic based on the domain information 154. In some of these implementations, the first message server 160 retrieves the domain information 154 by retrieving a public key certificate 156 associated with the second message server 160. Optionally, the domain information 154 includes a threshold number of message recipients 158, and the first message server 160 determines that the message 152 is authentic based on determining that the number of recipients receiving the message 152 satisfies the threshold number of message recipients 158. That is, if the domain is well-known for sending a large number of legitimate messages 152 (e.g., the domain belongs to a large and / or well-known enterprise), the threshold number of message recipients may be in a range that approximates the number of messages 152 that the domain typically sends. For example, if a domain regularly sends 100,000 messages 152 to a mailing list each week, the threshold message recipient number may be greater than 90,000 and less than 110,000. Numbers outside of this range may indicate a DKIM replay attack.

[0060] Figure 8 8 is a flow chart of an exemplary arrangement of operations of a computer-implemented method 800 for protecting messages. The method 800 includes, at operation 802, obtaining, at a first message server 160, a message 152 for a user 12 of a message service hosted by the first message server 160. The message 152 is from a second message server 160 hosting a second message service. The message 152 includes a header 310, and the header includes a digital signature 330 signed by an author of the message 152 and a list of one or more recipients 312 of the message 152. The method 800 includes, at operation 804, determining that a domain name system (DNS) TXT record 720 associated with the message includes a delegation policy 722 indicating that the header 310 declares all intended recipients 312 of the message 152. In response to determining that the DNS TXT record 720 includes the delegation policy 722, the method 800 includes, at operation 806, determining that the author's digital signature 330 is valid, and determining that the user 12 is a declared recipient 312 of the message 152 using the list of one or more recipients 312. In response to determining that the author's digital signature 330 is valid and the user 12 is the stated recipient 312 of the message 152 , the method 800 , at operation 808 , includes indicating that the message 152 is authentic.

[0061] Fig. 9900 is a schematic diagram of an example computing device 900 that can be used to implement the systems and methods described in this document. Computing device 900 is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions are intended to be exemplary only and are not intended to limit implementations of the inventions described and / or claimed in this document.

[0062] The computing device 900 includes a processor 910, a memory 920, a storage device 930, a high-speed interface / controller 940 connected to the memory 920 and a high-speed expansion port 950, and a low-speed interface / controller 960 connected to a low-speed bus 970 and the storage device 930. Each of the components 910, 920, 930, 940, 950, and 960 is interconnected using various buses and can be installed on a common motherboard or installed in other ways as appropriate. The processor 910 can process instructions for execution within the computing device 900, including instructions stored in the memory 920 or on the storage device 930, to display graphical information of a graphical user interface (GUI) on an external input / output device (such as a display 980 coupled to the high-speed interface 940). In other implementations, multiple processors and / or multiple buses and multiple memories and multiple types of memories can be used as appropriate. In addition, multiple computing devices 900 can be connected, each of which provides a portion of the necessary operations (for example, as a server group, a group of blade servers, or a multi-processor system).

[0063] The memory 920 stores information non-temporarily within the computing device 900. The memory 920 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. The non-temporary memory 920 may be a physical device for storing programs (e.g., instruction sequences) or data (e.g., program state information) on a temporary or permanent basis for use by the computing device 900. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0064] The storage device 930 is capable of providing mass storage for the computing device 900. In some implementations, the storage device 930 is a computer-readable medium. In various implementations, the storage device 930 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or a device array (including a device in a storage area network or other configuration). In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-readable medium or a machine-readable medium, such as a memory 920, a storage device 930, or a memory on a processor 910.

[0065] The high-speed controller 940 manages bandwidth-intensive operations of the computing device 900, while the low-speed controller 960 manages less bandwidth-intensive operations. Such a distribution of responsibilities is exemplary only. In some implementations, the high-speed controller 940 is coupled to a memory 920, a display 980 (e.g., through a graphics processor or accelerator), and a high-speed expansion port 950 that can accept various expansion cards (not shown). In some implementations, the low-speed controller 960 is coupled to a storage device 930 and a low-speed expansion port 990. The low-speed expansion port 990, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or a router, for example, through a network adapter.

[0066] As shown, the computing device 900 can be implemented in a variety of different forms. For example, the computing device can be implemented as a standard server 900a or multiple implementations in a group of such servers 900a, implemented as a laptop computer 900b, or implemented as part of a rack server system 900c.

[0067] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuitry, integrated circuit systems, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system that includes at least one programmable processor that can be either special purpose or general purpose and can be coupled to receive data and instructions from and transmit data and instructions to a storage system, at least one input device, and at least one output device.

[0068] A software application (i.e., software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0069] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0070] The process and logic flow described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware), which execute one or more computer programs to perform functions by operating on input data and generating output. The process and logic flow can also be performed by a dedicated logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). For example, a processor suitable for executing a computer program includes both a general-purpose microprocessor and a special-purpose microprocessor, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as a disk, a magneto-optical disk, or an optical disk, or be operably coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices or both. However, a computer does not have to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0071] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen) for displaying information to the user, and possibly a keyboard and pointing device (e.g., a mouse or trackball) by which the user can provide input to the computer. Other kinds of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0072] A variety of implementations have been described. However, it should be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Therefore, other implementations are within the scope of the following claims.

Claims

1. A computer-implemented method (800) which, when executed by data processing hardware (144), causes the data processing hardware (144) to perform operations comprising: A message (152) is obtained at a first messaging server (160) for a user (12) of a messaging service hosted by the first messaging server (160), the message (152) coming from a second messaging server (160) hosting a second messaging service, the message (152) including a header (310), the header (310) including: a digital signature (330) signed by the author of the message (152); and a list of one or more recipients (312) of the message (152); determining that a Domain Name System (DNS) TXT record (720) associated with the message (152) includes a delegation policy (722) indicating that the header (310) declares all intended recipients (312) of the message (152); In response to determining that the DNS TXT record (720) includes the delegation policy (722): determining that the digital signature (330) of the author is valid; and determining that the user (12) is a stated recipient (312) of the message (152) using the list of one or more recipients (312); and In response to determining that the digital signature (330) of the author is valid and the user (12) is the stated recipient (312) of the message (152), indicating that the message (152) is authentic.

2. The method (800) of claim 1, wherein the operations further comprise: obtaining, at the first messaging server (160), a second message (152), the second message being intended for a second user (12) of a third messaging service hosted by a third messaging server (160); indicating, via an authenticated reception chain (ARC) header (310), that the third message server (160) failed to declare all recipients (312) of the message (152); and The second message (152) is transmitted to the third message server (160).

3. The method (800) of claim 1 or 2, wherein the operations further comprise: receiving, at the first messaging server (160), from a third messaging server (160), a second message (152) for the user (12) of the messaging service hosted by the first messaging server (160); determining that the second message (152) is an indirect message (152); as well as In response to determining that the second message (152) is an indirect message (152), an indirect message (152) policy is applied to the second message (152).

4. The method (800) of claim 3, wherein determining that the second message (152) is an indirect message (152) comprises determining an inconsistency between a DomainKeys Identified Mail (DKIM) authentication and a Sender Policy Framework (SPF) authentication.

5. The method (800) of claim 3 or 4, wherein the indirect message (152) strategy comprises one of the following: rejecting the second message (152); or The second message is quarantined (152).

6. The method (800) of any one of claims 1 to 5, wherein the operations further comprise: obtaining, at the first messaging server (160), a second message (152), the second message being intended for a second user (12) of a third messaging service hosted by a third messaging server (160), the second message (152) including a second header (310); updating the second header (310) based on the third message server (160) to indicate all intended recipients (312) of the second message (152); and The second message (152) is transmitted to the third message server (160).

7. The method (800) of claim 6, wherein updating the second header (310) comprises adding a forward-to statement.

8. The method (800) of any one of claims 1 to 7, wherein the operations further comprise: receiving, at the first messaging server (160), from a third messaging server (160), a second message (152) for the user (12) of the messaging service hosted by the first messaging server (160); retrieving domain information (154) associated with the third message server (160); and The second message (152) is determined to be authentic based on the domain information (154).

9. The method (800) of claim 8, wherein retrieving the domain information (154) comprises retrieving a public key certificate (154) associated with the third message server (160).

10. The method (800) of claim 9, wherein: The domain information (154) includes a threshold message recipient number (158); and Determining that the second message (152) is authentic includes determining that a number of recipients (312) receiving the second message (152) satisfies the threshold message recipient number (158).

11. A system (100), comprising: Data processing hardware (144); as well as Memory hardware (146) in communication with the data processing hardware (144), the memory hardware (146) storing instructions that, when executed on the data processing hardware (144), cause the data processing hardware (144) to perform operations comprising: A message (152) is obtained at a first messaging server (160) for a user (12) of a messaging service hosted by the first messaging server (160), the message (152) coming from a second messaging server (160) hosting a second messaging service, the message (152) including a header (310), the header (310) including: a digital signature (330) signed by the author of the message (152); and a list of one or more recipients (312) of the message (152); determining that a Domain Name System (DNS) TXT record (720) associated with the message (152) includes a delegation policy (722) indicating that the header (310) declares all intended recipients (312) of the message (152); In response to determining that the DNS TXT record (720) includes the delegation policy (722): determining that the digital signature (330) of the author is valid; and determining that the user (12) is a stated recipient (312) of the message (152) using the list of one or more recipients (312); and In response to determining that the digital signature (330) of the author is valid and the user (12) is the stated recipient (312) of the message (152), indicating that the message (152) is authentic.

12. The system (100) of claim 11, wherein the operations further comprise: obtaining, at the first messaging server (160), a second message (152), the second message being intended for a second user (12) of a third messaging service hosted by a third messaging server (160); indicating, via an authenticated reception chain (ARC) header (310), that the third message server (160) failed to declare all recipients (312) of the message (152); and The second message (152) is transmitted to the third message server (160).

13. The system (100) of claim 11 or 12, wherein the operations further comprise: receiving, at the first messaging server (160), from a third messaging server (160), a second message (152) for the user (12) of the messaging service hosted by the first messaging server (160); determining that the second message (152) is an indirect message (152); as well as In response to determining that the second message (152) is an indirect message (152), an indirect message (152) policy is applied to the second message (152).

14. The system (100) of claim 13, wherein determining that the second message (152) is an indirect message (152) comprises determining an inconsistency between a DomainKeys Identified Mail (DKIM) authentication and a Sender Policy Framework (SPF) authentication.

15. The system (100) of claim 13 or 14, wherein the indirect message (152) strategy comprises one of the following: rejecting the second message (152); or The second message is quarantined (152).

16. The system (100) of any one of claims 11 to 15, wherein the operations further comprise: obtaining, at the first messaging server (160), a second message (152), the second message being intended for a second user (12) of a third messaging service hosted by a third messaging server (160), the second message (152) including a second header (310); updating the second header (310) based on the third message server (160) to indicate all intended recipients (312) of the second message (152); and The second message (152) is transmitted to the third message server (160).

17. The system (100) of claim 16, wherein updating the second header (310) comprises adding a forward to statement.

18. The system (100) of any one of claims 11 to 17, wherein the operations further comprise: receiving, at the first messaging server (160), from a third messaging server (160), a second message (152) for the user (12) of the messaging service hosted by the first messaging server (160); retrieving domain information (154) associated with the third message server (160); and The second message (152) is determined to be authentic based on the domain information (154).

19. The system (100) of claim 18, wherein retrieving the domain information (154) comprises retrieving a public key certificate (156) associated with the third message server (160).

20. The system (100) of claim 19, wherein: The domain information (154) includes a threshold message recipient number (158); and Determining that the second message (152) is authentic includes determining that a number of recipients (312) receiving the second message (152) satisfies the threshold message recipient number (158).

Images