Abstract:
Whitelists are automatically shared between users and/or domains without compromising user/domain privacy. Potential trust partners with whom to share whitelist data are automatically identified. A handshaking procedure is carried out to confirm the trust relationship and verify the partner&#39;s identity. Once a trust partner is confirmed, the parties can exchange acceptance criteria specifying the types of whitelist data they want to receive. Each party can provide the other with the appropriate entries from its own whitelist. The parties keep each other updated, as their own whitelists change.

Description:
RELATED APPLICATION 
     This application is a Continuation in Part of commonly assigned patent application Ser. No. 11/562,948, filed on Nov. 22, 2006, titled “Time and Threshold Based Whitelisting” (the “Automatic Whitelisting Application”). The Automatic Whitelisting Application is incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     This invention pertains generally to computer security, and more specifically to sharing whitelists of trusted email addresses. 
     BACKGROUND ART 
     Current email systems typically include whitelists of trusted email addresses and domains. An incoming email from a whitelisted entry is presumed to be legitimate, and is therefore delivered to the addressee without being subject to scanning for spam or other processing to check for malicious email. Checking for spam and other security processing consumes both time and computing resources, so it is desirable to be able to bypass it when email is known to be legitimate. 
     Currently available automated whitelisting techniques use very simple mechanisms, such as adding all parties to whom a user sends email to a whitelist. Whitelists created this way often include entries that are not truly legitimate. For example, a user might send an email to a business from whom the user does not wish to receive automatically generated commercial emails. The user might even send an email requesting to be removed from an email list. Clearly, in situations such as these, the user does not want the recipient added to the whitelist. These currently available simple whitelisting mechanisms also lead to the creation of very large whitelists that are typically very difficult and time consuming for users to manage. This problem becomes much worse when these simple mechanisms are applied for multiple users at a gateway or domain level. 
     The Automatic Whitelisting Application describes methodologies that a local client or gateway can use to better manage whitelists, by using time and threshold based values to automatically promote provisional whitelist entries to permanent status. The Automatic Whitelisting Application also discusses using a threshold to promote an entire domain to permanent status, such that an email from anyone at a whitelisted domain is accepted as non-spam. 
     The invention of the Automatic Whitelisting Application is very useful, but lacks a mechanism for establishing associative trust that could allow quicker provisional promotion for “friend of friend” senders. What is needed are methods, computer readable media and computer systems for automatically sharing whitelist data between users or domains while at the same time maintaining privacy at a user/domain level. 
     SUMMARY 
     Whitelists are automatically shared between users and/or domains without compromising privacy. Potential trust partners with whom to share whitelist data are automatically identified. A handshaking procedure is carried out to confirm the trust relationship and verify the partner&#39;s identity. Once a trust partner is confirmed, the parties can exchange acceptance criteria specifying the types of whitelist data they want to receive. Each party provides the other with the appropriate entries from its own whitelist. The parties keep each other updated, as their own whitelists change. 
     The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating the operations of a whitelist sharing manager, according to some embodiments of the present invention. 
         FIGS. 2-6  are flowcharts illustrating steps that a whitelist sharing manager executes, according to certain embodiments of the present invention. 
     
    
    
     The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a whitelist sharing manager  101 , according to some embodiments of the present invention. It is to be understood that although the whitelist sharing manager  101  is illustrated as a single entity, as the term is used herein a whitelist sharing manager  101  refers to a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a whitelist sharing manager  101  is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as a kernel loadable module, as one or more device drivers or as one or more statically or dynamically linked libraries. 
     As illustrated in  FIG. 1 , the operations of the whitelist sharing manager  101  enable the exchange of associative trust information  102  (e.g., whitelist entries) with trust partners  103  (e.g., other emails servers, gateways, domains, etc.) without compromising email whitelist  105  privacy. This is accomplished by automatically recognizing potential trust partners  103   potential , and exchanging whitelist content  102  therewith based on an established level of cooperation. The whitelist sharing manager  101  automatically identifies potential trust partners  103   potential , according to the methodology disclosed in the Automatic Whitelisting Application. It is to be understood that as discussed in the Automatic Whitelisting Application, a potentially trusted party  103   potential  can be in the form of an individual email user, an email server, an email gateway, or an entire domain as desired. 
     Whenever a potential trust partner  103   potential  is identified, the whitelist sharing manager  101  adds it to a list  107  of trust partners with an initial status  108  of “outbound provisional.” If the potential trust partner  103   potential  is already on the list  107  with a status  108  of “inbound provisional” (inbound provisional status  108  is discussed below), the status  108  of the potential trust partner  103   potential  is up graded to “two-way provisional.” At the time a potential trust partner  103   potential  is added to the list  107  (or upgraded in status  108  to “two-way”), the whitelist sharing manager  101  sends an initial “hello” notification  109  to the potential trust partner  103   potential . This notification  109  is received and processed by the whitelist sharing manager  101  of the potential trust partner  103   potential  as discussed below. 
     When a whitelist sharing manager  101  receives a “hello” notification  109 , it adds the sender  103   potential  of the notification  109  to its trust partner list  107  with a status  108  of “inbound provisional.” If the sender  103   potential  was already on the list  107  with an “outbound provisional” status  108 , its status  108  is upgraded to “two-way provisional.” When a sender (a form of potential trust partner  103   potential ) is added with “inbound provisional” status  108 , the whitelist sharing manager  101  sends them a response notification  111  specifying that the trust is only one way. If the sender  103   potential  was already on the list  107  as “outbound provisional” and is upgraded in status  108  to “two-way provisional,” the response  111  informs the potential trust partner  103   potential  that the potential trust relationship is now two-way. 
     By sending hello and response notifications  109 / 111 , whitelist sharing managers  101  can both prove their own authenticity and confirm that the other party is in fact whom it claims to be. When a message  109 / 111  is received from a potential trust partner  103   potential , the receiving party can check the message  109 / 111  for authenticity using DomainKeys, Sender Policy Framework (“SPF”) or a similar verification service. If the authenticity of the message response checks out, the status  108  of the trust partner is upgraded from “provisional” to “confirmed” (e.g., inbound provisional to inbound confirmed, or two-way provisional to two-way confirmed). 
     It is to be understood that the exchanges of notifications  109 / 111  and various provisional status  108  states are a form of handshaking, in which the parties engage to determine whether they wish to share whitelist information  102 . Once a partnership reaches the status  108  of “two-way confirmed,” actual sharing can occur. At this point, either trust partner  103   confirmed  may issue an indication  113  to the other specifying what associative data  102  (i.e., entries whitelisted by the other partner  103   confirmed ) it would like to receive and add to its own whitelist  105 . The parameters specifying what associative data  102  to accept can be configured by, e.g., the domain or system administrator. These parameters can also be seeded with default criteria. What whitelist data  102  to accept from a confirmed partner  103   confirmed  is a variable design parameter, and can be based on factors such as how long the entry  102  has been on the partner&#39;s  103   confirmed  whitelist  105  with provisional and/or permanent status, the length of the trust relationship with the partner  103   confirmed , the percentage of emails from the entry  102  reported as spam (if available), specific individual email addresses and/or domain entries, etc. In some embodiments, a party can simply accept the entire contents  102  of the whitelist(s)  105  of one or more trust partners  103   confirmed . Often, a party only accepts a subset of the whitelist entries  102  of trust partners  103   confirmed , according to its acceptance parameters. 
     A trust partner  103   confirmed  transmits to its other partner  103   confirmed  its own whitelist entries  102  that meet the specified acceptance criteria of that other partner  103   confirmed . As a party receives such associative whitelist entries  102 , it adds them to its own whitelist  105 . As additional whitelist entries  102  meet the acceptance criteria specified by the other partner  103   confirmed  and/or existing entries  102  cease to, the partners  103   confirmed  send up dates  115  to each other indicating these changes. These updates  115  can be transmitted at a default update frequency or one specified by the receiving partner  103   confirmed . Thus, the initial transfer of whitelist data  102  contains the bulk of the whitelist entries, and follow-up notifications  115  only contain additions and removals therefrom. If a party&#39;s  103   confirmed  whitelist data  102  has not changed with respect to its partner&#39;s  103   confirmed  specified criteria, the party  103   confirmed  still typically transmits “no-change” notifications  115  at the specified intervals. 
     In some embodiments, if a party  103   confirmed  fails to receive a configured or default number of consecutive interval notifications  115  (e.g., three) from a partner  103   confirmed , the party  103   confirmed  drops its trust relationship with that partner  103 , and removes all corresponding associative trust entries  102  from its own whitelist  105 . When a trust relationship is dropped, the dropping party  103  issues a “drop” notification  117  to the other partner  103 . When a “drop” notification  117  is received, the receiving partner  103  changes the status  108  for that partner  103  back to “outbound provisional” or “outbound confirmed” (instead of “two-way”). The receiving partner  103  also stops transmitting change notifications  115 . 
     To maintain privacy, whitelist entries can be shared via MD 5  (or similar) hashes. Notifications and other communication can be conducted between partners  103  via standardized emails, or other formats as desired. Exchanges can occur between standardized accounts configured for this purpose, such as, e.g., AssocTrustMaster@domain.xyz or the like. Lastly, any email received that doesn&#39;t authenticate via DomainKeys, SPF or the like is typically ignored. Thus, in some embodiments the associative trust exchange requires both parties to support DomainKeys, SPF or a similar service. 
       FIGS. 2-6  are flowcharts that illustrate steps that a whitelist sharing manager  101  can execute in order to identify and confirm trust partners  103 , provide shared whitelist content  102  to confirmed partners  103   confirmed , issue and process change (update) notifications  115 , and drop partners  103 . It is to be understood that these flowcharts simply illustrate examples of the execution of such steps according to some embodiments of the present invention. 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, notifications, statuses and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, notifications, statuses and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Furthermore, it will be readily apparent to those of ordinary skill in the relevant art that where the present invention is implemented in whole or in part in software, the software components thereof can be stored on computer readable media as computer program products. Any form of computer readable medium can be used in this context, such as magnetic or optical storage media. Additionally, software portions of the present invention can be instantiated (for example as object code or executable images) within the memory of any programmable computing device. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.