WO2005008983A2 - Method for anti-spam e-mail management - Google Patents

Method for anti-spam e-mail management Download PDF

Info

Publication number
WO2005008983A2
WO2005008983A2 PCT/IB2004/050687 IB2004050687W WO2005008983A2 WO 2005008983 A2 WO2005008983 A2 WO 2005008983A2 IB 2004050687 W IB2004050687 W IB 2004050687W WO 2005008983 A2 WO2005008983 A2 WO 2005008983A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
sender
file
iddb
received
Prior art date
Application number
PCT/IB2004/050687
Other languages
French (fr)
Other versions
WO2005008983A3 (en
Inventor
Diego Angelo Tomaselli
Original Assignee
Diego Angelo Tomaselli
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Diego Angelo Tomaselli filed Critical Diego Angelo Tomaselli
Publication of WO2005008983A2 publication Critical patent/WO2005008983A2/en
Publication of WO2005008983A3 publication Critical patent/WO2005008983A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking

Definitions

  • the present invention relates to a method and to a corresponding anti-spam computer product to avoid accumulating undesired messages in an electronic mailbox.
  • spam messages will be continued to be referred to, by designating under this term those not requested e-mail messages, sent in a way so that the sender cannot be easily detected, for advertisement purposes or other.
  • sofar limit to filter the incoming messages based upon predetermined rules, for example, by analyzing the words included in the message subject or in the body text thereof and eliminating those messages containing the words which have been previously inserted in a file of "not allowed" words.
  • the system of this most advanced type can be easily sidestepped thanks to a specific utilization of the search engines: in fact, currently the safest way for identifying an advertising mail is to isolate and search for the Internet address thereat the advertisement in question is linked, since the words utilized for the advertisement thereof can be easily created in a random way, whereas the advertisement subject, that is the advertised Internet site, cannot be always different, since this would have a cost; therefore, the most advanced anti-spam systems create lists of internet sites advertised inside the spam and they check if a mail is spam or not through the search for such addresses inside the messages subjected to the check.
  • the spammer in fact, needs only to replace the link to the site to be advertised with a link to a search engine, by re-setting such link so that the opening thereof automatically generates a search for such search engine and the result of such research shows the advisement subject site; in order to reach this aim with the certainty to make result just the wished site among the search's results, the spammer needs only to enter some specific key words inside the advertised site and to utilize such words in the pre-set search: since they are not common words, but specific key words, the spammer can be almost sure that the search will generate the advertisement subject site only as visible result to the user.
  • a possible solution is to create a computer program which browses inside the links existing inside the message subjected to the check (that is, by starting the search set by the spammer), to search for possible links inside the so-opened page (that is among the search results) and to check thereamong the presence of a possible internet site causing spamming, that is already detected previously as end target of not wished advertisement messages.
  • An object of the present invention is to solve the problems mentioned above, by providing a method for the anti-spam management of an e-mail message received in a mailbox, as described in claim 1.
  • An additional object of the present invention is to provide a method for identifying hidden links starting from a first link to a web page included in an e-mail message, as defined in claims 32 or 33.
  • An additional object of the present invention is to provide a computer product for implementing a method according to the present invention, as described in claim 34 or 35.
  • the main advantage of the method according to the present invention is given by the fact that it acts in an extremely effective and automatized way, without requiring any intervention and/or any action by the users (sender and/or recipient).
  • the system according to the present invention intervenes cyclically in an automatic way on the received messages, checking the legitimacy thereof. Such check does not depend upon any action of the message's sender (reply to the request for confirmation), thus the management process of each message is considerably fastest and easiest.
  • the invention does not necessarily requires that the received messages be held in a stand-by state before being able to be checked and/or read, but it checks the messages when they are already in the InBox, without moving anyone thereof and therefore leaving at the user's disposal, in any case, all the messages, thereamong there could be some urgent.
  • This does not exclude the possibility of maintaining separate, or however visually distinct to the user's sight, the surely secure messages from the ones still in the checking step: in fact, in order to distinguish them it is sufficient considering as checked the messages coming from authorized senders.
  • the computer program according to the present invention is executed at predefined intervals. It does not act upon receiving a new message only, but it monitors continuously the content of the user's mailbox.
  • figure 1 is a flow chart schematizing roughly the program's operating principle which implements the method according to the present invention
  • figure 2 is a flow chart related to the program portion which processes and manages the received messages considered with doubtful sender
  • figure 3 is a flow chart illustrating the complete flow of the method according to the present invention.
  • the method according to the present invention exploits a feature common to almost all spammers (under this term the users sending spam messages are designated hereinafter), that is the fact of sending spam by a not-existing e-mail address, or of anonymous and free type, or stolen type.
  • This feature is substantially always checked for obvious reasons, both legal (since in many countries, as in Italy, their activity is illegal) and practical ones. In fact, should they use real addresses it would be simple to filter them, since it would be sufficient to lock the sender, who, being real, could not result always different, as it happens nowadays.
  • the object of the method according to the present invention is to "manage" the messages coming from unknown senders (that is, which previously have not ever written to the sender's address) to understand if it is a valid and functioning e-mail address or if it is an address invented by a spammer and therefore a false or stolen one.
  • the sender of an e-mail message will be continued to be referred to, wishing to designate under this term the sender's e-mail address or the sender's domain or the sender's domain owner of the checked e-mail message.
  • the flow chart of figure 1 roughly schematizes the working principle of the program implementing the method according to the present invention.
  • the program checks the presence of e-mail messages in a user's mailbox. Under the term InBox also possible subfolders are wanted to be included, which, for example, could be useful to maintain the checked messages separated from the ones still to be subjected to the check. If there are no received messages, the program ends (remaining obviously active to check the possible presence of new messages at regular intervals), otherwise it proceeds in analyzing the first message (the messages' sequence is not important, it could be for example the reception order, that it from the oldest to the most recent message). Then, the received message is processed and managed, as it will be explained in details hereinafter. Then, if there are no additional messages, the program ends, otherwise it proceeds in analyzing the subsequent message.
  • the program can be executed cyclically according to pre-established time intervals (even if this does not exclude the activation thereof upon receiving a new message).
  • the regularity and the frequency of such intervals do not change the system effectiveness, but the efficiency thereof only.
  • the following figure 2 is a flow chart related to the program portion which processes and manages each of the received messages, when it is interpreted as a message with doubtful sender.
  • the idea underlying the invention is to analyze all the received messages existing in the InBox, without moving any of them (thus leaving at the user's disposal all messages, thereamong there could be urgent ones, even if this does not exclude the possibility of distinguishing the secure messages from the ones still to be subjected to the check).
  • IDDB codes corresponding to the sent test message.
  • the ID code created in a wholly random way by the system, can be numerical or alphanumerical, since it is unique and biunivocally associated to a test message. Then, the ID code is written in the sent test message (in the message's subject or body text or even inside the e-mail addresses of the involved users) and it will be then extracted by a possible "delivery error” or “denial” message, if received, for the subsequent checks, as it will be explained in more details hereinafter.
  • the sender the sender's e-mail address and the alias thereof
  • the subject of the received message the subject of the received message
  • despatch date and time of the test message will be then utilized to check certain conditions and to perform then pre-established operations for managing the messages.
  • the flow chart of figure 3 illustrates the whole flow, but not limitative, of the method according to the present invention.
  • the program is activated at regular time intervals, for example each minute, but this time it can vary according to the required performances or it can become also irregular (for example if activated upon receiving a new message) without overloading the system, in order to monitor constantly the user's mailbox.
  • the method provides a step of eliminating (or moving) the received message from the user's mailbox, in case the sender is included in the first file of blocked senders or, indeed, is clearly wrong or wholly absent. After the elimination, it is always appropriate to send a notice to the sender. ⁇ Are there ID in the msg?> On the contrary, if the sender's address is not among the locked ones, the program checks if the received message is a delivery error or denial message following a previously sent test message.
  • the extracted ID is not included in the IDDB file, it could be, for example, a test message coming from another user utilizing the same system.
  • the method provides a step of checking if a message was previously sent which, in turn, was subjected to a test by another user utilizing the same system and who thus generated the currently received message.
  • Such check can be carried out automatically if the system can access to a file of sent mail; if this is not possible, the system, however, can translate the test message into the user's language, obviously maintaining unchanged the references to the message subjected to the check.
  • This translation avoids that a spammer tries accessing to the user's mailbox by adding a fictitious ID inside the advertisement thereof, considering that said translation would wholly eliminate what is not pertinent to a correctly formatted test message: in other words, the translation would consist in searching inside the message for the fields related to the subject, to the despatch date and to the recipients of the message subjected to the check, in order then to utilize them to create again a test message corresponding to what is expected by the user, both as far as the language is concerned and as far as the corresponding explanation related to the system operation (that is, basically the instructions useful to deny to have ever sent the message in question) is concerned.
  • the method provides a step of checking if the sender's address is included in a third file of authorized senders. ⁇ Is the sender or domain authorized?> If the sender's address (or the sender's mail domain) results in the file of the senders authorized to send mail to the user, the program continues without intervening and it proceeds in analyzing possible subsequent messages, otherwise additional control and/or check steps are activated.
  • the messages the size thereof exceeds a pre-established threshold can be considered as authorized, since the spammers have to send millions of messages in order to have an economic gain and therefore they cannot allow themselves to send too big messages. Furthermore, it may happen that the user has sent manually a message to a wrong address.
  • a message's content includes references bringing back to a message previously sent by the user (for example, if the message includes the subject or the address of a recipient equal to what has been found in the sent mail) since the delivery service shows these data indeed to communicate that a certain message has not been delivered to a certain address.
  • such message can be considered as coming from an authorized sender, even if only thanks to this particular content thereof (the reference to a message sent manually by the user). In this way, the user is informed about a failed delivery, but a possible spammer cannot utilized this input way since he/she is not able to know what the user has previously sent manually.
  • the method provides a step of generating a new ID (for example, a random number) and of associating such ID to a test message to be sent to the sender of the received message, together with a brief text explaining the function thereof and thus explaining that the test message is used only to check that the sender's address does not generate errors and to confirm that the sender's address has not been falsified.
  • the test message includes references to the message subjected to the check, for example stating the subject, the despatch date and the recipients.
  • the method advantageously provides the elimination of possible ID existing in the original message, which is enclosed to (or simply mentioned in) the test message which, once received, can be then eliminated by the user (if also the sender adopts the same anti-spam system, the test message recognized as such can be deleted automatically) or, in case the user who receives it does not recognize to have ever sent the message in question (enclosed or mentioned by the test message), he/she could also signal to not recognize it (to deny it).
  • the "denial" could occur in a semi-automatic way, for example by pressing a button or a hyperlink included in the test message, so that this does not automatically generate a message replying to the test message, which still includes the sent ID, in order to be able to be recognized by the program.
  • the use of a hyperlink can involve the advantage of distinguishing with greatest certainty the ones which are really denial messages from the ones which could be simple requests for clarification sent as reply to the test message.
  • Another possible technique to try to minimize this kind of risk (the sender asks for clarifications and he/she replies to a test message, but he/she does not wish to deny to have sent a message) is constituted by the proper modification of the alias of the Reply-To field, so that the denials and the possible requests for clarification arrive always at the same address, however allowing the receiving system to distinguish the requests for clarification (that is the simple replies) since the corresponding alias results to be modified as shown in the Reply-To field.
  • the test message includes a hyperlink enabling the sender to deny, that is to send a reply, but this time without modifying the alias as shown by the Reply-To field.
  • the modification of the alias in the Reply-To field can be utilized however to further inform the user who is going to reply to a test message that a reply despatch constitutes a denial and therefore the corresponding message, therefor the test message has been sent, will be deleted, if he/she proceeds in replying to the test message.
  • the program proceeds in storing in the IDDB file the data of the managed message. In particular, as already illustrated, the ID, the sender, the subject (or the message's body text) and the despatch time of the test message.
  • the flow can proceed in analyzing a possible subsequent message, if existing, otherwise ending by waiting for the arrival of new messages.
  • the sender of the received message is the same one stored in the record of the IDDB file corresponding to the ID extracted from the received message, then it means that it is not a real signalling error and the sender has a real address, otherwise the reply containing the ID would have come from a third server and not from the sender directly (typical in case of error).
  • the case can be brought back wherein whoever receives a test message replies thereto (and denies it) in order not to recognize the paternity thereof and in this case it would not be correct blocking the sender by inserting him her in the list of the blocked senders.
  • the method according the invention preferably can be repeated periodically, according to a first pre-established period of time, for example each minute, so as to detect substantially in real time the received new messages and to manage them according to the rules described sofar, but it can also be activated upon receiving a new message.
  • the method according to the present invention can include a step, repeated periodically too, of eliminating from the file all the old registrations carried out before a pre-established period, for example 24 hours.
  • Such step of eliminating all old registrations includes a process which analyzes the IDDB file and it acts on the oldest registrations (for example 24 hour or more old), by deleting them. Practically, it "clears" the file (the error messages usually arrive within 24 hours). Moreover, upon deleting the registrations, advantageously this process can add the corresponding addresses in the file of the authorized addresses, since for these users no error or denial has arrived within 24 hours from the test message despatch. In this way, in future the test message will not ever sent to these senders. Obviously, this step can be subjected to the user's confirmation, who can decide then if authorizing the single sender in question or the whole domain thereof.
  • the method according to the present invention can also include a step of storing the sender's address in the file of the blocked addresses, when the received message is eliminated manually from a user's mailbox without being read. In case, such registering step can be conditioned to a confirmation step by the user.
  • Example 1 A "real" user A (not a spammer) sends an e-mail to the user B (who is currently using a computer program implementing the method according to the present invention), the subject thereof is, for example, "curriculum vitae".
  • the e-mail system of B receives the message of A.
  • the anti-spam program When the anti-spam program is executed, it detects the presence of the message received in the mailbox (InBox) of B. Then, it analyzes the message, in particular it checks the sender' address thereof (for example userA@users.com), which does not exist in the file of blocked addresses. Then, the system proceeds in analyzing the whole content of the message, searching for a ID in the message's subject, in the message's text and in the names of possible enclosures.
  • the program checks if the sender userA@users.com is instead in the file of the authorized addresses, but considering that the sender userA@users.com is unknown, the search result is negative. Before proceeding in sending a test message to the user A, the program checks if in the IDDB file a registration of a test message sent to the same userA@users.com already exists, so as not to enter an endless loop. Considering that it is the first time that userA@users.com writes to B, it does not result any registration.
  • the program proceeds in generating a random ID, which, for example, could be 1234567, then it will proceed in sending a test message to userA@users.com, whose subject could be something like: "Curriculum Nitae -TEST MESSAGE ⁇ ID>1234567 ⁇ /ID>", and the content thereof could be "This mail has been sent by an automatic anti-spam system in order to check the existence and functionality of the userA@users.com address. If one wants to deny to have sent the enclosed message, click the button [DENY] (or reply to the present message)".
  • the test message then, includes as enclosure the message "curriculum vitae" sent originally from A to B (or it shows the data thereof, as the subject).
  • the button [DENY] only generates a message replying to the test message: if a user replies to the test message, this will be then interpreted as a denial. Then, the program stores in the IDDB file the data of the sent test message: to whom it was sent (userA@users.com), with which ID (123467), which was the message to be checked (curriculum vitae) and at what time it was sent (02/07/2003 - 17:03). In the meantime, the message of A can be marked, in case, as not yet checked or it can be moved in a subfolder. Then, the program waits for being re-started again at regular intervals to check the returning of possible error messages.
  • the system proceeds in doing nothing, in case it moves or marks this message too as not yet checked.
  • the message then, remains at disposal of the user B, who then arranges an appointment for the following week.
  • the function "clearing" the IDDB file finds the registration of the message "curriculum vitae" which, as it is not yet present, means that the test message sent to userA@users.com has not yet generated errors, therefore it proceeds in inserting the address of this sender in the file of authorized addresses and it deletes the corresponding registration from the IDDB. If the messages had been moved or marked, it provides in marking them as authorized or in moving them in the same folder of the authorized messages. Once arrived the following week, A sends to B a confirmation message for the appointment.
  • Example 2 A spammer user A sends an advertising email to B, the subject thereof is "Money for you" and the sender thereof results to be spammer@spammers.com. Considering that spamming is illegal and considering that the spammer does not want to be blocked by any kind of filter applied by the sender, the supplied address (spammer@spammers.com) is obviously false, so as to be easily changed and so as to make the real spammer difficult to be traced.
  • the mail system of B receives the mail of A and when the anti-spam program is started, it detects the presence of the message in the InBox of B and it starts to analyze it. This means that first of all it analyzes the sender, which, for example, is spammer@spammers.com, which cannot be found in the file of the blocked senders. Then, the system proceeds in analyzing the whole content of the message, that is it looks for a valid ID in the message's subject, in the message's text and in the names of possible enclosures. If it finds it, it extracts it and searches for the extracted ID inside the IDDB file. In example case the ID is not found, since it is an advertising message.
  • the system checks if the sender spammer@spammers.com is in the file of the authorized addresses, instead. But considering that the sender sparrimer@spammers.com is unknown, the search result is negative. Before proceeding in sending a test message to the user A, the system checks if in the IDDB file a registration of a test message sent to the same spammer@spammers.com already exists, so as not to enter an endless loop. Considering that it is the first time that spammer@spammers.com writes to B, no registration results.
  • the program proceeds in generating a random ID, which for example could be ABC123DEF, then it will proceed in sending a mail to sparnmer@spammers.com, the subject thereof could be for example: "Money for you -TEST MESSAGE ⁇ ID>ABC123DEF ⁇ /ID>", and the content thereof could be "This mail has been sent by an automatic anti-spam system in order to check the existence and functionality of the address spammer@spammers.com. If one wants to deny to have sent the enclosed message, click the button [DENY]".
  • the program stores in the IDDB file the data of the sent test message: to whom it has been sent (spammer@spammers.com), with which ID (ABC123DEF), which was the message to be checked (Money for you) and when it has sent it (02/07/2003 - 17:03).
  • the message of A can be marked, in case, as not yet checked or it can be moved in a subfolder.
  • the program waits for being re-executed at regular intervals to check the return of possible error messages.
  • the last mail server involved in the process (it is not important if it is the server of B or a third server) signals with a mail (for example "Mail Delivery Failure"", sent for example by "postmaster@servers.com") that the user spammer@sparnmers.com cannot receive email, enclosing the message sent thereto ("Money for you -TEST MESSAGE ⁇ ID>ABC123DEF ⁇ /ID>").
  • the mail system of B receives the error signalling mail (Mail Delivery Failure).
  • the program performs again all the checks as already described, but in this case in one of the message's enclosures, the string ⁇ ID> is found, which by convention precedes the univocal identification generated at time of the test message despatch.
  • the program extracts the identification comprised between ⁇ ID> and ⁇ /ID> (that is "ABC123DEF”) and it search for it inside the IDDB file, by finding it, together with the data related to the message. Then, it is checked that the sender of this message (postmaster@servers.com) is not the same registered in the IDDB file (spammer@spammers.com) and therefore, the program proceeds in blocking spammer@spammers.com definitively (as address which has generated an error signalled by a third server, postmaste@servers.com) in case asking for confirmation to the user B to block also all the domain spammers.com and the owner thereof (the firm or the person which results to be the owner of the mail domain), so that in future all messages coming from these individuals are automatically eliminated.
  • spammer@spammers.com definitively (as address which has generated an error signalled by a third server, postmaste@servers.com) in case asking for confirmation to the user B to block also all the domain spammers.com and the owner
  • the original message registered in the IDDB file (Money for you) is eliminated from the InBox of the user B, as well as the corresponding registration is deleted Then, the system eliminates also the error signalling message (Mail Delivery Failure). Then, the system proceeds in analyzing the remaining messages. If the system finds additional messages coming from spammer@spammers.com (or even only by spammers.com if the whole domain has been blocked), it will provide in eliminating them automatically.
  • the present invention has been described sofar according to a preferred embodiment thereof, illustrated by way of example and not for limitative purposes. It is to be meant that other embodiments can exist, all however comprised within the protective scope of the present invention, as defined by the enclosed claims.

Abstract

A method for anti-spam management of an e-mail message received in a mailbox comprises a step of determining if the received message is to be considered an authorized message or not and, when the received message is not considered an authorized message, the steps of sending a test message to the sender’s e-mail address of the received e-mail message, checking the reception of a “delivery error” or “denial” message corresponding to the test message, obtaining an error information and managing the received e-mail message based upon the error information, deleting the e-mail message from the mailbox if the error information designate the occurred reception of the “delivery error” or “denial” message.

Description

"METHOD FOR ANTI-SPAM E-MAIL MANAGEMENT" DESCRIPTION The present invention relates to a method and to a corresponding anti-spam computer product to avoid accumulating undesired messages in an electronic mailbox. For clarity, hereinafter in this description spam messages will be continued to be referred to, by designating under this term those not requested e-mail messages, sent in a way so that the sender cannot be easily detected, for advertisement purposes or other. Most part of anti-spam systems utilized sofar limit to filter the incoming messages based upon predetermined rules, for example, by analyzing the words included in the message subject or in the body text thereof and eliminating those messages containing the words which have been previously inserted in a file of "not allowed" words. However, such systems do not manage the messages in an intelligent way and they can easily make errors, especially in the Anglophone countries, eliminating legitimate messages or considering legitimate spam messages only because the file of "not allowed" words is not updated or incomplete. Furthermore, since they are based only upon applying filters on words, obviously they can be easily sidestepped. Also the system of this most advanced type can be easily sidestepped thanks to a specific utilization of the search engines: in fact, currently the safest way for identifying an advertising mail is to isolate and search for the Internet address thereat the advertisement in question is linked, since the words utilized for the advertisement thereof can be easily created in a random way, whereas the advertisement subject, that is the advertised Internet site, cannot be always different, since this would have a cost; therefore, the most advanced anti-spam systems create lists of internet sites advertised inside the spam and they check if a mail is spam or not through the search for such addresses inside the messages subjected to the check. But such mechanism can be easily sidestepped: the spammer, in fact, needs only to replace the link to the site to be advertised with a link to a search engine, by re-setting such link so that the opening thereof automatically generates a search for such search engine and the result of such research shows the advisement subject site; in order to reach this aim with the certainty to make result just the wished site among the search's results, the spammer needs only to enter some specific key words inside the advertised site and to utilize such words in the pre-set search: since they are not common words, but specific key words, the spammer can be almost sure that the search will generate the advertisement subject site only as visible result to the user. It is to be noted that the anti-spam system trying to block such messages based upon the key words included in the link generating a particular search would be almost useless, since there is no limit to the number of key words which is possible to enter inside a web site and therefore there is no limit to the number of different links which is possible to create for reaching such site through a search carried out with such key words. A possible solution is to create a computer program which browses inside the links existing inside the message subjected to the check (that is, by starting the search set by the spammer), to search for possible links inside the so-opened page (that is among the search results) and to check thereamong the presence of a possible internet site causing spamming, that is already detected previously as end target of not wished advertisement messages. In this way, in fact, it is possible checking in an automatic way which is the real advertisement target of a spam campaign, otherwise constituted by messages with links always different and therefore which cannot be grouped and consequently which can hardly be blocked. Nevertheless, such systems, even the most advanced ones, imply a continuous maintenance of the files containing the spam words and index sites. Those programs which, in order to understand if a message is a spam or not, try to understand if the e-mail address therefrom it was sent is valid or not, belong to a second category of anti-spam systems. These programs send automatically to the unknown sender a so-called "request for confirmation" e-mail, that is a message wherein it is simply asked to reply in order to confirm that one's own e-mail address is valid. If the sender receives the message of "request for confirmation" and replies thereto, the system receives the "confirmation", it classifies the original e-mail message as legitimate and, in case, it moves it in the box of received messages (InBox). On the contrary, if this confirmation does not arrive within a predetermined period of time, the "pending" messages are cancelled once for all without the need for the user to see them. However, also this system type can incur errors and serious malfunctions. First of all, they have the considerable disadvantage of obliging a message's sender to receive a message of "request for confirmation" and to reply thereto immediately in order to "identify" himself/herself as authorized sender. Therefore, a message's recipient, before being able to receive and read an incoming e-mail, has to wait that the sender (if human) receives the request for confirmation, that he/she understands it and replies thereto. If the sender is an automatized system, the message has to be manually recovered by the recipient, as the system is not able to understand what is necessary to do so that the message is regularly delivered. Moreover, cases can occur wherein such systems cause the uncontrolled despatch of messages of "request for confirmation", entering an infinite loop with no way out. This can occur, for example, in case a message's recipient has activated the "automatic reply" function in case of absence, as it often occurs in the big companies. In fact, such messages, not corresponding to the basic rules which the system expects to receive, make the checking mechanism to start again, with new despatches of requests for confirmation. Obviously, this can involve a high possibility of damaging the fundamental working tool of highly professional users. An object of the present invention is to solve the problems mentioned above, by providing a method for the anti-spam management of an e-mail message received in a mailbox, as described in claim 1. An additional object of the present invention is to provide a method for identifying hidden links starting from a first link to a web page included in an e-mail message, as defined in claims 32 or 33. An additional object of the present invention is to provide a computer product for implementing a method according to the present invention, as described in claim 34 or 35. The main advantage of the method according to the present invention is given by the fact that it acts in an extremely effective and automatized way, without requiring any intervention and/or any action by the users (sender and/or recipient). The system according to the present invention intervenes cyclically in an automatic way on the received messages, checking the legitimacy thereof. Such check does not depend upon any action of the message's sender (reply to the request for confirmation), thus the management process of each message is considerably fastest and easiest. An additional advantage deriving from applying the present invention is given by the fact that the invention does not necessarily requires that the received messages be held in a stand-by state before being able to be checked and/or read, but it checks the messages when they are already in the InBox, without moving anyone thereof and therefore leaving at the user's disposal, in any case, all the messages, thereamong there could be some urgent. This does not exclude the possibility of maintaining separate, or however visually distinct to the user's sight, the surely secure messages from the ones still in the checking step: in fact, in order to distinguish them it is sufficient considering as checked the messages coming from authorized senders. The computer program according to the present invention is executed at predefined intervals. It does not act upon receiving a new message only, but it monitors continuously the content of the user's mailbox. Should it intervene only upon receiving a new message, it could apply its own filters to future messages only and not also to the already received ones, since said filters configurate and thus they change automatically as time passes. These and additional advantages, as well as the features and the application modes of the present invention will be evident from the following detailed description of one of the preferred embodiments thereof, illustrated by way of example and not for limitative purposes, by referring to the figures of the enclosed drawings, wherein: figure 1 is a flow chart schematizing roughly the program's operating principle which implements the method according to the present invention; figure 2 is a flow chart related to the program portion which processes and manages the received messages considered with doubtful sender; and figure 3 is a flow chart illustrating the complete flow of the method according to the present invention. The method according to the present invention exploits a feature common to almost all spammers (under this term the users sending spam messages are designated hereinafter), that is the fact of sending spam by a not-existing e-mail address, or of anonymous and free type, or stolen type. This feature is substantially always checked for obvious reasons, both legal (since in many countries, as in Italy, their activity is illegal) and practical ones. In fact, should they use real addresses it would be simple to filter them, since it would be sufficient to lock the sender, who, being real, could not result always different, as it happens nowadays. Then, the object of the method according to the present invention is to "manage" the messages coming from unknown senders (that is, which previously have not ever written to the sender's address) to understand if it is a valid and functioning e-mail address or if it is an address invented by a spammer and therefore a false or stolen one. Hereinafter in this description the sender of an e-mail message will be continued to be referred to, wishing to designate under this term the sender's e-mail address or the sender's domain or the sender's domain owner of the checked e-mail message. The flow chart of figure 1, roughly schematizes the working principle of the program implementing the method according to the present invention. The program checks the presence of e-mail messages in a user's mailbox. Under the term InBox also possible subfolders are wanted to be included, which, for example, could be useful to maintain the checked messages separated from the ones still to be subjected to the check. If there are no received messages, the program ends (remaining obviously active to check the possible presence of new messages at regular intervals), otherwise it proceeds in analyzing the first message (the messages' sequence is not important, it could be for example the reception order, that it from the oldest to the most recent message). Then, the received message is processed and managed, as it will be explained in details hereinafter. Then, if there are no additional messages, the program ends, otherwise it proceeds in analyzing the subsequent message. According to the present invention, the program can be executed cyclically according to pre-established time intervals (even if this does not exclude the activation thereof upon receiving a new message). However, the regularity and the frequency of such intervals do not change the system effectiveness, but the efficiency thereof only. The following figure 2 is a flow chart related to the program portion which processes and manages each of the received messages, when it is interpreted as a message with doubtful sender. In particular the idea underlying the invention is to analyze all the received messages existing in the InBox, without moving any of them (thus leaving at the user's disposal all messages, thereamong there could be urgent ones, even if this does not exclude the possibility of distinguishing the secure messages from the ones still to be subjected to the check). This occurs by sending a test message to the sender's e-mail address of the received e-mail message and by checking the reception of a message of "delivery error" (or denial) corresponding to the sent test message, obtaining an error information, when, indeed, the test message has been sent to a not-existing address, thus invented by a spammer, or stolen and utilized in a fraudulent way without the knowledge of the legitimate owner, who then has the possibility of denying by replying to the test message. By exploiting such error information, the program can then manage the e-mail message, for example, by eliminating it from the mailbox if the error information designates the occurred reception of the "delivery error" or denial message.. To each sent test message a corresponding univocally determined ID identification code is associated, which is then recorded into a record field of a file of
IDDB codes, corresponding to the sent test message. The ID code, created in a wholly random way by the system, can be numerical or alphanumerical, since it is unique and biunivocally associated to a test message. Then, the ID code is written in the sent test message (in the message's subject or body text or even inside the e-mail addresses of the involved users) and it will be then extracted by a possible "delivery error" or "denial" message, if received, for the subsequent checks, as it will be explained in more details hereinafter. Preferably in the IDDB file, in the same record corresponding to the sent test message, also the following data are stored: the sender (the sender's e-mail address and the alias thereof) thereto the test message is sent; - the subject of the received message; and despatch date and time of the test message. These data will be then utilized to check certain conditions and to perform then pre-established operations for managing the messages. The flow chart of figure 3 illustrates the whole flow, but not limitative, of the method according to the present invention. The program is activated at regular time intervals, for example each minute, but this time it can vary according to the required performances or it can become also irregular (for example if activated upon receiving a new message) without overloading the system, in order to monitor constantly the user's mailbox. <Are there any Msgs in the Inbox?> The program checks the presence of messages in the mailbox, including in such research also possible sub-folders. If there are no messages, the system ends. ["Go to the first msg] If there are messages, the program proceeds in analyzing the first message (the message sequence is not important, provided that it allows to analyze sequentially all messages). <Is the sender or domain blocked?> The method provides a step for checking if the sender (understood as the sender's e-mail address or the sender's mail domain or as domain's owner) is included in a first file of blocked senders.
Also those e-mail addresses which are clearly wrong (or wholly absent) can be considered as blocked. In the positive case, the message is interpreted as a not authorized spam message. Then, the method provides a step of eliminating (or moving) the received message from the user's mailbox, in case the sender is included in the first file of blocked senders or, indeed, is clearly wrong or wholly absent. After the elimination, it is always appropriate to send a notice to the sender. <Are there ID in the msg?> On the contrary, if the sender's address is not among the locked ones, the program checks if the received message is a delivery error or denial message following a previously sent test message. For such check, it is controlled if the examined message includes or not a ID and in this case such ID is extracted from the message. In order to improve the system's performances, it is possible avoiding such check inside messages too big to be "delivery errors" or "denials"; in fact, for such messages one can assume that the ID is not included therein. <Is ID in IDDB?> In the affirmative case, it is then checked if the extracted ID is included in the IDDB file and in the affirmative case (error message or denial reply to the test message), the flow passes to the check point designated and described hereinafter corresponding to the label <Sender = sender from IDDB?>. On the contrary, if the extracted ID is not included in the IDDB file, it could be, for example, a test message coming from another user utilizing the same system. In this case, the method provides a step of checking if a message was previously sent which, in turn, was subjected to a test by another user utilizing the same system and who thus generated the currently received message. Such check can be carried out automatically if the system can access to a file of sent mail; if this is not possible, the system, however, can translate the test message into the user's language, obviously maintaining unchanged the references to the message subjected to the check. This translation avoids that a spammer tries accessing to the user's mailbox by adding a fictitious ID inside the advertisement thereof, considering that said translation would wholly eliminate what is not pertinent to a correctly formatted test message: in other words, the translation would consist in searching inside the message for the fields related to the subject, to the despatch date and to the recipients of the message subjected to the check, in order then to utilize them to create again a test message corresponding to what is expected by the user, both as far as the language is concerned and as far as the corresponding explanation related to the system operation (that is, basically the instructions useful to deny to have ever sent the message in question) is concerned. Considering that the subject of the message subjected to the check and the list of the original recipients would not obviously translated and therefore they would be subjected to the user's attention, it is convenient avoiding that the spammer could insert a hyperlink therein, because this would be a possible advertisement vehicle: to this purpose, during the translation step, it is convenient eliminating or replacing the character groups such as "www", "http", apart from the characters "<" and ">". If the message has been really sent, the program simply provides to eliminate the received test message. On the contrary, if the program checks that a message corresponding to the received test message has never been sent, it provides to send a denial reply to the sender of the received message and then to eliminate the received message. Also the corresponding ID is stored in the IDDB (without linking thereto any sender) so as to avoid starting an infinite loop wherein two users with the same system continue to mutually deny to have sent an absent message from both the IDDB: in fact, if the ID is found in the IDDB, then the check related to the sent messages is not carried out and therefore the test message is simply eliminated at the point <Eliminate MSG>, after that the check <Sender = sender from IDDB> has given negative result (since no sender has ever been linked to this ID) and after having cleared the IDDB (at the point <Eliminate from IDDB>). On the contrary, if the message does not include a valid ID, then the method provides a step of checking if the sender's address is included in a third file of authorized senders. <Is the sender or domain authorized?> If the sender's address (or the sender's mail domain) results in the file of the senders authorized to send mail to the user, the program continues without intervening and it proceeds in analyzing possible subsequent messages, otherwise additional control and/or check steps are activated. Optionally, also the messages the size thereof exceeds a pre-established threshold can be considered as authorized, since the spammers have to send millions of messages in order to have an economic gain and therefore they cannot allow themselves to send too big messages. Furthermore, it may happen that the user has sent manually a message to a wrong address. In this case, then, he/she would receive a usual message notifying the failed delivery. If the anti-spam system detects this message notifying an error generated by a mail sent by the user himself/herself, it will try to check the sender. But this sender is a delivery service and therefore it could reply automatically as if it did not exist. For this reason the system would eliminate the corresponding message notifying the error and the user would not be advised of the fact to have sent, initially, a message to a wrong address. Therefore, it could be advantageous to check if a message's content includes references bringing back to a message previously sent by the user (for example, if the message includes the subject or the address of a recipient equal to what has been found in the sent mail) since the delivery service shows these data indeed to communicate that a certain message has not been delivered to a certain address. At this point, such message can be considered as coming from an authorized sender, even if only thanks to this particular content thereof (the reference to a message sent manually by the user). In this way, the user is informed about a failed delivery, but a possible spammer cannot utilized this input way since he/she is not able to know what the user has previously sent manually. <Same sender in IDDB?> If in the IDDB file a record associated to a test message sent to the same address in order to check the reliability thereof already exists, the method avoids to send additional test messages to the same address. Therefore, without any intervention, it proceeds in analyzing possible subsequent messages. [Create ID] -[Eliminate preceding ID"|-|"Send TEST messages] On the contrary, if test message already sent to that address do not result, the method provides a step of generating a new ID (for example, a random number) and of associating such ID to a test message to be sent to the sender of the received message, together with a brief text explaining the function thereof and thus explaining that the test message is used only to check that the sender's address does not generate errors and to confirm that the sender's address has not been falsified. Obviously, the test message includes references to the message subjected to the check, for example stating the subject, the despatch date and the recipients. These data can then be utilized, apart from by the sender who can recognize them, also by a possible anti-spam system utilized by the sender to check if it is necessary to reply to this test message (and therefore to deny to have sent it) or if it is possible to eliminate it (in case one has really sent it). Before sending the test message, the method advantageously provides the elimination of possible ID existing in the original message, which is enclosed to (or simply mentioned in) the test message which, once received, can be then eliminated by the user (if also the sender adopts the same anti-spam system, the test message recognized as such can be deleted automatically) or, in case the user who receives it does not recognize to have ever sent the message in question (enclosed or mentioned by the test message), he/she could also signal to not recognize it (to deny it). The "denial" could occur in a semi-automatic way, for example by pressing a button or a hyperlink included in the test message, so that this does not automatically generate a message replying to the test message, which still includes the sent ID, in order to be able to be recognized by the program. The use of a hyperlink can involve the advantage of distinguishing with greatest certainty the ones which are really denial messages from the ones which could be simple requests for clarification sent as reply to the test message. Another possible technique to try to minimize this kind of risk (the sender asks for clarifications and he/she replies to a test message, but he/she does not wish to deny to have sent a message) is constituted by the proper modification of the alias of the Reply-To field, so that the denials and the possible requests for clarification arrive always at the same address, however allowing the receiving system to distinguish the requests for clarification (that is the simple replies) since the corresponding alias results to be modified as shown in the Reply-To field. Obviously, also in this case it is necessary that the test message includes a hyperlink enabling the sender to deny, that is to send a reply, but this time without modifying the alias as shown by the Reply-To field. On the contrary, in case one wants to avoid asking to follow a hyperlink, the modification of the alias in the Reply-To field can be utilized however to further inform the user who is going to reply to a test message that a reply despatch constitutes a denial and therefore the corresponding message, therefor the test message has been sent, will be deleted, if he/she proceeds in replying to the test message. [Store ID/sender/msg in IDDB! The program proceeds in storing in the IDDB file the data of the managed message. In particular, as already illustrated, the ID, the sender, the subject (or the message's body text) and the despatch time of the test message. Then, the flow can proceed in analyzing a possible subsequent message, if existing, otherwise ending by waiting for the arrival of new messages. <Is sender=sender from IDDB?> By referring to the preceding step labelled <Is ID valid?>, if a message containing a valid ID arrives, but the sender thereof is different from the one stored in the corresponding record of IDDB file, then it means that it is an error signalling, which designates that the checked address is not existing or overloaded, the messages thereof will be treated as spam. [Block sender from IDDB1 In this case the sender stored in the corresponding record of the IDDB file is then stored in the file of the blocked senders (after possible request for confirmation by the user or with the possibility of choosing if blocking the whole mail domain, or the mail alias, or even the domain owner, as it can be checked automatically even later, or still a whole extension, as, for example, all domains ending with ".kr"). In order to decide automatically when a whole mail domain or a single address of that domain has to be blocked, one can avail oneself of a list of domains providing e- mail services: in fact, the addresses coming from this type of domains could belong both to spammers and to legitimate senders and therefore it is not convenient blocking the whole mail domain, since it could run the risk of refusing not spam messages. Considering that the sender is blocked, all possible additional messages existing in the InBox, but therefor the test message has not yet been sent, will be eliminated directly in the following cycles. However, if these senders are blocked automatically (that is, without confirmation by the user), they are also unblocked automatically after a period of time, since the failed delivery error could be due to a temporary situation and however, even if it is not the case, the additional messages sent by this address will be checked again and eliminated in any case, without the need for resulting already blocked. At the same time, the program provides to eliminate the corresponding record from the IDDB file. On the contrary, if the sender of the received message is the same one stored in the record of the IDDB file corresponding to the ID extracted from the received message, then it means that it is not a real signalling error and the sender has a real address, otherwise the reply containing the ID would have come from a third server and not from the sender directly (typical in case of error). For example, to this event the case can be brought back wherein whoever receives a test message replies thereto (and denies it) in order not to recognize the paternity thereof and in this case it would not be correct blocking the sender by inserting him her in the list of the blocked senders. [Eliminate from IDDB] In both cases (blocked address and/or real address) the system proceeds in eliminating (or moving in a specific directory, for example of "unwished mail") the "denied" message (thereof he/she had stored the references in the IDDB file). In practice, all the messages coming from the sender stored in the IDDB file and which also have the same subject, still stored in the IDDB -file, are eliminated from the InBox. [Eliminate msgl Then, the method provides a step of eliminating the received message from the user's mailbox, that is the error signalling or the "denial" message". <Additional msgs?> At this point, the presence of additional messages in the InBox is checked and, in case, the process is repeated for each one of the existing messages. The method according the invention, as described sofar, preferably can be repeated periodically, according to a first pre-established period of time, for example each minute, so as to detect substantially in real time the received new messages and to manage them according to the rules described sofar, but it can also be activated upon receiving a new message. Furthermore, the method according to the present invention can include a step, repeated periodically too, of eliminating from the file all the old registrations carried out before a pre-established period, for example 24 hours. Such step of eliminating all old registrations includes a process which analyzes the IDDB file and it acts on the oldest registrations (for example 24 hour or more old), by deleting them. Practically, it "clears" the file (the error messages usually arrive within 24 hours). Moreover, upon deleting the registrations, advantageously this process can add the corresponding addresses in the file of the authorized addresses, since for these users no error or denial has arrived within 24 hours from the test message despatch. In this way, in future the test message will not ever sent to these senders. Obviously, this step can be subjected to the user's confirmation, who can decide then if authorizing the single sender in question or the whole domain thereof. If the messages related to these registrations had been moved or marked waiting for the corresponding check (that is, waiting for a possible "delivery error" or "denial"), then said messages are joined to the ones coming from authorized senders, since a communication has not arrived (within the pre-established period of time) which would have caused the automatic deletion thereof. In order to check if in the meantime the sender has been overloaded (since the spammer could have used a real address, but free and therefore with small capacity and not able to receive several test messages), it is convenient sending an additional test message before moving the message that was delayed; said message will communicate to the legitimate senders that the message has been delivered at last (as it had been moved or marked): in case this notice generates soon a "delivery error", then the message is eliminated instead of being delivered or marked as checked. At last, the method according to the present invention can also include a step of storing the sender's address in the file of the blocked addresses, when the received message is eliminated manually from a user's mailbox without being read. In case, such registering step can be conditioned to a confirmation step by the user. Even in this case, a list of domains can be used, providing e-mail services to decide automatically when a whole domain or a single address of that domain has to be blocked. Similarly, also the messages which are read by the user can be considered instead as coming from authorized senders and also in this case such authorization can be subjected to the user's confirmation. EXAMPLES Hereinafter some practical examples will be illustrated, aimed at emphasizing the main intervention modes of a computer product which, through one or more computer programs, implements a method according to the present invention. Example 1 A "real" user A (not a spammer) sends an e-mail to the user B (who is currently using a computer program implementing the method according to the present invention), the subject thereof is, for example, "curriculum vitae". The e-mail system of B receives the message of A. When the anti-spam program is executed, it detects the presence of the message received in the mailbox (InBox) of B. Then, it analyzes the message, in particular it checks the sender' address thereof (for example userA@users.com), which does not exist in the file of blocked addresses. Then, the system proceeds in analyzing the whole content of the message, searching for a ID in the message's subject, in the message's text and in the names of possible enclosures. If it finds it, it extracts it and search for the extracted ID inside the IDDB file. In the example case the ID is not found, as it is a usual e-mail message. At this point, the program checks if the sender userA@users.com is instead in the file of the authorized addresses, but considering that the sender userA@users.com is unknown, the search result is negative. Before proceeding in sending a test message to the user A, the program checks if in the IDDB file a registration of a test message sent to the same userA@users.com already exists, so as not to enter an endless loop. Considering that it is the first time that userA@users.com writes to B, it does not result any registration. Therefore, the program proceeds in generating a random ID, which, for example, could be 1234567, then it will proceed in sending a test message to userA@users.com, whose subject could be something like: "Curriculum Nitae -TEST MESSAGE <ID>1234567</ID>", and the content thereof could be "This mail has been sent by an automatic anti-spam system in order to check the existence and functionality of the userA@users.com address. If one wants to deny to have sent the enclosed message, click the button [DENY] (or reply to the present message)". The test message, then, includes as enclosure the message "curriculum vitae" sent originally from A to B (or it shows the data thereof, as the subject). The button [DENY] only generates a message replying to the test message: if a user replies to the test message, this will be then interpreted as a denial. Then, the program stores in the IDDB file the data of the sent test message: to whom it was sent (userA@users.com), with which ID (123467), which was the message to be checked (curriculum vitae) and at what time it was sent (02/07/2003 - 17:03). In the meantime, the message of A can be marked, in case, as not yet checked or it can be moved in a subfolder. Then, the program waits for being re-started again at regular intervals to check the returning of possible error messages. All this takes place in very few seconds and, in the meantime, if the user B, who has already received in his/her InBox the message "Curriculum Vitae", decides to delete or read it, he/she can do it, even if the message had been marked or moved, since it has not yet been checked. In the meantime, B has read the curriculum and replies thereto by asking if A is available for a meeting. The user A, in turn, replies by sending a new message to B, confirming his/her availability for the following week. At this time, the anti-spam programma of B repeates all as described, but in this case in the IDDB file a registration of a test message already sent to a userA@users.com will be found. Therefore, the system proceeds in doing nothing, in case it moves or marks this message too as not yet checked. The message, then, remains at disposal of the user B, who then arranges an appointment for the following week. The following day, at 17:03, the function "clearing" the IDDB file finds the registration of the message "curriculum vitae" which, as it is not yet present, means that the test message sent to userA@users.com has not yet generated errors, therefore it proceeds in inserting the address of this sender in the file of authorized addresses and it deletes the corresponding registration from the IDDB. If the messages had been moved or marked, it provides in marking them as authorized or in moving them in the same folder of the authorized messages. Once arrived the following week, A sends to B a confirmation message for the appointment. Again, the program repeats the first steps as already described, but this time the address of A is found in the file of the authorized addresses and therefore the system does not intervene in any way. Therefore, the user B can read the message and, in turn, he/she can confirm the place and the time of the meeting. Example 2 A spammer user A sends an advertising email to B, the subject thereof is "Money for you" and the sender thereof results to be spammer@spammers.com. Considering that spamming is illegal and considering that the spammer does not want to be blocked by any kind of filter applied by the sender, the supplied address (spammer@spammers.com) is obviously false, so as to be easily changed and so as to make the real spammer difficult to be traced. The mail system of B receives the mail of A and when the anti-spam program is started, it detects the presence of the message in the InBox of B and it starts to analyze it. This means that first of all it analyzes the sender, which, for example, is spammer@spammers.com, which cannot be found in the file of the blocked senders. Then, the system proceeds in analyzing the whole content of the message, that is it looks for a valid ID in the message's subject, in the message's text and in the names of possible enclosures. If it finds it, it extracts it and searches for the extracted ID inside the IDDB file. In example case the ID is not found, since it is an advertising message. At this point the system checks if the sender spammer@spammers.com is in the file of the authorized addresses, instead. But considering that the sender sparrimer@spammers.com is unknown, the search result is negative. Before proceeding in sending a test message to the user A, the system checks if in the IDDB file a registration of a test message sent to the same spammer@spammers.com already exists, so as not to enter an endless loop. Considering that it is the first time that spammer@spammers.com writes to B, no registration results. Therefore, the program proceeds in generating a random ID, which for example could be ABC123DEF, then it will proceed in sending a mail to sparnmer@spammers.com, the subject thereof could be for example: "Money for you -TEST MESSAGE <ID>ABC123DEF</ID>", and the content thereof could be "This mail has been sent by an automatic anti-spam system in order to check the existence and functionality of the address spammer@spammers.com. If one wants to deny to have sent the enclosed message, click the button [DENY]". Then, the program stores in the IDDB file the data of the sent test message: to whom it has been sent (spammer@spammers.com), with which ID (ABC123DEF), which was the message to be checked (Money for you) and when it has sent it (02/07/2003 - 17:03). In the meantime the message of A can be marked, in case, as not yet checked or it can be moved in a subfolder. Then, the program waits for being re-executed at regular intervals to check the return of possible error messages. All this takes places in very few seconds and, in the meantime, if the user B, who has already received in his/her InBox the message "Money for you", decides to delete or read it, he/she can do it, even if the message had been moved or marked as not yet checked. The user spammer@spammers.com does not exist and, therefore, it cannot receive the test message ("Money for you -TEST MESSAGE <ID>ABC123DEF</ID>"). The last mail server involved in the process (it is not important if it is the server of B or a third server) signals with a mail (for example "Mail Delivery Failure"", sent for example by "postmaster@servers.com") that the user spammer@sparnmers.com cannot receive email, enclosing the message sent thereto ("Money for you -TEST MESSAGE <ID>ABC123DEF</ID>"). The mail system of B receives the error signalling mail (Mail Delivery Failure). The program performs again all the checks as already described, but in this case in one of the message's enclosures, the string <ID> is found, which by convention precedes the univocal identification generated at time of the test message despatch. Therefore, the program extracts the identification comprised between <ID> and </ID> (that is "ABC123DEF") and it search for it inside the IDDB file, by finding it, together with the data related to the message. Then, it is checked that the sender of this message (postmaster@servers.com) is not the same registered in the IDDB file (spammer@spammers.com) and therefore, the program proceeds in blocking spammer@spammers.com definitively (as address which has generated an error signalled by a third server, postmaste@servers.com) in case asking for confirmation to the user B to block also all the domain spammers.com and the owner thereof (the firm or the person which results to be the owner of the mail domain), so that in future all messages coming from these individuals are automatically eliminated. The original message registered in the IDDB file (Money for you) is eliminated from the InBox of the user B, as well as the corresponding registration is deleted
Figure imgf000018_0001
Then, the system eliminates also the error signalling message (Mail Delivery Failure). Then, the system proceeds in analyzing the remaining messages. If the system finds additional messages coming from spammer@spammers.com (or even only by spammers.com if the whole domain has been blocked), it will provide in eliminating them automatically. The present invention has been described sofar according to a preferred embodiment thereof, illustrated by way of example and not for limitative purposes. It is to be meant that other embodiments can exist, all however comprised within the protective scope of the present invention, as defined by the enclosed claims.

Claims

CLAIMS 1. A method for anti-spam management of an e-mail message received in a mailbox, comprising a step of determining if the received message is to be considered an authorized message or not, characterized in that, when the received message is not considered an authorized message, it comprises the steps of: sending a test message to the sender's e-mail address of the received e- mail message; checking the reception of a "delivery error" or "denial" message corresponding to the test message, by obtaining an error information; and - managing the received e-mail message based upon the error information, wherem the e-mail message is eliminated or moved from the mailbox if the error information designates the occurred reception of the "delivery error" or "denial" message.
2. Method according to claim 1, further comprising a step of checking if the sender is included in a first file of blocked senders.
3. Method according to claim 1 o 2, further comprising a step of checking if the sender is wrong or absent.
4. Method according to claim 2, further comprising, when the sender is included in said first file of blocked senders, a step of eliminating or moving the received message from the mailbox.
5. Method according to claim 4, further comprising a step of informing the blocked sender through a notice message.
6. Method according to claim 2 or 3, further comprising, when the sender is not included in said first file of blocked senders, a step of checking if the sender is included in a third file of blocked senders.
7. Method according to claim 6, comprising, when the sender is not present in said third file of authorized senders, a step of creating and sending a test message to the sender, said test message containing references to the message subjected to the check.
8. Method according to any of the preceding claims, wherein a univocally determined identification code (ID) is associated to the test message.
9. Method according to claim 8, further comprising a step of storing said identification code (ID) in a second file of codes (IDDB).
10. Method according to claim 9, further comprising a step of storing in said second file of codes (IDDB) the sender, thereto the test message, the subject of the message subjected to the check and the despatch date and time of said test message are sent.
11. Method according to claim 9 or 10, comprising a step of extracting the identification code (ID) from the "delivery error" or "denial" message, when received, by avoiding to search for said identification code (ID) inside the messages the size thereof exceeds a pre-established threshold.
12. Method according to claim 11, further comprising a step of checking if the extracted identification code (ID) is included in said second file of codes (IDDB).
13. Method according to any of the preceding claims, further comprising a step of extracting from the received message the sender who has sent it.
14. Method according to claims 10 and 12, further comprising, when the extracted identification code (ID) is included in said second file of codes (IDDB), a step of checking if the extracted sender is equal to the sender stored in said second file (IDDB) corresponding to the extracted ID.
15. Method according to claims 10 and 12, further comprising, when the extracted identification code (ID) is not included in said second file of codes (IDDB), a step of checking the existence of messages previously sent to the sender of the received message.
16. Method according to claim 15, further comprising a step of translating the received test message by eliminating or replacing the following groups of characters: "www", "http", "<" and ">".
17. Method according to claim 15 o 16, further comprising, when messages previously sent to the sender of the received message do not exist, a step of sending a denial message to the sender of the received test message, by storing the corresponding identification code in said file of codes (IDDB).
18. Method according to claim 14, further comprising, when the extracted sender is not equal to the sender stored in said second file (IDDB) corresponding to the extracted ID, a step of storing the sender in said first file of blocked senders.
19. Method according to claim 14, further comprising, when the extracted sender is not equal to the sender stored in said second file (IDDB) corresponding to the extracted ID, a step of comparing the sender's mail domain to a list of domains providing e-mail services, and, if the domain is not included therein, blocking the whole domain, otherwise blocking the single address.
20. Method according to claim 18 or 19, further comprising a step of eliminating or moving the message coming from the sender stored in said second file (IDDB) corresponding to the extracted ID.
21. Method according to claim 14, further comprising, when the extracted sender is equal to the sender stored in said second file (IDDB) corresponding to the extracted ID, a step of eliminating or moving from the mailbox the message corresponding to the sender stored in said second file (IDDB) corresponding to the extracted ID.
22. Method according to any of the claims 14 to 21, further comprising a step of eliminating the message received by the mailbox.
23. Method according to any of the claims 6 to 22, further comprising, when the sender is not included in said third file of authorized senders, a step of checking if the sender is included in said second file (IDDB), before proceeding in sending the test message.
24. Method according to any of the preceding claims, characterized in that it is applied to each of the messages included in the mailbox, including possible subfolders.
25. Method according to any of the preceding claims, characterized in that it is repeated periodically, according to a first pre-established period of time, or upon the arrival of a new message.
26. Method according to any of the preceding claims, further comprising a step of eliminating from said second file (IDDB), all the registrations carried out before a predetermined period.
27. Method according to claim 26, wherein said step of eliminating the old registrations is carried out periodically, according to a second pre-established period of time.
28. Method according to claim 26 o 27, further comprising, when a registration is eliminated from said second file IDDB, the insertion of the sender stored therein in said third file of senders authorized to send mail to the user.
29. Method according to claim 28, wherein the carrying out of said step of inserting the sender's address in said third file of authorized senders is conditioned to a confirmation step by said user.
30. Method according to any of the preceding claims, further comprising a step of storing the sender's address in the file of blocked addresses, when the received message is manually eliminated without being read from the mailbox by a user, or in the file of the authorized addresses, when, instead, the message is read.
31. Method according to claim 30 and any of the claims 18 or 19, wherein the carrying out of said step of storing the sender's address in the file of the blocked or authorized addresses is conditioned to a confirmation step by said user.
32. Method for identifying hidden links starting from a first link to a web page included in e-mail message, comprising the steps of: opening said web page; extracting possible links included inside the opened web page; and comparing said hidden links to an Internet address file generating spam.
33. Method for identifying hidden links according to claim 32, further comprising a step of storing said extracted hidden links in a file of Internet addresses.
34. Computer product, characterized in that it comprises one or more computer programs stored on a storage medium, said computer product being apt to implement a method according to any of the claims 1 to 33, when being executed on a computer.
35. Computer product, characterized in that it comprises one or more computer programs apt to implement a method according to any of the claims 1 to 33, when running on a computer.
PCT/IB2004/050687 2003-07-17 2004-05-13 Method for anti-spam e-mail management WO2005008983A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ITRM2003A000353 2003-07-17
IT000353A ITRM20030353A1 (en) 2003-07-17 2003-07-17 METHOD FOR ANTI-SPAM MANAGEMENT OF E-MAIL MESSAGES.

Publications (2)

Publication Number Publication Date
WO2005008983A2 true WO2005008983A2 (en) 2005-01-27
WO2005008983A3 WO2005008983A3 (en) 2005-05-12

Family

ID=29765923

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2004/050687 WO2005008983A2 (en) 2003-07-17 2004-05-13 Method for anti-spam e-mail management

Country Status (2)

Country Link
IT (1) ITRM20030353A1 (en)
WO (1) WO2005008983A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7996900B2 (en) * 2008-03-14 2011-08-09 Microsoft Corporation Time travelling email messages after delivery
US8387120B2 (en) 2007-07-25 2013-02-26 Szymon Lukaszyk Method and system of transferring electronic messages
CN110971447A (en) * 2019-10-22 2020-04-07 视联动力信息技术股份有限公司 Test information management method and device, electronic equipment and readable storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999010817A1 (en) * 1997-08-26 1999-03-04 Christopher Alan Cobb A method and system for filtering electronic messages
US20020198950A1 (en) * 1997-11-25 2002-12-26 Leeds Robert G. Junk electronic mail detector and eliminator
US20030009698A1 (en) * 2001-05-30 2003-01-09 Cascadezone, Inc. Spam avenger
US6546416B1 (en) * 1998-12-09 2003-04-08 Infoseek Corporation Method and system for selectively blocking delivery of bulk electronic mail
WO2003044617A2 (en) * 2001-10-03 2003-05-30 Reginald Adkins Authorized email control system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999010817A1 (en) * 1997-08-26 1999-03-04 Christopher Alan Cobb A method and system for filtering electronic messages
US20020198950A1 (en) * 1997-11-25 2002-12-26 Leeds Robert G. Junk electronic mail detector and eliminator
US6546416B1 (en) * 1998-12-09 2003-04-08 Infoseek Corporation Method and system for selectively blocking delivery of bulk electronic mail
US20030009698A1 (en) * 2001-05-30 2003-01-09 Cascadezone, Inc. Spam avenger
WO2003044617A2 (en) * 2001-10-03 2003-05-30 Reginald Adkins Authorized email control system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8387120B2 (en) 2007-07-25 2013-02-26 Szymon Lukaszyk Method and system of transferring electronic messages
US7996900B2 (en) * 2008-03-14 2011-08-09 Microsoft Corporation Time travelling email messages after delivery
US8327445B2 (en) 2008-03-14 2012-12-04 Microsoft Corporation Time travelling email messages after delivery
CN110971447A (en) * 2019-10-22 2020-04-07 视联动力信息技术股份有限公司 Test information management method and device, electronic equipment and readable storage medium

Also Published As

Publication number Publication date
WO2005008983A3 (en) 2005-05-12
ITRM20030353A1 (en) 2005-01-18
ITRM20030353A0 (en) 2003-07-17

Similar Documents

Publication Publication Date Title
US7596600B2 (en) System for selective delivery of electronic communications
US6779022B1 (en) Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US9177293B1 (en) Spam filtering system and method
CA2496313C (en) Communication management using a token action log
US7412487B2 (en) Method and system for tracking receipt of electronic message
US6266692B1 (en) Method for blocking all unwanted e-mail (SPAM) using a header-based password
CN109495377B (en) Instant E-mail embedded URL credit confirming equipment, system and method
US8194564B2 (en) Message filtering method
US20040093414A1 (en) System for prevention of undesirable Internet content
US20050044160A1 (en) Method and software product for identifying unsolicited emails
US20040267886A1 (en) Filtering email messages corresponding to undesirable domains
US20060149823A1 (en) Electronic mail system and method
US20070204043A1 (en) Method, system and apparatus for rejecting unauthorized or SPAM e-mail messages.
US20090044006A1 (en) System for blocking spam mail and method of the same
US20050125667A1 (en) Systems and methods for authorizing delivery of incoming messages
JP2008507005A (en) Online fraud solution
WO2001044953A1 (en) Method and system for confirming receipt of electronic mail transmitted via a communications network
CN104010085A (en) Message processing method and device
US8091118B2 (en) Method and system to optimize efficiency when managing lists of untrusted network sites
US8166113B2 (en) Access limited EMM distribution lists
WO2016156858A1 (en) Email management and control system
US20030033533A1 (en) Use of identification codes in the handling and management of communications
US8112482B1 (en) System and method for securing access to electronic mail
JPH11252158A (en) Electronic mail information management method and device and storage medium recording electronic mail information management processing program
WO2005008983A2 (en) Method for anti-spam e-mail management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG 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 MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK 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
122 Ep: pct application non-entry in european phase