Centralized validation of email senders via ehlo name and ip address targeting

0001The disclosure relates generally to the field of electronic messaging, and more specifically to centralized verification of email senders by EHLO name and IP address targeting.

0002Cross-reference to related applications This application claims the benefit of US Patent Provisional Application Nos. 62/116, 409 filed February 14, 2015, which is incorporated herein by reference in its entirety.

0003In distributed messaging systems such as email, the actual originator of a message can be validated against the alleged identification of the message in order to eliminate malicious messages. Examples of such malicious messages claim to be from a particular sender, but actually have a spoofed sender address and perform some fraudulent work on the recipient ( For example, it may contain "phishing" emails sent by malicious entities that may wish to steal personal information. One approach to this validation issue is to allow the owner of the outbound identity to create a set of rules that define which computers can relay email to the recipient's email server. Is. The Sender Policy Framework (SPF) is a standard implementation of this technique for email. Outgoing identification is these SPFs via the Domain Name System (DNS), such that the incoming mail server can access them to validate the identity of the sender of the received message. Publish the rules.

0004While this technique can be effective, it imposes a considerable burden on the receiving system and poses a challenge in using effective intermediaries (eg, mailing lists, "lifetime" email accounts, etc.). For example, a mailing list server may be required to forward a message from a sender of origin, but the mailing list server is not identified as a valid sender by the sender of origin. When verifying the validity of a message, the receiving system effectively performs more checks than some such rules, even if the complete ruleset requires hundreds or even thousands of rules. Cannot be run on.

0005SPF also includes strict limits on the number of possible Domain Name System (DNS) references to limit the burden on the receiving system, but at the expense of failing to validate some legitimate messages. I will pay. Other techniques, such as the Sender Rewrite Scheme (SRS), replace the original sender with an intermediate identification that can be validated by a more restricted ruleset. By doing so, the burden on the receiving system is minimized, but the validity of the message for the identification of the caller is not verified.

0006Therefore, what is missing is an arbitrarily large number of complex rules for sender identification verification that are compatible with existing frameworks and interoperable without unduly burdening the receiving system. The ability to define a set.

0007In some embodiments, the system and method reframe authentication questions about email from the network or IP level to the transmission mechanism level, leveraging the capabilities of existing Sender Policy Framework (SPF) protocols. Using a custom DNS system backed by a database that encodes the network information available from an SMTP connection into a targeted domain name, and maps that network information to a list of known mechanisms. Can include combining.

0008In some embodiments, the system and method of its own does not require the domain manager to manually reference the SPF record for the authorized mechanism, modify the DNS TXT record for the domain, or otherwise. To be able to define a set of mechanisms that can send e-mail. It also allows the domain manager to allow any number of transmission mechanisms and frees the domain manager from the need to track changes to the SPF configuration for authorized senders.

0009In some embodiments, the system and method include a set of rules (known as directives) that specify which mail server the domain owner can deliver email originating from that domain. It can include a Sender Policy Framework (SPF), which can be a protocol that can be defined in the DNS TXT record. The incoming mail server evaluates these rules and, based on the IP address of the delivery server, determines if the message in question can originate from that domain.

0010In some embodiments, the system and method can take advantage of two features of SPF. The first is the "include" mechanism, so that the SPF record references the target domain in which additional DNS SPF records are defined, and the rules defined in this reference record are included in the evaluated ruleset. Can be included in. Second, it is a macro system that allows request-specific values such as the IP address and EHLO name associated with the SMTP connection to be interpolated into the target domain.

0011In some embodiments, when configuring a domain, the SPF record encodes the name of the domain where e-mail is allowed, as well as the EHLO name and / or IP address of the SMTP connection, to the target domain name. Can be configured for domains that include "include" directives that use SPF macros in. The target domain name can be configured to be in a DNS zone managed by a targeted SPF DNS resolver, the DNS system responsible for mapping network information to a list of known mechanisms.

0012In a further embodiment, the targeted SPF DNS resolver can be responsible for responding to DNS queries against the target domain. It can also be responsible for maintaining accurate, up-to-date mappings of network information to known mechanisms, including combining public information such as domain registration records, public DNS entries, and picked information. be able to.

0013In a further embodiment, systems and methods for improving the Sender Policy Framework (SPF) are intended to reduce the overall complexity and maintenance burden presented to domain managers and to provide similar authentication. By removing the existing limitations of the latest systems in, the technology for authenticating email can be advanced. Moreover, the method may not require any changes to the system that receives the email and may be compatible with the existing and extensive base of the installed software.

0014The disclosed embodiments have advantages and features that are readily apparent from the detailed description, the appended claims, and the accompanying drawings (or drawings). A brief introduction of the figures is as follows.<figref num="1">FIG. 1 is a diagram showing an example of a system in which the validity of an e-mail sender can be verified through mediation by EHLO name and IP address targeting according to an embodiment.</figref><figref num="2">FIG. 2 is an interaction diagram and flowchart showing an example process of creating an email domain validation record for use by a third-party delivery mechanism according to one embodiment.</figref><figref num="3">FIG. 3 is an interaction diagram and a flowchart showing a process example of a solution by an email domain validation record using DNS according to one embodiment.</figref><figref num="4">FIG. 4 is a block diagram showing an example configuration of a machine capable of reading instructions from a machine-readable medium and executing instructions by a processor (or controller).</figref>

0015The figure (FIGS.) And the following description relate to a more preferred embodiment. From the following discussion, alternative embodiments of the structures and methods disclosed herein should be readily understood as viable alternatives that can be used without departing from the claimed principles. Please note.

0016Some embodiments, as well as the examples shown in the accompanying figures, are first referred to in detail. The figure shows an embodiment of the disclosed system (or method) for illustration purposes only. Those skilled in the art will readily appreciate from the description below that alternative embodiments of the structures and methods set forth herein can be used without departing from the principles set forth herein.

0017Overview of composition An embodiment disclosed as an example is a system and process that can validate an email sender through mediation by EHLO name and IP address targeting. In an embodiment, the DNS server receives a DNS query from the receiving email system for the email domain stored in the DNS server, the DNS query contains the identity of the sender of the email, and the email is: Identify itself as coming from an email domain. The DNS server extracts the e-mail sender's identification information from the DNS query and identifies one of the plurality of delivery mechanisms from the identification information. The DNS server determines if the identified delivery mechanism is allowed to deliver email on behalf of the email domain. In response to the identified delivery mechanism determining that it is allowed to deliver email on behalf of the email domain, the DNS server will identify the authorized delivery mechanism and email domain. Based on, the target validation record generates one or more rules that indicate to the receiving email system that the delivery mechanism is the authorized sender of the email for the email domain. Includes and responds to DNS queries to send target validation records to the receiving e-mail system.

0018In one embodiment, the outgoing email system is configured to create an email validation record for inclusion in the DNS record of the email domain, and the email domain validation record is emailed from the target domain. Is parsed by the receiving email system to indicate to the receiving email system whether the sender of the email is an authorized sender for the email domain. To create an email domain validation record, the outgoing email system configures the email domain validation record to include a target domain that is a domain separate from the email domain and email domain validation. When performing a syntactic analysis of the sex verification record, have the incoming email system submit a second request for the validation record to the target domain. The outgoing email system also configures the email domain validation record to include one or more macro statements that specify the identifying information, and the macro statements are sent to the incoming email system to include the email domain validation record. Have the email sender's identity included in the second request when parsing. The outgoing email system is configured to publish this created email domain validation record as a DNS record for the email domain.

0019Introduction The Sender Policy Framework (SPF) is a powerful tool for authenticating email, but it is difficult to configure and is actually in a given email domain, as it is used today. On the other hand, there are some substantive restrictions that impose a significant limit on the number of services that can be authenticated to deliver email. In some embodiments, systems and methods allow email domain owners to a) configure SPF authentication for their email domains for services rather than networking primitives, and b) configure these unlimited numbers. We can provide a supportable method.

