XEP-0236: Abuse Reporting

1. Introduction¶

Unfortunately, not all XMPP entities are well-behaved. Currently, if an XMPP entity (the "attacker") sends abusive stanzas to another XMPP entity (the "victim"), there is no way for the victim or the victim's server to inform the attacker's server that the attacker is generating abusive traffic. In practice, the victim's server may need to terminate the server-to-server connection (currently without explicitly informing the attacker's 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.

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).

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

<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).

<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 (XEP-0030) [6] information request:

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

<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>

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0236

Publisher

XMPP Standards Foundation

Status

Retracted

Type

Standards Track

Version

0.2

Last Updated

2008-05-09

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0030

Supersedes

None

Superseded By

None

Short Name

NOT YET ASSIGNED

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Peter Saint-Andre

Email

stpeter@stpeter.im

JabberID

stpeter@jabber.org

URI

https://stpeter.im/

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

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

Appendix F: Requirements Conformance¶

The following requirements 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".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.2 (2008-05-09)¶

   Retracted in favor of XEP-0161, which now contains the content originally published in this specification.

   psa
2. Version 0.1 (2008-03-05)¶

   Initial published version.

   psa
3. Version 0.0.3 (2008-02-29)¶

   Added reason element containing machine-readable conditions and optional human-readable text; added note about forwarding of abuse reports.

   psa
4. Version 0.0.2 (2008-02-26)¶

   Limited scope to reporting between two servers; more clearly defined what is abusive; changed protocol to use IQ request-response exchange; limited use of error condition to stream termination.

   psa
5. Version 0.0.1 (2008-02-19)¶

   First draft.

   psa

Appendix I: Bib(La)TeX Entry

@report{saint-andre2008not yet assigned,
  title = {Abuse Reporting},
  author = {Saint-Andre, Peter},
  type = {XEP},
  number = {0236},
  version = {0.2},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0236.html},
  date = {2008-02-19/2008-05-09},
}

END