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