0020Illustrative key representative system Figure 1 shows an exemplary system 100 that can validate email senders through mediation by EHLO name and IP address targeting according to embodiments. System 100 includes network 150, one or more client devices 160, allowed DNS server 130, domain owner DNS server 140, domain owner system 110, delivery email system 115, and incoming email system 120. The system 100 shown includes the elements shown in FIG. 1, but in other embodiments, the system 100 may contain different elements. Moreover, the function of each element can be distributed differently among the elements in other embodiments.

0021Network 150, which can be wired, wireless, or a combination thereof, enables communication within client devices 160, DNS systems 130/140, domain owner systems 110, and third-party systems 120, and the Internet, LAN. , VLAN (eg, with VPN), WAN, or other network. In one embodiment, the network 150 is equipped with standard communication technologies such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Uniform Resource Locator (URL), and Domain Name System (DNS). / Or use the protocol. In other embodiments, the entity may use custom and / or proprietary data communication techniques in place of or in addition to those described above.

0022The domain owner system 110 includes one or more computing systems in a particular domain (eg, examplecorp.com) and can be configured similar to the computing systems described with reference to FIG.

0023In one embodiment, the domain owner system 110 allows an incoming email system, such as the incoming email system 120, to verify the legitimacy of an email indicating the domain of the domain owner system 110 as the sender of the email. Includes a rule maker 111 that generates validation rules. When the incoming email system 120 receives such an email, it checks these validation rules to see if the email was actually sent legitimately from the domain owner system 110. can do. In one embodiment, the rule indicates the Internet Protocol (IP) address of the domain owner system 110, and therefore the receiving email system 120 verifies whether the email was received from the IP address indicated in the rule. To do.

0024These rules can be automatically generated based on the detected network characteristics (eg, the detected IP address of the outgoing email system, domain name information, etc.), or the rules are created by the administrator via the user interface. Can be received by vessel 111. After the rule is generated, rule maker 111 publishes the rule in a publicly accessible location. This publicly accessible location is a trusted location that only the domain owner can publish to the domain of the domain owner system 110. In that case, any incoming e-mail system 120 can access this public location to retrieve the rules, in one embodiment the public location is Domain Name System (DNS). Therefore, these rules may be stored in the email domain validation record 141 on the domain owner DNS server 140. In one embodiment, the rule is a Sender Policy Framework (SPF) rule, which is documented in RFCs 4408 and 7208 and incorporated herein by reference.

0025The delivery email system 115 sends an email for the domain owner system 110. The delivery e-mail system 115 comprises one or more computing systems that can be configured similar to the computing system described with reference to FIG. As an example, the delivery email system 115 is a mailing list server, a bulk mailer provider that sends email on behalf of a domain, a transactional email system managed by a third party that sends email on behalf of a domain, or on behalf of a domain. It can be a security system that scans email. The delivery e-mail system 115 can send e-mail on behalf of the domain owner system 110 so that the delivery e-mail system 115 can provide further processing or functionality for the e-mail.

