[Standards] DEFERRED: XEP-0377 (Spam Reporting)
flo at geekplace.eu
Sat May 23 10:38:12 UTC 2020
On 5/23/20 12:24 PM, Mathieu Pasquet wrote:
> 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?
It never can hurt to provide additional information, especially if it is
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards