[Operators] How-to fight with SPAM accounts

Peter Saint-Andre stpeter at stpeter.im
Fri Dec 11 22:28:19 CST 2009


On 12/11/09 9:08 PM, Mihael Pranjić wrote:
> On 2009-12-12 04:06, Peter Saint-Andre wrote:
>> On 12/9/09 2:51 PM, Jesse Thompson wrote:
>>> On 12/3/2009 3:02 PM, Peter Saint-Andre wrote:
>>>> On 12/2/09 2:22 PM, Jesse Thompson wrote:
>>>>> Peter Saint-Andre wrote:
>>>>>> On 11/25/09 11:53 AM, Jesse Thompson wrote:
>>>>>>> Peter Saint-Andre wrote:
>>>>>>>>> I think that the key for the 'right/best' anti-SPAM XMPP solution
>>>>>>>>> is to
>>>>>>>>> involve regular/polite XMPP users in any way.
>>>>>>>> I have my doubts that normal users will bother to flag messages as
>>>>>>>> spam.
>>>>>>>> However, given that I have only ever received a few spam messages
>>>>>>>> over
>>>>>>>> XMPP (and even those I wasn't 100% sure about), perhaps it would
>>>>>>>> not be
>>>>>>>> such a huge burden.
>>>>>>> I like the idea of account level reputation.  The current, most
>>>>>>> troublesome, battlefront on the war against email spam is dealing
>>>>>>> spammer-created freemail accounts,
>>>>>> Most of the large, public XMPP IM services essentially offer "freechat"
>>>>>> accounts. The use of CAPTCHAs at, e.g., jabber.org is a small hurdle.
>>>>> CAPTCHAs won't stop them from creating accounts.
>>>> Agreed. That's why I said the hurdle was small. :)
>>> This idea is probably too elaborate, but I'll throw it out there since
>>> it would actually leverage CAPTCHAs nicely.
>>>
>>> Would it be possible for the server to force the sender to solve a
>>> CAPTCHA for every "new" conversation between users that have not already
>>> authorized each other in their rosters?
>> I think it's better to use CAPTCHAs for making a subscription request.
>> Once that happens, there is implicit trust. We discussed this years ago,
>> see XEP-0159.
> CAPTCHAs are fine, you will have less accounts that could be created by
> bots/non-human-whateveryouwanttocallit. So IMHO CAPTCHAs are a really
> really fine idea, but this still leaves us with some accounts that are
> created and not properly used.

So what? We've had that for 10+ years. Unused accounts are a fact of
life, not a problem.

> So how to fight with that? Should it be a standard of XMPP services to
> remove accounts that were just created and then not used for 2 weeks or
> more. 

IMHO that is not a best practice for XMPP operators.

> Should it even be a standard to remove accounts at all? 

Unclear, and a different thread.

> Are we
> removing them because we want someone else to use the JID that becomes
> free or do we want a database without unnecessary accounts? If you want
> to bypass the problem of the identification of a person and also save
> disk space and have less "spam" accounts in your database there would be
> a simple solution. Keep a table with deleted accounts and disallow
> re-registration.

Sure. Make a feature request or send in a patch to your favorite server
project. :)

> What we get: only one person can register it, and we can safely remove
> accounts. Maybe not only an unsubscription request should be sent to all
> the contacts of the roster, but also a message containing for instance
> "This account has been automatically removed by our system because it
> was not used". This would leave it open if you should allow
> re-registerin because in a way the contacts would be informed that the
> account was deleted.
> Also it would be possible to keep a list when accounts were deleted and
> re-registered. It takes a huge database but would make it possible to
> see if an account still belongs to the person you think it does. If you
> see that it apparently changed owner you can assume that it is not the
> same person.This idea again leads to some kind of centralization of data.

Single point of failure. Never a good idea, and opposed to the basic
XMPP philosophy of decentralization.

