WO2004054188A1

WO2004054188A1 - Electronic mail system

Info

Publication number: WO2004054188A1
Application number: PCT/GB2003/005363
Authority: WO
Inventors: Tim Dean-Smith
Original assignee: Mk Secure Solutions Ltd
Priority date: 2002-12-10
Filing date: 2003-12-09
Publication date: 2004-06-24
Also published as: GB2405234B; GB0328519D0; GB2405234A; AU2003288445A1

Abstract

A message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps: checking for a first identification code (made available to selected individuals) sent in or in association with a message, the first identification code being particular to or associated with the intended recipient, checking for a second identification code (made publicly available) sent in or in association with a message, the second identification code being particular to or associated with the intended recipient, checking the originator or sender of the message with an permitted senders list, designating the message as allowed if the first identification code is associated with the message, or if the second identification code is associated with the message, or if the sender is present on the permitted senders list, and designating the message as disallowed is it has not been so designated as allowed.

Description

Electronic Mail System

The present invention relates to an electronic mail system, and, more particularly, though not exclusively, to the security and convenience of systems whereby email is transmitted over the Internet or World Wide Web.

Electronic mail, commonly referred to as email, allows an Internet or

World Wide Web user to send a message to one or more other Internet or World Wide Web users. The message may contain various types of content, including text, pictorial information, video and/or audio files, executable computer code, and other types of material as well.

Commercial material can be sent via email at little cost, and this has encouraged some individuals and companies to send unsolicited promotional emails to every email address that they can collect or generate. Such email addresses are obtained from various sources, for example, Usenet groups where participants' emails are visible, and on-line subscription forms where subscribers are required to enter their email addresses. Inevitably, such indiscriminate mass-mailing results in Internet and World Wide Web users receiving emails that are irrelevant or of no interest. Such unsolicited mass mailing is known as "spamming". Some reports (e.g.. June 2001 US Gallop Poll Study) estimate the amount of spam as high as 20% of all email. Spamming raises many economical and social issues. One economic issue is the sheer volume of spam and the storage capacity required to handle spam. Spam has also been linked to illegal activities (many spam email messages are for "get rich quick" and other dubious or fraudulent schemes, illegal gambling, and pornography), as well as other socially objectionable content. A known method for dealing with unwanted spam is to filter emails by looking at the identity of the sender. Each incoming email is examined, and if the sender is a known sender of spam messages, that email message is blocked. Such filtering may be carried out by a corporation or other organisation or the Internet Service Provider (ISP), or by the individual, or by both. When a user encounters a spam email, he or she may create a rule that blocks future emails from that sender; and the corporation, organisation, or ISP may operate in a similar manner.

Spam filtering techniques rely upon a particular sender of spam being recognised, and the sender of the spam being entered in a blocked senders' list so that future emails from that sender are blocked. This technique is time consuming; further, there is a delay before the spam is detected and filtering effected, during which time many spams may be emailed and received by a user. In any case, the spammer can typically change his or her address very quickly and thereby evade such spam filtering techniques. More complex spam filtering techniques may be employed, such as searching for a particular part of the spam sender's address, or some other characteristic of the email (such as the number and destination of the emails) may be used. This spam filtering is more complex, may still be evaded, and may have the undesired result that legitimate email messages are blocked, which is known as a "false positive".

Accordingly, one object of the present invention is to provide a system for conveniently reducing the number of unsolicited emails that an email user receives. According to one embodiment of the present invention, there is provided a message filtering method for excluding unsolicited electronic messages, capable of comprising the steps of:

checking for a first identification code (made available to selected individuals) sent in or in association with an electronic message, the first identification code being particular to or associated with the intended recipient,

checking for a second identification code (made publicly available) sent in or in association with an electronic message, the second identification code being particular to or associated with the intended recipient,

checking the originator or sender of the electronic message with an approved sender list established by the intended recipient or other authorised representative,

and designating the electronic message as allowed if the first identification code is associated with the message, or if the second identification code is associated with the message, or if the sender is present on the approved sender list,

and designating the electronic message as disallowed if the message has not been so designated as allowed.

The message may be an electronic mail message viewable on a computer display. According to another aspect of the present invention, there is provided a computer program element capable of performing a method as herein defined.

According to another aspect of the present invention, there is provided a computer programmed to perform a method as herein defined.

According to another aspect of the present invention, there is provided an electronic message filtering method for excluding unsolicited messages, capable of comprising the steps:

