On Wed, Mar 20, 2013 at 5:26 PM, Jesse Thompson < jesse.thomp...@doit.wisc.edu> wrote:
> 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? > >> >> I think it's a little more complex than that. Firstly, Google is an attractive target to spammers. The chances are that many of us have a Google Talk account; possibly even more than one - as does every Android user, every gmail user, and so on. Secondly, subscription request spamming is particularly tricky because of the limited nature of the things, making deciding what's spam and what isn't harder. It'd be useful to know from Per and his colleagues what a spammy subscription looks like. I suspect that as spam becomes a problem on the network it'll be hitting Google first, as far and away the largest domain on the network. But because Google's policy has always been to restrict communications to only those with a presence subscription, counter to the rest of the community, then they'll be seeing a unique flavour to their spam, as well. Nevertheless, I think any spam will be hitting Google first, and the rest of us later, of whatever kind. So we need to work on this for our own benefit too. Peter mentioned ensuring that open registration is blocked - I think that open registration has proved itself our equivalent of open relaying in SMTP, and we need to campaign strongly against this. The majority of servers have no need to support IBR; I think we have to declare this seriously harmful at this point. Others have suggested including some kind of proof of acquaintance as a method for filtering subscription requests - I'd note that LinkedIn has long used something similar, but we need to be careful to ensure what we ask will be both difficult for spammers and easy for real acquaintances. Finally, I'd note that clients themselves can mitigate against subscription request spamming by ensuring that their UIs handle requests in such a way that won't promote spam. I've entirely forgotten how Google Talk presents requests; so I don't know if there's something that Google themselves can do here. Dave.
