[Operators] How-to fight with SPAM accounts
stpeter at stpeter.im
Thu Dec 3 15:02:05 CST 2009
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
>>>> 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. :)
> Take a look at this
> list of email "phishing reply dropbox" email addresses that we have been
> collecting over the past year or two.
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.
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.
>>> For spamming accounts in trustworthy domains, the server operator could
>>> set it up to block accounts that meet a certain untrustworthiness
>> So when mydomain.com receives an inbound stanza from user at jabber.org, it
>> would check the trust score of the sender?
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).
>>> 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.
> 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
>> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Operators