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 >>>>>> [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). >>> 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/
smime.p7s
Description: S/MIME Cryptographic Signature
