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. :) > 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. 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. >> >> 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 [email protected], 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). >>> 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 >>> 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. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