designating the electronic message as allowed if the first identification code is associated with the message,

and designating the message as disallowed otherwise.

checking for a second identification code (made publicly available) sent in or in association with an electronic message, the second identification code being particular to or associated with the intended recipient, designating the electronic message as allowed if the second identification code is associated with the message,

and otherwise designating the message as disallowed.

checking the originator or sender of the electronic message with an approved sender list,

designating the electronic message as allowed if the originator or sender is present on the approved sender list,

and otherwise designating the message as disallowed.

According to another aspect of the present invention, there is provided an electronic message filtering method, comprising the capability of performing the steps of checking the message for a third identification code that is generated or defined by an algorithm using a characteristic of the sender,

designating the electronic message as allowed if the third identification code is so generated,

and designating the message as disallowed if it has not been designated as allowed. According to another aspect of the present invention, there is provided an email protocol and an email wherein an email header of an email message contains a separate field for entering one or more alphanumeric keys which are used for the purposes of confirming the validity of the email message as hereinafter defined.

The term "message" is intended to be interpreted broadly, with a particular application being email type messages which may be received and displayed using a computer, but also including telephone and fax messages and door entry system and intercom messages. The term "computer" is intended to be interpreted broadly, as the system of the present invention may advantageously be applied to desktop and laptop type computers, but also dumb terminal type computers, handheld computing devices, or other devices that incorporate a computing capability that can receive electronic messages, such as mobile phones, mobile communication systems, televisions, etc.

It should be noted that the terms "public identification key" and "private identification key" are individual codes to allow messages to be passed through the filtering system in accordance with various embodiments of the present invention, and should not be confused with the public and private keys used in an asymmetric code encryption system. Where the use of such asymmetric code public and private keys is intended, this will be clear from the context.

A message filtering system embodying the present invention will now be described, by way of example, with reference to the drawings, of which: Figure 1 is a diagrammatic representation of one embodiment of the filtering method in accordance with the present invention; and

Figure 2 is a diagrammatic representation of the connections of an embodiment of the filtering system of the present invention.

When a user provides his or her email address to a potential email sender whom he or she trusts, the user also provides a private identification key. Preferably, the private identification key is a user-selected code or reference (typically an alphanumeric string) that is unlikely to be guessed or easily randomly generated.

In addition, the user may distribute a public identification key to other potential email senders whom he or she may not trust to the same degree, but from whom the user wants to be able to receive electronic messages. In particular, the user may distribute this public identification key on the Internet or World Wide Web, for example, on a promotional Web site, or in Usenet discussion groups, or the like. If the public identification key is displayed on a Web site, it is preferably displayed in a form that is difficult to automatically capture, for example, by displaying the public identification key as an image, rather than using ASCII type text characters. An alternative method is to require a password displayed as an image to be entered by the potential email sender, the public identification key being displayed if the correct password is entered. In either event, the potential email sender may be required to register at the Web site or with the Usenet discussion group by providing at least an email address and perhaps a password before being permitted to have access to the public identification key. Alternatively, the public identification key may be sent via email or some other means, for example, by facsimile or postal mail, to a potential email sender who requests the public identification key, thus providing a further level of identification of the potential email sender.

Furthermore, the user may keep and maintain a list of permitted actual or potential email senders from whom he or she wants to receive email in any circumstances. However, the system can operate advantageously if a permitted email sender list is not present or employed.

Referring to the drawings and in particular to Figure 1, to receive emails, a user employs his email application or "email client" (typically installed in a client computer) to access 10 the POP3 or other mail server of the user's email server. The email client then submits the user's account name and password in a conventional manner, and requests the email files for the user's account.

When an email sender to whom the user has provided his private identification key sends an email, the sender includes the private identification key in the email. The private identification key may be included in the subject line of the email, or may appear in a particular location in the email header, or anywhere else in the email, including being embedded in the user's email address itself.

When the user has permitted access to a public identification key and an email sender that has found the intended recipient's public identification key sends an email, the sender includes the public identification key in the email in a similar manner to the inclusion of the private identification key, as described above. An email sender may also choose to include his or her own sender identifier key in the email in a similar manner to the inclusion of the private identification key described above. This enables the email recipient to include the email sender's private identification key in a reply to the email sender so that the reply is not blocked.

The email client examines 12, 14, 30, each email message, checking 16 for the presence of the private identification key in the specified location of the email. If the private identification key is present and correct, the email is marked as accepted 20.

