Данная статья представляет собой на самом деле скорректированный ответ мой на форуме одной персоне, которая утверждала, что достаточно будет просто сменить пароль и e-mail адрес в деталях, чтобы предыдущий юзер уже не мог вернуть себе данный уин. На самом деле, меня очень часто спрашивают, как могло произойти такое, допустим, что Вы угнали номер, сменили пароль и e-mail, а пользователь всё равно забрал её обратно. Именно поэтому, я решил разметить данный ответ тут.
Эту систему я изучил вдоль и поперёк и на куче форумах уже объяснял как она работает. Я не стал расписывать тут особенности, потому что не было времени, кроме того, всё и так написано в сносках на www.icq.com/password
Ну так что, буду тогда разъяснять:
The password retrieval service is applicable to Email addresses entered as of September 1, 1999, in the Email field under an ICQ number user details.
Ну тут всё понятно - пароли высылаются на любой e-mail, введённый с первого сентября 1999 года. Для особых ценителей точности и тех кто любит придираться скажу, что на все e-mail'ы, которые стояли до 1-ого сентября 1999 года в деталях и существовали в деталях в ночь с 31-ого августа 1999 года по 1-ое сентября 1999 года, также высылается пароль. Иными словами, пароли высылаются на все e-mail'ы, которые стояли в деталях первого сентября 1999 года + на все введённые позже (НО! см. следующий пункт)
Once an ICQ password is retrieved, any further attempt to retrieve the password to a more recently entered Email address for that ICQ number, will fail.
То есть, как только Вы заказали пароль на раннее введённый e-mail адрес, все последующие перестают считаться привязанным к этому номеру (на самом деле, очень хорошо продуманная защита от угона, вдумайтесь). То есть, допустим мы ввели подряд 3 e-mail'а. Назовём их просто так:
A B и С
A был введён первым, а C соответсвенно самым последним.
Мы заказываем пароль на мыло С, результат - мы можем всё завно заказать на любое из этих мыл и они все остаются валидные.
Мы заказываем пароль на мыло B. Т.к. мыло C было введено после него, то оно перестаёт быть привязанним к этому номеру аси. Валидными остаются только мыла A и B (на них мы ещё можем заказать пароли).
Мы заказываем пароль на мыло A. Т.к. мыла С и B были введены позднее, то на них уже ретрив пароля более невозможен. Единственным мылом, на которое может приходить пароль остаётся мыло A.
Please note that if the only Email address entered for your ICQ number is an ICQmail address, you may not be able to take advantage of this ICQ password retrieval service. Если Вы использовали e-mail сервис ICQ Inc, то заказывать пароль на e-mail'ы, зарегестрированные в нём Вы не сможете, т.к. тут используются теже пароли, что в ICQ номере и их смена происходит посредством смены пароля для самого номера ICQ.
Небольшие дополнения. Всё же подумав, мы пришли к выводу, что существует способ отучить асю от мыла ;). Дело в том, что по идее, используя эту систему БД AOL Inc, можно зафлеймить так, как никому и не снилось. Что стоит знающему человеку написать программу, которая будет посылать на сервер каждую секунду штук 100 новых e-mail'ов для данного уина. По идее они все должны писаться... а если таких прог будет параллельно работать 1000, 10000 ... и писать они будут по 1 млн мыл в сумме... ;)))
Посмотрите структуру DAT файла, в нём содержится информация о трёх последних пользователях (кстати, как система разбирается, какой тама пользователь - я не понимаю - вроде новый пользователь считается, если перерегистрировать номер на своём компьютере и сменить e-mail). Кстати ICQr Information 1.2 ещё позволял читать данные о всех трёх поочереди (если они, конечно, имелись), а вот ICQr Information 1.5 уже выводит данные тока одного.
Так вот, есть информация что на сервере AOL Inc. также хранится информация ТОЛЬКО о трёх юзерах. Тока не нуна думать что это = 3-ём мылам. Мне кажется что тама для каждого юзера может быть записано несколько мыл. Так что по идее, при добавлении четвёртого, все данные о первом по порядку просто удаляются. Но это только догадки!
После данного сообщения на одном из форумов, возникла небольшая дискусия насчёт моих догадок. Это сообщение было отправлено мной вслед за предыдущим:
Сразу как я это написал Spacoom быстренько создал прогу которая меняля мыла в асе. За эту ночь прога сменила 11143 мыл на одном уине ;) (10x to Spacoom). Скоро протестируем.
А пока ещё появилась следующая информация, точнее размышления на этот счёт:
То что информация хранится в SQL базе какой-нить - это 100% уверенность, иначе было бы просто не достичь большой скорости и гибкости базы.
Далее, на сервере ICQ обеспечение от MicroSoft, так что скорее всего тама стоит MS SQL.
Теперь всё зависит от того, как именно пишутся мыла в БД. Или каждому принадлежит отдельная ячейка (скорее всего и так, т.к. таким образом можно быстро искать нужную информацию), или, все мыла хранятся в одной ячейке через разделители.
Смотрим первый способ:
Каждое мыло в отдельнйо ячейке. Кол-во "ячеек" в БД MS SQL неограниченно и определятеся только ограничением размера самой базы. То есть, попросту говоря дисковым простанством AOL Inc ;). Мысль тупиковая.
Другой способ:
каждое мыло хранится в одной ячейке, соответствующей уину, через разделители.
Тогда размер ячейки может быть:
Variable-length non-Unicode data with a maximum length of 2^31 - 1 (2,147,483,647) characters.
Variable-length Unicode data with a maximum length of 2^30 - 1 (1,073,741,823) characters.
Короче если тама Юникод - то 1 Gb, если нет - то 2 Gb.
Итого, получается, что даже если хранятся данные в кодировке Unicode, то в каждую ячейку можно записать e-mail адресами на 1Гб.
А мы считайте за ночь максимум записали около 200Кб (сменив чуть больше 11 000 мыл).
С другой стороны такой способ организации информации является маловероятным, т.к. подумайте сами, если занять хотя бы 500 Мб пространства в ячейке, то тогда каким образом будет осуществляться поиск данных по ней? Это загрузит любую систему, пусть даже не на очень продолжительное время. SQL тем и хорош, что поиск между ячейками выполняется очень быстро, но тут не предусмотрно что психи будут вбивать по 1Гб данных в каждую.
Короче, это только опять же размышления, но основанные на реальных фактах.
Thanks to VKE and Spacoom for technical information =).