On 3/20/2013 1:03 PM, Dave Cridland wrote:
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.
I agree. Google's action is evidence that IBR is threatening the sustainability of XMPP federation.
An implementation of the equivalent of ORDB, and the adoption of DNSBL checks in the popular chat servers, would probably be effective in getting services to disable IBR. I wonder if a DNSBL provider like SpamHaus would be willing to share their infrastructure for an XMPP blacklist of IBR-enabled services?
I feel like we had this discussion about adding DNSBL support in XMPP services years ago. Maybe people have already done this, and it's just not popularized?
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.
I suppose my unoriginal suggestion of allowing unimpeded invitations between email correspondents is an example of that. I suppose Google, and others, could implement that in the client, or in the server.
It would be hard to create a specification for that sort of thing. Perhaps a proof of concept implementation of an acquaintance-driven subscription-whitelist which is proven to work would be enough to gain traction among the XMPP server plugin authors.
Jesse
