ual Architecture for SPIT Mitigation Call rate monitoring on the callee side: the system can observe the calls issued by a user towards a given destination. If the number of calls goes beyond a certain threshold, the call is automatically added to the user's white list. To get the agreement of the user, the system should first notify this user, however this is not easy when the user is often using a hardphone. Another option is that the user can delete any entry from his lists whenever he does not agree on adding any. Call rate monitoring on the caller side: the purpose behind this is to build some traffic patterns and make the SPIT analysis based on these patterns. We can for instance monitor continuously the arriving calls from a given user/host/domain targeting one or more end users. If we see that the number of the arriving calls deviates from the usual average, the sender will be classified as spammer. 23.4.1.3.2 White/black lists classification The white/black lists can be categorized as follows: Local lists: this type of list simply means that to each user, a white list and a black list will be bound. The way these lists are managed was described earlier. Global lists: there will also be global white and black lists besides the individual ones. If for a given sender a minimal number of users have opted to put this sender's URI on their white or black list, this URI will automatically advance to the global black or white list. The minimal number (or threshold) described earlier is policy dependant. Taking different values of the threshold has to be investigated and spe- cial care will be dedicated to the study of the generated false alarms if any. Global lists can cause problems if the users preferences have to be taken into account. Let us for instance assume that the above mentioned threshold is set to five. In this case, if six users opt for not receiving calls or instant messages related to job advertisements, this means that all the other users will be prevented from receiving this information even if 