Hello,

After writing my original email, I got a bit of feedback from the XEP's author out-of-band. They suggested making the additional field less 'vague', by using more explicit options. We briefly discussed the options provided by equivalent functionality in Mastodon. I can see the value in that.

I'd like to avoid introducing a large amount of options, as those would probably confuse and/or be ignored by end-users.

Instead of the one field that I originally suggested, lets have two boolean-based fields:
These options roughly correspond with the options given in the "software support" listing on xmppbl.org (see https://xmppbl.org/software )

Furthermore, I suggest that the XEP:
  • Explicitly mentions that clients may offer the options to an end-user whenever they are reporting a spam message, but also could use a (configurable) default that is automatically applied.
  • Define that servers MAY ignore 'true' values when their implementation does not provide the corresponding functionality.
  • Define that servers MUST NOT invoke corresponding functionality when the fields are provided with a 'false' value.
  • Discourages (SHOULD NOT) anonymizing the report to the origin server, as it hurts processing without adding any significant protection: it is likely that the origin server can easily look up the original stanza in their local message archive anyway.
  • Allows (MAY) anonymizing any submission to third-party analytical services (with instructions: remove the 'to' but not 'from' address, to protect the reporter, but not the spammer)
  • Define what the servers should do when the fields are not provided, but when the server does implement the corresponding functionality. Should that be a SHOULD NOT?
Unless there's feedback on this list within the next few days, I'll draft a PR that applies these suggested changes to the XEP.

Kind regards,

  Guus

On Mon, Feb 3, 2025 at 10:29 PM Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
Hello,

XEP-0377 describes a mechanism to report spam or abusive content to the local domain. While implementing the server-sided part of this, I was trying to think of useful processes that could follow a report.

Some of those actions could include sharing the report with third parties, such as the origin server of the spam, or a centralized spam-related collection service (like xmppbl).

There is a privacy aspect to this. An end-user that flags a particular message or entity might not realize or even appreciate that their report is being forwarded to others than the local domain.

I suggest having an additional field added to the data structure that is already defined in the XEP. This field is used by the reporter to signal if they agree to share the report with third parties. Clients could present this option as a checkbox that reads something like "Allow this report to be shared with relevant third parties" (or better words).

Kind regards,

  Guus