Patent Description:
The disclosure generally relates to the field of electronic messaging, and specifically to entity-separated email domain authentication for known and open sign-up domains.

While services such as Domain-based Message Authentication, Reporting and Conformance (DMARC) and Sender Policy Framework (SPF) can be used to validate emails to prevent email spoofing, i.e., the sending of emails using forged email addresses, these services do not prevent the receipt of emails which are from fraudulent domains masquerading as legitimate ones. For example, a malicious user may register the domain "acmee. com" and send emails from that domain, without email spoofing, to unsuspecting users who may accidentally understand the domain to be from the legitimate domain of "acme. " Some secure email gateways may send emails to a central system for checking email domains against simple blacklists or whitelists. However, such an approach may generate many false positives and negatives, while also creating a security vulnerability by transmitting emails, which may contain sensitive information, to a central repository. Such systems may also not be able to deal properly with emails from open sign up domains (e.g., free email services).

Hence, what is lacking, inter alia, is an ability to transparently and securely police email domains in a receiving email system.

United States patent application <CIT> discloses a mechanism for identifying the true source of a received email message. United States patent <CIT> discloses a system and method for filtering undesirable e-mail with forced nonexistent sender addresses in real time without sending a message to that sender.

The disclosed embodiments have advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.

The Figures (FIGS. ) and the following description relate to preferred embodiments by way of illustration only.

