CA2389472A1 - Method for filtering email spam - Google Patents

Abstract

Software and system that provides an effective means of limiting Unsolicited Commercial Email (A.K.A. "spam") without the risk of blocking legitimate email and without the need for the user to configure complex software, write filtering rules, maintain lists of email addresses, or change the way they currently retrieve, read, compose and send email. The invention includes a central database called the "Registry" that contains information about email addresses that is provided directly and indirectly by the senders and receivers of email messages and that is derived from the process of users sending and receiving email messages; a centralized collaborative rating process that uses information contained in the Registry to evaluate and rate each email address; an email "ratings server" that contains rating values for email addresses; and "filtering software" that filters email messages based on the users preferences and currently assigned address rating values provided by the ratings server.

Description

I i~,ll I ~I, I 1l BACKGROUND OF THE INVENTION
15 Electronic mail (more commonly referred to as "email") has introduced an extremely low cost means for people to communicate with others around the world using the Internet. However an unfortunate side effect of this new, low cost communications medium is the distribution of electronic marketing messages commonly known as "spam" or ' junk email".
More properly referred to as Unsolicited Commercial Email ("UCE") or Unsolicited Bulk Email 20 ("UBE"), spam includes any unsolicited or unwanted email message that is sent to Internet users.
Such unsolicited email is often sent to millions of email addresses at the same time, and often from a single email address that is valid for only a short period of time.
Many people consider spam as more than just a nuisance as it in effect 'steals' resources from businesses, Internet Service Providers ("ISP's") and individuals. Resources most affected by spam 25 theft include: l.) bandwidth that is lost handling unwanted email; 2.) time that is lost by employees sorting and deleting spam; 3.) computing resources that are consumed by ISP's and businesses trying to identify and filter spam, etc.

I<.L I,G. ~ l~ I . II ~ , Spain also increases the risk of accidentally deleting or overlooking important messages while sorting spam from legitimate messages. Spain frequently contains objectionable, fraudulent, or 30 dangerous content, such as pornography, illegal pyramid schemes and other financial scams.
Even more significant is the increased security risk that spam represents as it is commonly used to distribute destructive viruses, software code (Java applets, JavaScript, ActiveX, etc.) and worms, which are included in the email message either as attachments or active content, that when opened can wreak havoc on the users computer by deleting files, modifying information, turning off security 35 protocols, and so on.
Consequently, there is a need for an effective method that automatically identifies and controls the delivery of unwanted email to users' in-boxes, without impacting the users normal email processes and without any possibility of inadvertently labeling legitimate email as spam.
DESCRIPTION OF PRIOR ART
40 Previous attempts in the prevention of spam have included: 1.) scanning each incoming email message for key words and phrases that are typically found in spam message;

2.) preventing the delivery of email messages from specific Internet domains and IP addresses that have been identified as sources of spam email; 3.) limiting email messages to specific email addresses (whitelisting), and; 4.) limiting email messages from specific email addresses (blacklisting). The 45 most advanced filtering methods often use a combination of the above techniques backed up with a human review process.
B~ f~' the most common spam control technique is scanning 'each incoming email message for 'key ' words or phrases that are typically found in spam messages. More sophisticated products use fuzzy logic and a scoring system to try and detect spam. Simpler products simply use a list of known 50 words and phrases to try and filter out spam messages. In all cases this approach to filtering seam suffers from two major problems. The first is the potential of misidentifying a legitimate message as spam, representing a serious risk for business users if the filter accidentally deletes an important email message. And the second is the need to download the entire email message from the Email Service Provider ("ESP") before it can be determined if the message is spam or not, thereby wasting 55 expensive bandwidth and computing resources on sparn.

Domain and IP level filtering techniques are commonly use by ISPs, ESPs and commercial users who often rely on lists of known sources of spam email that are compiled and maintained by non-profit organizations such as the Mail Abuse Prevention System ("MAPS"). MAPS
maintains and operates the Realtime Blackhole List ("RBL") - a list of known networks that allows spammers to 60 send unsolicited email messages. While domain and IP fihering can be very effective in blocking unwanted spam, they often inadvertently block legitimate email messages from individuals and organizations that are part of the blocked domain or IP address.
Whitelisting and blacklisting of email addresses are also commonly used spam-filtering techniques typically incorporated into the software that allows the user to compose, send, retrieve and read 65 email. Additionally there are third party add-on programs that offer the user the ability to create email address filtering lists. Whitelisting does work reasonably well, but requires the user to continuously maintain their list of email addresses that they wish to receive ema.il from. Blacklisting on the other hand has proven to be a relatively ineffective technique as the senders of spam messages often use a different (and often invalid) reply addresses for every piece of email they send 70 out, making it virtually impossible to keep a blacklist up-to-date.
Very advanced filtering systems use a mufti-pronged approach to filtering email backed up by a human review process and have proven to be very effective. However they are very expensive to implement and operate and are usually well beyond the reach of individuals and smaller ISPs, ESPs and businesses.
75 Therefore it is the objective of the present invention to provide an effective, low cost means of limiting spam email without the risk of blocking legitimate email, and without the need for the user to change their email handling procedures or behavior, maintain complex software, write and maintain word/phrase filtering rules, or create and maintain whitelists and blacklists of email addresses.

In accordance with the present invention, a centralized "Registry" (201) maintains a database (206) of email addresses, which are provided either by the Senders of email messages (100) using an email registration process (208), or by an email proxy ( 102, 302) in instances where an email proxy ( 102, U i; U r ~ ; ~i 302) has submitted a request to a "Ratings Server" (202) for a rating for the email address and the 8S address has not yet been registered by the owner, or in instances where a user of the email proxy software ( 102, 302) has added the email address to their personal list of email addresses that they will always accept email from (the "GOlist"), or their personal list of email addresses that never want to receive email from (the "STOPIist").
Each email address maintained by the Registry is assigned a spam rating value (20S) using a rules 90 driven, Collaborative Rating Process ("CRP") (204). Rules are collaborative in nature in that they use information that is provided directly and indirectly by the senders and receivers of email messages along with operational information that is derived from the process of users receiving email messages when they have the email proxy software (302) installed on their computer.
Assigned rating values are in turn sent to an email address ratings server (202) which are in turn 9S used by a filtering process (303) that is part of the email proxy software (302) that is installed on the users computer (300) and that uses the currently assigned spam rating value and the users preferred filtering settings to determine whether an email message should be delivered to the users email software (301) or if the message should be detained by the proxy as possible spam. (306) BRIEF DESCRIPTION OF THE DRAWINGS
100 FIG. 1 is a schematic diagram showing the main components of the present invention;
FIG. 2 is a detailed schematic diagram that shows the functionality of the present invention;
FIG. 3 is a fimctional block diagram of the preferred embodiment of the present invention;
FIG. 4 is a flow diagram that describes the installation of the proxy software onto the users computer;
lOS FIG. S & 6 are flow diagrams that describe the email address registration process;
FIG. 7 is a flow diagram that describes the use of an optional GOhst;
FIG. 8 is a flow diagram that describes the use of an optional STOPIist;

