[Standards-JIG] privacy2 anti-SPIM proto-JEP

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Aug 29 20:37:12 UTC 2005

On Mon, 29 Aug 2005 22:20:47 +0200, Bart van Bragt <jabber at vanbragt.com>  

> Tijl Houtbeckers wrote:
>> 2. Server asseses the probability that the request is SPIM. There can  
>> be many ways of doing this, that are left undefined for now, besides  
>> the obvious (is it in the roster or whitelisted in the privacy list).  
>> These could include looking at the server it came from (is it trusted,  
>> does it have a good reputation, is it blacklisted by some etc), looking  
>> at who the user is (eg. is the user in the roster of any other users on  
>> this server, including in that of users who are in the roster of the  
>> target user, user reputation system, etc.), and possible sending a  
>> challenge or registration request etc. to sender.
> Maybe there's an opportunity here to incorporate the e2e web of trust in  
> this? Or use something like http://www.advogato.org/trust-metric.html  
> (yes, there it is again. Has been discussed on these lists since 2000  
> :D).

As you can see in my text, without going into it much, I listed this as  
one of the possible checks that could be done. I think it's important  
however, to define the generic procedure and protocol for spim checking  
first. That should make incorperating such tests a lot easier.
> BTW regarding email-xmpp and disallowing messages from people not in my  
> privacy lists. Is it an idea to differentiate between chats and messages  
> in the privacy lists?

Well, I could imagine a lower threshold for "email" messages. If  
email-over-xmpp will have some kind of special header to it that could  
work. In fact, when messages are longer (typical for email style messages)  
they become easier to work with for "traditional" email techniques again  
(bayesian filtering). If a long messages passes a bayesian filter, it  
would less likely be spim/spam.

> (of course I would like to keep my IM traffic as open as possible too).
> Something else that popped into my mind. If everyone would block  
> messages from other people not in their roster it would be pretty  
> difficult to create a function on a website to quickly send a message to  
> another Jabber user because you would first need to do the whole  
> subscribe thing.

Well if you do it by webform it's likely the jid is known to you (so you  
can white list it). If it's (for example) an xmpp uri, that's different.  
The advantage: the sending will most likely be handeled by your client  
which will do it's very best to proof your identity as a non-spimmer. Like  
I said, I think messages from people not whitelisted or in my roster  
should be treated the same way as a subscription request.

> Besides that blocking messages by default just doesn't work at the  
> moment because of the RFC requirement of silently dropping messages that  
> are matched by a 'deny' rule. This way I have no clue if the recipient  
> has blocked me, is too busy, has a crappy connection or just thinks that  
> I'm an annoying pest.

Right now if you send me a message, and I don't respond cause I don't like  
it, do you get an error message back? ;)

More information about the Standards mailing list