dent component or just a functionality collocated with another component in our archi- tecture. One way for combining the test results assumes that a score is assigned to each test [17]. By combining these scores together in an appr- opriate way, a real number is generated and compared to a pre-defined threshold. If this number is greater than the threshold, the SIP request is classified as SPIT. In the opposite case, the request is classified as non-SPIT. Another way of combining the tests results is to use them in a logical sequence. In other words, if the detection modules are organized in a logical sequence, and if the test corresponding to the first module is negative, a next test is performed, otherwise, the received request is clas- sified as SPIT. For this kind of combination, a simple script can be used. A third way would be to build a decision tree depending on the used modules. The tree could be described in a scripting language where the scripting engine traversals the tree, calls every anti-SPIT module until a final decision is made. This solution adds more flexibility in handling the results of each module and opens the ability of interaction between the different modules. But this also adds more complexity to the whole sys- tem and makes it more difficult to add or remove modules to the system. 23.4.1 Anti-SPIT Module Examples In Section 23.3, we have identified four types of problems that are behind the persistence of e-mail spam and which will certainly be the reasons behind the emergence and probably the persistence of SPIT. As a response to these issues, a non-exclusive list of SPIT detection modules is defined. These modules can be used as blocks for building potential anti-SPIT solutions. 23.4.1.1 Authentication Module The authentication module simply aims at enhancing domain verification for the anti-SPIT solutions. This module tries to identify senders by the set of © 2009 by Taylor & Francis Group, LLC A Conceptual Architecture for SPIT Mitigation SIP servers they use to send their request