[Operators] Update on spammy invites

Sebastián Odena sebodena at gmail.com
Tue Apr 9 08:58:05 UTC 2013


Please.... I'm allways having troubles sending subscription requests to
gmail or google apps account. I send like 100 per day because is a free
live chat service and users link their website to their gmail account.

 I was supposed to be in a white list but now users are not receiving their
subscription request and I have hundreds of complaints by mail.

Could somebody explain me what do I have to do, or which is the daily limit
if any?

thanks so much,

Sebastian


On Fri, Mar 22, 2013 at 11:59 AM, 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/c0742a66/attachment.html>


More information about the Operators mailing list