0026The delivery e-mail system 115 includes an e-mail transmitter 116 for sending e-mail. In one embodiment, the email transmitter 116 uses a standard email protocol, such as Simple Mail Transfer Protocol (SMTP). SMTP supports a variety of features. In particular, when the outgoing email system communicates with the incoming email system, SMTP indicates that the outgoing email system can send HELO, or extended HELO (EHLO) messages, to the incoming email system. This HELO / EHLO message may include an identifier for the outgoing email system (eg, a domain name) and, in the case of an EHLO message, an additional identifier indicating the supported extensions and features of the outgoing email system.

0027When sending or otherwise forwarding a message or email initially sent by the domain owner system 110, it may be associated with the domain owner system 110 and stored as an email domain validation record 141. The validation rules are modified to adapt to the authentication of the delivery email system 115.

0028The receiving e-mail system 120 is an e-mail system that receives one or more e-mails from the delivery e-mail system 115. The receiving e-mail system 120 comprises one or more computing systems that may be configured similar to the computing system described with reference to FIG.

0029The receiving e-mail system 120 includes an e-mail receiver 122 for receiving e-mail. In one embodiment, the email receiver 122 uses a standard email protocol, such as Simple Mail Transfer Protocol (SMTP).

0030The incoming email system 120 includes an email authenticator 121 that validates the identification of the sender of any received email to ensure that the email is not fraudulent. Upon receiving the email, the email certifier 121 will be identified by the server that received the email (eg, by the HELO command), or the domain indicated in the return path address of the email (eg, "gmail" You can look up any relevant email domain validation records associated with either .com "), or a domain with some other identifier. The email authenticator 121 determines whether the information identified from the email, such as the sender's IP address, matches any of the rules shown in any one of the relevant email domain validation records. Or it determines if it is allowed. If a match is found in the rule, the email authenticator 121 is likely that the email message is valid and is from what is referred to as the sender, not from an unauthorized source. To decide.

0031In one embodiment, the rule shown in the email domain validation record is an SPF rule. The SPF rule can indicate an IP address, so the email certifier 121 identifies the IP address indicated in the SPF rule as the IP address of the server that sent the email to the receiving email system 120 or other identification. It is possible to verify whether the information matches. The SPF rule can also indicate another domain, in which case the email authenticator 121 looks up the SPF rule record for that other domain and any rule in that record sent the email. You can check if it matches the identification information of the server. In some more cases, SPF rules support macros, which are special placeholder indicators that the email authenticator 121 replaces with dynamically determined data when receiving an email. For example, email authenticator 121 can extend macros such as "% {d}" indicated by rules for email return path domains (eg, "acme.com"). Further macro commands are SPF More detailed in RFC 7208, and 4408.

0032DNS servers 130 and 140 store DNS records for use in DNS systems. Each DNS server can include one or more computing systems, such as the computing system described with reference to FIG.

0033Each DNS server can store multiple DNS records for a particular domain, such as A records, MX records, and so on, as is known in the art. The record is separated into multiple entries and is on multiple servers, as shown in FIG. 1, but in other embodiments the record is less entries, a single server, a single. Combined into an entry or some other combination. Further, while a certain number of records are shown for each domain in FIG. 1, in other embodiments, each domain can have a plurality of records.

0034As shown in FIG. 1, the domain owner DNS server 140 contains an email domain validation record 141. This email domain validation record 141 can include one or more rules that allow the receiving email system 120 to validate the validity of the received email. As mentioned above, the email domain validation record 141 can indicate the IP address or other identifier for the sender associated with the domain, so the incoming email system 120 sends the email. The person's IP address (or other identifier) corresponds to the domain indicated in the email (for example, the email from "acmebank.com" is actually Acme It can be verified that it is from Bank). However, such simple rules can be disadvantageous if a third-party delivery email system 115 is used to send email on behalf of the outgoing email system or domain owner. This is because the rules in the email domain validation record 141 may not indicate that the delivery email system 115 is a valid sender for a particular domain.

0035Alternatively, the email domain validation record 141 can include rules with separate domains. DNS records for this separate domain can exist somewhere else, such as on a allowed DNS server 130. In addition, this rule with separate domains also contains one or more macros, and when syntactically parsed by the incoming email system 120, the incoming email system 120 receives the email. Have the macro replaced with additional information that identifies the server, or other identification information about the email. In one embodiment, this information includes any identifier in an EHLO message from the server on which the receiving e-mail system 120 received the e-mail, as well as the IP address of the same server. After the rule is parsed, the incoming e-mail system 120 queries the DNS record of the separate domain indicated by the rule. For example, a rule can indicate a domain with the macro "% {i} ._ip.verifier.com". After expansion, the macro "% {i}" can be replaced by the IP address of the server that sent the email to the receiving email system 120 (eg, this could be the delivery email system 115). The receiving e-mail system 120 also queries for the DNS record of the domain "verifier.com" and passes the IP address to a DNS server that can provide the DNS record in question.

0036DNS records for this separate domain can exist (or can be queried) on the authorized DNS server 130. The authorized DNS server 130 includes a distributor / IP storage device 131 that stores information about the delivery email system, as well as their associated IP addresses and EHLO information. The permitting DNS server 130 also includes a distributor / record storage device that stores rules for authenticating various delivery email systems. The authorized DNS server 130 also includes an authorized distributor list 132 showing the authorized delivery email systems for various domains.

0037As mentioned above, when the macro is replaced by the identification information of the server that sent the email, the domain information is received from the receiving email system 120 in the DNS query by the allowed DNS server 130. The permitting DNS server 130 includes a permit evaluator 135 that determines whether the server indicated by the identifying information is allowed to send e-mail for the domain indicated by the identifying information. In one embodiment, the domain is indicated by the EHLO information passed (by using macros) to the allowed DNS server 130, and the identifying information about the server is passed by IP address. The authorization evaluator 135 accesses the distributor / IP storage device 131 to determine the identification of the delivery email system 115 associated with the identification information. If such information is found, the authorization evaluator authorizes the delivery email system to determine if it is an authorized delivery agent for the domain indicated in the DNS query identity. Access the distributor list 132.

0038If so, the permitting DNS server 130 includes a target record constructor 133 that configures a set of rules using the distributor / record storage 134 as a response (to send) to the incoming e-mail system 130. .. This set of configured rules indicates that the delivery email system that sent the email (eg, delivery email system 115) is a valid sender for the domain indicated in the email. The receiving email system 130 can then use the information in its response to verify that the delivering email system is a valid sender and that this email can be received by its intended recipient. it can. In other cases, if the delivery e-mail system indicates that the delivery e-mail system is not valid, the receiving e-mail system 130 may instead discard or flag the e-mail.

0039The client device 160 may be used to view email received and authenticated by the incoming email system 120. The client device 160 can include a computing system, such as the computing system described with reference to FIG.

0040Specifically, the client device 160 includes an email client 165 for interfacing with the incoming email system 120. E-mail client 165 uses standard e-mail such as Post Office Protocol 3 (POP3), Internet Message Access Protocol (IMAP), Messaging AIP (MAIP), SMTP, and the like to communicate with the incoming e-mail system 120. You can use the mail protocol. In one embodiment, if the email is not properly authenticated by the receiving email system 120, the email client 165 will not receive the email. In other embodiments, the email client 165 can receive email, but can also receive instructions that the email is suspected or suspected to be fraudulent.

0041Using System 100 as described above, domain owners can use other third-party delivery mechanisms and the services of their delivery email system to send email, and in addition, The incoming email system 120 can be made to validate these emails as legitimate. Instead of updating various email domain validation records, the DNS server identifies in a centralized location the delivery email system 115 that sent the email, as received from the incoming email system 120. Depending on the information, a simple set of rules can be constructed. In addition, the incoming email system 120 does not need to query a large number of DNS records that may be present in the rules in the email domain validation record. This improves performance and simplifies the management of sending email by third-party agents, but still provides security and prevents the receipt of fraudulent or suspicious messages. .. Further details regarding the system and processing described above will be described with reference to FIGS. 2-3.

0042Illustrative Dialogue on Creating Email Domain Validation Records FIG. 2 is a dialogue diagram and a flow diagram illustrating an exemplary process of creating an email domain validation record for use by a third-party delivery mechanism according to one embodiment. In one embodiment, FIG. 2 assigns operations in the process to the indicated elements. However, some or all of the steps can be performed by other factors. In addition, some embodiments may perform operations in parallel, perform operations in different orders, or perform different operations. Further note that in one exemplary embodiment, the steps and / or modules can be executed by the processor 402 described with respect to FIG. 4, for example, as an instruction such as instruction 424.

0043In this discussion, the email domain refers to any domain that the incoming email system 120 can use as a "domain" when evaluating the SPF for incoming email messages. This is usually the domain found in the return path for the message.

0044The email domain owner, or the designated party, the domain owner system 110, can configure DNS records for the email domain. This can include creating (or generating) 210 email domain validation records (which can be SPF records) for use with email domains. Record a particular sender, email from an email domain indicates a valid sender for Le. In one embodiment, the record is an SPF record and is configured to include a unique "include" directive. The include directive can indicate a targeted SPF domain specification that points to another domain, so some or all of the SPF authentication decisions for messages are delayed to SPF records found in other domains. (deferred). In other words, as mentioned above, the record contains separate domains that are queried separately to determine the final SPF credentials.

0045In one embodiment, the targeted SPF domain specification in email domain validation record 141 can be configured to dynamically change the behavior for email messages based on the SMTP connection attributes for that message. This change was achieved by having the receiving server use the SMTP connection attributes and the email domain to build a custom domain name that yields a targeted SPF record that will be applied to the messages that are processed when resolved. Can be done.

0046To achieve this, in one embodiment, the targeted SPF domain specification can include three characteristics. First, it is the targeted DNS SPF resolver (eg, the allowed DNS server 130) that has the ultimate authority over any domain name resolved from the targeted SPF domain specification.

0047This can be achieved by ensuring that the targeted domain specification is finally broken down into subdomains of one or more specific fixed domains. In some implementations, DNS records containing a targeted SPF domain specification can be hidden behind one or more DNS CNAME or NS records that reference other domains and are not managed by the targeted DNS SPF resolver. This allows for the transfer or masking of the final DNS query target. In other words, other domains may need to be queried by the incoming email system before the final DNS query target is determined.

0048Second, the targeted SPF domain specification can force the incoming email system 120 to capture the EHLO name and / or IP address for the SMTP connection. These values can be captured using the SPF macro system. The% {h} macro can be used to capture EHLO names, and the% {i} or% {p} macros can be used to capture IP addresses or domain names whose IP addresses have been validated. Can be used for. In some embodiments, the domain owner system 110 also uses the% {l} and / or% {s} macros on the incoming email system 120 to provide a local part of the sender address, or the full sender. The targeted SPF domain specification can be configured to capture the address and encode the resulting value into the targeted SPF domain specification.

0049Depending on the exact configuration of the system, one or more of the optional transducers written in the SPF macro language may apply to the targeted SPF domain specification. Similarly, use the uppercase variants% {H},% {I},% {P},% {L}, or% {S} instead so that the result is an encoded URL. be able to.

0050Third, the targeted SPF domain specification can be configured so that the SMTP connection attributes can be clearly parsed from the resulting domain, which can actually be achieved for real-world systems.

0051To demonstrate this, a format for targeted SPF domain specifications that meet these three requirements can be configured. For example, assume that the targeted DNS SPF resolver (eg, the allowed DNS server 130) supports all DNS TXT queries in the zone defined by the domain "resolver.com". Furthermore, the email domain is assumed to be "emaildomain.com". Finally, assume that both the EHLO name and IP address are captured.

0052In this case, the letter-number-hyphen (LDH) rule may be used for the host name. These rules include a restriction that the fully qualified domain name (FQDN) can only contain ASCII characters, numbers, or hyphen symbols. More generally, the domain containing the one used for SPF record references does not have to meet this limitation. Both the EHLO name and the email domain must be FQDNs, so if you create a targeted SPF domain specification with a label that contains a non-LDH symbol such as "_", these fields are set by the domain owner system 110. Can be separated. A label containing an IP address cannot also contain a "_", as an IP address can consist only of numbers (IPv4) or numbers and letters a ~ f (IPv6). Therefore, labels containing "_" can also be used as separators for these values.

0053Combining all of the above, one targeted SPF domain specification that meets the requirements contained in the exemplary context is "% {i} ._ ipaddr.% {H} ._ehlo.emaildomain.com._tspf.resolver. com ". Any domain name interpolated during the SPF process from this domain specification will be based on "resolver.com" (the domain shown on the far right). It includes both the EHLO name and the IP address in the domain name. In addition, the use of labels containing "_" supports clear parsing of SMTP attributes from such domain names.

0054It should be noted that there are many formats that may meet these requirements and this particular example should be considered non-limiting.

0055In that case, the email domain validation record 141 should have an SPF rule with an include directive that references the targeted SPF domain specification mentioned above. A simple, non-limiting example of such a record using the example targeted SPF domain specification mentioned above is "v = spf1 include:% {i} ._ ipaddr.% {H} ._ehlo.emaildomain". .com ._tspf.resolver.com ". Again, this record should be considered realistic, but non-limiting, with respect to our example. Note that the "v" refers to the SPF version, and the include directive indicates that the domain indicated is a valid sender for the email domain.

0056After the email domain validation record 141 is configured, it can be published as a DNS TXT record for the email domain (for example, on the domain owner DNS server 140) 215. This allows it to be queried by any server that receives an email indicating this domain.

0057Illustrative Dialogue on Email Verification Rule Resolution FIG. 3 is a dialogue diagram and a flow diagram showing an exemplary process for resolving an email domain validation record using DNS according to one embodiment. In one embodiment, FIG. 3 assigns operations in the process to the indicated elements. But some or all of the steps can be performed by other factors. In addition, some embodiments may perform operations in parallel, perform operations in different orders, or perform different operations. Further note that in one exemplary embodiment, the steps and / or modules can be executed by the processor 402 described with respect to FIG. 4, for example, as an instruction such as instruction 424. It should be noted that the process described herein does not necessarily require any further modification or configuration of the incoming email system 120. Otherwise, as long as the incoming email system 120 supports SPF or a similar sender authentication method, it does not need to be changed.

0058First, the receiving e-mail system 120 receives e-mail with a return path corresponding to a particular e-mail domain 310. The receiving e-mail system 120 can attempt to authenticate this e-mail message (eg, using SPF). The incoming email system 120 can first query DNS for any email validation records for that email domain 315. These can be SPF records. The domain owner DNS server 140 can return the email domain validation record 141 published by the email domain owner in response, as described with reference to Figure 2 282.

0059The incoming email system 120 parses the email validation record and generates a target domain query 320. This process uses the value for the current SMTP connection (eg EHLO, IP address) to evaluate the include directive with the target domain SPF specification in the returned DNS record, and to configure the target domain. Interpolating these values can be included in the target domain SPF specification. For example, if the record shows the rule "% {i} ._ ipaddr.% {H} ._ehlo.emaildomain.com._tspf.resolver.com", the receiving email system 120 will call this "123.123. It can be evaluated as "123.123._ipaddr.deliveringdomain.com._ehlo.emaildomain.com._tspf.resolver.com", where 123.123.123.123 is the sender's IP address and emaildomain.com is the sender's sender. And deliveringdomain.com is the domain name indicated in the EHLO message to the sender.

0060The incoming email system 120 then queries DNS for the target domain 325. This query can be answered by an authorized DNS server 130 (which can be an authoritative server for the target domain). Domain owner DNS server 130 extracts identification information from the query 340. This identification information can include the EHLO name and IP address and can be syntactically parsed from the target domain query. In one embodiment, the domain owner DNS server 130 also parses the local part of the return path address from the target domain of the query, either as a stand-alone value or as part of the full encoded sender address. be able to.

0061In one embodiment, the domain owner DNS server 130 also extracts the email domain from the target domain query (if it is included in the query by macro). If an email domain exists and the domain owner DNS server 130 is configured to handle only requests for a limited set of domains, then the domain owner DNS server 130 knows the email domain. It can be determined whether or not there is. In this case, if the email domain is unknown, the domain owner DNS server 130 may return a default SPF record. The returned record is likely to be a record that does not accept any IP address, for example "v = spf1- ~ all".

0062The domain owner DNS server 130 uses the identification information extracted from the query to identify the delivery mechanism 345. The delivery mechanism is the owner of the delivery email system 115, which may not be part of the email domain. Domain owner DNS server 130 allows network-specific information associated with SMTP connections for email messages (eg, EHLO name and / or outbound server IP address) to be associated with a high level of abstraction of the delivery mechanism. Includes a distributor / IP storage device 131 that associates the identification information extracted from the query with the distribution mechanism.

0063Some examples of common delivery mechanisms are third-party senders contracted to send email by email domain owners, relaying messages originating from email domains to several receiving addresses. A forwarding system designed to alias an existing mailing list or one receiver address. The set in this example should not be considered exhaustive and the list should be considered non-limiting.

0064In one embodiment, access to the header information of a substantial (ie, statistically significant) corpus (hundreds of millions or more messages) of an email is made to the domain owner DNS server 130 or other entity. Distributor / IP storage 131 can be configured by using the information found in the email headers (especially the "received" and "authentication result" headers). In other embodiments, the list of distribution mechanisms can be examined and the results incorporated into the appropriate distributor / IP storage device 131. In a further embodiment, the domain registration record, which is the information stored in the WHOIS database in particular, can be useful in constructing this mapping for distributor / IP storage 131. These exemplary methods should be considered non-limiting and the processes described herein are other methods, or a plurality of, for configuring distributor / IP storage 131. It does not preclude the use of a combination of methods.

0065In a further embodiment, the incoming stream of DNS queries received by the domain owner DNS server 130 can be used as a source for EHLO names and IP addresses that need to be investigated. For a complete database, all combinations of (EHLO names and IP addresses) originating from legitimate emails should be mapped to known delivery mechanisms. Any incoming data that cannot be mapped to a known delivery mechanism can generally indicate a) a legitimate value lost in the database, or b) an incorrect source email. This "miss" can therefore serve as a source of information to fill gaps in the database, or as a source of threat information.

