[Operators] spam resistance

Peter Saint-Andre stpeter at stpeter.im
Wed May 22 23:48:06 UTC 2013

Hash: SHA1

Justin, thanks for weighing in.

On 5/22/13 5:35 PM, Justin Uberti wrote:
> On Wed, May 22, 2013 at 4:25 PM, Peter Saint-Andre
> <stpeter at stpeter.im <mailto:stpeter at stpeter.im>> wrote:
> 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.

Justin, I am sorry if it comes across as cynical. From what I've seen
so far, I'd call it realistic. And really I'm not *blaming* anyone at
Google -- in fact, it's laudable that the Talk service remained as
open as it did for as long as it did. But times change and company
priorities do, too. I don't think Google ever got much out of being
open in that way (none of the other IM services - not networks - ever
really offered open federation, and the recent large silos only
reinforced that reality), so I completely understand if folks decided
that it just wasn't worth it any longer.


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Operators mailing list