I~ I, II I .L i FIG. 9 is a flow diagram that describes the process of updating the registry with information from GOlists and STOPlists;
110 FIG. 10-12 are flow diagrams that describes how the proxy retrieves and uses address ratings from the rating server to filter email for the user, and;
FIG. I3 is a flow diagram that describes the email address registration process.
DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 is a schematic diagram representing the three main components of the fully fimctional spam 115 filtering process, including the Sender (100) the Email Rating Service (200) and the Receiver (300).
The Sender wants to send email to the Receiver. The Receiver wants to ensure that the email being sent is not spam. The Email Rating Service provides email address rating information to the Receiver. The Receiver in turn uses this information to determine if the email sent by the Sender may be spam and takes the appropriate action.
120 It should be noted that the role of the Sender (100) and Receiver (300) may be reversed. In addition Senders and Receivers could represent individuals or other entities such as a business, ISP or ESP. It should also be noted that the sending or receiving systems may be a personal computer ("PC") or a server used to queue, send, receive and hold email. It should also be noted that there may be one-to-one, one-to-many and many-to-one relationships between Sending and Receiving systems.
125 FIG. 2 is schematic diagram that provides a more detailed overview of how the filtering process . .. . .works. wets begin with the sender (1.0U).who wishes to send an email message to the receiver. (300) The sender composes the message using their preferred email software (101) and sends the email message via the Internet (1) using their preferred ESP. The email message is routed by the Internet (2) to the receivers ESP where the message is held until the receivers email proxy asks the ESP for 130 the header portion of all the email messages that are waiting to be delivered to the receiver. (4,3) (The "header" portion of an email message contains the postal information of the message, such as the recipient, the sender, the subject, etc. Headers also contain message routing instructions and other technical information that is used to direct an email message to its destination.) Normally the receivers preferred email software downloads the entire email message from the receivers ESP, but 135 if the receiver has installed the email proxy software (302) onto their system, then the proxy (302) manages the retrieval of the receivers email on behalf of the receivers email software.
Once the proxy has downloaded the email headers from the ESP (2,5) it parses out the senders email address and if the user has created a GOlist or STOPlist, compares the email address to email addresses that are on the users GOlist and STOPlist. If the email address is in the users GOlist, then 140 the proxy sends a request to the ESP to download the entire message (5,3,2,4) and then passes the message on to the receivers preferred email software program. If the email address is in the users STOPlist, then depending on how the receiver has configured the proxy software (302), the proxy either deletes the message header from the receivers computers and instructs the ESP to delete the entire email message from it's server, or it places the message header in a "detained" list of email 145 messages so that the receiver can review the message header information at their leisure and decide if they want to retrieve the entire message from the ESP, or delete the message without ever reading it. The definition and use of GOlists and STOPlists by the receiver is totally optional and are only provided as a convenience and an added level of filtering control for the receiver. GOlists and STOPlists ARE NOT required for the filtering process to work effectively.
150 If the email address is not on either the receivers GOlist or STOPIist, then the proxy sends a request via the Internet (4,6) to the address Rating Server (202) for the current spam rating of the email address. If the address has been assigned a rating value, then the address Rating Server forwards the address rating back to the receiver's proxy (302) via the Internet (7,5). The receiver's proxy then uses the rating provided by the address Rating Server to determine what to do with the message. If 155 the returned rating is higher then the minimum required rating set by the receiver for delivery of the message~to the receiver's i~bax:~hen the message header is placed.~n the receiver's detained list of messages (306) so that the receiver can review the message header information at their leisure and decide if they want to retrieve the entire message from the ESP, or have the message deleted.
Additional processes can be provided that will result in the email headers being automatically 160 deleted from the detained message list (306) if the receiver takes no action after a preset period of time.
If the returned rating is lower then the minimum required rating set by the receiver for delivery of the message to the receiver's inbox, then the proxy sends a request to the ESP
to send the entire ., . a! ~, U V. , p, i fl email message to the proxy. (4,2,3,5) After the entire message has been retrieved by the proxy, it is 165 then automatically forwarded to the receivers preferred email software.
If however the address Rating Server returns a value that indicates that the senders email address does not have an assigned rating value, then the receivers proxy places the email headers into the receivers detained list (306) and auto~tically sends a pre-composed email message to the sender vial the Internet (4,8) on behalf of the receiver. The pre-composed email message will typically 170 include a personal message from the receiver as well as information that the sender will need to register their email address with the Registry (201 ) before their email will be delivered to the receiver. (300) The registration information included in the email message will direct the sender of the original email message to a web based email registration process ( 1,10) (208) that will ask the sender for the email address they wish to register and what kind of email will be sent using that 175 email address. To-protect the privacy of the sender no other information other than the email address and what the address is used for is requested by the email address registration process. To prevent spammers from automatically registering hundreds or even thousands of email addresses from which they could send spam, the web-based registration process includes a non-machine readable tag that the registrant must manually enter into the registration form. As a further anti-spam deterrent, all 180 address registration requests must be verified by the address owner using a double opt-in process, wherein the registration request is verified by emailing a confirmation message to the provided email address requiring the address owner to respond to the registration request by entering a randomly generated registration code that is included in the registration confirmation email message into a web-page so that the registration process can confirm that the email address is valid, and that 185 the owner of the email address does indeed wish to have the address registered. As an alternative method to keying in ~a randomly generated code, the email rriessagecould inolude' a URL that includes a randomly generated code. When the user goes to the URL with their browser the coded URL will confirm to the registration process that the email address is valid and that the address owner wishes to have the address registered.
190 Once the registration process is completed, then the Email Rating Service (200) will assign a rating value to the email address using a rules driven, Collaborative Rating Process ("CRP") (204). The CRP uses information accumulated about each email address that may include (but is not limited to):
1.) when the email address was registered; 2.) the number of rating requests received for each email _7_ address; 3.) the date and time that each rating request was made for the email address; 4.) the 195 number of GOlists and STOPlists that the email address is currently on;
5.) the number of spam complaints received about the email address; 6.) the type of email that the email address has been registered to send (personal mail, newsletters, opt-in email, email based discussions, etc.); 7.) the IP
address that the email address was registered from; 7.) the HTTP header information recorded from the address owners browser when they confirmed their registration request; 8.) how the email 200 address was added to the Registry, i.e.: by the address owner or from a GOlist or STOPIist; 9.) the history of rating changes for the email address, and ; 10.) the header information from received email messages, etc. In the case of a newly registered email address the amount of information available is somewhat limited for that address, so the rating value assigned by the system may reflect that lack of information.
205 Email addresses may be included in the Registry (201) even if they have not been registered by the address owner. An address can be added to the Registry when a proxy makes a request for an address rating and the address has not been previously entered into the Registry. It can be added to the Registry when a proxy user adds the email address to either their GOlist or STOPIist. Or it may be added as the result of someone complaining about receiving spam email from the email address.
210 In all instances, email addresses that have not been registered by the address owner are processed by the CRP and assigned a rating that can be used by the receiver's proxy to filter email sent to the receiver.
Once the CRP has determined and assigned a rating for the email address, the email address and associated rating value is passed (9) to the Address Rating Server ("Rating Server") (202). The next 21.~~- time ~ that the r~eive~rs proxy checks for a rating assignment for email addresses of messages that have been placed in the detained list, (306) then Rating Server returns the newly assigned rating and the proxy determines how to handle the email message based on how the receiver has configured their filtering preferences.
FIG. 3 is a functional block diagram of the preferred embodiment of the system as shown in FIG. 1 220 and 2. In this embodiment each of the Sending (100) and Receiving (300) system includes a Message Filtering Module (103, 303), Configuration Module (104, 304), Address Management Module ( 105, 305), Detained Messages Module ( 106, 306), and Registration Request Module ( 107, _g_ ~, ~~~ wi b : ~n i wi 307), all of which may communicate with each other within the proxy software.
In the preferred embodiment each of the modules are implemented as software, but can also be implemented as 225 hardware and/or firmware. Examples of sending and receiving systems ( 100, 300) include desktop computers, portable computers, servers, PDAs, wireless devices and other digital devices.
The Email Rating Service (200) includes the email Registry (201) and the Ratings Server (202).
The email Registry (201) includes the following modules: Collaborative Rating Module (204), Ratings Maintenance Module (205), Address Information Storage (206), Email Registration Module 230 (208), Client Registration Module (209), Messaging Module (210), and the Administration Module (207). All of the email Registry modules may communicate with each other. In the preferred embodiment each of the modules are implemented as software, but can also be implemented as hardware and/or firmware. An example of an implementation of an Email Registry (201) would include server software running UNIX, Linux, Windows NT/2000/XP or Sun Solaris systems.
235 The system outlined in Fig. 3 generally operates in a manner descn'bed by the flow charts illustrated in Fig. 4 to Fig 13, which will be described below.
Turning now to Fig 4., the filtering process begins with a user who wants to reduce or eliminate the volume of spam that they receive. They may learn about this new registration based filtering process from friends and acquaintances who have already installed the proxy onto their personal computers, 240 or from a registration request message that they received from a user of the proxy software (102, 302) that they have sent an email message to. As a result they decide that they would like to try the filter and download the software from any one of the many software distribution hubs on the Internet; or directly 'from the Email Rating Service's own website ''~
During the installation process (405) the user will be asked to provide their email address to confirm 245 that the address has been properly registered with the central Registry.
(201) (410) To determine the current registration status of the users email address, the installation process sends a registration confirmation request to the Registry. (201, 210) (415) If the email address has not been registered by the address owner, then the Registry (201, 210) returns a not registered message and the installation process directs the user to the registration website that is part of the email registration module. (208) 250 (450) While the user is not required to complete the entire double opt-in registration process before .. . ~i.h~-u..~:: ~~ 1 they can finish installing the proxy software, (102, 302) they are required to initiate the registration process by completing and submitting the email address registration form.
After the user has initiated the email registration process the installation of the proxy software (102, 302) continues.
(425) After the software has been installed a registration process (430) is initiated that includes 255 sending a GUID ("Globally Unique Identifier") that was generated during the installation process to the Registry (201) uniquely identifying each installation of the software.
Additional information about the user of the software may also be gathered and sent to the Registry (201). Once the proxy ( 102, 302) has been registered, the installation process (435) continues with the user being provided with the option (440) to configure the software ( 104, 304) using a step-by-step wizard style 260 configuration process, (445) or an advanced software configuration process. (455) Figs. 5 & 6 provides a detailed flow diagram describing the email address registration process. The process begins when a person is directed to a web page that contains an email address registration application form A person may be directed to this form during the course of installing the proxy software ( 102, 302) (400); as the result of receiving a registration request message from a proxy 265 filter (303) ( 1000); as the result of visiting the Email Rating Service's website (200) and learning about the email registry service (201); by being referred by other users of the service, or; simply as the result of conducting web based searches of the Internet in search of spam filtering solutions.
Since spammers typically use invalid and randomly generated email addresses in the "From" and "Reply-To" fields of the message header, the process to register an email address is designed to only 270 allow one valid email address to be manually registered at a time, with each ema,il address validated using a double opt-in process that requires the address owner to respond to an email message sent to ~: registered address by going to a wela~page and providing a randomly generated registration code that was included in the email message. A complete description of the entire process follows.
Each registration page is automatically generated on demand by the web server and includes: 1.) a 275 non-machine readable registration code (typically in the form of a graphic image) that includes a randomly generated series of alphanumeric characters (506); 2.) a field for the user to enter the email address that they wish to register, and; 3.) a selection of radio buttons that allows the user to choose one option that describes the "type" of email that is typically sent using the entered email address. Email types may include (but are not limited to): 1.) Personal email messages -- low a; ~. 1l G ~ ~I

