[Operators] Update on spammy invites
jesse.thompson at doit.wisc.edu
Fri Mar 22 14:59:08 UTC 2013
On 3/21/2013 9:21 AM, Simone Marzona wrote:
> It often happened that for some reason if one single ip was sending spam
> messages all around than an entire c-class network was blacklisted...
> This was not funny for legitimate senders.
Yeah, that's a poor anti-spam implementation. I've used c-class
blacklists to greylist email, but using c-class blacklists for rejecting
email is not wise unless the anti-spam operator knows exactly what they
> What if if your xmpp chat server is blacklisted for just some day even
> if your users didn't do evil (cit) ?
It depends how the XMPP service operator implements anti-spam.
For example: Google is blocking invitations, not messages.
So, if you run a service that has a compromised account that causes you
to get blacklisted for a day, then it's not as big of a problem if
remote service blocks new invitation for that day, but still allows
messages to be sent between subscribed users.
> ...you can't trust users. Moreover if you're administering a xmpp
> service you DO NOT TRUST your users.
You're assuming that all XMPP services don't know who their users are.
Operators running an open registration service have different security
requirements than those who provide XMPP services to known users.
I was saying that you can't trust your "victim" users to have a client
that has anti-spam features to protect against the naughty users on
> Now some what if..
Oh good, brainstorming...
> - create some basic rate policy for specific message types (invites..)
> - use some Bayes rule to parse message content. Dirty job: some kind of
> pipe to spamc/spamd.. just like we did on old email servers.. (ok ok..
> performance problem ahead, difficult to parse file transfer, video/audio
> stream, otr-featured, and so on..)
> - some year ago I found that some University in UK used to log every
> message exchanged (the user was informed with a banner/service announce
> at logon time) for future analisys: could this be some kind of spam
> Open registration of users, in my opinion, is not the problem, and it
> isn't similar to open smtp.
> The problem is how to manage the user data AFTER registration: some kind
> of auto blocking of users based on chat behaviour, messages type/rate
> sent/received.. and so on..
I don't want to say that these are bad ideas, since effective anti-spam
needs to be multi-faceted in the face of evolving attacks.
However, Google is dealing with a situation where the spammer has to
only do this:
1. Generate an account on random service X
2. Invite one remote user to chat
3. Send one message
repeat step 3 if possible/desired,
repeat 2-3 if possible
repeat 1-3 forever
Assuming that there are any services that allow spammers to repeat step
1 without restriction, then the first win for anti-spam protection is
for receiving-side service operators to blacklist those abusive services
from sending any invitations.
We can't rely on XMPP service operators to voluntarily begin restricting
account creation, any more than SMTP operators relied on open relayers
to voluntarily disable open relaying.
More information about the Operators