[Operators] Update on spammy invites

bear bear42 at gmail.com
Tue Apr 9 18:51:11 UTC 2013


Per,

a number of people have asked about Google sharing the techniques you are
using for this - is that something you can ask about?

thanks!


On Tue, Apr 9, 2013 at 1:03 PM, Per Gustafsson <pergu at google.com> wrote:

> 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
>>
>
>


-- 
Bear

bear at xmpp.org (email)
bear42 at gmail.com (xmpp, email)
bear at code-bear.com (xmpp, email)
http://code-bear.com/bearlog (weblog)

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20130409/b4b8d681/attachment.html>


More information about the Operators mailing list