XEP-0236: Abuse Reporting

This specification defines an XMPP protocol extension for reporting abusive traffic between two XMPP servers.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Series: XEP
Number: 0236
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2008-03-05
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED
Wiki Page: <http://wiki.jabber.org/index.php/Abuse Reporting (XEP-0236)>

Author Information

Legal Notices

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Errata may be sent to <editor@xmpp.org>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents

1. Introduction

Unfortunately, not all XMPP entities are well-behaved. Currently, if an XMPP entity sends abusive stanzas over a server-to-server connection, there is no way for the receiving server to inform the sending server that the sender is generating abusive traffic. In practice, the receiving server may need to terminate the server-to-server connection (again without explicitly informing the sending server about the reason for the termination) rather than continue to accept the abusive traffic.

This situation is far from desirable. Therefore, this specification defines three small XMPP protocol functions that can help to improve the reliability of server-to-server connections:

1. A method by which the receiving server can send an abuse report to the sending server, including the JID(s) of the sender(s).
2. An application-specific stanza error condition that can be combined with the standard <not-acceptable/> stanza error condition to inform the sending server that a particular XMPP stanza is considered abusive.
3. An application-specific stream error condition that can be combined with the standard <policy-violation/> stream error condition to inform the sending server about the reason for termination of an XML stream.

2. Syntax

An abuse report MUST be sent in an IQ stanza of type "set" containing an <abuse/> element qualified by the 'urn:xmpp:tmp:abuse' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces). The allowable children of the <abuse/> element are:

• One or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s)
• An optional <reason/> element that specifies the reason for the abuse report, via a machine-readable abuse condition defined in this specification, (optionally) human-readable text about the report, and (optionally) an application-specific condition defined outside this specification.

This specification intentionally does not define exactly what constitutes abuse, since "abuse is in the eye of the beholder". However, the following machine-readable conditions are defined as children of the <reason/> element.

Table 1: Abuse Conditions

Note: The foregoing list of conditions is not exhaustive. The list may be augmented or otherwise modified in a future version of this specification as a result of implementation and deployment experience.

3. Abuse Report

<iq from='example.org'
    id='rep1'
    to='example.com'
    type='set'>
  <abuse xmlns='urn:xmpp:tmp:abuse'>
    <jid>abuser@example.com/foo</jid>
    <reason>
      <condition>
        <muc/>
      </condition>
    </reason>
  </abuse>
</iq>
    

<iq from='example.com'
    id='rep1'
    to='example.org'
    type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

<iq from='example.com'
    id='rep1'
    to='example.org'
    type='error'>
  <error type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

<iq from='example.com'
    id='rep1'
    to='example.org'
    type='result'/>
      

4. Stanza Error

The receiving server MAY report that a particular stanza is considered abusive. The stanza error condition MUST be <not-acceptable/> and the error stanza MUST include an application-specific error condition of <abuse/> qualified by the 'urn:xmpp:tmp:abuse' (see Protocol Namespaces regarding issuance of one or more permanent namespaces). The <abuse/> element MUST include one or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s).

Example 5. Abusive stanza

<message from='abuser@example.org/foo'
         to='victim@example.org'>
  [ ... some abusive payload here ... ]
</message>
  

Example 6. Stanza error

<message from='example.com'
         to='example.org'>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
  <abuse xmlns='urn:xmpp:tmp:abuse'>
    <jid>abuser@example.com/foo</jid>
    <reason>
      <condition>
        <unacceptable-payload/>
      </condition>
    </reason>
  </abuse>
</message>
  

5. Stream Error

If the sending entity continues to generate abusive stanzas via the sending server, the receiving server MAY close the stream between the receiving server and the sending server. The stream error condition MUST be <policy-violation/> and the stream error MUST include an application-specific error condition of <abuse/> qualified by the 'urn:xmpp:tmp:abuse'. The <abuse/> element MUST include one or more <jid/> elements whose XML character data specifies the JID(s) of the abusive sender(s).

Example 7. Stream Error

<stream:error>
  <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
  <abuse xmlns='urn:xmpp:tmp:abuse'>
    <jid>abuser@example.com/foo</jid>
    <reason>
      <condition>
        <too-many-stanzas/>
      </condition>
    </reason>
  </abuse>
</stream:error>
</stream:stream>
  

The receiving entity then SHOULD terminate the TCP connection between the receiving server and the sending server.

6. Discovering Support

If a server supports the abuse reporting protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:tmp:abuse" (see Protocol Namespaces regarding issuance of one or more permanent namespaces) in response to a Service Discovery [6] information request:

Example 8. Service Discovery information request

<iq from='example.org'
    id='disco1'
    to='example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  

Example 9. Service Discovery information response

<iq from='example.com'
    id='disco1'
    to='example.org'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:tmp:abuse'/>
    ...
  </query>
</iq>
  

7. Security Considerations

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].

9. XMPP Registrar Considerations

<condition>
  <ns>urn:xmpp:tmp:abuse</ns>
  <element>abuse</element>
  <desc>the sending entity has generated traffic that the receiving server considers abusive</desc>
  <doc>XEP-xxxx</doc>
</condition>
    

10. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:abuse'
    xmlns='urn:xmpp:tmp:abuse'
    elementFormDefault='qualified'>

  <xs:element name='abuse'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='jid' type='xs:string' minOccurs='1' maxOccurs='unbounded'/>
        <xs:element ref='reason' minOccurs='0'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='reason'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='condition' minOccurs='0' maxOccurs='1'/>
        <xs:element name='text' type='xs:string' minOccurs='0' maxOccurs='1'/>
        <xs:any namespace='##other' minOccurs='0' maxOccurs='1'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='condition'>
    <xs:complexType>
      <xs:choice>
        <xs:element name='gateway' type='empty'/>
        <xs:element name='muc' type='empty'/>
        <xs:element name='proxy' type='empty'/>
        <xs:element name='pubsub' type='empty'/>
        <xs:element name='service' type='empty'/>
        <xs:element name='spam' type='empty'/>
        <xs:element name='stanza-too-big' type='empty'/>
        <xs:element name='too-many-recipients' type='empty'/>
        <xs:element name='too-many-stanzas' type='empty'/>
        <xs:element name='unacceptable-payload' type='empty'/>
        <xs:element name='unacceptable-text' type='empty'/>
        <xs:element name='undefined-abuse' type='empty'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  

Notes

Revision History

END