If the private identification key is either absent or incorrect, the email client then checks 18 for the public identification key in the specified location of the email. Again, if this is found to be present and correct, the email is marked as accepted 20. If neither the private nor public identification key is present or correct, the email client then cross-checks 22 the sender against the permitted sender list. If the sender of the email is present on the permitted sender list, the email is marked as accepted. The email client then checks to see if there is a sender identifier key included in the email, and, if so, checks that this sender identifier key matches with the identity claimed by the sender. The email client can be configured so that the client marks as accepted any email which passes one or more of the above tests, in any desired order or combination.

The email client then marks, downloads, or stores 20 those emails marked as accepted. The emails which are not so marked may be downloaded to a separate folder or folders in the email client for the user to check if he or she wishes, or may be deleted 24 from the POP3 server without being read or downloaded by the user. Such excluded messages may be returned to the email sender, possibly together with information regarding seeking a public identification key (such a response can be generated for any of the testing regimes, for example, where the public and private identification keys are used to filter the email, but no permitted sender list is maintained). After the accepted emails have been downloaded, these too may be deleted 24 from the POP3 server. Typically, each email is checked sequentially until the entire email message account has been examined.

When performing the private identification key, public identification key, permitted sender list, and sender identifier key checks, it will be realised that the checks may be carried out in any order, and that each email message may be subjected to some or all the checks, or each check may be performed on all of the emails.

It will be observed that various categories of sender whom the user trusts are permitted to send email (using the private identification key, or being on the permitted sender list) that will not be excluded by the email client. The user also allows senders whom he does not necessarily trust to send him or her emails, using the public identification key. In this way, senders as yet unknown to the user can contact him or her. This is, of course, important where the user is soliciting potential customers, etc. The public identification key is kept relatively safe from spammers by being presented in a non-machine identifiable or readable form, or, indeed, being selectively delivered via email or other means to further assist in identifying the sender of emails.

It may be, however, that a sender of spam finds the public identification key, either by actually accessing the Web site of the user, or perhaps the user is asked to submit an email address to what appears to be a legitimate Web site which then passes the email details to a spammer. In such cases, the user or the provider of a public identification key service can easily change the public identification key. It will be seen that senders using the private identification key or included on the permitted sender list are unaffected. Senders using an old public identification key may be requested to check the current public identification key. If desired, public identification keys may be changed regularly, with overlapping windows in which each public identification key will be accepted by the email client. Furthermore, since it is not critical that the public identification key is kept secure, a searchable database may be maintained of the user's public identification keys, preferably in some non-machine readable form. Even if the entire public identification key database were to fall into the hands of a sender of spam, it will be seen that all the public identification keys may be changed relatively easily, rendering the old ones useless.

Rather than simply marking each email as accepted, the emails may be segregated according to which type of test they passed, and downloaded to "private", "public", "permitted sender" or "identified sender" email folders.

The user may compile and add to the permitted sender list on a person-by-person basis. Alternatively, the user may use an application to load names to his permitted sender list from some existing file of contacts and email addresses. For example, addresses of senders in the email client's address book may be copied onto the permitted senders list. The user may then check through these senders and select and edit those that he wishes to be included in the permitted senders list. When the email client determines the presence of a public or private identification key and accepts the email, but the sender is not on the permitted senders list, the email client may modify the email (or provide a separate menu), prompting the user to add the sender to the permitted senders list (or, alternatively, retain public identification key only status or even block email from the sender). The user may also cause senders of permitted mail to be automatically sent to his or her permitted senders list. In such a case, the email client may inform the user, whilst presenting him or her with the alternative options of alternatively retaining public identification key only status or even blocking email from that sender, again through modifying the email message or providing a separate menu.

In the case of a user deciding to allow senders using his or her public identification key successfully to be automatically entered on his or her permitted senders list, an option may be provided whereby the user may select a level of certainty or burden of proof that the email address is under the sender's actual control. Upon demonstrating that the address is properly controlled, the sender is accepted on the permitted senders list. Of course, such automatically selected senders may be entered upon a different list.

Spam emails and virus-carrying emails may "spoof or fake the source address of the email. The email client may therefore include utilities to authenticate that the declared source address is the genuine origin of the email, for example, by checking the email header information, eliciting feedback from that address, etc. Such measures are particularly appropriate for checking emails that are permitted only through the sender being on the permitted senders list. Again, the user may set a level of certainty that he or she is satisfied with to permit acceptance of emails. In the embodiments described above, the filtering function is performed by the email client on the user's computer, as is the application for compiling the user's permitted senders list. It may equally be that the filtering function is performed by a Web-site-based email server, where emails are written and sent, and received and read, on a Web page. Also, the filtering function described may equally be performed by a separate application, especially an Internet-based application provided by an ISP or other supplier for use with a user's computer-based email client.

