[Operators] Update on spammy invites

Jesse Thompson 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 
are doing.

> 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 
remote services.

> 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
> training?
> 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 mailing list