XEP-0161: SPIM Reporting

This document specifies an XMPP protocol extension for reporting unsolicited bulk instant messages (SPIM).

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: 0161
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.3
Last Updated: 2007-01-31
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0030
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED
Wiki Page: <http://wiki.jabber.org/index.php/SPIM Reporting (XEP-0161)>

Author Information

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

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
2. Protocol
    2.1. Reporting a SPIM Stanza
    2.2. Reporting a Spimmer
3. Reporting SPIM
4. Processing SPIM Reports
    4.1. Initial Processing
    4.2. Determining Spimmer Status
5. Discovering Support
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
    8.1. Protocol Namespaces
9. XML Schema
Notes
Revision History

1. Introduction

Unsolicited bulk email, commonly called "spam", is a widespread problem on today's email network. We want to make sure that unsolicited bulk instant messaging, commonly called "SPIM" (short for "spam over IM"), does not become a widespread problem on the XMPP instant messaging network. To that end, this document specifies an XMPP protocol extension for reporting particular instances of SPIM.

2. Protocol

2.1 Reporting a SPIM Stanza

The protocol for SPIM reporting is quite simple: wrap the complete SPIM stanza in a <spim/> element qualified by the 'http://www.xmpp.org/extensions/xep-0161.html#ns' namespace and send an IQ stanza of type "set" to the entity that shall receive the report. This protocol is intended to be used by recipients of SPIM stanzas and by other entities (e.g., servers or services) that wish to pass around SPIM reports. The following is an example:

Example 1. Unsuspecting User Receives SPIM from Evil Bot

<presence from='makemoney@spimmersheaven.info' 
          to='unsuspectinguser@example.net'
          type='subscribe'>
  <status>
    You too can be rich! Find out how at 
    http://spimmersheaven.info/makemoney
    Let&apos;s chat to make your dreams
    come true!
  </status>
</presence>

Example 2. Unsuspecting User Reports SPIM

<iq from='unsuspectinguser@example.net/foo'
    to='example.net'
    type='set'
    id='report1'>
  <spim xmlns='http://www.xmpp.org/extensions/xep-0161.html#ns'>
    <presence from='makemoney@spimmersheaven.info' 
              to='unsuspectinguser@example.net'
              type='subscribe'
              xmlns='jabber:client'>
      <status>
        You too can be rich! Find out how at 
        http://spimmersheaven.info/makemoney
        Let&apos;s chat to make your dreams
        come true!
      </status>
    </presence>
  </spim>
</iq>

If the entity that receives the report does not support the SPIM Reporting protocol, it MUST return a <service-unavailable/> error to the reporting entity:

Example 3. Service Unavailable

<iq from='example.net'
    to='unsuspectinguser@example.net/foo'
    type='error'
    id='report1'>
  <spim xmlns='http://www.xmpp.org/extensions/xep-0161.html#ns'>
    <presence from='makemoney@spimmersheaven.info' 
              to='unsuspectinguser@example.net'
              type='subscribe'
              xmlns='jabber:client'>
      <status>
        You too can be rich! Find out how at 
        http://spimmersheaven.info/makemoney
        Let&apos;s chat to make your dreams
        come true!
      </status>
    </presence>
  </spim>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the entity that receives the report is able to process the report, it MUST return an IQ-result to the reporting entity:

Example 4. Report Processed

<iq from='example.net'
    to='unsuspectinguser@example.net'
    type='result'
    id='report1'/>

2.2 Reporting a Spimmer

