[Operators] Spammy invites
mati at fsinf.at
Thu Feb 14 09:44:22 UTC 2013
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
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) 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
> 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
> 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 ;-)
> - --
> Peter Saint-Andre
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
I only read plain text mail! I prefer pgp|gpg signed & encrypted mails!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Operators