0066After the request is mapped to the delivery mechanism, in one embodiment, the domain owner DNS server 130 can determine if the delivery mechanism is known 348. If not known, it can return default records, including some variants of SPF records where all IP addresses are incorrect. For example, "v = spf1 ~ all" is a possible option.

0067Assuming that the delivery mechanism is known, the domain owner DNS server 130 determines whether the delivery mechanism is allowed to deliver the email for the email domain indicated in the query for the target domain. Can be 350. In one embodiment, the domain owner DNS server 130 allows any identified delivery mechanism to deliver email to any email domain. In other embodiments, the mapping of email domains to authorized delivery mechanisms can be stored in the authorized distributor list 132 or made available via the web API, and can also be made available to the domain owner. The DNS server 130 accesses the list or API to determine if the delivery mechanism is allowed.

0068If the identified delivery mechanism is not found to be allowed for the email domain, the domain owner DNS server 130 may return a default record. In general, this can be a record that denies delivery to all IP addresses (eg "v = spf1 ~ all").

0069As mentioned above, in one embodiment, the local part of the return path address may be encoded during the query of the target domain, either as a stand-alone value or as part of the sender address. In these embodiments, the domain owner DNS server 130, in combination with the email domain, determines whether the delivery mechanism is allowed to deliver a particular message to the local part of the email address. To use. For example, a delivery agency may be allowed to send an email for "newsletter@acme.com" rather than for a return pass address that has a local part indicating the employee's email address at acme.com.

