[Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mathieu Pasquet mathieui at mathieui.net
Sat May 23 10:24:43 UTC 2020

On 12.09.2017 12:45, Georg Lukas wrote:
>* Sam Whited <sam at samwhited.com> [2017-09-12 01:52]:
>> I had assumed that the server would be storing things and we didn't need
>> to send it back, but maybe that's not always the case. This does seem
>> like the kind of thing we might need to store or send back somehow.
>Yeah, this is going to be challenging. I'd really love to get the
>message content and not just the sender JID on my spam reports. That
>would require either MAM or some ring buffer of messages, which is all
>not-so-neat, or the client to reflect the offensive message inside the
>report, which is also challenging on it's own, and adds the security
>problems Kim outlined.
>A trade-off solution might be to make MAM an (optional) prerequisite. A
>client supporting MAM could add the <stanza-id/> of an offensive message
>into the report, giving the server a sufficiently large time window to
>obtain the message from its MAM store.
>If either entity lacks MAM support, we fall back to blocking the JID
>without further knowledge of the actual message content.

Sorry for the necromancer update, but would it not make sense to allow 
stanza-id elements as children to the <spam/> and <abuse/> elements?

That would make for a pretty simple change, keeping existing
implementations working, but would also allow updated server implementations
to extract the message contents from the local MAM archive (if enabled).
If there is no archive, then the situation is the same as what it
currently is.


More information about the Standards mailing list