Accordingly, referring now to Figure 2, a user may direct his computer 42 to connect to such an Internet-based filtering server 40, and requests his or her emails for a particular POP3 account 46 in the typical way, except that the request is made to or via the filtering server 40 rather than to a POP3 account's email server 45 directly. The filtering server 40 connects to the particular email server 45 and requests the received emails in the POP3 mailbox 46 on the user's behalf. The filtering server 40 then filters the emails, checking for the presence of the correct keys and the permitted sender list, using the methods in the manner previously described.

Email that is found to be permitted is sent from the filtering server 40 to the user's computer 42, whilst the blocked email is stored in a rejected email database 35 specific to the user's email account. The user may thereafter access this database if he or she wishes to personally examine the rejected emails.

The filtering server 40 may, if the user has chosen such functionality, automatically generate and send a message to the sender of the rejected email. This email may advantageously notify the user of the reason the email has been rejected and what steps can be taken to override the filtering process, and may, if desired, contain the public identification key (in non-machine-readable form). The filtering server 40 may either send this email directly to the POP3 mailbox 56 of the original sender's email server, or may send it to the user's SMTP server 47 to be sent. If the user has chosen to have the senders of blocked messages sent automatic replies, the user may also set a delay period, so that the user allows himself or herself this period in which to check the rejected emails without an automatic reply being sent, but if the user decides not to check the emails, an automatic message will nevertheless be sent after the delay period has elapsed.

