US20060031315A1 - Method and system for verifying identification of an electronic mail message - Google Patents

Method and system for verifying identification of an electronic mail message Download PDF

Info

Publication number
US20060031315A1
US20060031315A1 US10/859,402 US85940204A US2006031315A1 US 20060031315 A1 US20060031315 A1 US 20060031315A1 US 85940204 A US85940204 A US 85940204A US 2006031315 A1 US2006031315 A1 US 2006031315A1
Authority
US
United States
Prior art keywords
key
recited
domain
mail message
electronic mail
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/859,402
Other versions
US7437558B2 (en
Inventor
James Fenton
Michael Thomas
Frederick Baker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US10/859,402 priority Critical patent/US7437558B2/en
Assigned to CISCO TECHNOLOGY, INC. reassignment CISCO TECHNOLOGY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAKER, FREDERICK J., FENTON, JAMES L., THOMAS, MICHAEL A.
Priority to PCT/US2005/018326 priority patent/WO2005119481A2/en
Priority to US11/143,362 priority patent/US8090940B1/en
Publication of US20060031315A1 publication Critical patent/US20060031315A1/en
Priority to US12/203,853 priority patent/US8156554B2/en
Application granted granted Critical
Publication of US7437558B2 publication Critical patent/US7437558B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking

Definitions

  • the present invention relates to the field of electronic mail. Specifically, the present invention relates to a method and system for verifying identification of an electronic mail message.
  • IP Internet Protocol
  • DNS Domain Name System
  • an authorized third party may send email messages on behalf of a business.
  • the third party may be authorized to send emails as an agent of the business, but not from the business' internal network. Businesses do not want to authorize third parties to send emails from their network, so as to not expose their network to the third parties.
  • professional organizations, alumni associations, and other affinity domains may provide email addresses to users. In both of these cases, a recipient may receive an email supposedly coming from one domain, but the path indicates the email actually came from another domain. The path-based approach would not be able to verify the sender of the email in these cases.
  • path-based schemes can only identify a sender down to the domain level, not to the individual senders. In general, path-based identification schemes break some of the common ways email is used, and are not always effective in filtering unwanted email messages.
  • Signature-based identification schemes are also used to verify the sender of an email.
  • Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME) are examples of signature-based identification schemes.
  • PGP Pretty Good Privacy
  • S/MIME Secure Multipurpose Internet Mail Extensions
  • signature-based schemes verify a message signature embedded in the message.
  • a public key is retrieved.
  • PGP provides a system for having people or organizations other than the sender sign the public key.
  • Transitive trust verifies a key by having other people act as trusted introducers by signing the key. These people are either known to the recipient, or known by people known to the recipient.
  • Transitive trust does not scale adequately to a global email system.
  • the email identification problem is characterized by extreme scalability requirements. There are currently on the order of 30 million domains and a much larger number of individual addresses. It is important to preserve the positive aspects of current email infrastructure, which include the ability for anyone to communicate with anyone else without introduction. This contrasts with PGP's use of trusted introducers to vouch for the authenticity of keys. Key management based on introducers would have difficulty scaling to the large number of addresses in use and retain the degree of connectivity that email provides.
  • a third party authority provides an electronic certificate to the domain.
  • the authority performs some form of due diligence to confirm the domain's identity.
  • management of the certificates by the domain can be very complex and time consuming.
  • certificate revocation may be problematic. For example, if an employee leaves their position and is no longer authorized to send email messages using the domain, it is necessary to revoke the certificate.
  • the certifying authority is a third party, it would be necessary to contact the certifying authority to revoke the certificate.
  • an electronic mail message including a signature and a key identifier is received, the signature identifying a domain from which the electronic mail message originated and the key identifier for verifying the signature.
  • a domain name system (DNS) lookup may be performed to locate the key registration server based on the signature.
  • the key identifier is a key.
  • a key registration server of the domain is accessed to verify the key.
  • a rating service may be accessed to determine a security rating associated with the electronic mail message.
  • a system for verifying identification of an electronic mail message includes a mail signer, a key registration server, and a mail recipient.
  • the mail signer is operable to transmit an electronic mail message including a signature and a key identifier, wherein the key identifier is for verifying the signature.
  • the key identifier is a key.
  • the key registration server is operable to register and verify the key.
  • the mail recipient is operable to receive the electronic mail message, verify the signature based on the key, and access the key registration server to verify the key.
  • the mail recipient may also be operable to perform a domain name system (DNS) lookup to locate the key registration server based on the signature.
  • the system may also include a rating service operable to determine a security rating associated with the electronic mail message.
  • DNS domain name system
  • FIG. 1 is a block diagram of an exemplary computer system platform upon which embodiments of the present invention may be practiced.
  • FIG. 2 is a block diagram of one embodiment of a system for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention.
  • FIG. 3 is a flow chart illustrating a method for generating a self-verifying electronic mail message, in accordance with one embodiment of the present invention.
  • FIG. 4 is a flow chart illustrating a method for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention.
  • Embodiments of the present invention provide for receiving an email message including a signature and a key.
  • the signature identifies a domain from which the email message purportedly originated and the key is for verifying the signature.
  • Authorization of the key is verified by accessing a key registration server of the domain.
  • the key registration server provides for verifying that a key used to sign an email message is valid and that the sender is authorized by the domain to send the email message from the return address.
  • FIG. 1 illustrates an exemplary computer system 100 upon which embodiments of the present invention may be practiced.
  • computer system 100 comprises bus 110 for communicating information, processor 101 coupled with bus 110 for processing information and instructions, random access (volatile) memory (RAM) 102 coupled with bus 110 for storing information and instructions for processor 101 , read-only (non-volatile) memory (ROM) 103 coupled with bus 110 for storing static information and instructions for processor 101 , data storage device 104 such as a magnetic or optical disk and disk drive coupled with bus 110 for storing information and instructions.
  • RAM volatile memory
  • ROM read-only (non-volatile) memory
  • data storage device 104 such as a magnetic or optical disk and disk drive coupled with bus 110 for storing information and instructions.
  • computer system 100 comprises an optional user output device such as display device 105 coupled to bus 110 for displaying information to the computer user, an optional user input device such as alphanumeric input device 106 including alphanumeric and function keys coupled to bus 110 for communicating information and command selections to processor 101 , and an optional user input device such as cursor control device 107 coupled to bus 110 for communicating user input information and command selections to processor 101 .
  • an optional input/output (I/O) device 108 is used to couple computer system 100 onto, for example, a network.
  • Display device 105 utilized with computer system 100 may be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user.
  • Cursor control device 107 allows the computer user to dynamically signal the two-dimensional movement of a visible symbol (pointer) on a display screen of display device 105 .
  • cursor control device Many implementations of the cursor control device are known in the art including a trackball, mouse, joystick or special keys on alphanumeric input device 106 capable of signaling movement of a given direction or manner of displacement. It is to be appreciated that the cursor control 107 also may be directed and/or activated via input from the keyboard using special keys and key sequence commands. Alternatively, the cursor may be directed and/or activated via input from a number of specially adapted cursor directing devices.
  • system 200 includes mail user agent (MUA) 205 , mail transfer agent (MTA) 210 , MTA 240 , MUA 245 , key registration server (KRS) 220 , Domain Name System (DNS) 260 , and rating service 270 .
  • System 200 is operable to perform message transmission for a sender to a receiver.
  • components of system 200 are operable to perform a method for verifying identification of an email message.
  • MUA 205 , MTA 210 , MTA 240 , MUA 245 , KRS 220 , DNS 260 , and rating service 270 are comprised within separate computer systems (e.g., computer system 100 of FIG. 1 ) dispersed across Internet 230 .
  • the components of system 200 communicate via the communications protocols of system 200 .
  • MUA 205 may communicate to MTA 210 and MTA 210 may communicate to MTA 240 via simple mail transfer protocol (SMTP).
  • MTA 240 may communicate to KRS 220 and rating service 270 via hypertext transport protocol (HTTP).
  • MTA 240 may communicate to MUA 245 via post office protocol (POP) or Internet message access protocol (IMAP). It should be appreciated that any protocol that supports communication between computing systems may be used, and that embodiments of the present invention are not limited by the described embodiments.
  • POP post office protocol
  • IMAP Internet message access protocol
  • MUA 205 is an application that supports user interaction with an email system for sending and receiving email messages.
  • MUA 205 is a software application resident on a computer system.
  • MUA 205 is a Web-based email application accessible over the Internet.
  • MTA 210 is an application which transmits an email message through a network to a destination mail server.
  • MUA 205 and MTA 210 are associated with domain 215 , in which a domain is an organization's unique name on the Internet.
  • An email message generated at MUA 205 is transmitted by MTA 210 to a destination mail server. Prior to transmission, the email message is signed using a private key of a public/private key pair, wherein the signature is included in the email message header. The signature can be verified by using the public key of the key pair. The public key is also added to the email message header.
  • MUA 205 is operable to sign the email message and add the public key to the message header.
  • MTA 210 is operable to sign the email message and add the public key to the message header.
  • MUA support may be added to increase email verification flexibility.
  • a key identifier is added to the message header rather than the entire public key, to reduce the overall size of the email message.
  • the key identifier identifies a public key from KRS 220 .
  • MTA 210 is operable to transmit an email message, which includes a signature and a public key in the message header, to MTA 240 .
  • MTA 240 is operable to receive the email message and to verify the authorization of the public key.
  • a KRS may be considered authoritative to verify the association of a key with any email address in a domain.
  • KRS 220 associated with domain 215 is accessed to verify the authorization of the public key.
  • MTA 240 accesses DNS 260 to perform a DNS lookup to locate the address of KRS 220 .
  • the DNS lookup is based on the domain name listed in the return address of the email message (e.g., example.com for the email address joesmith@example.com). In another embodiment, the DNS lookup is based on the domain name listed in the message header.
  • DNS 260 is operable to return an IP address for the KRS (e.g., KRS 220 ) associated with the domain name listed in the email address to MTA 240 .
  • KRS 220 stores registered keys for domain 215 .
  • KRS 220 may store registered keys for any number of domains, and is not limited to a single domain.
  • a domain may outsource public key management to a third party KRS.
  • MTA 240 is operable to verify the authorization of the public key received in the email message against registered keys stored in KRS 220 .
  • KRS 220 determines a value indicating a trust level of the public key according to domain 215 .
  • the value indicates whether a public key is valid (e.g., good rating), a public key is unregistered (e.g., it is unknown), or it is invalid (e.g., public key is associated with a known stolen computer).
  • the value is based on a key fingerprint (e.g., a cryptographic hash) of the public key.
  • MTA 240 is configured to determine the authorization of the key based on the value. Based on the particular settings of MTA 240 , a public key can be determined as valid or invalid. In one embodiment, if the public key is invalid, the email message is dropped.
  • system 200 includes rating service 270 for determining a security rating associated with the sender of the email message.
  • rating service 270 is a third party service that provides independent ratings of the security provided by a domain and/or individual user address.
  • MTA 240 is operable to transmit a rating request to rating service 270 .
  • rating service 270 returns a security rating associated with a sender of the electronic mail message.
  • rating service 270 returns a security rating associated with the domain. It should be appreciated that rating service 270 is optional.
  • MTA 240 is operable to verify the signature based on the public key. In one embodiment, MTA 240 is also configured to verify the identification of the message based on the signature and the public key. In another embodiment, MTA 240 is also configured to verify the identification of the message based on the signature, the public key and the security rating as received from rating service 270 . If the identification of the message is verified, the message is transmitted to MUA 245 , for receipt by the intended recipient. In contrast, if the identification of the message is not verified, the message is tagged with the authorization of the identification and, if applicable, the security rating of the sender. In another embodiment, the message may be determined to be an unwanted email message, and is not forwarded to the intended recipient. It should be appreciated that other policies (such as returning a temporary failure until it is convenient to accept an unidentified message) are possible as well. Also, it is possible for MUA 245 to check the authorization (and optionally the security rating) of the message itself.
  • FIG. 3 is a flow chart illustrating a process 300 for generating a self-verifying electronic mail message, in accordance with one embodiment of the present invention.
  • process 300 is carried out by processors and electrical components under the control of computer readable and computer executable instructions.
  • the computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile and non-volatile memory (e.g., volatile memory 102 and non-volatile memory 103 of FIG. 1 ).
  • the computer readable and computer executable instructions may reside in any type of computer readable medium.
  • specific steps are disclosed in process 300 , such steps are exemplary. That is, the embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in FIG. 3 .
  • process 300 is performed by MUA 205 of FIG. 2 .
  • process 300 is performed by MTA 210 of FIG. 2 .
  • an email message is received.
  • the email message may be generated at an MUA (e.g., MUA 205 of FIG. 2 ).
  • a signature for the electronic mail message is generated (e.g., the message is signed).
  • the signature is generated using a private key of a public/private key pair.
  • the signature identifies the domain from which the electronic mail message originated.
  • the signature is added to a header of the email message.
  • the public key of the key pair is added to the email message, wherein the public key is for verifying the signature.
  • a key identifier identifying the public key is added to the email message. It should be appreciated that steps 310 , 320 and 330 may be performed at either a MTA or a MUA.
  • the public key is added to a header of the email message. In another embodiment, the public key and signature may be contained within the same email message header.
  • the signature header including the public key is included in an email message in order for it to be considered a self-verifying mail message.
  • the signature-text may include a number of fields that represent the signature itself, a public key used to create the signature, and related information.
  • Tags and their values in the X-IMAIL-SIG line are included into the cryptographic hash with the sole exception of the s: (signature) tag and its value.
  • the tags and their values are simply concatenated to each other when forming the cryptographic hash in the order they are present in the X-IMAIL-SIG line. That is: “v1hthomasm-u1dcisco.com[ . . . ]”. Syntactic markers are not included and the value used in the hash is before encoding/after decoding.
  • the final hash algorithm is as follows: TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12) where SIGTAGVALS is the encoding described above for the header tags/values and BODY is the SHA-1 hash of the body of the email itself.
  • SIGTAGVALS is the encoding described above for the header tags/values
  • BODY is the SHA-1 hash of the body of the email itself.
  • the SHA-1 value of the body uses the full 16 bytes of the hash (e.g., is not truncated).
  • tags used in the signature are as follows:
  • the email message also includes an optional verification header which is used to convey the verification of a message from an MTA to an MUA or another MTA within the same trust domain. If used, it is applied by an MTA that is close to the point where an MTA or the recipient's MUA applies policy based on the verification status of the message.
  • the verification header indicates whether an MTA was able to successfully verify the message according to whatever policies it decides to use.
  • a recipient MUA or MTA may decide to rely on the presence of a verification header in applying policy to the message (e.g., moving an unverified message to a lower-priority folder), or it may do such verification locally.
  • the verification header is not cryptographically protected, in order to avoid the need to manage keys for MTAs.
  • the verification header may be deleted from the header when the message is sent via SMTP outside the trust domain of the sender. In one embodiment, the verification header is discarded if it received from an SMTP peer that is not trusted by the recipient (e.g., an SMTP peer that is not within the recipient's administrative control).
  • An example of a verification header is as follows: X-IMAIL-VERIFY: s:“y”; v:“y”; r:“68”; h:“imail.example.com”
  • tags and values used by the verification header are as follows:
  • FIG. 4 is a flow chart illustrating a process 400 for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention.
  • process 400 is carried out by processors and electrical components under the control of computer readable and computer executable instructions.
  • the computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile and non-volatile memory (e.g., volatile memory 102 and non-volatile memory 103 of FIG. 1 ).
  • the computer readable and computer executable instructions may reside in any type of computer readable medium.
  • specific steps are disclosed in process 400 , such steps are exemplary. That is, the embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in FIG. 4 .
  • process 400 is performed by MTA 240 of FIG. 2 .
  • an email message comprising a signature and a key identifier is received.
  • the signature identifies a domain from which the email message originated and the key identifier is for verifying the signature.
  • the key identifier identifies an associated key for verifying the signature.
  • the key identifier is a key.
  • the key is a public key that verifies the signature was generated by the same public/private key pair.
  • the email message is received at an MTA (e.g., MTA 240 of FIG. 2 ).
  • a DNS lookup is performed to locate the KRS for the domain associated with the email message.
  • the KRS is considered authoritative to verify the association of a key with an email addresses in the domain.
  • the verifying MTA/MUA queries DNS with the hostname part of the envelope-from email address (e.g., eng.example.com for tom@eng.example.com).
  • the zone file for a given domain might contain records such as the following: example.com. IN MX 10 mail.example.com. example.com. IN MX 10 mail2.example.com. _krs._tcp.example.com. IN SRV 10 10 378 krs.example.com. _krs._tcp.example.com. IN SRV 10 10 378 krs2.example.com.
  • a KRS of the domain is accessed to verify authorization of the key.
  • the key is obtained from the KRS based on the key identifier.
  • the KRS confirms or denies the binding between the envelope-from email address used by the message and the key used to sign the message. It does so by receiving a query (e.g., an authorization verification request) including the key fingerprint and the envelope-from email address.
  • the query includes the envelope without the key.
  • the query receives the key for verifying authorization of the key.
  • a value is received from the KRS indicating a trust level of the key according to the domain.
  • the KRS returns a numerical value based on the policy of the sending domain as to whether the key is authorized to be used in sending a message from the specified address.
  • One exemplary policy might be as follows:
  • the outgoing MTA for a domain is most likely to perform rewriting, if any, of the envelope-from address of the message (for example, to remove an unnecessary subdomain). Since the KRS and the outgoing MTA are usually under common administration, the KRS can be configured to respond appropriately to expected rewritings of the envelope-from address.
  • the authorization of the key is verified based on the value. Verification of public keys from key registration servers is accomplished via a properly-formatted HTTP request.
  • the KRS response is the tag/value syntax with the following exemplary tags/values defined:
  • s status.
  • SMTP/HTTP status values e.g., 200, 300, 400, 500 semantics
  • revoked keys from the home KRS would be given a negative rating.
  • the KRS uses a mechanism that ensures that only authorized users are able to deposit key fingerprints on the server and revoke them. This may involve a mechanism such as an authenticated HTTP exchange that requires the user's password in order to register a public key fingerprint for that user on the server. It is implicit in this key management approach that only legitimate key-to-address bindings may be registered on the key registration servers. In one embodiment, in order to prevent harvesting of email addresses, a KRS will not respond with any email address other than that presented in the query or a more general address (for example, when the key fingerprint corresponds to a domain MTA).
  • a rating service is accessed to determine a security rating associated with the email message.
  • the security rating is associated with a sender of the email message.
  • the security rating is associated with the domain. It should be appreciated that step 460 is optional. It is helpful, but probably not sufficient to confirm that a message was signed using a key authorized for the stated address. This alone says nothing about the security of the originating domain's KRS, the method used to identify message senders prior to MTA message signing, and the overall character of the domain. Senders of unwanted email messages are free to register domains and set up KRSs for those domains. Domains might also be set up with explicitly open key registration policies, to permit anonymous exchange of signed messages among groups of people. In either case, mail from such domains might be less valued than from domains known to be reliable.
  • the address rating service fulfills the need to distinguish domains with differing registration policies and/or user behavior.
  • the rating service is a third-party service, somewhat analogous to a credit bureau, which the verifier of an identified mail message may use to obtain a relative evaluation of the sending address based on criteria established by the rating bureau.
  • the rating service is operable to monitor security, policies, and user behavior of a domain.
  • a hypothetical ratings database might include: 90 responsible-isp.com /* ISP with good security and policies */ 40 flaky-isp.com /* ISP that isn't very responsive */ 80 tom@flaky-isp.com /* Known good user at flaky ISP */ 0 spam-marketing.com /* Known source of UCE */
  • entries in the ratings database should be returned on the basis of longest-match. In the example above, the address “tom@flaky-isp.com” should return a rating of 80, not the value of 40 used for all other addresses in the domain. It should be appreciated that other values may be used for providing the security ratings. For example, domains or emails with poor ratings may have negative security ratings, while domains or emails with good ratings may have positive security ratings. It should be appreciated that step 460 is optional.
  • the signature is verified based on the key.
  • the identification of the email is verified. In one embodiment, the identification is verified based on the signature and the key. In another embodiment, the identification is verified based on the signature, the key and the security rating.
  • the described embodiments of the present invention provide a system and method for verifying identification of an email message.
  • a KRS for management of public keys
  • verification that a key used to sign an electronic mail message is valid and that the sender is authorized by the domain to send the electronic mail message from the return address may be management by a domain administrator.
  • a rating service for rating the security of the originating domain's KRS, a greater level of protection against unwanted email messages.

Abstract

A method and system for verifying identification of an electronic mail message. An electronic mail message including a signature and a key is received, the signature identifying a domain from which the electronic mail message originated and the key for verifying the signature. A key registration server of the domain is accessed to verify the key. The key registration server provides for verifying that a key used to sign an electronic mail message is valid and that the sender is authorized by the domain to send the electronic mail message from the return address.

Description

    FIELD OF INVENTION
  • The present invention relates to the field of electronic mail. Specifically, the present invention relates to a method and system for verifying identification of an electronic mail message.
  • BACKGROUND OF THE INVENTION
  • The use of electronic mail (email) allows users anywhere in the world to communicate with each other over the Internet. In recent years, Internet users have been subjected to a torrent of unwanted email messages. These unwanted messages generally take two forms: 1) messages originated by “spammers” to send advertising or solicitation, or as part of a confidence scheme, and 2) messages sent automatically by worms and other malicious software (malware) attempting to infect additional systems. In both cases, a large proportion of the messages attempt to disguise their true source to frustrate attempts to shut down the spammer, to disguise the identity of the infected system sending the message, or to support a social-engineering goal.
  • In an effort to reduce or eliminate the transmission of unwanted email messages, various approaches have been proposed to verify the identity of the return address of an email. However, current return address verification approaches suffer from various drawbacks which affect their implementation and usability. One approach is a path-based approach for attempting to verify the identity of the sender by verifying the Internet Protocol (IP) address of the message source. An email recipient performs a Domain Name System (DNS) query to determine what addresses are used for outgoing mail servers of the domain as listed by the sender (e.g., for the email address joesmith@example.com, example.com is the domain). If the message source is not from an outgoing mail server of the domain, it is determined that the identity of the return address is forged.
  • However, the path-based approach provides an incomplete solution to identity verification of an email. For example, an authorized third party may send email messages on behalf of a business. The third party may be authorized to send emails as an agent of the business, but not from the business' internal network. Businesses do not want to authorize third parties to send emails from their network, so as to not expose their network to the third parties. Furthermore, professional organizations, alumni associations, and other affinity domains may provide email addresses to users. In both of these cases, a recipient may receive an email supposedly coming from one domain, but the path indicates the email actually came from another domain. The path-based approach would not be able to verify the sender of the email in these cases. Moreover, path-based schemes can only identify a sender down to the domain level, not to the individual senders. In general, path-based identification schemes break some of the common ways email is used, and are not always effective in filtering unwanted email messages.
  • Signature-based identification schemes are also used to verify the sender of an email. Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME) are examples of signature-based identification schemes. In general, signature-based schemes verify a message signature embedded in the message. In order to verify the message signature, a public key is retrieved. However, since there are no limitations to the posting of a public key, it is necessary to verify the public key in order to avoid spoofing. PGP provides a system for having people or organizations other than the sender sign the public key.
  • One way to verify a public key supported by PGP is by transitive trust. Transitive trust verifies a key by having other people act as trusted introducers by signing the key. These people are either known to the recipient, or known by people known to the recipient. However, due to the large scale of the email system, it is not desirable to limit receipt of emails to degrees of separation necessary to encompass all email users. In other words, transitive trust does not scale adequately to a global email system. The email identification problem is characterized by extreme scalability requirements. There are currently on the order of 30 million domains and a much larger number of individual addresses. It is important to preserve the positive aspects of current email infrastructure, which include the ability for anyone to communicate with anyone else without introduction. This contrasts with PGP's use of trusted introducers to vouch for the authenticity of keys. Key management based on introducers would have difficulty scaling to the large number of addresses in use and retain the degree of connectivity that email provides.
  • Another way for verifying public keys is by using certificates. A third party authority provides an electronic certificate to the domain. In exchange for monetary compensation, the authority performs some form of due diligence to confirm the domain's identity. However, management of the certificates by the domain can be very complex and time consuming. In particular, certificate revocation may be problematic. For example, if an employee leaves their position and is no longer authorized to send email messages using the domain, it is necessary to revoke the certificate. In this case, since the certifying authority is a third party, it would be necessary to contact the certifying authority to revoke the certificate. Considering the large number of employees at many companies, as well as the organizational management of a certifying authority, it is quite complicated to manage certificates.
  • SUMMARY OF THE INVENTION
  • Various embodiments of the present invention, a method for verifying identification of an electronic mail message, are described. In one embodiment, an electronic mail message including a signature and a key identifier is received, the signature identifying a domain from which the electronic mail message originated and the key identifier for verifying the signature. In one embodiment, a domain name system (DNS) lookup may be performed to locate the key registration server based on the signature. In one embodiment, the key identifier is a key. A key registration server of the domain is accessed to verify the key. In one embodiment, a rating service may be accessed to determine a security rating associated with the electronic mail message.
  • In another embodiment, a system for verifying identification of an electronic mail message is described, wherein the system includes a mail signer, a key registration server, and a mail recipient. The mail signer is operable to transmit an electronic mail message including a signature and a key identifier, wherein the key identifier is for verifying the signature. In one embodiment, the key identifier is a key. The key registration server is operable to register and verify the key. The mail recipient is operable to receive the electronic mail message, verify the signature based on the key, and access the key registration server to verify the key. In one embodiment, the mail recipient may also be operable to perform a domain name system (DNS) lookup to locate the key registration server based on the signature. In one embodiment, the system may also include a rating service operable to determine a security rating associated with the electronic mail message.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
  • FIG. 1 is a block diagram of an exemplary computer system platform upon which embodiments of the present invention may be practiced.
  • FIG. 2 is a block diagram of one embodiment of a system for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention.
  • FIG. 3 is a flow chart illustrating a method for generating a self-verifying electronic mail message, in accordance with one embodiment of the present invention.
  • FIG. 4 is a flow chart illustrating a method for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention.
  • DETAILED DESCRIPTION
  • Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and the scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, structures and devices have not been described in detail so as to avoid unnecessarily obscuring aspects of the present invention.
  • Various embodiments of the present invention, a method and system for verifying identification of an electronic mail (email) message, are described herein. Embodiments of the present invention provide for receiving an email message including a signature and a key. The signature identifies a domain from which the email message purportedly originated and the key is for verifying the signature. Authorization of the key is verified by accessing a key registration server of the domain. The key registration server provides for verifying that a key used to sign an email message is valid and that the sender is authorized by the domain to send the email message from the return address.
  • Some portions of the detailed descriptions which follow are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer executed step, logic block, process, etc., is here and generally conceived to be a self-consistent sequence of steps of instructions leading to a desired result. The steps are those requiring physical manipulations of data representing physical quantities to achieve tangible and useful results. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.
  • It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “receiving”, “accessing”, “verifying”, “generating”, “performing”, “determining”, “signing”, “adding”, “registering”, or the like, refer to the actions and processes of a computer system or similar electronic computing device. The computer system or similar electronic device manipulates and transforms data represented as electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices.
  • Refer now to FIG. 1 that illustrates an exemplary computer system 100 upon which embodiments of the present invention may be practiced. In general, computer system 100 comprises bus 110 for communicating information, processor 101 coupled with bus 110 for processing information and instructions, random access (volatile) memory (RAM) 102 coupled with bus 110 for storing information and instructions for processor 101, read-only (non-volatile) memory (ROM) 103 coupled with bus 110 for storing static information and instructions for processor 101, data storage device 104 such as a magnetic or optical disk and disk drive coupled with bus 110 for storing information and instructions.
  • In one embodiment, computer system 100 comprises an optional user output device such as display device 105 coupled to bus 110 for displaying information to the computer user, an optional user input device such as alphanumeric input device 106 including alphanumeric and function keys coupled to bus 110 for communicating information and command selections to processor 101, and an optional user input device such as cursor control device 107 coupled to bus 110 for communicating user input information and command selections to processor 101. Furthermore, an optional input/output (I/O) device 108 is used to couple computer system 100 onto, for example, a network.
  • Display device 105 utilized with computer system 100 may be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user. Cursor control device 107 allows the computer user to dynamically signal the two-dimensional movement of a visible symbol (pointer) on a display screen of display device 105. Many implementations of the cursor control device are known in the art including a trackball, mouse, joystick or special keys on alphanumeric input device 106 capable of signaling movement of a given direction or manner of displacement. It is to be appreciated that the cursor control 107 also may be directed and/or activated via input from the keyboard using special keys and key sequence commands. Alternatively, the cursor may be directed and/or activated via input from a number of specially adapted cursor directing devices.
  • Referring now to FIG. 2, a block diagram of a system 200 for verifying identification of an email message, in accordance with one embodiment of the present invention. As depicted in FIG. 2, system 200 includes mail user agent (MUA) 205, mail transfer agent (MTA) 210, MTA 240, MUA 245, key registration server (KRS) 220, Domain Name System (DNS) 260, and rating service 270. System 200 is operable to perform message transmission for a sender to a receiver. In one embodiment, components of system 200 are operable to perform a method for verifying identification of an email message.
  • In one embodiment, MUA 205, MTA 210, MTA 240, MUA 245, KRS 220, DNS 260, and rating service 270 are comprised within separate computer systems (e.g., computer system 100 of FIG. 1) dispersed across Internet 230. In one embodiment, the components of system 200 communicate via the communications protocols of system 200. In one embodiment, MUA 205 may communicate to MTA 210 and MTA 210 may communicate to MTA 240 via simple mail transfer protocol (SMTP). In one embodiment, MTA 240 may communicate to KRS 220 and rating service 270 via hypertext transport protocol (HTTP). In one embodiment, MTA 240 may communicate to MUA 245 via post office protocol (POP) or Internet message access protocol (IMAP). It should be appreciated that any protocol that supports communication between computing systems may be used, and that embodiments of the present invention are not limited by the described embodiments.
  • MUA 205 is an application that supports user interaction with an email system for sending and receiving email messages. In one embodiment, MUA 205 is a software application resident on a computer system. In another embodiment, MUA 205 is a Web-based email application accessible over the Internet. MTA 210 is an application which transmits an email message through a network to a destination mail server. MUA 205 and MTA 210 are associated with domain 215, in which a domain is an organization's unique name on the Internet.
  • An email message generated at MUA 205 is transmitted by MTA 210 to a destination mail server. Prior to transmission, the email message is signed using a private key of a public/private key pair, wherein the signature is included in the email message header. The signature can be verified by using the public key of the key pair. The public key is also added to the email message header. In one embodiment, MUA 205 is operable to sign the email message and add the public key to the message header. In another embodiment, MTA 210 is operable to sign the email message and add the public key to the message header. By placing the signature generation and public key addition in MTA 210, it is not necessary to initially support this functionality in MUA 205, thereby speeding deployment and reducing technical support demands. However, MUA support may be added to increase email verification flexibility. In another embodiment, a key identifier is added to the message header rather than the entire public key, to reduce the overall size of the email message. The key identifier identifies a public key from KRS 220.
  • MTA 210 is operable to transmit an email message, which includes a signature and a public key in the message header, to MTA 240. MTA 240 is operable to receive the email message and to verify the authorization of the public key. In order for the signature to be meaningful, a trusted database of public keys needs to be available to verify message signatures. A KRS may be considered authoritative to verify the association of a key with any email address in a domain. Accordingly, KRS 220 associated with domain 215 is accessed to verify the authorization of the public key. In one embodiment, MTA 240 accesses DNS 260 to perform a DNS lookup to locate the address of KRS 220. In one embodiment, the DNS lookup is based on the domain name listed in the return address of the email message (e.g., example.com for the email address joesmith@example.com). In another embodiment, the DNS lookup is based on the domain name listed in the message header.
  • DNS 260 is operable to return an IP address for the KRS (e.g., KRS 220) associated with the domain name listed in the email address to MTA 240. KRS 220 stores registered keys for domain 215. It should be appreciated that KRS 220 may store registered keys for any number of domains, and is not limited to a single domain. For example, a domain may outsource public key management to a third party KRS. MTA 240 is operable to verify the authorization of the public key received in the email message against registered keys stored in KRS 220.
  • In one embodiment, KRS 220 determines a value indicating a trust level of the public key according to domain 215. In one embodiment, the value indicates whether a public key is valid (e.g., good rating), a public key is unregistered (e.g., it is unknown), or it is invalid (e.g., public key is associated with a known stolen computer). In one embodiment, the value is based on a key fingerprint (e.g., a cryptographic hash) of the public key. MTA 240 is configured to determine the authorization of the key based on the value. Based on the particular settings of MTA 240, a public key can be determined as valid or invalid. In one embodiment, if the public key is invalid, the email message is dropped.
  • Even if a key is determined to be valid, the email message may be an unwanted message (e.g., spam or a virus), as senders of unwanted messages may be able to register their own domain. Therefore, it may be desirable to have an independent rating service for rating the security level of a domain and/or a particular user. For example, a domain may be known to have low reliability for preventing unwanted email. In one embodiment, system 200 includes rating service 270 for determining a security rating associated with the sender of the email message. In one embodiment, rating service 270 is a third party service that provides independent ratings of the security provided by a domain and/or individual user address.
  • MTA 240 is operable to transmit a rating request to rating service 270. In one embodiment, rating service 270 returns a security rating associated with a sender of the electronic mail message. In another embodiment, rating service 270 returns a security rating associated with the domain. It should be appreciated that rating service 270 is optional.
  • MTA 240 is operable to verify the signature based on the public key. In one embodiment, MTA 240 is also configured to verify the identification of the message based on the signature and the public key. In another embodiment, MTA 240 is also configured to verify the identification of the message based on the signature, the public key and the security rating as received from rating service 270. If the identification of the message is verified, the message is transmitted to MUA 245, for receipt by the intended recipient. In contrast, if the identification of the message is not verified, the message is tagged with the authorization of the identification and, if applicable, the security rating of the sender. In another embodiment, the message may be determined to be an unwanted email message, and is not forwarded to the intended recipient. It should be appreciated that other policies (such as returning a temporary failure until it is convenient to accept an unidentified message) are possible as well. Also, it is possible for MUA 245 to check the authorization (and optionally the security rating) of the message itself.
  • FIG. 3 is a flow chart illustrating a process 300 for generating a self-verifying electronic mail message, in accordance with one embodiment of the present invention. In one embodiment, process 300 is carried out by processors and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile and non-volatile memory (e.g., volatile memory 102 and non-volatile memory 103 of FIG. 1). However, the computer readable and computer executable instructions may reside in any type of computer readable medium. Although specific steps are disclosed in process 300, such steps are exemplary. That is, the embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in FIG. 3. In one embodiment, process 300 is performed by MUA 205 of FIG. 2. In another embodiment, process 300 is performed by MTA 210 of FIG. 2.
  • At step 310 of process 300, an email message is received. The email message may be generated at an MUA (e.g., MUA 205 of FIG. 2). At step 320, a signature for the electronic mail message is generated (e.g., the message is signed). The signature is generated using a private key of a public/private key pair. In one embodiment, the signature identifies the domain from which the electronic mail message originated. In one embodiment, the signature is added to a header of the email message.
  • At step 330, the public key of the key pair is added to the email message, wherein the public key is for verifying the signature. In another embodiment, a key identifier identifying the public key is added to the email message. It should be appreciated that steps 310, 320 and 330 may be performed at either a MTA or a MUA. In one embodiment, the public key is added to a header of the email message. In another embodiment, the public key and signature may be contained within the same email message header.
  • The signature header including the public key is included in an email message in order for it to be considered a self-verifying mail message. For example, the signature header may have the syntax:
    signature=“X-IMAIL-SIG:” signature-text CRLF
  • The signature-text may include a number of fields that represent the signature itself, a public key used to create the signature, and related information. An example of a signature is as follows:
    X-IMAIL-SIG: v:“1”; h:“thomasm-u1”; d:“cisco.com”;
    t:“1080771772.862325”; x:“1081203772”; a:“rsa-sha1”; e:“Iw==”;
    n:“pZORwkeEetQnTVC7tw5MIE+31ROt/sGv5q+dxuwUIIqu5
    XKSva4P1/anPgIiz”
    “7K8V0MaRDwDjKIuYYGaUO5IdDNfE7WEKe+/r8k3D0lrkNCa
    8qNPDSKljocN6y”
    “d7Wjmx/Hk+tquACcpwhhDyVxzIBcj/A5aCApbeFeRkVvfFH70=”;
    s:“T3iRhynnuKx8+UNBuxMnDCIFet8RTM+VAs+
    STKM4P9ZqiEaUmG1rXmeXq3T+8”
    “0oHhWtztZob/2twTxiqzgMD5MnFOTaqujJUBOmkIf1VR+
    ELzKq/vPZ+GmWs+h”
    “mtSg3sH7jWrnvYHQpT6yey9TumnJVAdWepPl4budT9GFdp
    Ruw=”;
    c:“Subject: new tags”
  • Tags and their values in the X-IMAIL-SIG line are included into the cryptographic hash with the sole exception of the s: (signature) tag and its value. The tags and their values are simply concatenated to each other when forming the cryptographic hash in the order they are present in the X-IMAIL-SIG line. That is: “v1hthomasm-u1dcisco.com[ . . . ]”. Syntactic markers are not included and the value used in the hash is before encoding/after decoding. The final hash algorithm is as follows:
    TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12)
    where SIGTAGVALS is the encoding described above for the header tags/values and BODY is the SHA-1 hash of the body of the email itself. In one embodiment, the SHA-1 value of the body uses the full 16 bytes of the hash (e.g., is not truncated). Examples of the tags used in the signature are as follows:
      • a: Algorithm—One-way hash and public key algorithm. In one embodiment this is rsa-sha1.
      • c: Copied header—A copied header is a header which the sender would like to cryptographically sign. In one embodiment, there are no other headers into the cryptographic hash. The headers which are copied into the signature line are purely at the discretion and local policy of the signer. In one embodiment, the headers copied include the Subject, From, and Date headers. Receiving MTAs and/or MUAs may choose to replace the unsigned headers with headers which have been signed so as to present untampered with headers to the user, typically the headers copied from the originating domain. If such a replacement is performed, the unsigned headers may be preserved in the message (e.g., X-UNSIGNED-HEADER).
      • d: Domain of signer—This tag denotes the signing domain. It is used to inform the receiver of the appropriate level of address that is considered the authoritative domain in this context. For example, if a message is received from jdoe@eng.example.com, the d: tag might indicate that the domain is example.com or eng.example.com. If this tag does not correspond to either the hostname of the envelope-from address or a higher-level domain, the signature may be ignored.
      • e: The Rivest-Shamir-Adelman (RSA) public exponent of the supplied signing key, base 64 encoded.
      • h: Signing host.
      • n: The RSA public modulus of the supplied signing key, base 64 encoded. It should be appreciated that the key length is implicit with the number of decoded bits in the modulus. For example, supported key lengths may be 768 bits, 1024 bits and 1536 bits.
      • s: The RSA signature over the computed one-way hash, base 64 encoded.
      • t: Timestamp—The time that this signature was created. In one embodiment, the format is the standard Unix seconds-since-1970 followed by a fractional number. In one embodiment, the time stamp is unique for this signing key. The intent of the fraction is to the guarantee the uniqueness of any given signature at any particular instance. The value may be expressed as an unsigned integer.
      • x: Signature expiration in seconds-since-1970 format—In one embodiment, signatures are not considered valid if the current time at the receiver is past the expiration date. The value may expressed as an unsigned integer.
      • v: Version of these tags—In one embodiment this is set to “1”. The value may expressed as an unsigned integer.
  • In one embodiment, the email message also includes an optional verification header which is used to convey the verification of a message from an MTA to an MUA or another MTA within the same trust domain. If used, it is applied by an MTA that is close to the point where an MTA or the recipient's MUA applies policy based on the verification status of the message. The verification header indicates whether an MTA was able to successfully verify the message according to whatever policies it decides to use. A recipient MUA or MTA may decide to rely on the presence of a verification header in applying policy to the message (e.g., moving an unverified message to a lower-priority folder), or it may do such verification locally.
  • In one embodiment, the verification header is not cryptographically protected, in order to avoid the need to manage keys for MTAs. The verification header may be deleted from the header when the message is sent via SMTP outside the trust domain of the sender. In one embodiment, the verification header is discarded if it received from an SMTP peer that is not trusted by the recipient (e.g., an SMTP peer that is not within the recipient's administrative control).
  • An example of a verification header is as follows:
    X-IMAIL-VERIFY: s:“y”; v:“y”; r:“68”; h:“imail.example.com”
  • Examples of the tags and values used by the verification header are as follows:
      • s: Signature—The value is “y” if there is a signature line from the sending domain (e.g., the domain suffix in the envelope from). Otherwise the value is “n”.
      • v: Verify—The value is “y” if the home domain's signature is both present and the public key operation verifies correctly.
      • r: Rating—The value here is between −127 and 127 with negative values expressing an adverse rating, zero being neutral and positive values indicating a favorable rating. The rating value is at the discretion of the entity supplying the X-IMAIL-VERIFY header and may take into account many different factors including the rating supplied by the home domain's KRS, local and third party ratings, and any other factors the verifying entity considers relevant.
      • h: Host—This is the fully qualified domain name of the MTA that performed the verification. It should be noted that since the X-IMAIL-VERIFY header is not cryptographically protected, users or subsequent MTAs which make use of the X-IMAIL-VERIFY header independently ensure that it is not subject to tampering.
  • FIG. 4 is a flow chart illustrating a process 400 for verifying identification of an electronic mail message, in accordance with one embodiment of the present invention. In one embodiment, process 400 is carried out by processors and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile and non-volatile memory (e.g., volatile memory 102 and non-volatile memory 103 of FIG. 1). However, the computer readable and computer executable instructions may reside in any type of computer readable medium. Although specific steps are disclosed in process 400, such steps are exemplary. That is, the embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in FIG. 4. In one embodiment, process 400 is performed by MTA 240 of FIG. 2.
  • At step 410 of process 400, an email message comprising a signature and a key identifier is received. The signature identifies a domain from which the email message originated and the key identifier is for verifying the signature. In one embodiment, the key identifier identifies an associated key for verifying the signature. In another embodiment, the key identifier is a key. In one embodiment, the key is a public key that verifies the signature was generated by the same public/private key pair. In one embodiment, the email message is received at an MTA (e.g., MTA 240 of FIG. 2).
  • At step 420, a DNS lookup is performed to locate the KRS for the domain associated with the email message. The KRS is considered authoritative to verify the association of a key with an email addresses in the domain. In one embodiment, to locate the KRS, the verifying MTA/MUA queries DNS with the hostname part of the envelope-from email address (e.g., eng.example.com for tom@eng.example.com).
  • The zone file for a given domain might contain records such as the following:
    example.com. IN MX 10 mail.example.com.
    example.com. IN MX 10 mail2.example.com.
    _krs._tcp.example.com. IN SRV 10 10 378 krs.example.com.
    _krs._tcp.example.com. IN SRV 10 10 378 krs2.example.com.
  • At step 430, a KRS of the domain is accessed to verify authorization of the key. In one embodiment, the key is obtained from the KRS based on the key identifier. In another embodiment, where the key identifier is the key, the KRS confirms or denies the binding between the envelope-from email address used by the message and the key used to sign the message. It does so by receiving a query (e.g., an authorization verification request) including the key fingerprint and the envelope-from email address. In another embodiment, the query includes the envelope without the key. In another embodiment, the query receives the key for verifying authorization of the key.
  • At step 440, a value is received from the KRS indicating a trust level of the key according to the domain. In one embodiment, the KRS returns a numerical value based on the policy of the sending domain as to whether the key is authorized to be used in sending a message from the specified address. One exemplary policy might be as follows:
  • +127: Key is recognized and acceptable for the given address
  • 0: Key is unrecognized
  • −127: Key is known to have been compromised; do not accept it
  • The outgoing MTA for a domain is most likely to perform rewriting, if any, of the envelope-from address of the message (for example, to remove an unnecessary subdomain). Since the KRS and the outgoing MTA are usually under common administration, the KRS can be configured to respond appropriately to expected rewritings of the envelope-from address. The following are some excerpts from a hypothetical KRS database:
    #Rating TTL Address Key Fingerprint
    100 86400 tom@eng.example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC
    # Tom's usual address
    100 86400 tom@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC
    # Rewriting of Tom's address
    100 86400 dick@example.com 91881749E520D8F53B0B91BBD8963D0D
    # Dick's PC
    100 86400 dick@example.com 549D8949351DDA4E7C961E0F58727795
    # Dick's PDA
    −100 864000 harry@example.com 8C8252070CA9ED401DD2EE2A7B31A8CF
    # Harry's stolen PC
    100 86400 harry@example.com 17E64AC44DD5F8891560919D3FC6EA52
    # Harry's new PC
    100 86400 harry@example.com 073FDD7DD6D6EF6D1413FD7B3C577EFC
    # Tom is Harry's administrative
    # assistant, so Harry allows Tom
    # to originate mail for him.
    100 604800 *@example.com 27985A61447CC8B514A82BFA4597174A
    # Outgoing MTA key. MTA keys are
    # less likely to require rapid
    # revocation, hence the longer TTL.
    100 86400 nobody@example.com *
    # Any key will work for this address
    # NOT RECOMMENDED!
    −100 86400 nosig@example.com
    # No signature with email, where
    # domain signs all emails
  • At step 450, the authorization of the key is verified based on the value. Verification of public keys from key registration servers is accomplished via a properly-formatted HTTP request. A sample request might be formatted as follows:
    http://krs2.example.com:378?domain=example.com
    &name=“john@example.com”
    &keyfp=“27985A61447CC8B514A82BFA4597174A”
    &service=“SMTP”
  • The fields in the query are as follows:
      • name: The envelope_from of the incoming mail.
      • keyfp: The public key fingerprint that was supplied in the X-IMAIL-SIG line.
      • domain: The domain corresponding to the query to be performed. This is used primarily to allow a single KRS to support multiple domains, with each domain database being independently maintained.
      • service: The service (e.g., SMTP) for which the query is requested.
  • The KRS response is the tag/value syntax with the following exemplary tags/values defined:
  • s: status. Follows the general convention of SMTP/HTTP status values (e.g., 200, 300, 400, 500 semantics) with the following values defined:
    200: the lookup succeeded.
    201: the lookup succeeded, but the keyfp/name combination was
    not found
    500: any permanent failure.
      • t: Time to live—Responses may be cached on the receiver so as to reduce the query/response load back to the KRS. Time to live is expressed in seconds from when the query was sent.
      • r: Rating—Similar to rating in the X-IMAIL-VERIFY, an integer between −127 and 127 which as the sole discretion of the entity producing the rating.
  • For example, revoked keys from the home KRS would be given a negative rating.
      • m: Matches—Some key fingerprints may in fact sign for more than the single address that is present in the query. In order cut down trips to the KRS, the Matches field describes with normal Unix wildcard syntax what envelope_from patterns match this key fingerprint. For example:
        m:“*@example.com”
        would inform the cache logic of the requestor that future queries from example.com with this key fingerprint be given the same rating and time to live.
      • c: Comment—This is a free form string intended to convey a human readable comment about the operation.
      • v: Version of the responses—The value is expressed as an unsigned integer.
  • In one embodiment, the KRS uses a mechanism that ensures that only authorized users are able to deposit key fingerprints on the server and revoke them. This may involve a mechanism such as an authenticated HTTP exchange that requires the user's password in order to register a public key fingerprint for that user on the server. It is implicit in this key management approach that only legitimate key-to-address bindings may be registered on the key registration servers. In one embodiment, in order to prevent harvesting of email addresses, a KRS will not respond with any email address other than that presented in the query or a more general address (for example, when the key fingerprint corresponds to a domain MTA).
  • At step 460, a rating service is accessed to determine a security rating associated with the email message. In one embodiment, the security rating is associated with a sender of the email message. In another embodiment, the security rating is associated with the domain. It should be appreciated that step 460 is optional. It is helpful, but probably not sufficient to confirm that a message was signed using a key authorized for the stated address. This alone says nothing about the security of the originating domain's KRS, the method used to identify message senders prior to MTA message signing, and the overall character of the domain. Senders of unwanted email messages are free to register domains and set up KRSs for those domains. Domains might also be set up with explicitly open key registration policies, to permit anonymous exchange of signed messages among groups of people. In either case, mail from such domains might be less valued than from domains known to be reliable.
  • The address rating service fulfills the need to distinguish domains with differing registration policies and/or user behavior. In one embodiment, the rating service is a third-party service, somewhat analogous to a credit bureau, which the verifier of an identified mail message may use to obtain a relative evaluation of the sending address based on criteria established by the rating bureau. In one embodiment, the rating service is operable to monitor security, policies, and user behavior of a domain. A hypothetical ratings database might include:
    90 responsible-isp.com /* ISP with good security and policies */
    40 flaky-isp.com /* ISP that isn't very responsive */
    80 tom@flaky-isp.com /* Known good user at flaky ISP */
    0 spam-marketing.com /* Known source of UCE */

    In one embodiment, entries in the ratings database should be returned on the basis of longest-match. In the example above, the address “tom@flaky-isp.com” should return a rating of 80, not the value of 40 used for all other addresses in the domain. It should be appreciated that other values may be used for providing the security ratings. For example, domains or emails with poor ratings may have negative security ratings, while domains or emails with good ratings may have positive security ratings. It should be appreciated that step 460 is optional.
  • At step 470, the signature is verified based on the key. At step 480, the identification of the email is verified. In one embodiment, the identification is verified based on the signature and the key. In another embodiment, the identification is verified based on the signature, the key and the security rating.
  • The described embodiments of the present invention provide a system and method for verifying identification of an email message. By providing a KRS for management of public keys, verification that a key used to sign an electronic mail message is valid and that the sender is authorized by the domain to send the electronic mail message from the return address may be management by a domain administrator. Furthermore, by providing a rating service for rating the security of the originating domain's KRS, a greater level of protection against unwanted email messages.
  • Various embodiments of the present invention, a system and method for verifying identification of an electronic mail message, are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the below claims.

Claims (74)

1. A method for verifying identification of an electronic mail message, said method comprising:
receiving an electronic mail message comprising a signature and a key identifier, said signature identifying a domain from which said electronic mail message originated and said key identifier for verifying said signature; and
accessing a key registration server of said domain to verify authorization of said key identifier.
2. The method as recited in claim 1 further comprising performing a domain name system (DNS) lookup to locate said key registration server.
3. The method as recited in claim 1 further comprising receiving a key from said key registration server based on said key identifier; and
in response to said receiving said key, verifying said authorization of said key.
4. The method as recited in claim 1 wherein said key identifier is a key.
5. The method as recited in claim 4 further comprising:
receiving a value from said key registration server indicating a trust level of said key according to said domain; and
verifying said authorization of said key based on said value.
6. The method as recited in claim 5 wherein said value is based on a key fingerprint of said key.
7. The method as recited in claim 1 further comprising accessing a rating service to determine a security rating associated with said electronic mail message.
8. The method as recited in claim 7, wherein said security rating is associated with a sender of said electronic mail message.
9. The method as recited in claim 7, wherein said security rating is associated with said domain.
10. The method as recited in claim 1 further comprising verifying said signature based on said key.
11. The method as recited in claim 1 further comprising verifying said identification of said electronic mail message based on said signature and said key.
12. The method as recited in claim 7 further comprising verifying said identification of said electronic mail message based on said signature, said key and said security rating.
13. A system for verifying identification of an electronic mail message, said system comprising:
a mail signer for transmitting an electronic mail message, said electronic mail message comprising a signature and a key identifier, said key identifier for verifying said signature;
a key registration server for registering a key; and
a mail verifier for receiving said electronic mail message, for verifying said signature based on said key identifier, and for accessing said key registration server to verify authorization of said key identifier.
14. The system as recited in claim 13 wherein said mail signer is a mail transfer agent.
15. The system as recited in claim 13 wherein said mail signer is a mail user agent.
16. The system as recited in claim 13 wherein said mail verifier is a mail transfer agent.
17. The system as recited in claim 13 wherein said mail verifier is a mail user agent.
18. The system as recited in claim 13 wherein said mail verifier is also for performing a domain name system (DNS) lookup to locate said key registration server.
19. The system as recited in claim 13 wherein said mail verifier is also for receiving said key from said key registration server based on said key identifier, and verifying said authorization of said key in response to said receiving said key.
20. The system as recited in claim 13 wherein said key identifier is a key.
21. The system as recited in claim 20 wherein said key registration server is also for determining a value indicating a trust level of said key according to said domain.
22. The system as recited in claim 21 wherein said value is based on a key fingerprint of said key.
23. The system as recited in claim 13 further comprising a rating service for determining a security rating associated with said electronic mail message.
24. The system as recited in claim 23, wherein said security rating is associated with a sender of said electronic mail message.
25. The system as recited in claim 23, wherein said security rating is associated with said domain.
26. The system as recited in claim 13 wherein said mail verifier is also for verifying said signature based on said key.
27. The system as recited in claim 13 wherein said mail verifier is also for verifying said identification of said electronic mail message based on said signature and said key.
28. The system as recited in claim 23 wherein said mail verifier is also for verifying said identification of said electronic mail message based on said signature, said key and said security rating.
29. An electronic device comprising:
a bus;
a computer-readable memory coupled to said bus; and
a processor coupled to said bus, said processor for executing a method for verifying identification of an electronic mail message, said method comprising:
receiving an electronic mail message comprising a signature and a key, said signature identifying a domain from which said electronic mail message originated and said key for verifying said signature; and
accessing a key registration server of said domain to verify authorization of said key.
30. The electronic device as recited in claim 29 wherein said method further comprises performing a domain name system (DNS) lookup to locate said key registration server.
31. The electronic device as recited in claim 29 wherein said method further comprises:
receiving a value from said key registration server indicating a trust level of said key according to said domain; and
verifying said authorization of said key based on said value.
32. The electronic device as recited in claim 31 wherein said value is based on a key fingerprint of said key.
33. The electronic device as recited in claim 29 wherein said method further comprises accessing a rating service to determine a security rating associated with said electronic mail message.
34. The electronic device as recited in claim 33, wherein said security rating is associated with a sender of said electronic mail message.
35. The electronic device as recited in claim 33, wherein said security rating is associated with said domain.
36. The electronic device as recited in claim 29 wherein said method further comprises verifying said signature based on said key.
37. The electronic device as recited in claim 29 wherein said method further comprises verifying said identification of said electronic mail message based on said signature and said key.
38. The electronic device as recited in claim 33 wherein said method further comprises verifying said identification of said electronic mail message based on said signature, said key and said security rating.
39. A system for verifying identification of an electronic mail message, said system comprising:
means for transmitting an electronic mail message, said electronic mail message comprising a signature and a key, said key for verifying said signature;
means for registering said key; and
means for receiving said electronic mail message and operable to verify said signature based on said key and operable to access said means for registering said key to verify authorization of said key.
40. The system as recited in claim 39 wherein said means for receiving said electronic mail message is also operable to perform a domain name system (DNS) lookup to locate said means for registering said key.
41. The system as recited in claim 39 wherein said means for registering said key is also operable to determine a value indicating a trust level of said key according to said domain.
42. The system as recited in claim 39 further comprising a means for determining a security rating associated with said electronic mail message.
43. A method for verifying authorization of a key, said method comprising:
receiving an authorization verification request for verifying said authorization of said key, wherein said key is associated with an electronic mail message originating from a domain;
determining a value indicating a trust level of said key according to said domain; and
transmitting a response comprising said value.
44. The method as recited in claim 43 wherein said authorization verification request comprises said key.
45. The method as recited in claim 43 wherein said authorization verification request comprises a key fingerprint associated with said key.
46. The method as recited in claim 43 wherein said authorization verification request comprises a request for said key.
47. The method as recited in claim 43 wherein said response comprises a time to live of said authorization.
48. A computer-usable medium having computer-readable program code embodied therein for causing a computer system to perform a method for verifying authorization of a key, said method comprising:
receiving an authorization verification request for verifying said authorization of said key, wherein said key is associated with an electronic mail message originating from a domain;
determining a value indicating a trust level of said key according to said domain; and
transmitting a response comprising said value.
49. The computer-usable medium as recited in claim 48 wherein said authorization verification request comprises said key.
50. The computer-usable medium as recited in claim 48 wherein said authorization verification request comprises a key fingerprint associated with said key.
51. The computer-usable medium as recited in claim 48 wherein said authorization verification request comprises a request for said key.
52. The computer-usable medium as recited in claim 48 wherein said response comprises a time to live of said authorization.
53. An electronic device comprising:
a bus;
a computer-readable memory coupled to said bus; and
a processor coupled to said bus, said processor for executing a method for verifying authorization of a key, said method comprising:
receiving an authorization verification request for verifying said authorization of said key, wherein said key is associated with an electronic mail message originating from a domain;
determining a value indicating a trust level of said key according to said domain; and
transmitting a response comprising said value.
54. The electronic device as recited in claim 53 wherein said authorization verification request comprises said key.
55. The electronic device as recited in claim 53 wherein said authorization verification request comprises a key fingerprint associated with said key.
56. The electronic device as recited in claim 53 wherein said authorization verification request comprises a request for said key.
57. The electronic device as recited in claim 53 wherein said response comprises a time to live of said authorization.
58. A system for verifying authorization of a key, said system comprising:
means for receiving an authorization verification request for verifying said authorization of said key, wherein said key is associated with an electronic mail message originating from a domain;
means for determining a value indicating a trust level of said key according to said domain; and
means for transmitting a response comprising said value.
59. The system as recited in claim 58 wherein said authorization verification request comprises said key.
60. The system as recited in claim 58 wherein said authorization verification request comprises a key fingerprint associated with said key.
61. The system as recited in claim 58 wherein said authorization verification request comprises a request for said key.
62. The system as recited in claim 58 wherein said response comprises a time to live of said authorization.
63. A method for determining a security rating, said method comprising:
monitoring security of a domain;
receiving a security rating request associated with an electronic mail message originating from a domain;
determining a security rating associated with said electronic mail message; and
transmitting a response comprising said security rating.
64. The method as recited in claim 63 wherein said security rating is associated with a sender of said electronic mail message.
65. The method as recited in claim 63 wherein said security rating is associated with said domain.
66. A computer-usable medium having computer-readable program code embodied therein for causing a computer system to perform a method for determining a security rating, said method comprising:
monitoring security of a domain;
receiving a security rating request associated with an electronic mail message originating from a domain;
determining a security rating associated with said electronic mail message; and
transmitting a response comprising said security rating.
67. The computer-usable medium as recited in claim 66 wherein said security rating is associated with a sender of said electronic mail message.
68. The computer-usable medium as recited in claim 66 wherein said security rating is associated with said domain.
69. An electronic device comprising:
a bus;
a computer-readable memory coupled to said bus; and
a processor coupled to said bus, said processor for executing a method for determining a security rating, said method comprising:
monitoring security of a domain;
receiving a security rating request associated with an electronic mail message originating from a domain;
determining a security rating associated with said electronic mail message; and
transmitting a response comprising said security rating.
70. The electronic device as recited in claim 69 wherein said security rating is associated with a sender of said electronic mail message.
71. The electronic device as recited in claim 69 wherein said security rating is associated with said domain.
72. A system for determining a security rating, said system comprising:
means for monitoring security of a domain;
means for receiving a security rating request associated with an electronic mail message originating from a domain;
means for determining a security rating associated with said electronic mail message; and
means for transmitting a response comprising said security rating.
73. The system as recited in claim 72 wherein said security rating is associated with a sender of said electronic mail message.
74. The system as recited in claim 72 wherein said security rating is associated with said domain.
US10/859,402 2004-06-01 2004-06-01 Method and system for verifying identification of an electronic mail message Active 2025-04-01 US7437558B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US10/859,402 US7437558B2 (en) 2004-06-01 2004-06-01 Method and system for verifying identification of an electronic mail message
PCT/US2005/018326 WO2005119481A2 (en) 2004-06-01 2005-05-24 A method and system for verifying identification of an electronic mail message
US11/143,362 US8090940B1 (en) 2004-06-01 2005-06-01 Method and system for verifying identification of an electronic message
US12/203,853 US8156554B2 (en) 2004-06-01 2008-09-03 Method and system for verifying identification of an electronic mail message

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/859,402 US7437558B2 (en) 2004-06-01 2004-06-01 Method and system for verifying identification of an electronic mail message

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US11/143,362 Continuation-In-Part US8090940B1 (en) 2004-06-01 2005-06-01 Method and system for verifying identification of an electronic message
US12/203,853 Continuation US8156554B2 (en) 2004-06-01 2008-09-03 Method and system for verifying identification of an electronic mail message

Publications (2)

Publication Number Publication Date
US20060031315A1 true US20060031315A1 (en) 2006-02-09
US7437558B2 US7437558B2 (en) 2008-10-14

Family

ID=35463553

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/859,402 Active 2025-04-01 US7437558B2 (en) 2004-06-01 2004-06-01 Method and system for verifying identification of an electronic mail message
US12/203,853 Active 2024-08-04 US8156554B2 (en) 2004-06-01 2008-09-03 Method and system for verifying identification of an electronic mail message

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/203,853 Active 2024-08-04 US8156554B2 (en) 2004-06-01 2008-09-03 Method and system for verifying identification of an electronic mail message

Country Status (2)

Country Link
US (2) US7437558B2 (en)
WO (1) WO2005119481A2 (en)

Cited By (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050210106A1 (en) * 2003-03-19 2005-09-22 Cunningham Brian D System and method for detecting and filtering unsolicited and undesired electronic messages
US20050257261A1 (en) * 2004-05-02 2005-11-17 Emarkmonitor, Inc. Online fraud solution
US20060068755A1 (en) * 2004-05-02 2006-03-30 Markmonitor, Inc. Early detection and monitoring of online fraud
US20060069697A1 (en) * 2004-05-02 2006-03-30 Markmonitor, Inc. Methods and systems for analyzing data related to possible online fraud
US20060190606A1 (en) * 2005-02-22 2006-08-24 Kidaro Inc. Data transfer security
US20060212703A1 (en) * 2005-03-18 2006-09-21 Fujitsu Limited E-mail transfer method and device
US20060277459A1 (en) * 2005-06-02 2006-12-07 Lemoine Eric T System and method of accelerating document processing
US20070028301A1 (en) * 2005-07-01 2007-02-01 Markmonitor Inc. Enhanced fraud monitoring systems
US20070038719A1 (en) * 2005-07-29 2007-02-15 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US20070038704A1 (en) * 2005-07-29 2007-02-15 Research In Motion Limited System and method for processing messages being composed by a user
US20070071238A1 (en) * 2005-09-29 2007-03-29 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US20070107053A1 (en) * 2004-05-02 2007-05-10 Markmonitor, Inc. Enhanced responses to online fraud
US20070192853A1 (en) * 2004-05-02 2007-08-16 Markmonitor, Inc. Advanced responses to online fraud
US20070260876A1 (en) * 2006-05-05 2007-11-08 Research In Motion Limited Method and system for sending secure messages
US20070294762A1 (en) * 2004-05-02 2007-12-20 Markmonitor, Inc. Enhanced responses to online fraud
US20070294352A1 (en) * 2004-05-02 2007-12-20 Markmonitor, Inc. Generating phish messages
US20070299915A1 (en) * 2004-05-02 2007-12-27 Markmonitor, Inc. Customer-based detection of online fraud
US20070299777A1 (en) * 2004-05-02 2007-12-27 Markmonitor, Inc. Online fraud solution
US20080086532A1 (en) * 2004-10-04 2008-04-10 Brian Cunningham Method for the Verification of Electronic Message Delivery and for the Collection of Data Related to Electronic Messages Sent with False Origination Addresses
US20080086638A1 (en) * 2006-10-06 2008-04-10 Markmonitor Inc. Browser reputation indicators with two-way authentication
US20080091763A1 (en) * 2006-10-13 2008-04-17 Quipa Holdings Limited method for sharing functionality and/or data between two or more linked entities
US20090100079A1 (en) * 2007-10-12 2009-04-16 Fujitsu Limited E-mail information management apparatus, and e-mail information management method
US20090106557A1 (en) * 2007-10-20 2009-04-23 Sean Leonard Methods and systems for indicating trustworthiness of secure communications
US20090138711A1 (en) * 2007-11-21 2009-05-28 Dennis Heimbigner Sender Email Address Verification Using Reachback
US20090234925A1 (en) * 2008-03-14 2009-09-17 International Business Machines Corporation Dyanmic Domain Based Electronic Mail Signature Lines
US20090328224A1 (en) * 2008-06-30 2009-12-31 Brian Hernacki Calculating Domain Registrar Reputation by Analysis of Hosted Domains
US7747860B2 (en) 2004-05-04 2010-06-29 Message Level, Llc System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison
US20100211795A1 (en) * 2004-10-29 2010-08-19 Research In Motion Limited System and method for verifying digital signatures on certificates
US20100299399A1 (en) * 2009-04-15 2010-11-25 Kelly Wanser System and Method for the Management of Message Policy
US20100332848A1 (en) * 2005-09-29 2010-12-30 Research In Motion Limited System and method for code signing
US20110208723A1 (en) * 2010-02-19 2011-08-25 The Go Daddy Group, Inc. Calculating reliability scores from word splitting
US20110208513A1 (en) * 2010-02-19 2011-08-25 The Go Daddy Group, Inc. Splitting a character string into keyword strings
US20110265016A1 (en) * 2010-04-27 2011-10-27 The Go Daddy Group, Inc. Embedding Variable Fields in Individual Email Messages Sent via a Web-Based Graphical User Interface
US20110270926A1 (en) * 2010-04-28 2011-11-03 John Boyd Computer-based Methods and Systems for Arranging Meetings Between Users and Methods and Systems for Verifying Background Information of Users
US20130305367A1 (en) * 2012-05-10 2013-11-14 Fujitsu Limited Detecting method and device
US8909558B1 (en) 2010-02-19 2014-12-09 Go Daddy Operating Company, LLC Appraising a domain name using keyword monetary value data
US20150019652A1 (en) * 2013-07-11 2015-01-15 Blackberry Limited Qualified Email Headers
US9015263B2 (en) 2004-10-29 2015-04-21 Go Daddy Operating Company, LLC Domain name searching with reputation rating
US9058393B1 (en) 2010-02-19 2015-06-16 Go Daddy Operating Company, LLC Tools for appraising a domain name using keyword monetary value data
US9270638B2 (en) 2012-01-20 2016-02-23 Cisco Technology, Inc. Managing address validation states in switches snooping IPv6
US9275040B1 (en) 2012-09-14 2016-03-01 Go Daddy Operating Company, LLC Validating user control over contact information in a domain name registration database
US9444647B2 (en) 2006-02-14 2016-09-13 Message Level Llc Method for predelivery verification of an intended recipient of an electronic message and dynamic generation of message content upon verification
US9451050B2 (en) 2011-04-22 2016-09-20 Go Daddy Operating Company, LLC Domain name spinning from geographic location data
US9565147B2 (en) 2014-06-30 2017-02-07 Go Daddy Operating Company, LLC System and methods for multiple email services having a common domain
US9684918B2 (en) 2013-10-10 2017-06-20 Go Daddy Operating Company, LLC System and method for candidate domain name generation
US9715694B2 (en) 2013-10-10 2017-07-25 Go Daddy Operating Company, LLC System and method for website personalization from survey data
US9864755B2 (en) 2013-03-08 2018-01-09 Go Daddy Operating Company, LLC Systems for associating an online file folder with a uniform resource locator
US20180152461A1 (en) * 2016-11-29 2018-05-31 At&T Intellectual Property I, L.P. Secure Email Verification Service
US10897485B2 (en) * 2015-02-14 2021-01-19 Valimail Inc. Centralized validation of email senders via EHLO name and IP address targeting
US11416852B1 (en) * 2017-12-15 2022-08-16 Worldpay, Llc Systems and methods for generating and transmitting electronic transaction account information messages
US11587083B2 (en) 2019-12-11 2023-02-21 At&T Intellectual Property I, L.P. Transaction validation service

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8245049B2 (en) * 2004-06-14 2012-08-14 Microsoft Corporation Method and system for validating access to a group of related elements
US8103761B2 (en) * 2004-06-25 2012-01-24 Go Daddy Holding Company, LLC Methods of issuing a credit for a certificate for a domain name
US8117339B2 (en) * 2004-10-29 2012-02-14 Go Daddy Operating Company, LLC Tracking domain name related reputation
US20060200487A1 (en) * 2004-10-29 2006-09-07 The Go Daddy Group, Inc. Domain name related reputation and secure certificates
US7797413B2 (en) * 2004-10-29 2010-09-14 The Go Daddy Group, Inc. Digital identity registration
US20080028443A1 (en) * 2004-10-29 2008-01-31 The Go Daddy Group, Inc. Domain name related reputation and secure certificates
US8904040B2 (en) * 2004-10-29 2014-12-02 Go Daddy Operating Company, LLC Digital identity validation
US20080028100A1 (en) * 2004-10-29 2008-01-31 The Go Daddy Group, Inc. Tracking domain name related reputation
US20080022013A1 (en) * 2004-10-29 2008-01-24 The Go Daddy Group, Inc. Publishing domain name related reputation in whois records
US20060095404A1 (en) * 2004-10-29 2006-05-04 The Go Daddy Group, Inc Presenting search engine results based on domain name related reputation
US20070208940A1 (en) * 2004-10-29 2007-09-06 The Go Daddy Group, Inc. Digital identity related reputation tracking and publishing
US7970858B2 (en) * 2004-10-29 2011-06-28 The Go Daddy Group, Inc. Presenting search engine results based on domain name related reputation
US20060095459A1 (en) * 2004-10-29 2006-05-04 Warren Adelman Publishing domain name related reputation in whois records
US8180835B1 (en) 2006-10-14 2012-05-15 Engate Technology Corporation System and method for protecting mail servers from mail flood attacks
US8453235B1 (en) * 2006-12-15 2013-05-28 Oracle America, Inc. Controlling access to mail transfer agents by clients
WO2008097869A1 (en) * 2007-02-02 2008-08-14 Iconix, Inc. Authenticating and confidence marking e-mail messages
US20090271428A1 (en) * 2007-05-09 2009-10-29 The Go Daddy Group, Inc. Tracking digital identity related reputation data
US20090113328A1 (en) * 2007-10-30 2009-04-30 Penango, Inc. Multidimensional Multistate User Interface Element
US20090132713A1 (en) * 2007-11-20 2009-05-21 Microsoft Corporation Single-roundtrip exchange for cross-domain data access
JP2011507414A (en) * 2007-12-21 2011-03-03 コクーン データ ホールディングス リミテッド System and method for protecting data safety
US7950047B2 (en) * 2008-02-22 2011-05-24 Yahoo! Inc. Reporting on spoofed e-mail
US20100313253A1 (en) * 2009-06-09 2010-12-09 Walter Stanley Reiss Method, system and process for authenticating the sender, source or origin of a desired, authorized or legitimate email or electrinic mail communication
US8578465B2 (en) 2009-07-21 2013-11-05 Cisco Technology, Inc. Token-based control of permitted sub-sessions for online collaborative computing sessions
US9253199B2 (en) * 2010-09-09 2016-02-02 Red Hat, Inc. Verifying authenticity of a sender of an electronic message sent to a recipient using message salt
US9342274B2 (en) 2011-05-19 2016-05-17 Microsoft Technology Licensing, Llc Dynamic code generation and memory management for component object model data constructs
US8881101B2 (en) 2011-05-24 2014-11-04 Microsoft Corporation Binding between a layout engine and a scripting engine
US8997188B2 (en) * 2012-04-11 2015-03-31 Jerome Svigals System for enabling a smart device to securely accept unsolicited transactions
US9344437B2 (en) 2011-09-23 2016-05-17 Jerome Svigals Internet of things security
US9432378B1 (en) 2011-09-23 2016-08-30 Jerome Svigals Internet of things security
US9319404B2 (en) 2011-09-23 2016-04-19 Jerome Svigals Security for the internet of things
US9430452B2 (en) 2013-06-06 2016-08-30 Microsoft Technology Licensing, Llc Memory model for a layout engine and scripting engine
US9521138B2 (en) 2013-06-14 2016-12-13 Go Daddy Operating Company, LLC System for domain control validation
US9178888B2 (en) 2013-06-14 2015-11-03 Go Daddy Operating Company, LLC Method for domain control validation
US10079791B2 (en) * 2014-03-14 2018-09-18 Xpedite Systems, Llc Systems and methods for domain- and auto-registration
JP6508688B2 (en) 2014-10-31 2019-05-08 コンヴィーダ ワイヤレス, エルエルシー End-to-end service layer authentication
EP3272094B1 (en) 2015-03-16 2021-06-23 Convida Wireless, LLC End-to-end authentication at the service layer using public keying mechanisms
US9973337B2 (en) 2015-11-18 2018-05-15 International Business Machines Corporation Domain-server public-key reference
WO2019173732A1 (en) * 2018-03-09 2019-09-12 Trusona, Inc. Methods and systems for email verification

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6073242A (en) * 1998-03-19 2000-06-06 Agorics, Inc. Electronic authority server
US6292897B1 (en) * 1997-11-03 2001-09-18 International Business Machines Corporation Undeniable certificates for digital signature verification
US20020032853A1 (en) * 2000-04-17 2002-03-14 Preston Dan A. Secure dynamic link allocation system for mobile data communication
US6567913B1 (en) * 1998-12-24 2003-05-20 Pitney Bowes Inc. Selective security level certificate meter
US6584564B2 (en) * 2000-04-25 2003-06-24 Sigaba Corporation Secure e-mail system
US20030158961A1 (en) * 2001-12-17 2003-08-21 Fujitsu Limited Two-way communication method
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
US20050055410A1 (en) * 2003-05-09 2005-03-10 Landsman Richard A. Managing electronic messages
US20050172004A1 (en) * 2004-02-04 2005-08-04 Clay Fisher Methods and apparatuses for certifying electronic messages
US6986037B1 (en) * 2000-04-07 2006-01-10 Sendmail, Inc. Electronic mail system with authentication/encryption methodology for allowing connections to/from a message transfer agent
US7065547B2 (en) * 2000-03-09 2006-06-20 Persels Conrad G Integrated on-line system with enchanced data transfer protocol
US7127606B2 (en) * 1998-11-09 2006-10-24 First Data Corporation Account-based digital signature (ABDS) system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6256664B1 (en) * 1998-09-01 2001-07-03 Bigfix, Inc. Method and apparatus for computed relevance messaging
US6643684B1 (en) * 1998-10-08 2003-11-04 International Business Machines Corporation Sender- specified delivery customization
AU2001275298A1 (en) * 2000-06-06 2001-12-17 Ingeo Systems, Inc. Creating and verifying electronic documents
FR2825209A1 (en) * 2001-05-23 2002-11-29 Thomson Licensing Sa DEVICES AND METHOD FOR SECURING AND IDENTIFYING MESSAGES
US7191468B2 (en) * 2001-07-17 2007-03-13 The Boeing Company System and method for multidimensional data compression
US6704403B2 (en) * 2001-09-05 2004-03-09 Ingenio, Inc. Apparatus and method for ensuring a real-time connection between users and selected service provider using voice mail
US7130886B2 (en) * 2002-03-06 2006-10-31 Research In Motion Limited System and method for providing secure message signature status and trust status indication
AU2003278421A1 (en) * 2002-06-19 2004-01-06 Joseph C. Benowitz Technology enhanced communication authorization system
US7072944B2 (en) * 2002-10-07 2006-07-04 Ebay Inc. Method and apparatus for authenticating electronic mail
US20040111480A1 (en) * 2002-12-09 2004-06-10 Yue Jonathan Zhanjun Message screening system and method
US8024795B2 (en) * 2003-05-09 2011-09-20 Q1 Labs, Inc. Network intelligence system
US20050129021A1 (en) * 2003-12-15 2005-06-16 Kumar N. R. Packet header verification

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292897B1 (en) * 1997-11-03 2001-09-18 International Business Machines Corporation Undeniable certificates for digital signature verification
US6073242A (en) * 1998-03-19 2000-06-06 Agorics, Inc. Electronic authority server
US7127606B2 (en) * 1998-11-09 2006-10-24 First Data Corporation Account-based digital signature (ABDS) system
US6567913B1 (en) * 1998-12-24 2003-05-20 Pitney Bowes Inc. Selective security level certificate meter
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
US7065547B2 (en) * 2000-03-09 2006-06-20 Persels Conrad G Integrated on-line system with enchanced data transfer protocol
US6986037B1 (en) * 2000-04-07 2006-01-10 Sendmail, Inc. Electronic mail system with authentication/encryption methodology for allowing connections to/from a message transfer agent
US20020032853A1 (en) * 2000-04-17 2002-03-14 Preston Dan A. Secure dynamic link allocation system for mobile data communication
US6584564B2 (en) * 2000-04-25 2003-06-24 Sigaba Corporation Secure e-mail system
US20030158961A1 (en) * 2001-12-17 2003-08-21 Fujitsu Limited Two-way communication method
US20050055410A1 (en) * 2003-05-09 2005-03-10 Landsman Richard A. Managing electronic messages
US20050172004A1 (en) * 2004-02-04 2005-08-04 Clay Fisher Methods and apparatuses for certifying electronic messages

Cited By (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050210106A1 (en) * 2003-03-19 2005-09-22 Cunningham Brian D System and method for detecting and filtering unsolicited and undesired electronic messages
US8219630B2 (en) 2003-03-19 2012-07-10 Message Level, Llc System and method for detecting and filtering unsolicited and undesired electronic messages
US8005899B2 (en) 2003-03-19 2011-08-23 Message Level Llc System and method for detecting and filtering unsolicited and undesired electronic messages
US9026507B2 (en) 2004-05-02 2015-05-05 Thomson Reuters Global Resources Methods and systems for analyzing data related to possible online fraud
US8041769B2 (en) 2004-05-02 2011-10-18 Markmonitor Inc. Generating phish messages
US8769671B2 (en) 2004-05-02 2014-07-01 Markmonitor Inc. Online fraud solution
US20050257261A1 (en) * 2004-05-02 2005-11-17 Emarkmonitor, Inc. Online fraud solution
US20060068755A1 (en) * 2004-05-02 2006-03-30 Markmonitor, Inc. Early detection and monitoring of online fraud
US7992204B2 (en) 2004-05-02 2011-08-02 Markmonitor, Inc. Enhanced responses to online fraud
US7913302B2 (en) 2004-05-02 2011-03-22 Markmonitor, Inc. Advanced responses to online fraud
US9684888B2 (en) 2004-05-02 2017-06-20 Camelot Uk Bidco Limited Online fraud solution
US20070107053A1 (en) * 2004-05-02 2007-05-10 Markmonitor, Inc. Enhanced responses to online fraud
US20070192853A1 (en) * 2004-05-02 2007-08-16 Markmonitor, Inc. Advanced responses to online fraud
US7870608B2 (en) 2004-05-02 2011-01-11 Markmonitor, Inc. Early detection and monitoring of online fraud
US20070294762A1 (en) * 2004-05-02 2007-12-20 Markmonitor, Inc. Enhanced responses to online fraud
US20070294352A1 (en) * 2004-05-02 2007-12-20 Markmonitor, Inc. Generating phish messages
US20070299915A1 (en) * 2004-05-02 2007-12-27 Markmonitor, Inc. Customer-based detection of online fraud
US20070299777A1 (en) * 2004-05-02 2007-12-27 Markmonitor, Inc. Online fraud solution
US9203648B2 (en) 2004-05-02 2015-12-01 Thomson Reuters Global Resources Online fraud solution
US9356947B2 (en) 2004-05-02 2016-05-31 Thomson Reuters Global Resources Methods and systems for analyzing data related to possible online fraud
US20060069697A1 (en) * 2004-05-02 2006-03-30 Markmonitor, Inc. Methods and systems for analyzing data related to possible online fraud
US7457823B2 (en) * 2004-05-02 2008-11-25 Markmonitor Inc. Methods and systems for analyzing data related to possible online fraud
US8347095B2 (en) 2004-05-04 2013-01-01 Message Level, Llc System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison
US7747860B2 (en) 2004-05-04 2010-06-29 Message Level, Llc System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison
US20080086532A1 (en) * 2004-10-04 2008-04-10 Brian Cunningham Method for the Verification of Electronic Message Delivery and for the Collection of Data Related to Electronic Messages Sent with False Origination Addresses
US8725643B2 (en) 2004-10-29 2014-05-13 Blackberry Limited System and method for verifying digital signatures on certificates
US20100211795A1 (en) * 2004-10-29 2010-08-19 Research In Motion Limited System and method for verifying digital signatures on certificates
US9621352B2 (en) 2004-10-29 2017-04-11 Blackberry Limited System and method for verifying digital signatures on certificates
US9015263B2 (en) 2004-10-29 2015-04-21 Go Daddy Operating Company, LLC Domain name searching with reputation rating
US20060190606A1 (en) * 2005-02-22 2006-08-24 Kidaro Inc. Data transfer security
US7490353B2 (en) * 2005-02-22 2009-02-10 Kidaro, Inc. Data transfer security
US8060746B2 (en) * 2005-03-18 2011-11-15 Fujitsu Limited E-mail transfer method and device
US20060212703A1 (en) * 2005-03-18 2006-09-21 Fujitsu Limited E-mail transfer method and device
US20060277459A1 (en) * 2005-06-02 2006-12-07 Lemoine Eric T System and method of accelerating document processing
US20100162102A1 (en) * 2005-06-02 2010-06-24 Lemoine Eric T System and Method of Accelerating Document Processing
US7703006B2 (en) * 2005-06-02 2010-04-20 Lsi Corporation System and method of accelerating document processing
US20070028301A1 (en) * 2005-07-01 2007-02-01 Markmonitor Inc. Enhanced fraud monitoring systems
US8090786B2 (en) 2005-07-29 2012-01-03 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US8478830B2 (en) 2005-07-29 2013-07-02 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US20100281128A1 (en) * 2005-07-29 2010-11-04 Research In Motion Limited System and method for processing messages being composed by a user
US20070038704A1 (en) * 2005-07-29 2007-02-15 Research In Motion Limited System and method for processing messages being composed by a user
US20070038719A1 (en) * 2005-07-29 2007-02-15 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US8516068B2 (en) 2005-07-29 2013-08-20 Research In Motion Limited System and method for processing messages being composed by a user
US8244820B2 (en) 2005-07-29 2012-08-14 Research In Motion Limited System and method for processing messages being composed by a user
US20100121931A1 (en) * 2005-07-29 2010-05-13 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US8037149B2 (en) 2005-07-29 2011-10-11 Research In Motion Limited System and method for processing messages being composed by a user
US7653696B2 (en) * 2005-07-29 2010-01-26 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US7756932B2 (en) * 2005-07-29 2010-07-13 Research In Motion Limited System and method for processing messages being composed by a user
US9077524B2 (en) 2005-09-29 2015-07-07 Blackberry Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US20070071238A1 (en) * 2005-09-29 2007-03-29 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US8452970B2 (en) 2005-09-29 2013-05-28 Research In Motion Limited System and method for code signing
US20100332848A1 (en) * 2005-09-29 2010-12-30 Research In Motion Limited System and method for code signing
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US9444647B2 (en) 2006-02-14 2016-09-13 Message Level Llc Method for predelivery verification of an intended recipient of an electronic message and dynamic generation of message content upon verification
US20070260876A1 (en) * 2006-05-05 2007-11-08 Research In Motion Limited Method and system for sending secure messages
US20080086638A1 (en) * 2006-10-06 2008-04-10 Markmonitor Inc. Browser reputation indicators with two-way authentication
US20080091763A1 (en) * 2006-10-13 2008-04-17 Quipa Holdings Limited method for sharing functionality and/or data between two or more linked entities
US20090100079A1 (en) * 2007-10-12 2009-04-16 Fujitsu Limited E-mail information management apparatus, and e-mail information management method
US8832202B2 (en) * 2007-10-12 2014-09-09 Fujitsu Limited E-mail information management apparatus, and E-mail information management method
US20090106557A1 (en) * 2007-10-20 2009-04-23 Sean Leonard Methods and systems for indicating trustworthiness of secure communications
US8661260B2 (en) * 2007-10-20 2014-02-25 Sean Joseph Leonard Methods and systems for indicating trustworthiness of secure communications
US20090138711A1 (en) * 2007-11-21 2009-05-28 Dennis Heimbigner Sender Email Address Verification Using Reachback
US7827246B2 (en) 2008-03-14 2010-11-02 International Business Machines Corporation Dynamic domain based electronic mail signature lines
US20090234925A1 (en) * 2008-03-14 2009-09-17 International Business Machines Corporation Dyanmic Domain Based Electronic Mail Signature Lines
US9130962B2 (en) * 2008-06-30 2015-09-08 Symantec Corporation Calculating domain registrar reputation by analysis of hosted domains
US20090328224A1 (en) * 2008-06-30 2009-12-31 Brian Hernacki Calculating Domain Registrar Reputation by Analysis of Hosted Domains
US8285798B2 (en) 2009-04-15 2012-10-09 Ecert, Inc. System and method for the management of message policy
US20100299399A1 (en) * 2009-04-15 2010-11-25 Kelly Wanser System and Method for the Management of Message Policy
US8515969B2 (en) 2010-02-19 2013-08-20 Go Daddy Operating Company, LLC Splitting a character string into keyword strings
US8909558B1 (en) 2010-02-19 2014-12-09 Go Daddy Operating Company, LLC Appraising a domain name using keyword monetary value data
US20110208513A1 (en) * 2010-02-19 2011-08-25 The Go Daddy Group, Inc. Splitting a character string into keyword strings
US9058393B1 (en) 2010-02-19 2015-06-16 Go Daddy Operating Company, LLC Tools for appraising a domain name using keyword monetary value data
US20110208723A1 (en) * 2010-02-19 2011-08-25 The Go Daddy Group, Inc. Calculating reliability scores from word splitting
US8706728B2 (en) 2010-02-19 2014-04-22 Go Daddy Operating Company, LLC Calculating reliability scores from word splitting
US8572496B2 (en) * 2010-04-27 2013-10-29 Go Daddy Operating Company, LLC Embedding variable fields in individual email messages sent via a web-based graphical user interface
US20110265016A1 (en) * 2010-04-27 2011-10-27 The Go Daddy Group, Inc. Embedding Variable Fields in Individual Email Messages Sent via a Web-Based Graphical User Interface
US8621005B2 (en) * 2010-04-28 2013-12-31 Ttb Technologies, Llc Computer-based methods and systems for arranging meetings between users and methods and systems for verifying background information of users
US20110270926A1 (en) * 2010-04-28 2011-11-03 John Boyd Computer-based Methods and Systems for Arranging Meetings Between Users and Methods and Systems for Verifying Background Information of Users
US9451050B2 (en) 2011-04-22 2016-09-20 Go Daddy Operating Company, LLC Domain name spinning from geographic location data
US9270638B2 (en) 2012-01-20 2016-02-23 Cisco Technology, Inc. Managing address validation states in switches snooping IPv6
US8931098B2 (en) * 2012-05-10 2015-01-06 Fujitsu Limited Detecting method and device
US20130305367A1 (en) * 2012-05-10 2013-11-14 Fujitsu Limited Detecting method and device
US9275040B1 (en) 2012-09-14 2016-03-01 Go Daddy Operating Company, LLC Validating user control over contact information in a domain name registration database
US9864755B2 (en) 2013-03-08 2018-01-09 Go Daddy Operating Company, LLC Systems for associating an online file folder with a uniform resource locator
US10313286B2 (en) * 2013-07-11 2019-06-04 Blackberry Limited Qualified email headers
US20150019652A1 (en) * 2013-07-11 2015-01-15 Blackberry Limited Qualified Email Headers
US9684918B2 (en) 2013-10-10 2017-06-20 Go Daddy Operating Company, LLC System and method for candidate domain name generation
US9715694B2 (en) 2013-10-10 2017-07-25 Go Daddy Operating Company, LLC System and method for website personalization from survey data
US9565147B2 (en) 2014-06-30 2017-02-07 Go Daddy Operating Company, LLC System and methods for multiple email services having a common domain
US10897485B2 (en) * 2015-02-14 2021-01-19 Valimail Inc. Centralized validation of email senders via EHLO name and IP address targeting
US11057437B2 (en) * 2015-02-14 2021-07-06 Valimail Inc. Centralized validation of email senders via EHLO name and IP address targeting
US11368494B2 (en) 2015-02-14 2022-06-21 Valimail Inc. Authentication of email senders via authorizing DNS server
US11431756B2 (en) 2015-02-14 2022-08-30 Valimail Inc. Authentication of email senders via authorizing DNS server
US11582263B2 (en) 2015-02-14 2023-02-14 Valimail Inc. Centralized validation of email senders via EHLO name and IP address targeting
US20230224334A1 (en) * 2015-02-14 2023-07-13 Valimail Inc. Delegated domain name system responder for emails
US11811831B2 (en) * 2015-02-14 2023-11-07 Valimail Inc. Delegated domain name system responder for emails
US10122734B2 (en) * 2016-11-29 2018-11-06 At&T Intellectual Property I, L.P. Secure email verification service
US20180152461A1 (en) * 2016-11-29 2018-05-31 At&T Intellectual Property I, L.P. Secure Email Verification Service
US11416852B1 (en) * 2017-12-15 2022-08-16 Worldpay, Llc Systems and methods for generating and transmitting electronic transaction account information messages
US11587083B2 (en) 2019-12-11 2023-02-21 At&T Intellectual Property I, L.P. Transaction validation service

Also Published As

Publication number Publication date
WO2005119481A3 (en) 2016-03-10
US8156554B2 (en) 2012-04-10
US20080320591A1 (en) 2008-12-25
WO2005119481A2 (en) 2005-12-15
US7437558B2 (en) 2008-10-14

Similar Documents

Publication Publication Date Title
US7437558B2 (en) Method and system for verifying identification of an electronic mail message
US8090940B1 (en) Method and system for verifying identification of an electronic message
US9065842B2 (en) Methods and systems for authenticating electronic messages using client-generated encryption keys
US7650383B2 (en) Electronic message system with federation of trusted senders
Crocker et al. Domainkeys identified mail (DKIM) signatures
Delany Domain-based email authentication using public keys advertised in the DNS (DomainKeys)
US7774411B2 (en) Secure electronic message transport protocol
US7376835B2 (en) Implementing nonrepudiation and audit using authentication assertions and key servers
US7277549B2 (en) System for implementing business processes using key server events
US8756289B1 (en) Message authentication using signatures
US20090138711A1 (en) Sender Email Address Verification Using Reachback
US7730145B1 (en) Anti-UCE system and method using class-based certificates
US20060143136A1 (en) Trusted electronic messaging system
US20070255815A1 (en) Software, Systems, and Methods for Secure, Authenticated Data Exchange
US8875251B2 (en) Publicly available protected electronic mail system
US20050193130A1 (en) Methods and systems for confirmation of availability of messaging account to user
US20060218235A1 (en) Spam prevention by legal user database and user authentication
Herzberg DNS-based email sender authentication mechanisms: A critical review
Crocker et al. RFC 6376: Domainkeys identified mail (DKIM) signatures
US20220255750A1 (en) Electronic messaging security and authentication
Zhao et al. An add-on end-to-end secure email solution in mobile communications
Orman From Whom?: SMTP Headers Hold the Clues
Delany RFC 4870: Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
CN116170401A (en) Distributed mailbox system based on block chain
Hansen et al. DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FENTON, JAMES L.;THOMAS, MICHAEL A.;BAKER, FREDERICK J.;REEL/FRAME:016014/0032

Effective date: 20040528

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12