> > So you see my server generating the challenge and validating the > > response? > > > > 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?
Are you saying that message triggered challenges should be handled by the server, but subscription request challenges should be handled by the user? If so, then SPIM bots will concentrate on sending subscription requests instead of messages. Of course users won't want to be bothered with these bot requests. So why not allow the server to filter out the bots - and then allow the user to filter out the unwanted humans using the techniques you described? (Especially since the server will already have the challenge functionality in place.) > I don't think that automated bot-detection methods > (client-based or server-based) are nearly as effective > as human-to-human communication. Yes. But the point is that humans don't want the job of filtering out bots themselves. Most people hate manually filtering out the SPAM from their email inbox. The cost to users of responding to an occasional Bot-Proof Challenge is small, and perfectly acceptable, when they compare it to the countless bot-generated messages/requests they would otherwise have to filter every day. > > My server should remember which users have passed my anti-SPIM test > > *and which users I have sent stanzas to*. > > Well, my client could simply update my privacy lists once I click the > big "allow communications with this person until further notice" button. Yes, but, simple clients etc. > > RFC 3921 Privacy lists aren't really designed to block presence > > stanzas that are subscription requests (and allow all other presence > > stanzas through). > > RFC 3921 enables you to block all communication from another JID, so > your first sentence is not accurate. I'm not sure you understood what I was trying to say. I meant that RFC 3921 cannot, for example, be used to block <presence type='subscribe'/> while allowing through <presence type='subscribed'/> from the same user. > Sure thing, we've talked about that before on one of these > lists. I'll work on a proto-JEP for that soon. Thank you :) - Ian _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
