WO2002025464A1 - E-mail spam elimination method and system - Google Patents
E-mail spam elimination method and system Download PDFInfo
- Publication number
- WO2002025464A1 WO2002025464A1 PCT/US2001/029571 US0129571W WO0225464A1 WO 2002025464 A1 WO2002025464 A1 WO 2002025464A1 US 0129571 W US0129571 W US 0129571W WO 0225464 A1 WO0225464 A1 WO 0225464A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- source
- message
- database
- webserver
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/212—Monitoring or handling of messages using filtering or selective blocking
Definitions
- the present invention relates to electronic mail (e-mail), and more specifically to methods and systems for controlling the delivery of unwanted e-mail messages (spam).
- e-mail electronic mail
- spamm unwanted e-mail messages
- Unwanted e-mail, or spam is becoming a great nuisance. Spammers are becoming more adept at being annoying and getting around ordinary filters. One way they do this is to hide their real e-mail sending address and plug in some phony one. They then use a new return e-mail address for every new piece of spam. Although every spammer is ultimately trying to sell something, they all seem to prevent a simple e-mail reply. Instead, you must go to a website or call a phone number where you must listen to a long recorded message and leave a voice-mail message.
- More advanced e-mail filters are able to recognize keywords and phrases in the subject and message body, and then use the occurrence of these in a new message to block out the whole message. For example, “get rich quick” or “buy now” appearing in the subject line could signal an unwanted message.
- Eudora is an example of an e-mail application that includes a highly developed user-programmable filter.
- a first filter is supplied with e-mail sender addresses the user does not want to receive messages from.
- a second filter is loaded with those e-mail sender addresses that the user does want to receive. Messages caught by the first filter are simply dumped. Messages recognized by the second filter are passed through for delivery. Messages from addresses not brought to the attention of either filter are forwarded to a "waiting room" for the user to look at later. Any messages in this waiting room that are later rejected by a user's review are gleaned for information that is forwarded to a central system.
- a master-list update is then compiled for the first filters of all users/subscribers.
- An e-mail system includes an address book that registers all e-mail correspondents wishing to send messages to a particular user recipient. All e-mail directed to the user from outside is blocked unless the sender is registered in the address book and has a valid token. A limited number of such tokens are issued to each correspondent, and only after the sender has satisfactorily disclosed their identity. Such tokens limit the amount of access to a recipient. If the recipient later decides that any such sender is, fact, a spammer, then any further e-mail from that sender can be blocked.
- Fig. 1 is a top-level flowchart of an e-mail server embodiment of the present invention
- Fig. 2 is a flowchart of the Sendmail subroutine of Fig. 1
- Fig. 3 is a flowchart of the Procmail subroutine of Fig. 1 ;
- Fig. 4 is a flowchart of the PERL script "asptest.pl" subroutine of Fig. 1 ;
- Fig. 5 is a flowchart of the PERL script "dumpit.pl" subroutine of Fig. 1 ;
- Fig. 6 is a flowchart of the PERL script "getaddr.pl" subroutine of Fig. 1 ;
- Fig. 7 is a flowchart for creating user accounts in an embodiment of the present invention.
- Fig. 1 represents an e-mail server embodiment of the present invention, and is referred to herein by the general reference numeral 100.
- a new e-mail message 102 enters a sendmail subroutine 104 which inspects the "from" address header included in the e- mail. The whole e-mail is either then forwarded to a deliver-message subroutine 106 or a procmail subroutine 108, depending on whether the sender is an acceptable and known correspondent who has been preregistered in the system.
- Procmail 108 calls on an asptest.pl subroutine 110, a dumpit.pl subroutine 112, and a getaddr.pl subroutine 114, to process the incoming e-mails for acceptability to the user.
- PERL-script implementations are preferred, as indicated by the ".pi" extensions mentioned herein for the subroutine files.
- Fig. 2 details a sendmail subroutine 200 which is similar to the sendmail subroutine 104 (Fig. 1).
- a new e-mail message 202 is passed on to an address domain parser 204.
- the "from" address header in the message received is checked to see if the domain matches a preregistered domain, e.g., one that is known to the user or the e-mail system. If the domain does match a preregistered domain, and has a suffix of ".procmail", a step 206 strips the address of the ".procmail" suffix.
- a step 208 parses the e-mail recipient header e.g., with getaddr.pl subroutine 114, and delivers the e-mail in a step 210.
- the "from" address header is rewritten in a step 212 as "domain. procmail" and the whole message is piped through procmail by a step 214.
- Fig. 3 details a procmail subroutine 300 which is similar to the procmail subroutine 108 (Fig. 1).
- a new e-mail message 302 is passed on to a step 304 which generates a proper "from" address header.
- a step 306 checks for an "x-Ioop:" header entry. If one is not found, a step 308 makes a copy of the message and sends it to the asptest.pl subroutine 110. If the test in the asptest.pl subroutine returned a "no", then the message is dumped in a step 310 that trashes it with dumpit.pl subroutine 112.
- step 312 parses the recipient field from the e-mail header by calling the getaddr.pl subroutine 114.
- a step 314 then bounces the message on to the recipient/user.
- Fig. 4 details an asptest.pl subroutine 400 which is similar to the asptest.pl subroutine 110 (Fig. 1).
- a new e-mail message 402 is passed on to a step 404 which parses the sender and recipient info from the e-mail message header.
- Such parsed-out address information is then used by a step 406 to generate a hypertext transfer protocol (HTTP) message.
- HTTP hypertext transfer protocol
- ASP active server pages
- Such http-message can be communicated over any network, especially over the Internet via TCP/IP.
- a centralized system would then be possible that could be used to share preregistration information and any information generated about spammers.
- the webserver's ASP typically responds with one of four commands amounting to, (a) “deliver the e-mail", (b) “deliver the e-mail with form attached", (c) “reply and attach error", or (d) "delete the e-mail”. If the answer is anything but "deliver e-mail", an error message to the user is generated.
- a step 408 parses the ASP response.
- a step 410 generates an exitcode from the ASP response, and a step 412 returns the error message to procmail subroutine 108 and exits.
- Procmail uses the exitcode and error message to decide whether to "deliver the e-mail" or to trash it by sending it to the dumpit.pl subroutine 112.
- the "deliver the e-mail” choice uses the getaddr.pl subroutine 114 to parse out the recipient. The e-mail is then bounced to the recipient in step 314.
- Fig. 5 details a dumpit.pl subroutine 500 which is similar to the dumpit.pl subroutine 112 (Fig. 1).
- a new e-mail message 502 and an error message 504 are passed on to a step 506 which is to dump the message, reply to it, or to attach a form. If the decision is to "delete the e-mail", a null step 508 simply exits without doing anything. If the decision is to "reply and attach error", a reply header is generated in a step 510.
- a step 512 appends the error message to the e-mail, and a step 514 sends the new e-mail.
- a step 516 uses the getaddr.pl subroutine to parse the recipient from the e-mail header.
- a step 518 appends a hypertext markup language (HTML) form, and sends the e-mail to the recipient in a step 520.
- HTML hypertext markup language
- Fig. 6 details a getaddr.pl subroutine 600 which is similar to the getaddr.pl subroutine 1 12 (Fig. 1).
- a new e-mail message 602 has its header parsed in a step 604 for its recipient information.
- a step 606 returns to the calling program with the recipient address.
- Fig. 7 represents a method for creating new user accounts with the systems described h Figs. 1 -6, and is referred to herein by the general reference numeral 700.
- the method 700 is preferably included in a business model embodiment of the present invention.
- a profitable business can be constructed with an implementation from Figs. 1-7 that operates over the Internet and uses HTTP, HTML, and simple mail transfer protocol (SMTP) documents with both webpage servers and mail servers.
- the users are required, at least initially to enroll and load preferences, to have an Internet client and browser.
- Such Internet client is used in step 406 to ask the ASP what to do with particular messages received.
- the SMTP mail server delivers the basic e-mail messages, and the webservers use the Internet to communicate filter information between users and a centralized database.
- Such database and webserver is operated at a profit by charging users a subscription fee or per-use fee.
- the new user account creation method 700 begins with a fill-in form 702 that can b e implemented with JavaScript and HTML-code generated by the ASP in the webserver.
- An information 704 includes user data that is needed to enroll a user in a system like that described in Figs. 1-6.
- a step 706 validates the information submitted, e.g., by rule-based checking. It confirms receipt by the provider to the newly enrolled user.
- a step 708 downloads the verified information to the database for real-time use over the Internet.
- embodiments of the present invention defaults to blocking mail from all unknown sources. Any e-mail from known and acceptable sources are preferably viewable in a user directory free of unsolicited messages.
- Senders wishing to send messages to recipient-users, and who are unknown, must register with a central control system. For example, an Internet webserver is provided as a central control and registry. Those registering must identify themselves sufficient to satisfy the system operators and users. A limited number of tokens are then electronically credited to such previously unknown senders. The limits on the number of tokens allotted prevents mass mailings. Recipient-users who do have the sender listed as a known and acceptable source can authorize mail delivery without requiring any tokens.
- Messages that are sent with tokens and accepted by their intended recipients will preferably automatically generate more tokens for use by the corresponding sender. This is equivalent to rewards for good behavior, or the way credit is established b y establishing a record of responsible conduct. It also limits the volume of mail that can be sent by one sender, and thus makes the sending of junk e-mail uneconomical. Any e- mail received by using tokens as passports is sent to a directory in which the users know the messages inside may be unsolicited and require validation.
- a system of validation levels can be applied to authorized users.
- a "caller-ID" level confirms valid "from” e-mail addresses.
- a second level check if the sender's physical address is acceptable.
- a third level check if the sender's phone number is acceptable.
- a fourth level check if the sender has a valid certificate.
- Corporate senders can also be classified as non-profit or having paid a fee. Such fees can be collected by the system operator, or credited to individual recipients.
- Such validation levels, fee payments, non-profit senders, and the implementation of tokens can be included in the construction of the asptest.pl subroutine 110 and 400.
- a corresponding application program is included in the ASP program on the responsible webserver.
Abstract
An e-mail system includes an address book (108) that registers all e-mail correspondents wishing to send messages (202) to a particular user recipient. All e-mail directed to the user from outside is blocked unless the sender is registered in the address book and has a valid token (200). A limited number of such tokens are issued to each correspondent, and only after the sender has satisfactorily disclosed their identity. Such tokens limit the amount of access to a recipient. If the recipient later decides that any such sender is, in fact, a spammer, then any further e-mail from that sender can be blocked.
Description
E-MAIL SPAM ELIMINATION METHOD AND SYSTEM
Background Of The Invention
Technical Field
The present invention relates to electronic mail (e-mail), and more specifically to methods and systems for controlling the delivery of unwanted e-mail messages (spam).
Description Of The Prior Art
Unwanted e-mail, or spam, is becoming a great nuisance. Spammers are becoming more adept at being annoying and getting around ordinary filters. One way they do this is to hide their real e-mail sending address and plug in some phony one. They then use a new return e-mail address for every new piece of spam. Although every spammer is ultimately trying to sell something, they all seem to prevent a simple e-mail reply. Instead, you must go to a website or call a phone number where you must listen to a long recorded message and leave a voice-mail message.
More advanced e-mail filters are able to recognize keywords and phrases in the subject and message body, and then use the occurrence of these in a new message to block out the whole message. For example, "get rich quick" or "buy now" appearing in the subject line could signal an unwanted message. Eudora is an example of an e-mail application that includes a highly developed user-programmable filter.
But such filters can also block messages from desirable correspondents, so great care must be used in the selection of the keywords and phrases. A monitor also needs to be setup so the blocked messages can be reviewed to make sure acceptable
messages are not being filtered out. Systems like that described by Lucent Technologies (Murray Hill, NJ) in European Patent Application EP-0-899-918-A2, "System and method for providing anonymous remailing and filtering of electronic mail", published 03.03.1999, strip away the real source's address in e-mails and render the messages sent anonymous. Prior art filters can do little to stop such trickery.
The general problem with conventional spam eliminators is they must know something about the spammer and their messages in order to block them. Spammers use this weakness to their advantage by constantly finding subjects, messages, and return e- mail addresses that seen inoffensive.
European Patent Application EP-0-813-162-A2, published 17.12.1997, titled "Method and apparatus for identifying and discarding junk electronic mail", depends on a group of trusted users to collectively determine what is junk e-mail. Once a piece is labeled as junk e-mail, unviewed copies in the e-mail systems of the other trusted users are immediately disposed of. Single users thus get far less junk e-mail, especially in large organizations. However, someone must get stung first before the e-mail is blocked entirely by the system. A very similar approach is repeated in United States Patent 6,052,709, titled "Apparatus and method for controlling delivery of unsolicited electronic mail", which was issued April 18, 2000, to Sunil Paul.
Two filters are used in the method and system described by William B. McCormick, et al., in United States Patent 6,023,723, issued Feb. 8, 2000. A first filter is supplied with e-mail sender addresses the user does not want to receive messages from. A second filter is loaded with those e-mail sender addresses that the user does want to receive. Messages caught by the first filter are simply dumped. Messages recognized by the second filter are passed through for delivery. Messages from addresses not brought to the attention of either filter are forwarded to a "waiting room" for the user to look at later. Any messages in this waiting room that are later rejected by a user's review are gleaned
for information that is forwarded to a central system. A master-list update is then compiled for the first filters of all users/subscribers.
Summary Of The Invention
An e-mail system includes an address book that registers all e-mail correspondents wishing to send messages to a particular user recipient. All e-mail directed to the user from outside is blocked unless the sender is registered in the address book and has a valid token. A limited number of such tokens are issued to each correspondent, and only after the sender has satisfactorily disclosed their identity. Such tokens limit the amount of access to a recipient. If the recipient later decides that any such sender is, fact, a spammer, then any further e-mail from that sender can be blocked.
Brief Description Of The Drawings
Fig. 1 is a top-level flowchart of an e-mail server embodiment of the present invention; Fig. 2 is a flowchart of the Sendmail subroutine of Fig. 1 ; Fig. 3 is a flowchart of the Procmail subroutine of Fig. 1 ;
Fig. 4 is a flowchart of the PERL script "asptest.pl" subroutine of Fig. 1 ;
Fig. 5 is a flowchart of the PERL script "dumpit.pl" subroutine of Fig. 1 ;
Fig. 6 is a flowchart of the PERL script "getaddr.pl" subroutine of Fig. 1 ; and
Fig. 7 is a flowchart for creating user accounts in an embodiment of the present invention.
Detailed Description Of The Invention
Fig. 1 represents an e-mail server embodiment of the present invention, and is referred to herein by the general reference numeral 100. A new e-mail message 102 enters a
sendmail subroutine 104 which inspects the "from" address header included in the e- mail. The whole e-mail is either then forwarded to a deliver-message subroutine 106 or a procmail subroutine 108, depending on whether the sender is an acceptable and known correspondent who has been preregistered in the system. Procmail 108 calls on an asptest.pl subroutine 110, a dumpit.pl subroutine 112, and a getaddr.pl subroutine 114, to process the incoming e-mails for acceptability to the user. PERL-script implementations are preferred, as indicated by the ".pi" extensions mentioned herein for the subroutine files. Some of the processed e-mails can be returned by procmail 108 to sendmail 104 for ultimate delivery to the user.
Fig. 2 details a sendmail subroutine 200 which is similar to the sendmail subroutine 104 (Fig. 1). A new e-mail message 202 is passed on to an address domain parser 204. The "from" address header in the message received is checked to see if the domain matches a preregistered domain, e.g., one that is known to the user or the e-mail system. If the domain does match a preregistered domain, and has a suffix of ".procmail", a step 206 strips the address of the ".procmail" suffix. A step 208 parses the e-mail recipient header e.g., with getaddr.pl subroutine 114, and delivers the e-mail in a step 210. If the message is from an unknown source, e.g., the domain does not match any preregistered domain, the "from" address header is rewritten in a step 212 as "domain. procmail" and the whole message is piped through procmail by a step 214.
Fig. 3 details a procmail subroutine 300 which is similar to the procmail subroutine 108 (Fig. 1). A new e-mail message 302 is passed on to a step 304 which generates a proper "from" address header. A step 306 checks for an "x-Ioop:" header entry. If one is not found, a step 308 makes a copy of the message and sends it to the asptest.pl subroutine 110. If the test in the asptest.pl subroutine returned a "no", then the message is dumped in a step 310 that trashes it with dumpit.pl subroutine 112. But if the test in the asptest.pl subroutine returned a "yes", then the message is forwarded to a step 312. Such parses the recipient field from the e-mail header by calling the
getaddr.pl subroutine 114. A step 314 then bounces the message on to the recipient/user.
Fig. 4 details an asptest.pl subroutine 400 which is similar to the asptest.pl subroutine 110 (Fig. 1). A new e-mail message 402 is passed on to a step 404 which parses the sender and recipient info from the e-mail message header. Such parsed-out address information is then used by a step 406 to generate a hypertext transfer protocol (HTTP) message. This is then sent to an active server pages (ASP) application running on a webserver, e.g., WINDOWS-NT with IIS. Such http-message can be communicated over any network, especially over the Internet via TCP/IP. A centralized system would then be possible that could be used to share preregistration information and any information generated about spammers.
The webserver's ASP typically responds with one of four commands amounting to, (a) "deliver the e-mail", (b) "deliver the e-mail with form attached", (c) "reply and attach error", or (d) "delete the e-mail". If the answer is anything but "deliver e-mail", an error message to the user is generated. A step 408 parses the ASP response. A step 410 generates an exitcode from the ASP response, and a step 412 returns the error message to procmail subroutine 108 and exits. Procmail uses the exitcode and error message to decide whether to "deliver the e-mail" or to trash it by sending it to the dumpit.pl subroutine 112. The "deliver the e-mail" choice uses the getaddr.pl subroutine 114 to parse out the recipient. The e-mail is then bounced to the recipient in step 314.
Fig. 5 details a dumpit.pl subroutine 500 which is similar to the dumpit.pl subroutine 112 (Fig. 1). A new e-mail message 502 and an error message 504 are passed on to a step 506 which is to dump the message, reply to it, or to attach a form. If the decision is to "delete the e-mail", a null step 508 simply exits without doing anything. If the decision is to "reply and attach error", a reply header is generated in a step 510. A step 512 appends the error message to the e-mail, and a step 514 sends the new e-mail. But if
the decision in step 506 is to "deliver the e-mail with form attached", a step 516 uses the getaddr.pl subroutine to parse the recipient from the e-mail header. A step 518 appends a hypertext markup language (HTML) form, and sends the e-mail to the recipient in a step 520.
Fig. 6 details a getaddr.pl subroutine 600 which is similar to the getaddr.pl subroutine 1 12 (Fig. 1). A new e-mail message 602 has its header parsed in a step 604 for its recipient information. A step 606 returns to the calling program with the recipient address.
Fig. 7 represents a method for creating new user accounts with the systems described h Figs. 1 -6, and is referred to herein by the general reference numeral 700. The method 700 is preferably included in a business model embodiment of the present invention. A profitable business can be constructed with an implementation from Figs. 1-7 that operates over the Internet and uses HTTP, HTML, and simple mail transfer protocol (SMTP) documents with both webpage servers and mail servers. The users are required, at least initially to enroll and load preferences, to have an Internet client and browser. Such Internet client is used in step 406 to ask the ASP what to do with particular messages received. The SMTP mail server delivers the basic e-mail messages, and the webservers use the Internet to communicate filter information between users and a centralized database. Such database and webserver is operated at a profit by charging users a subscription fee or per-use fee.
The new user account creation method 700 begins with a fill-in form 702 that can b e implemented with JavaScript and HTML-code generated by the ASP in the webserver. An information 704 includes user data that is needed to enroll a user in a system like that described in Figs. 1-6. A step 706 validates the information submitted, e.g., by rule-based checking. It confirms receipt by the provider to the newly enrolled
user. A step 708 downloads the verified information to the database for real-time use over the Internet.
In general, embodiments of the present invention defaults to blocking mail from all unknown sources. Any e-mail from known and acceptable sources are preferably viewable in a user directory free of unsolicited messages. Senders wishing to send messages to recipient-users, and who are unknown, must register with a central control system. For example, an Internet webserver is provided as a central control and registry. Those registering must identify themselves sufficient to satisfy the system operators and users. A limited number of tokens are then electronically credited to such previously unknown senders. The limits on the number of tokens allotted prevents mass mailings. Recipient-users who do have the sender listed as a known and acceptable source can authorize mail delivery without requiring any tokens.
Messages that are sent with tokens and accepted by their intended recipients will preferably automatically generate more tokens for use by the corresponding sender. This is equivalent to rewards for good behavior, or the way credit is established b y establishing a record of responsible conduct. It also limits the volume of mail that can be sent by one sender, and thus makes the sending of junk e-mail uneconomical. Any e- mail received by using tokens as passports is sent to a directory in which the users know the messages inside may be unsolicited and require validation.
A system of validation levels can be applied to authorized users. A "caller-ID" level confirms valid "from" e-mail addresses. A second level check if the sender's physical address is acceptable. A third level check if the sender's phone number is acceptable. A fourth level check if the sender has a valid certificate. Corporate senders can also be classified as non-profit or having paid a fee. Such fees can be collected by the system operator, or credited to individual recipients.
Such validation levels, fee payments, non-profit senders, and the implementation of tokens can be included in the construction of the asptest.pl subroutine 110 and 400. A corresponding application program is included in the ASP program on the responsible webserver.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the claims included below.
Claims
1. A method for stopping unwanted messages from being accepted in an e-mail delivery system, comprising: receiving an e-mail message from a sender via an SMTP-mail server; parsing an address header from said e-mail message with an e-mail delivery system; sending an e-mail source address obtained in the step of parsing to a webserver; checking said e-mail source address against a list of source addresses maintained in a database associated with said webserver; instructing said e-mail delivery system from said webserver to deliver or not- deliver said e-mail message to a user; displaying said e-mail message at said e-mail delivery system to said user if instructed to do so by said webserver; and disposing of said e-mail message at said e-mail delivery system if instructed to do so by said webserver.
2. The method of claim 1 , wherein: the step of sending an e-mail source address depends on transmitting an HTTP- message via the Internet to an active server pages (ASP) equivalent application program operating on said webserver.
3. The method of claim 1 , wherein: the step of instructing said e-mail delivery system depends on transmitting an HTTP-message via the Internet from an active server pages (ASP) equivalent application program operating on said webserver.
4. The method of claim 1 , further comprising the step of: registering an e-mail source in said database such that the step of checking will approve of said e-mail message if originated by that e-mail source.
5. The method of claim 1 , further comprising the step of: preapproving a list of e-mail sources in said database such that the step of checking will allow delivery of said e-mail message if originated by any one of such e- mail sources.
6. The method of claim 1 , further comprising the step of: allowing an e-mail source to list itself in said database such that the step of checking will allow delivery of said e-mail message if originated by such e-mail source.
7. The method of claim 1 , further comprising the steps of: gathering identification information from an e-mail source not registered in said database; testing whether said identification information is acceptable according to a minimum standard; and if acceptable, allowing said e-mail source to be listed in said database such that the step of checking will allow delivery of said e-mail message if originated by such e- mail source.
8. The method of claim 7, further comprising the steps of: issuing a first token to an e-mail source previously not registered in said database; and requiring said first token to be expired before the step of checking will allow delivery of said e-mail message when originated by such e-mail source.
9. The method of claim 7, further comprising the steps of:
issuing a second token to said e-mail source previously not registered in said database if said user validates them after having received and read one of their e-mail messages.
10. An e-mail delivery system, comprising: a webserver connected to a computer data network; an SMTP-mail sever for providing the delivery of e-mail messages to a user; a spam-elimination system connected to receive said e-mail messages from the SMTP-mail server; and a database of registered e-mail senders included in the webserver; wherein, the spam-elimination system transmits any e-mail source address information included in any received e-mail messages to the webserver; wherein; the database is consulted for a registration listing matching said e-mail source address information; and wherein, the webserver provides for the instruction of the spam-elimination system to deliver or not deliver to a user a particular e-mail message.
11. The e-mail delivery system of claim 10, wherein the spam-elimination system further includes: a program subroutine for receiving an e-mail message from a sender via said
SMTP-mail server; a program subroutine for parsing an address header from said e-mail message with an e-mail delivery system; a program subroutine for sending an e-mail source address obtained in the step of parsing to a webserver; a program subroutine for checking said e-mail source address against a list of source addresses maintained in a database associated with said webserver; a program subroutine for instructing said e-mail delivery system from said webserver to deliver or not-deliver said e-mail message to a user;
a program subroutine for displaying said e-mail message at said e-mail delivery system to said user if instructed to do so by said webserver; and a program subroutine for disposing of said e-mail message at said e-mail delivery system if instructed to do so by said webserver.
12. The system of claim 1 , wherein: the program subroutine for sending an e-mail source address depends on transmitting an HTTP-message via the Internet to an active server pages (ASP) equivalent application program operating on said webserver.
13. The system of claim 11 , wherein: the program subroutine for instructing said e-mail delivery system depends on transmitting an HTTP-message via the Internet from an active server pages (ASP) equivalent application program operating on said webserver.
14. The system of claim 11 , further comprising: a program subroutine for registering an e-mail source in said database such that the step of checking will approve of said e-mail message if originated by that e-mail source.
15. The system of claim 11 , further comprising: a program subroutine for preapproving a list of e-mail sources in said database such that the step of checking will allow delivery of said e-mail message if originated by any one of such e-mail sources.
16. The system of claim 11 , further comprising: a program subroutine for allowing an e-mail source to list itself in said database such that the step of checking will allow delivery of said e-mail message if originated b y such e-mail source.
17. The system of claim 11 , further comprising: a program subroutine for gathering identification information from an e-mail source not registered in said database; a program subroutine for testing whether said identification information is acceptable according to a minimum standard; and a program subroutine for allowing said e-mail source, if acceptable, to be listed h said database such that the step of checking will allow delivery of said e-mail message if originated by such e-mail source.
18. The system of claim 17, further comprising: a program subroutine for issuing a first token to an e-mail source previously not registered in said database; and a program subroutine for requiring said first token to be expired before the checking will allow delivery of said e-mail message when originated by such e-mail source.
19. The system of claim 17, further comprising: a program subroutine for issuing a second token to said e-mail source previously not registered in said database if said user validates them after having received and read one of their e-mail messages.
AMENDED CLAIMS
[received by the International Bureau on 3 January 2002 (03.01.02); original claims 1-19 replaced by new claims 1-18 (8 pages)]
REPLACEMENT CLAIMS
1. A method for stopping unwanted messages from being accepted in an
e-mail delivery system, comprising:
receiving an e-mail message from a sender via an SMTP-mail server;
parsing an address header from said e-mail message with an e-mail
delivery system;
sending an e-mail source address obtained in the step of parsing to a
webserver;
checking said e-mail source address against a list of source addresses
maintained in a database associated with said webserver;
instructing said e-mail delivery system from said webserver to deliver
or not-deliver said e-mail message to a user;
displaying said e-mail message at said e-mail delivery system to said
user if instructed to do so by said webserver;
disposing of said e-mail message at said e-mail delivery system if
instructed to do so by said webserver; and
allowing an e-mail source to list itself in said database such that the
step of checking will allow delivery of said e-mail message if originated by
such e-mail source.
2. The method of claim 1 , wherein:
the step of sending an e-mail source address depends on transmitting
an HTTP-message via the Internet to an active server pages (ASP) equivalent
application program operating on said webserver.
3. The method of claim 1 , wherein:
the step of instructing said e-mail delivery system depends on.
transmitting an HTTP-message via the Internet from an active server pages
(ASP) equivalent application program operating on said webserver.
4. The method of claim 1 , further comprising the step of:
registering an e-mail source in said database such that the step of
checking will approve of said e-mail message if originated by that e-mail
source.
5. The method of claim 1 , further comprising the step of:
preapproving a list of e-mail sources in said database such that the
step of checking will allow delivery of said e-mail message if originated by any
one of such e-mail sources.
6. The method of claim 1 , further comprising the steps of:
gathering identification information from an e-mail source not registered
in said database;
testing whether said identification information is acceptable according
to a minimum standard; and
if acceptable, allowing said e-mail source to be listed in said database
such that the step of checking will allow delivery of said e-mail message if
originated by such e-mail source.
7. The method of claim 6, further comprising the steps of:
issuing a first token to an e-mail source previously not registered in
said database; and
requiring said first token to be expired before the step of checking will
allow delivery of said e-mail message when originated by such e-mail source.
8. The method of claim 6, further comprising the steps of:
issuing a second token to said e-mail source previously not registered
in said database if said user validates them after having received and read
one of their e-mail messages.
9. An e-mail delivery system, comprising:
a webserver connected to a computer data network;
an SMTP-mail sever for providing the delivery of e-mail messages to a
user;
a spam-elimination system connected to receive said e-mail messages
from the SMTP-mail server;
a database of registered e-mail senders included in the webserver; and
means for allowing an e-mail source to list itself in said database:
wherein, the spam-elimination system transmits any e-mail source
address information included in any received e-mail messages to the
webserver;
wherein; the database is consulted for a registration listing matching
said e-mail source address information; and
wherein, the webserver provides for the instruction of the spam-
elimination system to deliver or not deliver to a user a particular e-mail
message.
10. The e-mail delivery system of claim 9, wherein the spam-elimination
system further includes:
a program subroutine for receiving an e-mail message from a sender
via said SMTP-mail server;
a program subroutine for parsing an address header from said e-mail
message with an e-mail delivery system;
a program subroutine for sending an e-mail source address obtained in
the step of parsing to a webserver;
a program subroutine for checking said e-mail source address against
a list of source addresses maintained in a database associated with said
webserver;
a program subroutine for instructing said e-mail delivery system from
said webserver to deliver or not-deliver said e-mail message to a user;
a program subroutine for displaying said e-mail message at said e-mail
delivery system to said user if instructed to do so by said webserver; and
a program subroutine for disposing of said e-mail message at said e-
mail delivery system if instructed to do so by said webserver.
11. The e-mail delivery system of claim 10, wherein:
the program subroutine for sending an e-mail source address depends
on transmitting an HTTP-message via the Internet to an active server pages
(ASP) equivalent application program operating on said webserver.
12. The e-mail delivery system of claim 10, wherein:
the program subroutine for instructing said e-mail delivery system
depends on transmitting an HTTP-message via the Internet from an active
server pages (ASP) equivalent application program operating on said
ebserver.
13. The e-mail delivery system of claim 10, further comprising:
a program subroutine for registering an e-mail source in said database
such that the step of checking will approve of said e-mail message if
originated by that e-mail source.
14. The e-mail delivery system of claim 10, further comprising:
a program subroutine for preapproving a list of e-mail sources in said
database such that the step of checking will allow delivery of said e-mail
message if originated by any one of such e-mail sources.
15. The e-mail delivery system of claim 10, wherein said means for
allowing an e-mail source to list itself in said database comprises a program
subroutine for allowing an e-mail source to list itself in said database such that
the step of checking will allow delivery of said e-mail message if originated by
such e-mail source.
16. The e-mail delivery system of claim 10, further comprising:
a program subroutine for gathering identification information from an e-
mail source not registered in said database;
a program subroutine for testing whether said identification information
is acceptable according to a minimum standard; and
a program subroutine for allowing said e-mail source, if acceptable, to
be listed in said database such that the step of checking will allow delivery of
said e-mail message if originated by such e-mail source.
17. The e-mail delivery system of claim 16, further comprising:
a program subroutine for issuing a first token to an e-mail source
previously not registered in said database; and
a program subroutine for requiring said first token to be expired before
the checking will allow delivery of said e-mail message when originated by
such e-mail source.
) 18. The e-mail delivery system of claim 16, further comprising:
a program subroutine for issuing a second token to said e-mail source
previously not registered in said database if said user validates them after
having received and read one of their e-mail messages.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AU2001291174A AU2001291174A1 (en) | 2000-09-21 | 2001-09-20 | E-mail spam elimination method and system |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US66803500A | 2000-09-21 | 2000-09-21 | |
| US09/668,035 | 2000-09-21 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2002025464A1 true WO2002025464A1 (en) | 2002-03-28 |
Family
ID=24680727
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/US2001/029571 WO2002025464A1 (en) | 2000-09-21 | 2001-09-20 | E-mail spam elimination method and system |
Country Status (2)
| Country | Link |
|---|---|
| AU (1) | AU2001291174A1 (en) |
| WO (1) | WO2002025464A1 (en) |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004046992A2 (en) * | 2002-11-20 | 2004-06-03 | Return Path, Inc. | Electronic message delivery with estimation approaches |
| WO2005052834A1 (en) * | 2003-11-14 | 2005-06-09 | Electronic Data Systems Corporation | System, method, and computer program product for filtering electronic mail |
| WO2005062561A1 (en) * | 2003-12-22 | 2005-07-07 | All About It S.A.R.L. | Method and device for blocking undesired emails |
| EP1635291A1 (en) * | 2004-09-10 | 2006-03-15 | France Telecom | Unsolicited messages detection agent and process |
| GB2420045A (en) * | 2004-11-02 | 2006-05-10 | Ricky Charles Rand | Regulating electronic mail |
| US7219131B2 (en) | 2003-01-16 | 2007-05-15 | Ironport Systems, Inc. | Electronic message delivery using an alternate source approach |
| US7293065B2 (en) | 2002-11-20 | 2007-11-06 | Return Path | Method of electronic message delivery with penalties for unsolicited messages |
| WO2008108183A1 (en) * | 2007-02-27 | 2008-09-12 | Digital Arts Inc. | Method and system for electronic mail processing |
| US7577708B2 (en) | 2004-12-10 | 2009-08-18 | Doron Levy | Method for discouraging unsolicited bulk email |
| US7653695B2 (en) | 2004-02-17 | 2010-01-26 | Ironport Systems, Inc. | Collecting, aggregating, and managing information relating to electronic messages |
| US7748038B2 (en) | 2004-06-16 | 2010-06-29 | Ironport Systems, Inc. | Method and apparatus for managing computer virus outbreaks |
| US7756930B2 (en) | 2004-05-28 | 2010-07-13 | Ironport Systems, Inc. | Techniques for determining the reputation of a message sender |
| US7849142B2 (en) | 2004-05-29 | 2010-12-07 | Ironport Systems, Inc. | Managing connections, messages, and directory harvest attacks at a server |
| US7870200B2 (en) | 2004-05-29 | 2011-01-11 | Ironport Systems, Inc. | Monitoring the flow of messages received at a server |
| US7873695B2 (en) | 2004-05-29 | 2011-01-18 | Ironport Systems, Inc. | Managing connections and messages at a server by associating different actions for both different senders and different recipients |
| US7917588B2 (en) | 2004-05-29 | 2011-03-29 | Ironport Systems, Inc. | Managing delivery of electronic messages using bounce profiles |
| US7970832B2 (en) | 2002-11-20 | 2011-06-28 | Return Path, Inc. | Electronic message delivery with estimation approaches and complaint, bond, and statistics panels |
| US8028026B2 (en) | 2006-05-31 | 2011-09-27 | Microsoft Corporation | Perimeter message filtering with extracted user-specific preferences |
| DE102010025378A1 (en) | 2010-06-28 | 2011-12-29 | Siemens Aktiengesellschaft | Method for automatic and selective access control of distribution of mail at mail box, involves loading user-specific setting information on mobile apparatus of postman by post delivery service |
| US8166310B2 (en) | 2004-05-29 | 2012-04-24 | Ironport Systems, Inc. | Method and apparatus for providing temporary access to a network device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5930479A (en) * | 1996-10-21 | 1999-07-27 | At&T Corp | Communications addressing system |
| US6023723A (en) * | 1997-12-22 | 2000-02-08 | Accepted Marketing, Inc. | Method and system for filtering unwanted junk e-mail utilizing a plurality of filtering mechanisms |
| US6266692B1 (en) * | 1999-01-04 | 2001-07-24 | International Business Machines Corporation | Method for blocking all unwanted e-mail (SPAM) using a header-based password |
-
2001
- 2001-09-20 WO PCT/US2001/029571 patent/WO2002025464A1/en active Application Filing
- 2001-09-20 AU AU2001291174A patent/AU2001291174A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5930479A (en) * | 1996-10-21 | 1999-07-27 | At&T Corp | Communications addressing system |
| US6023723A (en) * | 1997-12-22 | 2000-02-08 | Accepted Marketing, Inc. | Method and system for filtering unwanted junk e-mail utilizing a plurality of filtering mechanisms |
| US6266692B1 (en) * | 1999-01-04 | 2001-07-24 | International Business Machines Corporation | Method for blocking all unwanted e-mail (SPAM) using a header-based password |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7293065B2 (en) | 2002-11-20 | 2007-11-06 | Return Path | Method of electronic message delivery with penalties for unsolicited messages |
| WO2004046992A3 (en) * | 2002-11-20 | 2004-07-08 | Ironport Systems Inc | Electronic message delivery with estimation approaches |
| WO2004046992A2 (en) * | 2002-11-20 | 2004-06-03 | Return Path, Inc. | Electronic message delivery with estimation approaches |
| US7970832B2 (en) | 2002-11-20 | 2011-06-28 | Return Path, Inc. | Electronic message delivery with estimation approaches and complaint, bond, and statistics panels |
| US7219131B2 (en) | 2003-01-16 | 2007-05-15 | Ironport Systems, Inc. | Electronic message delivery using an alternate source approach |
| WO2005052834A1 (en) * | 2003-11-14 | 2005-06-09 | Electronic Data Systems Corporation | System, method, and computer program product for filtering electronic mail |
| WO2005062561A1 (en) * | 2003-12-22 | 2005-07-07 | All About It S.A.R.L. | Method and device for blocking undesired emails |
| US7653695B2 (en) | 2004-02-17 | 2010-01-26 | Ironport Systems, Inc. | Collecting, aggregating, and managing information relating to electronic messages |
| US7756930B2 (en) | 2004-05-28 | 2010-07-13 | Ironport Systems, Inc. | Techniques for determining the reputation of a message sender |
| US7870200B2 (en) | 2004-05-29 | 2011-01-11 | Ironport Systems, Inc. | Monitoring the flow of messages received at a server |
| US7849142B2 (en) | 2004-05-29 | 2010-12-07 | Ironport Systems, Inc. | Managing connections, messages, and directory harvest attacks at a server |
| US7873695B2 (en) | 2004-05-29 | 2011-01-18 | Ironport Systems, Inc. | Managing connections and messages at a server by associating different actions for both different senders and different recipients |
| US8166310B2 (en) | 2004-05-29 | 2012-04-24 | Ironport Systems, Inc. | Method and apparatus for providing temporary access to a network device |
| US7917588B2 (en) | 2004-05-29 | 2011-03-29 | Ironport Systems, Inc. | Managing delivery of electronic messages using bounce profiles |
| US7748038B2 (en) | 2004-06-16 | 2010-06-29 | Ironport Systems, Inc. | Method and apparatus for managing computer virus outbreaks |
| EP1635291A1 (en) * | 2004-09-10 | 2006-03-15 | France Telecom | Unsolicited messages detection agent and process |
| GB2420045B (en) * | 2004-11-02 | 2009-04-01 | Ricky Charles Rand | A method and system for regulating electronic mail |
| GB2420045A (en) * | 2004-11-02 | 2006-05-10 | Ricky Charles Rand | Regulating electronic mail |
| US7577708B2 (en) | 2004-12-10 | 2009-08-18 | Doron Levy | Method for discouraging unsolicited bulk email |
| US7853660B2 (en) | 2004-12-10 | 2010-12-14 | Doron Levy | Method for discouraging unsolicited bulk email |
| US8028026B2 (en) | 2006-05-31 | 2011-09-27 | Microsoft Corporation | Perimeter message filtering with extracted user-specific preferences |
| WO2008108183A1 (en) * | 2007-02-27 | 2008-09-12 | Digital Arts Inc. | Method and system for electronic mail processing |
| DE102010025378A1 (en) | 2010-06-28 | 2011-12-29 | Siemens Aktiengesellschaft | Method for automatic and selective access control of distribution of mail at mail box, involves loading user-specific setting information on mobile apparatus of postman by post delivery service |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2001291174A1 (en) | 2002-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2002025464A1 (en) | E-mail spam elimination method and system | |
| US7822977B2 (en) | System for eliminating unauthorized electronic mail | |
| US8176531B2 (en) | System for eliminating unauthorized electronic mail | |
| US9356947B2 (en) | Methods and systems for analyzing data related to possible online fraud | |
| US6868498B1 (en) | System for eliminating unauthorized electronic mail | |
| US7620690B1 (en) | Privacy control system for electronic communication | |
| US7546349B1 (en) | Automatic generation of disposable e-mail addresses | |
| US7853660B2 (en) | Method for discouraging unsolicited bulk email | |
| US20060036701A1 (en) | Messaging system having message filtering and access control | |
| US20020138581A1 (en) | System and method for creating and managing forwarding email address | |
| US20060253597A1 (en) | E-mail system | |
| US20040249895A1 (en) | Method for rejecting SPAM email and for authenticating source addresses in email servers | |
| US9313158B2 (en) | Message challenge response | |
| US20060271629A1 (en) | Distributed Challenge and Response Recognition System | |
| US20080104188A1 (en) | Message Challenge Response | |
| US7461397B2 (en) | Customized electronic messaging | |
| US20040243847A1 (en) | Method for rejecting SPAM email and for authenticating source addresses in email servers | |
| Leiba et al. | A Multifaceted Approach to Spam Reduction. | |
| WO2005001733A1 (en) | E-mail managing system and method thereof | |
| US20070294351A1 (en) | Method for the Monitoring the Transmission of Electronic Messages | |
| US7558829B1 (en) | Apparatus and method for filtering email using disposable email addresses | |
| US7409206B2 (en) | Defending against unwanted communications by striking back against the beneficiaries of the unwanted communications | |
| US20060026107A1 (en) | Mechanisms for waiving or reducing senders' liability in bonded electronic message systems while preserving the deterrent effect of bonds | |
| JP2004523012A (en) | A system to filter out unauthorized email | |
| Smith | " Spam": An Overview of Issues Concerning Commercial Electronic Mail |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
| 122 | Ep: pct application non-entry in european phase | ||
| NENP | Non-entry into the national phase |
Ref country code: JP |