R: R: R: [jdev] about spim techniques

[Peter Saint-Andre]

Ian Paterson wrote:
>>(I should be able to specify the error  message that's
>>returned to you when your message to me is blocked 
>>because you're not in my roster -- at this point we have 
>>something like a challenge-response system
> 
> 
> Yes. IMHO this will be one of the most important anti-SPIM techniques
> (along with the others discussed earlier - regarding registration, s2s,
> etc...).
> 
> So you see my server generating the challenge and validating the
> response? I think you're right. (I had been assuming it would be my
> client!)
> 
> I think servers should operate the same rules for subscription requests
> and messages. i.e. I shouldn't even see the subscription request until
> the other user has passed my server's Bot-Proof Challenge.

I don't think it's my server or my client that does this -- it's me. Who 
better to figure out if the other person is human than me? I don't think 
that automated bot-detection methods (client-based or server-based) are 
nearly as effective as human-to-human communication.

> My server should remember which users have passed my anti-SPIM test *and
> which users I have sent stanzas to*. In future those users could send me
> messages or subscription requests (unless I blacklisted them with
> Privacy lists of course).

Well, my client could simply update my privacy lists once I click the 
big "allow communications with this person until further notice" button.

> [RFC 3921 Privacy lists aren't really designed to block presence stanzas
> that are subscription requests (and allow all other presence stanzas
> through). It should still work though. If it can't be made to work then
> the client might have to produce the Bot-Proof Challenge itself when it
> receives a subscription request.]

RFC 3921 enables you to block all communication from another JID, so 
your first sentence is not accurate.

>>6. Ask people in my roster whether they know this person
>>(could be automated)
> 
> 
> Yes we do need a protocol for this. Of course it fits perfectly with the
> public key association techniques we've been discussing.

Sure thing, we've talked about that before on one of these lists. I'll 
work on a proto-JEP for that soon.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml