[Operators] Update on spammy invites

[Jesse Thompson]

OK, so...

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 
here.

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.

Jesse


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
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRSeCMAAoJEOoGpJErxa2pgcgP/1Txu0WJ8Ky+uMepqwOQ4sJp
> sdz1U0C3t+by7nhWeD8lWW3sayL6sE+jotKRMgjHj3fLtY1i3x9aLAMrIkUX4UGh
> EVOsNtmWS/CqL9AkF7IIq4H1qDSMhKFt929tEBAvX8jb5LGDHET7LEtv3ersI2Tn
> SFKKFd0RGcC29uqUUxSmKegeWW5098Z3SxEPHzJPSxTDTL5C0xXTYOkc3PsPTs96
> vGcB4Pv2/D5ihie/jb2f3RmsTWI5z/8UYZ+zlie7l0HSGTj5BsnQsdLxXeWSTm8v
> JlsABk9w0WNBNTjk58xco+58gDHv4gUinjVn2+8P6Cvyr5MV+XRyRow9EHCriPiW
> efcsDx1bGjiPuhkYBHo1O3PZJB6UlViCTwQxf8+GzdOhfbNqJalbBkxFZMxDVG/E
> 6IcQGgBvEjXD1lOk/qF4rfoVAM7ByEC/cYFqpNjn2/2f36SUrmEn3XmpyHdaCiQ+
> lFkQWB/twAbt34rB39athl/8vkPtFaFFFmF7t0Np/+FM08+YY82NQDbR70hZP7wt
> KXBWd8wDIeRTQBwT+KFp12kTdEyCl/tK2ZmKOxFoSiYOD7N656iEYu5ERPQgj93d
> huYaVEy/sXy301m/RHHHQjVZCNdBIUa8hAmBQNh4oIvLMn5Zb/U5kTtUAJfHpAmD
> VzsdD8zjpi7Ry8dYJayF
> =+XrO
> -----END PGP SIGNATURE-----