On Wed, Feb 13, 2013 at 10:03:16AM -0700, Peter Saint-Andre wrote: > 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
Everything based on manual blocking continues to be your initially described game of whackamole. #1, #2 and #3 are important (them being based on manual intervention) but not as a first, but as a *last* line of defence. I think we should look more into what other systems, that have been dealing with spam for a much longer time, are doing against SPAM. Some things come to mind: 1. Limit the "attack vectors". This is really basic! Example: Right now a common SPAM (and/or DDOS attack) is to join a MUC with some multiline status, I have seen this in many rooms. On my server, some users register hundreds of MUCs within seconds. Why is all of this possible? It doesn't require any XMPP spec, server-software just have way to little SPAM-fighting mechanisms. 2. Integration into existing spam-fighting services. Many of the spam-registrations I see come from IPs listed on spamhaus.org or other blacklists. These services are there, AFAIK no XMPP server uses them. 3. Some services (i.e. Mollom[1]) send data to a central service and filter content based on information coming from *many* (in this case) websites. Why is there no such service for XMPP services? We have a couple of Drupal installations that use Mollom and it filters hundreds of comments every day. And I haven't received any complaint about false positives ever. > 4. Perhaps a general reputation mechanism Thats nice, but generally reputation mechanisms are complicated and don't see widespread adoption. Neither GPG nor CAcert are used at all outside of tech-circles. > 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? Many servers and users had great problems with spam for years, there are plenty of mails on this list alone. It should be a priority in this GSOC and should have been in the last years as well. And I'm really glad that "We don't need to worry about spam, because its just a little harder to spam on XMPP then on email" is finally not an argument any more ;-) greetings, Mati [1] http://mollom.com/ > > 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----- -- I only read plain text mail! I prefer pgp|gpg signed & encrypted mails!
signature.asc
Description: Digital signature