0070If the delivery mechanism is allowed to deliver email to the email domain, the domain owner DNS server 130 can be a target validation record (SPF record) based on the delivery mechanism and the email domain. ) To generate 355. To configure this record, the domain owner DNS server 130 can query the distributor / record storage 134 that contains a map to the target validation record of the distribution mechanism.

0071For each delivery mechanism, some virtual that allows mail from the server used by that delivery mechanism (eg, delivery email system 115) and rejects email originating from any other. Email validation records can exist. This means that any delivery mechanism that has a well-configured email domain validation record (eg, an SPF record) can use an existing email domain validation record for the delivery mechanism. It should also be true.

0072The domain owner DNS server 130 or administrator is given sufficient knowledge of the underlying network configuration, even if the delivery mechanism does not have a well-configured email domain validation record. And it is possible to build such a record. In one embodiment, the domain owner DNS server 130 creates and stores an email domain validation record for a delivery mechanism and / or for an email domain that is not otherwise available by the delivery mechanism.

0073In some embodiments, and for some configurations, the distributor / record storage 134 also targets the email domain and / or local path as a replacement or capture for the association of the delivery mechanism. Associate with a validation record. As an example where such a variant may be desirable, consider a delivery mechanism that further divides the cloud of a mail server by an email domain. In such situations, it may be necessary to know the email domain in combination with the delivery mechanism in order to deliver the optimal target validation record.

