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

Peter Saint-Andre stpeter at stpeter.im
Wed May 22 23:25:32 UTC 2013

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

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

Having said all that, I agree with you, Jesse, that we need to come up
with solutions here.

A number of related specifications have been proposed over the years.
Why don't we start there, figure out which ones have promise, and
start implementing and improving them?

Examples beyond the core of XMPP (e.g., authentication and encryption)

XEP-0158: CAPTCHA Forms (as applied to in-band registration, chatroom
joins, etc.)

XEP-0159: Spim-Blocking Control

XEP-0191: Blocking Command

XEP-0205: Best Practices to Discourage Denial of Service Attacks

XEP-0219: Hop Check

XEP-0268: Incident Handling

XEP-0287: Spim Markers and Reports

draft-ietf-xmpp-dna: Domain Name Associations (DNA) in XMPP

draft-miller-xmpp-posh-prooftype: Using PKIX over Secure HTTP (POSH)
as a Prooftype for XMPP Domain Name Associations

draft-ietf-dane-srv: Using DNS-Based Authentication of Named Entities
(DANE) TLSA records with SRV and MX records

We might also think seriously about doing away with in-band
registration (although CAPTCHA "protected" web registration doesn't
seem to be all that successful at discouraging spammers from
registering accounts, either).

Other suggestions are welcome.


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