Abstract:
A method and system are disclosed which regulate the electronic mail received by a subscriber or user by forcing the sender to pay a small amount for sending e-mail, making it uneconomic to send very large volumes of spam indiscriminately. The resulting permit or stamp can be reused by the receiver. A method and system for managing the response to unstamped e-mail is also disclosed.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    This invention relates to the efficient delivery of electronic mail (e-mail), between two legitimately corresponding parties, while preventing intrusion from unsolicited bulk e-mail or ‘spam’. In particular, it relates to a process of reusable permits or ‘stamps’ which can be attached to legitimate e-mail but which a bulk sender (‘spammer’) would find uneconomic to purchase. The invention also relates to a process of centralised management of response to unstamped e-mail. 
         [0003]    As e-mail, for example of the kind using RFC2821 and RFC2822 protocols has become a major communications technology, so has the problem of ‘junk mail’ or ‘spam’ e-mail. Users of e-mail are faced with very large quantities of advertising e-mail from parties unknown to them, sent indiscriminately. Existing ‘spam filtering’ services estimate that globally between 50% and 70% of all e-mail sent is spam, and individuals who have a significant ‘Internet presence’ and hence are easily targeted may find that up to 99% of their e-mail received is spam. 
         [0004]    Alongside the waste of network and computer resources in transmitting and storing such a huge volume of unwanted e-mail, the cost of dealing with spam is felt most strongly by recipients, who have to sort through large quantities of unwanted, irrelevant e-mails to find the few that do concern them. As well as the time and effort required to do this, there is a significant risk of missing a relevant e-mail in amongst the ‘noise’. E-mail as a whole thereby becomes a less reliable and useful form of communication. 
         [0005]    The perfect solution to spam would prevent the delivery of e-mail from bulk senders with no connection to the recipient, while still allowing delivery of e-mail from legitimate senders, including persons as yet unknown to the recipient and even low-volume, highly targeted marketing and advertising e-mail from relevant parties. 
         [0006]    2. Related Background Art 
         [0007]    A number of solutions to the ‘spam problem’ have been proposed, and many are in current operation. Following industry convention, in the following description a ‘false positive’ is a legitimate e-mail which was wrongly blocked, and a ‘false negative’ is a spam e-mail which was wrongly delivered. The aim of spam prevention is of course to reduce both types of error to zero. 
         [0008]    The practice of sending spam is considered sufficiently harmful that various jurisdictions have brought in legislation banning or restricting it, including:
       The CAN-SPAM Act in the USA   The EU Directive on Privacy and Electronic Communications (esp Art. 13)       
 
         [0011]    While these legal measures have undoubtedly made life harder for some spammers, the global nature of the Internet has made it impossible to keep up with the more sophisticated offenders who have simply moved their operations offshore to other jurisdictions, or hide behind a cascade of forged identities. The focus has therefore moved to more technical measures. 
         [0012]    The most obvious solution to the problem of spam is to prevent the spam being sent in the first place. Suppressing spam at source has the most direct effect on the network bandwidth wastage, instead of waiting for indirect economic effects curtailing the spammer&#39;s business. 
         [0013]    The e-mail system has traditionally been very open, allowing spammers to use almost any mailserver to send out their e-mail while remaining anonymous. One of the first anti-spam efforts was therefore to close down or block ‘open mail relays’, as disclosed in U.S. Pat. No. 6,321,267. 
         [0014]    As open relays became less useful, spammers then started to use Internet Service Provider&#39;s (ISPs) servers, hiding behind transient user accounts, and using the relatively anonymous mail protocols to send their e-mail without being identified. An attempted solution to this has been the increasing use of authenticated SMTP to force senders to authenticate to their ISP&#39;s mailserver. In combination with more stringent verification of user identity on signup, this can at least be used to trace an offending spam episode back to the originator, at which point the legal sanctions described above may be applied. 
         [0015]    Another alternative for spammers is to operate their own mailservers connected directly to the Internet, which connect directly to destination mailservers for delivery of e-mail. This avoids any attempt to control the spam at source, but some receiving mailservers implement a check against a ‘Black-list’ which indicates whether a sending mailserver is suspected of being a conduit for spam. This process unfortunately tends to cause a large number of false positives. 
         [0016]    Rather than simply blocking e-mail from suspected spammers, another solution is to deliberately create friction in the mail-sending process by building ‘broken’ e-mail receiving servers which slow down the sending mailservers by responding very slowly—an idea known as a ‘Tarpit’. This works particularly well if the Tarpit servers handle e-mail for some completely fictional addresses used only to entrap spammers. However, such techniques can fairly easily be worked around by a spammer who doesn&#39;t really care if any individual e-mail is delivered, and can simply cancel any delivery that takes too long. 
         [0017]    An alternate way of measuring the ‘badness’ of an individual e-mail sender is to measure the volume of e-mail they send—this being the major problem with spam in the first place. In theory, this could be done at the network edge where they connect, but does not seem to be in practice, possibly because of limitations of router processing power and storage capacity. However some large organisations are instituting their own control on this basis, using products such as TurnTide Anti-Spam Router. This measures the volume of e-mail coming from a particular network address, and limits it to a small number per hour. This stops major spam attacks from a single network address, but does not prevent more distributed ‘stealth’ tactics. 
         [0018]    A better, longer-term approach is to require stronger authentication of the e-mail exchange process itself, to at least prevent the forgery of return addresses which almost universally goes hand-in-hand with spam, and which prevents the satisfactory operation of other techniques such as ‘White-listing’ (discussed below). A number of proposals have been made under the general heading ‘Lightweight MTA Authentication Protocol’, plus some specific ones such as Yahoo&#39;s DomainKeys. Stronger versions of these proposals, which require cryptographic software at each end and strict proof of identity, have existed for some time. 
         [0019]    The problem with all these proposals is that at most they can verify that the sender has the right to use the domain or identity they claim to be from. Since domains are easily obtained and largely unregulated, this has little effect on their ability to send spam. Systems requiring strict proof of identity remove much of the ease of informal communication made possible by e-mail. 
         [0020]    Overall, the search for an at-source solution has foundered on the fact that the Internet is by design an open and dynamic mesh structure, and in the limit is very difficult to prevent spammers finding a legitimate or illegitimate way into it. 
         [0021]    By far the most common attempt to control spam in common current use is filtering based on the content of individual messages. This is currently relatively successful because spam messages have traditionally been ‘of a type’, containing brief and badly-worded advertisements for a small group of products (‘performance-enhancing’ drugs, loans, make-money-fast schemes and the like). It also carries the advantage of allowing implementation of the filtering at any stage of the process, including at the receiving e-mail client. 
         [0022]    Early filtering systems such as that disclosed in U.S. Pat. No. 5,377,354 and the ‘Rules Wizard’ built into well-known e-mail client software provided basic filtering for general organisation of incoming e-mail, which could be used for spam if carefully maintained. More sophisticated rule-based systems using scoring are built into a large number of spam filter products at different layers of the network: U.S. Pat. No. 6,650,890 discloses one such product which is built in at the network level. 
         [0023]    More modern content-filtering systems, such as that disclosed in U.S. Pat. No. 6,161,130, use statistical techniques to measure the ‘probability’ of a given incoming e-mail being spam based on the presence of words compared to corpora of spam and non-spam e-mail. The most famous of these is Paul Graham&#39;s “Plan for Spam”, which uses Bayes&#39; theorem of conditional probability. UK Patent No. GB2396993 discloses the further use of ‘artificial intelligence’ techniques. 
         [0024]    A more sophisticated technique than merely looking at each message individually is to provide collaboration between e-mail filters to attempt to measure the volume of identical messages being issued. This collaborative knowledge is then used to inform a more general filtering system. One such technique is disclosed in U.S. Pat. No. 6,023,723 and U.S. Pat. No. 6,330,590. Another technique disclosed in U.S. Pat. No. 6,453,327 is to ensure than once spam has been manually reported by one user it is automatically dealt with at others. This deals more directly with the core problem of spam, the sheer volume. Rather than attempt to send the entire e-mail to a central service for checking, most of these ‘collaborative filtering’ systems generate ‘signatures’ or ‘hashcodes’ of the message which can be more easily transmitted and compared than the message text itself. In some cases, as described in U.S. Pat. No. 6,052,709, fake e-mail accounts are created specifically to ‘harvest’ spam. 
         [0025]    The problem with all content-filtering systems is simply that the spammers adapt to them. Initially they used basic techniques to ‘disguise’ key words with punctuation or mis-spellings; they then turned to insertion of large quantities of meaningless pseudo-text to ‘confuse’ the Bayesian filter techniques or collaborative checksum systems. Eventually, spammers will generate e-mails which are personalised and to all intents and purposes identical to legitimate e-mail, requiring human intelligence to sort out the difference. The inherent contradiction in all forms of filtering is that the tighter the filter the less chance there is of a false negative, but the greater of a false positive. 
         [0026]    Another common method of attempting to deal with spam has been to filter at the receiving e-mail client on the basis of the (claimed) sender of the e-mail. This may take the form of a positive ‘White-list’ of senders whose e-mail will be accepted, possibly bypassing other checks, or a negative ‘Black-list’ of senders who will be blocked. Well known e-mail client software contains basic features allowing both of these. Most filtering solutions (see above), provide a White-list feature to ensure reduction of false positives. There are also solutions which provide fully implemented support for White-lists alone. This is a draconian solution which achieves a very low false negative rate through a high level of false positive for unknown senders. 
         [0027]    Given that senders&#39; addresses are routinely forged, the use of Black-lists on individual addresses is now dying out, although use across domains, or even entire countries, can still be effective. The success of White-lists requires that spammers do not yet forge addresses which are likely to be on receivers&#39; White-lists—something that they are increasingly able to do through correlation of addresses by domain, or through illegal access to receivers&#39; address books. Both issues will be to some extent ameliorated by tighter authentication of the senders&#39; address, as discussed above. 
         [0028]    Fundamentally, however, White-listing on its own suffers from the problem that e-mail will not be accepted from unknown senders. For most users, this is an unacceptable level of detachment from the community. White-listing remains however a useful component combined with other techniques. 
         [0029]    One solution to the issue of accepting e-mail from users who are not in a White-list is to challenge the unknown sender to prove that they are at least human, and preferably someone with a reason to communicate with the recipient. U.S. Pat. No. 6,546,416 and European Patent Application No. EP1376427 disclose ‘challenge-response’ (C-R) systems which allow this. In such systems, e-mail from an unknown sender is automatically responded to with a ‘challenge’ which hopefully only a human being can answer. This may be a visual or auditory perception problem, known as a ‘Captcha’, or a simple request for a statement of why the sender needs to communicate with the recipient. 
         [0030]    A number of freely-available and commercial products and services use challenge-response. Some of such products use a central response service to handle the challenges. 
         [0031]    One major issue with challenge-response in the absence of tight sender authentication is that the challenge is sent to a forged address. In the worst case, if a large number of e-mails were sent out with the same forged sender address, this can act as a ‘distributed denial of service’ (DDos) attack on the unfortunate real person with that address. At least, it can lead to confusion and irritation on the part of wrongly challenged parties. 
         [0032]    Another issue with challenge-response is that the sender of a legitimate e-mail is not necessarily a human being. People who use the Internet regularly may receive a large number of automatically-generated e-mails including order confirmations, update notifications and mailing list traffic. In the worst case, a poorly implemented challenge-response system could end up challenging entire mailing lists each time it received an e-mail from the list. 
         [0033]    Some form of challenge-response is however an essential component of any real-world solution which can, by necessity, inter-work with existing e-mail systems. A solution to the general problems of challenge-response is one of the objects of the present invention. 
         [0034]    One of the reasons that spam on the Internet is such a massive problem where traditional physical ‘junk’ mail is only a fairly minor one is that the cost of sending an e-mail is effectively zero. Traditional physical mail of course has printing costs and delivery costs, which naturally limits the volume that can be economically sent. This in turn leads senders to target their output reasonably tightly so that in most cases the volume of ‘junk’ is manageable, and sometimes even welcome. 
         [0035]    A number of proposals have therefore been made to add the equivalent of a conventional ‘stamp’ to e-mail. Some proposals require that the e-mail delivery system itself checks for the presence of a stamp, as in the conventional postal system, but it is also more easily implemented by an e-mail client simply refusing to accept e-mail without a stamp on it. The advantage of applying a cost to sending e-mail is that it directly addresses the economics of sending spam, without significantly harming ordinary low-level senders. 
         [0036]    There are a number of distinct forms of proposed systems. Firstly, like conventional postage, the cost of the stamp is non-returnable and acts as a direct tax on e-mail. This is unlikely to be acceptable to the general public given that e-mail has traditionally been ‘free’, and hence seems to rely on sending ISPs stamping legitimate user&#39;s e-mail for them, which simply pushes the problem of identifying a legitimate user back to the ISP as before. 
         [0037]    Secondly, there are proposals involving a stamp which may be optionally redeemed by the receiver if the e-mail is unwanted or equivalently refunded to the sender if the e-mail is wanted. Hence the stamp acts as a form of ‘bond’ that the e-mail is not spam. This however relies on a complex trust model and user action if receivers are not to either routinely return the bond or routinely redeem it. 
         [0038]    Thirdly, there are proposals which always transfer value from the sender to the receiver, optionally with a social model which is supposed to encourage receivers to send the value back if the e-mail was acceptable. One such proposal is disclosed in U.S. Pat. No. 5,999,967 and International Patent Application No. WO03/054764. The difference between this and the second set of proposals lies only in whether the transfer of value happens by default for non-spam e-mail. 
         [0039]    The disadvantage of all the above proposals is that they require significant interaction with a banking payment system every time an e-mail is sent or received. In addition, it removes the anonymity of both sender and recipient of e-mail, which may be unacceptable to some users. 
         [0040]    One possible solution to this problem which has been suggested but never implemented is to use a form of anonymous electronic cash which Can simply be stored by the recipient and re-used on outgoing e-mail. However, to avoid ‘double spending’ of the same cash this still either requires a verifying transaction back to the issuing bank, or a post fact traceback of the cash to the point that it was double-spent. In the latter case, one can be reasonably sure that the spammers will ‘double-spend’ (in the millions) anyway, and then disappear. In practice, no widely-supported digital cash infrastructure exists, and use for e-mail stamps is unrealistic. 
         [0041]    It is therefore an object of the present invention to retain the core premise of a monetary cost of sending large volumes of e-mail, without requiring loss of anonymity, interaction with the banking system for conventional e-mail, or a full-scale anonymous digital cash solution. 
         [0042]    Another approach disclosed in U.S. Pat. No. 6,484,197 is for the recipient to issue their own ‘tokens’ which senders can spend in order to send e-mails to them. This works for senders who are known to the recipient, but not for those who are not. It also requires effort from the recipient to manage the release of tokens. 
         [0043]    An alternative model for the ‘cost’ of an electronic stamp has been proposed, in which the cost represents a number of machine cycles required to perform some algorithmic problem. This concept has been implemented in some prototype systems but a problem with such an approach is that it is hard to balance the number of cycles required so that it becomes uneconomic for well-funded, distributed spammers without interfering with increasing use of e-mail in the general population. 
         [0044]    Fundamentally, only a true monetary cost for bulk e-mail can sufficiently deter spammers, since it unavoidably damages their entire business model, and hence some form of electronic stamp with a cash cost is the optimum solution for the long term. To appear ‘fair’ to ordinary users, a user who sends roughly as much e-mail as they receive should not be financially affected. 
         [0045]    A workable system will also include a White-list to allow certain known people or services to send e-mail without requiring a stamp, and a challenge-response system to deal with unknown people who have not yet attached one. It is also crucial that value is not lost by sending stamps to a receiver who does not know what to do with them. 
         [0046]    In summary therefore, the optimum system of this nature as taught by the prior art has the following faults:
       1) Every exchange of e-mail requires, or can potentially require, a transfer of cash value from sender to recipient through the banking system or an analogue thereof. Given the volume of global e-mail this is an unacceptable processing load on a general purpose payments system.   2) Nothing other than a truly anonymous digital cash system can provide the requisite anonymity of both sending and receiving e-mail, and such a system does not currently exist in practical form.   3) To create a workable system without requiring a wholesale switchover of technologies requires the system to interoperate with existing e-mail clients and mailservers which will not initially understand stamps.       
 
         [0050]    There is a requirement for a workable electronic stamp system which does not depend on continuous access to a banking payments system or a digital cash infrastructure, yet provides that a user sending broadly the same number of e-mails as they receive may do so without net cost. There is also a requirement for such a system that includes a managed challenge-response system which avoids some of the pitfalls of unmanaged challenges. 
       SUMMARY OF THE INVENTION 
       [0051]    An aspect of the present invention relates to a system of Reusable Mail Permits (RMP), which are generated by a central authority or authorities, the Permit Issuing Authorities (PIA). An RMP consists of a large unique number, along with indications of value monetary or otherwise, expiry date, issuing PIA and other ‘housekeeping’ information. RMPs are anonymous. 
         [0052]    Specifically, an aspect of the present invention is able to:
   1) Provide a mechanism for generation, purchasing and attaching reusable mail permits to outgoing e-mail.   2) Verify that a valid, unique, reusable mail permit of sufficient value has been attached to incoming e-mail.   3) Allow for single re-use of received reusable mail permits by receivers on subsequent outgoing e-mail, while preventing fraud through multiple use of the same reusable mail permit, without requiring a full-scale electronic banking or digital cash system.   4) Automatically return the reusable mail permit to certain favoured senders.   5) Optionally allow redemption of some or all of the value of the reusable mail permit back into cash or conversion into products or services.   6) Provide for a ‘White-list’ of known senders who cannot or will not attach reusable mail permits.   7) Carefully manage the process of communication with unknown senders who have not attached reusable mail permits to allow them either to:
       a) Be manually added to the White-list   b) Gain the means to attach a reusable mail permit to the current e-mail and to subsequent e-mails.   
       
 
         [0062]    According to an aspect of the invention there is provided a method for regulating the reception of e-mail by an e-mail client acting for a recipient, the method comprising the steps of:
       receiving a first e-mail from an e-mail server by the e-mail client;   checking for the presence of a reusable mail permit attached to said first e-mail;   performing a first action on said first e-mail if no reusable mail permit is attached thereto;   otherwise requesting verification of said reusable mail permit from a reusable mail permit issuing service;   performing a second action on the first e-mail if said reusable mail permit issuing service refuses to verify said reusable mail permit;   otherwise delivering said first e-mail to the recipient;   requesting renewal of said reusable mail permit of the delivered e-mail from said reusable mail permit issuing service; and   storing the renewed reusable mail permit for attachment to a subsequent outgoing e-mail.       
 
         [0071]    According to another aspect of the invention there is provided a system for regulating the transmission of e-mail by a sender to a recipient and the reception of the e-mail by the recipient, the system comprising:
       first sending means arranged to accept an outgoing e-mail from the sender;   second sending means arranged to send the outgoing e-mail onwards to a remote destination;   first receiving means arranged to accept an incoming e-mail from a remote source;   second receiving means arranged to deliver the incoming e-mail onwards to the recipient;   permit storage means arranged to store at least one reusable mail permit;   attachment means arranged to attach at least one reusable mail permit fetched from the permit storage means to the outgoing e-mail accepted at the first sending means before sending on the second sending means; and   extraction means arranged to extract and verify at least one reusable mail permit from an incoming e-mail accepted at the first receiving means before delivering on the second receiving means and storing the extracted reusable mail permit in the permit storage means.       
 
         [0079]    RMPs are attached to outgoing e-mails by a Permit Manager (PM) resident on the sender&#39;s computer, either as part of their normal e-mail client or acting as a proxy for it. Alternatively, the PM may be remotely installed at a central server as is common in the Internet. The receiving PM applies its own checks for acceptability, including checks for corruption, sufficient value, acceptable issuer and expiry date, and then verifies the validity of the received RMP with the issuing PIA before it will accept the e-mail. On receipt of a request for validation of a RMP, the PIA marks it as used and will fail any further requests to validate it. The PIA also initiates generation of a replacement RMP of the same value which can be collected by the verifying PM, and stored for use with subsequent outgoing e-mail. The verification and collection requests are correlated though a unique collection code invented by the PM using the unique number from the RMP (or any other RMP held from the same issuer), and a random component. Optionally, the PM may automatically respond to the incoming e-mail, attaching the replacement RMP. 
         [0080]    In this way, users who receive roughly the same number of e-mails that they send are not ‘taxed’ for their e-mail. Receivers also have the option to credit back the cost of sending e-mails to acceptable bulk senders such as mailing lists. In the case that a receiver accumulates a large number of RMPs, the PIA may also provide a facility for redemption for cash, products or services, of some or all of the value of one or more RMPs, on request. The PIA may also apply an expiry period on RMPs to ensure an ongoing requirement for purchase of new RMPs for housekeeping and optionally to help fund its operations. 
         [0081]    If e-mail is received without a valid or sufficient RMP, and the sender is not already present in a ‘White-list’ of allowed non-RMP senders, a challenge e-mail is returned. If the sender has a PM installed—as indicated by headers in the original e-mail—but did not attach a RMP because they were not aware that the receiver required one, or attached one of insufficient value, the challenge e-mail will be machine-readable and will trigger the automatic resending of the e-mail with a RMP of sufficient value attached (subject to a threshold for manual confirmation). 
         [0082]    If the sender has no PM installed, the challenge e-mail will be human-readable and indicate two possible actions for the sender:
       1) Instructions on how to obtain and install a PM which will then automatically provide a sufficient RMP   2) (At the receiver&#39;s option) A request to send a reason why the receiver should add the sender to the White-list of allowed non-RMP senders.       
 
         [0085]    In the latter case, a summary of requests to join the White-list will be presented to the user on a regular basis, from which they can choose to allow or disallow based on the information presented. In both cases, the receiver also queues the incoming e-mail awaiting response to the challenge and delivers it when a suitable one is received. 
         [0086]    To avoid flooding forged sender addresses with challenges or sending challenges to obvious spam, the sending of challenge e-mails is regulated through communication with a Response Management Service (RMS), which may be part of the PIA or an independent operation. The receiving PM forwards signature items describing the 2006/048621 PCT/GB2005/004205 received e-mail to the RMS, which by comparing them with signatures from other PMs may determine and inform the PM whether:
       a) A challenge should be sent immediately   b) The e-mail should be silently dropped   c) The e-mail should be delivered to the user   d) Further information, up to and including the entire e-mail, should be sent to the RMS   e) The question should be adjourned until further information from other PMs is available and/or the RMS is less busy.       
 
         [0092]    According to another aspect of the invention there is provided a system for regulating the reception of an e-mail by a recipient, the system comprising:
       first receiving means arranged to accept an incoming e-mail from a remote source;   second receiving means arranged to deliver the incoming e-mail onwards to the recipient;   permit storage means arranged to store at least one reusable mail permit; and   extraction means arranged to extract and verify at least one reusable mail permit from an incoming e-mail accepted at the first receiving means before delivering on the second receiving means and storing the extracted reusable mail permit in the permit storage means.       
 
         [0097]    According to another aspect of the invention there is provided a system for regulating the transmission of e-mail by a sender to a recipient, the system comprising:
       first sending means arranged to accept an outgoing e-mail from a sender;   second sending means arranged to send the outgoing e-mail to the recipient;   permit storage means arranged to store at least one reusable mail permit; and   Attachment means arranged to attach at least one reusable mail permit fetched from the permit storage means to the outgoing e-mail accepted at the first sending means before sending on the second sending means.       
 
         [0102]    According to another aspect of the invention there is provided a system for regulating e-mail communications between a sender and a recipient, the system comprising means at a sender for applying a reusable mail permit to an outgoing e-mail to a recipient, the recipient being arranged to block received e-mails which do not comprise a reusable mail permit and to extract said reusable mail permits from received e-mails which do comprise a reusable mail permit, said extracted reusable mail permit being replaced if verified by a reusable mail permit issuing authority and stored for subsequent application to outgoing e-mails sent by the recipient to other recipients. 
         [0103]    According to another aspect of the invention there is provided a computer software program for regulating the transmission of e-mail from a sender to a recipient and the reception of e-mail by the recipient, the program being arranged to attach a reusable mail permit to an outgoing e-mail from the sender to the recipient, the software further being arranged to block received e-mails from other senders which do not comprise a reusable mail permit, the recipient being able to extract reusable mail permits from received e-mails and to store reusable mail permits for subsequent attachment to outgoing e-mails sent by the recipient to other recipients. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0104]    An embodiment of this invention will now be described by way of an example only and with reference to the accompanying drawings, in which: 
           [0105]      FIG. 1  is a block diagram indicating the main components in the process of sending and receiving e-mail and attaching and verifying Reusable Mail Permits; 
           [0106]      FIG. 2  is a structure diagram indicating one possible content and format of a Reusable Mail Permit; 
           [0107]      FIG. 3  is a block diagram indicating the components of a Permit Manager; 
           [0108]      FIG. 4  is a UML sequence diagram indicating the sequence and flow of messages between the components for a normal successful transmission of e-mail between two Permit Manager-enabled e-mail clients; 
           [0109]      FIG. 5  is a UML sequence diagram indicating the sequence and flow of messages between the components for delivery of e-mail between two Permit Manager-enabled clients who have not previously communicated; 
           [0110]      FIG. 6  is a UML sequence diagram indicating the sequence and flow of messages between the components for delivery of e-mail between an initially non-Permit Manager-enabled client and a Permit Manager-enabled client; and 
           [0111]      FIG. 7  is a block diagram indicating the components of a Permit Issuing Authority. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0112]    The detailed architecture and operation of the present invention is now disclosed through detailed description of the drawings. 
         [0113]      FIG. 1  illustrates the main components of the invention. Components  100 ,  101 ,  102 ,  103 ,  104 ,  105 ,  106  are commonly found elements of the existing global e-mail system. Components  107 ,  108 ,  109 ,  110  (shaded) are additional components required by the present invention. 
         [0114]    The components are connected together by the Internet  100 , or alternatively by any other public or private network in which the reception of e-mail from unknown senders is to be regulated. E-mail is received by a receiving e-mail client  101  such as are widely available in the industry. E-mail is sent by e-mail clients  102 ,  103  which are also industry-standard e-mail programs, and by at least one custom bulk e-mail sending system  104  under the control of a spammer. For the purposes of illustration e-mail clients  102 ,  103  are described as senders and e-mail client  101  as a receiver, but in practice all clients are both senders and receivers at various times. Bulk sender  104 , however, is often incapable of receiving e-mail. 
         [0115]    For the purposes of illustration e-mail client  102  is assumed to be under the control of a legitimate sender who has installed the software implementing the present invention, while e-mail client  103  is assumed to be under the control of a sender who has not installed the requisite software, but nevertheless would be considered by the owner of receiving e-mail client  101  to be a legitimate correspondent, unlike bulk sender  104 . 
         [0116]    E-mail is commonly sent from originating e-mail clients  102 ,  103  and bulk sender  104  by a sender-initiated protocol such as SMTP, and may pass through zero, one or more ‘Smarthost’ mailservers  105  before being delivered to the destination mailserver  106 , where it is stored, and from which it is commonly fetched by receiving e-mail client  101  through a receiver-initiated protocol such as POP3 or IMAP. Alternative arrangements of delivery protocols and mailservers are common and obvious to those skilled in the art and are not material to the present invention, which operates on an end-to-end basis between e-mail clients. 
         [0117]    All outgoing and incoming e-mails from and to e-mail clients  101 ,  102  are passed through Permit Managers (PM)  107 ,  108 , which may be built into the e-mail clients  101 ,  102 , or alternatively act as a proxy for them, intercepting the e-mails being sent or received, acting on them, storing them and/or modifying them, and passing them onwards toward their destination. 
         [0118]    PM  108  communicates with one or more Permit Issuing Authorities (PIA)  109  in order to obtain Reusable Mail Permits (RMPs) for attachment to outgoing e-mail. In an exemplary embodiment, the RMP consists of a large unique number, along with indications of value, expiry date, issuing PIA and other ‘housekeeping’ information. This exemplary embodiment has the advantage that RMPs are anonymous. In a preferred embodiment, a cyclic redundancy check (CRC) or other form of verifiable redundancy such as is well known in the art is included as part of the RMP to aid validation. The structure and format of the RMP is more completely disclosed below. 
         [0119]    Upon receipt of e-mail with attached RMPs, PM  107  communicates with the PIA(s)  109  to verify the received RMPs and to obtain replacements, which it stores and uses on subsequent outgoing e-mail of its own. 
         [0120]    On receipt of an e-mail with no RMP attached, PM  107  checks whether the sender is in a White-list of allowed non-RMP senders, and if so, delivers the e-mail as normal. If not, it communicates with a Response Management Service (RMS)  110  in order to obtain advice as to a suggested response to the received e-mail, which may include the sending of a challenge e-mail as disclosed below. 
         [0121]      FIG. 2  is a data-structure diagram indicating an exemplary content and format of a RMP  200 . The structure is shown as a 64-byte (512-bit) binary block, but other sizes and formats of data are possible and easily designed by one skilled in the art. There are advantages and efficiencies in implementation, particularly in hardware, of choosing size of a power of two and 4-byte alignment of the fields within the structure. ‘Spare’ fields have been left for future expansion to accommodate this. Format field  201  is a fixed value which can be used to identify the RMP&#39;s type and version within general protocols. The use of the textual characters ‘RMP 1 ’ is exemplary and aids in debugging and protocol analysis. 
         [0122]    Flags field  202  is a bitmap of individual flags and small fields as defined in table  210 . In the present invention, the following flags and fields have been allocated: 
         [0123]    Redeemable flag  211  indicates whether the RMP is redeemable. Perpetual flag  212  indicates whether the RMP&#39;s expiry time will be extended upon renewal, or whether it remains fixed for the RMP&#39;s lifetime Number of uses field  214  indicates the maximum number of uses of the RMP. A value of zero indicates that usage is unlimited, subject to the overall expiry time. 
         [0124]    The remaining flags  213  are set to zero as defaults for future expansion. 
         [0125]    Unique ID field  203  is a 32-byte (256-bit) unique number which is allocated by the issuing PIA. IDs may be issued at random, but the PIA must ensure that no two IDs with the same value are outstanding at the same time. In a preferred embodiment of the PIA, the PIA ensures that the first 32 bits of the ID are unique, to improve efficiency of lookup, and pads the remaining 224 bits with random data as a redundancy check to prevent forgery. 
         [0126]    Expiry time field  204  gives the expiry time of the RMP as a 64-bit timestamp in Unix ‘time_t’ format—that is to say, number of seconds since midnight UTC on Jan. 1, 1970. This format provides the maximum generality; other formats are possible and will be obvious to one skilled in the art. Making the timestamp UTC (GMT) rather than local time provides for correct operation between clients in different time zones. 
         [0127]    Value field  205  gives the value of the RMP as an integer multiple of some small currency fraction; for example, USD 0.00001 or EUR 0.00001. Choice of this fraction ensures a maximally useful range of values that can be represented within the 32-bit field. In an exemplary embodiment, the value field represents a value within a ‘virtual currency’ maintained through the co-operation of the issuing PIAs, and subject to fixed or floating exchange rates with conventional world currencies, This provides for ease of cross-border exchange of RMPs. 
         [0128]    Issuer ID field  206  indicates which PIA issued the RMP, and can be looked up in a centrally-maintained table of PIAs to obtain a network address for its renewal or redemption. In a preferred embodiment, this table is held in DNS or X.500 distributed databases. 
         [0129]    Spare fields  207 ,  208  are provided for future expansion, and in order to pad the structure to 64 bytes, and are set to a default of zero in the present version. 
         [0130]    CRC field  209  provides a check against errors in the rest of the RMP data. In an exemplary embodiment the CRC is calculated with the standard CCITT CRC-16 algorithm across the rest of the RMP data block. 
         [0131]      FIG. 3  is a block diagram of an exemplary implementation of a Permit Manager (PM)  107 ,  108 . The definition of a Permit Manager should be regarded as functional and not limited by the structure described herein. 
         [0132]    Permit Managers  107 ,  108  comprise a permit processor  301  which adds RMPs to outgoing e-mail and checks RMPs on incoming e-mail. Permit processor  301  makes use of three databases  302 ,  303 ,  304  which may be held in memory, on disk file or in a conventional database subsystem. Recipient database  302  holds information on individual recipients who are known to also have PMs installed, keyed by e-mail address. In a preferred embodiment, recipient database  302  also includes a public key for each recipient. In a further preferred embodiment, recipient database  302  also includes the minimum RMP value  205  acceptable to the recipient. In a still further preferred embodiment, recipient database  302  includes the RMP flags  202  acceptable to the recipient. 
         [0133]    RMP database  303  holds all the RMPs available for use by the PM. Collection list  304  holds a list of collection codes and associated data for use in retrieval of replacement RMPs as more fully described below. 
         [0134]    Communicating with the local e-mail clients  101 ,  102  are a local mail receiver  305  and local mail sender  306 . Local mail receiver  305  provides means to deliver incoming e-mail to the local e-mail clients  101 ,  102 . In an exemplary embodiment this will be via client-initiated polling such as through POP3 or IMAP, but other mechanisms including direct delivery by SMTP or direct delivery to an ‘InBox’ are possible and obvious to one skilled in the art. 
         [0135]    Local mail sender  306  accepts outgoing e-mail from local e-mail clients  101 ,  102 . In an exemplary embodiment this will be via SMTP, but other mechanisms are possible and obvious to one skilled in the art. 
         [0136]    Communicating with mailservers in the outside world are global mail receiver  307  and global mail sender  308 . Global mail receiver  307  provides means to receive incoming e-mail from external mailservers  106 . In an exemplary embodiment, reception is performed through POP3. In an alternative embodiment, reception is performed through SMTP. Other protocols and mechanisms are possible and obvious to one skilled in the art. 
         [0137]    Global mail sender  308  delivers outgoing e-mail to external ‘smarthost’ mailserver  105 , or directly to destination mailservers  106 , or through other intermediate servers not shown. In an exemplary embodiment, this delivery is performed through SMTP, but other protocols and mechanisms are possible and obvious to one skilled in the art. 
         [0138]    PIA interface  309  manages transactions between the PMs  107 ,  108  and RMP-issuing PIA  109 . These transactions may be carried in binary messages, XML messages, CORBA requests, SOAP requests or other distributed system technologies such as are well known in the art. In a preferred embodiment, these transactions are encrypted in a public key cryptosystem such as RSA, using public keys configured into the PM or obtained through other trusted means such as DNS or an X.509 certificate chain. 
         [0139]    RMS interface  310  manages transactions between the PMs  107 ,  108  and RMS  110 . These transactions may be carried and encrypted as with transactions between PMs and PIA described above. In an alternative embodiment, the PIA and RMS interfaces are one and the same. 
         [0140]    Pending mail database  311  is a database of e-mail messages that have been recently sent but for which a challenge may be received requiring them to be resent. In an exemplary embodiment, e-mails are keyed in the database by their RFC2822 Message-ID. If the sending e-mail client does not provide a valid Message-ID, the PM invents one and attaches it to the outgoing e-mail, as is standard behaviour for mailservers. E-mails are kept in this database for a configurable period of time before it is assumed they have been successfully delivered and they are deleted. 
         [0141]      FIG. 4  is a simplified UML sequence diagram showing the sequence and flow of messages between components for normal delivery of e-mail between two PM-enabled e-mail clients who have previously communicated. 
         [0142]    The diagram shows an abstraction of the process, and the messages between components and within a component may be implemented in any message-passing or Remote Procedure Call (RPC) technology, such as are well known in the art, including but not limited to direct call, SOAP, CORBA, Java RMI, DCOM, .NET, HTTP, XML messages, ASN.1 messages, or other standardised or proprietary textual or binary protocols. 
         [0143]    For the purposes of exemplary embodiment, the PMs are shown as separate components, but the process is equally applicable if one or both of the PMs are built into their respective e-mail clients and the PM and e-mail client interact through normal procedural call. 
         [0144]    The process begins with the sending e-mail client  102  sending  401  an e-mail. In the exemplary embodiment shown, the sending PM  108  acts as a proxy for the e-mail client, and hence accepts the e-mail through SMTP at local mail sender  306  like any other ‘smart’ mailserver. The sending e-mail client  102  may be manually or automatically configured to send outgoing e-mail via sending PM  108 , or the local computer or network may be configured to transparently forward the SMTP traffic to the PM without the knowledge of the client. Both techniques are well known in the art in relation to e-mail virus checking. Methods of intercepting and modifying e-mails in other e-mail delivery protocols will also be obvious to those skilled in the relevant protocol. 
         [0145]    The sending PM&#39;s first step  402  is to look up the recipient of the e-mail in recipient database  302 . There are three possible cases:
       1) The recipient is believed to have a PM installed   2) The recipient is believed not to have a PM installed   3) Nothing is known about the recipient one way or the other       
 
         [0149]    The first case is the case shown in  FIG. 4 . In a preferred embodiment, having determined that the recipient is believed to have a PM, the sending PM  108  checks information in the recipient database  302  concerning the minimum value of RMP required by the recipient to allow receipt of e-mail. In a preferred embodiment, the sending PM  108  also checks information about the RMP flags required by the receiver. 
         [0150]    The next step  403  is to fetch a suitable RMP  200  from RMP database  303 . Assuming that the sending PM has a valid RMP of sufficient value and/or flag settings available, the next step  404  is to remove it from RMP database  303  and attach it to the e-mail. In a preferred embodiment, the value may be made up from multiple smaller RMPs, and all mentions of a singular RMP in the following should be taken to include the plural. In a more preferred embodiment the attached RMP is stored in a separate database, or temporarily marked as having been used, in case the transmission is rejected and the RMP needs to be recovered. In the exemplary embodiment using SMTP, attaching the RMP to the e-mail may be performed by inserting RFC2822 extension headers with a textual encoding of the RMP data, such as in hexadecimal or Base64 or other encoding schemes such as are well known in the art. Other protocol-specific methods of attaching an RMP to an e-mail message will be obvious to those skilled in the relevant protocols. 
         [0151]    In a more preferred embodiment, a public key for the receiving PM  107  is also looked up in the recipient database  302  in the first step  402 , and the RMP is encrypted with this public key in a public-key cryptosystem such as RSA, or others that are well known in the art, before attachment to the e-mail. In a still more preferred embodiment, to reduce processing requirement at the PIA and remove predictable plaintext, only the Unique ID  203  of the RMP is encrypted with the public-key. 
         [0152]    If the RMP database  303  does not have an RMP of sufficient value available, an error will be returned to the user notifying them that they need to purchase more RMPs. In an exemplary embodiment, this will take the form of an e-mail returned through local mail receiver  305 . The original e-mail is stored in pending mail database  311  until sufficient RMPs are available. If the user purchases additional RMPs (described below), or an RMP arrives from incoming e-mail, the PM will retrieve the pending e-mail and resume the sending process. 
         [0153]    In all cases, the sending PM&#39;s next step  405  is to attach PM data to the e-mail indicating the presence of the sending PM. In an exemplary embodiment, this is performed by attaching RFC2822 extension headers. In the preferred embodiment where encryption is used, the PM data also indicates the sending PM&#39;s public key. In the further preferred embodiment in which a minimum value and/or flag settings of RMPs for receiving e-mail is applied, this is also indicated in the PM data. 
         [0154]    In a more preferred embodiment (not shown) the sending PM  108  always stores the e-mail in pending mail database  311 , in case the RMPs are rejected by the receiving PM  107  due to out of date data about it—for example, the minimum value of RMP required by the receiving PM  107 . In this case, the sent e-mail is removed from the pending mail database  311  after a reasonable period of time for any error to be returned. 
         [0155]    The final step  406  for the sending PM  108  is to send the modified e-mail onwards to its destination using the standard e-mail mechanisms such as SMTP, through the global mail sender  308 . Step  406  is shown as dotted and asynchronous because it may involve several intermediate mailservers  105 ,  106 . The receiving PM  107  may receive the e-mail through SMTP itself, or more usually the destination mailserver  106  will receive it through SMTP and store it until the receiving PM  107  polls for it using a receiver-initiated protocol such as POP3 or IMAP. Such protocols and mechanisms for delivery of e-mail, and variations thereof, are well known in the art and are immaterial to the generality of the present invention. 
         [0156]    The receiving PM&#39;s first step  407  is to extract the RMP or RMPs  200  (if any) from the e-mail. In the exemplary embodiment using SMTP, this may be performed by extracting and decoding the extension headers inserted at  404 . In the more preferred embodiment in which the RMP is encrypted, this step further comprises decrypting the RMP with the receiving PM  107 &#39;s private key. 
         [0157]    The next step  408  for the receiving PM  107  is to check the prima facie acceptability of each RMP insofar as it is able to using its own information. This includes:
       1) Checking the RMP has not been corrupted, using the CRC  209     2) Checking the RMP is of a correct type and version, using the format field  201     3) Checking the RMP has acceptable flags, using flags field  202     4) Checking the RMP has not expired, using the expiry time field  204     5) Checking the RMP value is sufficient to allow reception of the e-mail, using the value field  205     6) Checking the RMP was issued by an acceptable issuer in a list of acceptable issuers, using issuer ID field  206         
 
         [0164]    In each case, if the acceptability check fails, the e-mail will be deleted and an error message may be returned to the sender, subject to management by the RMS  110  as more completely disclosed below. In a preferred embodiment, if the acceptability check fails, a machine-readable message is returned which indicates the reason for failure and gives the sending PM  108  a chance to resend the e-mail with a more suitable RMP attached and to recover any RMPs that may have been attached to the original e-mail. 
         [0165]    In a more preferred embodiment, to avoid loss of RMPs that are rejected by recipients, the sending PM  108  records all RMPs sent out and if they are rejected, returns them to RMP database  303 . In a still more preferred embodiment, to prevent receiving PM  107  fraudulently rejecting an RMP while nevertheless reusing it itself, the sending PM  108  requests reverification at the issuing PIA of any RMP which is rejected by a recipient. 
         [0166]    If the RMP appears prima facie acceptable to the receiving PM  107 , its next step  409  is to verify the RMP with the issuing PIA  109 . In an exemplary embodiment, the receiving PM looks up a network address of the issuing PIA from the issuer ID field  206  of the RMP in an internal table which may be refreshed from time to time. In a more preferred embodiment, the receiving PM looks up the issuer ID  206  in a distributed database such as the global Domain Name System (DNS) or X.500. In the case of DNS, the receiving PM may look up an address such as “12345.1ssuers.rmp.net”, where ‘12345’ is the value of the issuer ID field  206 , and ‘issuers.rmp.net’ is any DNS domain registered and configured into the PM for this purpose. 
         [0167]    On obtaining an address for the issuing PIA  109 , the receiving PM  107  requests validation of the RMP  200  by the issuing PIA. The receiving PM sends the entire RMP to the issuing PIA for validation. In an exemplary embodiment, the receiving PM also sends a collection code by which a later request for collection of a replacement RMP may be uniquely identified. The specification of the collection code by the PM rather than the PIA allows better recovery in case of loss of messages or failure, since the PM is able to retry the transaction without requiring return traffic from the PIA. In a preferred embodiment, the collection code is a large, unique, unforgeable number, which includes an element of uniqueness, such as the first 32 bits of any RMP held by the PM with the same issuer ID as the one being checked, and an element of randomness, such as a 32-bit random number. In a further preferred embodiment the receiving PM also sends its public key so that any reply message from the PIA may be secured. In a still more preferred embodiment, the receiving PM invents a symmetric session key for the transaction, and transmits this encrypted with the PIA&#39;s public key with the initial verification request. This session key can then be used to encrypt both the RMP itself and subsequent collection requests and responses, further reducing the workload of the PIA. Other methods of establishing session keys using a public key infrastructure are well known in the art. 
         [0168]    On receipt of a request for validation of a RMP  200 , the issuing PIA  109  may apply its own prima facie check for acceptability of the submitted RMP. Having checked that the submitted RMP appears acceptable and was issued by this PIA (by checking the Issuer ID  206 ), it then looks up the Unique ID  203  in an internal database of issued IDs. In the preferred embodiment wherein the first 32 bits of the Unique ID  203  are guaranteed to be unique, the PIA can use this as the lookup key more efficiently than searching for the entire 256-bit ID. In an exemplary embodiment of the lookup process, at least one hash table is used to make the lookup time approximately constant irrespective of the number of IDs held in the database. 
         [0169]    Having looked up the Unique ID  203  the PIA then compares the entire submitted RMP  200  against a copy stored in its database referenced by the Unique ID. Only if the submitted RMP and the stored RMP are identical in every respect is the submitted RMP considered valid. This check prevents any variation of the fields of the RMP during its lifetime—for example, to alter the expiry time or value. 
         [0170]    In an alternative embodiment of the present invention, in which lookup and block comparison are very efficient, the prima facie check is omitted, since the comparison of the entire RMP is sufficient to verify its validity in any case. 
         [0171]    If the submitted RMP exists in the database and has not been modified, the issuing PIA  109  returns a success indication to the receiving PM  107 . In a preferred embodiment, this success indication also includes an indication of a time at which the receiving PM may collect a replacement RMP. This time may be varied by the issuing PIA to spread its load in issuing replacement RMPs. In a more preferred embodiment, the success indication also includes a new Issuer ID from which the collection should be made, allowing an issuing PIA to hand its work to another issuing PIA should it need to do so for reasons of overload or imminent shutdown. 
         [0172]    If the submitted RMP is prima facie unacceptable, or does not exist in the database, or has been changed since it was issued, a failure indication is returned to the receiving PM  107  and the error, logged for manual investigation. Repeated failures of this nature may indicate an attempt at fraud on the system. 
         [0173]    In a further preferred embodiment, all transactions between the PMs  107 ,  108  and the issuing PIA  109  are encrypted under a public-key cryptosystem such as RSA with the public key of the issuing PIA, which may be determined either from an internal table or through lookup in a distributed database such as DNS, as with the network address of the issuing PIA. In an alternative embodiment, all transactions take place encrypted by a symmetric session key which is established using the public key of the issuing PIA. Such mechanisms for establishing symmetric session keys using public key infrastructure are well known in the art. 
         [0174]    In a still further preferred embodiment, all transactions between the issuing PIA  109  and the PMs  107 ,  108  are encrypted under a public-key cryptosystem such as RSA with the public key of the PM in question, which may be retrieved from the message received at step  409 . In an alternative preferred embodiment, all transactions between the issuing PIA and the PMs are encrypted under a temporary symmetric session key, which may be retrieved from the message received at step  409 , itself being encrypted with the PIAs public key. Such mechanisms for establishing symmetric session keys using public key infrastructure are well known in the art. 
         [0175]    If the receiving PM  107  receives a success indication from verification step  409 , the receiving PM  107 &#39;s next step  410  is to extract any PM data attached to the e-mail inserted at  405 . In an exemplary embodiment, this is done by searching for specific RFC2822 extension headers in the message. If PM data is available, the receiving PM&#39;s next step  411  is to store the PM data in the recipient database  302  against the sender of the e-mail, ready for use with any reply. 
         [0176]    In a preferred embodiment, if the sender is new or their PM data has changed, and their minimum acceptable RMP value is more than a user-configurable value, or they require certain configurable RMP flags, the user will be asked to manually authorise the storage of the sender in the recipient database and consequent sending of high-value or specially-flagged RMPs. In an exemplary embodiment, this is performed by returning a query e-mail to the user through local mail receiver  305 , quoting a subject referencing the e-mail&#39;s Message-ID. If the user responds to the query e-mail, the sender may be stored in the database. Failing that, the sender may be ignored, or alternatively an entry made in the recipient database to block outgoing e-mail for the sender&#39;s address. 
         [0177]    The receiving PM&#39;s next step  412  is to store the received e-mail for subsequent fetch by the receiving e-mail client  101  through local mail receiver  305 . At some time later  413 , the receiving e-mail client  101  may poll for new e-mail and the received e-mail will be delivered to the user. If the PM is built into the e-mail client, at step  412  it will simply store the received e-mail in the user&#39;s ‘InBox’ as usual. 
         [0178]    Following successful verification of the received RMP, the receiving PM will also store the collection code, collection time and collection issuer ID returned by the issuing PIA in collection list  304 . 
         [0179]    Should the receiving PM  107  receive a failure indication from verification step  409 , it will delete the e-mail and optionally return an error e-mail to the sender of the received e-mail, subject to management by the RMS  110  as more completely disclosed below. 
         [0180]    At some other time, before or after the delivery of the e-mail at  413 , the next step  414  of the receiving PM  107  is to work through the collection list  304 , collecting renewed RMPs from the appropriate issuing PIA  109 . The process of renewal of RMPs by the issuing PIA is described in detail below. 
         [0181]    In the preferred embodiment wherein the issuing PIA supplies a collection time as part of the success indication in verification step  409 , the receiving PM waits until that time before initiating the collection of the replacement RMP at step  414 . In the more preferred embodiment wherein the issuing PIA supplies a replacement issuer ID as part of the success indication, the receiving PM looks up the network address (and optionally, public key) of the replacement issuer at step  414  as at step  409 . 
         [0182]    In an alternative embodiment of the present invention (not shown), the steps of verifying a RMP  409  and collecting a RMP  414  may be combined into a single request and response to the issuing PIA. Other methods of arranging the communications between PM and PIA to verify and replace a RMP will be obvious to one skilled in the art. 
         [0183]    Having obtained a replacement RMP, the receiving PM&#39;s final step  415  is to store it into RMP database  303 , ready for use on a subsequent outgoing e-mail of its own. When sending a new outgoing e-mail, the initially receiving PM  107  then acts like sending PM  108  and the cycle begins again. 
         [0184]    In a preferred embodiment of the present invention (not shown), the receiving PM  107  may be configured to automatically return an e-mail carrying a RMP of equivalent value to specific senders or classes of senders of received e-mail. This allows selected senders, such as e-mail list servers and auto responders, to send repeated e-mail to the receiving e-mail client without incurring any net cost. 
         [0185]      FIG. 5  is a simplified UML sequence diagram showing the sequence and flow of messages between components for delivery of e-mail between two PM-enabled e-mail clients who are communicating for the first time and hence not yet aware that the other has PM technology installed. 
         [0186]    The process begins with sending step  401  and recipient lookup step  402  as in  FIG. 4 , In this case, however, the lookup of the recipient will fail, and no RMP will be used (steps  403 ,  404  are absent). Instead, the sending PM  108  takes the step  501  of storing the e-mail in pending mail database  311  in case a challenge is received. It then continues as in  FIG. 4  to attach its own PM data at  405  and deliver e-mail to the recipient at  406 . 
         [0187]    Receiving PM  107  checks for the presence of a RMP by looking for extension headers in the received e-mail, and finding none, skips steps  407 - 409 . It does however find headers indicating PM data, so extracts the PM data at  410 , but because no RMP is present it cannot perform steps  411 - 415 . Instead it performs new steps  502 ,  503  of forming a signature of the e-mail and requesting advice from the RMS  110  on whether to challenge the sender to attach a RMP. 
         [0188]    Forming signatures of e-mails is well known in the art in systems which use collaborative filtering techniques. The signature is a digested form of the e-mail which represents the key unique features of it without requiring the entire e-mail to be sent, which would waste bandwidth and may be a violation of privacy. In an exemplary embodiment one-way hash techniques such as SHA-1 are used to form a signature of significant headers and multiple overlapping sections of the content, providing some proof against addition of random text to the message. Further techniques of extracting identifying information and forming privacy-protected signatures will be obvious to one skilled in the art. 
         [0189]    On receipt of a request for advice on an e-mail from its signature, the RMS makes use of techniques well known in the art of collaborative filtering, and others as are described below, to decide whether the e-mail is:
       1) A legitimate e-mail   2) A clear attempt at using the challenge mechanisms as a denial-of-service (DoS) attack   3) A clear attempt at spam   4) Uncertain       
 
         [0194]    Depending on which determination is made, the RMS may return an advice result to the receiving PM which advises it to do one of:
       1) Delete the e-mail immediately   2) Deliver the e-mail immediately to the user without responding with a challenge;   3) Respond with a challenge immediately;   4) Send more detailed signature to the RMS for further advice;   5) Send the entire e-mail to the RMS for further advice;   6) Wait for a period of time and repeat the request for advice; the time specified either as an elapsed time or an absolute time.       
 
         [0201]    These options allow the RMS to manage the response to a widespread spam or DoS attack, while ensuring that potentially legitimate e-mail is allowed through. The failsafe response in cases of uncertainty is to delay advice until further information from other PMs is available, and then if still uncertain, to advise the sending of a challenge. Only if the e-mail is clearly spam within a user-configurable margin of error will immediate deletion be advised. Similarly, only if the e-mail is clearly legitimate within a user-configurable margin of error from a non-PM enabled sender will immediate delivery be advised. In this way, the user—or RMS on behalf of the user—can manage the balance between false positives, false negatives and challenges for optimum results. 
         [0202]    The outcome of possibly multiple, time-spaced requests to the RMS for advice on a given e-mail is therefore to delete the e-mail immediately and stop delivery; continue with delivery immediately at step  412 , or to challenge the sending PM to attach a RMP. 
         [0203]    In the latter case, the receiving PM then performs new steps  504 ,  505  of creating and delivering a challenge e-mail back to the sending PM. Since the receiving PM knows the PM data of the sending PM, the challenge e-mail can be largely machine-readable. The challenge e-mail refers to the original e-mail by its RFC2822 Message-ID, and also includes the PM data of the receiving PM. In a preferred embodiment, the PM data includes the minimum acceptable RMP value and/or flag values needed to deliver the original e-mail. In a further preferred embodiment, the value quoted may be dependent on the sender&#39;s identity or another quality of the original e-mail. Delivery of the challenge e-mail  505  is the reverse of the delivery of the original e-mail at  406 , using the standard procedure for delivering reply e-mail as is well known in the art. 
         [0204]    On receipt of a challenge e-mail, identified by the presence of further special headers, the sending PM&#39;s first step  506  is to store the PM data quoted into its recipient database  302 . This will allow it to send e-mails normally to this recipient in all future cases. As before at  411 , if the recipient&#39;s minimum acceptable RMP value is more than a user-configurable value, or requires certain configurable RMP flags, the user will be asked to manually authorise the storage of the recipient in the recipient database. 
         [0205]    The sending PM&#39;s next step  507  is to retrieve the original e-mail from its pending mail database  311 , making use of the Message-ID quoted in the challenge e-mail. Having the e-mail and valid recipient data in hand, it is then able to retry the sending process from step  403 ,  FIG. 4 , which should complete normally without further challenges. It is important that the original recipient&#39;s address is used to deliver the e-mail at step  406 , not the return address for the challenge, to avoid attack from third parties wishing to fraudulently extract RMPs from the sender. 
         [0206]      FIG. 6  is a simplified UML sequence diagram showing the sequence and flow of messages between components for delivery of e-mail between an e-mail client which does not have PM technology installed and one that does. 
         [0207]    In the first step  601 , the sending e-mail client  102  delivers e-mail to the receiving PM  107  by the common e-mail protocols, or others, as described above. Note that there is no sending PM  108  present (yet). Since the receiving PM finds neither PM data nor RMP attached, it immediately moves to challenge the e-mail. Firstly it requests advice on how to manage the challenge from the RMS  110  as previously shown in steps  502 ,  503 . Assuming the RMS indicates that a challenge is required, the receiving PM&#39;s next step  602  is to store the e-mail in pending mail database  311 , marking it as pending for reception rather than for sending as before. 
         [0208]    The next step  603  is to create a challenge e-mail. This time, however, the e-mail is designed to be read by a human, and contains an explanation of the RMP system, why the sender&#39;s e-mail has not yet been delivered, and instructions on how to obtain and install a Permit Manager in order to provide a RMP to allow it to be delivered. In a preferred embodiment, the instructions are sent in a language specified by the user at configuration time. In a further preferred embodiment, the instructions are sent in multiple languages. In a still more preferred embodiment, the first or only language the instructions are sent in is dependent on the geographical location of the sender as determined by lookup in an IP address allocation database, domain database, or otherwise. 
         [0209]    The e-mail&#39;s instructions will also have encoded in them the PM data of the recipient, including in preferred embodiments the receiving PM&#39;s public key and minimum RMP value, together with the Message-ID of the stored e-mail. In a preferred embodiment, this data is encoded into the URL link that the user clicks on to initiate the install process. 
         [0210]    The receiving PM then delivers  604  the challenge message back to the sending e-mail client, using the standard methods for sending reply messages. In this case, it is to be assumed the user agrees to install a PM at step  605 ; if not, the challenge will never be responded to and the original e-mail will eventually time out of the pending mail database  311 , and be silently deleted. 
         [0211]    However, the original sender may wish to (or be forced to), reply manually to the challenge rather than install a PM. In this case the sender should provide a brief explanation as to the reason for not installing the PM and must use the standard method of sending a reply message. In a preferred embodiment, in order that the receiving PM  107  can identify the manual response, it creates a distinguished Message-ID for the challenge e-mail which will conventionally be quoted in the ‘References’ header of the manual response. In a more preferred embodiment, this Message-ID will also include a reference to the original e-mail. The receiving PM will then extract the manual response from the returned challenge and present it to the recipient during the normal periodic reporting mechanism. The recipient may then wish to read the original e-mail and/or White-list the sender. In the more preferred embodiment, the original e-mail can be fetched from the pending mail database  311  using the e-mail reference extracted from the References headers in the returned challenge. 
         [0212]    In a still more preferred embodiment, to avoid providing a loop-hole for spammers to send free text to recipients, thus bypassing the system, any manual response is first filtered by the RMS  110 . Large numbers of apparent manual responses from the same address, or other indicators of spam content, can be used to filter the manual responses before presentation to the original recipient. 
         [0213]    Once the sending PM  108  is installed, it can continue the process of sending a RMP with an automatic response message. In order to construct the response message and properly attach the RMP it requires the recipient address, PM data and Message-ID from the challenge message returned to the non-PM e-mail client at  603 ,  604 . This is shown as step  606 . In a preferred embodiment the challenge data is passed through the install URL to the download service which provides the PM software, where it may be directly configured into the downloaded package, or stored against a reference returned with the downloaded package, from which it may be fetched by the newly installed PM. In an alternative embodiment, the challenge data is encoded in locally stored data such as browser cookies which the newly installed PM is able to access. Other means of passing challenge data to the newly installed PM will be obvious to one skilled in the art. 
         [0214]    In an alternative embodiment, the challenge data passed to the newly installed PM  108  consists only of the recipient address and Message-ID, and the newly installed PM  108  immediately requests the PM data of the recipient  107  by means of a specially-encoded e-mail. 
         [0215]    Once the newly installed sending PM  108  has the recipient address and the PM data from the challenge e-mail, it can store  607  the recipient details in recipient database  302 , ready for further e-mails to this recipient. It can also create  608  an automatic response e-mail including the Message-ID of the original e-mail, to be sent back to the receiving PM. It then goes through the normal steps  403 ,  404 ,  405 ,  406  of finding and attaching a RMP and its own PM data to this response message, and delivering it to the receiving PM  107 . 
         [0216]    Receiving PM  107 &#39;s first step  609  on receiving an authentic response to a challenge, which it identifies by the presence of further special headers, is to retrieve the original e-mail stored at  602  by looking up the Message-ID quoted in the response. Once the original e-mail is restored, the receiving PM can complete steps  407 - 415  as before to allow delivery of the original e-mail, except that the PM data and RMP are obtained from the response e-mail rather than the original e-mail itself. 
         [0217]    If PM-enabled e-mail client  102 ,  108  sends an e-mail to a non-PM enabled e-mail client, it will follow  FIG. 5  up to step  406  in which the e-mail is delivered to the non-PM enabled e-mail client. Since the attached PM data is encoded in extension headers, the receiving non-PM enabled e-mail client will display the e-mail as usual, and will not respond with a challenge. After a time, the sent e-mail will time out of the pending mail database  311 , and will be deleted with no further action. 
         [0218]      FIG. 7  is a block diagram showing the structure of a Permit Issuing Authority (PIA)  109 . The definition of a PIA should be regarded as functional and not limited by the structure described herein. 
         [0219]    The PIA  109  comprises a central permit issuer  700 , which maintains a database of issued RMPs  701 , and a database of outstanding collections  702 . Attached to the permit issuer  700  are one or more permit checkers  704 ,  707 , each with a PM interface  703 ,  706  which accept requests from PMs to verify RMPs and collect new ones as previously described. Also attached to permit issuer  700  is a Web interface  709  which provides user access to the service for the purposes of purchase and redemption of RMPs as described below. 
         [0220]    The primary technical issue for the PIA is one of scalability. The permit issuer  700  has to be a single logical unit, because it controls a single database of RMPs  701  and list of outstanding collections  702 . Systems for delivering highly-scalable database instances are well known in the art. However, all extraneous functionality other than the critical functions of maintaining the RMP database and collection list should be removed from the core permit issuer and distributed to multiple devices. 
         [0221]    The highest load on the PIA is in verifying submitted RMPs as at  409 ,  FIG. 4 . This requires a number of prima facie acceptability tests, a lookup step of the unique part of the RMP, and a comparison step of the whole submitted RMP against a stored copy, as described above. In the more preferred embodiment in which the RMP is encrypted, this step further comprises decrypting the RMP before verifying it. These processes are best performed by a cluster of dedicated servers each containing an in-memory cache of valid RMPs  705 ,  708 . Lookups in memory augmented by hash tables are extremely fast, and the memory requirements are manageable even for several million outstanding RMPs. 
         [0222]    A permit checker  704 ,  707  which verifies the validity of a RMP can immediately return a response to the requesting PM  107 , indicating success or failure. In a preferred embodiment, if the verification was successful a collection time is also returned. In a still more preferred embodiment, an alternate issuer ID is returned if the issuing PIA wishes to offload the renewal and collection. The verifying permit checker  704 ,  707  also sends an update message quoting the original RMP and the PM&#39;s collection code and collection time to the permit issuer  700 . On receipt of the update message, the permit issuer  700  renews the RMP with the same flags  202 , expiry time  204 , value  205  and issuer ID  207  as the original, but with a new Unique ID  203  and CRC  209 . In a preferred embodiment, the Unique ID is arranged so that the first 32 bits are unique and the remainder is random. It replaces the old RMP with the new RMP in the RMP database  701 , and adds the new RMP keyed by the collection code to the collection database  702 . In a more preferred embodiment, other fields of the RMP may be modified according to the PIA&#39;s policy. 
         [0223]    In order to update the RMP caches  705 ,  708  of all the permit checkers  704 ,  707 , the permit issuer  700  broadcasts an update message to all permit checkers, quoting both the old and the new RMP. Each permit issuer deletes the old RMP from its own memory cache and inserts the new one. In an alternate embodiment, only the old RMP is quoted and deleted, and the new one is inserted upon collection. In a further alternate embodiment, only the old RMP is quoted and deleted, and the new one is inserted by a further message at another time. 
         [0224]    On receipt of a request for collection as at  414 ,  FIG. 4 , the permit checker  704 ,  707  passes it directly to the permit issuer  700 . The permit issuer  700  looks up the collection code in collection database  702 , and, if found, deletes the record from the collection database  702 , and returns the relevant renewed RMP which the permit checker  704 ,  707  then returns to the requesting PM  107 . If distributed systems and/or non-reliable protocols (e.g. UDP) are used, this process will require mechanisms to assure consistency and reliability of the transactions such as are well known in the art. 
         [0225]    In a preferred embodiment, the permit issuer  700  may manage the collection times being issued by the permit checkers  704 ,  707  in order to control its own workload, based on the suggested collection time and the time the collection is successfully completed. 
         [0226]    In the foregoing, a given RMP may be reused many times before it is eventually expired. In order to maintain the ‘float’ of RMPs within the system as a whole, users will need occasionally to purchase new RMPs from an issuing PIA  109 . 
         [0227]    In an exemplary embodiment of the present invention, RMPs may be purchased by the user using a Web browser to connect to Web interface  709 , providing a standard Web-based e-commerce interface such as is well known in the art. As a result of a purchase with credit-card or other method of payment, Web interface  709  requests permit issuer  700  to create a number of new RMPs with specified flags  202 , value  205  and expiry time  204  as when renewing an old one. 
         [0228]    In an alternative embodiment, RMPs may be purchased in bulk through a web-services interface such as SOAP provided by Web interface  709 . 
         [0229]    In a preferred embodiment, the collection codes for the RMP creation are invented by the Web interface  709 , and communicated back to the user&#39;s PM  107  through a machine-readable update e-mail. The user&#39;s PM  107  then collects the RMPs as at  414 ,  FIG. 4 . In an alternate preferred embodiment, the Web interface  709  collects the RMPs itself, and the entire RMPs are communicated directly back to the user&#39;s PM  107  through an automatic e-mail. In the more preferred embodiment in which such messages are encrypted, a prior e-mail exchange will be required to exchange public keys. Such e-mail exchange may be initiated through a ‘mailto:’ Web link presented at the end of the purchase process. The exact form of the ‘mailto:’ may include identifying data for the transaction. 
         [0230]    The issuing PIA may also choose to offer redemption of RMPs for all or some of their purchase value. In this case, the RMP will have the ‘Redeemable’ flag  211  set. RMPs with this flag set may be sent by PM  107  to the PIA  109  as for verification, but with the request that instead of renewing them they are redeemed for value paid to the user&#39;s account in an accounting system (not shown). The Web interface  709  may be used to manage the account and pay in and withdraw funds as is well known in the art. 
         [0231]    In a large-scale scenario where PMs are widely deployed, it is likely that each PM user will have an account with only one out of a number of RMP-issuing PIAs. In such a case it is possible that an RMP received by a recipient may have been issued, and must therefore be redeemed, by a PIA other than the one with which the recipient has a direct accounting relationship. In a preferred embodiment, therefore, there is an inter-PIA payment clearing system (not shown) which enables payments redeemed at one PIA to be resolved to credits in an account held by another. Such systems for clearance or resolution of payments or charges between providers are well known in fields such as banking and telephony. In the preferred embodiment therefore, the request to redeem an RMP, if not to the PM&#39;s ‘home’ PIA, includes a reference to the home PIA and user&#39;s account to enable the clearance of some or all of the redeemed value to the user&#39;s account in the home PIA. 
         [0232]    In an alternative preferred embodiment (not shown), the user does not require an account with any particular PIA, but can redeem RMPs through an RMP clearing service which accepts RMPs from a number of PIAs and handles the process of redeeming them by proxy on behalf of the user, then makes an aggregated payment or delivers goods or services to the user for the total redeemed value, minus a service charge. Payments from PIAs to the RMP clearing service are handled on a periodic aggregated basis. The communication between PIAs and an RMP clearing service may be through Web services such as is well known in the art. 
         [0233]    In an alternative embodiment, all communication between the user and the PM and PIA is performed by e-mail. In a further preferred embodiment, the PM has its own user interface for management of RMPs which communicates directly with the PIA. In a still further preferred embodiment, web services or other distributed systems technologies are used to manage purchase and redemption of RMPs. Further methods of arranging the purchase and redemption of RMPs will be obvious to those skilled in the art. 
         [0234]    In a preferred embodiment of the present invention, new users of the system are issued with a small number of free RMPs, to encourage them to use the service. These free RMPs will not be redeemable  211 , and are likely to have a short expiry time  204 , to avoid flooding the system with free RMPs. Ideally, free RMPs will expire at the same rate as they are issued. To avoid misuse, the number of free RMPs issued to any single person or entity will be limited. 
         [0235]    One of the major hurdles in deploying a stamp-based spam-control service such as is described in the present invention is in handling senders who have not, will not, or cannot, install the software (PM) to attach a ‘stamp’ (RMP). It has been shown in  FIG. 6  how a sender who does not initially have a PM  108  installed may be directed how to obtain one and allow the free flow of their original and subsequent e-mail. In some circumstances, however a recipient may wish to allow free passage of e-mail without attached RMPs from senders who they believe will not or cannot install PM technology. 
         [0236]    Accordingly, in a preferred embodiment of the present invention, a ‘White-list’ of senders (not shown) is stored at PM  107 . E-mail from senders on the White-list is allowed through even if no RMP is attached. Senders may be added to the White-list manually, or, at the user&#39;s option, as a result of any outgoing e-mail to them, or presence in the user&#39;s address book. 
         [0237]    In order to allow communication from non-PM-enabled senders who are not in the White-list, the challenge process  603 ,  604   FIG. 6  is adapted to provide for an alternative, human response to the challenge rather than forcing the installation of a PM  108 . In a preferred embodiment, the challenge requires the completion of a ‘captcha’ task that only a human can easily perform. In a still more preferred embodiment, the challenge asks the sender briefly to indicate the reason for the e-mail in the response, and the receiving PM  107  batches these up in a list of requests periodically presented to the receiving user for their authorisation or denial. In either case, if the sender successfully completes the challenge they are added to the White-list and their pending e-mail delivered as at  609 . 
         [0238]    With the addition of a White-list as described, the use of RMPs is only required for previously unknown senders who wish to avoid the challenge process, such as individuals who send out a lot of ‘first-contact’ e-mail, and organisations sending small-volume marketing material. However, in the long term the White-list process is open to attack by spammers in a number of ways:
       1) Automatic response to captcha challenge—it has been known for attackers to grab the captcha problem, present it to real users in a different context (e.g. for entry to an ‘adult’ website) and use the answer in response to the original challenge.   2) Automatic response to human challenge—spammers may be able to forge legitimate-looking reasons for communication based on (e.g.) website contents.   3) Forged sender addresses using likely known senders—spammers may pretend to be well-known e-commerce services, or correlate addresses within the same domain.       
 
         [0242]    The White-list option is therefore likely to be of most use early in the deployment while PM-enabled clients are relatively uncommon and spammers have not yet caught up. 
         [0243]    In the foregoing, it has been assumed that the user will install PM software  107  on their local e-mail client. This has the advantage of:
       1) Retention of existing e-mail addresses   2) Retention of privacy of communication   3) Distribution of delivery avoiding a central bottleneck       
 
         [0247]    However, many users already choose to use semi-centralised ‘Webmail’ services such as Yahoo! Mail and Google Mail. In this case, in an alternative embodiment of the present invention, the PM functionality may be more efficiently installed as part of the central service. The operation of the PM is identical, except that its interface to the receiving and sending e-mail clients  101 ,  102  will be internal to the Webmail service, and all communication with the user will take place through the service&#39;s normal Web interface. 
         [0248]    Similarly, any organisation with an automated e-mail sending system, such as mailing lists and e-commerce operations, may wish to include the functionality of the sending PM  108  in their e-mail sending systems. They may either purchase RMPs from the PIA as would a normal user, or rely on receivers automatically returning RMPs as previously disclosed. The latter option is likely to be essential for voluntary-operated mailing lists. 
         [0249]    As has already been noted, certain automated e-mail senders may nonetheless be legitimate, such as mailing lists, service updates and order acknowledgements from e-commerce operations. If the automated sender will not or cannot install PM functionality, and the recipient has not placed them on a White-list, then there is no way of their e-mail being delivered. In a preferred embodiment of the present invention, the PIA provides a mechanism of generation of temporary e-mail addresses which are leased by the user and through which e-mail can be received without requiring an RMP to be attached. The user can then use one of these temporary e-mail addresses when subscribing to mailing lists, ordering goods etc. 
         [0250]    In a further preferred embodiment, lease of a temporary e-mail address requires a purchase by means of submitting RMPs of a given value to the PIA. In an alternative preferred embodiment, each e-mail received on the temporary e-mail address requires payment of an RMP by the receiver. 
         [0251]    In a still further preferred embodiment, the temporary e-mail address is automatically deleted as soon as one or a small number of e-mails are received on it, or after a short user-configurable period. In an alternative preferred embodiment, the same benefit is gained by including a sender&#39;s e-mail address on the White-list only until one or a small number of e-mails is received from them, or for a short user-configurable period. 
         [0252]    While the present invention has been described herein through exemplary embodiments, it will be understood that many modifications may be made by those skilled in the art without departing from the true spirit and scope of the Invention.