0074In some embodiments, the existing email domain validation record can be an important source of information for configuring the distributor / record storage device 134. For example, in the case of SPF records, existing records for the delivery mechanism can be used to get a list of directives. In other embodiments, manual investigation of the delivery mechanism can also be a good source of this information. In a further embodiment, a further method using a combination of sources is also feasible. The sources listed here should be considered non-limiting.

0075If these, or any other, method is used to configure distributor / record storage 134, the underlying network configuration will change over time and it may be necessary to update the data. .. In some embodiments, the domain owner DNS server 130 can use a polling mechanism to update the distributor / record storage 134, but in other embodiments it is different. A non-limiting example of such a polling mechanism is a domain owner DNS server 130 that performs regular (eg, daily) DNS queries to detect updates to DNS records published by known senders. It should be the software component above. These updates can then be incorporated into the database by the domain owner DNS server 130.

0076After generating the target validation record, the domain owner DNS server 130 sends the record back to the incoming mail system 120 in response to the original query 360.

0077The incoming mail system 120 authenticates the email message using the received target validation record 330.

0078In one embodiment, as described above, instead of using the SPF's "include" mechanism, the system described herein is an "a", "mx", or "s" that is part of the SPF. Can be configured to use the "exists" mechanism. If one of these mechanisms is used, the behavior of the email domain owner can be almost invariant, i.e. the "a", "mx", or "exists" mechanism is in this case the "include" mechanism. Just replace it with.

