CA2450488C - System and method for eliminating unsolicited e-mail - Google Patents
System and method for eliminating unsolicited e-mail Download PDFInfo
- Publication number
- CA2450488C CA2450488C CA002450488A CA2450488A CA2450488C CA 2450488 C CA2450488 C CA 2450488C CA 002450488 A CA002450488 A CA 002450488A CA 2450488 A CA2450488 A CA 2450488A CA 2450488 C CA2450488 C CA 2450488C
- Authority
- CA
- Canada
- Prior art keywords
- message
- key
- messages
- authentication key
- correspondent
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/212—Monitoring or handling of messages using filtering or selective blocking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention is a system and method for eliminating unsolicited e-mail. The invention employs the simple approach of limiting correspondence to known correspondents through a system of authentication, while allowing persons who are not authenticated correspondents to petition correspondence by means of an extremely restrictive message format that is useless for marketing purposes. The system uses a Header Parser [102] to sort all incoming electronic mail into solicited and unsolicited messages without parsing the message body. It allows unauthenticated correspondents to solicit correspondence by means of a specially tagged message format called a Request Correspondence Message, and makes use of a Format Inspector [103] to ensure that all such solicitations meet strict format requirements which make it impraticable to use such messages for the purposes of marketing or solicitation. Authenticated Correspondents are managed for each user with an Authentication Key Database [106]. The integrity of the system is maintained by means of a transactional exchange of authentication keys, which are transformed with each exchange to prevent keys from being intercepted and reused. This method allows users to maintain absolutely unique key signatures, which can be attached to message headers and sent in, clear without fear of interception or spoofing. This safeguard makes it impossible to share, sell, or compromise users' correspondent lists, and makes this approach to eliminating unsolicited e-mail unique from any similar method that employs correspondent lists.
Description
CA 02450488 2008-10-21 ndustry mauetrie Canada Canatla ~` '~rnn,v 295 ~II 08 II~
CiPO OPIC E001067662 S ystem and Method for Eliminating Unsolicited E-Mail Background of the Invention:
The burgeoning problem of unsolicited electronic mail, or e-mail "Spam" is well documented, and many methods have been suggested to try to stem this problem. The "Spam" tag, incidentally, originated from an early Monty Python sketch in which a diner at a greasy spoon discovers that every item on the menu includes Spam, (a notorious and noxious tinned luncheon meat), whether he wants it or not. The e-mail phenomenon works in much the same way - in addition to the messages you want, you get a good deal of what you don't want.
The true cost of this problem goes far beyond the inconvenience and annoyance of individual users, who often find that they receive far more e-mail messages they don't want, than messages they do want. Direct e-mail sales have become the province of hucksters, fraudsters and unprincipled marketeers who are very clever at circumventing software designed to filter out their solicitations. They employ very sophisticated means to hide the origin of the message, and even its content; sometimes encoding the entire message body in a binary format so it can not be parsed properly by e-mail filtering software.
The problem stems in the fact that existing e-mail protocols were written by academics who couldn't conceive that they were laying the groundwork for a means of communication that dishonest people would exploit. They simply couldn't imagine someone not wanting to receive an e-mail message.
Ideally, the solution would be to scrap the old standards, and start again with a completely fresh architecture that cannot be so easily exploited. The problem is that the existing standards are so widespread, and so widely implemented in different kinds of software that the expense of making a global change would be so large as to be virtually impracticable.
Not fixing the problem could have even graver consequences, as the cost of simply enduring the status quo, and attempting to filter the enormous volume of e-mail communications makes huge demands on bandwidth, software, and processor activity. In interviews with Internet Service Providers, I found that many of them have been obliged to buy more and more hardware simply to keep up with the demands of parsing and filtering incoming messages, and outwitting Spam marketeers who may try to co-opt their bandwidth to send e-mail campaigns.
A recent study of corporate communications calculated the cost of managing e-mail spam at over $800.00 (CDN) per seat, per annum.
Privacy and marketing legislation is not applied evenly on an international basis and is virtually impossible to enforce. More sadly still, many unsolicited messages become vectors for the initial dispersion of mass mailing worms and other malicious software.
My approach to the problem was to try to engineer a system and method of controlling correspondents that would uphold three first principles:
1) any solution that can be globally applied must use existing protocols so as to avoid obsolescence and unnecessary expense 2) the solution must be scalable, so it can be adopted alongside existing e-mail architecture without conflict, both by networks and individual users, and 3) It must be simple and secure.
The simplest approach is not to control and filter messages, but to filter correspondents. There are already existing patents, and perhaps more pending that use a variation on this approach:
that of a list or table of authenticated correspondents.
However, there has to be a simple means of allowing new users and acquaintances to contact users and solicit correspondence, or change their e-mail addresses while still maintaining their contacts.
My solution to this problem is to use extensions to the SMTP protocol, (as described in RFC
1869) to tag messages and divide them into two main groups: Authenticated Correspondent Messages, (from people you know and trust), and Request Correspondence Messages, (short messages asking for permission to correspond).
To prevent Spam marketeers from co-opting Request Correspondence Messages to sell you things, and to prevent the spread of mass-mailing worms and malicious code, all Request Correspondence Messages would be checked by a format inspector to make certain they meet certain conditions. They would have to be short - no more than 300 characters, and they could not include hyperlinks, web addresses, or attachments. This would render them useless for transmitting Spam and make it impossible to attach malicious code.
The second problem is that any means of tracking and managing correspondents is vulnerable, because existing protocols make it very easy to "spoof' a correspondent, or make it appear that a message has been sent by another person. There would a great temptation for less than honest Internet Service Providers or hackers to steal and sell users' correspondent lists. It is necessary to ensure that a message purporting to come from a particular person does, in fact, come from that person.
The solution to this problem is to assign every user a unique identity or key that can not be stolen or duplicated. My solution is described in another patent application: A
system and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition.
Transactional Successive Transposition is a means of sending unencrypted keys that are transformed in every exchange, rendering it pointless to intercept or copy them. This process has other applications besides securing e-mail, and for that reason is described in a separate patent application.
Summary of the Invention:
This is a system and method for eliminating unsolicited e-mail. The fundamental principles of this system are threefold: that it use existing protocols so as to avoid obsolescence and unnecessary expense; that it be scalable, so it can be adopted alongside existing e-mail architecture without conflict, both by networks and individual users; and that it be simple and secure.
In its most basic embodiment, the Invention restricts full-format e-mail messages to trusted (Authenticated), correspondents, and requires anyone else to use a restricted format which permits only 300 Bytes of ASCII text.
The system employs new header types as extensions to the Simple Mail Transfer Protocol, (SMTP) as described in RFC 1869 to divide electronic mail into one of three classes: Request Correspondence Messages (RCMs), Authenticated Correspondent Messages (ACMs), and Key Grant Messages (KGMs).
Authenticated Correspondent Messages are messages from known and trusted correspondents.
Request Correspondent Messages allow putative correspondents to make contact with a user and request permission to correspond, (within a highly restricted format that prevents the inclusion of hyperlinks, attachments, or more than 300 bytes of text), and Key Grant Messages allow a user to grant permission to a new correspondent to send messages -assigning an identity to that correspondent in the process.
Identity spoofing is prevented by the use of a unique Authentication Key for each user, which is transposed on each use, as described in a separate patent application applied for by the same person. [Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
Any messages that do not have the required headers, or fit one of these three formats are simply discarded; thus eliminating the need to parse the message body, or maintain databases of filters, and reducing server load and the risk of the transmission of mass mailing worms.
This system is meant to be implemented on a network wide basis with a mail server component, but it can also be adopted in a less robust manner by individual users, allowing for a natural evolution of adoption and implementation.
In the drawings, which form a part of this specification, Illustration 1 is a logical diagram showing the system and mechanism for inspecting incoming e-mail messages;
Illustration 2 is a logical diagram showing the system and mechanism for handling outgoing e-mail messages; and Illustration 3 is a table of header and format requirements for the three main classes of e-mail message used by the invention.
CiPO OPIC E001067662 S ystem and Method for Eliminating Unsolicited E-Mail Background of the Invention:
The burgeoning problem of unsolicited electronic mail, or e-mail "Spam" is well documented, and many methods have been suggested to try to stem this problem. The "Spam" tag, incidentally, originated from an early Monty Python sketch in which a diner at a greasy spoon discovers that every item on the menu includes Spam, (a notorious and noxious tinned luncheon meat), whether he wants it or not. The e-mail phenomenon works in much the same way - in addition to the messages you want, you get a good deal of what you don't want.
The true cost of this problem goes far beyond the inconvenience and annoyance of individual users, who often find that they receive far more e-mail messages they don't want, than messages they do want. Direct e-mail sales have become the province of hucksters, fraudsters and unprincipled marketeers who are very clever at circumventing software designed to filter out their solicitations. They employ very sophisticated means to hide the origin of the message, and even its content; sometimes encoding the entire message body in a binary format so it can not be parsed properly by e-mail filtering software.
The problem stems in the fact that existing e-mail protocols were written by academics who couldn't conceive that they were laying the groundwork for a means of communication that dishonest people would exploit. They simply couldn't imagine someone not wanting to receive an e-mail message.
Ideally, the solution would be to scrap the old standards, and start again with a completely fresh architecture that cannot be so easily exploited. The problem is that the existing standards are so widespread, and so widely implemented in different kinds of software that the expense of making a global change would be so large as to be virtually impracticable.
Not fixing the problem could have even graver consequences, as the cost of simply enduring the status quo, and attempting to filter the enormous volume of e-mail communications makes huge demands on bandwidth, software, and processor activity. In interviews with Internet Service Providers, I found that many of them have been obliged to buy more and more hardware simply to keep up with the demands of parsing and filtering incoming messages, and outwitting Spam marketeers who may try to co-opt their bandwidth to send e-mail campaigns.
A recent study of corporate communications calculated the cost of managing e-mail spam at over $800.00 (CDN) per seat, per annum.
Privacy and marketing legislation is not applied evenly on an international basis and is virtually impossible to enforce. More sadly still, many unsolicited messages become vectors for the initial dispersion of mass mailing worms and other malicious software.
My approach to the problem was to try to engineer a system and method of controlling correspondents that would uphold three first principles:
1) any solution that can be globally applied must use existing protocols so as to avoid obsolescence and unnecessary expense 2) the solution must be scalable, so it can be adopted alongside existing e-mail architecture without conflict, both by networks and individual users, and 3) It must be simple and secure.
The simplest approach is not to control and filter messages, but to filter correspondents. There are already existing patents, and perhaps more pending that use a variation on this approach:
that of a list or table of authenticated correspondents.
However, there has to be a simple means of allowing new users and acquaintances to contact users and solicit correspondence, or change their e-mail addresses while still maintaining their contacts.
My solution to this problem is to use extensions to the SMTP protocol, (as described in RFC
1869) to tag messages and divide them into two main groups: Authenticated Correspondent Messages, (from people you know and trust), and Request Correspondence Messages, (short messages asking for permission to correspond).
To prevent Spam marketeers from co-opting Request Correspondence Messages to sell you things, and to prevent the spread of mass-mailing worms and malicious code, all Request Correspondence Messages would be checked by a format inspector to make certain they meet certain conditions. They would have to be short - no more than 300 characters, and they could not include hyperlinks, web addresses, or attachments. This would render them useless for transmitting Spam and make it impossible to attach malicious code.
The second problem is that any means of tracking and managing correspondents is vulnerable, because existing protocols make it very easy to "spoof' a correspondent, or make it appear that a message has been sent by another person. There would a great temptation for less than honest Internet Service Providers or hackers to steal and sell users' correspondent lists. It is necessary to ensure that a message purporting to come from a particular person does, in fact, come from that person.
The solution to this problem is to assign every user a unique identity or key that can not be stolen or duplicated. My solution is described in another patent application: A
system and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition.
Transactional Successive Transposition is a means of sending unencrypted keys that are transformed in every exchange, rendering it pointless to intercept or copy them. This process has other applications besides securing e-mail, and for that reason is described in a separate patent application.
Summary of the Invention:
This is a system and method for eliminating unsolicited e-mail. The fundamental principles of this system are threefold: that it use existing protocols so as to avoid obsolescence and unnecessary expense; that it be scalable, so it can be adopted alongside existing e-mail architecture without conflict, both by networks and individual users; and that it be simple and secure.
In its most basic embodiment, the Invention restricts full-format e-mail messages to trusted (Authenticated), correspondents, and requires anyone else to use a restricted format which permits only 300 Bytes of ASCII text.
The system employs new header types as extensions to the Simple Mail Transfer Protocol, (SMTP) as described in RFC 1869 to divide electronic mail into one of three classes: Request Correspondence Messages (RCMs), Authenticated Correspondent Messages (ACMs), and Key Grant Messages (KGMs).
Authenticated Correspondent Messages are messages from known and trusted correspondents.
Request Correspondent Messages allow putative correspondents to make contact with a user and request permission to correspond, (within a highly restricted format that prevents the inclusion of hyperlinks, attachments, or more than 300 bytes of text), and Key Grant Messages allow a user to grant permission to a new correspondent to send messages -assigning an identity to that correspondent in the process.
Identity spoofing is prevented by the use of a unique Authentication Key for each user, which is transposed on each use, as described in a separate patent application applied for by the same person. [Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
Any messages that do not have the required headers, or fit one of these three formats are simply discarded; thus eliminating the need to parse the message body, or maintain databases of filters, and reducing server load and the risk of the transmission of mass mailing worms.
This system is meant to be implemented on a network wide basis with a mail server component, but it can also be adopted in a less robust manner by individual users, allowing for a natural evolution of adoption and implementation.
In the drawings, which form a part of this specification, Illustration 1 is a logical diagram showing the system and mechanism for inspecting incoming e-mail messages;
Illustration 2 is a logical diagram showing the system and mechanism for handling outgoing e-mail messages; and Illustration 3 is a table of header and format requirements for the three main classes of e-mail message used by the invention.
Detailed Description of the Invention:
In order to protect users from unsolicited electronic mail in a full and effective manner, the invention processes both incoming and outgoing e-mail messages.
Incoming Messages As seen in Illustration 1, all incoming e-mail messages are examined by a Header Parser [102].
The Header Parser only examines the message headers, and does not parse the message body.
In an ideal embodiment of the invention, this component would be resident on the mail server, but in order to facilitate adoption over time, this component can also be resident on the end user's computer and associated with the any existing mail client software.
All messages that do not include valid headers can simply be discarded, or can be returned to the sender with an invitation message, according to the wishes of the end user or the network administrator.
In order to be accepted by the Header Parser, all incoming messages must be identified as being Authenticated Correspondent Messages (ACMs), Request Correspondence Messages (RCMs), or Key Grant Messages (KGMs).
Incoming Request Correspondence Messages If a message is identified as a Request Correspondent Message, it is in turn passed to the Format Inspector [103], which may be resident on the mail server or the client computer. The Format Inspector parses the message body in order to determine that it fits the required profile for a Request Correspondence Message.
In order to be accepted by the Header Parser [102], Request Correspondence Messages must include an identifier, and a key offer tag. Request Correspondence Messages can not exceed 300 Bytes in length. They must only include ASCII text. They can not include hyperlinks or web addresses, and they can not be multipart messages. Any message that does not fit this format is a potential threat, and is immediately discarded. Any valid Request Correspondence Message is therefore useless to a spam marketer, (as no web addresses or images can be attached to it), and perfectly safe for a user to download as no malicious code could possibly be fit within the format.
A typical Request Correspondence Message might be "Hi bob, this is Jerry Cartwright - we met at the MegaCorp trade show last week, and you gave me your card. Can you set up correspondence for us?" They are necessarily short and sweet - to waste as little of the user's time as possible while determining if this is, in fact, someone he wants to correspond with.
After all, the core concept of this system is to reduce the volume of bandwidth consumed by electronic mail.
Request Correspondence Messages that meet the required format are forwarded to the user e-mail client [107], and can be downloaded separately from other correspondence.
Incoming Authenticated Correspondent Messages Messages that are identified as Authenticated Correspondent Messages are virtually free from restrictions, except that they must include an Authentication Key header [102]. All Authenticated Correspondent Messages are forwarded to the Authentication Key Inspector [104], which is preferably resident on the mail server, but can also be resident on the client computer.
The Authentication Key Inspector does not parse the message body. The message body can be virtually any type of message, including multi-part messages, and it can include attachments, because it presumably originates with a correspondent that the user knows and trusts.
However, the attached Authentication Key is examined by the Authentication Key inspector [104], which invokes the Key Transformation Engine [105] to make certain that it corresponds to the stored key value in the Authentication Key Database [106] for the originating e-mail address. The Authentication Key Database can be present on the mail server or the client computer. If the originating e-mail address is not present in the database, the message is immediately discarded as a spoofed message.
Because the Simple Mail Transfer Protocol does not allow for the encryption of mail headers, the attached Authentication Key must be sent in clear, which means that it could possibly be intercepted or compromised. To prevent this, the Authentication Key is transposed with each mail transaction as described in a linked patent application.
New Authentication Key values are created via transposition based on the last received value, which is stored for incoming messages only, so the process is transactional.
[Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
The Authentication Key Inspector [104] retrieves the last stored value of the associated Key from the Authentication Key Database [106] and the Key Transformation Engine [105]
performs a reverse transposition. If after reverse transposition, the two values match, the new value for the Authentication Key is stored in the Authentication Key Database alongside the old value, and the message is forwarded to the user e-mail client [107].
The user can then be completely certain that the message he receives has originated with a trusted correspondent. The amount of processing and storage capacity required to examine the relatively tiny Authentication Keys is far less than that demanded by e-mail filtering systems that parse the message body of correspondence and match them against spam filters.
This is an important consideration for ISP's and large organizations that process a large volume of electronic correspondence.
The identity of the originating correspondent is protected with an Authentication Key, as opposed to simply storing tables of e-mail addresses to prevent message spoofing, (forging the originating e-mail address of correspondents is a common practice among spam marketers - I
have received many spam messages that purported to have been sent from large agencies like Microsoft TechNet, or even myself), and to prevent the theft or sale of correspondent lists. Since the keys are transposed with each transaction, it would be useless to try to steal or sell the data stored in the Authentication Key Database.
Incoming Key Grant Messages The third type of message that would be passed by the Header Parser [102] is a Key Grant Message (KGM). Key Grant Messages are used only at the beginning of a correspondence, and are only sent in response to a Request Correspondence Message. They include a key offer notification and two associated Authentication Key - one that is offered to the recipient, and the corresponding key that the recipient sent to the originator when requesting correspondence. The user will already have stored the corresponding Authentication Key in the Authentication Key Database [106] when he requested correspondence.
Under special circumstances, Key Grant Messages can be sent in order to change or renew an Authentication Key, but in that case, there would still be a corresponding entry in the Authentication Key Database.
The Header Parser would determine that the required headers were present in the message, before forwarding it to the Format Inspector [103]. Like Request Correspondence Messages (RCMs), the body of Key Grant Messages can not exceed 300 Bytes in length.
They must be ASCII text. They can not be multipart messages, and they can not include attachments.
If a Key Grant Message fits the required format, it is in turn passed to the Authentication Key Inspector [104]. The Authentication Key Inspector would examine the headers in much the same way it does for Authenticated Correspondent Messages, and invoke the Key Transformation Engine [105] in order to verify that there is a matching Authentication Key in the Authentication Key Database [106] which corresponds to the sender's e-mail address. This is the only time when it would be mathematically possible to determine both parts of a key pair, because the corresponding key required to perform a reverse transposition is also included in the message headers.
This is the only point at which the Invention is vulnerable to spoofing or interception, because by intercepting a Key Grant Message, one would have the means to recreate the key transpositions between users. However, the risk of the correspondence being compromised is minimal, because in order to spoof or forge an Authenticated Correspondent Message, one would have to know not only both originating keys, but also exactly how many messages have been exchanged between both correspondents. Even if this were known, both correspondents are free to change or renew their keys at any point in their correspondence. This makes message identity forgery a virtual impossibility, and absolutely useless from the point of view of a spam marketer.
Outgoing Messages Illustration 2 shows how the process is reversed to handle outgoing correspondence. All outgoing e-mail messages are first examined by the Correspondent Processor [202], which is resident on the client computer. This component can either be integrated into the user's e-mail client software, or set up as a plug-in or proxy to it in order to allow users to continue to make use of existing software while adopting the Invention. The Correspondent Processor examines each outgoing message in order to determine which class of message it is, and how to treat it.
Outgoing Request Correspondence Messages If the user is seeking to open correspondence with a new correspondent, the Correspondent Processor will generate the necessary headers to create a Request Correspondence Message (RCM). The Correspondent Processor will also invoke the Outgoing Format Inspector [204]. The Outgoing Format Inspector guides the user to create a valid Request Correspondence Message, and prompts him if the message is too long, or includes attachments, links, or HTML formatting, (which can not be included in a Request Correspondence Message).
When the user sends the message, the Outgoing Format Inspector [204] invokes the Authentication Key Generator [203]. The Authentication Key Generator creates a unique key for each correspondent. This is a pseudo-random string of 256 or more characters, which is associated with the recipient's e-mail address, and stored in the Local Authentication Key Database [206] in association with the recipient's e-mail address.
The Local Authentication Key Database is resident on the client computer and mirrors the content held for that user in the Authentication Key Database [209] resident on (or accessible to) the outgoing SMTP server [210] if the Invention is implemented on a network-wide basis.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Request Correspondent Message, it will forward the message to the Format Inspector [208].
When the Invention is implemented at the network level, the Format Inspector [208] is invoked to prevent malicious users from attempting to send malformed Request Correspondent Messages.
This is simply another layer of security designed to prevent the misuse and wastage of bandwidth.
If a message identified as a Request Correspondence Message fails to meet the required format, it will simply be discarded. If it passes muster, the Format Inspector will store the proffered Authentication Key and recipient's e-mail address in the Authentication Key Database [209]
before forwarding the message to the SMTP server to be stored in the transmission queue, and ultimately, sent to the recipient.
Outgoing Key Grant Messages If the user chooses to send an affirmative reply to a Request Correspondence Message (RCM), the Correspondent Processor [202] will prompt him to determine the duration for which to grant an Authentication Key. This can be for one week, one month, or one year, and will generate a Key Grant Message (KGM). It will also attach the proffered key included in the header of the Request Correspondence Message that the user is replying to the Key Grant Message.
At this point the Correspondent Processor [202] will invoke the Outgoing Format Inspector [204]
which will guide the user in creating a valid Key Grant Message and prompt him if the message is too long, or includes attachments, links, or HTML formatting, (which can not be included in a Key Grant Message).
When the user sends the message, the Outgoing Format Inspector [204] invokes the Authentication Key Generator [203]. The Authentication Key Generator creates a unique key for each correspondent. This is a pseudo-random string of 256 or more characters, which is associated with the recipient's e-mail address, and stored in the Local Authentication Key Database [206] in association with the recipient's e-mail address. Since the Key Grant Message is generated in Response to a Request Correspondence Message, the original Authentication Key proffered in the Request Correspondence Message is also stored in association with his or her e-mail address.
In effect the Authentication Key Databases store up to three Authentication Key values for each correspondent: the Reference Key, and the Transformation Key, which in the case of a Key Grant Message would be the newly generated outgoing key, and the original key proffered by the Request Correspondence Message. At the next exchange or iteration, a third derived value would also be stored, and then with every successive transformation, each value would be replaced, and the old Reference Key would be discarded. The process of Authentication Key exchange and transformation is explained in greater detail in a separate application.
[Canada, Patent 2,438,809:
System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
The Local Authentication Key Database is resident on the client computer and mirrors the content held for that user in the Authentication Key Database [209] resident on the outgoing SMTP server [210] if the Invention is implemented on a network wide basis.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Key Grant Message, it will forward the message to the Format Inspector [208].
If a message identified as a Key Grant Message fails to meet the required format, it will simply be discarded. If it passes muster, the Format Inspector will store the proffered Authentication Keys and recipient's e-mail address in the Authentication Key Database [209] before forwarding the message to the SMTP server to be stored in the transmission queue, and ultimately, sent to the recipient.
Outgoing Authenticated Correspondent Messages While the process of initiating correspondence with new users requires a certain amount of user intervention at either end, the most advantageous aspect of the Invention is that corresponding with trusted or regular correspondents is completely transparent to the user, and requires absolutely no intervention on his part.
When a user composes a message to a known correspondent the Correspondent Processor [202] will query the Local Authentication Key Database [206].
If that correspondent's e-mail address is found in the Local Authentication Key Database, the associated Authentication Keys will be retrieved from the Local Authentication Key Database [206], and the newer value will be used as a template to transpose the older one by the Key Transformation Engine [205]. The newly transformed Authentication Key will be attached as a header to the outgoing message.
When the user sends the message, the assembled message is forwarded to the mail server.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Authenticated Correspondent Message, it will forward the message to the SMTP
server to be stored in the transmission queue, and ultimately, sent to the recipient. The transformed value of the key is not stored.
The process of Authentication Key exchange and transformation is explained in greater detail in a separate application. [Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
Revoking Correspondence Privileges In order to prevent abuse of the Invention, either party to a correspondence can terminate it at any time by simply transmitting a Key Revoke Message (KRM). This is a special message format that simply states that the Authentication Key that allows correspondence between two users has been revoked at the instigation of the sender. Once a key has been revoked, if a user tries to send a message to a correspondent who has sent a Key Revoke Message, the Correspondent Processor [202] will advise the user that he or she must send a new Request Correspondence Message, and obtain a Key Grant in order to correspond again.
In order to protect users from unsolicited electronic mail in a full and effective manner, the invention processes both incoming and outgoing e-mail messages.
Incoming Messages As seen in Illustration 1, all incoming e-mail messages are examined by a Header Parser [102].
The Header Parser only examines the message headers, and does not parse the message body.
In an ideal embodiment of the invention, this component would be resident on the mail server, but in order to facilitate adoption over time, this component can also be resident on the end user's computer and associated with the any existing mail client software.
All messages that do not include valid headers can simply be discarded, or can be returned to the sender with an invitation message, according to the wishes of the end user or the network administrator.
In order to be accepted by the Header Parser, all incoming messages must be identified as being Authenticated Correspondent Messages (ACMs), Request Correspondence Messages (RCMs), or Key Grant Messages (KGMs).
Incoming Request Correspondence Messages If a message is identified as a Request Correspondent Message, it is in turn passed to the Format Inspector [103], which may be resident on the mail server or the client computer. The Format Inspector parses the message body in order to determine that it fits the required profile for a Request Correspondence Message.
In order to be accepted by the Header Parser [102], Request Correspondence Messages must include an identifier, and a key offer tag. Request Correspondence Messages can not exceed 300 Bytes in length. They must only include ASCII text. They can not include hyperlinks or web addresses, and they can not be multipart messages. Any message that does not fit this format is a potential threat, and is immediately discarded. Any valid Request Correspondence Message is therefore useless to a spam marketer, (as no web addresses or images can be attached to it), and perfectly safe for a user to download as no malicious code could possibly be fit within the format.
A typical Request Correspondence Message might be "Hi bob, this is Jerry Cartwright - we met at the MegaCorp trade show last week, and you gave me your card. Can you set up correspondence for us?" They are necessarily short and sweet - to waste as little of the user's time as possible while determining if this is, in fact, someone he wants to correspond with.
After all, the core concept of this system is to reduce the volume of bandwidth consumed by electronic mail.
Request Correspondence Messages that meet the required format are forwarded to the user e-mail client [107], and can be downloaded separately from other correspondence.
Incoming Authenticated Correspondent Messages Messages that are identified as Authenticated Correspondent Messages are virtually free from restrictions, except that they must include an Authentication Key header [102]. All Authenticated Correspondent Messages are forwarded to the Authentication Key Inspector [104], which is preferably resident on the mail server, but can also be resident on the client computer.
The Authentication Key Inspector does not parse the message body. The message body can be virtually any type of message, including multi-part messages, and it can include attachments, because it presumably originates with a correspondent that the user knows and trusts.
However, the attached Authentication Key is examined by the Authentication Key inspector [104], which invokes the Key Transformation Engine [105] to make certain that it corresponds to the stored key value in the Authentication Key Database [106] for the originating e-mail address. The Authentication Key Database can be present on the mail server or the client computer. If the originating e-mail address is not present in the database, the message is immediately discarded as a spoofed message.
Because the Simple Mail Transfer Protocol does not allow for the encryption of mail headers, the attached Authentication Key must be sent in clear, which means that it could possibly be intercepted or compromised. To prevent this, the Authentication Key is transposed with each mail transaction as described in a linked patent application.
New Authentication Key values are created via transposition based on the last received value, which is stored for incoming messages only, so the process is transactional.
[Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
The Authentication Key Inspector [104] retrieves the last stored value of the associated Key from the Authentication Key Database [106] and the Key Transformation Engine [105]
performs a reverse transposition. If after reverse transposition, the two values match, the new value for the Authentication Key is stored in the Authentication Key Database alongside the old value, and the message is forwarded to the user e-mail client [107].
The user can then be completely certain that the message he receives has originated with a trusted correspondent. The amount of processing and storage capacity required to examine the relatively tiny Authentication Keys is far less than that demanded by e-mail filtering systems that parse the message body of correspondence and match them against spam filters.
This is an important consideration for ISP's and large organizations that process a large volume of electronic correspondence.
The identity of the originating correspondent is protected with an Authentication Key, as opposed to simply storing tables of e-mail addresses to prevent message spoofing, (forging the originating e-mail address of correspondents is a common practice among spam marketers - I
have received many spam messages that purported to have been sent from large agencies like Microsoft TechNet, or even myself), and to prevent the theft or sale of correspondent lists. Since the keys are transposed with each transaction, it would be useless to try to steal or sell the data stored in the Authentication Key Database.
Incoming Key Grant Messages The third type of message that would be passed by the Header Parser [102] is a Key Grant Message (KGM). Key Grant Messages are used only at the beginning of a correspondence, and are only sent in response to a Request Correspondence Message. They include a key offer notification and two associated Authentication Key - one that is offered to the recipient, and the corresponding key that the recipient sent to the originator when requesting correspondence. The user will already have stored the corresponding Authentication Key in the Authentication Key Database [106] when he requested correspondence.
Under special circumstances, Key Grant Messages can be sent in order to change or renew an Authentication Key, but in that case, there would still be a corresponding entry in the Authentication Key Database.
The Header Parser would determine that the required headers were present in the message, before forwarding it to the Format Inspector [103]. Like Request Correspondence Messages (RCMs), the body of Key Grant Messages can not exceed 300 Bytes in length.
They must be ASCII text. They can not be multipart messages, and they can not include attachments.
If a Key Grant Message fits the required format, it is in turn passed to the Authentication Key Inspector [104]. The Authentication Key Inspector would examine the headers in much the same way it does for Authenticated Correspondent Messages, and invoke the Key Transformation Engine [105] in order to verify that there is a matching Authentication Key in the Authentication Key Database [106] which corresponds to the sender's e-mail address. This is the only time when it would be mathematically possible to determine both parts of a key pair, because the corresponding key required to perform a reverse transposition is also included in the message headers.
This is the only point at which the Invention is vulnerable to spoofing or interception, because by intercepting a Key Grant Message, one would have the means to recreate the key transpositions between users. However, the risk of the correspondence being compromised is minimal, because in order to spoof or forge an Authenticated Correspondent Message, one would have to know not only both originating keys, but also exactly how many messages have been exchanged between both correspondents. Even if this were known, both correspondents are free to change or renew their keys at any point in their correspondence. This makes message identity forgery a virtual impossibility, and absolutely useless from the point of view of a spam marketer.
Outgoing Messages Illustration 2 shows how the process is reversed to handle outgoing correspondence. All outgoing e-mail messages are first examined by the Correspondent Processor [202], which is resident on the client computer. This component can either be integrated into the user's e-mail client software, or set up as a plug-in or proxy to it in order to allow users to continue to make use of existing software while adopting the Invention. The Correspondent Processor examines each outgoing message in order to determine which class of message it is, and how to treat it.
Outgoing Request Correspondence Messages If the user is seeking to open correspondence with a new correspondent, the Correspondent Processor will generate the necessary headers to create a Request Correspondence Message (RCM). The Correspondent Processor will also invoke the Outgoing Format Inspector [204]. The Outgoing Format Inspector guides the user to create a valid Request Correspondence Message, and prompts him if the message is too long, or includes attachments, links, or HTML formatting, (which can not be included in a Request Correspondence Message).
When the user sends the message, the Outgoing Format Inspector [204] invokes the Authentication Key Generator [203]. The Authentication Key Generator creates a unique key for each correspondent. This is a pseudo-random string of 256 or more characters, which is associated with the recipient's e-mail address, and stored in the Local Authentication Key Database [206] in association with the recipient's e-mail address.
The Local Authentication Key Database is resident on the client computer and mirrors the content held for that user in the Authentication Key Database [209] resident on (or accessible to) the outgoing SMTP server [210] if the Invention is implemented on a network-wide basis.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Request Correspondent Message, it will forward the message to the Format Inspector [208].
When the Invention is implemented at the network level, the Format Inspector [208] is invoked to prevent malicious users from attempting to send malformed Request Correspondent Messages.
This is simply another layer of security designed to prevent the misuse and wastage of bandwidth.
If a message identified as a Request Correspondence Message fails to meet the required format, it will simply be discarded. If it passes muster, the Format Inspector will store the proffered Authentication Key and recipient's e-mail address in the Authentication Key Database [209]
before forwarding the message to the SMTP server to be stored in the transmission queue, and ultimately, sent to the recipient.
Outgoing Key Grant Messages If the user chooses to send an affirmative reply to a Request Correspondence Message (RCM), the Correspondent Processor [202] will prompt him to determine the duration for which to grant an Authentication Key. This can be for one week, one month, or one year, and will generate a Key Grant Message (KGM). It will also attach the proffered key included in the header of the Request Correspondence Message that the user is replying to the Key Grant Message.
At this point the Correspondent Processor [202] will invoke the Outgoing Format Inspector [204]
which will guide the user in creating a valid Key Grant Message and prompt him if the message is too long, or includes attachments, links, or HTML formatting, (which can not be included in a Key Grant Message).
When the user sends the message, the Outgoing Format Inspector [204] invokes the Authentication Key Generator [203]. The Authentication Key Generator creates a unique key for each correspondent. This is a pseudo-random string of 256 or more characters, which is associated with the recipient's e-mail address, and stored in the Local Authentication Key Database [206] in association with the recipient's e-mail address. Since the Key Grant Message is generated in Response to a Request Correspondence Message, the original Authentication Key proffered in the Request Correspondence Message is also stored in association with his or her e-mail address.
In effect the Authentication Key Databases store up to three Authentication Key values for each correspondent: the Reference Key, and the Transformation Key, which in the case of a Key Grant Message would be the newly generated outgoing key, and the original key proffered by the Request Correspondence Message. At the next exchange or iteration, a third derived value would also be stored, and then with every successive transformation, each value would be replaced, and the old Reference Key would be discarded. The process of Authentication Key exchange and transformation is explained in greater detail in a separate application.
[Canada, Patent 2,438,809:
System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
The Local Authentication Key Database is resident on the client computer and mirrors the content held for that user in the Authentication Key Database [209] resident on the outgoing SMTP server [210] if the Invention is implemented on a network wide basis.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Key Grant Message, it will forward the message to the Format Inspector [208].
If a message identified as a Key Grant Message fails to meet the required format, it will simply be discarded. If it passes muster, the Format Inspector will store the proffered Authentication Keys and recipient's e-mail address in the Authentication Key Database [209] before forwarding the message to the SMTP server to be stored in the transmission queue, and ultimately, sent to the recipient.
Outgoing Authenticated Correspondent Messages While the process of initiating correspondence with new users requires a certain amount of user intervention at either end, the most advantageous aspect of the Invention is that corresponding with trusted or regular correspondents is completely transparent to the user, and requires absolutely no intervention on his part.
When a user composes a message to a known correspondent the Correspondent Processor [202] will query the Local Authentication Key Database [206].
If that correspondent's e-mail address is found in the Local Authentication Key Database, the associated Authentication Keys will be retrieved from the Local Authentication Key Database [206], and the newer value will be used as a template to transpose the older one by the Key Transformation Engine [205]. The newly transformed Authentication Key will be attached as a header to the outgoing message.
When the user sends the message, the assembled message is forwarded to the mail server.
If the Invention is implemented by the user's ISP or organization, all outgoing messages will be examined by the Header Parser [207]. If the Header Parser determines that the outgoing message is a Authenticated Correspondent Message, it will forward the message to the SMTP
server to be stored in the transmission queue, and ultimately, sent to the recipient. The transformed value of the key is not stored.
The process of Authentication Key exchange and transformation is explained in greater detail in a separate application. [Canada, Patent 2,438,809: System and method for the preservation of unique identity keys without encryption through a process of Transactional Successive Transposition. Filed by Christopher Ivey on 08/08/2003]
Revoking Correspondence Privileges In order to prevent abuse of the Invention, either party to a correspondence can terminate it at any time by simply transmitting a Key Revoke Message (KRM). This is a special message format that simply states that the Authentication Key that allows correspondence between two users has been revoked at the instigation of the sender. Once a key has been revoked, if a user tries to send a message to a correspondent who has sent a Key Revoke Message, the Correspondent Processor [202] will advise the user that he or she must send a new Request Correspondence Message, and obtain a Key Grant in order to correspond again.
Claims (27)
The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. A system for eliminating unsolicited incoming electronic mail sent to a user and verifying the identity of correspondents by means of unique Authentication Keys, wherein the system requires all email messages to originate from trusted correspondents and compels any new or unauthenticated correspondent to employ a restricted message format which is limited to 300 characters of plain text and can not include links or attachments, and wherein the system can interface with a plurality of email servers and email clients which reside on clients' computers without requiring encryption of data streams, the system further including:
a) a Header Parser [102] which examines the headers of all incoming email messages, and discards any messages which do not include a header declaring the message to be one of four acceptable message formats which include Request Correspondence Messages (RCM), Key Grant Messages (KGM), Authenticated Correspondent Messages (ACM), and Key Revoke Messages (KRM);
b) A Format Inspector [103] which examines the message content of certain declared message formats and discards any message which does not fit the expected format c) An Authentication Key Inspector [104] that examines Authentication Keys attached to incoming messages d) A Key Transformation Engine [105] which decodes the attached Authentication Keys e) An Authentication Key Database [106], which maintains a list of Authenticated Correspondent e-mail addresses and associated keys for each user of the system f) An interface to an e-mail server.
a) a Header Parser [102] which examines the headers of all incoming email messages, and discards any messages which do not include a header declaring the message to be one of four acceptable message formats which include Request Correspondence Messages (RCM), Key Grant Messages (KGM), Authenticated Correspondent Messages (ACM), and Key Revoke Messages (KRM);
b) A Format Inspector [103] which examines the message content of certain declared message formats and discards any message which does not fit the expected format c) An Authentication Key Inspector [104] that examines Authentication Keys attached to incoming messages d) A Key Transformation Engine [105] which decodes the attached Authentication Keys e) An Authentication Key Database [106], which maintains a list of Authenticated Correspondent e-mail addresses and associated keys for each user of the system f) An interface to an e-mail server.
2. A system according to claim 1, wherein any correspondence addressed to a user of the system must be identified as one of four message types, which are identified with headers extensions to the Simple Mail Transfer Protocol, (SMTP) as described in RFC
1869, and follow a prescribed format for that message type, These include:
a) Request Correspondence Messages (RCM) [301], which are a brief message requesting permission to correspond, and must include an identifying header and a key offer header;
Request Correspondence Messages must not exceed 300 Bytes in length and are subject to restrictions on content type and attachments b) Key Grant Messages (KGM) [302], which are a brief message issued in response to a Request Correspondence Message, granting an Authentication Key for continued correspondence; and must include an identifying header, a key offer header, and a valid Authentication Key; Key Grant Messages must not exceed 300 Bytes in length and are subject to restrictions on content type and attachments c) Authenticated Correspondent Messages (ACM) [303], which represent the bulk of normal correspondence between users and are not subject to restrictions on content type, length, or attachments, and must include an identifying header and an Authentication Key d) Key Revoke Messages (KRM) [304], which are a specialized message format that allow one correspondent to advise another that the Authentication Key which allows correspondence between them has been revoked at the instigation of the sender.
1869, and follow a prescribed format for that message type, These include:
a) Request Correspondence Messages (RCM) [301], which are a brief message requesting permission to correspond, and must include an identifying header and a key offer header;
Request Correspondence Messages must not exceed 300 Bytes in length and are subject to restrictions on content type and attachments b) Key Grant Messages (KGM) [302], which are a brief message issued in response to a Request Correspondence Message, granting an Authentication Key for continued correspondence; and must include an identifying header, a key offer header, and a valid Authentication Key; Key Grant Messages must not exceed 300 Bytes in length and are subject to restrictions on content type and attachments c) Authenticated Correspondent Messages (ACM) [303], which represent the bulk of normal correspondence between users and are not subject to restrictions on content type, length, or attachments, and must include an identifying header and an Authentication Key d) Key Revoke Messages (KRM) [304], which are a specialized message format that allow one correspondent to advise another that the Authentication Key which allows correspondence between them has been revoked at the instigation of the sender.
3. A system according to claim 2, whereby any correspondence addressed to a user of said system which is not identified as being one of these message types is discarded by the Header Parser [102].
4. A system according to claim 1, wherein the Header Parser [102], which may be resident on the mail server, or the client computer, parses the headers of all incoming e-mail messages and discards any messages which do not include a header declaring the message to be one of four acceptable message formats, which include Request Correspondence Messages (RCM), Key Grant Messages (KGM), Authenticated Correspondent Messages (ACM), and Key Revoke Messages (KRM), and forwards any messages identified as Key Grant Messages, Request Correspondence Messages, or Key Revoke Messages to the Format Inspector [103].
5. A system according to claim 1, wherein the Format Inspector in turn examines the content of each forwarded message, and discards any messages which do not meet the format and content requirements for the declared message type.
6. A system according to claim 5, wherein the Format Inspector forwards accepted Request Correspondent Messages to a separate database or storage queue for collection by the user, and forwards all Key Grant Messages and Key Revoke Messages to the Authentication Key Inspector [104].
7. A system according to claim 1, wherein the Authentication Key Inspector extracts the Authentication Keys and sender's FROM address attached to Key Grant Messages and Key Revoke Messages and queries the Authentication Key Database [106] to determine if there are associated entries for the sender's FROM address stored in the database;
if there is no matching entry, the messages are immediately discarded as forged or fraudulent.
if there is no matching entry, the messages are immediately discarded as forged or fraudulent.
8. A system according to claim 7 for examining authentication keys, whereby if there is a matching entry for the sender's e-mail address in the Authentication Key Database, the key value extracted from the message is processed by the Key Transformation Engine [105]; if the transformed value of the key matches the value stored in the Authentication Key Database, the message is forwarded to a separate database or storage queue for collection by the user.
9. A system according to claim 7, wherein if a message is a Key Grant Message, the extracted Authentication Key is stored in the Authentication Key Database [106] in association with the sender's e-mail address to be used in subsequent transpositions of the key, and the key duration, or lifetime of the key is extracted from the key value and stored in the Authentication Key Database.
10. A system according to claim 9, wherein if a message is a Key Revoke Message, the entries with a matching key are deleted from the Authentication Key Database.
11. A system according to claim 10, wherein the Header Parser [102], forwards any messages identified as Authenticated Correspondent Messages to the Authentication Key Inspector [103].
12. A system according to claim 11, wherein the Authentication Key Inspector extracts the Authentication Key and sender's FROM address attached to the Authenticated Correspondent Message and queries the Authentication Key Database [106] to determine if there are associated entries for the senders' FROM address stored in the database; if there is no matching entry, the message is immediately discarded as forged or fraudulent.
13. A system according to claim 12, whereby if there is a matching entry for the sender's e-mail address in the Authentication Key Database, the key value extracted from the message is processed by the Key Transformation Engine [105]; if the transformed value of the key matches the value stored in the Authentication Key Database, the message is forwarded to a separate database or storage queue for collection by the user, and the newly transposed value of the Authentication Key is stored in the Authentication Key Database [106].
14. A system according to claim 2, wherein the Header Parser [102] may be configured by the user to pass certain messages regardless of whether or not they are an accepted message type, based solely on the sender's FROM address matching an entry in the Authentication Key Database, in order to temporarily facilitate correspondence from familiar e-mail addresses.
15. A system according to claim 1 for processing outgoing electronic mail, operable both as a program or service entirely resident on the client computer, or employing a program or service resident on the client computer together with a process or daemon on the mail server, characterized by:
a) Client computer software which includes a Correspondent Processor [202], either integrated into the user's mail client software or operating as a proxy or plug-in b) An Authentication Key Generator [203], resident on the client computer which is used to generate a unique Authentication Key for each new correspondent; the Authentication Key is a pseudo-random string of 256 characters, which is associated with the correspondent's e-mail address in the Local Authentication Key Database [206]
c) An Outgoing Format Inspector [204], resident on the client computer, which guides the user to create valid Request Correspondence Messages (RCMs) and Key Grant Messages (KGMs) d) A Key Transformation Engine [205], resident on the client computer which transforms the Authentication Key attached to each outgoing message e) A Local Authentication Key Database [206], resident on the client computer which stores the e-mail addresses and Authentication Keys for all of the user's correspondents f) An interface to an SMTP mail server
a) Client computer software which includes a Correspondent Processor [202], either integrated into the user's mail client software or operating as a proxy or plug-in b) An Authentication Key Generator [203], resident on the client computer which is used to generate a unique Authentication Key for each new correspondent; the Authentication Key is a pseudo-random string of 256 characters, which is associated with the correspondent's e-mail address in the Local Authentication Key Database [206]
c) An Outgoing Format Inspector [204], resident on the client computer, which guides the user to create valid Request Correspondence Messages (RCMs) and Key Grant Messages (KGMs) d) A Key Transformation Engine [205], resident on the client computer which transforms the Authentication Key attached to each outgoing message e) A Local Authentication Key Database [206], resident on the client computer which stores the e-mail addresses and Authentication Keys for all of the user's correspondents f) An interface to an SMTP mail server
16. A system according to claim 15, whereby if said system is implemented at the network level by the user's organization, company, or Internet Service Provider, outgoing messages will also be examined by a Header Parser [207] and Format Inspector [208] on the outgoing mail server prior to being queued for transmission by the SMTP server
17. A system according to claim 15, wherein if the user replies to a Request Correspondence Message, the Correspondent Processor [202] will invoke the Outgoing Format Inspector [204], which will guide the user to create a properly formatted Key Grant Message, and further includes means for prompting the user to reduce the message size.
18. A system according to claim 15, wherein once the user transmits a Key Grant Message, the Correspondent Processor [202] will create a new entry for the recipient in the Local Authentication Key Database [206], and store the proffered Authentication Key attached to the original Request Correspondence Message in the Local Authentication Key Database;
this in turn will invoke the Authentication Key Generator [203] in order to create a new Authentication Key for the intended correspondent.
this in turn will invoke the Authentication Key Generator [203] in order to create a new Authentication Key for the intended correspondent.
19. A system according to claim 18, wherein the Authentication Key Generator will in its turn invoke the Key Transformation Engine [205] to combine the two Authentication Keys; the resulting transposed key will be attached to the outgoing message before it is transmitted to the mail server.
20. A system according to claim 15, wherein if the user attempts to send a message to a new correspondent, the Correspondent Processor [202] will query the Local Authentication Key Database [206], and if the recipient's e-mail address is not present, it will invoke the Outgoing Format Inspector [204].
21. A system according to claim 20, wherein the Outgoing Format Inspector will guide the user to create a properly formatted Request Correspondence Message, by limiting the message size and preventing the user from using HTML formatting or including attachments.
22. A system according to claim 21, wherein once the user transmits a Request Correspondence Message, the Correspondent Processor [202] will create a new entry for the recipient in the Local Authentication Key Database [206], and in turn invoke the Authentication Key Generator [203], to create a new Authentication Key for the putative correspondent; the resulting key will be attached to the outgoing message before it is transmitted to the mail server, and stored in the Local Authentication Key Database.
23. A system according to claim 15, wherein if the user attempts to send a message to an authenticated correspondent, the Correspondent Processor [202] will query the Local Authentication Key Database [206]; if the recipient's e-mail address is present, the Correspondent Processor will not invoke the Outgoing Format Inspector [204], and the user will be free to format an e-mail message in any way he or she chooses.
24. A system according to claim 23, wherein once the user transmits an Authenticated Correspondent Message, the Correspondent Processor [202] will invoke the Key Transformation Engine [205]; the Key transformation Engine will extract the Authentication Key values associated with the recipient's e-mail address from the Local Authentication Key Database [206], and use them to transpose the value of the key; the resulting key value is attached to the outgoing message prior to transmission.
25. A system according to claim 15, whereby users will be able to terminate correspondence with any authenticated correspondent in the Local Authentication Key Database at any time by transmitting a Key Revoke Message.
26. A system according to claim 15, whereby if said system is implemented at the network level by the user's organization, company, or Internet Service Provider, outgoing messages will also be examined by a Header Parser [207] and any new correspondents or key values will be stored in the Authentication Key Database [209].
27. A system according to claim 26 whereby if said system is not implemented at the network level, data stored in the Local Authentication Key Database [206] will be replicated in an Authentication Key Database on the client computer, and the Header Parser [102], Format Inspector [103], Authentication Key Inspector [104] and Authentication Key Database [106]
will be created as services to run locally on the client computer.
will be created as services to run locally on the client computer.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002450488A CA2450488C (en) | 2003-11-13 | 2003-11-13 | System and method for eliminating unsolicited e-mail |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002450488A CA2450488C (en) | 2003-11-13 | 2003-11-13 | System and method for eliminating unsolicited e-mail |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2450488A1 CA2450488A1 (en) | 2005-05-13 |
| CA2450488C true CA2450488C (en) | 2009-08-04 |
Family
ID=34558397
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002450488A Expired - Fee Related CA2450488C (en) | 2003-11-13 | 2003-11-13 | System and method for eliminating unsolicited e-mail |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2450488C (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060112271A1 (en) * | 2004-11-22 | 2006-05-25 | Murata Kikai Kabushiki Kaisha | Cipher mail server device |
-
2003
- 2003-11-13 CA CA002450488A patent/CA2450488C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2450488A1 (en) | 2005-05-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7917757B2 (en) | Method and system for authentication of electronic communications | |
| US6615348B1 (en) | Method and apparatus for an adapted digital signature | |
| US8819410B2 (en) | Private electronic information exchange | |
| KR101133829B1 (en) | Verifying authenticity of webpages | |
| US8073912B2 (en) | Sender authentication for difficult to classify email | |
| US8005899B2 (en) | System and method for detecting and filtering unsolicited and undesired electronic messages | |
| US8347095B2 (en) | System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison | |
| US20080086532A1 (en) | Method for the Verification of Electronic Message Delivery and for the Collection of Data Related to Electronic Messages Sent with False Origination Addresses | |
| US20040054741A1 (en) | System and method for automatically limiting unwanted and/or unsolicited communication through verification | |
| US20040236838A1 (en) | Method and code for authenticating electronic messages | |
| US20130067004A1 (en) | Electronic Message System with Federation of Trusted Senders | |
| US20110314283A1 (en) | E-mail certification service | |
| US20050132060A1 (en) | Systems and methods for preventing spam and denial of service attacks in messaging, packet multimedia, and other networks | |
| US20060143136A1 (en) | Trusted electronic messaging system | |
| CA2677525A1 (en) | Method for predelivery verification of an intended recipient of an electronic message and dynamic generation of message content upon verification | |
| US20050210272A1 (en) | Method and apparatus for regulating unsolicited electronic mail | |
| Hess et al. | Content-triggered trust negotiation | |
| Herzberg | DNS-based email sender authentication mechanisms: A critical review | |
| CA2660288C (en) | System and method for preventing delivery of unsolicited and undesired electronic messages by key generation and comparison | |
| CA2450488C (en) | System and method for eliminating unsolicited e-mail | |
| CA2340384A1 (en) | Apparatus and method for an authenticated electronic userid | |
| JP2009505216A (en) | System and method for detecting and filtering unsolicited electronic messages | |
| Patanwadia et al. | Email Based Trust Management System | |
| Virag et al. | Transmission of Unsolicited E-mails with Hidden Sender Identity | |
| Heimbigner | Fine Grain Spam Suppression Using Reachback |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20141113 |