[Operators] spam resistance
stpeter at stpeter.im
Wed May 22 23:48:06 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
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:
> -----BEGIN PGP SIGNED MESSAGE----- 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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Operators