Abstract:
An e-mail handling system, wherein e-mail messages are entered, transported and stored, comprises a central key repository, means for encrypting a message using a key associated with the message, means for adding the key to the central key repository; and means for deleting the key for a message when the message is to be made unrecallable.

Description:
BACKGROUND OF THE INVENTION 
   The present invention relates to the field of e-mail systems. More specifically, one embodiment of the present invention provides a facility for easily controlling e-mail communications. 
   E-mail is an increasingly popular form of communication. One reason for this is that a sender can simply type in a message and press a button to have the email message sent to the recipient. Typically, the recipient receives the message, reads it and deletes it. E-mail drafters often assume, given the ease at which e-mail can be created, sent and read, that e-mail is a disposable, “off-the-record” communication. However, as currently practiced, e-mail messages are “on-the-record” communication since copies of e-mail messages may remain in the computer system used to convey the e-mail messages, and form a possibly permanent record subject to later scrutiny. In contrast, nearly all telephone conversations and face to face conversations are off-the-record. With the conversation being off-the-record, the participants can speak freely and informally, without worrying about their statements later being taken as polished, well thought out statements that can be later questioned. This on-the-record nature of e-mail and the continued existence of a copy of a message permits its examination under subpoena and risks its accidental exposure to unauthorized persons, either of which might embarrass the writer. Even when the writer believes that the message has been deleted, various system copies might still exist which may cause the same problems. 
   From the above it is seen that an improved e-mail handling system is needed. 
   SUMMARY OF THE INVENTION 
   An e-mail handling system, wherein e-mail messages are entered, transported and stored, comprises a central key repository, means for encrypting a message using a key associated with the message, means for adding the key to the central. 
   A further understanding of the nature and advantages of the inventions herein may be realized by reference to the remaining portions of the specification and the attached drawings. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  illustrates a network over which the present invention could be used. 
       FIG. 2  is a block diagram showing the mail server of  FIG. 1  in further detail. 
       FIG. 3  is an illustration of the structures of a key table and a message table used as part of one embodiment of a mail system according to the present invention. 
       FIG. 4  is a schematic of one entry in the message table shown in  FIG. 3 . 
       FIG. 5(   a ) is a flowchart of a process for creating a message in one embodiment of a mail system according to the present invention. 
       FIG. 5(   b ) is a flowchart of a process for reading a message in one embodiment of a mail system according to the present invention. 
   

   DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1  is a block diagram of a computer system  10  in which the present invention might be used. Computer system  10  is shown including several client computers  12  coupled to a mail server  14  via a network  16 . In this example, the network connecting the clients and server can be a local area network, a wide area network or the Internet, a global internetwork of networks in common use today to connect clients and servers. 
     FIG. 2  shows mail server  14  in further detail. A network interface  22  provides for communication between a processor  20  and network  16 . Within mail server  14 , processor  20  is coupled to a random access memory  24  and a program memory  26  containing program code that controls the operation of processor  20  (and thus mail server  14 ). Processor  20  is also coupled to storage  28 , which serves as permanent storage for data. Storage  28  is “permanent” in that the data stored thereon persists even if mail server  14  is not powered up or operating. Although storage  28  is shown as being internal to mail server  14 , it should be understood that the invention does not require internal storage and many other types of storage could be used instead, such as an external file server or hard drive. 
   Storage  28  is shown with areas allocated to a message table  30 , a key table  32  and other data  34 . The structure of key table  32  and message table  30  is shown in greater detail in  FIG. 3 . In this example, key table  32  has multiple key entries and message table  30  has multiple message entries, with each table having fixed length entries with a correspondence between key table entries and message table entries. As shown, the message contents are stored separately, with pointers from the message table entries to message contents. This allows the message table entries to be fixed length without constraining the messages to be fixed length. Each entry in key table  32  holds a key value and is associated with a particular mail message ID. Some of the keys, such as the key for entry  36 , might be deleted, as explained below. Some key table entries, such as entry  38 , are designated “no key” to indicate that no key is needed to read the corresponding message. 
     FIG. 4  shows the structure of one example of a message table entry  40 . That message table entry  40  includes fields for: a mail message ID, an OTR (“off-the-record”) flag  41 , a mail creation date, a mail expiration date and a pointer to the mail message contents. A message table entry might also include other fields not shown. The OTR flag  41  is used to indicate whether or not the message is an “off-the-record” message or a regular message. If the OTR flag is set (value=“1”), the message is an “off-the-record” message subject to being “shredded” when the corresponding key is deleted from key table  32 . In either case, a message might be stored on mail server  14 , but if the OTR flag is set, the message contents is encrypted and the key is needed to decode the message. The message contents might be found in more than one location. For example, if each mail client stores a local copy of the message, each recipient would have a copy of the message and each backup made of the sender&#39;s computer, the mail server and the recipient clients could have a copy of the message. However, since the message is encrypted everywhere, the key is needed to read any copy of the message, and the key is not backed up with the message. 
     FIG. 5(   a ) illustrates a process of creating a message that is to be an off-the-record message. A mail client accepts input of the message (by a human user or a computer) and creates a data structure in the format desired by the mail client (step S 1 ). The mail client then requests a mail ID and a key from the mail server (S 2 ). The key is stored in the key table and a corresponding message entry is created in the message table (S 3 ). The contents of the mail are encrypted and the clear text of the message is discarded (S 4 ), and those steps can be done at the mail client or the mail server, taking into account the computing capabilities of each and the security available to prevent snooping of the clear text. Any suitable encryption could be used, such as triple-DES, to encrypt the messages. Once the message is encrypted, it can be sent (S 5 ) and/or stored at the mail server. 
     FIG. 5(   b ) illustrates a process of reading a mail message. Once a user makes a request to read a message, the mail reader determines the mail ID of the message to be displayed (S 11 ). The mail reader then checks the message table to determine if the OTR flag is set (S 12 ). If the OTR flag is not set, then the message is stored in unencrypted form and it is presented to the user (S 13 ). That completes the reading process for non-OTR mail. 
   For OTR mail, the mail reader requests a key from the server for that ID (S 14 ). The key server can be part of the mail server or a separate computer. If the key is not available (S 15 ), the server reports the unavailability to the mail client, which displays an error (S 17 ). If the key is available, the mail reader uses the key to decrypt the message and present it to the user (S 16 ). 
   The key handling can be entirely transparent to the sender of a message and to the recipient or reader of the message. When a sender decides that a message is no longer needed, or when an expiration time is reached, the key for that message is deleted from the key table, rendering all the various copies of the message unreadable, wherever they happen to be stored. Because of this, senders can use e-mail messaging for off-the-record comments, knowing that each encrypted copy of the message would be, effectively, shredded wherever the message happens to be. 
   The key table can be used in a simple message purge process. In that purge process, the processor or program responsible for message storage examines the key table and each place an OTR message has a deleted key, the encrypted message associated with that deleted key is removed from the system. Preferably, the keys are not backed up with the messages. If the keys are backed up at all, preferably the backups are reviewed so that a key deleted from the mail server is also removed from the backups. 
   In a higher security environment, special controls can be placed on the machine that manages the key table to prevent compromise of the key table. However, not as much control need be placed on the machines that are maintaining copies of messages and making copies of messages, because those messages are encrypted. 
   The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.