Comments 103
Согласен, соблюдать стандарты — пустая трата времени.
Вообще всегда были подозрительны люди в яшиками не в формате imyafamiliya334356@mail.ru
Вообще всегда были подозрительны люди в яшиками не в формате imyafamiliya334356@mail.ru
Вообще всегда были подозрительны люди в яшиками не в формате imyafamiliya334356@mail.ru
У людей просто нет фантазии, а все нормальные ники заняты )
Люди такие, и фантазии нет, и без таблички «сарказм» к ним лучше не ходить…
Сарказм не всегда бывает к месту.
Расскажите поподробнее
Подробно не сумею, но вот кратко — посмотрите в мой профиль и сравните со своим. На абсолютные значения кармы можно даже внимания не обращать, тут важно сколько людей там отметилось вообще. Итого можно сделать вывод — около 50% людей не любят сарказм при любом раскладе.
Да ну, фигня. Посмотрите в мой профиль :)
Я подозреваю, что карма раздаётся нормальным распределением и в сумме, и для каждого в отдельности.
Гораздо интереснее не цифры в профиле (да и при 6 десятках выводы делать вообще рано), а то, что минусы в карму обычно схватываю там, где в каментах солидно наплюсили. Так что про 50% людей вывод очень куцый.
Гораздо интереснее не цифры в профиле (да и при 6 десятках выводы делать вообще рано), а то, что минусы в карму обычно схватываю там, где в каментах солидно наплюсили. Так что про 50% людей вывод очень куцый.
всегда казалось что уж +tag то — это как раз — RFC — tools.ietf.org/html/rfc3696#section-3
и, нигде не сказано что + обязательно должен именно как алиас поддерживатся
по поводу резки поддоменов — … а как в общем случае быть уверенным что что user@vladivostok.domain.ru и user@domain.ru это один и тот же почтовый ящик? а если есть и user@moscow.domain.ru? а если там user@moscow.russia.domain.com?
и, нигде не сказано что + обязательно должен именно как алиас поддерживатся
по поводу резки поддоменов — … а как в общем случае быть уверенным что что user@vladivostok.domain.ru и user@domain.ru это один и тот же почтовый ящик? а если есть и user@moscow.domain.ru? а если там user@moscow.russia.domain.com?
Сообщество Symfony с Вами не согласно =)
github.com/symfony/Validator/blob/master/Constraints/EmailValidator.php#L66
github.com/symfony/Validator/blob/master/Constraints/EmailValidator.php#L66
Там же:
github.com/egulias/EmailValidator
if ($constraint->strict && class_exists('\Egulias\EmailValidator\EmailValidator')) {
$strictValidator = new StrictEmailValidator();
$valid = $strictValidator->isValid($value, false);
github.com/egulias/EmailValidator
Если вы все-же хотите поддерживать RFC822, то для этого есть perl regex:
Не открывать
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*))*)?;\s*)
ссылка на него есть в статье, кстати.
Регулярку точно писал человек? Не могу прочитать, из-за чего возникла необходимость такой вложенности…
В ссылке в статье есть комментарий автора, что он автоматизировал процесс слияния разных регекспов. Итак, еще раз:
http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
email.match /@/
Вместо тысячи слов
@"><img/src="//owned
и? это уже другая проблема, к проверке email'a не относящаяся
К теме статьи напрямую не относится, но очень часто разработчики грешат тем, что «оптимизируют» экранирование, если уверены, что исходные данные чисты. E-mail или числа — как раз примеры таких данных, только вот и те, и другие могут быть проблемой (про e-mail уже написал, а числа могут быть отрицательными, т.е.
Поэтому совет проверки входной строки на простое наличие там
-... и это иногда может быть дырой).Поэтому совет проверки входной строки на простое наличие там
@ я лично считаю опасным. В общем случае.
Всякие поклонники Смарти, Django templates и т. п., конечно, со мной не согласятся… но, по моему мнению, шаблонизатор, который по умолчанию не эскейпит вывод, это полный треш. Проблемы @"><img просто не должно существовать. Надо заниматься бизнес-логикой, юзабилити, а про это просто не думать. Для меня полнейшая загадка, почему этого ещё не поняли после стольких XSS.
С этим целиком согласен, но даже в новомодном Laravel для PHP стандартный шаблонизатор использует синтаксис подобный Mustache/Handlebars, но заменив
Печально, да. Народ до сих пор в потёмках. Да что там далеко ходить — habrahabr.ru/post/222453/#comment_7576571
{{ }} на некранирующий вывод, а {{{ }}} — на экранированный. Печально, да. Народ до сих пор в потёмках. Да что там далеко ходить — habrahabr.ru/post/222453/#comment_7576571
В Django экранирование по-умолчанию вообще-то =)
Согласен, про Django templates я неправ.
Видимо, сказалась моя к ним ненависть за то, что как-то меня заставили условие разворачивать по ДНФ, т. к. Django не поддерживают скобок в условиях.
Видимо, сказалась моя к ним ненависть за то, что как-то меня заставили условие разворачивать по ДНФ, т. к. Django не поддерживают скобок в условиях.
символы тэгов выкашиваются на более низком уровне для абсолютно всех форм и везде, где пользователь может хоть что-то ввести
Как сказал ahmpro, это уже другая проблема. Такое экранировать при выводе, а не при вводе надо.
exim -bt :)
Это старый стандарт между прочим.
Есть противоположное мнение. Которое, во-первых, не накладывает стописяттысяч странных и непредсказуемых ограничений на пользователей (тем самым, потенциально уменьшая конверсию, как подход в статье, явно придуманный программистами, заботящимися о себе, а не о пользователе), а во-вторых – занимает не целую статью, а порядка одного приложения. Да и в реализации, как ни странно, попроще будет.
Не проверяйте синтаксис почтового ящика вообще, а просто пошлите туда письмо и убедитесь, что оно было получено.
Не проверяйте синтаксис почтового ящика вообще, а просто пошлите туда письмо и убедитесь, что оно было получено.
UFO just landed and posted this here
Кстати, по поводу проверки почты регексами была довольно давно уже статья на хабре
И не одна:
habrahabr.ru/post/55820/
habrahabr.ru/post/175329
habrahabr.ru/post/175375/
Но, эта — лучшая. Она единственная, которая объясняет что плохо и почему.
Кроме того, важно, что она рассеивает ложное чувство уверенности, что адреса почты — это просто и предупреждает грабли, с которыми может столкнуться такой самоуверенный гражданин.
habrahabr.ru/post/55820/
habrahabr.ru/post/175329
habrahabr.ru/post/175375/
Но, эта — лучшая. Она единственная, которая объясняет что плохо и почему.
Кроме того, важно, что она рассеивает ложное чувство уверенности, что адреса почты — это просто и предупреждает грабли, с которыми может столкнуться такой самоуверенный гражданин.
Тоже лет 10 назад не удавалось зарегистрироваться на половине сайтов из-за того, что мой е-мейл начинался с цифры. (1xxxx@abc.com)
Интернационализированные Домены IDNНасколько я помню, поддержки IDN в почте еще нет нигде. Вики говорит вот так:
Всё ещё недоступно в полном объёме применение международных доменных имен в электронной почте. Технический стандарт, благодаря которому это станет возможно, разрабатывается инженерной группой Интернета (IETF)
Gmail тут отличился: в то время как стандарт включает в себя точку как стандартный символ, Gmail не делает различий между адресами ящиков с точками и без.Это же давно известно. Прекрасный способ фильтровать спам — делаем разные фильтры на письма с точками и без. В результате если везде светим адрес в виде «bla.bla», то если придет на «blabla» — 99% что спам :)
UFO just landed and posted this here
я пользую +spam для этих целей, но не всегда пропускает +, тогда юзаю точку. Но фильтр спама на гуглопочты и без этого справляется
Точки поддерживаются только в Gmail но не поддерживаются в Google Apps.
В apps только символ плюса. Так ivan@domain.com и ivan+spam@domain.com являются одним ящиком. На месте уже можно разруливать метки встроенными фильтрами.
В apps только символ плюса. Так ivan@domain.com и ivan+spam@domain.com являются одним ящиком. На месте уже можно разруливать метки встроенными фильтрами.
А вот еще один корректный адрес, он создан из допустимых для адреса символов:
rambler так не думает
Много кто так не думает:
Крупные e-mail провайдеры не разрешают использовать это примерно по тем же причинам; таким образом обычно достаточно дозволять буквы, цифры, точки, подчеркивания, дефисы, апострофы и плюсы.
Надо ввести новое правило для хабраэтикета: не прочитал пост — не комментируй.
Ну да, обычно на форумах вопрос «какое регулярное выражение использовать для почты» начинается с элегантного однострочного RE до огромного, в несколько абзацев монстра.
до огромного, в несколько абзацев монстра
Как в Perl модуле для проверки адреса в соответствии с RFC-822, например.
Собственно, regexp:
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
Не нравятся конторы, которые запрещают «+» в почтовых адресах и пытаются блокировать одноразовые почтовые службы вроде mailinator.com
Борьба с необычными почтовыми адресами — это в чистом виде борьба с пользователями. Нафига пользоваться сайтом, который с тобой борется?
- Я всё равно не скажу им свою реальную почту: если бы хотел, сказал бы сразу.
- Я всё равно найду способ не давать им свой адрес.
- Если совсем ничего не получится, я уйду, не регистрируясь.
Борьба с необычными почтовыми адресами — это в чистом виде борьба с пользователями. Нафига пользоваться сайтом, который с тобой борется?
Подобные конторы хотят на вас заработать и для этого им нужен хотя бы ваш адрес почты. То, что вы предоставите им фальшивый адрес, равносильно для них тому, что вы просто уйдёте. Поэтому подобными сайтами изначально не стоит пользоваться.
Шок! Сенсация! Сайты хотят зарабатывать на пользователях :)
Не стоит ими пользоваться.
Не стоит ими пользоваться.
только сейчас вот пробовала зарегистрироватся с адресом вида vikarti+site@domain.com на сайте где для использования подразумевается платная подписка. но видимо им деньги не нужны совсем и заработать на мне у них не получилось по причине собственной же лени в создании нормальной проверки.
Я вот так делаю:
$email = "example@mail.com";
$apos = strrpos($email, '@');
if ($apos > 0 AND $apos < strlen($email) - 1) {
print('Email ' . htmlspecialchars($email) . ' is valid!');
}
else {
print('Email ' . htmlspecialchars($email) . ' is invalid!');
}
Чтобы лишний раз не отправлять запрос на сервер использую такую проверку:
А чтобы не словить XSS на клиенте данные уже с сервера приходят заэнкоженнные.
/(.*)@(.{4,})$/
А чтобы не словить XSS на клиенте данные уже с сервера приходят заэнкоженнные.
hodor@hodor@hodor
Ну и? Если человек хочет ввести левый меил, то он его введет. И не важно, сколько собачек, запятых или точек будет в сообщении, оно ему никогда не придет, а у вас запись всё же останется.
Email @ is invalid!
Что-то в этом есть. Где бы зарегать?
Особенно радует, что $email = ""; — тоже валидный.
С последним погорячился.
Портанул видимо криво, на js всё ок:
log:
/**
var email = "example@mail.com";
var apos = email.lastIndexOf('@');
if (apos > 0 && apos < email.length - 1) {
console.log('Email ' + email + ' is valid!');
}
else {
console.log('Email ' + email + ' is invalid!');
}
*/
['example@mail.com', '@gmail.com', '@', 'example@', ''].forEach(function(email) {
var apos = email.lastIndexOf('@');
console.log('Email ' + email + ' is '+((apos > 0 && apos < email.length - 1) ? '':'in')+'valid!');
});
log:
"Email example@mail.com is valid!"
"Email @gmail.com is invalid!"
"Email @ is invalid!"
"Email example@ is invalid!"
"Email is invalid!"
«Email @ is invalid!» — вот это валидный email по этой проверке.
Повторюсь, порт на php видимо корявый. А если лень в консоль заглянуть, то пример: js.do/code/38843
Минусовать собеседника — моветон.
js.do/dovg/38846
Email Email example@ is invalid! is valid! — тоже кстати валидный email по вашей проверке.
js.do/dovg/38846
Email Email example@ is invalid! is valid!Email Email example@ is invalid! is valid! — тоже кстати валидный email по вашей проверке.
Из-за таких мнений, что, регистрозависимость можно игнорировать и принудительно приводить имя ящика к нижнему регистру, в большом количестве случаев невозможно пользоваться ящиком на bitmessage-email гейте :-(
Угу. Ещё умиляет мнение людей, которые читают RFC, а видят там фигу. Вот объясните мне, идиоту, откуда взялось мнение о регистронезавсимости адресов? RFC как бы говорит чётко и недвусмысленно: The
local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith".
Стандарт конечно допускает, но если локальная политика запрещает создание таких ящиков, то где здесь проблема? Это хорошая тактика против фишеров. Потому что сходу отлитичить smith@example.com и smIth@example.com (upper «i») в подписанном сообщении (т.е где визуально показано, что адрес легитимный) не представляется возможным.
Вообще статья про то, что стандарты должны адаптироваться со временем.
Вообще статья про то, что стандарты должны адаптироваться со временем.
Можно сохранять адрес e-mail «as is», но при проверке есть ли уже пользователь с данным e-mail, выполнять регистронезависимый поиск (т.к. в 99% случаев регистр действительно не имеет значения).
Ну и с точки зрения пользователя лучше использовать общепринятые стили адресов, а не искать самый экзотический вариант, валидный по RFC.
Ну и с точки зрения пользователя лучше использовать общепринятые стили адресов, а не искать самый экзотический вариант, валидный по RFC.
!#$%&'*+-/=?^_`{}|~example.com <== Корректный адрес вряд ли достойный поддержки
Тот, кто в своё время активно пользовался UUCP протоколом, смотрит на такие адреса с бооольшим недоверием.
Добавлю, что доменное имя не обязательно должно содержать точку, что порой удобно при тестировании:
user@localhost
$emails = ['admin@host.com', 'admin.2@test.gov.com.net', 'путин@президент.рф', 'admin admin@host.com', '@host.com', 'test+next@123.123.123.123', '123312@', '@', 'admin@localhost', '!$%^*@host.com'];
foreach ($emails as $email) {
$valid = filter_var($email, FILTER_VALIDATE_EMAIL);
if ($valid) {
echo "OK: '" . $email . "' is valid <br/>";
} else {
echo "ERROR: '" . $email . "' is invalid <br/>";
}
}
/*
'admin@host.com' - OK
'admin.2@test.gov.com.net' - OK
'путин@президент.рф' - ERROR
'admin admin@host.com' - ERROR
'@host.com' - ERROR
'test+next@123.123.123.123' - ERROR
'123312@' - ERROR
'@' - ERROR
'admin@localhost' - ERROR
'!$%^*@host.com' - OK
*/
Пользуюсь таким вариантов. В целом, сплю спокойно, хотя два последних варианта настораживают.
А как юзать теги в адресе гугловской почты. Отправил письмо на ящик с тегом, оно пришло как обычное, никаких тегов в списке писем не появилось.
Товарищ автор!
Вот, на самом деле, такое же люди как вы, которые считают, что совсем не обязательно поддерживать RFC и достаточно только [a-z0-9.-] меня всё чаще и чаще огорчают тем, что либо нельзя зарегистрироваться на их сайте (плюс у них, видите ли, недопустимый символ для e-mail), либо e-mail просто тупо ВООБЩЕ не приходит, пока там есть экстеншн (да и сам плюс, скорее, всего, тоже).
В общем, чтобы не было разночтений «почему эти куски RFC можно не поддерживать, а эти — нельзя» я таки предлагаю поддерживать RFC полностью.
Как-то так…
Вот, на самом деле, такое же люди как вы, которые считают, что совсем не обязательно поддерживать RFC и достаточно только [a-z0-9.-] меня всё чаще и чаще огорчают тем, что либо нельзя зарегистрироваться на их сайте (плюс у них, видите ли, недопустимый символ для e-mail), либо e-mail просто тупо ВООБЩЕ не приходит, пока там есть экстеншн (да и сам плюс, скорее, всего, тоже).
В общем, чтобы не было разночтений «почему эти куски RFC можно не поддерживать, а эти — нельзя» я таки предлагаю поддерживать RFC полностью.
Как-то так…
Бывает еще смешнее.
На госуслугах у пользователя email с + (разумеется проверка через отправку проверочного сообщения — пройдена).
У банка есть вариант взять данные с госуслуг при заполнении заявки и в этом случае те поля что взяты насколько помню редактировать нельзя.
Вот только банк все равно проверяет e-mail, и не допускает +, форма выкидывает ошибку.
С точки зрения банка — виноват кто угодно кроме них.
Вы меня простите, уважаемый переводчик, но автор статьи является вредителем.
Замечательный, глубокий совет. Зачем слепо подчинятся, когда можно подойти творчески!
А апостроф стоит. Чем объяснсняется такая избирательность?
Было бы недурно перед тем, как воевать со стандартами, их почитать.
Никаких «тэгов» упомянутые 822/2822 не предусматривают. Знак плюс является ВАЛИДНЫМ символов в любом месте адресной части. Существуют другие RFC, которые описывают необязательный механизм адрсации одного ящика многими адесами, который сервера МОГУТ выбрать поддерживать. Опять же, нигде не сказано, что это непременно знак плюс.
Удачи при посылки почты, например, мне. Если регистр будет нарушен, мой сервер отвергнет письмо из-за неверного адресата, и мне пофиг, как это делают другие. Регистр ОБЯЗАН учитываться.
А не Gmail — делает различия. Кроме того, домены под Гугл Аппсом тоже не делают различий. Как будем выходить из ситуации?
А некоторые не являются. Мой реальный адрес выглядит как
Ставлю три бочки рома против дохлого попугая, что неприятности на вашу у вас будут как раз в том случае, если вы будете подвергать «каноникализации» то, что ввёл пользователь, и согласно своему разумению уродовать адреса, сравнивать, и принимать решения об их идентичности либо различности.
UUCP bang path, может, и впрямь экзотика, в первую очередь потому, что с высокой вероятностью сервер вашего провайдера не настроен на их роутинг, но трогать всё остальное, что не содержит знаков "!", это просто накликивать себе проблемы и лучи ненависти благодарных пользователей. DON'T DO IT.
Несмотря на то, что этот совет может показаться слишком радикальным, это все равно лучше, чем слепо подчиняться стандартам.
Замечательный, глубокий совет. Зачем слепо подчинятся, когда можно подойти творчески!
«Alan Turing»example.com <== Это корректно, но поддерживать не стоит
А апостроф стоит. Чем объяснсняется такая избирательность?
Кроме того, некоторые системы позволяют добавлять теги к адресу. Обычно это происходит в формате:
mailbox+tag@hostname
Было бы недурно перед тем, как воевать со стандартами, их почитать.
Никаких «тэгов» упомянутые 822/2822 не предусматривают. Знак плюс является ВАЛИДНЫМ символов в любом месте адресной части. Существуют другие RFC, которые описывают необязательный механизм адрсации одного ящика многими адесами, который сервера МОГУТ выбрать поддерживать. Опять же, нигде не сказано, что это непременно знак плюс.
Считайте, что имя почтового ящика регистронезависимо:
ALLEN@example.com
Allen@example.com
allen@example.com
Удачи при посылки почты, например, мне. Если регистр будет нарушен, мой сервер отвергнет письмо из-за неверного адресата, и мне пофиг, как это делают другие. Регистр ОБЯЗАН учитываться.
Gmail не делает различий между адресами ящиков с точками и без. Эти адреса указывают на один и тот же почтовый ящик:
first.last@gmail.com
firstlast@gmail.com
f.i.r.s.t.l.a.s.t@gmail.com
А не Gmail — делает различия. Кроме того, домены под Гугл Аппсом тоже не делают различий. Как будем выходить из ситуации?
Некоторые адреса содержат ненужные поддомены: например, «email.msn.com» и «msn.com» являются одним и тем же почтовым доменом
А некоторые не являются. Мой реальный адрес выглядит как
name@subdomain.domain.lv, будете выкидывать первую часть или как?Создание второй, канонической, формы сохранения адреса в базе может неплохо прикрыть вашу за вас в случае неприятностей.
Ставлю три бочки рома против дохлого попугая, что неприятности на вашу у вас будут как раз в том случае, если вы будете подвергать «каноникализации» то, что ввёл пользователь, и согласно своему разумению уродовать адреса, сравнивать, и принимать решения об их идентичности либо различности.
UUCP bang path, может, и впрямь экзотика, в первую очередь потому, что с высокой вероятностью сервер вашего провайдера не настроен на их роутинг, но трогать всё остальное, что не содержит знаков "!", это просто накликивать себе проблемы и лучи ненависти благодарных пользователей. DON'T DO IT.
Считайте, что имя почтового ящика регистронезависимо:
ALLEN@example.com
Allen@example.com
allen@example.com
Удачи при посылки почты, например, мне. Если регистр будет нарушен, мой сервер отвергнет письмо из-за неверного адресата, и мне пофиг, как это делают другие. Регистр ОБЯЗАН учитываться.
По вашему мнению, публичные сервисы предоставляющие почту должны регистрировать Allen@example.com и allen@example.com как два разных аккаунта? Почему в таком случае в написании доменных имен регистр не учитывается, а в имени пользователя учитывается? Эта история яркий пример habrahabr.ru/post/224623/#comment_7642915 тому, что стандарт устарел и должен быть изменен.
Мне все равно, что должны и не должны публичные сервисы почты. Я лишь утверждаю, что публичный сервис, который воспринимает почтовые адреса, ДОЛЖНЫ учитывать регистр именной части.
Потому что именная часть контролируется RFC-2822, а доменная RFC-1034.
Когда стандарт изменится хотя бы в виде RFC proposal, тогда и обсудим. Пока же существуют как «Allen@», так и «allen@» в качестве различных адресов на одном сервере, одним чихом это не поменять.
Почему в таком случае в написании доменных имен регистр не учитывается, а в имени пользователя учитывается?
Потому что именная часть контролируется RFC-2822, а доменная RFC-1034.
Когда стандарт изменится хотя бы в виде RFC proposal, тогда и обсудим. Пока же существуют как «Allen@», так и «allen@» в качестве различных адресов на одном сервере, одним чихом это не поменять.
«Разные адреса» не равносильно «разные пользователи». Это дело конкретного почтового сервера конкретной организации, привязывать ли разные адреса, отличающиеся регистром к одному и тому же пользователю или нет. А приложение или веб-сервис не должно считать, что оно лучше пользователя знает, какой у него email и как-то его искажать.
Вот, кстати, про регистрозависимость могу небольшую сказку рассказать.
Жил да был старик Ростом. Хорошо старик жил, в свои 87 успешно пользовался компьютером, ходил по садам зелёным (он каждые выходные приезжал в свой загородный дом на старой советской Волге), писал музыку и ходил собирать грибы. И тут Ростом решил сайт свой сделать. Ну, — думает старик, — дело-то простое, благо, Django ещё года 4 назад выучил. Сверстал всё Ростом, провёл UX-испытания, потом нарисовал прототип ещё более удачного интерфейса, снова за вёрстку принялся, потом сел за программирование бэкэнда, потом JS стал писать. В общем, так месяца два прошло, и в итоге сайт был готов. Два дня он с друзьями событие это светлое отмечал! Компания подобралась хорошая, громкая. Вино пили, песни пели, на гитаре играли. А на сайте тем временем уже где-то полтысячи пользователей зарегистрировалось. И тут стал у Ростома в кармане айфон пищать — сообщения на email приходят. Смотрит Ростом, а это пользователи пишут. Говорят, что не могут на сайт войти.
Стал Ростом думать и гадать, сайт тестировать, и никак не поймёт, в чем дело. С виду — всё работает! Уж было хотел на Тостер иль Stackoverflow вопрос писать, и тут понимает: это так бэкэнд авторизации работает! Пользователь регистрировался с адресом Superkitty@yandex.ru, а вводит при логине superkitty@yandex.ru. Одна лишь буква в другом регистре, но этого достаточно, чтобы сайт считал, что это почтовый адрес другого пользователя.
И ответил пользователю — попросил его попробовать ещё разок. Пользователь попробовал, и у него всё получилось. Вот так вот старик Ростом хоть и убавил соответствия стандартам, но зато позволил большему количеству простых людей иметь меньше заморочек с его сайтом, потому что после этой правки они смогли вводить свой почтовый адрес в любом регистре — и сайт при этом всегда встречал их открытыми дверьми и тёплыми приветствиями.
Вот и сказочке конец, а кто слушал — молодец.
Жил да был старик Ростом. Хорошо старик жил, в свои 87 успешно пользовался компьютером, ходил по садам зелёным (он каждые выходные приезжал в свой загородный дом на старой советской Волге), писал музыку и ходил собирать грибы. И тут Ростом решил сайт свой сделать. Ну, — думает старик, — дело-то простое, благо, Django ещё года 4 назад выучил. Сверстал всё Ростом, провёл UX-испытания, потом нарисовал прототип ещё более удачного интерфейса, снова за вёрстку принялся, потом сел за программирование бэкэнда, потом JS стал писать. В общем, так месяца два прошло, и в итоге сайт был готов. Два дня он с друзьями событие это светлое отмечал! Компания подобралась хорошая, громкая. Вино пили, песни пели, на гитаре играли. А на сайте тем временем уже где-то полтысячи пользователей зарегистрировалось. И тут стал у Ростома в кармане айфон пищать — сообщения на email приходят. Смотрит Ростом, а это пользователи пишут. Говорят, что не могут на сайт войти.
Стал Ростом думать и гадать, сайт тестировать, и никак не поймёт, в чем дело. С виду — всё работает! Уж было хотел на Тостер иль Stackoverflow вопрос писать, и тут понимает: это так бэкэнд авторизации работает! Пользователь регистрировался с адресом Superkitty@yandex.ru, а вводит при логине superkitty@yandex.ru. Одна лишь буква в другом регистре, но этого достаточно, чтобы сайт считал, что это почтовый адрес другого пользователя.
И написал тогда Ростом свой бэкэнд авторизации.
from django.contrib.auth.backends import ModelBackend
from django.contrib.admin.models import User
class EmailAuthBackend(ModelBackend):
def authenticate(self, email=None, password=None, **kwargs):
if not email:
return None
try:
user = User.objects.get(email__iexact=email)
except User.DoesNotExist:
return None
except User.MultipleObjectsReturned:
user = User.objects.filter(email__iexact=email)[0]
if user.check_password(password):
return user
И ответил пользователю — попросил его попробовать ещё разок. Пользователь попробовал, и у него всё получилось. Вот так вот старик Ростом хоть и убавил соответствия стандартам, но зато позволил большему количеству простых людей иметь меньше заморочек с его сайтом, потому что после этой правки они смогли вводить свой почтовый адрес в любом регистре — и сайт при этом всегда встречал их открытыми дверьми и тёплыми приветствиями.
Вот и сказочке конец, а кто слушал — молодец.
Непонятно, почему это для логина на сайте должны действовать такие же стандарты, как для адресов почты.
Ничего нет страшного в том, чтобы адрес сохранять и использовать только в том же регистре, как ввёл его пользователь, а логиниться разрешать с любым регистром.
Ничего нет страшного в том, чтобы адрес сохранять и использовать только в том же регистре, как ввёл его пользователь, а логиниться разрешать с любым регистром.
Ну, гипотетически, сайт таким образом ущемляет других пользователей с тем же адресом, в котором какие-то символы набраны в другом регистре (потому что среди пользователей, адрес которых отличается только регистром символов, сможет зарегистрироваться только первый). Но, как говорится, special cases aren’t special enough to break the rules: в данном случае можно вполне обоснованно принять позицию, в соответствии с которой такие пользователи ССЗБ, и должны использовать другую почту, если сайт им всё-таки нужен.
Итак, вам вероятно следует воздержаться от поддержки адреса, если он содержит:
***
Специальные символы кроме '._+-
***
Вот тут не соглашусь! У одного меня полно знакомых с ящиками, где есть спецсимволы. Особенно часто: _ и -
Страница ада для моего ника. Столько нотификаций я не получал никогда.
Шел 2014 год, а программисты все спорили как проверять валидность email.
Шел 2022 и некоторые программисты считают что если есть
личность A с e-mail'ом <Имя>.<Фамилия>@gmail.com (которая НЕ клиент сервиса O)
и личность B с e-mail'ом <имяфамилия>@gmail.com (которая клиент)
То A обязана получать информацю об заказах и прочем личности B
При этом техподдержка сервиса О то считает что это проблемы личности A и оная личность должна поменять себе e-mail. Ну или написать в гугл. При этом у сервиса есть обязательное указание телефона и они имеют вход через SMS.
Вообще такая трактовка имён аккаунтов как одинаковых внедрена гуглом: регистр букв и любое количество точек в любых местах не имеют значения и игнорируются. Т.е. указанные Вами адреса - это действительно один email. Равно как и Имя.Фам.Или.Я@gmail.com. Так что техподдержка ответила абсолютно корректно.
Sign up to leave a comment.
Никогда не проверяйте e-mail адреса по стандартам RFC