0079Under this variant, the behavior of the domain owner DNS server 130 remains largely unchanged except for the value it returns. If the domain owner DNS server 130 indicates that the message is not authenticated, the domain owner DNS server 130 can return the NXDOMAIN code. Also, instead of returning a target validation record, the permitting DNS server 130 can match the IP address to the target validation record. If the IP address does not match the record, the domain owner DNS server 130 can return NXDOMAIN. Alternatively, if the IP address is found to match, the domain owner DNS server 130 can return an A, MX, or A record containing the IP address.

0080In one embodiment, the domain owner DNS server 130 is used as a remote SPF audit tool. SPF resolution is performed on the incoming e-mail system 120, and therefore the results of its evaluation cannot generally be made available to an external audit system unless specialized software is installed. If the targeted SPF domain specification is structured to include both an EHLO name and an IP address, the domain owner DNS server 130 will tell each (EHLO name, IP address) combination from which the message is delivered. Can be called at least once. With this information, the resolver can mirror the SPF evaluation performed by the incoming email system 120 and record the corresponding results.

0081Illustrative machine architecture FIG. 4 is a block diagram showing an exemplary machine component capable of reading instructions from a machine-readable medium and executing the instructions on a processor (or controller). Specifically, FIG. 4 illustrates a schematic representation of a machine in an exemplary form of computer system 400. The computer system 400 is used to execute instruction 424 (eg, program code or software) to cause a machine to perform any one or more of the methods (or processes) described herein. Can be used. In an alternative embodiment, the machine operates as a stand-alone device or as a connected (eg, networked) device connected to another machine. In a networked deployment, the machine can act as a server machine or client machine in a server / client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

0082A machine can be a server computer, client computer, personal computer (PC), tablet PC, set-top box (STB), smartphone, Internet of Things (IoT) device, network router, switch or bridge, or any action taken by that machine. It can be any machine that can execute the specified instruction 424 (sequentially or otherwise). Further, although only a single machine is shown, the term "machine" also executes instruction 424 individually or jointly to include any one or more of the methods discussed herein. It should be interpreted to include any collection of machines to perform.

0083An exemplary computer system 400 includes one or more processing units (typically processor 402). Processor 402 may be, for example, a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), controller, state machine, one or more application specific integrated circuits (ASIC), one or more. A high frequency integrated circuit (RFIC), or any combination thereof. The computer system 400 also includes a main memory 404. The computer system can include a storage unit 416. Processor 402, memory 404, and storage unit 416 communicate via bus 408.

0084Further, the computer system 406 can include a static memory 406, a display driver 410 (eg, for driving a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). The computer system 400 also includes an alphanumeric input device 412 (eg keyboard), a cursor control device 414 (eg mouse, trackball, joystick, motion sensor, or other indicating device), signal generation device 418 (eg speaker). , And network interface devices 420, which are also configured to communicate over bus 408.

0085The storage unit 416 includes a machine-readable medium 422 that stores instructions 424 (eg, software) that perform any one or more of the methods or functions described herein. Instruction 424 can also reside entirely or at least partially in main memory 404 or in processor 402 during its execution by computer system 400 (eg, in processor cache memory). The main memory 404 and the processor 402 also constitute a machine-readable medium. Instruction 424 may be transmitted or received via network 426 by network interface device 420.

0086Although the machine-readable medium 422 is shown in an exemplary embodiment as a single medium, the term "machine-readable medium" is a single medium or multiple media (which can store instructions 424). For example, it should be construed as including a centralized or distributed database, or associated caches and servers). The term "machine readable medium" is also intended to include any medium capable of storing instruction 424 to be performed by the machine and to cause the machine to perform any one or more of the methods disclosed herein. It should be interpreted. The term "machine readable medium" includes, but is not limited to, data repositories in the form of solid state memory, optical media, and magnetic media.

0087Further considerations Using the systems and processes described above, domain owners can utilize the services of other third-party delivery mechanisms and their delivery email systems to send email, yet these The e-mail can be validated by the receiving e-mail system as legitimate. Instead of updating various email domain validation records, the DNS server identifies the delivery email system that sent the email in a centralized location, as received from the incoming email system. Generate a simple set of rules informed. In addition, the incoming email system does not need to query the large number of DNS records that may exist in the rules in the email domain validation records. This improves performance and simplifies the management of sending email by third-party agents, but still provides security and prevents the receipt of fraudulent or suspicious messages.

0088Throughout the specification, a plurality of examples may implement the components, actions, or structures described as a single example. Although the individual operations of one or more methods are shown and described as separate operations, one or more of the individual operations can also be performed simultaneously and the operations, It does not have to be performed in the order shown. In the exemplary configuration, the structures and functions shown as separate components can be implemented as combined structures or components. Similarly, structures and functions presented as a single component can be implemented as separate components. These and other modifications, changes, additions, and improvements are within the scope of the subject matter herein.

