lid URI: too short when applied to the SIP message header, may deal particularly with the fol- lowing situations The From field (see Table 23.1). The Subject field: Is the Subject field empty? If not, which words are there: pills, money, or some other good indicators? Is this request the first one from this user? Number of blank lines in the SIP header. As SPIT is sent in bulk, a big number of the recipients' URIs or IP addresses will come from old lists that are no longer in operation. Also, SPITters might use 'dictionary attack' or trying out local parts 'after the @' in order to build a list of their targets. As a consequence, the SIP messages sent by a SPITter (to differentiate from someone spewing saliva or tobacco juice) will present various weaknesses that a learning algorithm can exploit to detect the corresponding SPIT activity. With other respects, the above criteria are defined according to our obser- vation of the current e-mail case. The learning algorithms need concrete data about the SIP messages sent by the SPITters. Unfortunately, this is still early because the SPIT problem is expected to become more serious and hence detectable, as VoIP deployment goes further. Another way of defining machine learning algorithms is to log the calls or the instant messages that we are sure are SPIT. For instance, some spam tools create calls which fail a challenge/response test. These calls are logged and a set of attributes is stored. This can be specific SIP headers, IP ranges, etc. The machine learning module recognizes a pattern SO that when next time this tool is used, calls could force a challenge/response or even drop the calls completely. 23.4.1.4.2 Detect safe calls The idea behind this approach is to allow a call to quickly progress to the endpoint based on an assumption that this is almost guaranteed a non-spam pattern. This is not necessarily a direct inverse as the first architecture. Completely different attributes could detect a known safe caller than in the first architecture. A module as describ