[Operators] Update on spammy invites
jesse.thompson at doit.wisc.edu
Wed Mar 20 17:26:46 UTC 2013
Maybe I missed something. Didn't I read that Google is blacklisting
*all* invites from *all* external XMPP services? What you said
indicates that they are only blocking invites from some services.
Which is correct?
Google might have a perception problem ...
It appears that the technologists at Google are still apparently
committed to reimplementing XMPP federation and CalDAV client support
(another topic). But the public statements offered by Google corporate
are indicating that Google is starting to do exactly what every other
company does with open standards. They use open standards only when it
is advantageous to their bottom line. What's going on? I suggest that
the Google techs fix the public corporate statements if they aren't
accurate. Google has a credibility issue with the internet community
Specifically on the spammy invite issue...
In the email world, "open relays" exist; and email administrators
solved the problem by creating various blacklists that identify open
relays and other types of "spammy" reputations. Every email service
today uses various levels of reputation to stop spam. IP reputation is
still a primary method for identifying email spam. I really don't
understand why blacklists aren't the solution for identifying and
blocking "open" XMPP services. XMPP service providers won't start
putting hurdles on account creation until after they get blacklisted.
Frankly, I wouldn't be aware if a public XMPP blacklist already exists,
since our university doesn't have the problem of XMPP spam. It seems
that the spammers are only targeting certain services, such as Google.
This might explain why Google feels that the XMPP community isn't
supportive in dealing with their spam problem (e.g. by means of
maintaining public blacklists). Are my thoughts on this correct?
Now, maybe I'm not understanding the problem Google is dealing with...
Are these spammy invites coming from XMPP services that are otherwise
restricted to authorized users? We certainly deal with end-user
credential getting compromised for purposes of sending email spam, so
it is logical that the spammers might also use these credentials to
send XMPP spam. I think that this is an interesting problem that needs
new clever solutions; both for email and chat.
Can I suggest an option for Google? It might not be feasible. How
about automatically whitelisting the invite initiator if the Google
user has had an email correspondence with that recipient? e.g. If
pergu at google.com has sent an email message to
jesse.thompson at doit.wisc.edu, then you can be relatively certain that
an XMPP invite from jesse.thompson at doit.wisc.edu to pergu at google.com is
legit. I know that this technique only works if the JID is the same as
the mail address, but it might be a partial solution.
On Wednesday, March 20, 2013 11:15:09 AM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 3/20/13 8:47 AM, Per Gustafsson wrote:
>> Quick update: restricting federated invites has significantly
>> reduced the spam problem for our users. We continue to work on this
>> problem and expect to roll out a solution next week that does not
>> require whitelisting.
> Hi Per, thanks for the update!
> While I realize that Google needs to do what is best for itself and
> its users, I also encourage everyone here to think about and work on
> solutions that will enable us to maintain federated communication in
> the long term. Among other things, that might mean shutting down open
> (non-CAPTCHA-controlled) registration on public XMPP servers. We might
> also reconsider some of the technologies we've been working on over
> time, such as automated incident handling (XEP-0268), server / user
> reputation (XEP-0275), and the blocking command (XEP-0191). Federation
> is very important, and we can't allow some script kiddies to make us
> stop communicating.
> - --
> Peter Saint-Andre
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
More information about the Operators