Немало копий поломано в вопросе о том, как следует проверять адрес электронной почты (например, habrahabr.ru/post/175329), но позвольте предоставить вам немного статистики с реального проекта.
Итак, есть сервис, который не требует проверки e-mail перед созданием учётной записи. На момент написания поста имеем около 5000 зарегистрированных пользователей. Конечно, отсутствие пробелов, наличие «собаки» и прочие явные ошибки были указаны пользователю ещё на этапе ввода, а потому в базу не попали. Получается, что мы не можем достоверно понять, ошибся ли пользователь в левой части e-mail (нельзя ведь исключать, что он опечатался, но и нельзя быть уверенным, что он это сделал), то её сразу следует отбросить. Что мы имеем после этого – домен, а в домене есть домен верхнего уровня.
Оказывается, более одного процента пользователей ошибаются и используют вместо домена верхнего уровня .com, домен .con, это связано с похожестью данных букв и соседним расположением на клавиатуре. С доменами в зоне .ru такой проблемы не обнаружено. Также по косвенным признакам (левая часть email и другие характеристики) был найден еще как минимум один процент пользователей (от общего числа, а не только в зоне com), заметивших ошибку и исправивших её (т.е. в базе есть два очень похожих аккаунта, один из которых неактивный).
Итого, мы имеет как минимум 2 процента неправильных e-mail’ов. Нужно ли что-нибудь делать с этим? Для этого нужно ответить на вопрос,
зачем вы просили email?
Чтобы иногда писать ему письма?
Нестрашно, переживем.
Чтобы у пользователя сохранилась история и/или ему не пришлось бы регистрироваться ещё раз?
Скорее всего, тоже переживем.
Чтобы отправить пользователю информацию о заказе и т.п.?
Пользователю придется поволноваться, пока не получит свою покупку или звонка менеджера. Или даже обратиться в техподдержку. Наверное стоит помечать заказы, для которых не удалось доставить письма, и при звонке таким пользователям дополнительно уточнять e-mail.
Чтобы пользователь мог хранить в вашем сервисе полезные вещи?
Вот это уже серьезней, захочет потом войти ещё раз, и не получится. И хорошо если догадается в чем причина. А ведь может зарегистрироваться ещё раз и начать кричать, что данные пропали.
Как это можно исправить?
Черный или белый список? Можно проверять домен верхнего уровня на наличие в предопределенном списке, который нужно будет часто обновлять (см., например, habrahabr.ru/company/yandex/blog/180355), или на лету проверять на наличие в data.iana.org/TLD/tlds-alpha-by-domain.txt, или же наоборот отфильтровывать явно опечаточные домены, вроде .con.
Запрещать или разрешать? Стоит ли запрещать регистрацию, если, как нам кажется, введенный пользователем e-mail – неправильный? Мне кажется, что нет, но его нужно предупредить и предложить исправить.
Оффтопик: Меня жутко бесят требования сайтов ввести пароль длиннее 7 символов, и чтобы он содержал буквы разные, цифры и знаки препинания, хотя я знаю, что никогда больше не вернусь сюда. Ах да, вы не можете использовать пароль password, а вот gfhjkm конечно же сгодится. А ведь можно предупредить пользователя, что его пароль слабый и, если он таки его заиспользует, то никакие претензии рассматриваться не будут. Хотя как показывает опыт общения с разными службами они всё равно не будут рассматриваться.
– Что же здесь написано? – спросил Фродо, который старался прочесть надпись на арке. – Я думал, что знаю письмо эльфов, но это я не могу прочесть.
– Это слова эльфийского языка древности с запада Средиземья, – ответил Гэндальф. – Но они не говорят ничего важного для нас. Вот что они означают: Дверь Дьюрина, повелителя Мории… Скажи, друг, и входи.
– А что значит «скажи, друг, и входи»? – спросил Мерри.
– Это-то ясно, – ответил Гимли. – Если ты друг, скажи условное слово, дверь откроется, и ты сможешь войти.
– Да, – подтвердил Гэндальф. – Эта дверь, вероятно, управляется словом.
<…>
Он вновь подошел к скале и слегка коснулся своим посохом серебряной звезды в середине, под знаком наковальни. Повелительным голосом он сказал:
– Аннон эдхолен, эдре хи аммен!
Серебряные линии потускнели, но серый камень не дрогнул. Много раз повторял он эти слова в различном порядке, варьируя их. Потом испытал другие заклинания, одно за другим. Ничего не произошло.
<…>
– Я все-таки ошибся, – сказал Гэндальф, – и Гимли тоже. Мерри, единственный из всех, оказался прав. Открывающее слово все время было написано на арке. Перевод должен был быть такой: скажи «друг» и входи. Я лишь произнес на эльфийском языке слово «друг», и дверь открылась.
Что делать?
Сайт или приложение?
Есть пользователь пользуется сайтом для доступа к сервису, то он с большей вероятностью столкнется с повторным вводом e-mail/пароля (хотя предложения браузеров запомнить пароль стремятся максимально его от этого оградить), чем в случае, если регистрация осуществляется непосредственно на мобильном устройстве: пользователь введет e-mail/пароль один раз и больше никогда :) не будет его вводить. А когда придет пара менять девайс, доступа к старому, чтобы найти ошибочный e-mail, может и не быть.
Так проверять e-mail или нет?
Есть три политики проверки e-mail’а:
- проверка обязательна, пока пользователь не подтвердит e-mail ничего делать нельзя;
- проверка необязательна, но часть функционала недоступна, пока пользователь не подтвердит e-mail;
- проверка отсутствует.
Если у вас сайт, то можно воспользоваться вторым способом, причем ограничивать функционал не обязательно, можно не очень назойливо напоминать. Если же у вас приложение, то можно попробовать ввести гибридный вариант проверки e-mail: пользователю высылается e-mail, если он его не подтвердит в течение недели, приложение может показывать напоминалку с просьбой проверить почтовый ящик или убедиться в правильности e-mail’а.
И в качестве бонуса разрешите представить еще немного статистики:
- 65% всех пользователей сервиса зарегистрированы в домене .com;
- 41% всех пользователей сервиса использует gmail.com в качестве адреса электронной почты;
- 25% всех пользователей сервиса зарегистрированы в домене.ru.
- 17% всех пользователей имеют уникальные для данного сервиса домены.
Комментарии (43)
gurux13
12.08.2015 13:56+5Меня больше всего раздражает даже не подтверждение email, а необходимость его дважды вводить. А потом всё равно подтверждать!
Мне кажется, у большинства пользователей стоит автозаполнение поля email (мне хром автоматом подсказывает, хотя я это не настраивал). Но только, черт побери, для первого поля ввода email, для поля «повторите ввод email» приходится делать copy-paste.
И вопрос — нет ли у вас статистики о том, сколько email не было подтверждено никогда (которые можно считать ошибочными)? Это, конечно, имеет смысл только для ресурсов с политикой типа (1) проверка обязательна, пока пользователь не подтвердит e-mail ничего делать нельзя. Для второй политики не так интересно, но тоже может быть полезно.
Спасибо за интересную статистику и статью!
chronomaster
13.08.2015 12:00И вопрос — нет ли у вас статистики о том, сколько email не было подтверждено никогда
В данном сервисе подтверждение email не требуется. Валидный email нужен на случай, если будет забыт пароль.
mdaemon
12.08.2015 14:00+2Я бы еще проверку а ля gmail.ru добавил, пару раз по запарке такой адрес вводил…
chronomaster
12.08.2015 14:31Я так тоже делал, но с тех пор как у самого появился адрес на gmail — перестал.
mdaemon
12.08.2015 14:34у меня есть адрес и на mail.ru и на gmail.com.
chronomaster
12.08.2015 14:43у меня на inbox.ru, поэтому и нет проблемы %)
+ немного статистики по русским доменам:
- mail.ru — 50%
- yandex.ru — 25%
- inbox.ru/bk.ru/list.ru — по 5% каждый
от всех доменов в .ru
Borz
12.08.2015 15:20но ведь ящик и на "@gmail.ru" может быть
chronomaster
12.08.2015 15:24Им не повезло. А зачем нам неудачники?
Не запрещать, а предупреждать. В этом секрет.
domix32
12.08.2015 14:02(см., например, habrahabr.ru/company/yandex/blog/180355)
Что мешает автору сделать текст ссылкой?
KoGor
12.08.2015 16:07+4Бонусная статистика крутая у вас! Не подскажите, как вы создавали эту круговую диаграмму, исходя из имеющихся данных:
- 65% всех пользователей сервиса зарегистрированы в домене .com;
- 41% всех пользователей сервиса использует gmail.com в качестве адреса электронной почты;
- 25% всех пользователей сервиса зарегистрированы в домене.ru;
- 17% всех пользователей имеют уникальные для данного сервиса домены?
А то очень интересен ход мыслей её создателя. Даже если закрыть глаза на то, что сумма процентов больше 100%, а «gmail.com» является подкатегорией ".com", как получилось что сектор gmail больше?
P.S. Для полного счастья ещё не хватает трёхмерности всего происходящего и слегка выезжающего сектора.chronomaster
12.08.2015 16:12+3.ru = 25% gmail.com = 41% .com = 65% - gmail.com others = 100% - (gmail.com + .com + .ru )
а 17% в диаграмме не участвует :)
achekalin
12.08.2015 18:26Добавим к этому предел маразма: по два поля для ввода email-а и пароля:
E-mail: [__________]
Еще раз email: [__________]
Пароль: [__________]
Пароль еще раз: [__________]
Пароль при этом закрывается звездочками, и при сабмите формы она злорадно возвращается юзеру с припиской «Одно из полей не совпадает с другим».
По мне, так делаем поля для эл. почты, и ВСЕ! На почту присылаем пароль. Нет пароля — нет ввода. И, по уму, еще диагностику: «мы попробовали отправить вам письмо, но ваш почтовый сервер ответил „550 No spam here“». И письмо отправлять сразу, а не как иные особо озадаченные жизнью сервисы, «в течении получаса на ваш ящик придет письмо».
aleksandy
12.08.2015 19:14+4Я бы не стал доверять сервису, пересылающему пароли в письме. В письме должна быть ссылка на защищённую страницу, на которой я этот пароль могу задать.
Kalobok
12.08.2015 21:34И если адрес случайно оказался неправильным, ваш пароль сможет задать совершенно посторонний человек.
Правильный способ: человек указывает адрес и пароль, ему посылают запрос на подтверждение адреса (при подтверждении или для логина сразу после подтверждения обязательно спрашивать пароль). Если ответ на запрос не получен в течение короткого времени (день-неделя), вся информация удаляется.
От сторонников остальных вариантов я постоянно получаю письма с чужими паролями, логинами, личными данными, документами и т.п. Поубивал бы.
Accetone
12.08.2015 23:55+1Как вариант, пользователь вводит только email, а по ссылке из пришедшего email заполняет и пароль и остальную необходимую информацию.
Kalobok
13.08.2015 00:00Ну, или так. Главное — не давать доступа к информации по одному только адресу.
catharsis
13.08.2015 01:28Но ведь доступ все равно будет по восстановлению пароля через почту.
Kalobok
13.08.2015 03:03Вот поэтому и надо хотя бы один раз убедиться, что почта принадлежит правильному человеку.
chronomaster
13.08.2015 12:04+1Даже если это регистрация в интернет магазине?
Мы вам перезвоним сразу после подтверждения адреса электронной почты.Kalobok
13.08.2015 15:52Не понял, чем магазин принципиально отличается от всего остального?
chronomaster
13.08.2015 16:14Потому что я хочу заказать товар, и не хочу лезть в папку спам и искать письмо со ссылкой. Или ждать письма. Я хочу, чтобы мне позвонили, а для этого e-mail не нужен.
Kalobok
13.08.2015 16:22Тогда вам просто не нужно регистрироваться. В нормальных магазинах должен быть гостевой режим — заказал, оплатил, ушел навсегда. Письмо при этом отправить можно, но с минимумом информации — «ваш заказ готовится/отправлен» и все. Даже если упадет в спам или уйдет другому человеку, ничего страшного не произойдет.
Про звонок не понял — может, российские магазины работают не так, как в других странах. Зачем нужно звонить?chronomaster
13.08.2015 16:25Про звонок не понял — может, российские магазины работают не так, как в других странах. Зачем нужно звонить?
Для подтверждения заказа. Иногда (часто) ты можешь положить в корзину то, чего нет.Kalobok
13.08.2015 16:29Ну так мылом и ответить — автоматически, дешевле, быстрее. Не нужны люди для обзвона, не нужно ловить момент, когда клиент ответит. Еще лучше прямо при покупке указывать, какой товар есть в наличии, но это уже сложнее организовать.
А телефон человек может указать неправильно с той же вероятностью, что и почту.
rekby
Если проверять, то зачем использовать списки доменов:
1. Это найдет только опечатки для доменов верхнего уровня
2. Да, за этим надо отдельно следить.
Думаю надежнее проверять MX-запись домена, который указал пользователь и (возможно) попробовать подключиться туда.
При желании можно начать smtp-сессию и попробовать проверить левую часть адреса тоже: www.lissyara.su/articles/freebsd/mail/smfsav
Это заметно надёжнее, чем искать опечатки.
dMetrius
Но можно напороться на сервер с грей-листингом и не успеть проверить доставку юзеру за тайм-аут в случае если сервер вернёт временную ошибку.
chronomaster
Проверять только MX-запись (без левой части) бессмысленно, т.к. опечатка может быть везде. Идея проверять smtp-сессией не приходила в голову, скорее всего это «идеальный вариант» для большинства пользователей, если опечатка не ведет в соседний ящик.
Ну и доступность почтового сервера отдельный вопрос, как указали выше.
rekby
Проверка по MX дает точность больше, чем проверка по доменам верхнего уровня.
Например проверка по доменам верхнего уровня не найдет ошибку в user@gmaik.com, а проверка по MX найдет. При этом если не подключаться к серверу, то его доступность значения не имеет (DNS сервера обычно работают заметно надежнее, чем сам сервер).
При этом конечно оба не заметят ошибки при пользователь напишет user@gmai.com — потому что такой домен есть и mx-запись у него тоже есть и скорее всего это мошенники.
chronomaster
я, видимо, криво написал.
Моё мнение такое, что все ошибки не исправить, поэтому не надо сильно парится при проверке. Но самые частые можно и предупредить.
kekekeks
Сервисы типа mail.ru не дают проверять левую часть.
dMetrius
Это почему это?
root@d-metrius:/# host mail.ru
mail.ru has address 94.100.180.200
mail.ru has address 217.69.139.200
mail.ru has address 94.100.180.202
mail.ru has address 217.69.139.202
mail.ru mail is handled by 10 mxs.mail.ru.
root@d-metrius:/# nc -vv mxs.mail.ru 25
mxs.mail.ru [217.69.139.150] 25 (smtp) open
220 Mail.Ru ESMTP
HELO d-metrius.ru
250 mx107.mail.ru ready to serve
MAIL FROM: <admin@d-metrius.ru>
250 OK
RCPT TO: <d-metrius@mail.ru>
250 OK
RSET
250 OK
QUIT
221 mx107.mail.ru closing connection
sent 89, rcvd 115
kekekeks
Теперь попробуйте туда вбить несуществующий email. Или это у gmail/yandex такая проблема была. Надо перепроверить.
TarSer
root@d-metrius:/# nc -vv mxs.mail.ru 25
mxs.mail.ru [217.69.139.150] 25 (smtp) open
220 Mail.Ru ESMTP
HELO d-metrius.ru
250 mx155.mail.ru ready to serve
MAIL FROM: <admin@d-metrius.ru>
250 OK
RCPT TO: <nesushestviyushiydddeeerrr@mail.ru>
550 5.1.1 Bad destination mailbox address
RSET
250 OK
QUIT
221 mx155.mail.ru closing connection
sent 106, rcvd 150
kekekeks
Похоже, моя информация устарела. Прошлой осенью mail.ru отвечал на все такие запросы успешно.
TarSer
Не может быть такой проблемы ни у кого. Это основа основ работы почтовых протоколов.
Может только TEMP FAIL быть, в случае с грей-листингом, но он раньше бы вылетел, а так сервер всегда должен отвечать либо OK, либо ошибку (не существует, квота и т.д.) на указанный RCPT ящик.
kekekeks
mail.ru раньше принимал почту успешно, а потом делал bounce с руганью на левый адрес.
kekekeks
ru.stackoverflow.com/questions/187642/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-e-mail-%D0%BD%D0%B0-%D1%81%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#comment187990_187663 — пруфлинк от 2013-го года.
TarSer
В 2013 — возможно. А я уже год работаю с кодом, в котором есть такие проверки перед рассылкой — всё ок.