как расшифровать адрес электронной почты
Адрес электронной почты
Мария Смирнова-Матрос
Создайте рассылку в конструкторе за 15 минут. Отправляйте до 1500 писем в месяц бесплатно.
Отправить рассылку
Электронная почта — это такой же важный инструмент связи, как и телефон. Электронная почта используется для общения по работе, для регистрации в социальных сетях и мессенджерах, для покупок в интернет-магазинах, для официальных запросов в госорганы.
Всего в мире более 4 млрд почтовых аккаунтов на 7,9 миллиардов населения Земли. Конечно, не у каждого жителя есть электронная почта, зато у некоторых пользователей по 5 электронных ящиков для разных целей.
В почтовой системе каждому пользователю присваивается индивидуальный адрес — email, который состоит из уникального имени пользователя почты, значка «@», обозначающего, что это email-адрес, и доменного имени.
Например, вот из каких частей состоит адрес электронной почты maria.matros@gmail.com:
Популярные почтовые провайдеры
Почтовые провайдеры — это компании (сервисы), которые организуют доставку и хранение почты:
В каких почтовых программах читают почту в СНГ
Как правило, личную почту регистрируют на каком-то из этих провайдеров.
Как создать электронный ящик
Для создания электронной почты нужно уникальное имя пользователя, состоящее из латинских символов и пароль, защищающий почту. Уникальное имя пользователя + знак «@» + домен, к которому привязана почта — это и есть электронный адрес.
Все адреса электронной почты должны быть уникальными, чтобы точно идентифицировать получателя. Именно поэтому сейчас нельзя зарегистрировать почту, к примеру, ivan.ivanov@gmail.com — этот адрес уже занят каким-то пользователем. Но если ivan.ivanov удалит свой ящик на Gmail — имя снова будет свободно и вы сможете его занять.
На разных доменах может быть одинаковое имя пользователя. К примеру, mariia.matros@gmail.com и mariia.matros@unisender.com.
В почте можно использовать латинские буквы, символ нижнего подчеркивания «_», иногда точку. Символы, которые можно использовать, ограничены протоколами RFC, это общие правила использования символов в интернете. Почтовик, как правило, указывает, какие символы можно и нельзя использовать в логине. Недопустимые спец-символы почтовый сервис подчеркнет во время создания почтового ящика.
Вот ограничения по символам в Почте Mail.ru. У остальных провайдеров они примерно такие же.
Для примера создадим электронную почту на сайте Почта Mail.ru.
1. Заходим на главную Почта Mail.ru.
2. Выбираем «Создать ящик» возле окошка «Вход в почту».
3. Попадаем на главную страницу создания аккаунта в Почте Mail.ru.
4. Заполняем форму создания почтового ящика.
Форма регистрации Почты Mail.ru
5. Заходим в почту с помощью пары логин-пароль, которую ввели при регистрации.
6. Электронная почта готова. Вы можете указывать ее в формах регистрации, подписываться на рассылки — вам будут приходить письма.
Чтобы письма приходили, важно точно указывать адрес электронной почты. Если при заполнении почты опечататься хотя бы на один символ, почта придет другому человеку или вернется отправителю с сообщением «Не существует такого email-адреса».
Для создания почты достаточно пары логин-пароль. Но современные почтовые системы часто просят номер телефона или резервный электронный почтовый адрес, чтобы можно было восстановить доступ к почте, если пользователь забудет свой пароль. Также просят заполнить имя, пол, дату рождения, чтобы сервис идентифицировал пользователя, который регистрирует почту.
Имя будет указано в поле «Отправитель». Если это поле не заполнено, в поле «Отправитель» будет дублироваться адрес электронной почты.
Советы по выбору адреса личной электронной почты
Почта Mail.ru составила памятку о том, как организовать почту и как ею пользоваться.
Советы по созданию пароля для электронной почты
Пароль к электронной почте — один из самых важных паролей, так как получив доступ к почте, злоумышленники смогут сбросить пароли всех остальных сервисов и сайтов, которые зарегистрированы на эту почту. С одной стороны, пароль должен быть надежен, а с другой — его важно помнить.
Некоторые сайты создают дополнительные требования к паролям: не использовать пароли, которые уже были использованы, обязательно использовать и цифры, и буквы, и спецсимволы, использовать буквы разного регистра.
При регистрации почтовый сервис сам покажет дополнительные требования к созданию пароля.
Вот что Почта Mail.ru думает о стандартном пароле qwert
Несколько советов от разработчиков из «Студии Касперского»:
Как узнать свой адрес электронной почты и пароль
Адрес электронной почты всегда можно посмотреть в личном кабинете почтового сервиса, а в «Настройках почты» изменить пароль. Как правило, пароль нельзя посмотреть, его можно только восстановить. Для этого нужно или ввести старый пароль, или ввести резервную электронную почту, или номер телефона. На почту или телефон придет временный пароль, с помощью которого можно зайти в аккаунт почты и в «Настройках» установить новый пароль.
При создании корпоративной электронной почты все эти задачи выполняет системный администратор, а сотрудник получает пару логин-пароль и может зайти в уже созданную почту. Читайте статью, о том, как сделать корпоративную почту на своем домене.
Как создать электронный ящик на Gmail
1.Зайти на главную страницу почтового сервиса Gmail.
2.Нажать на кнопку «Создать аккаунт».
3.Ввести имя, уникальный адрес почты и пароль.
Первый экран создания почты Gmail
4.Ввести номер телефона или резервную почту. Это не обязательно, но без них не получится восстановить доступ к почте.
Заполнение резервных способов восстановления пароля в Gmail
5.Принять правила Политики конфиденциальности Gmail (без этого создать почту не получится).
Важно. Google постоянно меняет внешний вид экрана создания почты, поэтому когда вы будете регистрировать почту, этот путь может выглядеть немного по-другому.
Как расшифровать адрес электронной почты пользователя Gravatar
Этот сервис получился экспромтом в результате одного эксперимента, целью которого было ответить на вопрос: насколько безопасно Gravatar хранит ваш адрес электронной почты и насколько реально расшифровать все адреса всех пользователей Gravatarа (подробности на Habrahabr)! Интересно? Вот подробности:
Как работает Gravatar
Схема не мудренная: пользователь регистрируется в сервисе Gravatar и сохраняет там свой аватар и адрес электронной почты. Теперь, когда он хочет оставить комментарий на сайте или блоге, он лишь указывает свой адрес электронной почты! Скрипт сайта шифрует этот адрес электронной почты и отправляет его на сервер Gravatar, откуда тот возвращает картинку-аватар!
Если мы откроем исходную страницу с картинкой Gravatar, то увидим примерно следующее:
MD5-хэш адреса электронной почты в адресе картинки Граватара
Как видим, картинка загружается с адреса:
и, по сути, содержит один единственный ключ, который и идентифицирует пользователя в системе Gravatar! Но что это за ключ? Это MD5-хэш от самого почтового адреса пользователя! То есть, это и есть сам адрес электронной почты, зашифрованный алгоритмом MD5.
Алгоритм шифрования MD5 есть на всех языках программирования. Вот как это работает на PHP:
В результате функции мы получим 32-значное шестнадцатеричное число, это и есть MD5-хэш!
Теперь, подставлям MD5-хэш в ссылку сервиса Gravatar, чтобы получить урл картинки:
И обрамляем урл атрибутами картинки, чтобы отобразить ее на своем сайте:
Таким вот нехитрым образом Gravatar и работает! Разумеется, есть различные параметры, которые можно передать в урле на сервер Gravatar для получения дополнительной информации: например, размер картинки, рейтинг и т.д. Но это ключевой момент, который нам и понадобится для понимания того, о чем мы будем говорить далее.
О расшифровке MD5
Вы уже наверное слышали, что на сайтах пароли не хранятся в открытом виде и их не может знать даже администратор сайта? Все верно, поскольку пароли хранятся как раз в хэшированном виде (32-значное шестнадцатеричное число). Во время регистрации на сайте, вы придумываете себе пароль, скажем «Mypass15» и в базу данных заносится MD5-хэш вашего пароля. В нашем случае так:
А как же осуществляется авторизация?
При вводе пароля во время авторизации он снова хэшируется:
и получится опять та же самая MD5-хэш сумма:
Хранение паролей пользователей в некоторых движках сайтов все еще осуществляется с помощью алгоритма MD5, хотя сам алгоритм уже заметно устарел (появился в 1991 году) и вместо него есть довольно-таки хорошие альтернативы. Но в Gravatar, при шифровании адреса электронной почты, используется (по старинке) именно этот пресловутый алгоритм!
Расшифровка Граватаров: теория
Мы уже уяснили, что адрес электронной почты пользователя Gravatar зашифрован в самой картинке. И если бы возникла необходимость узнать этот адрес электронной почты, мы бы использовали все свои силы и знания в области «взлома» MD5-хэша.
Есть ли еще варианты, более быстрые и эффективные? В поисках ответа на этот вопрос, меня вдруг посетила мысль: если адреса электронных ящиков ВСЕХ пользователей интернета рано или поздно где-то засветились (в поиске, в спам-базах, в переписке с друзьями и т.д.), то теоретически можно собрать ВСЕ адреса (ну или почти все) со всего интернета в единую базу, перевести все эти адреса в единую большую базу MD5-хэшей, а потом каждый MD5-хэш проверить на наличие в базе Gravatar!
Вскоре, взвесив некоторые доводы «за» и «против», я понял, что по скорости распознавания адресов электронной почты пользователей Gravatar, это будет самый эффективный и дешевый метод. Оставалось продумать механизмы и реализовать все это на практике.
Расшифровка Граватаров: практика
На практике создание сервиса по распознаванию адресов электронной почты пользователей Gravatar сводилось к трем пунктам:
Собрав для пробы публичные электронные адреса, приступил к созданию скрипта проверки MD5-хэша в базе Gravatar. Как узнать, зарегистрирован ли такой-то адрес электронной почты в сервисе Gravatar? Естественно, если мы зашифруем адрес электронной почты в ссылку вида:
мы увидим аватар пользователя, либо дефолтную картинку, что аватара нет. Но как заставить это определять скрипт?
Методом проб и ошибок был выбран запрос к сервису Gravatar по адресу с параметром:
Помимо адреса электронной почты и MD5-хэша, в базу данных решено было вносить и логин пользователя Gravatar, поскольку по логину можно сформировать урл на официальную страницу выбранного граватара для получения дополнительных данных. Такой урл, как уже было указано в самом начале, имеет структуру:
Получить логин можно при обращении к файлу импорта вида:
Итак, у нас есть 3 необходимых значения, для занесения в базу данных, что мы и делаем:
И это все! Осталось запустить скрипт и подсчитать КПД. Для эксперимента я взял 10 млн. адресов из открытых источников (спам-базы и адреса, попавшие в поиск Google открытым текстом) и проверил их на наличие граватаров (обычным локальным сервером Денвер в многопоточном режиме со скоростью 2 млн. адресов в сутки).
Специализируюсь на безопасности сайтов: защищаю сайты от атак и взломов, занимаюсь лечением вирусов на сайтах и профилактикой.
Наверняка у Вас есть вопросы, просьбы или пожелания. Не стесняйтесь спросить, я отвечаю всегда быстро.
Gravatar: как расшифровать адреса электронной почты всех пользователей?
Про Gravatar многие наслышаны, а кое-кто им и пользуется. Если не слышали, то Gravatar — глобально распознаваемый аватар — изображение, которое привязывается к вашему адресу электронной почты и которое вы можете использовать на других сайтах при комментировании, заполнении профиля и т.д.
Сервис Gravatar оказался довольно популярным и востребованным публикой и с годами превратился в свою мини-социальную сеть с многомиллионной аудиторий. Впрочем, сколько всего есть Граваторов (то есть пользователей, которые привязали к своему адресу электронной почты аватар) информации я так и не нашел. Лишь на официальном сайте создатели сервиса с гордостью заявляют, что «Миллионы аватаров показываются более 8,6 млрд. раз в день».
О популярности Gravatar говорит тот факт, что он поддерживается многими популярными движками, такими как, Redmine, W-script и, конечно же, WordPress. Имеются плагины и модификации, которые позволяют интегрировать поддержку глобально распознаваемых аватаров в такие системы, как Drupal, Joomla, MODX, SMF и phpBB.
Работает Gravatar по схеме: пользователь регистрируется в сервисе Gravatar и сохраняет там свой аватар и адрес электронной почты. Отныне у него есть свой Gravatar. Теперь, когда он хочет оставить комментарий на сайте или блоге, он лишь указывает свой адрес электронной почты. Скрипт сайта шифрует этот адрес электронной почты и отправляет его на сервер Gravatar, откуда и возвращается картинка-аватар.
Если мы откроем исходную страницу с картинкой Gravatar, то увидим примерно следующий адрес аватара:
32-значное шестнадцатеричное число в этом адресе есть MD5-хэш самого адреса электронной почты и, по сути, это один единственный ключ, который и идентифицирует пользователя в системе Gravatar.
Алгоритм хэширования MD5, используемый сервисом Gravatar, предназначен в первую очередь для сокрытия адреса электронной почты пользователя (не передавать же его в открытом виде). Его особенностью является «однонаправленность», то есть функцией MD5 мы можем получить (зашифровать) хэш (отпечаток) какого-либо слова, но не можем его получить (расшифровать) обратно. То есть, разобрать, что же именно мы зашифровали в хэш «05933ec7a23f6ebd2017490abfbcd3f3» — невозможно никакой математической функцией.
Тем не менее, существуют методы «расшифровки» MD5, такие как «перебор по словарю», «радужные таблицы» и т.д. В таком случае встает вопрос сохранности адреса электронной почты пользователя Gravatar. Впрочем, сам пользователь может сделать свой адрес электронной почты публичным, а также он известен администратору сайта, на котором он оставляет комментарий. Но вернемся к эффективности использования уязвимого алгоритма хэширования (MD5) сервисом Gravatar.
Насколько он является безопасным и насколько реально расшифровать… все граватары?
Чтобы ответить на этот вопрос, я решил не «взламывать» MD5-хэши (что показалось мне затратным по времени), а проверять наличие имеющего адреса электронной почты на наличие в базе Gravatar. Принцип предельно простой: проверяем адрес электронной почты на наличие граватара, если граватар есть, заносим в базу данных MD5-хэш.
Методом проб и ошибок для таких целей был выбран оптимальный запрос к сервису Gravatar по адресу с параметром:
При обращении по такому адресу сервис Gravatar вернет ответ 200, если у пользователя есть граватар (если вообще такой пользователь существует) и ответ 404 — если пользователя нет в базе Gravatar. В таком случае, пишем скрипт на проверку ответа сервера:
Итак, проверить наличие граватара у адреса электронной почты мы научились. В качестве сырья я скачал первые попавшиеся базы адресов электронной почты из интернета (обычные спам-базы, а также адреса электронной почты попавшие в поисковую выдачу открытым текстом) в количестве свыше 10 000 000 (почистил от дублей, проверил на валидность и т.д.). Поставил на обычный компьютер обычный локальный сервер (Денвер), вышеуказанный скрипт сделал многопоточным (добился скорости проверки около 2 млн. адресов в сутки). К удивлению, не смотря на чудовищные запросы к сервису Gravatar, тот не блокировал работу скрипта и исправно отдавал данные на всем этапе эксперимента.
В течении недели были проверены все 10 млн. адресов, а результат работы записан в базу данных, имеющую следующую структуру:
Напишем скрипт, который найдет требуемую нам переменную под названием — preferredUsername
Пояснения: эксперимент и сервис не создавался в каких-либо злонамеренных целях (для спама и т.д.). Также никто не может нести ответственности за сохранность адреса электронной почты пользователя Gravatar — пользователь осведомлен, что он виден администратору сайта, на котором оставлен комментарий. Заботясь о сохранности персональных данных, я ограничил результаты поиска, закрыл данные от попадания в поисковый индекс и т.д. Сервис, получившийся экспромтом в результате эксперимента, сделан для людей в справочных и контактных целях. А также, как информация к размышлению, для держателей сервиса Gravatar.
Итоги: рядовой компьютер за неделю перебрал/проверил 10 млн адресов электронной почты (взятых из открытых источников). Лишь у 3% (около 300 000 распознанных MD5-хэшей) из них оказался свой Граватар (не густо). Но теоретически все адреса электронной почты у всех пользователей интернета могут быть собраны в единую базу для последующей проверки по описанному методу. И также теоретически все MD5-хэши сервиса Gravatar могут быть вычислены. Все — это намного больше, чем 10%, которые можно получить перебором MD5 хэшей. Алгоритм шифрования адреса электронной почты в Gravatar уязвим, пользуясь сервисом, надо это учитывать.
Никогда не проверяйте e-mail адреса по стандартам RFC
Множество сайтов требуют от пользователя ввода адреса электронной почты, и мы, как крутые и щепетильные разработчики, всегда стремимся проверять формат введенных адресов строго по стандартам RFC. Благодаря этому наши приложения и сайты проверяют формат e-mail корректно и не имеют проблем с юзабилити, а мы сладко спим, потому что уверены, что все работает как надо.
Ага, как бы не так!
Приведенные выше аргументы звучат круто и железобетонно, но проблема здесь заключается в том, что в адресе почты могут находиться совершенно бессмысленные вещи, и, на деле, проверка адресов по стандартам RFC может, наоборот, все жутко запутать.
Почему так? Существует множество способов сформировать адрес почты, который будет одновременно и корректным и бредовым. Отчасти это происходит из-за того, что некоторые почтовые службы в целях обратной совместимости позволяют представлять адреса в форматах, которые давно устарели. Например это электронная почта существовавшая до появления DNS и до появления современного формата user@domain.tld: тогда использовались UUCP ”bang path” — адреса, которые представляли собой список всех узлов по маршруту ответственных за доставку.
Внутренности адреса почты
Адрес e-mail выглядит так:
Тут mailbox может быть локальным аккаунтом пользователя, аккаунтом роли или маршрутизатором автоматизированной системы такой, например, как список рассылки, а в качестве hostname может быть использован любой узел, если о нем известно DNS-серверу, к которому обращается почтовик при доставке.
Кроме того, некоторые системы позволяют добавлять теги к адресу. Обычно это происходит в формате:
где тег и разделитель (обычно это «+», но qmail использует «-» по-умолчанию, хотя может быть сконфигурирован и иначе) игнорируются при доставке. Обычно это используется для фильтрации почты по папкам и автоматизации, но может быть использовано и для разделения введенных адресов по получателям и выявления злоупотреблений персональными данными.
Итак, в адресе в формате «mailbox@hostname», «mailbox» является пользовательским аккаунтом, приложением или аккаунтом системной роли, но может содержать и такие экстравагантные вещи, как информацию для дальнейшей маршрутизации или идентификаторы используемые для сортировки, автоматизации или отслеживания, а «hostname» — обычно доменное имя, но может являться и субдоменом, сервером, сервисом, ip-адресом или просто именем хоста.
Корректные имена ящика с точки зрения RFC
Специцификация одобряет довольно странные адреса, и было бы накладно поддерживать их все потому, что некоторые слишком сложны, и не слишком много людей обладают достаточными знаниями чтобы выделывать такие пируэты в нейминге. Поддержка таких адресов затруднит поддержку таких аккаунтов вашими сотрудниками, к тому же они почти никогда не используются в быту.
Ящик может содержать пробелы. Насколько я помню, доинтернетовский AOL разрешал пробелы в «Imya Polzovatelya», которые использовались еще и как почтовые ящики с вырезанными оттуда пробелами: «imyapolzovatelya@aol.com», однако ж согласно RFC вы можете использовать двойные кавычки вокруг ящиков содержащих пробелы:
Кстати говоря, по этой логике, ящик содержащий всего лишь пробел корректен:
А вот еще один корректный адрес, он создан из допустимых для адреса символов:
Кстати, проверяйте апострофы, апострофы должны поддерживаться:
Апострофы не должны закавычиваться или эскейпиться, но когда вы сохраняете такие адреса в базу или передаете еще куда-то, убедитесь, что всё чики-пуки.
В Википедии есть еще куча примеров.
Нужна ли полная совместимость с RFC? Вам выбирать, но я не советую — пробелы и нестандартные символы в адресе довольно необычная штука и чаще всего являются просто опечаткой. Крупные e-mail провайдеры не разрешают использовать это примерно по тем же причинам; таким образом обычно достаточно дозволять буквы, цифры, точки, подчеркивания, дефисы, апострофы и плюсы.
Регистрозависимые адреса
Согласно RFC уникальность адреса определяется его регистрозависимой уникальностью, однако 99,9% провайдеров считают иначе и не позволяют регистрировать VasyaPetrov@example.com, если vasyapetrov@example.com уже зарегистрирован. Считайте, что имя почтового ящика регистронезависимо:
Небольшая кучка систем использует полную проверку регистра, позволяя лишь адрес Allen@example.com и отбрасывая входящую корреспондецию всех остальных АлЛеНоВ, однако это не работает на практике, поскольку пользователь не привык различать регистр в адресах почты.
Должны ли вы тут сохранять совместимость с RFC? Конвертируя адреса в нижний регистр перед сохранением вы можете доставить проблем небольшому количеству пользователей (вы не сможете посылать им письма), но отослав миллионы e-mail я столкнулся с этим всего несколько раз.
Конвертация в адреса в нижний регистр является неплохой идеей в плане нормализации данных, так как домен всегда регистронезависим и должен быть в нижнем регистре. Если же вы решите сохранять адрес так, как он введен, добавьте поле, в котором будет хранить каноническую версию.
Нестандартные символы
Gmail тут отличился: в то время как стандарт включает в себя точку как стандартный символ, Gmail не делает различий между адресами ящиков с точками и без. Эти адреса указывают на один и тот же почтовый ящик:
Обратите внимание, что Google Apps позволяет использовать Gmail на любом домене.
Основная проблема здесь заключается в поиске адреса в базе в том виде, в котором он был изначально введен, что может доставить немало геморроя как пользователю, так и службе поддержки, а также и программистам с тестировщиками. Тут то вам и пригодится вторая, канонiческая форма адреса, но об этом позже.
Расширенная форма названия ящиков с использованием тегов.
Но нужно ли вычищать теги из адреса ящика?
НЕТ! Будьте дружелюбны к своим пользователям, и пользователи проникнутся верой, что вы не осуществите хищение и сбыт их персональных данных с целью наживы. Даже если вы пытаетесь запретить регистрацию дополнительных аккаунтов с существующим ящиком, представьте себе, насколько просто в наше время тупо зарегистрировать еще один ящик чтобы снова зарегистрироваться у вас — не сложнее создания алиаса или папки(но об алиасах, папках и тегах, наоборот, мало кто знает).
Итак, еще раз. Создание второй, канонической, формы сохранения адреса в базе может неплохо прикрыть вашу за вас в случае неприятностей. Убедитесь, что вы ликвидировали из нее все теги, точки и т. д. и можете сравнивать с ней свежевведенные адреса.
Юникод и интернационализированные имена ящиков
Доменные имена
У почтовых доменов те же самые ограничения как и в HTTP: они регистронезависимые, так что их следует нормализовывать в нижний регистр.
Поддомены
Некоторые адреса содержат ненужные поддомены: например, «email.msn.com» и «msn.com» являются одним и тем же почтовым доменом, кроме того, такие истории часто случаются в корпоративной среде (и это еще один хороший кандидат для каноникализации).
Интернационализированные домены (IDN )
IDN были созданы для того чтобы использовать местные символы Юникода в названиях доменов, кроме того, возможно создать домен и со специальными символами:
этот классно описывает круговорот воды в природе.
Как и HTTP, SMTP поддерживает лишь 7-битную кодировку, и для того чтобы справиться с этим несчастьем IDN конвертируются в Punycode, что позволяет имени домена конвертироваться в представление Юникод и обратно:
Очень жаль, но существует возможность фишинга при использовании IDN. Юникод содержит несколько разных экземпляров некоторых символов ASCII. Это позволяет злоумышленнику создать сайт, название которого выглядит точно также как и оригинал из-за того, что некоторые символы в названии совпадают внешне, но не внутренне.
Это порождает несколько вопросов на которые следует ответить:
Должны ли мы дозволять IDN-адреса? Можем ли мы обеспечить саппорт пользователей службой поддержки (откуда у саппорта, например, клавиатуры с китайскими иероглифами?) Должны ли мы сохранять их в Юникоде или Punycode? Если мы сохраняем каноничные адреса, то в какой кодировке это делать? Поддерживает ли вообще наш почтовик (MTA) IDN, и в какой форме он ждет адреса при отправке писем?
IP Address syntax
Использование IP-адресов допустимо:
Однако такие адреса выглядят подозрительно, и вряд ли им стоит доверять.
Временные почтовые адреса
Существует множество сервисов, которые предоставляют пользователям временные почтовые адреса. Обычно это используется для анонимности или для того чтобы регистрироваться на недоверенных сайтах.
Даже такие сервисы как Hotmail и Yahoo предоставляют алиасы, которые могут быть использованы примерно тем же способом, то есть уничтожены через некоторое время. Не существует единой техники выявления таких адресов — в конце концов именно для этого они и предназначены. Они используют большущий набор доменных имен с постоянной ротацией для того чтобы быть на шаг впереди тех, кто пытается пресечь их деятельность.