> So in short imho:
> CAPTCHA - yes
> Problems - not really solved

The problems are not clear to me in what you describe. The issue of
deleted accounts is tangential to the spam issue.

>>> And here is another off the wall idea:  Or is there some way to
>>> implement greylisting in XMPP?  The idea here is to initially tempfail
>>> (if that is even possible in XMPP) a "conversation", but then accept it
>>> when the sending server retries.
>> Greylisting in XMPP seems counter-productive, because the whole idea of
>> IM is that it's supposed to be instant.
> Instant should indeed stay instant :)

I'm glad we agree about something.

>> Do you mean greylisting for servers or for clients?
> 
>>> and another idea... is there a way to implement content scanning?  If I
>>> get an unsolicited message from someone not in my roster, then can the
>>> client or server send the content to a service for classification?
>> That won't work if people use end-to-end encryption.
> 
>>>>> Take a look at this
>>>>> list of email "phishing reply dropbox" email addresses that we have been
>>>>> collecting over the past year or two.
>>>>>
>>>>> https://aper.svn.sourceforge.net/svnroot/aper/phishing_reply_addresses
>>>> Nice. And some of those double as IM addresses.
>>>>
>>>>>>> and with phished account credentials
>>>>>>> on closed systems.
>>>>>> I think we've seen less of this on the XMPP network because we don't
>>>>>> have very good web integration.
>>>>> No, the phishers just ask the users to reply via email with their
>>>>> account credentials.  The link above is a list of these reply
>>>>> destination email accounts.
>>>>>
>>>>> Or, they put up a web form somewhere.
>>>>>
>>>>> You would be surprised how many users will give away their credentials
>>>>> to anyone that asks.
> Steps to protect yourself:
> * install norton XMPP security pack
> :D :D :D
> (jk, sorry phishing reminds me of "security" software)
>>>> Sadly, you're probably right.
>>>>
>>>>>>> You could apply an account-level reputation system at the server as
>>>>>>> well
>>>>>>> as the client.
>>>>>>>
>>>>>>> An XMPP operator could set up the server to block domains whose
>>>>>>> trustworthy account ratio is below their tolerance level.  This would
>>>>>>> effectively block domains that have only spammers.  But it would not
>>>>>>> block domains like jabber.org or gmail that are trustworthy but have
>>>>>>> spammers signing up for free accounts.
> So you are going to keep a list of servers which in your opinion are
> safe but have spammers? how scalable is this?
>>>>>> Agreed.
>>>>>>
>>>>>>> For spamming accounts in trustworthy domains, the server operator
>>>>>>> could
>>>>>>> set it up to block accounts that meet a certain untrustworthiness
>>>>>>> threshold.
>>>>>> So when mydomain.com receives an inbound stanza from
>>>>>> user at jabber.org, it
>>>>>> would check the trust score of the sender?
>>>>> yeah
>>>> That could generate a lot of traffic. Perhaps it could be optimized to
>>>> check only on the first message received in a chat session (although
>>>> "chat session" is mostly undefined at the protocol level).
>>> Yeah.  However, keep in mind that the server/client can inherently trust
>>> any traffic that is between users that have already authorized each
>>> other in their rosters.
>> Right. We need to leverage things we have in IM that don't exist or are
>> cumbersome in email (e.g., rosters and presence subscriptions). You'll
>> notice that Google does that in Google Talk (presence subscription
>> required before sending messages).
> 
>>>>>>> Or, the users could do it at the client level.
>>>>>> That seems like more work. See above about user laziness. :)
>>>>> My thought was more that ambitious developers will be more able to
>>>>> integrate it into the clients before it is adopted into server software
>>>>> and deployed by the operators.  Think of it as a way to bridge the gap.
>>>> I'm not opposed to both methods, although I think that development of
>>>> clients and servers is about equal in speed these days.
>>> It has more to do with necessity.  Right now, there aren't enough users
>>> of a service that actually have a problem with spam to justify a service
>>> operator to spend time implementing anti-spam.  Those users who have a
>>> spam problem would gravitate to clients that support anti-spam in the
>>> mean time.
>> Gosh, the problem is that we don't have any spam!
> I thouht this was about SPAM ACCOUNTS, not spam being sent around? 

