[Operators] How-to fight with SPAM accounts

Jesse Thompson jesse.thompson at doit.wisc.edu
Wed Dec 2 15:22:29 CST 2009

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.  Take a look at this 
list of email "phishing reply dropbox" email addresses that we have been 
collecting over the past year or two.


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

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


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

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.

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

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.


   Jesse Thompson
   Division of Information Technology, University of Wisconsin-Madison
   Email/IM: jesse.thompson at doit.wisc.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3317 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/operators/attachments/20091202/8ad70903/attachment.bin>

More information about the Operators mailing list