mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-23 16:18:51 -05:00
295 lines
11 KiB
XML
295 lines
11 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Spam Reporting</title>
|
|
<abstract>
|
|
This document specifies a mechanism by which users can report spam and other
|
|
abuse to a server operator or other spam service.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0377</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XMPP IM</spec>
|
|
<spec>XEP-0191</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.3</version>
|
|
<date>2021-06-21</date>
|
|
<initials>ssw</initials>
|
|
<remark>Rework based on list feedback.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2017-09-11</date>
|
|
<initials>XEP Editor (jwi)</initials>
|
|
<remark>Defer due to lack of activity.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.0</version>
|
|
<date>2016-05-25</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>Initial version approved by the Council.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2016-05-21</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Background' anchor='background'>
|
|
<p>
|
|
This document extends the blocking command instead of providing a separate
|
|
reporting IQ because we hypothesize that this will slightly lower the levels
|
|
of false reports received by service operators.
|
|
We have observed a common pattern on the internet where a user becomes mad
|
|
at or disagrees with another user and begins harassing them by replying to
|
|
or reporting their every comment even if it is not itself spam or abusive.
|
|
However, this sort of behavior cannot continue if the harasser can no longer
|
|
read the messages of the person they are stalking.
|
|
Giving them a choice between their abusive behavior and being able to
|
|
read their targets can possibly force them to break the cycle and only
|
|
create valid reports.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Discovering Support' anchor='disco'>
|
|
<p>
|
|
Entities that support &xep0030; and abuse reporting using the blocking
|
|
command as defined in this spec MUST respond to service discovery requests
|
|
with a feature of 'urn:xmpp:reporting:1'.
|
|
Support for this namespace also indicates support for the abuse reporting
|
|
reasons defined in this document.
|
|
For example, 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:
|
|
</p>
|
|
<example caption="Service discovery information response"><![CDATA[
|
|
<iq from='example.net'
|
|
id='ku6e51v3'
|
|
to='kingclaudius@example.net/castle'
|
|
type='result'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
<feature var='urn:xmpp:reporting:1'/>
|
|
…
|
|
</query>
|
|
</iq>]]></example>
|
|
</section1>
|
|
<section1 topic='Payload' anchor='payload'>
|
|
<p>
|
|
The payload for reporting abuse to the server takes the form of a
|
|
<report/> qualified by the 'urn:xmpp:reporting:1' namespace &VNOTE;.
|
|
</p>
|
|
<example caption='The most basic report payload'><![CDATA[
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam"/>]]></example>
|
|
<p>
|
|
Abuse reports MUST include a reason for the report in the "reason" attribute.
|
|
</p>
|
|
<p>
|
|
This document defines the following reasons for a report:
|
|
</p>
|
|
<dl>
|
|
<di>
|
|
<dt>urn:xmpp:reporting:spam</dt>
|
|
<dd>Used for reporting a JID that is sending unwanted messages.</dd>
|
|
</di>
|
|
<di>
|
|
<dt>urn:xmpp:reporting:abuse</dt>
|
|
<dd>Used for reporting general abuse.</dd>
|
|
</di>
|
|
</dl>
|
|
<p>
|
|
Reports MAY contain a user provided message explaining or providing context
|
|
about the reason for the report.
|
|
See also the <link url='#i18n'>Internationalization Considerations</link>
|
|
section of this document.
|
|
</p>
|
|
<example caption='Report with optional reason and text'><![CDATA[
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam">
|
|
<text xml:lang="en">
|
|
Never came trouble to my house like this.
|
|
</text>
|
|
</report>]]></example>
|
|
</section1>
|
|
<section1 topic='Use with the Blocking Command' anchor='blocking'>
|
|
<p>
|
|
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:
|
|
</p>
|
|
<example caption='Report sent with blocking command'><![CDATA[
|
|
<iq from='juliet@example.com/chamber' type='set' id='block1'>
|
|
<block xmlns='urn:xmpp:blocking'>
|
|
<item jid='romeo@example.net'>
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:abuse"/>
|
|
</item>
|
|
</block>
|
|
</iq>]]></example>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
If the server supports &xep0313; the report MAY also include the stanza-id
|
|
of specific messages being reported.
|
|
This is done by including copies of each <stanza-id/> element that the
|
|
user wishes to report as a child of the <report/> element.
|
|
The stanza indicated by the provided stanza-id SHOULD be by the same JID
|
|
being reported and blocked.
|
|
</p>
|
|
<example caption='Report sent with stanza IDs'><![CDATA[
|
|
<iq from='juliet@example.com/chamber' type='set' id='block1'>
|
|
<block xmlns='urn:xmpp:blocking'>
|
|
<item jid='romeo@example.net'>
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam">
|
|
<stanza-id xmlns='urn:xmpp:sid:0' by='romeo@example.net' id='28482-98726-73623'/>
|
|
<stanza-id xmlns='urn:xmpp:sid:0' by='romeo@example.net' id='38383-38018-18385'/>
|
|
<text xml:lang="en">
|
|
Never came trouble to my house like this.
|
|
</text>
|
|
</report>
|
|
</item>
|
|
</block>
|
|
</iq>]]></example>
|
|
</section1>
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
|
<p>
|
|
Clients that support sending reports as part of the blocking command SHOULD
|
|
expose interfaces to both block a JID without reporting it as abuse, and to
|
|
block and report a JID.
|
|
</p>
|
|
<p>
|
|
The blocking command may be used to block multiple JIDs at the same time.
|
|
When blocking multiple JIDs any abuse report only applies to a single JID.
|
|
If the client allows selecting multiple JIDs in an abuse reporting dialog
|
|
they SHOULD also allow choosing a separate reason, text, and messages for
|
|
each JID.
|
|
They MAY choose to only allow reporting a single JID at a time as well when
|
|
the "block and report" dialog is accessed, and multiple JIDs when the
|
|
"block" dialog is accessed.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
|
<p>
|
|
If one or more <text/> elements are present they SHOULD include
|
|
'xml:lang' attributes specifying the natural language of the XML character
|
|
data.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
This document introduces no additional security considerations above and
|
|
beyond those defined in the documents on which it depends.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
|
<p>This specification defines the following XML namespace:</p>
|
|
<ul>
|
|
<li>urn:xmpp:reporting:1</li>
|
|
</ul>
|
|
<p>
|
|
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;.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
|
&NSVER;
|
|
</section2>
|
|
<section2 topic='Abuse Reporting Registry' anchor='registrar-reporting'>
|
|
<p>
|
|
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 representing the reason.
|
|
</p>
|
|
®PROCESS;
|
|
<code>
|
|
<![CDATA[<reason>
|
|
<name>The human-readable name of the abuse report reason.</name>
|
|
<feature>URN representing the reason.</feature>
|
|
<desc>A natural-language summary of the reason.</desc>
|
|
<doc>
|
|
The document in which the report reason is specified.
|
|
</doc>
|
|
</reason>]]></code>
|
|
</section2>
|
|
<section2 topic='Abuse Reporting Reasons' anchor='registrar-reasons'>
|
|
<p>This specification defines the following abuse reporting reasons:</p>
|
|
<ul>
|
|
<li>urn:xmpp:reporting:spam</li>
|
|
<li>urn:xmpp:reporting:abuse</li>
|
|
</ul>
|
|
<p>
|
|
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:
|
|
</p>
|
|
<code><![CDATA[
|
|
<reason>
|
|
<name>spam</name>
|
|
<feature>urn:xmpp:reporting:spam</feature>
|
|
<desc>Used to report a JID that was sending spam messages.</desc>
|
|
<doc>XEP-0377</doc>
|
|
</reason>]]></code>
|
|
<code><![CDATA[
|
|
<reason>
|
|
<name>abuse</name>
|
|
<feature>urn:xmpp:reporting:abuse</feature>
|
|
<desc>Used to report general abuse that is not covered by a more specific reason.</desc>
|
|
<doc>XEP-0377</doc>
|
|
</reason>]]></code>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>
|
|
An XML schema will be added before this specification moves to draft
|
|
status.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Acknowledgements' anchor='acknowledgements'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
Thanks also (in no particular order) to Jonas Wielicki, Georg Lukas,
|
|
Daniel Gultsch, and Matthew Wild for their feedback.
|
|
</p>
|
|
</section1>
|
|
</xep>
|