280 volume personal and business email messages sent by a single person to friends, acquaintance or business associates; 2.) opt-in email messages -- bulls email that is sent to individuals who have agreed or "opted" to receive unscheduled or scheduled promotional or informational email from the owner of the email address; 3.) discussion list messages ("ListServs") --email that is sent to individuals who have subscribed to receive emails of messages posted to a discussion list by other 285 subscn'bers the list; 4.) regularly scheduled information services --email messages that are sent to individuals who have agreed (either directly or indirectly) to receive email messages from the email address owner at some pre-defined regular interval. Examples would include monthly newsletters, scheduled service status reports, monthly billing notices, etc., and; 5.) irregularly scheduled information services -- email messages that are sent to individuals who have agreed (either directly 290 or indirectly) to receive email messages from the address owner at random and un-scheduled intervals. Examples would include occasional newsletters, unscheduled service status reports, appointment reminder notices, etc.
After the user has completed and submitted the email address registration application page, the process continues by comparing the non-machine readable registration code entered by the user with 295 the value represented by the graphically displayed alphanumeric code.
(512) If the entered code does not match the graphically displayed alphanumeric code, then the process checks to see if the user has attempted to register the same email address with an incorrect registration code more than x times, where x is an integer equal to a value set by the system administrator.
(207) (527) If the user has attempted to register the same email address with an incorrect registration code less than x 300 times, then the process displays a registration failure message and a new, blank registration application page is generated with a newly generated non-machine readable registration code. (524) If the user has attempted to register the same email address vs%ith an incorrect registration code more '~"
than x times, then the process displays a registration failure message and advises the user that they will not be able to re-attempt registering that particular email address for a random period of time 305 and returns the user to the main page of the website. (530) The objective of this process is to prevent a user from designing automated email address registration processes.
If the entered registration code does match the graphically displayed alphanumeric code (512) then the process continues by checking to see if the email address has already been registered. (515) If the email address has already been registered, then the process displays a message advising the user . . 1-~-I~:~ : ~ I II . -310 that the email address has been registered (533) and asks the user if they would like to register a different address. (536) If an application to register the email address has already been submitted, but the email address has not yet been "validated" (518) (the address owner has confirmed that they wish to have the email address registered), then a message is displayed (521) telling the user that the address has already been submitted for registration but has not yet been validated by the address 315 owner. The user is then asked if they would like to have another registration confirmation email message sent to the email address. (560) If the email address has not been registered and there is no application for registration on file, then the system creates a randomly generated alphanumeric code that is saved with the email address in the Registry's database (206). In one embodiment of the invention the code and the email address 320 are encrypted and included in a coded web page URL. The URL is then emailed to the address that was entered on the registration web page. (542) When the owner of the email address receives the message they are instructed to click on or cut and paste the URL into their web browser. The web page that the URL points to includes a server-based, automatic process that extracts the randomly generated alphanumeric code and encrypted email address from the URL and compares them to the 325 information that was saved in the Registry database (206) when the application for registration was submitted. If both the alphanumeric code and email address from the URL match the alphanumeric code and email address in the Registry database, (206) (551) then the address has been confirmed as valid and recorded as fixlly registered by the address owner (572) in the Registry database. (206) If the email that was sent to the email address provided during the application process bounces 330 (returned as an invalid address), (548) then the database (206) entry for that email address is flagged . ~. ;., ~ : as invalid. (569) If more than x.days, where x is equal to an integer value configured by. the system administrator (207) elapses without a response from the address owner, (554) then the database (206) entry is updated to indicate that the validation process failed due to a lack of response from the address owner. (557) 335 Once the email address has been validated by the address owner and added to the Registry database (206), (572) the address is then added (575) to the rating queue (205) (1600) for evaluation and a spam rating assignment. After the address has been evaluated and rated it is then added (578) to the ratings server (202). If the owner of the address requested that they be advised of the rating assigned i, ;, ~o i~ . ~~ . ~~

