"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
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.