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

[Sander Devrieze]

Op maandag 29 augustus 2005 21:58, schreef Tijl Houtbeckers:
<snip>
> By using the techniques discussed in this thread by me and others. My
> prefered model is this.
>
> 1. A subscription request (with potential extentions that could help it)
> arrives at the server.

I also like to receive messages from people not in my roster. (This will be 
also needed when XMPP replaces SMTP as a spam-proof alternative ;-) )

So my idea is this:

1) Introduction
* Receivy is the name of a receiver.
* Sendy is the name of a sender.
* Sendy might be a spimmer, but this is not known.

2) Receivy sets his privacy list (during/after registration).
a. Receivy uses his client that supports the Bot Challenge JEP.
b. Receivy sets for example a question and a set of possible good and wrong 
answers (he also can choose CAPTCHA etc if his server supports that). He sets 
the same question for for all incoming messages from people not in his roster 
(thus including subscription requests).
c. Receivy sets the small time interval between different tryings from the 
sender.
d. Receivy sets the long time interval.
e. Receivy sets the maximum number of tryings before the long time interval is 
enabled.
f. Receivy's server stores this information and generates a secret.

3) A few weeks later Sendy sends Receivy a message or subscription request.
a. Receivy's server looks to Receivy's privacy list and sees the Bot Challenge 
question.
b. Receivy's server looks if there is a secret attached to the subscription 
request or message. This is not the case.
c. Receivy's server drops Sendy's message and sends Receivy the Bot Challenge 
question (including a random set of answers defined by Sendy) from Sendy's 
privacy list.
d. Sendy answers the Bot Challenge question and sends it to Receivy.
e. Receivy's server sees Sendy answered too fast (he couldn't have read the 
question!), it drops the message, and sends the Bot Challenge question (with 
*other* random answers!) to Sendy again.
f. same as d
g. same as e
h. same as d
i. Receivy's server sees Sendy answered too fast, drops the message, and sees 
that the maximum number of tryings is exceeded. The server enables the long 
time interval for Sendy. Receivy's server sends an error to Sendy indication 
that he should try again later (with or without the time?).
j. Sendy tries again before the end of the long time interval.
k. Receivy's server sees Sendy tried again too fast, it drops his message, it 
resets the long time interval, and replies the error to Sendy.
l. Sendy tries sending again after the long time interval.
m. same as a, b, c and d
n. Receivy's server sees Sendy answered the question in a reasonable time and 
compares the message with the good answers in Receivy's privacy list.
o. It was a wrong answer! The server sends the Bot Challenge question (with 
*other* random answers!) to Sendy again.
p. same as d and n
q. It was a good answer! The server sends the secret from Receivy to Sendy.
r. Sendy sends his message again including the secret from Receivy.
s. Receivy's server do not block the message because it sees the secret (and 
compared it with the one in Receivy's privacy list of course).

Remark 1: this long scenario will be normally not used for humans. As a result 
only bots will loose *much* time. Bots should also need much computer 
resources as they should remember to not try to spim a user again before the 
long time interval (otherwise it is reset!) and they should do this for every 
user. They also should remember the previous questions and answers they tried 
(more resources! >:-) ).
Remar 2: bots also should be able to handle CAPTCHA's etc, and that this will 
result in even more resources (I love that! ;-) ).

4) Thoughs:
* Should Sendy's server or client store the secret from Receivy? Maybe it 
should be stored in some special part of his roster or privacy lists?
* What about bad servers that were setted up to get much secrets. Maybe some 
kind of encryption is needed for the secret so that server admins can't set 
up a list of secrets?
* If Receivy starts getting spim, he should block that user. If he gets spim 
from several people and blocking do not help, he should change his Bot 
Challange question (and the secret will change then too). He also can try to 
only change his secret (in case the bots do not cache his question and good 
answers).
* The client of Receivy can advice the user when he gets spim. E.g., "Your Bot 
Challenge question was probably too easy. Try to make it more difficult, add 
more answers, increase the long term interval,..."
* The long term interval also can be some kind of exponentional function. So 
Receivy can set for example to: allow three tryings, then increase the time 
interval to 10 minutes, then increase the time interval to 10^2 minutes, then 
10^3, then 10^4, then block that user and inform my server that this user was 
blocked. The server then automatically can block this user for *everyone*. 
The server also can publish the Jabber ID from this user on a web page, XML 
file,... so that other servers also will know this user.
* Receivy's server can detect if someone is DoS'ing several of his users, and 
automatically block him.

<snip>

-- 
Mvg, Sander Devrieze.

xmpp:sander at devrieze.dyndns.org ( http://jabber.tk/ )