diff --git a/inbox/spam-report.xml b/inbox/spam-report.xml new file mode 100644 index 00000000..e753f2f5 --- /dev/null +++ b/inbox/spam-report.xml @@ -0,0 +1,227 @@ + + +%ents; +]> + + +
+ Spam Reporting + + This document specifies a mechanism by which users can report spam and other + abuse to a server operator or other spam service. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0191 + + + + NOT_YET_ASSIGNED + &sam; + + 0.0.1 + 2016-05-21 + ssw +

First draft.

 + +
+ +

+ Many spam and abuse prevention techniques rely on users being able to report + other users who are sending unwanted messages, or specific instances of + abuse. &xep0191; allows users to block spammers, but does not provide a + mechanism for them to report a reason for the block to the server operator. + This specification extends the blocking command to optionally provide an + abuse report. +

+ + +

+ Entities that support &xep0030; and abuse reporting MUST respond to service + discovery requests with a feature of 'urn:xmpp:reporting:0' and with a + feature for each reason supported by the responding entity as described in + the relavant specifications. Eg. a response from a server that supports + reporting and understands the abuse and spam reasons defined later in this + specification might look like the following: + + + + + + + + ]]> +

+ + +

+ The payload for reporting abuse to the server takes the form of a + <report/> qualified by the 'urn:xmpp:reporting:0' namespace &VNOTE;. + Report payloads are reusable and MUST NOT be sent without first being + wrapped in a stanza. +

+ ]]> +

+ Abuse reports MAY include a reason for the report and servers MUST tolerate + unknown XML elements in a report without making assumptions about the + semantic meaning of unknown elements. +

+

+ This document defines the following reasons for a report: +

+
+
<spam/>
+
Used for reporting a JID that is sending unwanted messages.
+
<abuse/>
+
Used for reporting general abuse.
+
+

+ Clients MUST include only one reason per report. +

+

+ Reports MAY contain a user provided message explaining or providing context + about the reason for the report. See also the + Internationalization Considerations section of this + document. +

+ + + Never came trouble to my house like this. + + +]]> + + +

+ To send a report, a report payload MAY be inserted into an <item/> + node sent as part of a request to block a spammer as defined in &xep0191;. + For example: +

+ + + + + + + + +]]> +

+ Servers that receive a blocking command with a report MUST block the JID or + return an error just as they would if no report were present. Servers then + MAY take other actions based on the report, however, such actions are + outside the scope of this document. +

+ + +

+ Clients that support sending reports as part of the blocking command SHOULD + expose interfaces to both block a JID without reporting it as abusive, and + to block and report a JID. +

+ + +

+ If one or more <text/> elements are present they SHOULD include + 'xml:lang' attributes specifying the natural language of the XML character + data. +

+ + +

+ This document introduces no additional security considerations above and + beyond those defined in the documents on which it depends. +

+ + +

This document requires no interaction with &IANA;.

+ + + +

This specification defines the following XML namespace:

+
    +
  • urn:xmpp:reporting:0
    • +
+

+ Upon advancement of this specification from a status of Experimental to + a status of Draft, the ®ISTRAR; shall add the foregoing namespace to + the registry located at &DISCOFEATURES;, as described in Section 4 of + &xep0053;. +

+ + + &NSVER; + + +

+ The XMPP Registrar shall maintain a registry of abuse report reasons. + All abuse report reason registrations shall be defined in separate + specifications (not in this document). Application types defined within + the XEP series MUST be registered with the XMPP Registrar, resulting in + protocol URNs of the form "urn:xmpp:reporting:reason:name:X" (where + "name" is the registered name of the reason and "X" is a non-negative + integer). +

+ ®PROCESS; + + + The name of the abuse report reason. + urn:xmpp:reporting:reason:{name}:{ver} + A natural-language summary of the reason. + + The document in which the report reason is specified. + +]]> + + +

This specification defines the following abuse reporting reasons:

+
    +
  • urn:xmpp:reporting:reason:spam:0
    • +
  • urn:xmpp:reporting:reason:abuse:0
    • +
+

+ Upon advancement of this specification from a status of Experimental to + a status of Draft, the ®ISTRAR; shall add the following definition to + the abuse reporting reasons registry, as described in this document: + + Spam + urn:xmpp:reporting:reason:spam:0 + Used to report a JID that was sending spam messages. + XEP TODO +]]> + + Abuse + urn:xmpp:reporting:reason:abuse:0 + Used to report general abuse that is not covered by a more specific reason. + XEP TODO +]]> +

+ + + +

TODO

+ + +

+ Thanks to the participants of the XMPP Summit 20 in Austin, TX who + discussed this XEP: specifically to Waqas Hussain, Kevin Smith, Lance + Stout, and Matthew Wild. A special thanks to Daniel Wisnewski for giving + the presentation that kicked off the anti-abuse work. +

+ +