Standard advice to customer in the email world is to block countries that you don't do business with. Seems a bit extreme bit if you have lot's of registrations from lets say Iran and you don't have any users/customer there and don't want any the just block that country.
I have at least half a dozen clients who block the whole world except the the region they're doing business in, in this case Australia. [ducks...:-] David http://zerp.ly/dbanes xmpp: [email protected] Mobile: +44 (0)782 5138 214 On 13/02/2013, at 5:03 PM, Peter Saint-Andre <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/13/13 8:41 AM, aszlig wrote: >> On Wed, Feb 13, 2013 at 09:48:59AM +0100, Per Gustafsson wrote: >>> I work with Google's chat service, and we are seeing lots of >>> spammy invites from users on various federated domains, including >>> jabberes.org, jabber.se, jabber-hosting.com and jabber.org. Have >>> you noted an elevated amount of sccount creation etc., and is >>> there anything you can do about it in that case, otherwise we >>> will have to institute very tight limits of invites per day being >>> sent from federated domains. >> >> Here I've got the same problems as well (aszlig.net, >> headcounter.org, no-icq.org, noicq.org - not yet listed at xmpp.net >> since the rework) and i'm going to disable new registrations as >> soon as the load is low enough. The main target of these massive >> spammy subscribes is gmail.com and it's quite hard to track them >> down without "accidentally" locking out real users. >> >> My second step would be to reenable registrations and only allow >> verified users to use S2S. But I'm not sure about how to do this >> for every single user (maybe some kind of WoT within the local >> network?). >> >> So, any idea about how to mitigate this without forcing too much >> restrictions on real users (like for example I'd want to avoid >> captchas)? > > Well, as we know CAPTCHA doesn't really work. It's better than > nothing, but it's not very good. > > Furthermore, I think these spammers don't need that many accounts, and > therefore don't need to auto-create them. They can simply go to the > web page where one creates accounts - such as > https://register.jabber.org/ - and hand-register a few accounts as > needed. Once we disable one of their accounts, they create another > one. It's a game of whackamole. > > IMHO we need: > > 1. Better blocking of spammers by users > 2. Better reporting of spam from users to services > 3. Better reporting of spammers from service to service > 4. Perhaps a general reputation mechanism > > We have specs defined for #1, #3, and #4 (i.e., XEP-0191, XEP-0268, > XEP-0275). We've talked about #2 as well (and a service could make > guesses about who the spammers are based on XEP-0191 requests and > other hints). However, we don't have implementations and we haven't > deployed these methods. > > Perhaps it would make sense for this to be a priority during the > Google Summer of Code if the XMPP Standards Foundation is accepted as > a sponsoring organization? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRG8dTAAoJEOoGpJErxa2pddMP/21lOzbC/WTycr8Qq84xRsol > ZL6I87zVG7rhhPNQRrDeSz6puYncdYx44YpBm97BxcokY47rtLaEfXfMd43d/8sP > glCENleyUa6xuCWZzee3GL+lUdan5vIqIhxz2pc1wIo4W/SgGSpRgdMLvEsH68iU > BROVH/0PjmMqNI82vFvkRe3YsfwUS0Kq45eJNXWLpY6H8B6MoAD27ybB52TW4rDR > Zwp3wsWw4akJm3gddOvCkgCihCe7jvNTBj1wkqJnX6FHFblqq+TVyLIkKZXgPnbf > Go1RLUyfP/wazCtUqMQepFWPNSoZ7+xrSD60wa38cNHj8iA7GDnti0WxhaYA2MF5 > QpnZz/WEfIBnMAy3c2JnHiGe9JLt9aTja5v+YA7AmBLEmLp3gngT7dTWAgo/XYhG > n5ad4vd61XjJO1cONeeBljuqa3aypXmhEnbRvSDTRmhpGPehqxQEvLoYLGDLsqFG > E7NlnNG4LH6neFglP3tgvFKoHsK6ZVGUBnlQQFWz92fVvqBrr+ptOGk7MpTKCzo3 > bPFrBwX0AuzgWRpxhnDif6oLP3mvUbzx8Tgb8JKYnZbU+FKRT/iVoRaZDKWmRGVy > 2mGU6iLtLg0Xyht6ao/7cPi3znJYfiTgdbVCbQuJOVxVklA8fE/yRDuaVQzhe7kS > 937vnedJEq3DwGZ8nxsQ > =NXzE > -----END PGP SIGNATURE----- >