to their submitted email address, then the process will conclude by preparing and sending an email 340 message with the assigned rating value (581) and explanation of what the rating means to the email address owner.
Fig. 7 descn'bes the process that a user would use to create and maintain a personal GOlist. A GOlist is a list of emaal addresses that the user is prepared to always receive email from. This could include friends, relatives, business associates, customers, etc. The creation and use of a personal GOlist is 345 completely optional and simply provides the user with more control over what email is delivered to their inbox. In the preferred embodiment of the invention the user can choose to create or add email addresses to their personal GOlist using an import fimction (610) that will allow the user to import email addresses from existing address books, text files, databases, or from another users GOlist.
(635) Alternatively, (615) they could simply manually add email addresses to their personal GOlist.
350 (640) Additional options (620, 625) are provided that allows the user to manually edit (645) and delete (650) email addresses from their personal GOlist. All GOlist adds and edits are evaluated (630) to ensure that none of the email addresses appear in both the users GOlist and STOPlist. If the same address appears in both lists, then a process is started that allows the user to resolve the conflict. (655) 355 Reciprocally, Fig. 8 descn'bes the process that a user would use to create and maintain a personal STOPlist. A STOPlist is a list of email addresses that the user never wants to receive email from.
The creation and use of a personal STOPlist is completely optional and simply provides the user with more control over what email is blocked from their inbox. In the preferred embodiment of the invention the user can choose to create or add email addresses to their personal STOPlist using an ~ 360 import function option (710) that vu~ill-allow the user to import email addresse~~from~existing address books, text files, databases, or from another users STOPlist. (735) Alternatively (715) they could simply manually add email addresses to their personal STOPIist. (740) Additional options (720, 725) are provided that allows the user to manually edit (745) and delete (750) email addresses from their personal STOPIist. All STOPlist adds and edits are evaluated (730) to ensure that none of the 365 email addresses appear in both the users STOPlist and GOlist. If the same address appears in both lists, then a process is started that allows the user to resolve the conflict.
(755) II L,.~~ 'i .I. I V'I

Fig. 9 illustrates processes that are invoked each time that the user adds, removes or modifies email addresses in their personal GOlist or STOPlist. (760) If there are email messages in the users detained message list ( 106, 306) with email addresses that are also in the users GOlist or STOPIist, 370 (765) then the proxy ( 102, 302) will determine if the disposition of these messages has changed as the resuk of the changes made to the users GOlist or STOPIist, (790) and whether the detained messages should be retrieved from the users ESP and forwarded to the users inbox (if the email address has been added to the GOlist), or deleted from the users detained list and ESP if the email address has been added to the users STOPIist and the user has configured the proxy ( 102, 302) to 375 automatically delete all messages from senders whose address is in their personal STOPIist.
Additionally a process is started that will send the email addresses (775) that have been added to or removed from a users GOlist and STOPIist to the Registry database (206) along with the GUID for that users proxy installation. (102, 302) The Registry (201) in turn records when each email address has been added or removed from the GOlist or STOPIist related to that installation GUID. The 380 number of GOlists and STOPlists that each email address is on and when the email address was added or removed from these lists can provide important information that is used by the CRP.
Turning now to Fig. 10 we can step through the process used by the proxy (102, 302) to retrieve a message from the users ESP and determine the current rating (if any) and disposition of the message. In one embodiment of the invention, the preferred email client (301) used by the receiver 385 of the email message initiates a check for new email. (803) The proxy (302) will intercept the email check request and submit a request for just the header portion of new email messages to the users ESP on behalf of the users preferred email client (301). (806) After downloading all new email f ~headers> the~proxy x(302): will seleet ;the next message header from the::downloaded list of message . -headers and attempt to parse out a valid email address for the sender of the email. (809) In the 390 majority of cases this address can be found in the one of the three industry standard header fields as currently defined by RFC 2822 (Network Working Group, Request for Comments:
2822, April 2001, "Internet Message Format") and includes: 1.) From; 2.) Sender; and 3.) Reply-To: fields. In cases where there are multiple fields to choose from, each with a different email addresses, then the proxy (302) will comply with RFC 2822's recommendations for the automatic use of the From, 395 Sender, and Reply To fields.

