[Operators] How-to fight with SPAM accounts

Mihael Pranjić tux at limun.org
Fri Dec 11 22:08:47 CST 2009

Hash: SHA1

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 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. Should it even be a standard to remove accounts at all? 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
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.

So in short imho:
Problems - not really solved
>> 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 :)
> 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? 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.
>>>> 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..."
> 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
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Operators mailing list