Figure (<FIG> illustrates an exemplary system for validating email domains, according to an embodiment. The system <NUM> includes a network <NUM>, a delivering email system <NUM>, a receiving email system <NUM>, an email validation system <NUM>, a domain owner system <NUM>, one or more client device <NUM>, and a contacts manager system <NUM>. Although the illustrated system <NUM> includes the elements shown in <FIG>, in other embodiments the system <NUM> may include different elements or a different number of elements. For example, there may be multiple receiving email systems <NUM> or other elements. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.

The network <NUM>, which can be wired, wireless, or a combination thereof, enables communications among at least the elements shown, and may include the Internet, a LAN, VLAN (e.g., with VPN), WAN, or other network. For example, some of the elements, such as the client device <NUM> and receiving email system <NUM> may communicate with each other using a LAN, making at least some of the communications between these entities hidden to the external WAN or Internet with which the other elements, such as the delivering email system <NUM>, are connected. In one embodiment, the network <NUM> uses standard communications technologies and/or protocols, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Uniform Resource Locators (URLs), and the Doman Name System (DNS). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

The client device <NUM> receives emails for a user from the receiving email system <NUM> for presentation to the user. The client device <NUM> may comprise a computing system such as the computing system described with reference to <FIG>.

The client device <NUM> includes an email client <NUM> to interface with the receiving email system <NUM>. The email client <NUM> may be a web browser, client application, or other interface which communicates with the receiving email system <NUM> to allow a user of the client device <NUM> to access the user's email account. This access includes the ability to send and receive emails, and to enter contacts into a contact list. In the case where the email client <NUM> is a web browser, the receiving email system <NUM> may provide a web interface to allow the web browser to access the user's email account via the web interface. The actual emails, contacts information, and other data may be stored at the client device, such as in a cache, etc., or externally, e.g., at the receiving email system <NUM>. In one embodiment, if a received email is not properly validated by the receiving email system <NUM>, the email client <NUM> may not be able to access the email. In other embodiments, the email the client <NUM> may be able to access the email but also receive an indication (e.g., an alert) that the email is suspected to be fraudulent or suspicious. Such an email may be accessible by the email client <NUM> in a separate section of the interface provided by the receiving email system <NUM>, such as in a spam folder.

The contacts manager system <NUM> comprises one or more network attached systems that store email addresses for known contacts of users with accounts at the receiving email system <NUM>. user contact. The contacts manager system <NUM> may be part of the receiving email system <NUM>, may be a component in a cloud-based system executing on one or more computing devices of cloud infrastructure provider, or may be a standalone computing device or set of computing devices, similar to the computing devices described with reference to <FIG>. The email addresses stored in the contacts manager system <NUM> are stored in the user contact list <NUM>. The email addresses stored in the contacts manager system <NUM> may derive from several sources. Some may come from lists of contacts with email addresses, generated and maintained by the individual users of the receiving mail system. Users may update contact lists on a number of systems. In some implementations this may include a web-based interface or an installed email client, such as email client <NUM>. Each contact in the user contact list <NUM> can be associated with the user who entered the contact. Contacts may be added to the list on a per-group, domain or system wide basis by an administrator. As described in further detail below, the email addresses in the user contact list <NUM> may be used by the receiving email system <NUM> to validate emails which have sender addresses matching email addresses in this user contact list <NUM>.

The delivering email system <NUM> delivers or sends emails for or on behalf of a domain owner, such as the domain owner system <NUM>. In some embodiments, the delivering email system <NUM> includes one or more systems that may be configured similarly to the computing system described with reference to <FIG>. As an example, the delivering email system <NUM> may be a mailing list server, a bulk email provider that sends emails on behalf of a domain, a transactional email system managed by a third party that sends emails on behalf of a domain, or a security system that scans emails on behalf of a domain. The delivering email system <NUM> may send email on behalf of the domain owner and may also provide additional processing or functionality for the sent emails. Alternatively, the delivering email system <NUM> may be part of the domain owner, e.g., the delivering email system <NUM> is a subsystem within the domain owner's system.

The delivering email system <NUM> includes an email sender <NUM> to process and send emails. In one example embodiment, the email sender <NUM> uses standard mail protocols, such as Simple Mail Transfer Protocol (SMTP) in order to deliver emails. These emails may be delivered to other domains, such as the one associated with the receiving email system <NUM>.

The receiving email system <NUM> receives emails bound for a domain associated with the receiving email system <NUM>. For example, the receiving email system <NUM> may receive emails from the delivering email system <NUM>. In one embodiment, the receiving email system <NUM> comprises one or more computing systems, which may be configured similarly to the computing system described with reference to <FIG>. In another embodiment, the receiving email system may be a component of a cloud-based system and may execute on one or more computing systems of a cloud infrastructure provider.

The receiving email system <NUM> includes an email receiver <NUM> to receive emails, and an email validation agent <NUM> to validate the received emails in conjunction with the email validation system <NUM>. In one embodiment, the email receiver <NUM> uses standard mail protocols, such as Simple Mail Transfer Protocol (SMTP), to receive emails bound for addresses associated with a domain for which the receiving email system <NUM> is associated. For example, this domain could be a domain stored in an MX record on a DNS system of an organization associated with the receiving email system <NUM>. Any emails which are addressed to this domain may be transmitted to the receiving email system <NUM>, and in response the email receiver <NUM> may process these emails. The email receiver <NUM>, after receiving these emails, may transmit them to the email validation agent <NUM> for validation, or may in some cases, directly process these emails and send them to an email storage location of a user associated with the recipient email address of the email (i.e., the address indicated in a "To" section of the email).

The email validation agent <NUM> validates emails by, in some cases, determining whether an email that claims to have come from a domain was actually sent from that domain or authorized by that domain (e.g., the domain owner). For example, if an email purports to come from the domain "acme. com," the email authenticator <NUM> determines whether the "acme. com" domain actually sent the email, or whether an owner of the "acme. com" domain authorized the sender of the email to send on behalf of the "acme. com" domain. Thus, the email authenticator <NUM> operates to prevent email spoofing. The domain of a received email may be specified in the envelope or header of the email, such as in the Return-path address, or in a From section, etc. of the email. To validate a received email, the email authenticator <NUM> may submit one or more pieces of validation information for the email to the email validation system <NUM>. This validation information may include an identifier of the sender address or domain, the receiver address or domain (i.e., the address the email is being sent to). The sender address may be hashed or otherwise obfuscated to protect the privacy of the sender.

The email validation agent <NUM> receives, after sending the validation information of the email to the email validation system <NUM>, a response from the email validation system <NUM> indicating whether the email is valid, i.e., whether it is from a known domain and/or sender. A known domain is a domain that is owned or represented by the organization (or entity) for which the domain purports to be. If the email is valid, the email validation agent <NUM> may store the email for later access, e.g., at the email store <NUM>. The stored email is associated with the account of the user that matches the recipient(s) indicated in the email. Instead, if the email is not valid, then the email validation agent <NUM> may send a notification to an administrator, quarantine the email, or perform some other remediation action against the email.

The email validation agent <NUM> may perform other actions, such as receiving the user contact list <NUM> associated with the receiving email system <NUM>. The email validation agent <NUM> hashes the email addresses in these authorized contacts lists <NUM>, and transmits the hashed email addresses to the email validation system <NUM>. These hashed email addresses may further be used to validate emails that are sent from these addresses. In one embodiment, the email validation agent <NUM> may be a separate software package executing on the receiving email system <NUM>. In another embodiment, the email validation agent <NUM> may be a plugin tool executing at the receiving email system <NUM>.

Additional details regarding the email validation agent <NUM> are described below with reference to <FIG>.

The email validation system <NUM> validates emails for which validation information is sent by the email validation agent <NUM> of the receiving email system <NUM>. Upon receiving validation information for an email from the email validation agent <NUM>, the email validation system <NUM> may inspect the sender domain indicated in the validation information. The email validation system <NUM> compares this information to a database of known domains. These are list of trusted domains which are known to be authentic and not spoofed or otherwise malicious. If the sender domain matches a domain in this list of known domains, the email validation system <NUM> may indicate to the email validation agent <NUM> that the email is valid.

The email validation system <NUM> additionally determines if the sender domain is an open-sign up domain. An open sign-up domain is a domain for which any user may request an email address (for no cost or for a fee). Services which operate open sign-up domains, in contrast to organizations such as corporations or other associations, do not control which users may use their services. Therefore, emails with sender domains matching an open sign-up domain may be from any sender, legitimate or otherwise. The email validation system <NUM> determines whether an email with a sender from an open sign-up domain is valid using a database of trusted contacts. These trusted contacts may be derived from the user contact list <NUM> of associated with the receiving mail system <NUM>. If an email with sender domain that is an open sign-up domain has a sender address which matches an address in the trusted contacts database, the email validation system <NUM> may also indicate to the email validation agent <NUM> that the email is valid.

The email validation system <NUM> may in some cases determine that the email has a sender address that is neither in a database of known domains or in a list of trusted contacts. In such a case, the email validation system <NUM> may perform a new domain inspection upon the new domain. This inspection is used to determine whether the new domain should be placed in the database of known domains as a known domain.

The email validation system <NUM> may also log all requests for email validation, and transmit portions of this log to an administrator of the receiving email system <NUM> for further analysis and processing. In one embodiment, the email validation system <NUM> is a component of the receiving email system <NUM>. In another embodiment, the email validation system <NUM> is a component of a third party email validation entity. Additional information regarding the email validation system <NUM> is described below with reference to <FIG>.

The domain owner system <NUM> comprises one or more computing systems, which may be configured similarly to the computing system described with reference to <FIG>, and which may be associated with a domain owner of a sender domain for which the delivering email system <NUM> sends emails.

The domain owner system <NUM> may include a DNS server on which an authoritative domain name system (DNS) record of a domain owner is stored. The domain owner may be associated with the purported domain of emails that have been sent to the receiving email system <NUM>. The domain owner DNS system <NUM> uses the DNS protocol to respond to DNS requests for DNS records for the domain owner. Examples of these DNS records include A records, CNAME records, MX records, TXT records, and so on.

<FIG> is a detailed block diagram of the email validation agent of the receiving email system of <FIG>, according to one embodiment. The email validation agent <NUM> includes a trusted contacts hash engine <NUM>, an email info transmitter <NUM>, and an email action module <NUM>. Although the illustrated email validation agent <NUM> includes the elements shown in <FIG>, in other embodiments the email validation agent <NUM> may include different elements or a different number of elements. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.

The trusted contacts hash engine <NUM> receives or accesses, from the contacts manager system <NUM>, the user contact lists <NUM> of each domain associated with an organization and hashes the email addresses contained in the list(s) for transmission to the email validation system <NUM>. In one embodiment, the trusted contacts hash engine <NUM> takes each email address in a user contact list <NUM> and hashes the email address. However, in another embodiment, the trusted contacts hash engine <NUM> only hashes email addresses associated with a list of authorized users of the organization. The hash is transmitted by the trusted contacts hash engine <NUM> to the email validation system <NUM>. The hash may be a hash of the local part of the email address, of the domain of the email address, a combination of the two, or may be more than one hash for each of the local part and domain. The hash can be transmitted along with an indicator of the organization, as well as an indicator of the email address of the user which is associated with the contact that was used to generate the hash. The email of the user may also be hashed by the trusted contacts hash engine <NUM> before transmitting it to the email validation system <NUM>. The trusted contacts hash engine <NUM> may further hash the email address in combination with a key. Such a key is only known to the email validation agent <NUM>, and is stored locally and not transmitted over a network. The key may be a randomized string of hashable characters. The hash itself prevents the transmission of personally identifiable information to an external entity, such as the email validation system <NUM>. The addition of the key in the hash further prevents the external entity from tracking the hashed email address over multiple systems, in the case where the external entity receives hashes of the same email address using the same hashing algorithm from these multiple systems. This also allows the email validation agent <NUM> to comply with various privacy regulations, such as the GDPR (General Data Protection Regulation) of the European Union.

The hashing algorithm that is used may be HMAC. HMAC uses a hash function, such as SHA256 or MD5, and a cryptographic key, such as the key described above, in order to hash a message, such as the email address. In addition, different cryptographic keys may be used to hash email addresses, in accordance with the user or subgroup of users to which the email addresses are associated. Therefore, there may be multiple cryptographic keys in use for signed hashes at any given time.

The trusted contacts hash engine <NUM> may further normalize the email address before hashing it. In one embodiment, if the domain of the email address has many variations, the trusted contacts hash engine <NUM> replaces the domain of the email address with a standard default variation if the domain does not match the standard default variation. For example, if the email address has a domain listed as googlemail. com, the trusted contacts hash engine <NUM> may convert this to gmail.

Although a process is described above whereby the email addresses are hashed, in other embodiments no hashing is performed on the email addresses and the email addresses are transmitted without modification (e.g., without hashing or obfuscation).

The email info transmitter <NUM> transmits validation information about an email to the email validation system <NUM> in an email validation request. This may occur every time a new email is received by the receiving email system <NUM>, or may occur in batch. As described above, the validation information may include various metadata about the email that is received. This may include the sender domain of the sender address of the email (i.e., the domain indicated in the From header section of the email), the Return-path of the email, the recipient domain of the email (i.e., the domain indicated in the To header section of the email), the sender local part address of the sender address (i.e., the portion of the sender address before the @ symbol in the From header section of the email), the recipient local part address, the EHLO information of the email, any IP address indicated in the header of the email, and so on. Any of the metadata may first be hashed by the email info transmitter <NUM> before being transmitted to the email validation system <NUM>. This may include hashing (portions of) the sender and/or recipient address of the email using the same hashing algorithm and key used by the trusted contacts hash engine <NUM>. The email info transmitter <NUM> may also normalize the sender address before hashing it or transmitting it to the email validation system <NUM>. This normalization may include changing alternate domain names to a standard domain name according to one or more rules. For example, the domain "googlemail. com" may be converted to "gmail.

As described above, after sending the validation information of a received email to the email validation system <NUM>, the email validation system <NUM> responds with an indication of whether the email is valid or not valid. The email action module <NUM> acts in response to this information. If the email is indicated to be a valid email, the email action module <NUM> may forward the email to the email store <NUM> and associate it with the user indicated in the recipient address of the email, i.e., the email is processed normally, so that the user may later access it via the email client <NUM>. If the email is indicated to be not valid, the email action module <NUM> may perform various remediation actions based on a policy or the content of the email. In one embodiment, the email action module <NUM> may quarantine the email. In another embodiment, the email action module <NUM> may forward the email to the user but include with the email a warning or other indicator to alert the user that the email may be fraudulent. The email action module <NUM> may transmit a notification to an administrator, who can further take action upon the email, such as mark the sender domain of the email as a trusted domain for that organization. If marked as a trusted domain, the sender domain may be added to a custom domain list for the organization at the email validation system <NUM>. The action performed by the email action module <NUM> may be specific for each user, e.g., some users may receive emails that are not valid (e.g., a sales representative), while others may not. In another embodiment, the email action module <NUM> may simply delete the email and do nothing else. The email action module <NUM> may also process the email normally without any special action. In some embodiments the email action module <NUM> may incorporate email authentication results (i.e. DMARC, SPF, DKIM) or other forensic data as inputs into the policy decision for disposition of the email.

<FIG> is a detailed block diagram of the email validation system <NUM> of <FIG>, according to one embodiment. The email validation system <NUM> includes a domain inspector <NUM>, a domains list <NUM>, an open sign-up email inspector <NUM>, a trusted contacts list <NUM>, a new domain inspector <NUM>, a response logger <NUM>, and a domain list generator <NUM>. Although the illustrated email validation system <NUM> includes the elements shown in <FIG>, in other embodiments the email validation system <NUM> may include different elements or a different number of elements. Furthermore, the functionalities of each element may be distributed differently among the elements in other embodiments.

The trusted contacts list <NUM> includes sender email addresses received from the trusted contacts hash engine <NUM> of the email validation agent <NUM> for various domains/organizations. These sender email addresses are known contacts from which emails can be received, as they were added by the users of the organization. Each email address in the trusted contacts list <NUM> may be represented by a hash, such that the email validation system <NUM> cannot identify a person associated with the email address. Each email address in the trusted contacts list <NUM> may be associated with an indicator of the organization from which the email address was received, and may also be associated with an indicator of the user from which email address was received. The indicator of the user may be a hash of the recipient email address of the user. As noted, the email addresses in the trusted contacts list <NUM> are received from the trusted contacts hash engine <NUM> of the various email validation agents <NUM> of various organizations which utilize the email validation system <NUM>. Upon receiving the hashed email addresses from the email validation agents <NUM>, the email validation system <NUM> may perform various sanity and validation checks upon the hashed email addresses, and store the hashed email addresses in the trusted contacts list <NUM>. For example, the email validation system <NUM> may verify that the hash is a valid hash. As noted above, in some cases the emails are not hashed. In such a case, the email validation system <NUM> does not verify the hash as the email addresses are not hashed.

The open sign-up email inspector <NUM> responds to email validation requests from the email validation agent <NUM> for emails in which the sender domain is an open sign-up domain to determine if the sender address is valid. The open sign-up email inspector <NUM> matches the sender domain in the validation information of an email validation request to determine whether the sender domain matches an open sign-up domain indicated in the domains list <NUM>. If so, the open sign-up email inspector <NUM> determines whether the sender address indicated in the email validation request matches an address in the trusted contacts list <NUM>. As described above, the sender address in the validation information may be hashed using a hashing algorithm and a key. The same hashing algorithm and key would have been used to hash the email addresses stored in the trusted contacts list <NUM>. Therefore, a match between the hashed sender address in the validation information and a hashed email address in the trusted contacts list <NUM> indicates that the email is from a known contact. The open sign-up email inspector <NUM> matches the hashed sender address in the validation information with the hashed email addresses in the trusted contacts list <NUM> to determine if a match exists. If a match is found, the open sign-up email inspector <NUM> may transmit a response to the email validation agent <NUM> that the email associated with the email validation request is a valid email. Otherwise, if a match is not found, the open sign-up email inspector may transmit a request to the domain inspector <NUM> to inspect the sender domain, or may transmit a response to the email validation agent <NUM> indicating that the email is not valid.

The open sign-up email inspector <NUM> may only check the email contacts in the trusted contacts list <NUM> which are associated with the organization which requested the email validation request. The open sign-up email inspector <NUM> may further limit the email contacts that are checked in the trusted contacts list <NUM> to email addresses which are associated with the recipient address indicated in the validation information.

The domains list <NUM> includes a list of known domains. These known domains are domains known to be associated with domain owners that are linked with known organizations. A known organization is one whose provenance is known, such that it can be linked to an identifiable entity in the real world. For example, the domain valimail. com is a known domain because it can be associated with a known organization, i.e., Valimail, Inc. of San Francisco, California. Therefore, the list of known domains in the domains list <NUM> are all domains for which a definite association with a real world entity has been established. While the known domains have links to real world entities, this does not mean that the real world entities are necessarily always good actors. A real world entity may perform activities which are in violation of various laws or other regulations. However, the linking of the domain to the real world organization better guarantees that a chain of liability or indemnity may be traced from emails sent by the known domain to the real world organization. In one embodiment, the domains list <NUM> is stored in punycode format.

The domains list <NUM> may also include a list of open sign-up domains. As described above, an open sign-up domain is a domain which allows any user to sign up for an email address (either for free or for a fee). Examples of open sign-up domains include gmail. com, yandex. ru, outlook. com, and so on.

In one embodiment, the domains list <NUM> also includes a list of bad domains, e.g., spoofing, phishing, or other malicious domains. These are domains that have previously been determined to be bad domains, i.e., domains which are not associated with a known and legitimate organization.

In another embodiment, the domains list <NUM> also includes a list of custom domains. The custom domains list is a list of known domains, and in some cases bad domains, specific to an organization. In other words, these domains have been selected by the organization and are only checked when the recipient domain indicated in the email validation request is associated with the organization. Each organization may have its own list of custom domains.

The domain inspector <NUM> compares the sender domain information received in an email validation request from the email validation agent <NUM> to a list of known domains in the domains list <NUM>. If a match is found, then the domain inspector <NUM> may transmit a response to the email validation agent <NUM> indicating that the email is valid. If no match is found, then the domain inspector <NUM> may transmit a response to the email validation agent <NUM> indicating that the email associated with the email validation request is not valid, or may further send the email validation request to the new domain inspector <NUM> to determine whether the domain is valid.

In one embodiment, before checking the sender domain, the domain inspector <NUM> also checks to see if the recipient domain received in the email validation request is within a list of recipient domains (e.g., that are subscribed to the email validation service). If not, the domain inspector <NUM> may stop checking for the sender domain and return an error. In another embodiment, before checking the sender domain, the domain inspector <NUM> may normalize the sender domain. This may include converting the domain to a standard domain name for the organization associated with the sender domain using a list of known alternative domain names.

In some cases, the domain inspector <NUM> may also check the sender domain to see if it matches a bad domain that is stored in the domains list <NUM>. If such a match is found, the domain inspector <NUM> transmits a response to the email validation agent <NUM> indicating that the sender domain matches a known bad domain.

In one embodiment, the domain inspector <NUM> also matches the sender domain with a known domain (or bad domain) in a list of custom domains for the organization, in a fashion similar to the process described above of matching the sender domain to the list of known domains. This custom domains is stored in the domains list <NUM>.

The new domain inspector <NUM> may inspect sender domains received in email validation requests that are not listed in the domains list <NUM> to determine whether they belong to known organizations. If a sender domain from an email validation request is not indicated in the domains list <NUM>, then the new domain inspector <NUM> may execute various processes to determine whether this new domain is associated with a known organization.

In one embodiment, the new domain inspector <NUM> checks the WHOIS information of the new domain. If the WHOIS information includes address or other contact information which can be traced to a real world location, e.g., via an address database, a mapping tool, a public contacts database, a government incorporation database, then the new domain inspector <NUM> may determine that the new domain is associated with a known organization, and may store this new domain as a known domain in the domains list <NUM>. The new domain inspector <NUM> may also inspect the historical information for the new domain, to determine how long the WHOIS information has been registered, and whether it has changed. If the WHOIS information has been registered for a threshold duration without change, the new domain inspector <NUM> may also include the new domain as a known domain in the domains list <NUM>.

The new domain inspector <NUM> may query a passive DNS database for the new domain. The passive DNS database captures various DNS requests made across the Internet. The new domain inspector <NUM> may store the new domain as a known domain if the passive DNS database indicates that the new domain has been requested by other known domains for a threshold duration of time into the past (i.e., whether one or more timestamps of queries from other known domains is beyond a time duration threshold from the current time) or by a threshold number of other known domains.

The new domain inspector <NUM> may inspect any website or other Internet presence (e.g., a mail server, DNS server, file server, etc.) associated with the new domain (e.g., by using the DNS records of the new domain). The existence of multiple presences (e.g., beyond a threshold count) may cause the new domain inspector <NUM> to store the new domain as a known domain. The new domain inspector <NUM> may compare these presences to the presences of known domains (e.g., it may compare the website of the new domain to those websites of known domains). If one or more presences of the new domain closely matches (e.g., via image analysis, metadata comparison) the corresponding presence of a known domain (e.g., by a threshold similarity percentage), the new domain inspector <NUM> may not store the new domain as a known domain (and may store it as an invalid/bad domain in the domains list <NUM>).

The new domain inspector <NUM> may include a machine learning classifier to classify new domains. The classifier may receive as features the data indicated above for a domain, and return a confidence score indicating whether that domain is likely a known domain. The classifier may be trained on valid and invalid domains.

The new domain inspector <NUM> may, after making a determination that a new domain is a known domain, send the determination result to an administrator, which may further verify the results of the determination, before transmitting a request to the new domain inspector <NUM> to have the new domain inspector <NUM> store the new domain as a known domain. Conversely if the new domain inspector <NUM> does not determine that the new domain is a known domain, the new domain inspector <NUM> may also send this determination to the administrator, who may override the determination made by the new domain inspector <NUM>. However, in another embodiment, the new domain inspector <NUM> places the domain into the known domain list or the bad domain list without sending it for confirmation to the administrator when it determines that the domain is a known domain or is not a known domain, respectively.

The new domain inspector <NUM> may also submit a request to an administrator of the organization associated with the receiving email system <NUM> which made the email validation request in order to determine whether the new domain is a known domain. If the administrator responds with an indication that the domain is known, the new domain inspector <NUM> may store this new domain as a custom domain for that organization only. If a sufficient number of administrators indicate that a new domain is a known domain, then that new domain may also be placed in the global known domains list.

The response logger <NUM> logs email validation requests and the response provided by the email validation system <NUM> in response to these requests. These logs may be transmitted by the response logger <NUM> to an administrator of the receiving email system <NUM>, etc..

The domain list generator <NUM> may generate the initial list of known domains in the domains list <NUM>. To generate the initial list, the domains list generator <NUM> may monitor the inbound emails for a selected number of organizations to gather a list of domains indicated in those received emails. These domains may be analyzed to determine which of them are legitimate, and these legitimate domains are placed in the list of known domains, while the illegitimate domains may be placed in the list of bad domains. Alternatively, the domains for the list of known domains may be determined automatically, by selecting those domains indicated in emails that users in the selected number of organizations respond to beyond a threshold number of replies, which users across multiple organizations respond to, and so on. The new domain inspector <NUM> may remove from these lists those emails which have sender domains that belong to open sign-up domains. The domain list generator <NUM> may also gather lists of known domains from third party sources, such as third party organizations that collect domains for known organizations, semi-private data sources (e.g., list from a marketing organization), private data sources, and public data sources (e.g., a list of publicly traded companies such as the Fortune <NUM> or Russell <NUM>). The domain list generator may also cross-reference these lists with other known sources to generate a final list.

In one embodiment, the email validation system <NUM> may also receive requests from administrators of receiving email domains to remove a domain from the list of known domains for an organization. In such a case, the domains list <NUM> may include in the custom domains list for the organization a list of removed domains. If a domain is in this removed domains list, then it is not treated as a known domain for that organization. If a sufficient number of administrators from different organizations request that a domain be removed, that domain may also be removed from the global known domains list.

<FIG> is an interaction diagram illustrating an exemplary process for validating an email domain, according to one embodiment. In one embodiment, <FIG> attributes the operations in process to the indicated elements. However, some or all of the steps may be performed by other elements. In addition, some embodiments may perform the operations in parallel, perform the operations in different orders, or perform different operations. Also, it is noted that in one example embodiment the steps and/or modules may be embodied as instructions, e.g., instructions <NUM>, that may be executed by the processor <NUM> described with respect to <FIG>. Note that elements with dashed lines indicate optional elements that may not be performed or transmitted or which are performed or transmitted conditionally.

The receiving email system <NUM>, in one embodiment, receives <NUM> emails from a delivering email system, such as the delivering email system <NUM>. To validate this email, the receiving email system <NUM> transmits <NUM> an email validation request with information about the email to the email validation system <NUM>. As noted above, this information may include the sender address, recipient address, recipient organization, and so on. One or more elements of this information may be hashed. This request may generated and sent by an email validation agent, such as email validation agent <NUM>, on the receiving email system <NUM>.

The email validation system <NUM> receives the email validation request <NUM>, and validates the email <NUM>. This may be performed similarly to the method described above for the email validation system <NUM>. Thus, the email validation system <NUM> may determine <NUM> if the hashed sender email in the email validation request is in a trusted contacts list, e.g., trusted contacts list <NUM>. The email validation system <NUM> may determine <NUM> if the sender domain indicated in the email validation request is in a known domains list, such as the known domains listed stored in the domains list <NUM>. Otherwise, if the sender domain is unknown, the email validation system <NUM> may inspect <NUM> the new domain, and may place it in the known domains list if it determines that the domain is known.

After validating the email, the email validation system <NUM> transmits <NUM> a response to the receiving email system <NUM> indicating the validity of the email indicated in the email validation request <NUM>. The receiving email system <NUM> may take <NUM> some action depending upon the response, as described above.

<FIG> is a flow chart illustrating an exemplary process for validating an email domain, according to one embodiment. In one embodiment, <FIG> attributes the operations in process to the email validation system <NUM>. However, some or all of the steps may be performed by other elements. In addition, some embodiments may perform the operations in parallel, perform the operations in different orders, or perform different operations. Also, it is noted that in one example embodiment the steps and/or modules may be embodied as instructions, e.g., instructions <NUM>, that may be executed by the processor <NUM> described with respect to <FIG>. Note that elements with dashed lines indicate optional elements that may not be performed or transmitted or which are performed or transmitted conditionally.

To validate an email, the email validation system <NUM> receives <NUM> an email validation request from a receiving email system (e.g., receiving email system <NUM>) with information about an email that was received. This information may include the sender domain, recipient domain, and hash of the sender address, as described above. The email validation system <NUM> determines <NUM> whether the hash of the sender address is in a trusted contacts list for the organization, e.g., trusted contacts list <NUM>, in a method similar to that described above for the open sign-up email inspector <NUM>. This inspection may also include determining if the sender domain is an open sign-up domain. If so, the email validation system <NUM> transmits <NUM> a response to the receiving email system <NUM> indicating that the email is valid. Otherwise, the email validation system <NUM> determines <NUM> whether the sender domain is in a list of known domains, such as the list of known domains in the domains list <NUM>. This process may be similar to the process described above for the domain inspector <NUM>. If the sender is a known domain, the email validation system <NUM> transmits <NUM> the response indicating the email is valid.

If the sender domain is not in the list of known domains, the email validation system <NUM> inspects <NUM> the sender domain to determine if it is valid. This inspection may be performed in a method similar to the method described above for the new domain inspector <NUM>. If the sender domain is determined <NUM> to be valid, the sender domain is added <NUM> to the known domains list, and the valid email response is transmitted <NUM>. Otherwise, a non-valid email response is transmitted <NUM>.

<FIG> is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller). Specifically, <FIG> shows a diagrammatic representation of a machine in the example form of a computer system <NUM>. The computer system <NUM> can be used to execute instructions <NUM> (e.g., program code or software) for causing the machine to perform any one or more of the methodologies (or processes) or functions described herein, for example, in <FIG>. In alternative embodiments, the machine operates as a standalone device or a connected (e.g., networked) device that connects to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a smartphone, an internet of things (IoT) appliance, a network router, switch or bridge, or any machine capable of executing instructions <NUM> (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute instructions <NUM> to perform any one or more of the methodologies discussed herein.

The example computer system <NUM> includes one or more processing units (generally processor <NUM>). The processor <NUM> is, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these. The computer system <NUM> also includes a main memory <NUM>. The computer system may include a storage unit <NUM>. The processor <NUM>, memory <NUM> and the storage unit <NUM> communicate via a bus <NUM>.

In addition, the computer system <NUM> can include a static memory <NUM>, a display driver <NUM> (e.g., to drive a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). The computer system <NUM> may also include alphanumeric input device <NUM> (e.g., a keyboard), a cursor control device <NUM> (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a signal generation device <NUM> (e.g., a speaker), and a network interface device <NUM>, which also are configured to communicate via the bus <NUM>.

The storage unit <NUM> includes a machine-readable medium <NUM> on which is stored instructions <NUM> (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM> or within the processor <NUM> (e.g., within a processor's cache memory) during execution thereof by the computer system <NUM>, the main memory <NUM> and the processor <NUM> also constituting machine-readable media. The instructions <NUM> may be transmitted or received over a network <NUM> via the network interface device <NUM>.

While machine-readable medium <NUM> is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the instructions <NUM>. The term "machine-readable medium" shall also be taken to include any medium that is capable of storing instructions <NUM> for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term "machine-readable medium" includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

Example benefits (or advantages) of the disclosed configurations include the ability to validate emails.

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms, for example, as illustrated in <FIG>. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium and executable by a processor) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

The one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).

In addition, use of the "a" or "an" are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Claim 1:
A computer implemented method, comprising:
generating a known domain list of known domains, wherein a known domain is a domain that is linked to an organization whose provenance is known;
receiving (<NUM>), at an email validation system (<NUM>), an email validation request from a requestor to validate an email, the email validation request indicating at least a sender domain;
determining (<NUM>) that the sender domain is not listed in the known domain list of known domains;
in response to determining that the sender domain is not listed in the known domain list of known domains, accessing a WHOIS information of the sender domain; determining that the WHOIS information of the sender domain includes address or other contact information that can be traced to a real world location via one of: an address database, a mapping tool, a public contacts database, and a government incorporation database;
storing the sender domain in the known domain list of known domains;
generating a message indicating that the email is valid; and
transmitting the message to the requestor.