0089Some embodiments are described herein as including logic, or some components, modules, or mechanisms, for example, as shown in FIGS. 1-4. Modules can be either software modules (eg, code implemented on machine-readable media or in transmitted signals) or hardware modules. A hardware module is a tangible unit that can perform several operations and can be configured or arranged in a certain way. In an exemplary embodiment, one or more computer systems (eg, stand-alone, client, or server computer systems), or one or more hardware modules of a computer system (eg, processors, or groups of processors). It may be configured by software (eg, an application or an application portion) as a hardware module that operates to perform some of the operations described herein.

0090In various embodiments, the hardware module can be implemented mechanically or electronically. For example, a hardware module is dedicated to be permanently configured (as a dedicated processor, such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC)) to perform some operations. Circuit or logic can be provided. Hardware modules may also contain programmable logic or circuits (eg, contained within a general purpose processor or other programmable processor) that are temporarily configured to perform some operations by the software. it can. The decision to make a hardware module in a circuit that is mechanically or temporarily configured (eg, software) with a dedicated and permanently configured circuit is by considering cost and time. Can be done.

0091The various operations of the exemplary methods described herein are at least by one or more processors that are temporarily (in software) or permanently configured to perform the associated operation. Can be partially implemented. Such a processor, whether temporarily or permanently configured, constitutes a module performed by a processor operating to perform one or more operations or functions. Can be done. Modules referred to herein can include modules implemented in a processor in some exemplary embodiments.

0092One or more processors can also operate in a "cloud computing" environment or as "software as a service" (SaaS) to support the performance of related operations. For example, at least some operations can be performed by a group of computers (eg, a machine containing a processor), and these operations can be performed over a network (eg, the Internet) and one or more suitable operations. It is accessible through various interfaces (eg, application program interface (API)).

0093The performance of some operations may not only reside within a single machine, but may be distributed among one or more processors deployed across several machines. In some exemplary embodiments, one or more processors, or modules implemented on processors, are located in a single geographic location (eg, in a home environment, office environment, or server farm). Can be done. In other exemplary embodiments, one or more processors, or modules implemented on the processors, may be distributed across several geographic locations.

0094Some parts of the specification are presented by algorithms or symbolic representations of operations on data stored as bit or binary digital signals in machine memory (eg, computer memory). These algorithms or symbolic representations are examples of techniques used by those skilled in the art in data processing techniques to convey the content of their achievements to those skilled in the art. As used herein, an "algorithm" is a sequence of self-consistent operations, or similar processing, that leads to the desired result. In this context, algorithms and operations include physical manipulation of physical quantities. Usually, but not necessarily, such quantities are of electrical, magnetic, or optical signals that can be stored, accessed, transferred, combined, compared, or otherwise manipulated by the machine. Can take form. Using terms such as "data", "content", "bits", "values", "elements", "symbols", "characters", "terms", "numbers", "numbers", or similar Referencing such signals is often convenient primarily for general use. However, these terms are merely convenient labels and should be associated with appropriate physical quantities.

0095Unless otherwise stated otherwise, "process", "use a computer", "calculate", "determine", "present", "display", or the like herein. Discussions that use terms such as one or more memories (eg, volatile memory, non-volatile memory, or a combination thereof), registers, or other machines that receive, store, transmit, or display information. It can refer to a machine (eg, computer) action or process that manipulates or transforms data, represented as a physical (eg, electronic, magnetic, or optical) quantity contained in a component.

0096As used herein, "one embodiment", or any reference to an "embodiment," has at least one particular element, function, structure, or property described in connection with the embodiment. It means that it is included in the embodiment. The appearance of the phrase "in one embodiment" in various places herein does not necessarily refer to the same embodiment.

0097Some embodiments can be described using the expressions "combined" and "connected" with their derivatives. For example, some embodiments can be described using the term "combined" to indicate that the two or more elements are in direct, physical, or electrical contact. However, the term "combined" can also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. The embodiments are not limited to this context.

0098As used herein, the terms "includes", "comprising", "includes", "including", "has", "has", "includes", "includes", "includes", "includes", "includes" "Having", or any other variant thereof, is intended to include non-exclusive inclusion. For example, a process, method, article, or device that includes a list of elements is not necessarily limited to these elements, but other elements that are not explicitly listed, or such processes, methods, articles. , Or other elements specific to the device or the like. Moreover, unless the opposite is explicitly stated, "or" refers to inclusive or, not exclusive or. For example, condition A or B is satisfied by one of the following: A is true (or exists), B is false (or nonexistent), and A is false (or nonexistent). ), B is true (or exists), and both A and B are true (or exist).

0099In addition, the use of "a", or "an" is used to describe the elements and components of the embodiments herein. This is done solely for convenience and merely gives the general meaning of the present invention. This description should be read to include one, or at least one, and the singular form also includes multiples unless it is clear that it means the other form.

0100After reading this disclosure, one of ordinary skill in the art will understand additional and alternative structural and functional designs for systems and processes that can validate email senders through mediation through EHLO name and IP address targeting. Will be done. Therefore, although specific embodiments and uses have been shown and described, it should be understood that the disclosed embodiments are not limited to the exact components and components disclosed herein. Various modifications, changes, and modifications that should be apparent to those skilled in the art, without departing from the spirit and scope defined in the appended claims, are the arrangements of methods and devices disclosed herein. The operation, as well as its details, can be done.