[Operators] Update on spammy invites

[Jesse Thompson]

On 3/20/2013 6:09 PM, Peter Viskup wrote:
> On 03/20/2013 07:03 PM, Dave Cridland wrote:
>> Peter mentioned ensuring that open registration is blocked - I think
>> that open registration has proved itself our equivalent of open
>> relaying in SMTP, and we need to campaign strongly against this. The
>> majority of servers have no need to support IBR; I think we have to
>> declare this seriously harmful at this point.
>
> Please stop spread this myth. IBR isn't nothing like open relay in SMTP.
> Any web-form based registration isn't solution to this situation. I am
> seeing a lot of automated registrations on my Drupal sites for example.

Drupal isn't analogous to XMPP federation.  A spammer can misuse *your* 
Drupal to spam *your* site, but doesn't allow them to spam *my* site.

If your chat service is going to participate in XMPP federation, then 
there needs to be hurdles to spammers in creating accounts on your 
service.

Disallowing automated registration is a good first step, but it's not a 
complete solution.

Any open service (even Gmail) that permits any sort of open 
registration, even if it has CATCHAs or whatever, needs to add 
safe-guards against the misuse of their service by the accounts that 
have been created.

Even if you don't allow open registration, the XMPP service operator 
needs to be responsible in dealing with accounts that get compromised by 
a spammer.

In the email world, neglecting to prevent misuse of your SMTP submission 
service results in your SMTP servers getting blacklisted.  You don't get 
off the blacklist until after you've proven that the abuse has stopped.

What makes chat any different?


> Did anybody performed some investigation and proved which servers are
> used for these attacks and if all of them are IBR-enabled? I'm not aware
> of anybody - didn't see list of the servers.

Apparently not.

Due to the (apparent) fact that there is no system for XMPP operators to 
identify abusing services, Google is now assuming that *every* service 
is a threat.

If we want Google to stop lumping the good services with the bad, then 
there needs to be a maintained public blacklist.


>> Finally, I'd note that clients themselves can mitigate against
>> subscription request spamming by ensuring that their UIs handle
>> requests in such a way that won't promote spam.
>
> Agree - for example Gajim client has 'Anti-Spam' extension which
> probably can be used as an protection against this (I don't use it/not
> sure about it).

Google users don't use Gajim.

The reality is that the whole of the clients haven't implemented spam 
protection; much less implemented it consistently.  Given reality, how 
can we say that client-side anti-spam presents any solution to this problem?

The XMPP service that our team runs has around 1200 active users, and 
they all use a different client of their choosing.  There is no way to 
effective protect our users from spam.  Not to discredit Gajim, telling 
them to use a different client won't fly.

Around the year 2000, client-side email spam filters were very popular, 
and they worked pretty well.  But client-side filters only work for 
savvy users.  If client-side filters are so effective in stopping spam, 
then why does essentially every email service now implement server-side 
spam protection?

Jesse