i ~,, ii . , ; Gi Email based mailing lists may use additional industry standard header fields as currently defined by RFC 2369 (Network Working Group, Request for Comments: 2369, July 1998, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields") that identify the administrator of the mailing list that administrative email messages should be sent 400 to, rather than the From or Reply-To addresses which may result in the message being redistributed to all of the subscn'bers of the mailing list in cases where the mailing list is configured as an interactive and un-moderated mailing list. To accommodate mailing lists, the proxy (102, 302) will also look and use the email address contained in the RFC defined "List-Owner"
field in the message header. While a standard exists for mailing list email header fields, the use of the standard List-405 Owner field is only recommended, not required by the currently defined RFC
for mailing list commands and header fields. As a result many mailing list software programs support and use a variety of custom field names to identify the list owner. To accommodate non-standard fields, the proxy ( 102, 302) will also look for non-standard list owner fields using an up-dateable list of known list owner fields that are in common use.
410 If the proxy (302) is unable to identify a valid email address for the sender or list owner (812) then depending on how the receiver has configured the proxy (302), (821) the email message is: 1.) retrieved from the users ESP and forwarded to the users preferred email client (301) (818), or; 2.) the proxy (302) places the message header for the email message in the receivers detained message list (306) so that the receiver can decide if they wish to retrieve or delete the message (824), or; 3.) 415 the proxy (302) deletes the message headers for the email message and sends instructions to the ESP
to delete the message.
If they prca~xy (3U2) is~rahlg~xo°~.parse~out a valid email address<>itom ahe~ sender~or~,list~ owner, it then checks to see if there are other messages with the same address in the receiver's detained list. (306) (815) If there are, then the message header is placed in the detained list.
(306) (824) If there are no 420 other messages with the same address in the users detained list, then the proxy (302) checks to see if the senders email address is on the receivers personal GOlist. (830) If the email address is on the receivers GOlist, then the entire message is retrieved from the receivers ESP
and forwarded to the receivers preferred email client (301). (848) If the senders email address is not on the receivers GOlist, then the proxy (302) checks the receivers STOPlist. (833) If the senders email address is on 425 the receivers STOPIist, then depending on how the receiver has configured the proxy (302) (857), "~~~~ :gin the message headers are placed on the receivers detained list for review by the receiver (860), or the proxy (302) deletes the message header (851) and instructs the receivers ESP
to delete the message.
(854) If the email address is not on the users STOPIist (833), then the proxy (302) sends a request to the 430 ratings server (202) for the current spam rating of the email address.
(836) If the ratings server (202) does not reply to the rating request after x number of tries (839), then depending on how the receiver has configured the proxy (302) (842) the email message is either retrieved from the receivers ESP
and forwarded on to the receivers preferred email client (301) (892), or the message headers are placed on the receivers detained list (306) with a note that the email was detained because the proxy 435 (302) was unable to contact the ratings server. (202) (845) If the ratings server (202) sends a reply to the rating request, the proxy (302) evaluates the reply to determine what action to take based on the rating value provided. If the returned rating indicates that the address is unknown to the Registry (201), or that the address is in the Registry (201) but a registration request needs to be sent to the owner of the email address (863), then the receivers proxy 440 (302) launches the registration request service (307) (872) and emails a registration request message to the sender. If there is no rating value returned by the ratings server (202) (864), the proxy (302) places the message headers on the receivers detained message list (306) (875) and then checks to see if there are additional headers to process. (827) If a rating value is returned by the ratings server (202), the proxy (302) evaluates the rating to 445 determine how to handle the message. If the rating is equal to or below the receiver's minimum acceptable rating value,, the proxy (302) retrieves the entire message from the receivers ESP and T,. . ,~ , ., : ,~::~. ,.
forwards it to the receivers preferred email client (301) (878) and deletes the header from the downloaded header list. (881) If the returned rating is above the receivers minimum acceptable rating value, and if the receiver has configured the proxy (302) to delete email messages with 450 address ratings above their minimum acceptable rating value (869), then the proxy (302) instructs the ESP to delete the message (887) and deletes the message header from the downloaded header list. (890) Finally if the receiver has configured the proxy (302) not to delete messages with rating values above their minimum acceptable rating value, then the message header is placed on the VI Ii . ~. i !I

receivers detained list with an indicator showing that the returned rating value was above the 455 receivers minimum acceptable rating value. (884) Email registration requests are only sent to senders who have sent the receiver a message and only by the receiver's proxy (302) when instructed to do so by the Registry (201).
Fig. 13 illustrates registration request process that is . Before sending out a registration request message to a sender, the registration request module (307) checks to see if a registration request message has been sent to 460 the sender within the last x days, where x is equal to a value defined by the receiver. (900) If a registration request has been sent out to the sender within the past x days, then the process ends. If no registration request have been sent by the registration request module (307) to the sender, then the registration request module (307) checks to see if the email message that the was received from the sender was passed on to the receivers inbox or placed in the detained message list (306). (905) If 465 the message was passed on to the receiver's inbox, then the registration request module (307) generates a registration request message using a message that has been pre-defined by the receiver that advises the sender that their message has been delivered to the receiver's inbox, but their email address has not yet been registered and that they should consider registering their ema,il address with the email rating service. (200) (930) A URL for the registration page is included in the message. If 470 the message was placed in the receivers detained message list (306), then the registration request module (307) generates a registration request message using a message that has been pre-defined by the receiver that advises the sender that their message has not been delivered to the receiver's inbox and that the delivery of their message is not guaranteed unless they register their email address with the email rating service. (200) (910) A URL for the registration page is included in the message.
475- . In one-embodiment.of the inv$ntion the receiver-is able to personalise registration request messages that are sent out to senders, however the inclusion of some elements in the registration request message will be required to ensure the integrity of the process. These elements may include, the URL of the registration page, details about the email rating service, privacy policy statements, etc.
Once the registration request module (307) has emailed the registration request message to the 480 sender it advises the Registry (201, 210) of the email address that the message was sent to (915) and the date and time that the message was sent on. (920) p ;, y '~N ~ ~ ~'~ a The registration request module (307) continues to monitor incoming email messages for bounced registration requests. (925) If a registration request bounces, then the registration request module (307) updates all of the message headers from the bounced email address in the detained list (306) to 485 indicate that email from that address is possibly spam. (935) The registration request module (307) also advises the Registry (201, 210) of all bounced registration requests.
(940) Email addresses that need to be rated or re-rated by the CRP are prioritized and submitted to a "rating queue". (205) In the preferred embodiment of the invention an evaluation priority may be automatically or manually assigned to each email address. Email addresses are evaluated in 490 ascending order of priority using a First In, First Out (FIFO) arrangement.
In one possible embodiment an evaluation priority scale of 1 to 10 may be used, where 1 equals the highest priority and 10 equals the lowest priority. In this embodiment if 15 email address were in the queue with an evaluation priority value of 1, and 35 email address were in the queue with an evaluation priority value of 6, and 126 email addresses where in the queue with an evaluation 495 priority value of 8, then all of the priority 1 email addresses would be evaluated in ascending date/time order, followed by all of the priority 6 email addresses in ascending date/time order, followed by all of the priority 8 email addresses in ascending date/time order. If additional email addresses with higher evaluation priority values are added to the queue while lower priority email addresses are being evaluated, then the next address to be evaluated will be the address with the 500 higher evaluation priority value and the oldest date/time stamp. In addition, rules driven processes may re-define the priority evaluation value assigned to any email address already submitted to the rating queue (205) at any time resulting in an email address being assigned a higher or lower evaluatioa~-priority value. Email addresses that are added to~the queue with wo evaluation priority are automatically assigned the lowest evaluation priority by the queue management process. (205) 505 In the preferred embodiment of the invention email evaluation priority values may be automatically or manually determined by the way that each email address is submitted to the queue. Submission methods may include, (but are not limited to): 1.) ema.il addresses that are added to a users GOlist;
2.) email addresses that are added to a users STOPlist; 3.) email addresses that are provided by the address owner through the registration process; 4.) email address that are submitted by a rule; or 5.) 510 email addresses that are manually submitted to the queue. In the case of submission methods 1,2, py II P~II~~.~~~I~~ i~~ ' : ~~I ~ ~~