Both. Spammers send spam. :)

> o.O

What the hell is "o.O"???

> Afaik we were trying to find a way to safely remove unused accounts on a
> server. Spam may become a problem, but you can just block a user and the
> problem is gone.

I don't care about unused accounts, except that I don't want a million
accounts clogging up the jabber.org service. 330,000 semi-active
accounts is enough for me.

>>>>> Anti-spam scanning was built into email clients well before it became
>>>>> common on the server-side (around 2002.)  Once the servers caught up,
>>>>> the client approach became less effective, but it is still useful in
>>>>> some situations.
>>>> Agreed. And the client-side approach might tie in nicely with rosters.
>>>>
>>>>>>> The key is to figure out how to collect and expose the data in a
>>>>>>> private
>>>>>>> way.
>>>>>> Your thoughts are welcome.
>>>>>>
>>>>>> Do you mean the scores need to be private, or the source data needs to
>>>>>> be private?
>>>>> I was initially thinking of a trust network: I trust someone who is
>>>>> trusted by the people I trust.  I could then set it up so that people
>>>>> who are very trustworthy are allowed to send me anonymous messages and I
>>>>> will auto-authorize into my roster, someone who is completely foreign to
>>>>> my trust network is blocked from sending messages, and various levels in
>>>>> between.
>>>>>
>>>>> Some of this data is already available within the server roster
>>>>> databases, but otherwise it would have to be fed by opt-in contributers.
>>>>>   The problem with this trust network approach is that the data could be
>>>>> mined by spammers and phishers, so it would need to be kept private
>>>>> somehow.
>>>>>
>>>>> Otherwise, traditional DNSBLs (specifically, URIBLs of JIDs) are the way
>>>>> to go.  It might be possible to work with the existing DNSBL providers
>>>>> to create a new blacklist of JIDs.
>>>> Yes, that's worth exploring, though I'd like a way to query it in XMPP
>>>> and not over DNS.
>>> As an analogy, in regards to cross-network IM, we have some clients that
>>> rely on transports, and others that implement the protocol directly. The
>>> DNS part of the implementation should be relatively easy since clients
>>> already look up SRV records, but the UI would be non-trivial regardless
>>> of how the client does the query.  If it's implemented using service
>>> discovery, then the user could configure their client to use an external
>>> anti-spam service just like they can use an external transport today. 
>>> But there has to be someone willing to run the service.
>>>
>>> How the anti-spam plugin/service is implemented depends on where the
>>> data is stored.  If you want to leverage existing URIBLs, then the
>>> plugin would have to be capable to querying via DNS.  Are DNSBLs still
>>> using DNS because it is the best way to do it, or is it just legacy?
>> IMHO because it's legacy. We could do the same thing over XMPP, without
>> pushing more stuff onto the DNS that it wasn't designed for.
> 
>>> That's something I'm not sure of.
>>>
>>> I kind of wish that our service actually got spam so that I could try
>>> out some of these ideas. :-)  Spammers: hit me!
>> I've said that before, too. It still hasn't happened. But doesn't mean
>> it won't happen. "Be careful what you wish for..."
> Agreed!
>> Peter
> 
> Ah just a side note: should the security related discussion be moved to
> the security list, and the "spam account removal" thing is discussed
> here? IMHO spam/phihing/blacklists is security related. The original
> post from Mati starting this thread was about removing unused accounts
> from a server, that surely could belong into operators list. If you dont
> think so just ignore this side-note :D

Duly ignored. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/operators/attachments/20091211/9b461c15/attachment-0001.bin>


More information about the Operators mailing list