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

[Ian Paterson]

> (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.

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).

[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.]


> 1. Automatic vCard lookup (who *is* this person?)

Yes. Nice implementation feature. [/me adds to tasks list.]

> 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.

- Ian