and 3 the evaluation priority may be pre-determined by the system administrator (207) and automatically assigned by the queue submission process. In the case of submission method 4, the evaluation priority may be automatically determined by the rule that submitted the email address to the queue for evaluation. And in the case of submission method 5, the evaluation priority may be 515 manually assigned by the user who submitted the email address to the queue.
Date/time ranges that define when the address should be processed may also be provided for each address added to the queue. Addresses with specified date/time processing ranges are not processed, regardless of their evaluation priority assignment until the defined date/time range. During the defined date/time range for processing the priority value assigned to the address (if any) are used to 520 determine when the address is processed. As the time period comes closer to expiring, the evaluation priority of the address will increase to ensure that the address is evaluated within the specified date/time range.
Email rating values are assigned to each address using a series of pre-defined "collaborative rules".
Any number of rules may be defined, and one or more rules may be used to determine an address's 525 current rating value. Rules are collaborative in nature in that they use information that is provided directly and indirectly by the senders and receivers of email messages, along with operational information that is derived from the process of users sending and receiving email messages and maintaining their personal proxy software. ( 102, 302) Information about each email address that is directly provided by users may include (but is not 530 limited to): 1.) The type of email that is typically sent from the users registered email address as previously descmbed, and; 2.) spamtcomplaint submissions 1~';, :,: ~ y.. .
Information about each email address that is indirectly provided by users may include (but is not limited to): 1.) Email addresses and the date/time stamp that each email address was added to or removed from a users GOlist; 2.) email addresses and the date/time stamp that each email address 535 was added to or removed from a users STOPlist; 3.) header information from email messages processed by the proxy (102, 302); 4.) the IP address of the registrant at the time they registered their email address; 5.) the HTTP header information from the registrants browser at the time they registered their email address; 6.) the date/time that the email address was registered; 7.) date/time stamp and the senders email address for each email header that is deleted from a users detained IN ~ ',~I.~'e'~~~"~f' I,~i 540 message list ( 106, 306) by the user, and; 8.) date/time stamp and the senders email address for each email header that is deleted from a users detained message list (106, 306) by an auto delete function.
Information about each email address that is derived from operational activities may include (but is not limited to): 1.) How the email address was added to the Registry (201).
Le.: By the owner, from a personal GO/STOPIist, etc.; 2.) the date/time stamp each time that an email address's status and 545 rating information was requested by a proxy (102, 302); 3.) a complete history of all rating changes for each email address, including the date/time stamp of each rating change and the new rating; 4.) the number of registration requests that were sent to the address owner before the owner registered the address; 5.) the time elapsed between the time that the user submitted a registration application form and the time that they validated the address; 6.) the number of times that the registration 550 process "timed out" (the address owner did not respond to the validation request within the administrators (207) pre-set period of time) requiring the address owner to re-start the registration process.
Information that is not used in any way to calculate email address ratings includes: 1.) The body text of email messages, and; 2.) any information that could personally identify the sender or receiver of 555 the email message.
In the preferred embodiment of the invention rating rules can be created, added, changed, suspended or deleted at any time. Rating rules are applied using a high level scripting language that: 1.) Allows rating rules to be invoked in a specific order; 2.) allows rating rule scripts to be chained so that a rule or script can invoke another script; 3.) allows rating rules or rating rule scripts to invoke one or more 560 additional rating rules or rating rule scripts based on the results produced by the invoking rating rule , or rating rule script; 4.) allows subsequently run rating rules or rating rule scripts to use the results from one or more previously run rating rules or rating rule scripts; 5.) allows ratings rules or rating rule scripts to be results driven so that the product of each rating rule within the script will determine what rule will be invoked next; 6.) allow rating rules or rating rule scripts to be invoked based upon 565 a predefined schedule; 7.) allow rating rules or rating rule scripts to be invoked based upon a predefined set of circumstances such as a system restart, pre-determined number of email addresses waiting in the rating queue (205) for processing, etc.; 8.) allow rating rules or rating rule scripts to re-add an address to the rating queue (205) and specify an evaluation priority and date/time range that the address should be re-rated using a specific rating rule or rating rule script; 9.) allows the 570 wildcard selection of email addresses to be evaluated by a rule, i.e::
select and evaluate all email addresses that end with "someplace.com"; I0.) allow the use of include files (lists) of email addresses that are to be evaluated by a rule, and 11.) allow variables used by each rule to be specified by the creator of the script or by the results of previously run rating rule scripts or rating rules.
575 In addition to the definition of and ad-hoc use of rating rule scripts, the system administrator (207) is also able to associate rating rules or rating rule scripts with each email address when the email address is added to the rating queue (205). What rating rules and rating rule scripts are associated with the email address can depend on how the email address was added to the rating queue. (205) Le.: it was added to a users GOlist or STOPlist and has not yet been rated, it was added to the 580 Registry (201) by the address owner, etc.) If an email address is manually added to the rating queue (205) by an administrator (207), the administrator (207) has the option to specify what rating rules or rating rule scripts are to be used for evaluating the email address, the evaluation priority of the email address, and any pre-defined schedules or time ranges during which the address should be evaluated.
585 Rating rules contain a series of mathematical, Boolean and procedural instructions that are designed to generate a Contributory Rating Value ("CRV") using direct, indirect or derived information about the email address as previously described. In the preferred embodiment of the invention CRVs are floating-point numbers of any value. The CRV generated by each rule only "contributes" to the final rating value assigned to each email address evaluated by the rule. They are not the actual rating 590 values assigned to the email address. It should also be noted that rules may be created to generate negative CRVs, zero and positive CRVs, or negative, zero and positive CRVs.
Negative CRVs represent a relative level of improvement over previously generated CRVs by the same rule, where larger negative values represent the most improvement, and smaller negative values represent the least improvement. Zero and positive values represent absolute spam CRVs that 595 are based upon currently available direct, indirect and/or derived information for the email address, where 0 means that the rule is unable to detect any evidence of spamming whatsoever, and larger values represent increasingly stronger evidence that the email address is being used to send unwanted email.
In one embodiment of the invention values assigned to each email address that represent the current 600 rating would be a series of integers from 0 to 9. Where 0 means that it is extremely unlikely that email received from the address is spam, and 9 means that it is extremely likely that email received from the email address is spam.
In instances where only a single rule has been used to evaluate an email address, only zero and positive CRV results are used to generate the current rating value of the address by rounding down 605 the CRV to the nearest integer and assigning the integer as the current rating value for the email address. If the resulting integer is greater than 9, then 9 becomes the assigned rating value.
In instances where multiple rules are used to evaluate the email address during a single evaluation session, the session will sum and average all of the generated CRVs (negative and positive) for the session, round down and convert the resulting floating point value to an integer, which becomes the 610 final rating value for the email address. If the email address had a pre-assigned rating value, that value may or may not be included in the sum and averaging functions. If the resulting integer is greater than 9, then 9 becomes the assigned rating value. If the resulting integer is less than 0, than 0 becomes the assigned rating value While any number of rules can be created and used to evaluate and rate email addresses, for the 615 purposes of illustration we will descr'be three rules that could be considered the minimum needed to accurately assess and rate an email address. The following examples are only provided to illustrate how rules may work in one possible embodiment of the invention and should not be considered as functionally complete. In addition, the sample rules provided only illustrate the generation of positive CRVs. Variations of these example rules could generate negative CRVs to account for users 620 who are trying to improve or correct their rating assignment by implementing email best practices.
As experience is gained in the creation and deployment of rating rules, more sophisticated and functionally complete rules will be developed.
Sample Rule #1 - Excessive Rating Requests: This rule assumes that if the ratings server (202) receives an excessive number of rating requests for an email address over a pre-defined period of i~:~~ i~, ~ ;n i '~