The filtering application has access to the permitted senders list to perform all the tests on the received emails. In the case of the filtering server 40 described above, the server itself maintains a permitted senders database 50 for each user (or even each of the user's email accounts). The application for compiling the permitted senders list may, however, be separate from the filtering application, and again may be either installed or installable on the user's computer.

There may be multiple permitted senders lists of different categories, allowing access to different mailboxes or email accounts of the user of the system in accordance with the present invention, depending upon the email account, the user's preferences, and the type of sender.

Occasionally, a sender has a legitimate wish to send several identical emails to different recipients. The filtering server 40 may include a trusted sender database 51, comprising individuals or organisations that the provider of the filtering server 40 has vetted in some manner and deemed trusted. During the filtering process, the trusted senders database is checked, particularly in relation to otherwise impermissible emails. An email originating from a trusted sender can be allowed to pass to the user. In this way, trusted senders can send unsolicited emails to the filtering server's users, and the filtering server 40 can generate revenue for providing the trusted senders this service, which in turn can subsidise the service provided to the email user recipient. In order not to defeat the object of providing an email filtering method, the activities of the trusted senders may be monitored to assure that users are not inconvenienced; for example, the trusted sender could be issued a single-use trusted sender key which must be included in the emails he or she sends to the users of the system, the trusted sender database including this trusted sender key and associated usage criteria so that the filtering server 40 can allow him or her to send a single email to each user.

The filtering server 40 may include the other functions of the email client previously discussed, such as including senders in the permitted senders database 50, or providing a separate permitted senders database 53.

Rather than having the filtering server 40 interposed between the user and the email server, a filtering server may be provided for a user's ISP or email server to link to and consult after the user connects directly to the

ISP or email server. Of course, the filtering methods may be incorporated directly into a conventional remote email server.

The private and public identification keys may be chosen by the intended user recipient, or, alternatively, may be randomly generated, or may be generated by an algorithmic process, whereby the private and/or public identification key generated is related by an algorithm or formula to the address or secret key or code of the intended user recipient, or to the address of the sender or secret key or code of the sender, or to any combination of any two or more of these.

Similarly, the sender identifier key may be chosen by the sender, or, alternatively, may be randomly generated, or may be generated by an algorithmic process, whereby the sender identifier key generated is related by an algorithm or formula to the address or secret key or code of the intended user recipient, or to the address of the sender or secret key or code of the sender, or to any combination of any two or more of these.

Any of the above keys may also be further secured by using a combination of keys or algorithms or other encryption methods, whereby the sender has a secret key or algorithm which is specific to the sender, and that key or algorithm allows only that sender to correctly receive and/or decrypt and/or generate the key(s) which are provided by or sent to the sender, for inclusion in the email to the intended user recipient.

A further method of securing the system is to allow the user to choose an option whereby when a potential sender of an email requests the user's public identification key, the system sends an email to the user of the system asking whether he or she wants a public identification key to be issued to the intended sender, or if he or she wants to add the email address of the intended sender to his or her permitted senders list.

The sender of spam will therefore be much less likely to send unsolicited emails to an intended recipient where the recipient is a user of the described system, since the sender will have no access to the user's private identification key, will not be present on the permitted senders list, and it would be time consuming and unworthwhile to keep finding the public identification key. The sender will also be unwilling or unable to provide a valid sender identifier key, or if he or she does, his or her emails are blocked by one of the other tests, or, indeed, the sender may be added to a list of senders from whom the intended recipient blocks incoming emails.

In accordance with another embodiment of the present invention, as an additional component of the filtering system, the sender preferably has a public and a private signature encryption key (the private signature encryption key being known only to him or her), and the recipient has a public and a private message encryption key (the private message encryption key being known only to him or her). The public and private encryption keys are preferably of the well-known asymmetric code type, such that data may be encrypted using one key, and decrypted using the other corresponding key. However, the application of such codes in the filtering method of the present invention is different from that of conventional encryption of email message data in that they apply only or mainly to the identification key accompanying the email, rather than to the main body of the message itself. The public and a private signature encryption keys of the sender may be specific to the sender individually, or otherwise be specific to the domain or sub-domain or IP address of the sender or the sender's mail server.

Considered in more detail, when the sender sends an email, the following process takes place, either on the PC or client of the sender, or on the mail or message server of the sender. A random ID is generated (hereinafter referred to as the email ID key), and the email ID key is hashed (i.e.. the email ID key is reduced to a constant length string using a hash algorithm). This email ID key can be entirely random, or may fall within certain parameters agreed between the operator of the system and the sender. By this method, the email ID key can provide access to a greater or fewer number of email addresses which are within the sphere of operation of the system.

The sender then encrypts the hashed email ID key using the sender's private signature encryption key, and encrypts the original randomly generated email ID key using the recipient's public message encryption key. The encrypted email ID key and encrypted hashed email ID key are then included in the header fields of the email to be sent.

When the email is received, the filtering system decrypts the hashed email ID key using the sender's public signature key. If the data that is decrypted does not conform to the hash data format, the email can be rejected as unauthenticated. If it is a hash, the email ID key is decrypted using the recipient's private message key, hashed using the same hash algorithm as that used by the sender, and the two hashed email ID keys are compared. If the hashed email ID keys are identical, the email is fully authenticated as coming from the sender.

The email ID key can be generated by a free-standing application on the sender's computer. As described below, the email ID key may also be generated by the filtering server 40, or by the sender's ISP. Furthermore, the hashing of the email ID key, and the encryption of the email ID key and hashed email ID key, are ideally carried out automatically by the sender's ISP. The recipient's public message key may be stored by the sender's ISP, or the sender's ISP may request the recipient's public message key from the recipient's ISP. Also, the recipient's ISP can then automatically carry out the functions of decrypting the email ID key and hashed email ID key, and comparing them to authenticate the email. Again, the recipient's ISP can either store the sender's public signature key, or request that key from the sender's ISP. The recipient's and sender's ISPs, of course, only send out the public keys, and do not divulge the private keys. If only the sender's ISP participates in the method, the filtering server 40 can fulfil the function described here for the recipient's ISP; also the filtering server can fulfil the function described for the sender's ISP. Indeed, the filtering server 40 may fulfil both roles, in which case obtaining the necessary public keys can be easily ensured and need not necessarily involve the server. Each random email ID key may be generated by the filtering server 40 and sent to the sender (or his or her ISP, or stored in an appropriate filtering server database, depending upon the particular implementation), or the sender may generate the email ID key and, if the hashing and encryption are automatically carried out by the ISP or on the filtering server, sent unencrypted to the appropriate server.

In this manner, the recipient is assured that the email has been sent by the indicated sender, and the apparent origin of the message has not been "spoofed". This ensures that someone who may not have contacted the intended recipient before can send an email to the recipient provided that he or she uses his or her true email address, but by automatically checking this, the filtering system can reject emails that do not come from verified email addresses and so block spam and other messages having "spoofed" addresses. This check of the email ID key can advantageously be used by senders who may have a legitimate interest in sending out a large number of emails to a group of accounts.

The security of the system may be further enhanced by allowing the sender of the email to hash part or all of the main body of the email, and to also include that hash in the message in addition to the email ID key. This hash of the main body of the email can be encrypted using the public part of the recipient's message encryption key. The recipient can decrypt this hash, and then compare it to the hash of the message which he or she generates. If the two hashes match, the message has not been tampered with or substituted since leaving the sender.

It may be that the intended recipient does not subscribe to the filtering system at the time the sender wishes to send an email, but the sender would like the recipient to be able to authenticate the email. The sender may encrypt the hashed email ID key using the sender's private signature key, and encrypt the original email ID key using a newly issued, or a filtering system default, public message encryption key. The recipient may obtain the newly issued or filtering system default public and private encryption keys, together with the sender's public encryption key, at a later date on registration with the filtering server 40, and so authenticate the sender of the email post-event. In the same way, the recipient may access the random key sent by a different protocol after having received the message in order to authenticate it.

In another embodiment of the invention, when a sender wishes to send for the first time an email capable of authentication, his email server contacts an a Key Generating server. The Key Generating server issues a public and private signature ID key pair to the sender's email server, and also sends a copy to the Sender Register server. The sender's email server than encrypts the sender's email ID as previously described. When the email is delivered to the intended recipient, he or she is invited to participate in the filtering and authentication system if he or she is not presently participating. The recipient then obtains or confirms the public signature ID key of the purported sender with the Sender Register server, and then decrypts the email ID using the public signature ID key to confirm the message has not been tampered with. It will be realised that the confirmation and authentication steps may be carried out by the recipient following a URL included in the email, or carried out automatically, either by the recipient's PC-based, or his or her email server. It will also be realised that a different public and private signature ID key pair may be issued for each email a user sends.

If an email sender is alleged to be sending spam, his or her behaviour is impartially adjudicated upon by the Sender Register server organisation, which is ideally independent of the Key Generating server.

The Sender Register may also exclude, or flag as suspect, email servers that operate laxly, for example by allowing their users to send emails without confirming the confirming he message source, allowing that email server's users to "spoof email messages.

As well as excluding certain individuals and email servers, the Sender Register may rank or attribute a rating to individual email senders and to email servers corresponding to their conduct or good practice. A recipient of an email may then be confident in the veracity of messages authenticated as coming from high-ranking or well-rated individual email senders and/or email servers.

In another alternative method in accordance with the present invention, server level sender authentication may be provided. When an email is sent by a sender whose email server incorporates the filtering system, the filtering server resolves the target email server and determines whether it has a key pair for that server, that is, if it establishes a relationship by sending its server ID and password, which the target server checks against a central database. If this test is passed, a relationship key pair is issued that is valid for a definable period of time (for example, a default period of one hour). Once the sending server has this relationship key, it creates a 15 -character random string, for example, and then hashes this using the relationship key. This data is then sent to the target server along with "from" and "to" addresses. The data is also added as a header to the outbound email which is then sent. When the target server receives an email, it unhashes the header data and compares it to the data it has stored. If a match is found, it verifies the email. Otherwise, it marks the email as unverified. If a sending server sends to a target server that is not enabled to provide authentication, the sending server creates a relationship key itself and uses this to add a URL to the bottom of the email (such a URL could of course be added by default even where the target server is enabled). When the recipient receives the email, he or she may click on the URL and go to an online process that compares the header data and the provided target email address with stored data. If a match is found, the recipient is displayed a positive verification. If not, he or she is displayed a negative verification.

In another method in accordance with the present invention, email integrity is provided via an encrypted message hash. The sender may choose to use an algorithm to produce a hash based on the content of the email itself. This Message Hash may then be used in place of, or in combination with, the "normal" email ID key described earlier.

Considered in more detail, as described above, the email sender has a public and a private signature encryption key (the private signature encryption key being known only to him or her), and the email recipient has a public and a private message encryption key (the private message encryption key being known only to him or her). The public and private encryption keys are preferably of the known asymmetric code type, such that data may be encrypted using one key, and decrypted using the other corresponding key.

When the sender sends an email, the filtering system uses a Message Hash Hashing algorithm to hash the Message Hash, to create a Hashed Message Hash. The Hashed Message Hash is then encrypted using the sender's private signature encryption key. The original Message Hash is then encrypted using the recipient's public message encryption key. The encrypted Hashed Message Hash and Message Hash are then included in the header fields of the email to be sent.

When the email is received, the filtering system decrypts the encrypted Hashed Message Hash and Message Hash. The filtering system applies the Message Hash Hashing algorithm to the Message Hash. If this produces a Hashed Message Hash identical to the decrypted Message Hash, then neither the encrypted Hashed Message Hash nor the Message Hash has been tampered with.

The filtering system then uses the Message Hashing algorithm to produce a Message Hash from the message itself. If this Message Hash is identical to the now-decrypted Message Hash sent in the headers by the sender, then the message has not been tampered with en route.

In an alternative method in accordance with the present invention, the sender may generate a random ID key (the filtering server 40 generates a number for the sender to use). This ID key is then embedded into the header of an email before the email is sent to the recipient, and the ID key is also sent to the recipient using a different protocol, such as file transfer protocol (FTP). The recipient (or his computer or the filtering server 40) then checks each incoming email for the presence of the number corresponding to the one sent by FTP (or other protocol), in which case the origin of the email is authenticated via independent ID key transmission.

Users of the system described above may choose to have multiple private and/or public identification keys, which allow access by different groups of individuals, and the system may be set up with different sets of tests for each group, or, indeed, may allow access to different email addresses of a user of the system in the case where he or she has more than one email address.

It will be realised that although the description of specific embodiments refer to POP3 and SMTP servers, various means of receiving and transmitting electronic messages for filtering according to the various embodiments of the present invention can be envisaged.

The system is applicable to a wide range of messaging. For example, the above processes and checks may be applied to other forms of electronic communication, such as the Short Message Service system currently popular with mobile phone users.

The principles of the present invention disclosed herein may also be used in combination with conventional telephony. For example, a telephone caller may be required to key in a public or private identification key in order to proceed to activate or access the telephone or facsimile machine of the intended recipient. The public identification key may easily be advertised in printed publications or distributed by other means, such as the Internet or World Wide Web, and may, as previously described, be changed when required. In such a case, there will not typically be a mail server or mailbox as such, but the checking function may be performed at a telephone exchange, or by the intended recipient's machine. When dialling a telephone number, the telephone caller's number is often included in the dialling signal; a list of permitted callers may then be compiled and used in a similar way to the permitted senders list described above.

It will also be realised that in all the examples given, a subset of the testing regime, or even a single type of test or check, may be employed in a system to some advantage, without performing every described test or check.

In addition to the features of the present invention as described above, for the electronic mailing application, a filtering, sorting, or ranking process may be incorporated into the system. By this method, the email may be sorted or categorised as to whether it is more or less likely to be genuine email meant for the consumer or spam or, indeed, some other category or type of communication. The sorting can either take place before the series of tests described above, at some midpoint in the process (or as part of the tests or checks), or after the series of tests or checks. The sorting method used may be a traditional Bayesian filter or may be a filter which self improves on a neural network basis as it performs more filtering processes (and/or learning from the user's reaction/ranking of the emails), or could work on some other rule-based series of tests or checks.

If the sorting is carried out initially, or at an intermediate stage, some categories may bypass the previously outlined filtering tests performed by the filtering server 40, or the like (for example, emails having high probability of being genuine which could be passed directly to the user, and the emails which are almost certainly spam which could be discarded without further testing). Equally, the sorting may be used at a late or final stage only on certain categories of email allowed or disallowed by the previously outlined tests or checks.

Again, it will also be realised that in the examples given that a subset of either the testing regime described first above, or a subset of the additional sorting or filtering method, or any combination of such subsets, may be employed in a system to some advantage, without performing every described test.

Claims

1. A message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps:

checking for a first identification code (made available to selected individuals) sent in or in association with a message, the first identification code being particular to or associated with the intended recipient,

checking for a second identification code (made publicly available) sent in or in association with a message, the second identification code being particular to or associated with the intended recipient,

checking the originator or sender of the message with an permitted senders list,

designating the message as allowed if the first identification code is associated with the message, or if the second identification code is associated with the message, or if the sender is present on the permitted senders list,

and designating the message as disallowed is it has not been so designated as allowed.

2. A method according to claim 1 wherein the message is an electronic message viewable on a display comprising a computer.

3. A method according to claim 1 wherein the message is a telephone message viewable on a display comprising a computer.

4. A method according to claim 1 wherein the first and or second identification codes are generated or defined by an algorithm using a characteristic of the intended recipient.

5. A method according to claim 1, further including the step of checking the message for a third identification code that is generated or defined by an algorithm using the a characteristic of the sender.

6. A method according to any of claims 1 to 5 wherein the allowed messages are transferred to a user's computer, whilst the disallowed messages are not so transferred.

7. A method according to any of claims 1 to 6 wherein the disallowed messages are transferred to a separate folder where they may be checked by the recipient.

8. A method according to any of claims 1 to 7 wherein the approved sender list is created by extracting data from an existing file present on a user's computer.

9. A method according to any previous claim wherein one of the identification codes is publicly available in a form that cannot be readily automatically captured.

10. A method according to any previous claim wherein one of the identification codes is publicly available and is sent to a requesting sender via email or some other communications means, ensuring that it cannot easily be captured by a person who does not reveal his identity.

11. An electronic message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps:

and designating the message as disallowed otherwise.

12. An electronic message filtering method according to claim 11 including the capability to perform the step:

designating the electronic message as allowed if the second identification code is associated with the message,

13. An electronic message filtering method according to either claim 11 or 12, including the capability of performing the steps:

checking the originator or sender of the message with a permitted senders list,

designating the message as allowed if the sender is present on the permitted senders list,

and designating the message as disallowed is it has not been designated as allowed.

14. An electronic message filtering method according any of claims 11 to 13, including the capability of performing the steps:

checking the message for a third identification code that is generated or defined by an algorithm using a characteristic of the sender,

designating the message as allowed if the third identification code is so generated,

and designating the message as disallowed if it has not been designated as allowed.

15. An electronic message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps: checking for a second identification code (made publicly available) sent in or in association with an electronic message, the second identification code being particular to or associated with the intended recipient,

and otherwise designating the message as disallowed.

16. An electronic message filtering method according to claim 15, including the capability of performing the steps:

checking the originator or sender of the message with a permitted senders list,

designating the electronic message as allowed if the sender is present on the permitted senders list,

17. An electronic message filtering method according to either claim 15 or 16, including the capability of performing the steps:

designating the message as allowed if the third identification code is so generated, and designating the message as disallowed is it has not been designated as allowed.

18. An electronic message filtering method for excluding unsolicited or unwanted messages, capable of comprising the step:

checking the originator or sender of the message with a permitted senders list,

and designating the electronic message as allowed if the sender is present on the permitted senders list,

and otherwise designating the message as disallowed.

19. An electronic message filtering method according to claim 18, including the capability of performing the steps:

20. An electronic message filtering method, comprising the capability of performing the step of checking the message for an identification code that is generated or defined by an algorithm using a characteristic of the sender, and designating the message as allowed if the identification code is so generated, and designating the message as disallowed if it has not been designated as allowed.

21. An electronic message filtering method according to any previous claim, including the steps:

checking that an encrypted first identification code may be decrypted using the public key of a public-private asymmetric code pair,

and designating the electronic message as allowed if the decrypted first identification code is associated with the message,

and designating the message as disallowed otherwise.

22. An electronic message filtering method according to any previous claim, including the step of sorting the messages as to their likelihood of being unsolicited.

23. An electronic message filtering method according to claim 22 wherein the messages are sorted before being subjected to the filtering method.

24. An electronic message filtering method according to either claim 22 or 23 wherein the messages are sorted before being subjected to the message filtering method.

25. An electronic message filtering method according to either claim 22 or 23 wherein the messages are sorted after being subjected to the message filtering method.

26. An electronic message filtering method according to either claim 24 or 25 wherein some of the sorted messages are disallowed prior to being subjected to the message filtering method.

27. An electronic message filtering method according to either claim 22 or 23 wherein the messages are sorted after being subjected to the message filtering method.

28. An electronic message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps:

designating the electronic message as allowed if the decrypted first identification code is associated with the message,

and designating the message as disallowed otherwise.

29. An email protocol wherein an email header of an email message contains a separate field for the entering of one or more alphanumeric keys which are used for the purposes of confirming the validity of the email message according to any previous claim.

30. An email according to claim 29.

31. A message filtering method for excluding unsolicited or unwanted messages, capable of comprising the steps:

checking the originator or sender of the message with a permitted senders list,

and designating the electronic message as allowed if the first identification code is associated with the message, or if the second identification code is associated with the message, or if the sender is present on the permitted senders list,

32. A computer program element capable of performing a method according to any previous claim.

33. A computer programmed to perform a method according to any previous claim.

34. A method and system as herein described an illustrated.

35. Any novel and inventive feature or combination of features specifically disclosed herein within the meaning of Article 4H of the International Convention (Paris Convention).