If an entity that processes SPIM reports determines that the suspected spimmer is indeed an actual spimmer, it SHOULD report its conclusions to appropriate other entities (e.g., the spimmer's server or dedicated SPIM reporting services). Here again, the protocol is quite simple: wrap the spimmer's JID in a <spimmer/> element qualified by the 'http://www.xmpp.org/extensions/xep-0161.html#ns' namespace and send an IQ stanza of type "set" to the entity that shall receive the report. This protocol SHOULD NOT be used by recipients of SPIM stanzas. The following is an example:

Example 5. Server Reports Spimmer

<iq from='example.net'
    to='spim.xmpp.net'
    type='set'
    id='spimmer1'>
  <spimmer xmlns='http://www.xmpp.org/extensions/xep-0161.html#ns'>makemoney@spimmersheaven.info</spimmer>
</iq>

3. Reporting SPIM

The following rules and guidelines apply to the act of reporting SPIM.

  1. The recipient SHOULD NOT report the SPIM stanza to a server or service until it determines that the server or service supports the SPIM Reporting protocol (see the Discovering Support section of this document).

  2. If the recipient's home server (i.e., the server with which it has a registered account or other trust relationship) supports the SPIM Reporting protocol, the recipient SHOULD report the offending stanza only to its own server.

  3. If the recipient's home server does not support the SPIM Reporting protocol, the recipient SHOULD report the SPIM stanza to one or more dedicated SPIM reporting services if available.

  4. The recipient SHOULD NOT report the SPIM stanza to the suspected spimmer's server.

  5. The recipient SHOULD NOT report the SPIM stanza to the suspected spimmer.

4. Processing SPIM Reports

4.1 Initial Processing

The following rules and guidelines apply to initial processing of a SPIM report:

  1. Before processing the report, the processor MAY respond to the report by sending a challenge to the sender (e.g., using Robot Challenges [1]) in order to make sure that the sender is not sending spurious reports or otherwise abusing the SPIM reporting system.
  2. The processor MUST add the report to a list or database of pending SPIM reports.
  3. If the suspected spimmer is not already on the processor's list of known spimmers, the processor SHOULD use the report in determining whether the suspected spimmer is an actual spimmer (see next section).
  4. The processor MAY report the SPIM stanza to one or more dedicated SPIM reporting services if available.
  5. The processor MAY report the SPIM stanza to other servers it trusts.
  6. The processor MAY report the SPIM stanza to the suspected spimmer's server (if the server is otherwise trusted, i.e., is not considered a rogue server).
  7. The processor SHOULD NOT report the SPIM stanza to the suspected spimmer.

4.2 Determining Spimmer Status

Not all SPIM reports are valid, and not all JIDs that send stanzas reported as SPIM are spimmers. Care must be taken in correctly determining if a suspected spimmer is an actual spimmer. The following rules apply:

  1. The processor SHOULD NOT add a suspected spimmer to its list of known spimmers until it has received at least three (3) valid SPIM reports with regard to that suspected spimmer.

  2. If the processor determines that the suspected spimmer is an actual spimmer, the processor:

    1. MUST add that JID to its list of known spimmers.
    2. SHOULD send a spimmer report to the spimmer's server.
    3. MAY send a spimmer report to SPIM reporting services or reputation services.
    4. MAY send a spimmer report to other servers it trusts.
    5. SHOULD NOT send a spimmer report to the spimmer.

5. Discovering Support

In order to discover whether another entity supports SPIM reporting, Service Discovery [2] SHOULD be used. If an entity supports SPIM reporting, it MUST return a feature of "http://www.xmpp.org/extensions/xep-0161.html#ns" in responses to service discovery information requests, as shown in the following examples:

Example 6. User Queries Server Regarding Protocol Support

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

Example 7. Server Replies Regarding Protocol Support

<iq from='example.net'
    to='unsuspectinguser@example.net/foo'
    type='result'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://www.xmpp.org/extensions/xep-0161.html#ns'/>
    ...
  </query>
</iq>

6. Security Considerations

Not all reported SPIM is actual SPIM, and not all reported spimmers are actual spimmers. Processors must take care to ensure that processing of one or a few reports does not result in branding of a legitimate sender as a spimmer, since otherwise the sender could effectively be the subject of a denial of service attack.

It is NOT RECOMMENDED for client recipients to send SPIM reports to the server of a suspected spimmer, since that server could be a rogue domain capable of sending SPIM from any JID at that domain.

7. IANA Considerations

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

8. XMPP Registrar Considerations

8.1 Protocol Namespaces

Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-00161.html#ns"; upon advancement of this specification, the XMPP Registrar [4] shall issue a permanent namespace in accordance with the process defined in Section 4 of XMPP Registrar Function [5].

9. XML Schema

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://www.xmpp.org/extensions/xep-0161.html#ns'
    xmlns='http://www.xmpp.org/extensions/xep-0161.html#ns'
    elementFormDefault='qualified'>

  <xs:import 
      namespace='jabber:client'
      schemaLocation='http://www.xmpp.org/schemas/jabber-client.xsd'/>

  <xs:element name='spim'>
    <xs:complexType>
      <xs:choice xmlns:xmpp='jabber:client'>
        <xs:element ref='xmpp:iq'/>
        <xs:element ref='xmpp:message'/>
        <xs:element ref='xmpp:presence'/>
      </xs:choice>
    </xs:complexType>

  <xs:element name='spimmer' type='xs:string'/>

</xs:schema>

Notes

1. XEP-0158: Robot Challenges <http://www.xmpp.org/extensions/xep-0158.html>.

2. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

3. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

4. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

5. XEP-0053: XMPP Registrar Function <http://www.xmpp.org/extensions/xep-0053.html>.

Revision History

Version 0.3 (2007-01-31)

Specified that client recipient should not send a report to the server of a suspected spimmer; modified XML namespace name to conform to XEP-0053 processes; corrected several examples.

(psa)

Version 0.2 (2006-09-21)

Modified business rules; added security considerations; defined XML schema.

(psa)

Version 0.1 (2005-10-19)

Initial version.

(psa)

Version 0.0.1 (2005-09-28)

First draft.

(psa)

END