they are not against it. As a consequence, global and local lists have to be handled dependently. The use of global lists might raise conflict issues. Imagine the situation where a given URI is on both global white and black lists, this yields to an undefined situation. 23.4.1.3.3 Scored global lists In this part, another alternative for white/ black global lists is discussed. While the global white and black lists can be effective in fighting SPIT, some drawbacks can affect their performance. In the previous paragraph, we reported briefly some of the disadvantages of using white and black lists. Another drawback that we have not mentioned yet is the fact that if the provider policy is to add a user to the global white list © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security when a given number of users have reported his calls as not spam, an attacker could create a series of legitimate calls (to his own accounts, for example) in order to get on the white list. Similarly, a user can be mistakenly blacklisted if some users repeatedly report him to create spam either intentionally (e.g., friends who don't get along anymore) or unintentionally (e.g., wrong button pressed). As a conse- quence, the entrance policies for the white/black lists are difficult to define and maintain. These drawbacks come from the fact that the white/black lists offer very limited information about the entries, making it easy for a SPITter to work around them once it understands the policies. Therefore, the white/black lists can be improved by attaching a score to each entry. This score represents the probability of a user being a SPITter based on its past activity. Every time a callee marks a call as SPIT, it will raise the score of the caller, and every time a callee marks a call as non-SPIT, it will lower the score of the caller. A basic example of such a score is "the number of times the user was reported as SPITter" minus "the number of times the user was reported as non-SPITter". Even with this sim