Немало копий поломано в вопросе о том, как следует проверять адрес электронной почты (например, habrahabr.ru/post/175329), но позвольте предоставить вам немного статистики с реального проекта.
Многие захотят спросить, зачем мы её собрали.
Проблема прозаична обычна: в какой-то момент после выпуска аналитик проекта выгрузил статистику по использованию сервиса и понял, что она врет. А врет она потому, что там есть тестовые пользователи, в т.ч. для нагрузочного тестирования. И как оказалось, не все разработчики/тестеры использовали правильную маску для тестовых email. Поэтому, основной задачей было пометить предположительно тестовые email, что и было успешно сделано. Заодно мы получили немного интересной статистики, коей и хотим поделиться.
Итак, есть сервис, который не требует проверки 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% всех пользователей имеют уникальные для данного сервиса домены.