625 time, that there is a possibility that the address is being used to send spam. This rule only generates zero and positive CRVs. When run, the rule queries the email database (206) for all rating requests received for the email address being evaluated since the last time that the rule was used to evaluate the same address. The rule also queries the email database (206) and calculates an average value for all rating requests received for all email addresses that are of the same type as the email address 630 being evaluated and with a currently assigned spam rating value of x or less, where x is a value assigned by the system administrator (207). The number of rating requests received for the email address being evaluated is subtracted from the average number of email rating requests received for the comparative email addresses. The difference is then multiplied by x (where x is a value defined by the administrator (207)) to arrive at a CRV that is used to calculate the final rating assignment for 635 the email address when all other rules have completed their evaluation of the address.
Rule #1 Example: someone@somewhere.com is a personal address that has a rating value of 1 currently assigned to it. The last time that the address was evaluated by the Excessive Rating Requests rule it was re-added to the rating queue (205) with instructions to re-evaluate the address within 15 to 30 minutes using the same rule with an evaluation priority of 4.
After 15 minutes has 640 elapsed the queue starts the revaluation process of someone@somewhere.com using the Excessive Rating Requests rule and determines that the email address has received 13 rating requests in the past 15 minutes. The rule queries the email database (206) and determines that the average number of requests received for the same type of email address (personal) with a current rating assignment of 2 or less in the past I S minutes is 4.3, giving us a difference between the average number of 645 rating requests received by other email addresses and the number of rating requests received for someone@somewhere.com of 8.7. The administrator (207) has assigned a multiplier value of .5, which results in a final CRV of 4.35. If no other rules have been used to evaluate the email address, then the process continues by averaging the currently assigned rating value of 1 with the CRV of 4.35 to arnve at an average value of 2.675 which when rounded down to the nearest integer results 650 in a new rating value of 2, which is the new rating value assigned to someone@somewhere.com The process concludes by comparing the previously calculated rating value for someone@somewhere.com with the value previously generated by the same rule.
Since the rating value has increased by 1, the rule re-submits the email address to the rating queue (205) with a evaluation priority of 8 and a request a review of the email address using the same rule in not more 655 than 15 minutes and not less than 30 minutes from the time it was submitted to the rating queue (205).
Sample Rule #2 - Excessive STOPlist Assignments: This rule assumes that if an email address is assigned to an excessive number of user STOPlists, that there is a possibility that the address is being used to send spam. This rule generates zero and positive CRVs. When run, the rule queries the 660 email database (206) for a total count of STOPlists that the email address is currently assigned to by users of the proxy ( 102, 302) software. The rule also queries the email database (206) for all email addresses that are currently assigned to one or more user STOPlists and calculates the average number of STOPlists that other email addresses are on. The average number of STOPlists that other email addresses are on is subtracted from the number of STOPlists that the email address that is 665 being evaluated is on. If the difference is not equal to or less than 0, then the difference is multiplied by x (where x is a value defined by the administrator (207)) to arrive at a CRV that is used to calculate the final rating value assignment for the email address when all other rules have completed their evaluation of the address.
Rule #2 Example: someone@somewhere.com is a personal address that has a rating value of 2 670 currently assigned to it. The last time that the address was evaluated by the Excessive STOPlist Assignment rule it was re-added to the rating queue (205) with instructions to re-evaluate the address within 6 to 10 hours using the same rule. After 6 hours has elapsed the queue starts the revaluation process of someone@somewhere.com using the Excessive STOPIist Assignments rule and determines that the email address is currently on 37 STOPlists. The rule queries the email 675 database (206) and determines that the average number of STOPlists that other addresses of the ,.type (personal) are::on is 5.8; giving us a difference between the average number of STOPlists that other email addresses are on and the number of STOPlists that someone@somewhere.com is on of 11.2. The administrator (207) has assigned a multiplier value of .5, which results in a final CRV
of 5.6. If no other rules have been used to evaluate the email address, then the process continues by 680 averaging the currently assigned rating value of 2 with the CRV of 5.6 to arrive at an average value of 3.8 which when rounded down to the nearest integer results in a new rating value of 3, which is assigned to someone@somewhere.com. The process concludes by comparing the previously calculated rating value for someone@somewhere.com with the value previously generated by the same rule. Since the rating value has increased by 1, the rule re-submits the email address to the 685 rating queue (205) with a evaluation priority of 5 and requests a review of the email address using the same rule in not more than 6 hours and not less than 10 hours from the time it was submitted to the rating queue (205).
Sample Rule #3 - Excessive Complaints: This rule assumes that if an email address receives an excessive number of complaints from users about email being sent from the address, that there is a 690 strong possibility that the address is being used to send spam. This rule generates zero and positive CRVs. When run, the rule queries the email database (206) for a total count of complaints received from users for the email address being evaluated. The rule also queries the email database (206) for email addresses of the same type, that have received one or more complaints, and that have a currently assigned rating value of x or less, where x is an integer value assigned by the system 695 administrator. (207) The process then uses the query results to calculate a value that represents the average number of spam complaints received for all other email addresses that complaints have been received for. The average number of complaints received for other email addresses are subtracted from the number of complaints received from the email address that is being evaluated. If the difference is greater than 0 than the difference is multiplied by x where x is a value defined by the ?00 administrator (20?) to arnve at a CRV that is used to calculate the final rating value assignment for the email address when all other rules have completed their evaluation of the address.
Rule #3 Example: someone@somewhere.com is a personal address that has a rating value of 4 currently assigned to it. The last time that the address was evaluated by the Excessive Complaints rule it was re-added to the rating queue (205) with instructions to re-evaluate the address within 4 to 705 5 hours using the same rule. After 4 hours has elapsed the queue starts the revaluation process of ~:, . ~-s~meone@sa~~uhere:eom using the Excessive Complaints rule ~and.:determines that the email address has received a total of 28 complaints. The rule queries the email database (206) and determines that the average number of complaints received by other addresses of the same type (personal) is 3.21, giving us a difference between the average number of complaints that other email 710 addresses have received and the number of complaints that someone@somewhere.com has received of 24.79. The administrator (207) has assigned a multiplier value of .5, which results in a final CRV
of 12.395. If no other rules have been used to evaluate the email address, then the process continues by averaging the currently assigned rating value of 3 with the CRV of 12.395 to arrive at an average value of 7.69?5 which when rounded down to the nearest integer results in a new rating value of 7, iN ; , : k,u,~,G ~ d~ f ~I

