On 5 Sep 2017, at 02:46, Peter Saint-Andre <stpe...@stpeter.im> wrote: > > On 9/3/17 11:53 PM, Evgeny Khramtsov wrote: >> Sun, 3 Sep 2017 17:07:32 -0600 >> Peter Saint-Andre <stpe...@stpeter.im> wrote: >> >>> Before we spend energy on building a reputation system, it would be >>> good to understand what problems it is intended to help solve. IMHO >>> nothing will solve 100% of the spam problem, but perhaps a reputation >>> system would help. It seems that it might also help solve attacks on >>> chat rooms. Anything else? >> >> I think this is quite enough. The only my concern currently is: do we >> really need such complex approach? After we (ejabberd) released the >> module which blocks any messages from unsubscribed users we got quite >> encouraging results. Currently spammers started to send >> subscription requests, although I'm not sure what they want to achieve, >> maybe they will stop doing this understanding this is a waste of time >> (I think nobody accepts their subscription requests). Any thoughts on >> this? > > Well, Google Talk had a similar policy years ago and it worked quite > well for awhile. If clients don't show the subscription request text > (which was probably a stupid idea in 1999, but we were so innocent back > then), I agree that the subscription requests are useless, although not > harmless because they can be distracting and confusing to most users. > > One suggestion I've heard is to require proof of work in order to even > allow a subscription request to be delivered by the recipient's server. > That seems like a promising approach, to me.
We had a discussion about this in the MUC the other day, and two approaches were suggested that I think have travel (not that this doesn’t, clearly spam is not something one ‘solves’ with a single technique). 1) Have clients provide an option where they won’t show subscription requests, but will automatically respond if the user has sent a request to the other end. This works for many people, where adding each other is fine. Together with only accepting messages from entities you’ve sent presence to, this should more or less completely prevent spam, at a cost of inconvenience. 2) For everyone else, who wants people to be able to send a request and not need it to be mutually triggered, servers could delay routing of the presence sub request, while they do some sort of ‘is this likely to be spam?’ checking. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
