[Operators] Update on spammy invites

Per Gustafsson pergu at google.com
Tue Apr 9 17:03:11 UTC 2013


Another short update: we have rolled out spam filtering and removed the
need for whitelisting. Invites should be working now. We will be monitoring
and tuning filters as needed. Thanks for your support and understanding in
this group!

Per


On Fri, Mar 22, 2013 at 3:59 PM, Jesse Thompson <
jesse.thompson at doit.wisc.edu> wrote:

> 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.
>
> Jesse
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20130409/e824115f/attachment.html>


More information about the Operators mailing list