715 which is assigned to someone@somewhere.com. The process concludes by comparing the previously calculated rating value for someone@somewhere.com with the value previously generated by the same rule. Since the rating value has increased by 4, the rule re-submits the email address to the rating queue (205) with a evaluation priority of 9 and requests a review of the email address using the same rule in not more than 1 hour and not less than 2 hours from the time it was 720 submitted to the rating queue (205).
. .. . . . ,.""~ :s:,:r.~-s~ ~-; . , , .

Claims (25)

We Claim:

1. A method of limiting unsolicited commercial email (spam) by using a system comprising of: a central database that contains information about email addresses derived from the process of users sending and receiving email messages; a challenge-response process that requires unknown senders of email messages to register their email address with a central repository; a centralized, collaborative rating process that uses information stored in the central repository to generate email address ratings information; an email "ratings server" that disseminates address rating information to remote processes; and "filtering software" that filters email messages based on pre-defined preferences.

2. The method of claim 1 comprising the step of collecting information, through the use of filtering software, about email addresses when email is sent by a sender and received by the recipient.

3. The method of claim 1 wherein a challenge is sent to unknown senders of email messages requiring them to respond by registering their email address in a central database before their email messages are delivered to the recipients.

4. The method of claim 1 wherein email address owners may submit their email address to be rated so that email from their email address is delivered to recipients running filtering software without delay, provided that the senders email rating in the central address repository is sufficient to be accepted by the recipients filtering software.

5. The method of claim 1 wherein a collaborative process is used to evaluate and rate each email address maintained in a central database.

6. The method of claim 1 comprising of an email address rating service that sends, in a secured fashion, current email address ratings maintained in a centralized repository to remote processes on demand, such as email filtering software.

7. The method of claim 1 comprising of filtering software that uses a combination of methods to filter out spam email from incoming email messages.

8. The method of claim 7 wherein the filtering software intercepts communication between the recipients email software and the configured email server that it connects to whereby the filtering software obtains the headers of the email messages waiting on the email server for the recipient and begins a process of validation of each email address that the email messages are from.

9. The method of claim 8 wherein the filtering software uses locally stored lists, called a GoList and a StopList, which contain email addresses that the filtering software uses, in part, to determine whether or not an email message should be delivered to the recipients email software.

10. The method of claim 8 wherein the filtering software sends a request in a secured fashion to a rating server for the current rating information of an email address in order to determine if the email message sent from the senders email address should be delivered to the recipients email software.

11. The method of claim 10 wherein the rating of a given email address retrieved by the filtering software is compared to the threshold configured by the user in the filtering software to determine if the email message should be delivered to the users email software.

12. The method of claim 8 wherein the filtering software sends a pre-configured challenge email message to the sender requesting the sender to register their email address with a central database before their email message is delivered to the recipient's email software if the senders email address is not already registered in the central repository and is not contained within the users Stoplist or Golist.

13. The method of claim 8 wherein the filtering software includes a process that does not deliver email messages to the recipients email software if the email messages do not meet the filtering software's threshold, which is set by the user of the filtering software

14. The method of claim 13 wherein the email software saves email header information in a "detained"
list until such a time that the sender registers their email address so that it can be rated, or the receiver releases the message from the detained list by manually selecting messages to be delivered, or by adding the senders email address to the local GoList in the filtering software.

15. The method of claim 8 wherein the filtering software includes settable parameters that allows the user to control how email messages are filtered.

16. The method of claim 13 wherein the user can view the header information of detained messages via an interface in the filtering software

17. The method of claim 4 wherein a challenge process includes the delivery of an email to the registered email address with a non-machine interpretable graphic consisting of a series of random alpha-numeric characters that are obfuscated by a variety of methods such that a human being must interpret the graphic and enter the value into a web page as part of the registration process.

18. The method of claim 17 wherein the registration process compares the value the user interpreted to the value that the non-machine readable graphic represented that was sent to the registered email address to confirm that it is correct, prior to being saved in the registration database.

19. The method of claim 18 whereby if the user failed to correctly enter the value that represented the graphic, a new graphic is generated in a similar fashion for them to try again.

20. The method of claim 4 wherein the email addresses that are not already rated are sent to be rated by the Collaborative process. These email addresses may be new registrants or email addresses that the filtering software requests a rating for that do not exist in the central repository.

21. The method of claim 2 wherein the email rating service will submit any email addresses that ratings are requested for that are not already rated to the collaborative process so they will be rated.

22. The method of claim 5 where in the collaborative process creates a "rating" for a given email address by using information contained within the central repository such as, but not limited to the time of and number of times that email addresses are added to Stop/Go lists of filtering software users, the number and time of requests for ratings received by the rating service for a given email address, the type of email that was indicated at the time the email address was registered (if registered), and if users of the filtering software have indicated that an email message from a given sender was spam.

23. The method of claim 22 wherein the collaborative process assigns to email addresses a weighting number representing the scale of how likely it is that the email address has sent spam by using a pre-determined set of filtering rules that may be added, edited, or disabled at any time.

24. The method of claim 22 wherein the rules used by the collaborative filter contain numeric thresholds that may be edited at anytime either by the collaborative filter or by an administrator

25. The method of claim 22 wherein the collaborative filter saves ratings of email addresses in the rating service.