[Operators] spam resistance (was: Re: google abandoning XMPP??)

Justin Uberti juberti at google.com
Wed May 22 23:35:03 UTC 2013

On Wed, May 22, 2013 at 4:25 PM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> Hash: SHA1
> On 5/22/13 2:40 PM, Jesse Thompson wrote:
> > On 5/22/2013 10:02 AM, Peter Saint-Andre wrote: On 5/22/13 8:52 AM,
> > Jesse Thompson wrote:
> >>>> Google failed to note the correlation of the drop in
> >>>> federated XMPP connections with the fact that Google Apps
> >>>> (which internally federates its hosted domains) and Office
> >>>> 365 (which doesn't support XMPP federation) are gobbling up
> >>>> the market as organizations move to the cloud.
> >>>>
> >>>> Oh well ... it always troubled me that people trusted
> >>>> Google's support for open protocols as somehow permanent to
> >>>> the nature of the company.
> >
> > Yes, it seems to have been a marriage of convenience (since
> > they're also dropping RSS via Google Reader, also cf. the SPDY work
> > to supersede HTTP, etc.).
> >
> > On the other hand, not needing to interoperate with Google Talk
> > might free us to more aggressively work on network security
> > improvements. I say let's take this as an opportunity rather than a
> > disappointment.
> >
> >> The one technical reason cited for the largest XMPP service
> >> operator to exit the XMPP community is that there is a spam
> >> problem; not a network security problem.
> >
> >> Improving network security doesn't improve the spam problem;
> I am speaking of network security in the broad sense: e.g., things
> like incident reporting and entity reputation and JID blocking in
> addition to authentication and encryption. It might be true that some
> of those don't directly help with spam resistance (I don't say spam
> prevention because nothing can fully prevent it), but now that we've
> been deploying these technologies since 1999 you might think that at
> least we could authenticate and encrypt our server-to-server
> connections (which at least might raise the bar for certain forms of
> attack).
> >> otherwise Google would have tried it.
> Given the vast resources at Google's disposal, they could easily have
> contributed even a few comments to the standardization efforts at the
> XSF regarding spam resistance and network security, not to mention
> code patches for popular XMPP servers or even fixes to their own
> service -- but they never got involved except for a few lonely and
> very occasional souls on this list.
> >> (As a comparison, the various email domain authentication and
> >> encryption schemes hasn't put a dent on email spam.)
> And how widely is SMTP authentication enabled? Not very.
> The best (least-worst) solutions to email spam seem to be based on
> statistical analysis of message content (Bayesian filtering and such).
> In fact gmail does a pretty good job of blocking spam, so I wonder if
> the folks at Google ever thought about turning that same technology
> against IM traffic. We'll probably never know.

> >> If there is any chance to woo Google (and the thousands of
> >> domains they host) back into the fold, then the spam problem
> >> needs to be the prime focus.
> I don't think it's a question of wooing -- it seems to me that they
> made their decision for business reasons ("don't be open") and the
> technical rationalizations were just air cover.

That seems like an overly cynical assessment of the situation. Speaking as
an individual, it is sad that spammers were more willing to adopt XMPP than
other IM networks, but so it goes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20130522/4259d5c7/attachment-0001.html>

More information about the Operators mailing list