The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanzas could take many forms; a full taxonomy is outside the scope of this document.

One technique developed to combat abusive messages and behavior via non-XMPP technologies requires humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage XMPP abuse. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.

An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash Hashcash <http://hashcash.org/>. challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of abusive traffic.

Both CAPTCHAs and hashcash have been criticized regarding their effectiveness (or lack thereof). Therefore, the challenge protocol specified herein provides a great deal of flexibility, so that challenges can include CAPTCHAs, hashcash, word puzzles, so-called kitten authentication, and any other mechanism that may be developed in the future.

The generic challenge protocol described in this document is designed for incorporation into protocols such as &xep0077;, &xep0045;, &xep0016;, and &xep0159;.

This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of XEP-0077.

Note: The <challenge/> wrapper element is not included, because XEP-0077 specifies that data forms shall be contained as the direct children of the &QUERY; element.

Note that the CAPTCHA form MUST be inside the &QUERY; element, and the server's challenge ID is specified within the form:

The server MAY include an <instructions/> element and a URL using Out-of-Band Data (e.g., a web page) in the &QUERY; element (see example above). In-Band Registration recommends that the challenger SHOULD submit the completed x:data form, however if it does not understand the form, then it MAY present the instructions and the included URL to the user instead of providing the required information in-band.

A service that hosts multi-user chat rooms in accordance with XEP-0045 MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.

A challenger MAY provide a text question in the &BODY; element of a challenge stanza for clients that do not support CAPTCHA forms. Entities that cannot serve Out-of-Band Data URLs MAY use this option to challenge legacy clients.

Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the CAPTCHA form.

Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a CAPTCHA form.

Legacy clients respond to the challenger using a &MESSAGE; stanza (not an &IQ;).

The challenger SHOULD treat the stanza as a normal message (instead of as a response to its challenge) if the legacy client either takes too long to submit it or has already responded to the challenge. The challenger MAY treat the response as a normal message even in cases where the challenge became unnecessary while the challenger was waiting for the response.

Otherwise the challenger MUST report the result of the challenge to the legacy client using a &MESSAGE; stanza (not an &IQ;).

It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see XEP-0161 and &xep0205;).

It is expected that this protocol will be an important and successful tool for discouraging abusive traffic. However, much of its success is dependent on the quality of the CAPTCHAs and other puzzles employed by a particular implementation.

The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances:

• If he realises that the challenger's challenges are largely ineffective in combating abusive traffic, and that the reduction in abuse does not compensate for the inconvenience to humans of responding to the challenger's challenges.
• If other, more transparent, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against abusive traffic.
• If the challenger needs no protection at all because it receives only a negligible amount of abusive traffic.

Each form field SHOULD include a 'label' attribute. If the sender did not include an 'xml:lang' attribute, then the challenger may not know the correct language for the labels. Therefore, depending on user preferences, the client that receives a challenge MAY present generic but localized text instead of label text that would not be understood by the user. Suggested generic text (to be suitably localized) is provided by Table 1 in the CAPTCHAs section of this document.

The use of CAPTCHAs is not a panacea, and should be combined with other anti-abuse mechanisms, such as those described in XEP-0161 and XEP-0205. For example, the task of finding solutions to CAPTCHAs and other computational puzzles is becoming easier for computer programs, and in any case can be farmed out to third parties. Therefore challengers should limit the number of triggering stanzas (e.g., registration attempts, subscription requests, or chatroom joins) allowed per JabberID or IP address during any given time period, and may simply refuse repeated stanzas by terminating an XML stream with a &policy; stream error or returning a ¬acceptable; stanza error as appropriate. In addition, a challenger should feel free to deploy additional anti-abuse mechanisms as needed.

This document requires no interaction with &IANA;.

Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording. Of course Aunt Tillie would typically use this feature only if she was plagued by abusive traffic.