I do not think that captcha is the right and best medicine for that issue - it hardly affects user's comfort. I think that per-IP time limitation should be enough for that along with the administrator's responsibility in removal of users which were not logged in for some time period /x months/. I do not see any needs for captcha nor for blocking in-band registration.
Did you track the 'malware' you mentioned? Is that something real or just some people were playing with perl based xmpp-client or anything else? I do not understand why do you mean the problem will be more acute when there will be hundreds of thousands of public servers available in the list. Because at that time there will be hundreds of thousands servers with their's administrators who will be taking care of it and removing not used accounts regularly. I have experience that these 'fake' [probably malware] accounts were never been logged in. Isn't this a way how JabberES's xmpp-search-bot is checking the servers availability? Are you still sure that ban servers which do not provide 'controlled registration' is good idea? Does your server jabber.ru ban jabber.sk? Anyway you did not answer my question how do you check if the server has '[non]-controlled registration'. Do you try to register 'fake' account on all public jabber servers to check that? ;-) -- Regards, Peter Viskup On Thu, Nov 19, 2009 at 7:30 AM, Evgeniy Khramtsov <[email protected]>wrote: > Peter Viskup wrote: > >> What does your expression - 'uncontrolled registration' - mean? >> What is the definition of 'controlled registration'? >> How do you check if the jabber server has 'controlled registration'? >> >> > From my point 'uncontrolled' means: no captcha or no per-IP time limitation > - both of them leads to the ability for massive unlimited registration by > automated software (bots). > By the way, I've found out that even time limitation doesn't provide a good > protection from massive registrations: there is a malware which traverses > the list of public server and registers one account per an iteration on each > server in the list. The problem will become more acute when there will be > hundreds of thousands of public servers available in the list. > > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:[email protected] <xmpp%[email protected]>. > >
