On Wed, Sep 6, 2017, at 01:44, Remko Tronçon wrote:
> (e.g. no IBR, harder proof of validity)
XEP-0389 [1] was written to help with this. Feedback, implementations,
and mechanisms to make mass registrations harder are appreciated.
—Sam
[1]: https://xmpp.org/extensions/xep-0389.html
_
Wed, 6 Sep 2017 10:18:09 +0200
Georg Lukas wrote:
> a) Throttle per-IP IBR attempts
How? By restricting a period a single IP can register an account?
Doesn't work: spammers walk through the huge list of servers,
effectively bypassing the restriction.
> b) Throttle outgoing presence/messages fro
Hi,
just to add some (controversial) points to the SPAM debate:
The XSNDR spam is ridiculously easy to filter with some heuristics
(and prosody's mod_firewall). I'm blocking north of 10K messages per
day on yax.im. If you are still getting spam from XSNDR, your server
operator needs some urgent h
On 6 September 2017 at 08:29, Evgeny Khramtsov wrote:
> The problem is, last time I checked[1], one third of ejabberd servers
> were running ancient versions, like 5 years old or more. There are also
> lots of jabberd servers, not sure they have any registration protection
> at all. Seems like we
Wed, 6 Sep 2017 08:44:22 +0200
Remko Tronçon wrote:
> I was sort of hoping that you would come up with a magic trick after
> getting through your reading list.
Hehe, most of the problems in that list is about how to authenticate
remote servers in SMTP (like SPF, DKIM and so on). I didn't find lo
> Also, it might be easier to control this sort of thing in a silo like
> Signal than in a federated network like XMPP.
It's definitely easier for them, since they don't have to federate with
badly
setup servers that leave doors wide open, and their own users need to
verify a phone number before t
Tue, 5 Sep 2017 23:06:22 +0200
Remko Tronçon wrote:
> This couples presence (and the roster) even more tightly with
> messaging than it already is.
I agree that presences and rosters are second-class citizens in modern
IM world. We could use another stuff (like a requirement to accept or
reject
Tue, 5 Sep 2017 15:52:50 -0600
Peter Saint-Andre wrote:
> Given that all the XMPP spam I have ever received is about paying
> someone to send even more XMPP spam (nothing about pharmaceuticals,
> easy ways to make money, or anything really interesting like that), I
> expect that the senders will
Tue, 5 Sep 2017 15:20:05 -0600
Peter Saint-Andre wrote:
> Remko, what do you suggest?
>
> When I log in and receive dozens of spam messages, that's a degraded
> user experience. If we can use tools we have (such as rosters and
> presence subscriptions) to make that experience better, I'm all for
On 9/4/17 11:52 PM, Evgeny Khramtsov wrote:
> Mon, 4 Sep 2017 19:46:32 -0600
> Peter Saint-Andre wrote:
>
>> 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, t
On 9/5/17 3:06 PM, Remko Tronçon wrote:
>
>
>> On 5 Sep 2017, at 09:27, Kevin Smith wrote:
>>
>> Together with only accepting messages from entities you’ve sent presence to,
>> this should more or less completely prevent spam,
>
> This seems to be a recurring theme, and I'm not sure I like it.
> On 5 Sep 2017, at 09:27, Kevin Smith wrote:
>
> Together with only accepting messages from entities you’ve sent presence to,
> this should more or less completely prevent spam,
This seems to be a recurring theme, and I'm not sure I like it. This couples
presence (and the roster) even more
Tue, 05 Sep 2017 09:45:29 -0500
Sam Whited wrote:
> but you can't expect everyone else to do so
I pretty much expect that, because from my experience a contact list of
a typical Whatsapp user has virtually every contact with at least a
photo (and in the majority of cases it's her/his personal ph
On Tue, Sep 5, 2017, at 09:24, Evgeny Khramtsov wrote:
> Shouldn't a client provide a straightforward way to request the vCard?
> Because that's what I do before accepting any subscriptions (I
> personally deny requests with empty vCards immediately).
I would probably do the same if I got a reques
Tue, 05 Sep 2017 09:10:22 -0500
Sam Whited wrote:
> Removing the text doesn't seem like an appropriate solution to me in
> general. Presumably this means you get a request from an unknown JID,
> but now have no way to tell that it's spam and not a friend reaching
> out, so you possibly accept it
On Tue, Sep 5, 2017, at 03:07, Evgeny Khramtsov wrote:
> After we started receiving subscriptions from spammers I actually
> started to think to remove subscription text on server side :)
Removing the text doesn't seem like an appropriate solution to me in
general. Presumably this means you get a
Tue, 5 Sep 2017 08:23:57 +0100
Dave Cridland wrote:
> We're teaching client developers not to render the textual part of
> the subscription request, which for previously unknown contacts would
> normally prove most interesting
After we started receiving subscriptions from spammers I actually
sta
On 5 Sep 2017, at 02:46, Peter Saint-Andre wrote:
>
> On 9/3/17 11:53 PM, Evgeny Khramtsov wrote:
>> Sun, 3 Sep 2017 17:07:32 -0600
>> Peter Saint-Andre wrote:
>>
>>> Before we spend energy on building a reputation system, it would be
>>> good to understand what problems it is intended to help
On 5 September 2017 at 06:52, Evgeny Khramtsov wrote:
> Mon, 4 Sep 2017 19:46:32 -0600
> Peter Saint-Andre wrote:
>
>> 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 a
Mon, 4 Sep 2017 19:46:32 -0600
Peter Saint-Andre wrote:
> 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.
Clients should support it, that's the problem.
On 9/3/17 11:53 PM, Evgeny Khramtsov wrote:
> Sun, 3 Sep 2017 17:07:32 -0600
> Peter Saint-Andre 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, b
Sun, 3 Sep 2017 17:07:32 -0600
Peter Saint-Andre wrote:
> I did some reading about reputation systems last year, and my
> recollection is that they are not proven to help all that much with
> spam compared to the cost of implementing them, but I'm very much
> open to better evidence.
Sorry, I mi
Sun, 3 Sep 2017 17:07:32 -0600
Peter Saint-Andre 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 th
Hi Evgeny,
On 9/3/17 2:57 AM, Evgeny Khramtsov wrote:
> Since the SPIM discussion has sparkled again in the operators list, I
> would like to resurrect long-standing reputation problem in XMPP
> (see, for example, XEP-0275).
Thanks for bringing this topic back to the attention of the list.
Befor
Since the SPIM discussion has sparkled again in the operators list, I
would like to resurrect long-standing reputation problem in XMPP
(see, for example, XEP-0275).
We probably can consider how this problem is being solved in
distributed p2p systems. One of the popular approach to collect
reputati
25 matches
Mail list logo
